- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Interesting F$GETQUI restriction
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2009 08:28 AM
тАО01-09-2009 08:28 AM
I decided to read the F$GETQUI documentation (what a novel idea!) and found this interesting tidbit (DCLI-426):
-----------------------------------Restriction--------------------------------------
The GQC that is saved for wildcarded F$GETQUI calls is destroyed if you run any DCL queue-related command, such as SHOW QUEUE or SHOW
ENTRY. To avoid this problem, use the SPAWN command to create a new process in which to run the DCL commands.
Whoa! Timeout... I've seen so many examples and pieces of code that looped through queue entries and none ever spawned a subprocess before "operating" on the current entry. Even Bruce Claremont's sample code in his article in the OpenVMS Technical Journal volume 11 (F$GETQUI To The Rescue) doesn't.
Bottom line... I modified my script to open a temp file and write out the DCL queue commands I wanted to execute (mostly SET ENTRY commands) then after I had finished looping through all the F$GETQUI entries, I closed the temp file and SPAWNed a subprocess to execute the commands. I didn't want to do a SPAWN for every entry (which would've been the easier thing to do) because there could be hundreds of entries in the queue and I didn't want to spam spawning subprocesses. Now my procedure works 100% of the time.
How many of you knew this restriction?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2009 09:38 AM
тАО01-09-2009 09:38 AM
Re: Interesting F$GETQUI restriction
I ran into it a couple of years ago, but I did not feel I truely mastered f$getqui, and I found that bit of docu then.
So, I blamed my own lack of knowledge, and took the indicated action.
Interestingly, I -- never -- (yet!) had that issue with SET ENTRY, so I did nothing special for those.
You make me wonder now: is this a SHOW-only issue, or have I been "lucky" sofar?
It seems reasonable, that any command that somehow scans queue-related objects DOES need context.
In hindsight it --might-- have been preferable to use a F$GETQUI-specific context specifier (or maybe something like the stream-identifier for f$search) but I do not even KNOW if that would be possible.
But - what you get IS the documented behavior.. :-)
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2009 09:48 AM
тАО01-09-2009 09:48 AM
Re: Interesting F$GETQUI restriction
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2009 09:55 AM
тАО01-09-2009 09:55 AM
Re: Interesting F$GETQUI restriction
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2009 11:35 AM
тАО01-09-2009 11:35 AM
Re: Interesting F$GETQUI restriction
>>>
Where I discovered it was when I was doing SET ENTRY /HOLD (and /NOHOLD).
<<<
I cannot recall any programmed SET ENTRYs.
So, it appears I escaped by pure luck!
Be sure I will remember this one! Thanks!
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2009 03:23 PM
тАО01-09-2009 03:23 PM
SolutionF$GETQUI and (apparently) all the DCL queue related commands all use the default wildcard context. This context is reset if SYS$GETQUI is called with a different object-id, even when there is no wildcard involved in the new SYS$GETQUI call.
Many DCL queue related commands will call SYS$GETQUI at least once, if for no other reason then to use its TRANSLATE_QUEUE function which only has one item code, QUEUE_NAME, and is used to interatively translate logical names - not just for queues but also for forms and characteristics.
So if you are in the middle of a wildcard F$GETQUI loop even this call would destroy the context:
$ NAME = F$GETQUI("TRANSLATE_QUEUE","QUEUE_NAME", "SYS$PRINT")
despite the fact that no wildcard is involved and the "WILDCARD" keyword is not even allowed as a flag argument with TRANSLATE_QUEUE.
Years ago I got tired of writing lots of different command files that used a wildcard F$GETQUI loop to find queues that I wanted to execute commands on (START, STOP, SET) since it was a pain to work-around this restriction. I also had a lot of command files that used F$GETQUI as a selection filter for SHOW QUEUE commands.
Eventually I wrote one command file that can be used for any DCL command line that takes a queue name. Over time I made it more robust and added lots of features. It is attached to this post.
---------------------------------------------
QUEUE_COMMANDS executes any valid DCL command line that uses a queue name. Instead of a single queue name you can use a list of names with wildcards.
Qualifiers not in below lists are passed on so must be valid for the verb.
These three SHOW QUEUE selection qualifiers are supported for any command:
/BATCH Batch queues only.
/DEVICE[=type] Symbiont [type] queues only.
/GENERIC Generic and logical queues (blame DCL for the combo).
These qualifiers can also be used on any command line, including SHOW QUEUE:
/NOGENERIC Execution queues (ignores generic and logical queues).
/[NO]AUTOSTART Queues [not] set to autostart on one or more nodes.
/NODE[=node_name] Queues that execute on given node. "*" and "" allowed.
/STOPPED Queues that are currently stopped.
/CONFIRM Prompt for confirmation before executing commands.
/DISPLAY Display the commands as they are being executed.
/NOEXECUTE Do not execute the commands but do display them.
/NOON Continue with next matching queue if an error occurs.
Note there are two special /NODE= cases and useful combinations of the above:
/NODE=* Execution and logical queues (no true generic queues).
/GENERIC /NODE=* Logical queues only.
/GENERIC /NODE="" True generic queues only (i.e. no logical queues).
Examples:
$ QC :== @QUEUE_COMMANDS.COM
$ QC SHOW QUEUE /ALL/DEVICE/NOGENERIC
$ QC STOP/QUEUE/NEXT * /NODE=ADAM/NOAUTOSTART/DISPLAY
$ QC START/QUEUE /BATCH/NODE/STOPPED *
$ QC SET QUEUE /CLOSE *VAX* /CONFIRM
$ QC PRINT REPORT.TXT /QUEUE=(SYS$PRINT,SYS$PRINT2) /NOTIFY
$ QC @DELETE_OLD_JOBS * -0-04:00 /DEVICE=(PRINTER,TERMINAL)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2009 05:29 AM
тАО01-10-2009 05:29 AM
Re: Interesting F$GETQUI restriction
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2009 09:26 AM
тАО01-10-2009 09:26 AM
Re: Interesting F$GETQUI restriction
I can't speak to the specific queue commands. MAIL was one of the cases I received trouble reports on, and that triggered some documentation updates. IIRC, it was the PRINT command within MAIL that was blowing the f$getqui context freeze, in the particular case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-11-2009 12:44 PM
тАО01-11-2009 12:44 PM
Re: Interesting F$GETQUI restriction
I've certainly been bitten by this before! The reason F$GETQUI is so troublesome is the context is quite complex, but has no visibiliy at all. Too many things can potentially change it. In addition to SET and SHOW QUEUE commands, there's MAIL, as Hoff has mentioned, and I'd also add various TCPIP commands.
Here's a piece of a procedure I use to find and report on retained jobs, or those where the scheduled procedure has been superceeded. Note the comment:
$ IF e.NES.LastEntry
$ THEN
$ WRITE SYS$OUTPUT ""
$! Use SPAWN for the SHOW ENTRY to retain queue
$! context in this process.
$ SPAWN/NOLOG SHOW ENTRY/FULL 'e'
$ WRITE SYS$OUTPUT ""
$ LastEntry=e
>I modified my script to open a temp file
>and write out the DCL queue commands I
>wanted to execute (mostly SET ENTRY
>commands) then after I had finished
>looping through all the F$GETQUI entries,
>I closed the temp file and SPAWNed a
>subprocess to execute the commands. I
>didn't want to do a SPAWN for every entry
I hate temporary files. An alternative is be to write the commands to SYS$OUTPUT, then:
$ PIPE @your-procedure | @sys$pipe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-13-2009 04:18 PM
тАО01-13-2009 04:18 PM
Re: Interesting F$GETQUI restriction
Looks like the $GETQUI doco isn't 100% either.
"The context is marked with the caller├в s mode (user, supervisor, executive, or kernel). Any attempt to use that context in successive calls is checked and no call from a mode outside the recorded mode is allowed access."
Maybe that doesn't apply to the default context.
I can't see any reason why the various DCL commands shouldn't use a unique context. That would avoid most of the problem.