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 Twice Burned Originally published May, 1995 By Kevin G. Barkes In my 13-plus years of home office computing, I have had two catastrophic system failures which resulted in hardware damage and loss of data. The cause of both disasters was of a surprisingly unexpected source: uninterruptible power supply (UPS) units. In each instance, the UPS units failed during power outages and sent "dirty" current to my systems. The VAXstation power supplies were hardy enough to withstand the abuse, but the power supplies in the clone PCs fried themselves and caused some collateral damage to peripheral cards and modems. The UPS manufacturers blamed the failure of their units on batteries which were older than two years and power surges in excess of the published tolerances the UPSes would accept. So much for lifetime warranties. I probably could have haggled, but who has the time? I bought replacement units from a different manufacturer. The first incident happened about six years ago and put me out of business for two days, until I could get new PC power supplies Fedexed. The most recent calamity only kept me down for a few hours, thanks to the fact one of those computer superstore chains finally opened an outlet in Pittsburgh. The moral here is don't blindly trust your UPSes. They're sort of like smoke detectors; a great concept, but worthless if the batteries aren't working. The fact that the VAXstations came through without a problem while the commodity-class personal computers smoked themselves reinforces the old cliche, "You get what you pay for." ******************* DCL MAILBOX CREATION. A VMS mailbox is a software data structure that simulates a record-oriented device. It's used for inter-process communication; senders write to a mailbox, receivers read from that maibox. While mailboxes can be accessed from DCL, mailbox creation requires calling the $CREMBX system service, and there's no direct DCL command to do that. There is, however, DCL_MBX.COM (Program 1), a command procedure originally posted to the Usenet newsgroup comp.os.vms by Mark Graybill, modified by Anthony C. McCracken and based on a handout distributed by Skipper Morris at his Advanced DCL Hackery DECUS session. Mr. McCracken, in posting the modified code published here, notes: "The original posting of DCL_MBX worked but had some side effects that were not necessarily good. There were a few syntax errors that didn't show up due to the fact that the subprocess was killed prior to executing those statements. "The main process used a STOP PROCESS to kill off the subprocess after snagging the subprocess' termination mailbox. This had the side effect of leaving an extra channel assigned to the mailbox. Since the subprocess was stopped it never wrote a termination message and DCL never deassigned its channel. In other words, there's no easy way short of logging off to make the mailbox(es) go away. "I changed the main thread of execution to do a RESUME on the suspended subprocess instead of a STOP; this causes the subprocess to terminate and write its termination message to the mailbox. DCL then deassigns its channel, leaving only the main thread OPEN with a channel. Once you close DCL_MBX(nnn) the mailbox goes away. "I commented out PIPE and GREP since these conflict with PIPE and GREP which are part of our DCLTABLES. I fixed up the syntax errors in the last few lines since they are now executed and changed the SPAWN/NOWAIT/PROCESS=... to SPAWN/NOWAIT/OUTPUT=NL:/PROCESS=... so that the subprocess won't write any garbage to the main processes screen. "Here's the fixed up version, thanks Jerry and SKIP::MORRIS for the ingenious DCL hack. This one should go into Kevin Barkes' DCL Dialogue column in DEC Professional." Okay Anthony, you asked for it... ******************* COLOR ME MIFFED. The art department here at Cardinal Business Media does a great job designing and typesetting DEC Pro and its sister publications. I have only one gripe: the shading in the boxes containing program listings. Now, if you hold the page at arm's length and view it strictly from an aesthetic perspective, those grey boxes look spiffy. But when you're fortysomething and trying to type in DCL code with lots of apostrophes and quotations, it's a real pain to the eye and lower portions of the anatomy. I think the art people believe I'm a tastless heathen, which is true but beside the point. If shaded program boxes bug you, send a note to DEC Pro editor Eric Schoeniger or drop him e-mail at schoeniger@cardinal.com. Don't send mail to me; you're preaching to the choir. ******************* BBS INFO. I get a lot of requests for information about setting up and running computer bulletin board systems. Sometimes I think I'm running a BBS consulting business judging by the calls and e-mail I get. Last month was especially heavy with BBS-related inquiries, to the point where I was spending upwards of three to four hours a week answering questions. For those of you who want to start a BBS, here's a short list of vital info: 1. Most BBS software is MS-DOS based. I know of no commercial VMS BBS software, and Unix-based software is comparatively expensive and difficult to maintain. 2. Multi-user BBS systems use either a) built-in multi-taskers, b) QEMM and DESQview for multi-tasking under MS-DOS, or c) networked PCs, using Netware, LANtastic, or other networking software. I use Pathworks for my multi-node networked BBS system, and I haven't had any problems. Indeed, VMS and Pathworks provides probably the most stable platform for networked BBS operation. 3. Get a copy of Boardwatch Magazine, the unofficial bible of BBS system operators. It's published monthly and is available at most large bookstores. If you can't find it locally, call them at 800-933-6038 or write them at 8500 W. Bowles Ave., Suite 210, Littleton, CO 80123. Virtually all BBS software vendors advertise there, and most have demo versions of their software available for download from their respective support BBS systems. 4. Get "Running A Perfect BBS", published by Que, available at most bookstores (ISBN: 1-56529-919-1). It includes a stripped-down but functional version of Mustang Software's Wildcat! BBS system on 3.5" disk. The book does a fairly comprehensive job of covering all aspects of BBS design, installation and operation. I would have recommended it even without receiving the free review copy, but thanks anyway, Macmillan... ******************* Kevin G. Barkes is an independent consultant whose favorite television show, "Lois & Clark: The New Adventures of Superman" is reportedly being considered for cancellation by ABC. Give the program a look, and if you like it, send mail to abcaudrccc@abc.com and tell them you'll quit painting mustaches on Peter Jennings' pictures in TV Guide if they pick up the series for another season. Kevin lurks on the comp.os.vms newsgroup and can be reached at kgbarkes@gmail.com. -------------- PROGRAM 1 MBX.COM $ vfy = f$verify(0) $! CREATE_MBX E2.3 (Create a mailbox for use from DCL) $! Skip Morris, "SKIP::MORRIS", 9-July-1986 Based on $! ideas and work by Jerry Leichter, Dave Lennig & Elis::Garson. $! $! This procedure creates and opens a mailbox for use from DCL. The $! maibox is given the process logical name DCL_MBX. If it is run $! multiple times, extra mailboxes are given the names DCL_MBXnn. $!- $ my_pid = f$getjpi("","pid") $ if f$leng(p1) .gt. 0 then goto subprocess $ count = "" $! allow for multiple mailboxes to be created (not to exceed 32 total) $ sanity_count = 0 $loop: $ sanity_count = sanity_count + 1 $ if sanity_count .ge. 32 then exit 4 $ if f$trnlnm("dcl_mbx''count'") .eqs. "" then goto spawn $ count = f$stri(f$inte(count)+1) $ goto loop $spawn: $ dcl_mbx = "dcl_mbx" + count ! logical name used $ procedure = f$envi("procedure") $! spawn a subprocess creating a mailbox... $ spawn/nolog/nowait/out=nl:/proc=crembx_'my_pid' @'procedure' 'my_pid' 'count' $ set process/suspend/id=0 $ mailbox = "mba" + f$trnlnm(dcl_mbx) $ open/read/write 'dcl_mbx' 'mailbox': ! grab mailbox $ deassign/job 'dcl_mbx' ! remove job logical $ set proc/resume crembx_'my_pid' ! Allow subproc to die $ write sys$output f$fao("%CREMBX-I-CREATED, mailbox !AS !AS: created.", - dcl_mbx,f$trnlnm(dcl_mbx)) $! The following may conflict with symbols defined elswhere $! pipe'count' == f$fao("spawn/nowait/nolog/output=!AS:",f$trnlnm(dcl_mbx)) $! grep'count' == f$fao("search !AS:",f$trnlnm(dcl_mbx)) $ exit 1+0*f$verify(vfy) $! $subprocess: $ mailbox = f$getjpi("","tmbu") $ define/nolog/job dcl_mbx'p2' 'mailbox' ! tell parent mbx name $loop: $ set process/resume/id='p1' $ wait 00:00:01.50 $ if f$extr(0,3,f$getjpi(p1,"state")) .eqs. "SUS" $ then $ sanity_check = f$integer("''sanity_check'")+1 $ if sanity_check .gt. 256 then exit %x4 $ goto loop $ endif $ set process/suspend/id=0 $ exit 4+0*f$verify(vfy)