Copyright 1993-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, 1993 Don't Get Me Started By Kevin G. Barkes You're reading this in May, but I'm writing it in February, arguably the most miserable month of the year. We've had three school-delaying snowstorms in the last week; my VAXstation-induced partial electrocution still hurts like the dickens; my wife and daugher had particularly nasty bouts with intestinal flu; my father had a cataract removed; I'm so far behind schedule on several major projects I've directed my answering service to tell clients I've died; and I've reached the breaking point trying to deal with some of the inanities which exist in the VMS... oh, exsqueeze me... OpenVMS environment. So I beg your humble pardon as I throw caution to the wind and vent my spleen. Feel free to join in at any time. REALITY CHECK - The most common question/complaint heard on the VAXForum on CompuServe and anywhere else VMS system managers congregate is DEC's continuing refusal to recognize the widespread acceptance of Hewlett-Packard LaserJet and non-DEC PostScript laser printers. It seems like every tenth question posted on any VMS-oriented BBS deals with configuring VMS print symbionts to deal with these "foreign" printers. There are workarounds available, mainly through modified device control library modules posted in various public sources by civic-minded individuals. But given the widespread acceptance of these devices, is there any defensible reason why DEC can't add a /DEVICE=LJ or /DEVICE=PS to the SET TERMINAL command? It's certainly understandable that DEC doesn't want to commit itself to officially supporting a rival's product, but it sure doesn't jive with the posture it's assumed since it got religion and started prefixing everything with an "Open" moniker. Virtually every laser printer manufactured today supports either PostScript or HP's PCL language; they are, indeed, defacto standards. Knock, knock... hello, DEC? Anybody home? For heaven's sake, every piece of MS-DOS shareware I own supports LaserJets. You'd think that for the beaucoup bucks we spend every year for VMS support they could come up with a default symbiont that could drive a LaserJet without spitting out extra form feeds. DEC spends millions to make its products and manufacturing processes environmentally correct, yet continues to defoliate the greater northwest by needlessly ejecting an extra blank page on every job sent to a LaserJet. And what about that most accursed of essential i/o devices, the terminal server? What rocket scientist designed this kludge? It has its own software (hence its own set of bugs), its own counter-intuitive command set totally unrelated to the VMS SET TERMINAL command, and rotten documentation. It should be no more difficult to configure a terminal server port than it is to set up a TT port on a VAXstation. (Of course, VAXstation ports don't support modem signals, but that's another issue.) Not a day goes by that I don't get a letter or email message from someone trying to get the rudimentary BEEPER.COM procedure which appeared in last September's issue to work on a terminal server. Some people have managed to do it, but not consistently, and not across all versions of hardware and software; hence I can't publish the fix. You'd think DEC would realize how humiliating it is when it takes an experienced system manager days to get a couple modems and printers reliably hung off a server while the temp from the local office pool can connect the beasties to a PC without cracking a manual. Can you say downsize? Come on, DEC, get with the program. Whew. I feel better now. BUG, FEATURE, OR BOTH? Michael Hewitt of Ottawa, Ontario, Canada asks if I am aware of the "undocumented feature/security hackers back door called @tt". "By invoking it at the DCL prompt," Michael notes, "it can give you a new layer for symbol creation that won't interfere with your parent process" and possibly create some security problems in command procedures which use the INQUIRE command instead of the safer, preferred READ command. Well, I've known about it, Michael, but I never really thought of it as being a security hack. Guess it comes from my naive upbringing. The @ (execute procedure) command does more than execute command procedures. It tells DCL to read as its command input from that point on the file or device name which follows the "@". So, for example, if I have a file called time.com that contains the single word: time And I issue the command $ SHOW @time DCL will read the SHOW command, hit the @, switch its command input to the file time.com, read the word time, and execute the SHOW TIME command. As for @TT, TT is a logical VMS assigns to your LNM$PROCESS_TABLE. You can get the same effect with the process permanent filenames SYS$INPUT, SYS$COMMAND or even SYS$ERROR. They're all "legal" VMS file names, so @ will obediently read input from them while stepping down to the next command level. Thanks for pointing out behavior that's documented but still unexpected. BLATANT PLUG - Another area that generates loads of queries is Pathworks, DEC's single biggest-selling piece of code. The interest in the subject is so high that DEC itself sponsors a PC integration forum on CompuServe (DECPCI) devoted entirely to dealing with questions about the software. Pathworks comes with over a dozen manuals. They're all well-written, to be sure, but the task of getting up to speed is still a daunting one. This onerous chore can be made much more tolerable by getting Ken Spencer's "The Complete Guide to Pathworks" book, coincidentally published by CBM Books, a subsidiary of the burgeoning media conglomerate that also brings you the magazine you're reading. Parochialism aside, though, "Guide" is a smartly-written tome that puts Pathworks in perspective and helps you to successfully install and configure it in record time. The book also comes with a 3.5" diskette jammed with essential utilities and sample files. It's well worth the investment. Additional information about ordering the Guide can be found on one of those irritating cardboard thingies bound elsewhere in this issue, or by calling CBM books at 215-957-4265. BUG FIXES, ODDITIES AND MISCELLANY: Geoff P. Oakley of North Oxford, MA notes that you can control-y out of last April's TERMLOCK.COM procedure if you've run it after doing set host to another system. A double control-y causes VMS to ask if you want to terminate the connection to remote node. The easy answer is you shouldn't have an idle terminal logged on to a remote node. Anyone have the right answer? Thanks to Howard Weiner, Ken Alexander and Marv Pribble for their code and comments this month; yet another reminder the free BBS tape offer has expired; and remember, always ship TK50s in padded envelopes via US Mail unless you don't mind your postal delivery person handing you a bag containing a couple hundred feet of oxide-coated plastic confetti. ********************** Kevin G. Barkes is an independent consultant who should probably switch to decaf at the earliest opportunity. He lurks on comp.os.vms and can be reached at kgbarkes@gmail.com.