phweb question specific to vms

[Joe Boyle]

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.