Access from CICS and TSO Remote Terminal Processors

For regular CICS or TSO users, transparent access to NOMAD directly in the Session Manager region is simplified using NOMAD's Remote Terminal Processors (RTP). An RTP is a small interface program that runs in a non-NSM environment, and uses MVS Cross Memory Services to communicate with an NSM address space. The RTP requests logon services from NSM initially, and then uses the terminal services of its own environment to read from and write to the terminal at the direction of NSM. NSM sessions via an RTP look just like native NSM sessions to the users.

NSM provides RTPs that execute as TSO command processors, ISPF dialog functions or CICS transactions. Access to NOMAD via the CICS RTP program has no impact on existing CICS applications since NOMAD processing occurs outside of the CICS address space (see Figure 3).

System Commands

The NSM makes special provisions for handling NOMAD SYSTEM commands by allowing NOMAD to simulate commands such as TSO ALLOCATE, ATTRIB, DELETE and FREE.

When NSM receives a SYSTEM command it first attempts to simulate it locally. If it cannot and if the session originated via an RTP, then the SYSTEM command is "reflected" to the RTP for processing.

The TSO RTP supports the reflection of SYSTEM commands, and will either ATTACH them as subcommands or execute them as ISPF Dialog Functions, as appropriate. Thus, when an applica- tion developer is running NOMAD in the NSM via the TSO RTP, all of the normal TSO and ISPF services are available, including the EDIT command, from NOMAD.

In addition, a NOMAD-based version of ISPF (called NSPF) is included in the NOMAD Collection and gives NSM users access to functionality similar to ISPF, as well as to a NOMAD-based editor.

NOMAD CICS Companion

The NOMAD CICS Companion is an add-on product to the NOMAD Session Manager. The CICS Companion provides access to CICS-controlled data without sacrificing the high-speed transaction processing rates, logging, journaling and recovery features of CICS.

The Companion creates a cooperative processing relationship between NOMAD and CICS by offering two basic services: data sharing between the two environments and the ability to make processing requests from one environment to the other.

The Companion allows NOMAD and CICS to communicate in two ways. An application in either environment can place data in transient data queues or temporary storage areas for access by an application in the other environment. Additionally, an application in either environment can trigger processing in the other environment.

An example of the value of the Companion is that a NOMAD Windows front-end can be integrated into an existing CICS application in order to provide the end-user with a friendlier, easier-to-work-with interface while retaining all the strengths of CICS (see Figure 4).

Performance Improvements Benchmark Tests

Select Business Solutions benchmark tests highlight the significant improvements in performance and response time made possible with the NOMAD Session Manager.

In 164 individual tests, CPU seconds and clock time used were recorded. These tests included a variety of Schema functions and procedures covering reporting and updating activities.

The average CPU time required by NSM activities was .096 seconds, compared to .109 seconds in TSO _an 11.1% savings with Session Manager.

Improvements in response time are more dramatic. Clock time for the full test with Session Manager was recorded at 331 seconds. Using TSO, the same activities took 902 seconds. Response time was cut with Session Manager by a factor of nearly 3:1.

Delivering Response-Time Benefits

The NOMAD NOMSYS (main) module is currently about 1.7 megabytes of code. The single copy needed for the NSM address space is pre-loaded at initialization time, as well as all identifiable re-entrant modules that are associated with the NSM System. During session initiation, virtually all of the needed modules are already resident in the Job Pack Area, and LOADs are satisfied immediately with no I/O delay. For NSM users, your installation gets the response time benefits of having NOMSYS in the Link Pack Area (LPA) without taking up LPA space.

Once the NOMAD session is initialized, the performance improvements continue. All dataset allocations pass through the NOMAD/SM Allocation Manager, which uses MVS Dynamic Allocation to allocate datasets and manage their use among individual sessions. A given dataset is allocated to NSM once, no matter how many sessions use it. NSM maintains a use count for its global allocations and does not release them until the count goes to zero. Although this may seem like a small economy, the allocation overhead of catalog search and VTOC search is considerable, especially when User Catalogs are involved. In fact, taking advantage of an existing allocation eliminates all of the I/O normally associated with allocation, and considerably reduces the response time for NOMAD operations that involve a dataset allocation.

NSM also allows installations to "pre-allocate" commonly used datasets by including them as DD cards in the start-up JCL for an address space. Such allocations are never released and are always available without allocation overhead for NSM users in that address space.

Below the allocation level, NSM also manages DCBs for library DDs (e.g., FILETYPE = NOMAD, SCHEMA), and maps multiple users of a library onto a single, already open DCB, wherever possible.

One of the most striking performance improvements is apparent to support personnel rather than the NOMAD user. Because the NSM address space serves multiple users on an asynchronous basis, the overhead involved in making the address space non-swappable can be justified. This replaces multiple TSO NOMAD users with a single NSM address space that is demand-paged. In other words, it is never forcibly swapped, but if its pages become the least recently used, it loses its real storage to more active applications. If the NOMAD applications being executed are low think-time production-type applications, the savings in swap I/O time can be considerable, and if no users are active, the working set of the NSM address space quickly returns to a minimum size (approximately 70K). TSO NOMAD users with NOMAD not in the LPA experience a significant reduction in paging I/O when these users are migrated to an NSM environment.

Benefits for Shared Database Servers

NSM Shared Database Servers function the same as batch servers, and are equally accessible to batch and TSO NOMAD users. However, they are directly accessible to other NSM sessions in the same address space without any need for Cross Memory Services. The elimination of paging and dispatching delays associated with the inter-address-space transfer gives other NSM driver sessions extremely fast response from co-resident servers. As a result, shared database access is as fast, in most cases, as private access.

NOMAD Session Manager in MVS/XA

In an MVS/XA environment, all of the VTD and NOMAD/SM code and most of their working storage can be resident above the 16-megabyte line. In addition, the NOMSYS module, as well as a significant amount of its working storage, can reside above the line (see Figure 5).

In addition to the virtual storage constraint relief, one of the benefits of running NOMAD Session Manager in an XA environment is that MVS/ESA Session Manager users have the option of placing virtual file buffer pools in either data spaces or hiperspaces.

Facilities for Monitoring and Control