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 Clear As Mud Originally published July, 1995 By Kevin G. Barkes In a press release loaded with glowing buzzwords and pr hype, Digital and Microsoft announced a program "integrating OpenVMS with Microsoft's Windows NT". To give you an idea how well the announcement was interpreted, every trade rag had a different take on it. Computerworld, the same brilliantly insightful publication that announced Pathworks' supposed demise last year, said the program was "a migration path designed to slowly pass the torch from OpenVMS to Microsoft Corp.'s Windows NT". Yeah, that's sure something for Digital to brag about, huh? This column was written shortly after the official May 8 announcement at the DECUS Spring Symposium in Washington, DC, so there's been little chance for analysis and clarification by Digital and Microsoft. Some see the announcement as Microsoft's confession that NT doesn't have what it takes to handle really immense server configurations. Others feel Digital has decided VMS' future lies mainly as a superset of NT performing back-end server functions, using its soon-to-be-introduced 64-bit log-structured file system. The OpenVMS/NT combo is a "three-tier software application architecture", the release explains. The third tier is where data, mission-critical applications and services are managed, with OpenVMS systems operating as servers. The "application or functional logic tier, which governs the rules by which the business applications operate" can run on either NT or OpenVMS. "The presentation tier, or deskop, is dominated by personal computers" running Windows. Thus, Digital seems to be officially ceding the desktop to Microsoft. Digital and Microsoft envision users standardizing on Windows at the desktop, where the presentation logic will reside. Application logic, written in "portable code" will run on either NT or OpenVMS, the latter being facilitated by Digital's scheduled porting of the Win32 APIs and other tools to OpenVMS. What's going to happen, long-range? Maybe people will see how stable and robust the OpenVMS servers are and ditch the NT front end. The "teats on a bull" analogy comes to mind. Or maybe Microsoft will come up with its own 64-bit log-structured file system a couple years down the road when NT finally matures. Then Bill will give Digital the old heave-ho, in a move reminiscent of the IBM-Microsoft-OS/2-Windows melodrama. On the plus side, the arrangement "validates" OpenVMS, albeit in a rather perverse sort of way, and insures that it will be around for a while. Digital's decision is arguably a shrewd business move. It's just that I feel so... so... used. **************** Phil Katz Saved My Butt, But... I probably wouldn't be in business today if it weren't for Phil Katz, the founder and president of PKWARE, Inc. and the inventor of the .zip compression/file packaging utility. Back in the mid-80s, a power spike trashed my PC's hard drive while it was updating a floppy-based archive file containing all of my business financial records. The overwritten file, my only backup, was corrupted. The hard drive had been reduced to a whirring mass of iron oxide particles. I was doomed. I called PKWARE and Phil himself answered the phone. He told me to make a diskcopy and send it to him. I did so, via Federal Express, along with a check for $100. Phil hadn't asked for any money, but I figured it couldn't hurt. Two days later, the Fedex guy rang the doorbell. I grabbed the envelope from him, dashed to my office, stuck the floppy in my replacement machine and saw, much to my relief, that my financial files were intact. Another look inside the envelope revealed a registered version of the software and a note from Phil admonishing me to be more careful in the future. Since then, I've been a big PK booster. I have multiple registered copies of PKZIP on my MS-DOS machines, and I urge all my clients to register any copies of PKZIP I find on their computers. I truly admire Phil Katz. If every copy of PKZIP currently in use was registered, he could probably buy out Bill Gates' share of Microsoft. Instead, he still allows shareware distribution of his software, which can be found on just about every MS-DOS computer in the world. He dedicated the .ZIP filename extension, file format and compression format (but not PK's actual software) to the public domain, so others can write programs compatible with PKZIP. He even accepted minor changes in the .zip file format so third parties could more easily write ZIP flavors for other platforms. This policy has resulted in ZIP being ported to Unix, VMS, Windows NT, Minix, Atari and Macintosh. The most widely-used VMS version of ZIP was written by members of the Info-Zip group, specifically Mark Adler, Richard B. Wales, Jeanloup Gailly, Kai Uwe Rommel, Igor Mandrichenko and John Bush. Their most recent releases do a pretty decent job of supporting VMS file types. Still, I was hoping PKWARE would release its own VMS version of PKZIP. The good news is they have. The bad news is Info-Zip's freeware version (ZIP) is better. Part of the problem is that zip files are only expected to work with stream-LF files. PKZIP does support some VMS file formats, but not all; ZIP supports more, and generally runs faster with slightly better compression. PKZIP and ZIP both handle text files, executable images and backup savesets okay, for the most part. But look what happens with an indexed file, like sysuaf.dat. $ copy sys$system:sysuaf.dat ziptest.dat $ copy sys$system:sysuaf.dat pkziptest.dat $ zip "-V" -m ziptest ziptest.dat adding: ziptest.dat (deflated 72%) (The "-V" saves VMS file attributes; the -m deletes the original file after moving it into the archive.) Now, let's decompress it: $ unzip ziptest Archive: USER2:[BARKES.PROPRESS.DCL95]ZIPTEST.ZIP;1 inflating: ziptest.dat And now let's test it: $ analyze/rms ziptest.dat . . . The analysis uncovered NO errors. Just to be certain, let's compare it to the original file: $ diff ziptest.dat sys$system:sysuaf.dat Number of difference sections found: 0 Number of difference records found: 0 DIFFERENCES /IGNORE=()/MERGED=1- USER2:[BARKES.PROPRESS.DCL95]ZIPTEST.DAT;1- SYS$COMMON:[SYSEXE]SYSUAF.DAT;1 Now, let's try PKZIP: $ copy sys$system:sysuaf.dat pkziptest.dat $ pkzip/move/attrib pkziptest pkziptest.dat PKZIP for VMS FAST! Compression Utility Version 2.01 2-Jun-1994 Copyright 1989-1994 PKWARE Inc. All Rights Reserved. PKZIP Reg. U.S. Pat. and Tm. Off. Patent No. 5,051,745 %PKZIP-I-CREATE, creating file USER2:[BARKES.PROPRESS.DCL95]PKZIPTEST.ZIP; %PKZIP-I-ADD, deflating file PKZIPTEST.DAT (92%) Let's extract the file: $ pkzip/extract pkziptest PKZIP for VMS FAST! Compression Utility Version 2.01 2-Jun-1994 Copyright 1989-1994 PKWARE Inc. All Rights Reserved. PKZIP Reg. U.S. Pat. and Tm. Off. Patent No. 5,051,745 %PKZIP-I-SEARCH, searching file USER2:[BARKES.PROPRESS.DCL95]PKZIPTEST.ZIP;1 %PKZIP-I-EXTRACT, inflating file PKZIPTEST.DAT And let's test it: $ an/rms pkziptest.dat . . . *** VBN 1: Prolog block checksum is invalid. *** VBN 2: Prolog block checksum is invalid. *** VBN 3: Prolog block checksum is invalid. . . . Unrecoverable error encountered in structure of file. The analysis uncovered 23 errors. Sigh. ZIP also supports VMS file versions, although it requires the use of another command line switch. PKZIP apparently does not. And both ZIP and PKZIP mysteriously added carriage returns to the end of records on a text file that was zipped to a VMS disk by a Pathworks-connected PC. The carriage returns disappeared when the file was extracted by MS-DOS PKZIP over the network. If you need to transfer compressed text files across platforms, ZIP and PKZIP will fill the bill ok. For that matter, Rahul Dhesi's ZOO program, probably the first cross-platform file compression/archiver, will also work fine. And Rahul's BILF utility program is quite useful for converting munged files back to their proper characteristics. What do I recommend? I use MS-DOS PKZIP a lot, mainly for backing up my PCs to the VAXstation via Pathworks. I use ZIP and UNZIP for decompressing VMS files people send me. Unfortunately, there are a number of versions of the ZIP programs out there, and compatibility is sometimes a problem. Both have comparable compression ratios. ZOO, which doesn't compress as well, is rather stable and I use it daily for text file transfers to customers. If I need to compress VMS files for transfer to another VMS system, I use the LZCOMP and LZDCMP programs available from DECUS; they're the only ones I've found that maintain all VMS file attributes. Actually, I find myself sending VMS files to other VMS systems by copying them into a BACKUP saveset and transferring the saveset using C-Kermit's built-in on-the-fly compression. C-Kermit's compression ratio is on the low side, but it eliminates the need for compression/decompression programs and the time involved in running them. The latest version of C-Kermit supports virually all VMS file formats (using the LABELED file type), so formatting is no longer an issue. How do I archive files on my VMS system? I just back them up to a saveset on one of the drives that uses Intersecting Concepts' DiskMizer dynamic disk compression softwre. The compression is decent and automatic. As for PKZIP... I'm sure Phil Katz will get the VMS flavor up to speed shortly. He's never let me down before. ******************* Kevin G. Barkes is an independent consultant whose Internet tagline of the month is "I am Pentium of Borg. Division is futile. You will be approximated." Kevin lurks on comp.os.vms and can be reached at kgbarkes@gmail.com.