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 March, 1989 By Kevin G. Barkes DEC's Dastardly DCL Plot Until a few days ago, I honestly believed the enhancements which DEC added to DCL in VMS version 5.0 were examples of a responsive company listening to the requests of its customer base. Imagine my surprise when I learned DEC's true, sinister intent. A commentary published in a trade journal intimated that DEC's been adding bells and whistles to DCL in order to trick people into thinking it's a full- blown programming language. Once users are entranced by DCL's state-of-the- art syntax (apparently, the addition of an ELSE statement), they will forsake their C, BASIC and Fortran compilers and begin writing everything in Digital Command Language. Because DCL is inherently less efficient than compiled languages, "programs" written in it run more slowly and consume more system resources. Therefore, in order to maintain the throughput necessary in today's fast-paced business world, these DCL junkies will force their management to purchase bigger and faster VAXes to run their code more quickly. An insidious plot, this. Unfortunately, the author of the piece did not offer any strategic countermeasures, such as dumping VMS in favor of ULTRIX. A UNIX-like system which does not coddle its users with such evil devices as command names which accurately describe program functions, it should be clear that ULTRIX is morally superior to VMS. Consider the command which searches through files for matching strings. DEC calls its DCL variant of this function "SEARCH", pandering to the laziness of the masses. The UNIX flavor of the command is GREP, which insures that it is employed only by persons who really know what they're doing. It's this philosophy that places UNIX users head and shoulders above their VMS counterparts. An operating system in which it's easier to write a C program to perform a function than remember a command name will naturally produce better users. Perhaps DEC can take the first step at rectifying this problem by removing all the vowels from its DCL commands in the next release of VMS. It took a lot of soul-searching to decide to continue producing this column; we certainly don't want to be considered pawns in DEC's plot to put 8800s in every VAX site in America. But on the outside chance that DEC's motives, if not totally altruistic, are also not completely manipulative, let's remove our tongues from our cheeks and forge ahead... ***** A Big Utility One problem we face on an ongoing basis is insufficient space to run all the great command files submitted by our users. Over a year ago, Mark Polakowsi of Toronto, Ontario Canada submitted a suite of procedures which enable users to maintain indexed, relative and sequential RMS files. Unfortunately, we've never had the room to publish five the .COM files which comprise the set. So, we've instituted a new policy of accepting such submissions and placing them in the download area of ARIS, where at least some of our readers can access them. We feel limited distribution is better than none at all, and we hope you'll agree. The procedures are bundled in the file "FILEMAN.TXT" in ARIS' DCL area. A programmer/analyst at Canadian Fine Color Co., Ltd., Mark's procedures can call each other or can be used as standalone utilities. "Although (they) will work for all file organizations," he notes, "best efficiency is obtained for indexed files. For sequential and relative files, processing takes longer... as records can be accessed only sequentially." Mark's full description of the utilities is included in the ARIS download. And A Small One Doug Parsons, a Software Analyst at The Boston Globe, submitted a short procedure written by a fellow programmer which generates a unique name by manipulating the system time. This is particularly handy when it's necessary to produce temporary files which are created and discarded during the execution of another command file. As a rule, most random file name generators use a combination of system time and process id number to insure the string is totally unique. This simpler alternative is useful when the need for absolute uniqueness is not required. The name is placed in the symbol UNIQUE_NAME unless a P1 parameter is supplied to the procedure. In that case, the value of P1 is used as a symbol name to pass the string. $! UTCOUNIQ.COM $ ON CONTROL_Y THEN CONTINUE $ SYMNAME = "''P1'" $ IF SYMNAME .EQS. "" THEN - SYMNAME = "UNIQUE_NAME" $ PARSED_NAME = F$FAO("!%T",0) $ PARSED_NAME = "''PARSED_NAME'" - ":" - ":" - "." $ 'SYMNAME' == "''PARSED_NAME'" $ EXIT 1 ****** ---------- 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.