AUTOMON®/VTAM - OS390

Enterprise-Wide VTAM Level Compression Utility

  • OVERVIEW
    OVERVIEW
    OVERVIEW
    OVERVIEW
    OVERVIEW
    OVERVIEW
  • AT-A-GLANCE
    AT-A-GLANCE
    AT-A-GLANCE
    AT-A-GLANCE
    AT-A-GLANCE
    AT-A-GLANCE
  • FEATURES
    FEATURES
    FEATURES
    FEATURES
    FEATURES
    FEATURES
  • RESOURCES
    RESOURCES
    RESOURCES
    RESOURCES
    RESOURCES
    RESOURCES
  • REQUIREMENTS
    REQUIREMENTS
    REQUIREMENTS
    REQUIREMENTS
    REQUIREMENTS
    REQUIREMENTS

OVERVIEW

AUTOMON/VTAM is a terminal datastream compression product which runs at the VTAM level. Its function is to eliminate, as much as possible, superfluous characters in datastreams that are transmitted to and from the host CPU and the terminals. Since the number of characters in a datastream is the major factor in determining the response time for an on-line transaction, the elimination of extra characters can significantly reduce that time. Most users experience a 55 to 80% reduction in terminal traffic with AUTOMON/VTAM, which results in dramatic savings both in time and cost of the computer installation usage.

With AUTOMON/VTAM you can have datastream compression for any VTAM application. CICS, IMS, TSO, any application system which communicates with terminals using VTAM can benefit. It does not require its own region or partition to operate. AUTOMON/VTAM will increase efficiency of mission critical domains such as CICS, IMS/DC, TSO, ROSCOE, IDMS/DC, Printers, Terminals, PCs, third party hardware and applications.

Today's network system programmer, for the most part, only has control over the first of these variables, overall system tuning. He can distribute the load over the available resources to maximize efficiency, and adjust the various application controls to eliminate bottlenecks. He can do very little in most conditions, to control application program efficiency or data transmission amounts, since much of today's application software is made up of vendor-written packages.

Terminal data streams produced by most of today's application software is severely inefficient. This simply means that much more data is transmitted on every transaction than is necessary. There are three major reasons for this:

  • In the local environment, the amount of data transmitted is not quite the noticeable factor that it is in the remote environment, since the transmission rate is considerably higher for local terminals than it is for remotes. For remote terminals running at 4800 or 9600 BAUD, it is often the single most important factor.
  • In today's large-system, multi-terminal networks, the single most critical factor of day-to-day operation has become terminal response time. Excessive response time is responsible for many of the problems in company operations. It is often the major factor behind project overruns, worker frustration and apathy, and careless errors.
  • Excessive terminal response time inevitably becomes the most obvious focus of user complaints in large systems and multi-terminal networks. System Network Architecture (SNA) networks consist of a complex series of data streams in CICS/TS, VTAM, in the Network Control Program (NCP) and z/OS that determine terminal response time. These data streams determine the time required to send a message from an application to a terminal screen and for the user input to reach its application destination. The three fundamental variables influencing terminal response time are overall system tuning, individual application program efficiency and the quantity of data transmitted. Network system programmers, for the most part, have control over only the first of these variables. Application program inefficiencies are largely due to sub-optimal mapping and outbound programming techniques.

AT-A-GLANCE

  • Repetitive Character Elimination
  • Transmission of Only the Changed Data
  • Inbound Mirroring
  • Exclusion List
  • Selection List
  • Threshold Table
  • User Exit handler and a TSO Command Driver.

FEATURES

The average outbound terminal data stream contains from 20 to 25 percent repetitive characters; elimination of: Strings, spaces, nulls, asterisks, dashes, etc. are common in almost all output displays.

Most application programs and map generators handle a string of repetitive characters as a single field, which may or may not be preceded by a START-BUFFER-ADDRESS (SBA) sequence.

Thus, a row of 30 asterisks starting somewhere on the screen would appear in hexadecimal form as:

5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C

for a total field length of 30 bytes.

This same field of 30 asterisks can be sent to the terminal and displayed properly in only four bytes by taking advantage of the buffer display logic that is present in all 3270-mode devices. To do this, we can use the REPEAT-TO-ADDRESS (RA) sequence instead of the SBA sequence. With an RA sequence use of, you tell the device what character you want to repeat, and the ending buffer address of the field. Thus, the following sequence would display exactly the same on the terminal, but only needs to transmit four bytes:

3C xx xx 5C (The xx xx is the buffer address of the end of the stream).

AUTOMON/VTAM examines the outgoing data streams and looks for fields of repetitive characters: elimination of that excess four bytes. When one is found, the ending address of the field is calculated and an RA sequence is inserted into the data stream. The extra characters in the original field are no longer needed and are discarded.

Outbound image saving

It is very often the case in day-to-day terminal operation that an operator will use the same transaction continuously over a period of time. This usually involves the same basic display with only the data fields changing from one display to the next. That is, the screen titles and text fields remain the same.

Terminal data streams; outbound programming provides a technique to minimize data transmission by using a terminal write of data only for all but the first display. In other words, the first time a particular display is sent to the terminal, the ERASE command is included to clear the screen, then all of the data, titles, text and data fields are sent. For the next display, the ERASE command is not sent and only the data fields are output. As long as the operator continues to use the same display, there is no need to continue to clear the screen and re-send all of the data with every output transmission.

The problem with this technique is that it requires more sophisticated programming effort. The application program needs to know that the display in question is the same display (except for the data fields) that was sent last time. This can involve quite a bit more program logic, and most application programs just don't go to that much trouble. It's far easier to erase and re-send all data.

AUTOMON/VTAM imposes this programming technique on all output data streams; outbound without placing the burden on the application programs.

An image in outbound compression of each terminal buffer is maintained in memory. This image is always an exact replica of what is displayed on the terminal at any given time. Now, when an output data stream is sent to the terminal, AUTOMON/VTAM compares the outgoing image with the image of the buffer.

If it determines that the outgoing data stream is an entirely different screen display, the repetitive characters-elimination of elimination logic is performed on this data stream, then it is sent to the terminal, leaving the ERASE command undisturbed.

If, however, the outgoing data stream contains many of the same title and text fields as currently in the image of the terminal buffer, AUTOMON/VTAM will remove the ERASE command, making it a data-only write, and also remove all fields in the outgoing data stream that are already present on the terminal screen. Even the data fields are examined, and removed if the same data is being sent again.

The result is a tremendous reduction, system-wide, in the amount of data that is transmitted to the terminals.

Inbound image saving

On the input side, that is, the data being transmitted from the terminal to the host system, there is nothing that can be done to reduce the amount of data that is keyed by the operator. There is, however, something that can be done to reduce the total amount of data transmitted from the terminal in many cases.

When an operator enters data into any field on the screen, the logic contained in the terminal causes a flag to be turned on in the attribute byte of that field, indicating that the field was modified. This flag is called the modified-data-tag:use of, or MDT.

The MDT can also be turned on by an application program when the data stream is transmitted to the terminal. If this is done, the field will be transmitted back from the terminal, whether the operator enters anything in that field or not. It is a very common programming technique, to turn on the MDT for many (in some cases all) of the fields prior to sending the data stream to the terminal. This eliminates the necessity in the application program of determining which fields the operator modified.

AUTOMON/VTAM can reduce the amount of data transmitted from the terminal by turning off all modified-data-tag:removal ofs as the data streams:inbound is going out to the terminal. Now, only the data that is actually modified by the operator is transmitted back in.

Since AUTOMON/VTAM keeps an image:in inbound compression in memory of the current state of the terminal screen, it knows which fields had MDT on, and therefore would normally have been re-transmitted. If these fields do not come back in, they are inserted into the data stream prior to sending it on to the application system. Thus, when the application program receives the input data, it looks just as it would normally appear. The application program never knows the difference, but the actual amount of data transmitted is significantly reduced.

RESOURCES

REQUIREMENTS

  • Mainframe
    IBM z/Architecture and compatible
  • Operating System
    MVS/ESA
    OS/390 2.10 or later
    z/OS 1.8 or later 
  • Host System
    CICS Transaction Server 3.2 or later
Are you looking for AUTOMON®/VTAM for a different operating system?

AUTOMON®/VTAM - VSE