Quick CLOSE command behavior

[Cousins, Michael]

Quick reads pointers ( logicals on VMS, file equations on HP, environment
variables on UNIX) at initialization of the Quick session, not necessarily
the processing screen. Once read, the pointer is stored in memory and not
reset until the session of quick which read the pointer is exited.

To achieve the processing you wish, you would have to call Quick from Quick
once the new pointer command is issued. This is usually accomplished by
using a RUN COM off of a menu which executes a server script to set the
environment and then start Quick.

Cheers,
/mc

-----Original Message-----
From: Murray Scholz [mailto:murray.scholz@abri.une.edu.au]
Sent: Thursday, February 01, 2001 5:13 PM
To: Kesterson, Roger; POWERHOUSE List Server
Subject: Re: Quick CLOSE command behavior


Hello Roger,

One would think that the CLOSE verb should do the trick for you,  unless
of course the file has been opened at a higher level screen. ???  (in
which case the close verb will do nothing at all).

To achieve similar functionality to what you're after here, we have put
the CLOSE option on the file statement (eg. FILE XXX OPEN READ SHARE
CLOSE) , exited the processing quick screen back to a higher level
screen (which successfully releases the file), then at the higher-level
screen do the re-assignment of the logical name for the file (perhaps by
the user entering the filename of the new file which they wish to look
at/process now), then re-enter the processing quick screen.  This
approach works fine.  If the CLOSE verb itself won't work for you, you
could do something similar to this in your batch quick screen.

Regards
Murray Scholz
Associate Director
Agricultural Business Research Institute
University of New England
Armidale NSW 2351 Australia

"Kesterson, Roger" wrote:
> 
> PH 7.10.G2 on Alpha OpenVMS 7.1
> 
> We have some Quick programs that run in batch and process requests from
our
> data collection systems via mailboxes.  These Quick programs retrieve data
> from our MRP system (indexed RMS files) in the process of handling the
data
> collection requests.  The files are defined in Quick as "FILE X DESIGNER
> OPEN READ SHARE".  The MRP system is taken down once each month for
> end-of-month processing which requires exclusive access to all files.
> 
> To allow the data collection process to continue during these periods, the
> files used by Quick are backed up to another location, and the logical
names
> that reference them are redefined to point to the new location.  In an
> attempt to get Quick to relenquish access to the production files, and
open
> the backup copies instead, I added a reset request which, when received by
> Quick through the mailbox, causes the program to do an explicit "CLOSE" on
> each file.  My assumption was that the file would be released, and the
next
> time Quick tried to access it, it would be reopened at the new location.
> 
> My assumption was apparently incorrect, the file is not released.  When I
do
> a "SHOW DEVICE/FILES" in the production directory, it still shows Quick as
> having the files open there.  Can anyone explain this?  Is there a way to
> get this to work, besides exiting and restarting Quick?
> 
> Thanks,
> 
> Roger Kesterson
> Senior Programming Analyst
> MTD Southwest, Inc.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
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
This list is closed, thus to post to the list, you must be a subscriber.