27.04.2013 Views

MVS Jan 2005.p65 - CBT Tape

MVS Jan 2005.p65 - CBT Tape

MVS Jan 2005.p65 - CBT Tape

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

the requirement to ship elements from the test LPARs, where<br />

the development occurs, to the production LPARs, where the<br />

applications actually run. One of the elements that is shipped<br />

is the compile and link-edit listings that are stored by Endevor.<br />

These are shipped so that if there is a production abend the<br />

applications programmer can have the compile listing available<br />

for debugging purposes. The compile listings are stored in a<br />

compressed format, to save space. Endevor provides a utility<br />

to read and expand the listing to human-readable format.<br />

When we decided to make separate sysplexes, however, we<br />

elected to license the use of Endevor only on our test sysplex.<br />

This meant the listings that were shipped over to the production<br />

sysplex would not be usable by the applications programmers<br />

for debugging, because we were not licensed to run the<br />

Endevor utility to expand the compressed listings on our<br />

production sysplex. We decided to examine the listings and<br />

found that we could easily write a utility to expand the listings<br />

back to human-readable format ourselves, without the use of<br />

any Endevor utility. This is the mechanism we decided to use<br />

on the production sysplex.<br />

It turns out that the compression method used by Endevor is<br />

the replacement of repeating character strings with either a 2or<br />

a 3-byte flag string. We found two different types of flag<br />

string. The first was for the replacement of repeating blanks<br />

with a 2-byte field. The first byte was a flag indicator byte<br />

containing X'FD', followed by another 1-byte field that was the<br />

repetition count. The second was for the replacement of<br />

repeating non-blank characters with a 3-byte field. The first<br />

byte was a flag indicator byte containing X'FC', followed by a<br />

1-byte field containing the character that had been compressed,<br />

followed by another 1-byte field containing the repetition<br />

count.<br />

With the above information, a rather simple REXX EXEC was<br />

written to read a compressed listing file stored as a PDS<br />

member, and to expand the flag fields back to their original<br />

format. If the EXEC is called under ISPF, then ISPF browse is<br />

invoked to display the listing, otherwise the user is given the<br />

© 2005. Reproduction prohibited. Please inform Xephon of any infringement.<br />

17

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!