====================================================== -----Original Message----- From: "Paul Gilmartin" <[EMAIL PROTECTED]> Sent: 6/26/2006 5:22 PM To: "[email protected]" <[email protected]> Subject: Re: Program Objects
In a recent note, Rick Fochtman said: > Date: Mon, 26 Jun 2006 17:11:16 -0500 > > I'm looking at the updates I need to keep ARCHIVER up to date and I'm having > problems finding DOC. Most specifically, I'm trying to understand the > differences between "LOAD MODULES" and "PROGRAM OBJECTS" as they are stored > in a > PDS or PDSE. I don't envision updating ARCHIVER to access the "UNIX-like" file > system of z/OS. Can anyone either point me to, or forward me privately, the > necessary DOCs? > I thought program objects in the UNIX FS were very similar to those in PDSE. How close? Can /bin/cp move between the two without exploiting Binder? > as (possible) access to VSAM clusters of the indexed, sequential and relative > I've learned that my compression algorithm can create records longer > than > the original records, so I'm working on a fix for that, as well. > There's no fix for that (think Pigeonhole Principle). You must be prepared to tolerate it. ====================================================== A popular commercial compression tool added extra "control" bytes at the end of the record to indicate that the record was compressed and which compression technique was used. On expansion, the tool looks for the "control" bytes. If not there, then the record is not compressed. The record is only rewritten compressed when the compression shortens the data enough to accommodate the "control" bytes without exceeding the original size. Unfortunately, it's impossible to come up with a configuration of bit patterns for control bytes that won't intersect with possible user data. In this case, the commercial tool happened to use "control" bytes that just happened to look like a floating point number, which an unfortunate customer actually had in their records. The tool misinterpreted the real data as "control" bytes and tried to decompress the record and yielded garbage. Another issue was trying to convince management to rescind their edict that the tool should always compress data. It's not possible to always compress data (i.e., make it shorter than the original). Otherwise, such a compression technique could recompress the compressed data and make it even shorter. The "recursive descent" inductive proof (Fermat) would show that any data could thus be compressed ultimately to zero bits. (This all assumes, of course, that you eventually want to expand the data back to its original bits.) Of course, if you want to compress to zero bits, just delete the file and forget about getting back your data. eek! Jeffrey D. Smith Farsight Systems Corporation 24 BURLINGTON DR LONGMONT, CO 80501 303-774-9381 direct 303-709-8153 cell 303-484-6170 fax ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
