Copyright 1995-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 Automatic Foreign Commands Originally published September, 1995 By Kevin G. Barkes Of all the enhancements in Version 6.2 of OpenVMS, the one I consider most interesting is the addition of "automatic foreign commands" to DCL. It finally gives VMS the MS-DOS/Unix capability of searching a user-defined pathlist of directories for command procedures or images to execute. And it executes them without using the "@" or "run" commands. Under older versions of OpenVMS, when you entered something that wasn't a DCL symbol or a real DCL command, the interpreter spit back an error message that you had entered an unrecognized command verb. With OpenVMS 6.2, you can define a search-list type logical called DCL$PATH. If the command interpreter fails to find a DCL symbol or a valid entry in the DCL command tables, it does an RMS $SEARCH operation for any file in DCL$PATH that contains the invalid verb in its file name. So, if I enter "FOO" at the command line, and I have no symbol defined for FOO, DCL looks at DCL$PATH for files named FOO.COM or FOO.EXE. If it finds a match, it either executes the command procedure FOO.COM or activates the image FOO.EXE. If you have both a FOO.COM and a FOO.EXE, the .COM file will be run, since $SEARCH finds the .COM file before .EXE file. At least it does on VMS, which sorts its directories in alphabetical order. If you're accessing another operating system over a network, you get whatever gets found first. The rest of the command line is passed as parameters to the .COM or .EXE file. Bear in mind that if you're activating an image, the called program will have to do its own command parsing. DCL just passes the whole line on to the program without doing anything to it. Now before you start defining DCL$PATH to search your entire disk farm, you should give some serious thought to the implications of your action. Automatic foreign commands could wreak havoc on an unprepared user community. System managers should implement this feature carefully, and users might want to protect themselves by explicitly defining DCL$PATH to "" in their login.com files, to avoid any surprizes A couple other gotchas: OpenVMS allows characters in filenames that are not legal in DCL symbols. For example, OpenVMS filenames can contain hyphens and begin with a dollar sign. DCL symbols cannot. If the program or command procedure you want to execute has a filename that contains characters not permitted in DCL symbols, automatic command execution won't work. Also, since DCL only looks at the first four characters of any command verb, it can miss files that have names similar to actual DCL commands. A file named DIRECLIST.COM will never get executed by the automatic foreign command feature, since DCL will execute the native DIREctory command first. ****** OTHER STUFF. One really nice addition to the 6.2 distribution kit is a CD-ROM chock full of freeware and public domain software. It also contains stuff that was developed internally by Digital, like SDL, NMAIL, MAILWATCH, Internet programs and even compilers for Bliss-32 for VAX and Alpha and Bliss-64 for Alpha. OpenVMS Engineering is looking for software to include on future editions. The guidelines for submission are fairly straightforward: The software has to be free, with no license fees; It has to run on OpenVMS 6.0 or later; Digital offers the software without warranty, provides no support, and guarantees only that it occupies physical space on the CD; and Users can adapt the source as they see fit. If you can't get your hands on your site's copy of the CD-ROM, you can check out http://www.openvms.digital.com, Digital's external OpenVMS web site. ****** ZIPs and UNZIPs In talking about zip-compatible file compression software in the July issue, I managed to mangle the information concerning its contributors and neglected to point out that Zip and Unzip are two different packages maintained by different folks. Greg Roelofs, the maintainer of Unzip and its principal author, brought us up to date on the latest ports of the software: "Minix is basically Unix, the Mac port (for Info-ZIP's Zip) was never completed, there have been OS/2, Amiga and Human68k ports for years (not to mention DOS, of course), and there are now Acorn RISCOS, MVS, VM/CMS and maybe one or two other ports. UnZip currently has more ports than Zip (including Macintosh and a Windoze GUI)," Greg reports. The authors list published in July "covers most of Zip but skips half of the main UnZip authors (including myself)", Greg notes. "A complete list of the 17 or so primary authors is on our home page, http://quest.jpl.nasa.gov/Info-ZIP/ Note that Hunter Goatley is responsible for the DCL interface in UnZip 5.12 and in the upcoming version of Zip (2.1)." Greg also pointed out that support for VMS file types was provided by Igor Mandrichenko of "our Russian/Ukrainian contingent." As for my comment about compatibility problems with older versions of the software, Greg commented: "If we could get rid of all the old versions, we would. Most of the ftp sites in the world aren't all that well maintained, however. And note that Zoo suffers the same problems with respect to compatibility of compression methods; it's just not as noticeable since Zoo versions prior to 2.0 were never all that popular. LHa/lharc also have this problem. If you want your data compression to continue to improve as new algorithms are discovered and implemented, that's the price you necessarily pay." And as for my comment about carriage returns being "mysteriously" added to the end of records on a text file that was zipped to VMS disk by a pathworks-connected PC, Greg explained, "Nothing was mysteriously added; go look at the original file with a hex dumper or editor. CR/LF is how PCs mark line-endings. Zip has a -l option and UnZip a -a option to convert text files appropriately. (I think the latter is "/text" in the DCL version.)" Thanks to Greg for his comments and insight. Guess it's time to fire up the web browser and start looking... ******************* Kevin G. Barkes is an independent consultant who quotes Jeremy S. Anderson, who notes the two major products to come out of Berkeley are LSD and UNIX, and who doesn't believe this to be a coincidence. Kevin lurks on comp.os.vms and can be reached at kgbarkes@gmail.com.