Setting VMS logicals from Quick

[Hamilton, Allison]

It is perfectly legitimate to change logicals while within QUICK so long as
you know what you are doing, and recognise that the RUN COMMANDs are being
done in one or more subprocesses (which is why the JOB table is used, so
that all subprocesses AND the parent can see the change if necessary - the
parent can't see something changed in the subprocess otherwise.)  The use of
GETSYSTEMVALUE and SETSYSTEMVALUE means that the current process table is
enough, as it's changed within the parent process.  Here though, you may
still want to use the JOB table if you've already done a RUN COMMAND as it
would not have inherited the new logical and may be re-used by a subsequent
command.   For files that have already been opened by QUICK, you would have
to close them so that the next access would reopen the file using the new
logical.   

Changing logicals on the fly is a very useful tool, but does require careful
and thorough testing in order to ensure that no timing anomolies will cause
the wrong file to be used if the logicals will only be used within the
current QUICK session.  If RUN COMMANDs are where the new settings will be
used, then usually just putting the logical in the JOB table is enough.
Allison Hamilton

> ----------
> From: 	Chris Sharman[SMTP:Chris.Sharman@ccagroup.co.uk]
> Sent: 	Monday, February 15, 1999 4:18 AM
> To: 	martyn.thomson@gems1.gov.bc.ca
> Cc: 	Chris.Sharman@ccagroup.co.uk; powerh-l@lists.swau.edu
> Subject: 	RE: Setting VMS logicals from Quick
> 
> >I've tried doing a run command "$DEASSIGN/JOB"   between the DEFINEs and
> >that works, but the second DEFINE still doesn't work.  This I know from
> >stepping through in debug and using "$show logical TAB$SUBJ$AREA"
> >
> >Any ideas why redefining the logical doesn't work?
> >Any suggestions for an alternative strategy?  
> >Although it works at the first attempt if the file exists, is it even a
> >valid technique to declare a file before it's specification is known?  I
> >didn't write this program;-)
> 
> You seem to have solved the problem, but the question of whether it's
> valid to
> declare a file before defining the necessary logical is interesting.
> 
> I'd always assumed it wasn't. We use logicals to implement
> customer-specific
> price files for certain customers, rather than the default file, but we've
> always made users come all the way out of Quick to change files.
> 
> Can anyone say when it's valid to change the logicals ?
> My screen does an explicit getsystemval to display which file it's got, in
> addition to the implicit translation done to open the file. I'd hate for
> them
> to get out of synch, and I'd always assumed that once you'd got to the
> screen
> it was too late to change, and also that the second open would use the
> context
> of the first open rather than re-translating.
> 
> PS: I'd have thought getsystemval & setsystemval preferable to 'run
> command...'
> 
> 
> ______________________________________________________________________
> Chris Sharman			Chris.Sharman@CCAgroup.co.uk
> CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancashire, PR2 9WS.
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> =
> Subscribe: "subscribe powerh-l" in message body to
> majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
> powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
> This list is closed, thus to post to the list, you must be a subscriber.
> 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.