phweb question specific to vms
Deskin, Bob
Bob.Deskin@Cognos.COM
Sun, 4 Jul 2004 19:48:56 -0400
You can't depend on the logical to pass values. It would be an interesting test. First of all, you don't know which PHWebServer will process your request, unless there's only one, but that's not likely in a production system. Second, you'll loose things when the Dispatcher restarts things.
Re the HTMLFILECLOSE, I missed the original. If they're using the old version, HTMLFILECLOSE only applied to relational. In the new version, it also applies to indexed and IMAGE. I can't remember whether we closed non-relational files automatically. Regardless CLOSE on the FILE statement should force a close.
Bob Deskin
Senior Product Manager, Application Development Tools
Cognos Inc. 3755 Riverside Drive, Ottawa ON K1G 4K9 CANADA
bob.deskin@cognos.com (613) 738-1338 ext 7268
-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com]On Behalf Of Joe Boyle
Sent: July 4, 2004 10:07 AM
To: powerh-l@sowder.com
Subject: RE: phweb question specific to vms
Hi Bob,
Does this mean that the latest page to access a PHwebserver will see the
value of the logical set by any preceeding page to access the PHwebserver
and which happened to set the logical ?
Incidentally, I understood this to be an RMS file system enquiry, but I
believe the chap mentioned earlier that he has tried the HTMLFILECLOSE
option and it did'nt help.
-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Deskin, Bob
Sent: 04 July 2004 12:56
To: powerh-l@sowder.com
Subject: RE: phweb question specific to vms
Sorry I missed the original of this.
What may be happening is that the file is not being closed when you leave
the "screen". By default, we do not close indexed or IMAGE files or detach
from relational databases in order to save the overhead.
You can either add the CLOSE option to the FILE statement (probably the
easiest in this case) or change the default using the program parameter
HTMLFILECLOSE.
By the way, we do not restart the PHWebServer process for each request.
Again, this is to save processing. The Dispatcher starts one or more
PHWebServer processes and they wait to process requests. When a PHWebServer
is finished with a request, it sends a message to the Dispatcher indicating
its status and waits for the next request. Every so often (by default 2
hours), the Dispatcher shuts down all PHWebServers and restarts one or more
(based on the configuration settings).
It is because we do not shut down PHWebServers that you may be seeing what
you're seeing.
Please let us know what happens.
Bob Deskin
Senior Product Manager, Application Development Tools
Cognos Inc. 3755 Riverside Drive, Ottawa ON K1G 4K9 CANADA
bob.deskin@cognos.com (613) 738-1338 ext 7268
-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com]On Behalf Of Joe Boyle
Sent: July 4, 2004 7:27 AM
To: powerh-l@sowder.com
Subject: RE: phweb question specific to vms
One more ( or perhaps a better ) thought, I seem to recall that a new
PHwebserver is started every time you submit your form/page. This means
that the new job in which your latest screen/form/page process was running
has no knowledge of logicals set in preceding pages.
In every screen that you call and in which the file is used, I would try
adding a setsystemval call in the initial procedure ( or even the postpath )
or wherever it is now appropriate with Phweb screens. Sadly, I haven't coded
any Phweb for over a year now, there is probably a new procedure purely for
processing of this kind :-)
-----Original Message-----
From: Joe Boyle [mailto:joeboyle_adt@hotmail.com]
Sent: 04 July 2004 11:56
To: powerh-l@sowder.com
Subject: RE: phweb question specific to vms
Hi all,
In order to get an idea of at which level your PHweb screens are seeing the
logicals, why not run two or more user sessions and then run some designer
procedures which call commands with syntax getsystemval, setsystemval and
deletsystemval. You could create procedures one for each of logical trees
process, job, group and system( where privileges allow ). If other users
see changes made by a given user, try another logical tree level.
If the above doesn't help, in the opening Phweb screen, why not prompt the
user for a username ( unless this is already available form calls like
userid - loginid etc... ) and then append ( or prepend ) this id into your
primary key. This userid can be sent around all of the lower screens as a
temporary item.
If you need to see all records for a given userid use code like that below
let t-key = userid + "@"
get filename using t-key via segment item etc...
to write the records use below,
let t-key = userid + ASCII ( keynum)
put filename reset
You might have to do some lookup processing to ensure only one user exist
per userid.
-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com] On Behalf Of
Daniel.Miller@nightfreight.co.uk
Sent: 02 July 2004 16:20
To: powerh-l@sowder.com
Subject: RE: phweb question specific to vms
hi,
the file is unique just by using a sequential number.
My thinking behind having separate files is that one of the uses is
postcode/address lookups which can sometimes produce huge results if the
user put in "high street" etc. There is code in to try and stop this but
sometimes someone will do something thats not been thought of and it still
happens occasionally.
If we did go with one file it would likely need to be cleared daily, which
might be a problem if parts of the site are available 24 hours.
Saying that the number of files is a valid point and if this problems not
easy to solve then all this might be overkill and ill go with one big file.
Im also considering maybe having a big file for some things and individual
files for other uses.
-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com]On Behalf Of Chris Sharman
Sent: Friday, July 02, 2004 3:46 PM
To: PowerH List
Subject: Re: phweb question specific to vms
daniel.miller@nightfreight.co.uk wrote:
> hello all,
>
> my situation is as follows:
>
> Phweb screen A creates a unique physical rms indexed file with "run
command" and then sets a process level logical with "setsystemval"
that points the open name of a file in the dictionary to it. The screen
is then able to put data into that file and pass the file name to screen B
as a parameter, its a hidden field on the page. This is all in one
procedure, which deassigns the logical with deletesystemval before
finishing.
>
> Phweb screen B then sets a logical to the passed filename and then
reads the data from this file.
> It then does a deletesytemval before finishing.
>
> The idea is each person who uses the website gets a unique temporary file
with only their data which are cleared off the system after a couple of
days. Id prefer this to one big indexed file which all website users would
have to access which i guess would need to be cleared daily or some such.
>
> However this technique only works the first time, in subsequent uses of
the page it keeps picking up data from previous uses. It appears that with
all the subprocesses with the dispatcher and phwebservers the logical is
still assigned somewhere. Similiar to with dcl subprocesses for run
commands etc in normal ph.
How exactly do you 'create a unique file' - most webservers reuse
processes, so if you use the process id, it won't be unique.
Show us the code that generates the unique name/file, please.
Given the propensity of web browsers to quit mid-transaction, you'd
probably better call deletesystemval on entry too, in case there's some
old, undeleted context.
I'd question the idea that every user needs a unique file, too, unless
your user data size approaches or exceeds 32k: if you've got very large
numbers of these users, you're going to finish up with a very large
directory (which VMS can struggle with), and a lot of wasted space in
partially filled clusters.
Having one file, and giving each user a unique record in it with a
timestamp, will probably work better for smallish record sizes, and will
do away with the "run command", which incurs the significant overhead of
a process creation in VMS.
Chris
-----------------------------------------------------------------------
Any views expressed in this message are those of the sender and not
necessarily those of CCA Group. The unauthorized use, disclosure,
copying or alteration of this message is forbidden. The contents of
this message may be confidential and/or privileged, copyright CCA Group
and are intended solely for the use of the individual or entity to whom
they are addressed. Whilst this message has been scanned, CCA Group
cannot guarantee that it is virus free or compatible with your systems
and accepts no responsibility for any loss or damage arising from its
use. The recipient is advised to run their own anti-virus software. If
you receive this message in error please contact
postmaster@ccagroup.co.uk immediately, destroy any copies and delete it
from your computer systems.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.sowder.com
Subscribe: "subscribe" in message body to powerh-l-request@lists.sowder.com
Unsubscribe: "unsubscribe <password>" in message body to
powerh-l-request@lists.sowder.com
http://lists.sowder.com/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.sowder.com
Subscribe: "subscribe" in message body to powerh-l-request@lists.sowder.com
Unsubscribe: "unsubscribe <password>" in message body to
powerh-l-request@lists.sowder.com
http://lists.sowder.com/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.sowder.com
Subscribe: "subscribe" in message body to powerh-l-request@lists.sowder.com
Unsubscribe: "unsubscribe <password>" in message body to
powerh-l-request@lists.sowder.com
http://lists.sowder.com/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.
This message may contain privileged and/or confidential information.
If you have received this e-mail in error or are not the intended recipient,
you may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so. Thank you.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.sowder.com
Subscribe: "subscribe" in message body to powerh-l-request@lists.sowder.com
Unsubscribe: "unsubscribe <password>" in message body to
powerh-l-request@lists.sowder.com
http://lists.sowder.com/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.sowder.com
Subscribe: "subscribe" in message body to powerh-l-request@lists.sowder.com
Unsubscribe: "unsubscribe <password>" in message body to powerh-l-request@lists.sowder.com
http://lists.sowder.com/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.