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 June, 1990 By Kevin G. Barkes DCL on the Edge of Forever We had just rebooted the system following a software upgrade, and everything had checked out fine. The test suites ran without a hitch, the queues had come up perfectly, and even the laser printers kicked in with nary a burp. Saturday was off to a good start. I was heading home to the second day of a six-hour "Trek-A-Thon" on the local independent television station. (This installment of "DCL Dialogue" was also due but, hey, there are priorities, you know?) The Star Trek episode "City on the Edge of Forever" was scheduled to be aired, and no true Trekker would voluntarily miss it. Generally considered to be the finest show of the old series, the original draft of "City" won a Writers' Guild award for Harlan Ellison. The teleplay by Gene Roddenberry garnered a Hugo award, the science fiction community's highest honor. I was also looking forward to re-watching my SuperBeta hi-fi copy of "Yesterday's Enterprise", an episode of "Star Trek-The Next Generation". This show also dealt with the paradox of altered timelines and featured special effects of big-budget motion picture quality. Some fans have suggested "YE" is the best "Trek" story ever, and I was eager to review it again for perhaps the fifth time to form my own opinion. This time I'd watch the battle sequence in digitally-enhanced slow motion, a frame at a time. So much for magazine deadlines. You can imagine my consternation as the system manager and I were halted in our tracks by the irritating sound of VT220s beeping throughout the production area. I glanced at the nearest screen, and saw: -------------------------------------------------------------- Figure 1. Reply received from user DAYSTROM at M-5 Batch 09:30:04 Please perform incremental backup. -------------------------------------------------------------- "We have to do an incremental backup?" I asked, trying to mask my annoyance. "We just did a full image backup on all the drives." The system manager sheepishly logged into a terminal and killed the offending batch job. "Just ignore it," he said. "It's to remind everyone to run the incrementals during the week. I forgot to set the job back to Monday before I left yesterday." I glanced at my watch. Oh, what the hell. "Let's fix it," I offered, and had him call up the .COM file. A quick look at the screen revealed the first thing the command procedure did when it began execution was to submit itself again 24 hours later. I decided to take the easy way out and not fudge with the logic of the SUBMIT command. Instead, I added the following immediately after the SUBMIT: --------------------------------------------------------------------- Figure 2. $ DAY = F$CVTIME(,,"WEEKDAY") $ IF DAY .EQS. "Saturday" .OR. DAY .EQS. "Sunday" THEN EXIT --------------------------------------------------------------------- "There," I announced proudly. "No more spurious backup announcements. Let's warp out of here." The system manager didn't move. "Uh, there's still a problem," he said. "This file also runs at midnight. We have a shift here late Friday night that runs over into early Saturday morning. When this thing kicks in then, it'll exit. That message must go out, or the people here will forget. The Friday night incremental is really important; it's the last backup before the weekend." "Well, just check the hour field to see if it's midnight," I offered, edging toward the door. "I'm a manager, not a programmer," he snarled, his right eyebrow rising nearly to his hairline. And obviously part Romulan. I made a few quick changes: -------------------------------------------------------------------- Figure 3. $ DAY = F$CVTIME(,,"WEEKDAY") $ HOUR = F$CVTIME(,,"HOUR") $ IF - DAY .EQS. "Sunday"- .OR. - (DAY .EQS. "Saturday" .AND. HOUR .NES. "00")- .OR. - (DAY .EQS. "Monday" .AND. HOUR .EQS. "00")- THEN EXIT -------------------------------------------------------------------- "Okay," I explained. "No one does anything at any time on Sunday, so we bail out. If it's Saturday and not midnight, we also exit. If it's Saturday and it is midnight, it's really Friday, so we continue. If it's Monday and it's midnight, it's really Sunday, so we abort, otherwise we keep going." "Fizzbin," the manager cursed. "What about holidays?" Since it's a little-known fact the low-level RF radiation from the CI port of a VAXcluster effectively jams transporter beams, I had little choice but to grab the holiday list from the wall and enter the following data file: ---------------------------------------------------------------------- Figure 4. SYS$MANAGER:HOLIDAY.LIST List all holidays or dates when incremental backups should not be performed. Be certain you use the yyyy-mm-dd format. 1990-07-04 Independence Day 1990-09-03 Labor Day 1990-10-08 Columbus Day 1990-11-22 Thanksgiving Day 1990-11-23 Day after Thanksgiving 1990-12-24 Christmas Eve 1990-12-25 Christmas Day 1990-12-31 New Year's Eve ----------------------------------------------------------------------- Then I hacked out FIZZBIN.COM: ----------------------------------------------------------------------- Figure 5. $! If it's midnight, it's really yesterday, $! so set our day and date accordingly; $! otherwise, use the actual values. $! And thank the Great Bird of the $! Galaxy that lexical functions $! don't use stardates. $ IF F$CVTIME(,,"HOUR") .EQS. "00" $ THEN $ DAY = F$CVTIME("YESTERDAY",,"WEEKDAY") $ DATE = F$CVTIME("YESTERDAY",,"DATE") $ ELSE $ DAY = F$CVTIME(,,"WEEKDAY") $ DATE = F$CVTIME(,,"DATE") $ ENDIF $! Quit if it's the weekend: $ IF - DAY .EQS. "Saturday" - .OR. - DAY .EQS. "Sunday" - THEN EXIT $! $! See if it's a holiday. $! Make certain a failed search $! doesn't bomb us out: $ ON ERROR THEN CONTINUE $! If we find the holiday, then exit: $ SEARCH - SYS$MANAGER:HOLIDAY.LIST "''DATE'" - /NOOUTPUT $ IF $SEVERITY .EQ. 1 THEN EXIT --------------------------------------------------------------------------- "You can call this procedure from within another command file," I explained. "By adding a status value to EXIT, the calling procedure can determine whether it should continue or abort." The system manager became intrigued at the possibilities. "We have about a dozen procedures that could use this, or variations of it. We could specify other holiday lists, and substitute a logical name for the hard-coded file specification." He assumed an imperious attitude and made an enigmatic gesture with his right hand. "Make it so," he proclaimed. I had no intention of redesigning his batch operations with the Trek-A-Thon less than an hour away. Using a trick I picked up from a greenish-looking fellow at the DECUS LUG, I placed my right hand on his shoulder and squeezed firmly. The system manager slumped into his chair, a smile on his face. "Steady as we go," he muttered, as I dove through the door. ---------- 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.