Copyright 1989-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 December, 1989 Syntactical Dissonance By Kevin G. Barkes SYNTACTICAL, adj., of or in accordance with the rules of syntax. DISSONANCE, adj., opposing in opinion, temperament, etc.; incompatible; incongruous. Not all changes in the behavior of DCL are listed in the VMS Release Notes. From time to time, a potentially irksome change in behavior slips through without official notification. I was working with my VAXstation 3100, learning the new and wondrous features of VMS 5.2, and was testing some previously-written queue management command files and setting up a nightly backup procedure. At first, all appeared ok: $ show queue/batch/all sys$batch Batch queue SYS$BATCH Jobname Username Entry Status ------- -------- ----- ------ DBACK BARKES 37 Holding until 10-OCT-1989 00:00 Then I decided to kill the DBACK job and replace it with a newer version: $ del/entry=37 sys$batch %DCL-W-CONFLICT, illegal combination of command elements - check documentation \CONFIRM\ Huh? Another SHOW QUEUE command revealed DBACK was still in the queue, scheduled for execution at midnight. As for the nature of the error itself, the explanation was simple. Like many users, I have the following line in my LOGIN.COM file: $ DEL*ETE:== DELETE/CONFIRM/LOG And a quick check proved I was correct: $ SHOW SYMBOL DELETE DEL*ETE == "DELETE/CONFIRM/LOG" So, to kill the waiting batch job, all I had to do was: $ DELETE:==DELETE $ del/entry=37 sys$batch I was rather peeved that a command which worked under previous versions of VMS with nary a burp would crash and burn so unexecpectedly. However, being a good DCL camper, I followed the error message's advice and checked the documentation. DELETE/ENTRY, like DELETE/CHARACTERISTIC, DELETE/FORM, and a few other variations, have their own definitions to differentiate them from the plain vanilla DELETE file command. Only the latter has a /CONFIRM qualifier, though; DELETE/ENTRY accepts only a job number and a queue name. Previous versions of DCL were bright enough to ignore the qualifiers which weren't applicable to DELETE/ENTRY; DCL under 5.2 isn't. I couldn't find anything in the DCL Dictionary that would warn of DELETE/ENTRY's new pickiness. A quick scan through the Version 5.2 release notes was also unrewarding. If DEC has this change in behavior documented somewhere, I couldn't unearth it. If it is noted, I know that within a day after this magazine hits the streets, lots of sharp-eyed readers will be directing me to the exact volume, page and line number, as well as providing CLD patches to restore the old DELETE/ENTRY I've come to know and love. Of course, it could be an instance of "syntactical dissonance": a glitch or change in behavior of the CLI. In the meantime, I've resolved my problem with a simple: $ DQ:== DELETE DQ/ENTRY=nnn now works the way the old DEL/ENTRY did. I also discovered using the previous DELETE symbol with /NOCONFIRM also worked: $ DELETE/NOCONFIRM/ENTRY=nnn but that's too much typing. MORE SYMBOL IRRITATIONS: While on the subject, few things are more irritiating than executing a command file which suddenly starts behaving unexpectedly due to conflicting symbol assignments. Even DEC is guilty of this, in a particularly nasty place: the SYS$SYSTEM:SHUTDOWN.COM procedure. I haven't checked recently, but I know that on Version 4.7 systems, SHUTDOWN would come to a screeching halt and the console would display something like: DELETE SYS$SYSROOT:[SYSMGR]SHUTDOWN.TMP;1 ? [N]: if the user running the procedure had DELETE/CONFIRM/LOG assigned to a DELETE symbol. Fixing this type of problem is quite simple, by using the SET SYMBOL/SCOPE command. SET SYMBOL/SCOPE can make local and/or global symbols temporarily undefined at the current command level, eliminating the possibility of conflicts. If you add: $ SET SYMBOL/SCOPE=(NOLOCAL,NOGLOBAL) to the beginning of a command file, you can stop worrying about users with bizarre symbol assignments mucking up the procedure. Be careful, though; if your command file makes references to foreign commands, those too will be undefined. The "P" command procedure parameters are not affected by SET SYMBOL, and once the command procedure exits and returns to the previous command level, all the symbols are "unmasked" and again available: $ @test 1 2 3 4 5 6 7 8 $ SET VERIFY $ SET SYMBOL/SCOPE=(NOLOCAL,NOGLOBAL) $ SHOW SYMBOL/GLOBAL/ALL $ SHOW SYMBOL/LOCAL/ALL P1 = "1" P2 = "2" P3 = "3" P4 = "4" P5 = "5" P6 = "6" P7 = "7" P8 = "8" $ EXIT DCL's F$ENVIRONMENT(SYMBOL_SCOPE) lexical function is a handy tool for checking the status of symbol scoping within an executing procedure. Of course, SHUTDOWN.COM is a DEC-supplied procedure, and you're not supposed to touch it. I compromised and changed the DELETE to DELETE/NOCONFIRM/NOLOG. *************** OTHER 5.2 ITEMS DEC's added a few other goodies to VMS 5.2, including an enhanced BACKUP utility and commands which return information on all nodes in a cluster. The new BACKUP has improved save and copy operations, faster CRC checking for processors that emulate CRC in software (you might consider taking the /NOCRC off your BACKUP commands now), and a control-T command in BACKUP which displays, among other things, the last file scanned, the saveset volume and block number and the size of the saveset blocks. At the time of this writing, there were rumblings on DECUserve and the USENET info.vax conference about problems with BACKUP, third party disk defragmentation software and RMS itself under 5.2. These will certainly be hot topics at the DECUS Symposia in Anaheim, which, due to the marvels of magazine time lag, occurred last month. If you haven't done so already, hitch up with ARIS or one of the other DEC-related electronic bulletin board systems to get the latest info. ---------- Kevin G. Barkes is an independent consultant. He publishes the KGB Report newsletter, operates the www.kgbreport.com website, lurks on comp.os.vms, and can be reached at kgbarkes@gmail.com.