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 October, 1993 The Big Squeeze By Kevin G. Barkes Back in the July issue I mentioned that somebody was looking for beta testers for an OpenVMS/VAX dynamic space compression utility. The other day an unsolicited Airborne Express package arrived from Mark Graybill, the president of Intersecting Concepts, Inc. While the company's name may not be too familiar, its products certainly are. Intersecting Concepts is responsible for Code Blue, an emulation package that allows DEC Rainbows to run programs designed for the IBM PC. Code Blue is a legend in the Rainbow community and saved many of DEC's early PC efforts from premature boat anchor status. The company also developed the patented data compression technology used in Fifth Generation's Fastback Plus PC backup utility, and is now being used in a new product developed for the OpenVMS/VAX market. Mark had spotted my oblique reference to his firm and sent along a review copy of DiskMizer, "Real-Time Disk Doubling Software for VMS". DiskMizer is conceptually similar to the various MS-DOS disk compression software packages now on the market, such as Stacker and DoubleSpace. DM creates a large file on a Files-11 volume in which to store its compressed data. A device driver connects the "host file" to OpenVMS, where it looks and acts like a normal OpenVMS disk volume. The driver automatically compresses and decompresses data written to and read from the host file. The degree of compression depends, of course, on the data being scrunched. The product's "disk doubling" claim is based on a general mix of files. A DiskMizer volume containing mostly pre-compressed .ARC and .ZIP files from my BBS system showed, not unexpectedly, negligible compression. But DM really put the squeeze on another volume I specifically created to hold large data files from my database publishing business. Compression ratios as high as 11-1 weren't uncommon, and the average was an extremely impressive 7.3-1. This is of enormous benefit to me, since I frequently have to keep large database files on my system. I use the LZ compression utilities available from DECUS to reduce my disk space requirements. The problem is I have to decompress the files before I can use them, a process that is often time-consuming and cpu-intensive. DiskMizer permits random block reads and can decompress as little as a single cluster of a file. Plus, there's no danger of running out of disk space like there is usual traditional compression utilities. Installation of the software is trivial, taking just a few minutes to input the license data and run VMSINSTAL. Configuration consists of adding a single line to the system startup file and deciding what to compress and where to put it. When you create a DiskMizer volume, you tell it what percentage of disk space to use initially and the maximum size to which it can grow. DiskMizer will dynamically increase the size of its host file as needed. The package includes several utilities, including one which allows the transfer of files into a DiskMizer volume and the automatic deletion of the original uncompressed file. It's similar to BACKUP/DELETE, except that BACKUP waits until the entire operation is completed before performing its deletion pass. The DiskMizer utility kills the uncompressed version of a file immediately after it's been successfully copied. I created three separate DiskMizer volumes on my new 1.6 gig hard drive. One contains the aforementioned database files, another the temporary directories where Usenet news is handled, and a third to contain PostScript output files. The new setup gives me the equivalent of about 4 gigabytes of additional space. CPU overhead, while not negligible, isn't oppressive. I wouldn't want to run DiskMizer on a 750, but it does fine on a VAXstation 3100. Editing 20,000 block database files with TPU isn't an instantaneous process anyway. The $395 price for a workstation license is a lot cheaper than buying another large disk drive, and I don't have to pay hardware maintenance charges. Looks like I'll be adding DiskMizer to GreyMatter's Scriptserver and Channel Island Software's DCL to Fortran Precompiler as essential tools for the ol' VAXstation. While we're talking about compression, Dietrich O. Banschbach of SAS Institute GmbH in Heidelberg, Germany emailed me to say DEC sells something called FLAM for OpenVMS V.2.6., a compression product it licenses from another firm in Friedrichsdorf, Germany. Since it's only sold in Germany, it's not of much use to those of us here in the States, but thanks for the info, Dietrich. THE SAGA BEGINS. DEC's monthly maintenance charges for my ancient VAXstation 3100 Model 30 have reached the point where it's time to look at leasing a 4000 Model 60. I know, why not get an AXP, right? What can I say? I like VAXes. I like OpenVMS/VAX. OpenVMS/VAX has been bery bery good to me. All the software I use is on OpenVMS/VAX. Case closed. My main problem is dealing with the psychological trauma that accompanies the thought of dealing with DEC. The last time we did business, I ordered an ethernet card and a cable from DECdirect and told them to ship it via UPS ground. It showed up the next day via UPS Red. DEC didn't charge me for the expedited shipping, but I didn't discover that until two weeks later, when a company in New York returned the invoice which DEC mistakenly sent to them instead of to me. Two months before that I had called DECdirect to see about leasing a DECpc. A nice lady on the phone faxed me a quote, I faxed her back a purchase order, she called to say the order was passed on to the leasing department, and I never heard from her again. I called about a month later (the PC acquisition wasn't urgent) and the salescritter was on vacation. I got bounced around to several nice, apologetic people who offered to re-take my order. This time I needed the PC quickly (DEC was quoting a 17 business day backorder), so I opted for a bare-bones 486 50Mhz no-name machine from Infotel Distributors in Ohio, the place where I buy all of my PC-based bits and pieces. (Nice outfit. Ask for Audrey if you call.) Last summer, if you recall, I needed a 9-track tape drive. DEC listed the drive as a FastShip item. The power cord, however, was on backorder. I leased a Cipher clone and saved big bucks. Anyway, because getting a VAXstation 4000 involves trading in my 3100, updating and realigning my service and hardware contracts and arranging a DEClease, I have to (shudder) go through my local sales department. DEC's field service department in Pittsburgh is without peer, even though they've lost a lot of good people in the downsizing purge. My experiences with their sales department is another story. Ask me someday to tell you about the DEC vp who horned in on a package begin put together by me and a DEC distributor, pissed off the customer and lost us about 600K in sales. But I digress. I'm hoping the whole thing goes smoothly, that the DEClease people don't learn of my Star Trek memorabilia habit and the fact I'll soon be paying car insurance for two teenage drivers. If so, I'll sing DEC's praises here next month. Otherwise, if DEC's sales department acts consistently with my past experiences with them... well, I've always had a secret desire to write horror stories. Stay tuned. This should be fun. I figure either way I can't lose. If DEC comes through, next month I'll be writing this on my new VAXstation. If not, I'll have lots of stuff to write about. INTERESTING NOTES from readers this month. Simon Maufe, who works at DEC's Customer Support Center in Colorado Spring, sent along several files to monitor system quotas. Unfortunately, they were a bit too large to include here. A hint to readers: if you want to get your code published, make certain it's tight, well-written and no more than 50 lines or so. An anonymous message came over the Internet about incremental backups. (My reply bounced, and the notewriter didn't enter his real name or address within the message). He suggested that a great timesaver is not to use the /RECORD qualifer on incremental backups. That way, every file created or modified since the last image backup could be saved to a single tape which could be rewritten every day, instead of using separate tapes for each daily incremental. While this may be ok under certain circumstances, I can think of several situations where it wouldn't be desirable. For example, the program that I was fiddling with all week that worked fine Wednesday broke after I modified it on Thursday, but I didn't discover that until Friday. Unfortunately, on Thursday I purged the directory. With separate incremental backup tapes, I could go to the Wednesday or Thursday tape to recover the working program. Using the /NORECORD single tape method, I'm SOL (simply out of luck), since the prior versions of the file are gone and all I have left is the latest version. Someone on the VAX Forum on CompuServe claimed they successfully installed OpenVMS AXP V1.5 on the Jensen PC. The ROM level should be 14b and the PAL level x5.41. It appears AXP doesn't know how to deal with the graphics display; the workaround is to use a character cell terminal as the console device, using a DECconnect to 9-pin plug to connect to the socket below the keyboard connector. You have to remove the keyboard's DIN plug as well. Of course, this is highly irregular, totally unsupported and an affront to all right-thinking DECcies. Have fun. I still think we should change the name of the VAXFORUM to the VMSFORUM. OPENVMSFORUM is too many letters. LINER NOTE of the month, from Rhino Records' Super Hits of the 70s, Volume 3: "The Buoys reached the Top 20 in May (1971) with `Timothy', the biggest hit ever written about cannibalism--okay, the only hit ever written about cannibalism." Granted, this has nothing to do with computers, but some of you out there need to broaden your horizons. ******************** Kevin G. Barkes is an independent consultant whose daughter recently acquired contact lenses and a new boyfriend. She also turns 16 this month and starts driver's ed real soon. When not hunched in a fetal position under his desk, Kevin lurks on comp.os.vms and can be reached at kgbarkes@gmail.com.