phweb question specific to vms

[chuck.reinke]

I believe the programming issue here is a little different.

Problem is that in the stateless environment, the idea of a specific
temporary file wont work conceptually. What is the key for the record ?
You can have a temporary file, but everyone will share the same one.

You can use something like a unique userid and/or password as a unique
index, however.

To get fancy, you might assign a unique id and store it in a cookie.

----- Original Message ----- 
From: "Joe Boyle" <joeboyle_adt@hotmail.com>
To: <powerh-l@sowder.com>
Sent: Sunday, July 04, 2004 8:12 AM
Subject: RE: phweb question specific to vms


> Apologies, I meant to type "deletsystemval/setsystemval combination
> alongside the HTMLFILECLOSE",  although it might be useful to do a
> getsystemval and check that this now agrees that 'what you set is what you
> get' :-)
>
> -----Original Message-----
> From: powerh-l-admin@lists.sowder.com
> [mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Joe Boyle
> Sent: 04 July 2004 16:04
> To: powerh-l@sowder.com
> Subject: RE: phweb question specific to vms
>
> Hi again Bob,
>
> In PH there were two close options, one on the file statement and a
> procedural close option, does the HTMLFILECLOSE option achieve both of
> these, and at the same timing ?
>
> Daniel, I would think you would be wise to see what happens if you use a
> deletsystemval/getsystemval combination alongside the HTMLFILECLOSE
option.
>
> This might be a better option anyway, because it ensures that every screen
> processes against the file logical set by itself. I am assuming that a
given
> PHwebserver can only process one page request at a time - so there should
> only ever be one file logical active for any given PHwebserver.
>
> And, regarding my last code suggestion, code like that below might be more
> effective :-)
>
> If you need to see all records for a given userid use code like that below
>
>   let t-key = userid + "@"
>   while ret filename using t-key via segment-item etc...
>   begin
>      etc...
>
> to write the records use below,
>
>   let key-segment = userid + ASCII ( keynum)
>   put filename reset
>
> better still, use two segments in the key item, e.g. username and recorded
>
>
>
> -----Original Message-----
> From: powerh-l-admin@lists.sowder.com
> [mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Joe Boyle
> Sent: 04 July 2004 15:07
> 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.
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> 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.
>