Copyright 1993-2016 by Kevin G. Barkes All rights reserved. This article may be duplicated or redistributed provided no alterations of any kind are made to this file. This edition of DCL Dialogue is sponsored by Networking Dynamics, developers and marketers of productivity software for OpenVMS systems. Contact our website www.networkingdynamics.com to download free demos of our software and see how you will save time, money and raise productivity! Be sure to mention DCL Dialogue! DCL DIALOGUE Originally published February, 1993 Using $ENTRY By Kevin G. Barkes Back in January '91, when I was commiserating with you about the problems of staying current with new features in VMS and DCL, I mentioned in passing how I had missed the $ENTRY symbol that had been introduced in VMS 5.4. Recently I had a need to come up with some improved methods of checking the status of batch job execution. As I repeatedly entered SHOW SYSTEM/BATCH and SHOW PROCESS/CONTINUOUS commands at the keyboard, I realized there had to be an easier way to do this. Laziness and sloth can be marvelous motivational devices. A dim bulb flickered in my mind (hmm... sounds recursive to me) and a search through past articles recalled the reference to $ENTRY. Whenever a SUBMIT or PRINT command is successfully executed, VMS creates or updates a local symbol named $ENTRY with a string containing the entry number of the most recently queued job. With this one piece of information, it becomes a snap to write 1-line command procedures that can return all sorts of information about the last batch or print job you submitted. A few quick examples: $ SHOW PROCESS/CONTINUOUS BATCH_'$ENTRY' gives a continuous display of the job while it's executing. $ PID = F$GETQUI("DISPLAY_ENTRY","JOB_PID",$ENTRY) will return the process id of the submitted job, which you can in turn feed to other procedures or routines. For that matter, with $ENTRY and the F$GETQUI lexical, you can get literally hundreds of pieces of information about your job. $ENTRY also makes life with the SYNCHRONIZE command a lot easier, permitting you to write generic procedures which automatically and dynamically determine the required command qualifiers. One last note... while the doc says the value of the $ENTRY local symbol is stored as a string, and, indeed, a show symbol command produces: $ show symbol $entry $ENTRY = "44" a call to the F$TYPE lexical indicates otherwise: $ WRITE SYS$OUTPUT F$TYPE($ENTRY) INTEGER which points out an interesting attribute of F$TYPE. The lexical returns "INTEGER" if the symbol is originally equated to an integer: VALUE = 14 OR (and this is the significant part) if the symbol is equated to a string whose characters form a valid integer. This piece of trivia is good for winning bets with co-workers. ("Hey Charlie, why are you using an integer instead of a string here?") ******************** READER COMMENTS November's article on BACKUP prompted some interesting and useful reader comments. Joe Gurman, whose Internet address suggests he's somewhere within NASA, points out the problems with being too conservative and using broad generalizations. "[E]ven DEC recommends using /BLOCK = 40960 or some similarly large number for BACKUP operations to a TLZ04 or other helical scan tape drive," Joe notes. "If you use the default block size on such devices, you end up writing a huge amount of blank tape (given the physical block size they use, 8192 bytes in the case of DDS DAT, vs. the default size of 8464 bytes for BACKUP) and slowing the drive from cache/streaming to clunkity-clunk. Exabyte drives, if I'm not mistaken, will even write blank blocks to avoid slowing down. "The omission of the /BLOCK = 40960 qualifier," Joe points out, "stretches an /IMAGE BACKUP of an RZ23 on a VAXstation 3100 from under 20 to over 40 minutes - yecch. And we've never had a restore problem with the DATs at any block size. Given the large number of sites now using helical scan tapes for BACKUP, I'd hate to see people slowing down their drives for no special reason. "The moral may be," Joe suggests, "don't screw around with the RECOMMENDED (rather than DEFAULT) block size for a given medium." Comet of Oracle Corp. commented "One of the design features of the TK drives is that they like to "stream" tapes. They don't like start/stop processing, so they have a tape controller which supports write caching, so mounting the tape /CACHE=TAPE_DATA will speed up the backup." He also reminded that "[I]n VMS 5.4, the BACKUP Utility changed dramatically. It is very important that the account performing the backups be configured correctly to take advantage of the new algorithm. See section 1.1 "Setting Up the Account from Which You Perform BACKUP Operations" in the manual for details. Table BCK-2 shows sample suggested values, and Table BCK-1 shows how to make the fastest BACKUP process possible, since it allocates the maximum amount of resources that will be used. If you change the UAF quotas as suggested, you will notice a performance increase for BACKUP at no cost to safety. You will also notice that anything else happening on the system will go slower, as BACKUP will be using up memory, I/O, and CPU resources (same amount of work, but in less time--BACKUP is working harder!)." And finally, thanks to Tom Ohlendorf of Towson State University and Sean Brennan of the Stanford Synchrotron Radiation Laboratory for passing along some interesting .com files. ********************** Kevin G. Barkes is an independent consultant whose current favorite e-mail tagline is "Scrute the inscrutable, eff the ineffable." Kevin lurks on comp.os.vms and can be reached at kgbarkes@gmail.com.