Copyright 1988-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 May, 1988 By Kevin G. Barkes The Five-Oh Defense Nothing sets a DCL hacker aquiver quite like the anticipation of "a future major release of VMS". With the impending introduction of 5.0, a lot of people are shaking like southern California near the San Andreas fault. Some can't wait for the rumored enhancements to DCL; others, remembering some of the conversion problems from 3.7 to 4.0, are simply quaking in fear. Converting your DCL code to run properly under 5.0 can be either a dream or a nightmare, depending upon the approach taken. If you observe the basic recommendations listed here, the chore will be less onerous. 1. Get a hard copy of all your DCL command files. 2. Produce a listing of all the files, along with their purpose and where they're invoked. This can be tougher than it seems. At many sites, symbols used for activation of .COM files have been around so long the procedures they call may be well nigh forgotten. Do a SHOW SYMBOL/GLOBAL/ALL to pick up any "hidden" procedures. Another easily overlooked source are calls within DEC-supplied system command files, like SYS$SYSTEM:STARTUP.COM and SYS$MANAGER:SYSTARTUP.COM. 3. Make certain your present procedures work properly and are self-documenting. Go through them and get rid of all inoperative code, invalid comments and commented-out lines. Make certain each procdure contains a line explaining its function, and if it is called from another command file, the caller's name. Make certain they work as intended. When you're done, print them out again. 4. Classify the procedures as critical (needed for system startup and configuration), urgent (needed for proper application operation), non-critical (nice to have, but you can live for a while without them), and trash. "Trash" procedures, those which haven't been used for ages, never did work, or of unknown purpose, should be written off to tape for "just-in-case" safekeeping and then deleted. (You'll probably need the extra space for 5.0!) Of course, don't blow away any files in any SYS$ directories without being absolutely certain they're not DEC-supplied and therefore non-essential. Now's a good time to move command files which are not specifically system-related to site- specific directories. (And remember, the "$" is a DEC-reserved character.) 5. Study the release notes, making certain you understand all the changes in DCL command syntax. Command qualifier default changes and alterations in command display output are the two most common sources of problems. For instance, much grief was caused when DEC changed the default condition of BACKUP's /REWIND qualifier back around version 3.4 or 3.5. Unpleasant situations of this nature can be avoided by making certain the commands used in your critical and urgent procedures don't use "defaults" implicitly. A quick rule of thumb: if the command will fail when a "non-default" qualifier is used, include the qualifer. This has the added benefit of making future changes to the .COM file easier to implement. Procedures which write the output of a command to a file (such as SHOW USERS) and read it back in are also candidates for close scrutiny, as DEC usually enhances command displays with each new release. The F$EXTRACT call which presently pulls out a user name might, under 5.0, return nothing but spaces. You can expect procedures using MONITOR and SHOW to require modification; it's likely that queue management commands will also need tweaking. 6. Avoid temptation... don't try to implement the marvelous enhancements to DCL initially. Your first job is to get your system up and running and your applications humming along. Make as few changes as necessary; after everything's operating reliably, you can start adding your improvements. Major operating system upgrades are painful in any environment, but fortunately DEC goes to great pains to automate the process and to provide the system manager with all the information required to effect a smooth transition. The installation procedures and documentation will contain detailed instructions and explicit directions; follow them religiously. ------------------------- In last August's column, we featured a command procedure by James Robanske which enabled users to send themselves reminder messages via MAIL. Craig W. Dickinson of GE Consulting Services liked the procedure but wanted more... mainly to be able to "send an alarm of more than one line to myself or other users. I eventually modified the routine to allow the user to specify a filename containing a multi-line message or simply enter a one-line alarm as in Mr. Robanske's ALARM.COM program. "A highlight in the program is the fact that the INQUIRE statement was not used while prompting the user for message input. By utilizing the READ statement, blank lines could easily be entered and the user could exit by simply entering control-z..." I hope Craig doesn't mind, but I also added a few bells and whistles of my own to message.com, mainly support for MAIL distribution lists. This little procedure can now send a message to users in a .DIS file at a scheduled time in the future. ---------- 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.