Copyright 1990-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 April, 1990 My Skull Is Thick By Kevin G. Barkes Ah, April. The buds are in bloom. Warm winds begin to waft. Sorry for the terse alliteration. It was needed to get past that silly block at the top of the column. Every month I have to write a snappy intro in forced monosyllables or risk having my copy hacked to itty-bitty pieces. (And you thought we columnists lead a cushy life, free from editorial anarchy. Hah.) Since this is the special April Fool's edition of DCL Dialogue, I thought I'd forego the linguistic gymnastics while giving you a fascinating glimpse at the high-pressure world of big-time magazine production. But I digress. Shortly after joining up with DEC Pro, I wrote a parody of one of those high-tech "rumor" columns for an April Fools' joke. That particular piece still shows up on the Internet every year; unattributed, but what the hey. It's been placed on CompuServe and several BBS systems, where others have added and embellished upon the original. I received more comments on that column than any other. It even got me a coffee cup and a good-natured round of approval from the target of my parody. I'm talking about the orginal fella, not the current sorry excuse of a rumor monger who would be better off admitted to the Betty Ford Clinic for Inebriated Pseudo-Technoweenies. I've been inundated with requests to write another parody. (In the DEC magazine business, four requests constitutes an inundation. Five is a groundswell of support. Six is "a user community in turmoil". Just thought you should know how we gauge these things.) Well, I'm not going to do it. It would invariably be compared with the original, which was written during one of those rare periods of enervated inspiration. The last time I had to write something that original was when I had to explain to the IRS why three dozen balloons and ten packages of unflavored gelatin used during the Cincinnati DECUS Symposium should be allowed as a deductible business expense. I'm just relieved they didn't question the plumbing charges on the hotel bill. Instead of attempting to top the original column, I thought I'd observe April Fools Day by recounting some of the inane things VAX users and system managers sometimes do to themselves and their machines. I've committed several of these atrocities myself; heard of some from my local DEC Field Service guys in Pittsburgh; and picked up the rest from late-night DECUS soirees. Next month we'll return to the realm of the practical... but in the meantime, enjoy. SAY WHAT? Picture a small one-person VAX site in the boonies. The manager, hired for his taste in in-laws and not his technical abilities, struggles mightily to maintain the system. He has no personal contact with other users, never "talks shop" with fellow system managers, and has never had to make a service call. His knowledge of VMS and computers is obtained strictly from the doc set. Despite his isolated condition, he manages pretty well. The system goes belly up one day, and he finally has to get on the horn to service. He tells them there's something wrong with the "ka-poo ka-shay". It takes several hours, but Field Service finally figures out the guy has a bad cpu cache. SYSTEM MANGLING You sometimes wonder whether these types of stories are true; that is, that anyone is so dense to attempt this stuff. Alas, I can attest to the veracity of the following tales; names are not used since some of these people are now divisional presidents. The most common one is the guy who "discovers" that a whole bunch of system files appear to be needlessly duplicated in SYS$COMMON. He decides to free up a lot of disk space by deleting the "extra" files. Those having a recent image backup generally survive this debacle and learn of the mystical powers of the SET FILE command; the others seek exciting careers in motel management. DEC Service and I once spent a week trying to figure out the source of recurring corruption on a system disk. Three HDAs and countless service calls later, it turned out the system manager, in an attempt to free up space on the system disk, had deleted the system dump file. Every time the system shut down, it blasted the contents of system memory across the system disk where it thought sysdump.dmp was located. DEC has taken steps in recent releases of VMS to prevent these types of things from happening too often. For example, VMS now keeps the dump file open, preventing its accidental deletion. A system manager acquaintance of mine wished DEC would ship a laminated sheet, similar to the kind they send with VCRs, outlining certain things one should never do on a VAX. Considering how little documentation actually gets read at some sites, it's not surprising lots of VAXes out there perform the moral equivalent of blinking 12:00 a.m. MODE MADNESS One of my favorite personal snafus occurred while trying to automate a site's system startup file. They had a communications program which ran as a batch job, listening for incoming files over a bisync line. As part of the command file's initialization, it would test to see whether it was in batch or interactive mode. If the procedure was executed interactively, it branched to a part of the code that submitted itself to the batch queue. If it was executed in batch, it just sat there waiting for files to come in. Every time the system rebooted, it was necessary for someone to restart the job. I thought I'd make things easier by automatically executing the command procedure from the system startup file. After about a half-hour waiting for the system to come up, it dawned on me that SYSTARTUP.COM executes in batch, not interactive mode; therefore, the VAX was just going to sit there, waiting for a file to come in. It never executed the rest of the startup file (including the incredibly utilitarian SET LOGIN/INTERACTIVE command). Thank goodness for removable disk packs. ONE LINER AWARD My favorite horror story deals with that most feared of computer system failures, the disk crash. A neophyte system manager noticed one of his drives had a fault light on and wouldn't spin up. He moved the pack to another drive with the same result. So he tried it again. And again. And again. Then he put all the original packs back in. The computer room was aglow with red lights. The DEC Field Service guy listened to the tale impassively, then went over to one of the drives and lifted the lid. The inside was coated with a fine covering of brown oxide. "What's that stuff?" the system manager asked innocently. "Data," the field service guy responded. ------------- ONE TECHNICAL NOTE All foolishness aside, it should be noted that the January issue's reference to SET SYMBOL_SCOPE neglected to note explicitly that turning the state "off" prohibits future symbol assignments from being made. Considering the mail I received on this one (a "user community in turmoil", see above), I'm surprised no one pointed it out. ---------- 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.