Entire Net-Work provides a message compression capability that can be selected or deselected for each link using the COMPRMSG parameter on the LINK statement. If COMPRMSG=YES is specified, outgoing messages over that link are compressed. Incoming compressed messages are always decompressed, regardless of the parameter setting. If a compressed message passes through a relay node en route to its destination, it is not decompressed until it reaches the target node.

Compression is accomplished "in place", but decompression requires a second buffer as an output area. This fact should be considered when estimating storage requirements. An output area is needed even without compression if blocking is in effect.

Compression consists of replacing sequences of identical characters with a record describing how many characters are deleted and where to reinsert them upon decompression.

The compression algorithm can be tuned beyond the simple yes/no decision afforded by the COMPRMSG parameter by using the MINCMP parameter or a translation table. The objective is to trigger compression where it is expected to be effective and to skip cases where the cost outweighs the benefits.

This document covers the following topics:

• Using the MINCMP Parameter

• Using a Translation Table

---

Using the MINCMP Parameter

The MINCMP parameter can be used to specify the shortest sequence of identical characters to be compressed. The nature of the algorithm is such that at least six characters must be found before anything is gained. Therefore, MINCMP defaults to 6. If a value less than 6 is specified, it is automatically reset to 6.

Values greater than 6 can be specified with the effect that compression takes place only where substantial savings can be expected. This results in less CPU overhead than full compression at the cost of a slight reduction in the overall compression factor.

A value for MINCMP should be selected based on typical message contents with the objective of reducing the number of decompressions needed, thereby reducing both storage and CPU requirements.

The following example describes three applications with various compression requirements, and provides a method for using the MINCMP parameter to effectively handle compression for all three applications.

Application	Characteristics
A	has record buffers defined that contain many relatively long alpha fields, some of which tend to be all blanks.
B	uses special characters such as dashes in its screen maps to form boxes or to prefill input fields.
C	processes bit maps. Bit maps contain many fixed-length binary fields that usually have rather diverse values. Occasionally, a few consecutive bytes may have the same value.

In applications A and B, compression is likely to produce a reasonable reduction in the amount of data transmitted.

In application C, the occasional sequences can be compressed away, but the message length will not be reduced by much. The expected savings is probably not worth the CPU cycles spent for compression and decompression, plus the extra storage needed for the output buffer required for decompression.

If these applications all run through the same link on the network, the MINCMP specification for the link can be used to tune compression. The value specified for MINCMP will be

• not larger than most of the sequences of blanks in application A; and

• not larger than the sequences of special characters in application B; but

• larger than most of the "accidental" sequences in application C.

The sequences in applications A and B are then compressed with good results, and no time is wasted finding the occasional sequences in application C.

Using a Translation Table

A CSECT named NETTRT is linked into the NETWRK control module. This CSECT is exactly 256 bytes long and contains a translation table used by a Translate-And-Test (TRT) instruction in the compression algorithm. The TRT and the table in NETTRT are used to find characters in the message that are likely candidates for compression. Only the characters translating into a non-zero function value are considered for compression. The assumption behind this algorithm is that certain characters, such as a blank or a binary zero, are more likely to occur in sequences than others, such as the lower case letter "k". The compression process is faster if "unlikely" characters are not considered for compression.

The translation table provided by Software AG is a reasonable starting point for most situations, but users can and should modify or replace NETTRT with their own version if their data streams differ from the usual pattern. If, for instance, your company logo appears on a map built from many occurrences of the character "O", you should probably change NETTRT to contain a non-zero value in the position related to "O". The following is AMASPZAP input for z/OS systems to change NETTRT so that "O" will be considered for compression:

NAME NETWRK NETTRT
VER  D6 00             X'D6' = C'O'
REP  D6 FF