Copyright 1992-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 November, 1992 BACKUP Ramblings By Kevin G. Barkes BACKUP is one of VMS' most powerful and essential utilities. Yet it remains greatly misunderstood by many users. This situation is exacerbated by all the VAXstations and small VAX systems in the field. In these situations, responsibility for BACKUP operations is in the hands of relatively inexperienced users. One of the problems is that to fully understand how BACKUP should be used, you need access to the VMS BACKUP Utility Manual, which few system managers consider to be user documentation. I've received a number of requests for an article on BACKUP pitfalls and suggestions for small system and VAXstation users. Herewith are some tips learned through bitter experience. Bear in mind these recommendations are extremely conservative; BACKUP gurus may use various qualfiers and tweaks to speed up or alter the utility's performance. My advice: don't mess around. Saving a few minutes a day on a BACKUP procedure which results in munged data is, frankly, stupid. Use The Defaults. The performance and speed of BACKUP can be enhanced by modifying various command parameters, such as /CRC, /GROUP, /BLOCK and several others. My advice to neophytes: DON'T. Small VAX systems and workstations often have bizarre peripheral configurations and third-party hardware which may behave unpredictably. Don't modify BACKUP's default behavior. I've never seen a BACKUP restore fail when the saveset was created using the defaults. In fact, I successfully restored a disk from a BACKUP tape which had a tear almost completely across the media surface. Purge AFTER Backup. A lot of people purge their disks prior to backing them up in order to save tape and reduce backup time. Bad move. Better than even money says that one prior version of a critical file you need was wiped out by PURGE before the last backup. Multi-Media Is Good. Whenever possible, you should backup to multiple media formats. I have an "extra" drive on my system with a fairly decent amount of space. Whenever I do an incremental backup to tape, I also do a backup to a disk saveset. And if I need to restore something, copying from the disk saveset is a lot faster. Remember to add the /SAVESET qualifier when the specified target device is a disk. Watch Out For TK Drives. If you "stack" incremental backups on one tape (that is, record one saveset after another sequentially to the tape), you could be living dangerously. One of the design "features" of TK drives is their inability to read past a hard error on the tape. If you hit a non-recoverable error on a TK tape, everything past that point will be unreadable. It's also been my experience that TK drives are more susceptible to positioning errors and other problems that cause BACKUP to fail. If you're running BACKUP from a batch command procedure, make sure you have the proper error-handling DCL code in place. Use /VERIFY. Some may complain about the time involved, but /VERIFY is the best way to be absolutely certain you have a good backup. It's also a good way to test the reliability of your disks and tapes. It recently saved my tuchas when the SCSI controller on my VAXstation went schizoid and started mangling files. The aberrant controller generated no errors while it cheerfully trashed every file I edited. BACKUP/VERIFY caught it. Backup Everything. If you can fit all the files on a disk on one tape, and if there are a lot of frequent modifications to the files, it may make more sense to do an image backup rather than an incremental. When you tell backup /SINCE=BACKUP, it has to look at all the file headers on the disk to find which have been modified since the last backup. An /IMAGE backup grabs everything without the time-consuming date scan. I've seen instances where an /IMAGE backup of an entire disk was actually faster than an incremental. Plus, you have the advantage of a one-tape restore to disk; no application of incremental savesets. You can also /SELECT files from an image backup saveset the same way you can from a "normal" saveset. Frequency. You should back up daily; more if you're working on critical data that changes frequently. I used to back up every eight hours, and felt rather smug about it. That is, until the SCSI controller on my VAXstation went belly-up and trashed my main work disk seven hours after the last backup. ************************** Some Coincidence Just as I was completing this column, the C: drive on my XT-based SYS$OUTPUT BBS died a horrible death. Of course, the latest backup I have is a week old. Sigh. I really can't complain. SYS$OUTPUT has been in constant operation since 1986 using a pair of old Seagate ST-238 30MB RLL drives. That's a MTBF of over 52,000 hours, which isn't too shabby. I'm replacing the dead unit with a 212MB Conner IDE drive, which can work in the old XT with a special disk controller board. Why not just upgrade the BBS to a 386, now that the more powerful machines are dirt cheap? Frankly, I don't need the power, and I don't want to spend the cash for another machine. BBSes are not really CPU intensive applications, and I expect a big performance boost from the Conner I'm installing. The old 238s had a seek time of 65ms; the Conner clocks in at 16ms. That should significantly speed up BBS housekeeping operations, and reduce the timeout errors for folks downloading at high baud rates. Plus, the 212MB Conner is our standard drive, used in all the machines in my house and office. When one dies, I can swap in a disk from another computer until I can permanently replace it. And when the XT itself finally gives up the ghost, I have this old Sanyo XT motherboard out in the garage somewhere... ******************* DEASSIGN Bug. While wandering through DSNlink, I noticed a posting regarding the DEASSIGN command. If you define a logical name terminated with a colon (e.g., DKA100:), you can't DEASSIGN it. DEC's workaround: specify two colons (DEASSIGN DKA100::) ****************** More On Compiled DCL Frank Noell, Vice President of Channel Island Software, is one happy guy, and so will be the lucky folks who get Version 2.0 of his DCL to Fortran Precompiler (DFP). The new release adds a lot of functionality to the product, and includes a major new feature: support of runtime interpretive functions in compiled code, such as runtime generated symbols. The ability to handle interpretive DCL operations in an .EXE is a major accomplishment, and should make DFP a "must have" for sites who need fast, secure DCL code. Version 1 of the product was reviewed in the September 1991 column. The precompiler reads in DCL command procedure files and outputs VAX/VMS FORTRAN source code, which is then compiled and linked to generate an executable image (.EXE) file. You need DEC's FORTRAN compiler to use the Precompiler, but you don't need to know FORTRAN programming. While I haven't personally seen Version 2 yet, Frank's an upstanding fella, so I'll violate my rule about endorsing untested products just this one time. I hope to do a more complete review at a later date. *************************** Kevin G. Barkes is an independent consultant who seems to spend most of his time installing disk drives and restoring volumes from backup tapes. Kevin lurks on comp.os.vms and can be reached at kgbarkes@gmail.com.