IntercommThe Intercomm teleprocessing monitor is a robust software system which supplies those services required in a comprehensive on-line transaction processing environment. These services are efficiently provided to maximize throughput and minimize response time. Hundreds of users have utilized Intercomm, each over many years of production. Such extensive use guarantees the highest level of code integrity within the Intercomm-provided software and ensures that these services have been rigorously field tested.
Intercomm's features include:
· Communications Functions for Devices and Line Control
Provided through VTAM (utilizing SNA, TCP/IP, and/or LU6.2 communication) for physical device management, and through other Intercomm Front End components, for logical network management.
· Full Resource Management
Main storage, files, CPU cycles
· Job Management
Scheduling, loading
· Task (Program) Management
Queuing, concurrent processing, swapping, multithreading
· System Control
Security, message and file restart/recovery, logging (journaling)
· Application Program Services
Message formatting/editing, scratch pad and table storage management, data storage and retrieval, conversational control
· Preprogrammed Applications
Message switching/broadcasting, record retrieval, system, application, and network processing control and dynamic status display
The Intercomm design philosophy has resulted in a system which meets the following needs:
· High Programmer Productivity
Intercomm includes a wealth of preprogrammed functions which are table-driven, not requiring coding, testing and debugging by the application programmer. An Intercomm program is written as much like a batch program in the programmer's native language (Assembler, COBOL, or PL/1) as possible in an on-line environment. The programmer is shielded from the communications devices by either the Edit/Output Utilities or Message Mapping Utilities. The created program is device-independent. It deals with fixed-format, fixed-field messages (both input and output). It calls the Intercomm Monitor for preprogrammed services. The programmer can concentrate on the logic of the application rather than the bits and bytes of the teleprocessing environment.
· Low System Overhead
Intercomm makes low system overhead possible in both CPU cycles and main storage utilization. This is particularly significant in the area of data management. File I/O is centralized in Intercomm’s generalized File Handler, which allows for true dynamic buffering, a single DCB or ACB for each file, exclusive control at a physical record level, and dynamic file allocation. A file can thus be opened once per day without high overhead. VSAM file processing can be optimized through the use of Local Shared Resources (LSR) pools in storage above the 16M line. Another area where low system overhead is highly significant is that of obtaining and freeing areas of main storage on an as-required basis. Intercomm's Resource Management facilities contain an option for predefined storage pools (areas of user-specified size and number) in 24-Amode, and optionally, 31-Amode storage. Intercomm services storage requests from these pools, utilizing a best-fit technique. This prevents storage fragmentation and reduces CPU utilization by bypassing GETMAIN/FREEMAIN overhead. Via tuning, the user can reduce the pool sizes to the lowest possible storage requirements consistent with the desired level of performance.
· High System Throughput
Intercomm is a system without any built-in roadblocks. Given a high enough priority message volume on a standalone computer, Intercomm will use 100 percent of the available CPU cycles on a machine while continuing to process messages. High system throughput is obtained by efficient message processing management within the Intercomm job. This job management capability is primarily implemented through the Subsystem Controller, which controls the scheduling of applications within an Intercomm address space. Scheduling is based on resource availability and demands, and an algorithmic combination of the priority of the input terminal, the message, and the application program. The Subsystem Controller, in conjunction with the Dispatcher (Task Manager) and other components, totally controls the sequence of execution of all messages such that maximum processing overlap occurs (through concurrent processing and multitasking) whenever possible.
· High System Integrity
Intercomm will detect application program loops (CPU and non-CPU bound), intercept application program-checks and ABENDs (ESPIE and ESTAE protection), and handle terminal and file I/0 error situations. In the rare event of system failure, it provides for message and file restart/recovery. In addition, the Multiregion version of Intercomm (MRS) allows for separation of application systems (groups of application programs) into their own independent address spaces within an LPAR, thus providing the highest possible level of system integrity. Intercomm also provides an Extensive (dynamically-controlled) Security System (ESS) under supervision of a proprietary SVC.
· The Intercomm Environment and Facilities
Intercomm is IBM operating system-independent and functions under OS/390 and z/OS. It executes as a single job (or multiple independent jobs with the Multiregion Support Facility), normally concurrent with the user's regular workload in other regions. Within its region, Intercomm may be thought of as an operating system within the operating system. The computer's operating system was designed to efficiently handle a batch workload consisting of multiple programs performing iterative functions over a relatively long time period. Intercomm was designed to supervise an on-line workload consisting of multiple programs performing multiple processing functions once per input message. The batch program reads and processes a series (batch) of sequenced transactions from a single input source. An on-line program receives a message (transaction) from a communications device, processes the message, transmits one or more responses (output), and then is idle until another transaction is entered. If a user had only one program, which processed messages from one terminal, this situation might be acceptable. However, the usual situation is that the user has more than one terminal and more than one application program. With multiple terminals submitting multiple messages to multiple application programs, a control program is necessary; hence Intercomm.
The five main Intercomm components that perform this control over the on-line environment are as follows:
· Teleprocessing Interface (Network Management)
Controls communication between the region and all teleprocessing systems and terminals connected to that Intercomm.
· Message Collection/Retriever (Queue Management)
Controls queuing and dequeuing of queues of messages awaiting input processing and/or output transmission.
· Subsystem Controller (Job Management)
Schedules and manages the sequence of initiating application subsystems (message processing programs) within Intercomm.
· File Handler (Data Management)
Manages all file I/O activities in a centralized manner, and also supports commonly used data bases.
· Dispatcher (Execution Management)
Manages the allocation and overlap of CPU time among multiple program tasks executing concurrently, and establishes multiple real time clocks.
Intercomm's efficiency is achieved by processing parallel messages under the control of the Subsystem Controller (message processing scheduler), the Dispatcher (CPU scheduler), the teleprocessing interface (Front End message handler) and the File Handler (data management interface).
All incoming and outgoing messages are concurrently routed to the various processing programs via internal message queues managed by Message Collection and Retrieval. Intercomm's capabilities extend not only to scheduling and dispatching tasks for high volume throughput, but also to providing the necessary linkage for any file access method of the operating system. All I/O processing is centralized via a special Intercomm facility called the File Handler. Because of the multitasking Dispatcher, the LPAR is active during file (or data base) access procedures, and can be scheduled for other processing functions.
Intercomm is designed for processing both small and large volume multi-application teleprocessing systems with many types of input messages. There is no restriction, aside from the amount of main storage available for the address space, as to the size or maximum number of non-reentrant or reentrant modules/programs that can be controlled by Intercomm. Non-reentrant programs may either process one message at a time in parallel with other programs, or multiple copies of the program may be used. Within each reentrant Assembler, PL/1 or COBOL application program under Intercomm’s control, many messages can be operated upon concurrently by multithread processing.
A special load facility allows for dynamic loading of user-specified subsystems or subroutines above or below the 16M line. A link-edit is not required; a system interface resolves the external references. This facility allows for revision and/or correction of such loadable user subsystems or subroutines while Intercomm is executing.
In the event of a program check within an application subsystem, the Intercomm job does not abend. The program responsible for the error is terminated for the message being processed, but the rest of the system continues execution. Intercomm will snap the program's registers, debugging information, and the related areas of main storage, then will free files, and cancel the message in progress. The operator at the originating terminal is notified of the message-cancelled condition, and the master control terminal receives a detailed message describing the program check condition. Whether or not the program with the error continues to process additional messages is the user's option. A feature is available to spin off snap output to a separate data set which may be printed concurrently with on-line execution, rather than after job termination. Snaps may be routed to a SYSOUT data set which is deallocated and queued for printing immediately on completion of the snap. System debugging information is also provided at the time of the program-check or abend.
With its fast message and file restart/recovery capabilities, Intercomm ensures safe recovery of all messages and files and coordinated restart in the event of computer failure or system abend. The Restart/Recovery facility encompasses queued messages, messages in process, and completed messages. Queues and files are automatically reconstructed from data contained on the system log (journal). Completed messages are discarded; duplicated messages are eliminated; processing is resumed from the point of failure, in most cases within minutes of the restart of execution.
