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 August, 1988 Is DEC WIMPing Out on DCL? "While we're going to maintain and improve DCL indefinitely, we're changing our focus a bit in the system management area. In the future, the real focus in system management will be in the DECwindows environment... in the future, the real enhancments will be in DECwindows." That comment, made by a DEC representative at the Spring DECUS in Cincinnati, threw many DCL enthusiasts into a tizzy. Was DEC giving DCL and the good 'ol command line interface the heave-ho? By embracing a WIMP (windows, icons, menus, pulldowns) interface, was DEC somehow intimating that DCL would become a relic, an arcane tool used only by DECcie-tecchies on VT52s? At a DEC Pro editorial meeting last year, a fellow editor, extolling the virtues of WIMPish interfaces, announced DCL was gasping its last breaths. "In a year, you'll be out of a job," he told me. Well, to paraphrase Mark Twain, the reports of DCL's demise are greatly exaggerated. SMOKE AND MIRRORS In my DCL training classes, I liken VMS windowing software to the Wizard of Oz, and show a transparency of users cowering before an intimidating god-like image labeled "DECwindows". Off to the side is a non-descript little booth labeled "DCL". And the Wizard image is saying, "Pay no attention to that man behind the curtain." Graphical interfaces on VMS obscure DCL's presence. But just like the little man in the booth, our favorite command language interpreter is there, doing a lot of the work while the flashy displays attract all the attention. WHY WIMP? We've managed quite well with the "$" prompt for the past ten years; why is DEC placing such a major thrust behind graphical interfaces? For the cynics among you, the answer is money. DEC makes a somewhat more substantial profit on workstations than on dumb terminals, so it has a great deal of incentive to get as many users as possible hooked on mice and menus. But there are other valid considerations as well. While the command line will always be around, the market is moving toward graphical interfaces. In the microcomputer world, it's almost impossible to find new application software which doesn't use WIMP as its user interface. Since the line between high-end micros and low-end minis is becoming more nebulous each day, DEC can't afford not to provide a familiar-appearing gateway into its systems. DECwindows, when it officially arrives, will provide significant enhancements to user efficiency and ease of use. For end users running simple tasks such as word processing and other turnkey operations, a WIMP environment makes a lot of sense. Such users are easily managed in the DECwindows environment. System managers can tailor a user's window to provide him or her with only those functions and commands needed to perform assigned tasks. The WIMP interface can be an impenetrable barrier between the user and DCL, insulating the non-technical types from the wilds of VMS and preventing costly mistakes. On the other hand, WIMPs can be a paradise for the programmer, system manager and, yes, the DCL fanatic. The ability to open multiple windows and perform numerous tasks simultaneously will result in phenomenal increases in efficiency and productivity. The cost differential between a workstation and dumb terminal shrinks substantially when one considers the capabilities of each. SEIZING THE OPPORTUNITY For DCL adepts, the disappearing "$" should be viewed as a golden opportunity. New entrants into the VMS environment will be spared the ongoing struggle with the syntax of DCL commands; on the downside, they will have little exposure to the nuts of bolts of dealing with DCL. We "old-timers" will be able to look at a DECwindow, create or modify a command file or add new qualifiers to commands on the menu with great ease. We will be the new "wizards", and users will look at us with awe and admiration. WIMPs? Bring 'em on, I say! They prove the future of DCL is a bright one. As long as VMS exists, DCL will be there. As for being out of a job... well, when DEC comes up with a way to put icons in a .COM file, then I'll begin to worry. ++++++ The mass release of VMS 5.0 should be arriving at your door around the same time this issue appears. There are many new and enhanced commands, but the move to 5.0 should be less traumatic than the jump from 3.x to 4.0, at least from the DCL standpoint. For those of you waiting for your system manager to wade through several hundred pounds of doc and shipping material, here's a quick lowdown on what's new in DCL: IF-THEN-ELSE-FINALLY DCL finally has an ELSE statement, which will reduce the contortions in which procedure writers have had to engage for the past decade. The "classic code", plain-vanilla IF - THENs will continue to function as they have in the past. When used with the new ENDIF command, THEN becomes a verb in a new "block IF" construct: $ IF SOME_VALUE .EQ. 1 $ THEN $ @SOMEPROCEDURE1 $ @SOMEPROCEDURE2 $ ENDIF When we throw in the new ELSE statement, we have: $ IF SOME_VALUE .EQ. 1 $ THEN $ @SOMEPROCEDURE1 $ ELSE $ SOME_COMMAND $ ENDIF ENDIFs are necessary to close the new IF-THEN/IF-THEN-ELSE blocks. Only ENDIFs can have a label specified on the same line. The IF, THEN and ELSE commands cannot be truncated, but you can shorten ENDIF to ENDI if you're a performance junkie. It's possible to nest up to 15 IF statements, but procedures cannot branch out of the current command block into the middle of another command block. New SETS... SET AUDIT has a new /FAILURE_MODE qualifier to deal with how to proceed when resource limitations prevent the performance of security audits. You can have the system wait until it can perform the check, continue, or even crash itself. The SET QUEUE/ENTRY command is superceded by a new SET ENTRY command which modifies jobs pending in a queue. SHOW ENTRY provides a quick way to obtain information about a user's batch and print queue entries; qualifiers to the command accept lists of items, making it far less tedious to learn the status of pending jobs. (Queue management has been completely reworked in v5; ACLs are now supported, and DEC now claims significant improvement in the job controller.) SET HOST/DUP is a more general type of SET HOST/HSC, with /SERVER and /TASK qualifiers. SET HOST/BUFFER permits the user to set the size of the protocol message sent between the terminal and remote processor from 140 to 1024 bytes, with 1010 being the default. Even niftier, SET HOST/RESTORE saves the original terminal characteristics before a remote session and restores them when the session is over. SET PROCESS/SUSPEND temporarily stops a process. SET TERMINAL now knows about VT3xx terminals. New SHOWS... The SHOW QUEUE command has a host of new qualifiers, making it far easier to obtain specific data about queue operation and status. SHOW CPU is a privileged command which returns information on VAXen running in an SPM environment. SHOW TERMINAL has been modified slightly. Other Stuff... A new SYSMAN utility speeds up cluster management and consolidates several system management functions. The RENAME command now requires the process running it to have DELETE access to the file being handled. The RECALL/ERASE command wipes out the contents of the recall buffer. The SEARCH command has been given qualifiers making its command form more in line with other file manipulation utilities. SEARCH now supports /BEFORE, /AFTER, and /SINCE. Other qualifier changes include /FORMAT, which controls how form feed character are displayed, and /HIGHLIGHT, which causes the targeted text to be highlighted in the output display. The new F$GETQUI lexical function will make life simpler for DCL programmers who need to obtain information about batch and print jobs; additional items have been added to the F$GETSYI and F$GETDVI lexicals as well. In the utilities area, MAIL, BACKUP, MONITOR, AUTOGEN, VAXTPU and several other facilities have been reworked, enhanced or modified. It's going to be an interesting fall for system managers. ---------- 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.