5
Systems Network Architecture Concepts

This chapter describes typical data flows between two systems network architecture transaction programs. The following topics are discussed:

Data Flow

Figure 5-1 displays a simple exchange of data between the following two transaction programs:

The CICS adapter
A CICS transaction on the mainframe

Figure 5-1 Windows Platform to Mainframe Flow

Text description of the illustration nttomainframe.gif

Logical Units and Parallel Sessions

LU 6.2 can provide more than one session (used by the conversation). These sessions are:

Long-lived--Activated on demand by a command or automatically when a there is request to start a conversation. They can also be called when an Allocate command is received.
The maximum number of sessions is a parameter--The maximum session is 32767 (for VTAM) for a LU 6.2.

There is a limitation of 999 sessions for the mainframe CICS LU 6.2. CICS can receive up to 999 conversations concurrently from one to n other LU 6.2 connection. The session can be reused by conversations.

CICS Adapter Conversations

Since it is possible that a request from an adapter may require more than one transaction, it is possible to reuse the same conversation (by not de-allocating the session). By definition, sessions are long-lived connections between the two logical units and a conversation should be allocated and deallocated as soon as possible, to allow other conversations to start. For example a terminal operator who forgot to close a session may hold a conversation open.

It is possible for the CICS adapter to use the same conversation (without de-allocating it and reallocating it again). Therefore, similar credentials from different source use the same one. Modification must be made in the CICS application (application written using CICS as APPC API). If the application in CICS issues a EXEC CICS SEND LAST command, it tells CICS that it will deallocate the session (by an EXEC CICS FREE) later.

If the application instead loops backs to an EXEC CICS RECEIVE and waits for new data, then the conversation could be reused if the program supports the new transaction code.

One of the ways to know if a CICS program loops back is to define it in the metadata. This allows the CICS adapter to know if it can issue more than one transaction without reallocating a conversation. Also, the CICS transaction may deallocate the session when:

The CICS adapter has no choice.
It must deallocate locally the session and re-allocate one for a new transaction.

Reusing the same conversation drives more complexity in the CICS adapter because it knows when it can use an already open conversation. In addition, there are security issues. If the same UserID is not used, it starts a new conversation and there are conversations management issues.

On the other hand, if the application on the mainframe was designed to be called from a concentrating server, it may expect several transactions to be sent on the same conversation, to increase efficiency.

Security

Security has always been an important matter in mainframe. Almost every resource in a mainframe can be protected. While in the past, applications programs were doing their own security, you can now use software packages that help to protect almost all types of mainframe resources. IBM integrated a security interface in the operating system and different vendors (including IBM) uses that interface for implementation. CICS is using the same interface. In short, defining it and allowing users, with the correct profile, can protect resources. VTAM (systems network architecture controller) is also using it. CICS, like the others packages, is using its own security scheme. However, since CICS version 9.0.2, it is using an External Security Manager (ESM) to protect resources. The ESM used in CICS mainframe documentation is RACF, the IBM ESM.

LU 6.2 Security

The LU 6.2 architecture defines a number of conversation-level security option sets that include passwords, UserIDs, and profiles in allocation requests. The LU 6.2 architecture also defines a session-level security option set. The architecture requires that session-level LU-LU verification be allowed when conversation-level security option sets are enabled and when the logical units that make up the network are not physically secure (as determined by installation management). In an IBM mainframe using OS/390 for example, VTAM, in essence, is part of the systems network architecture Server and is primarily responsible for handling the LU 6.2 security. It supports session-level security and offers pass-through support for conversation-level security. The application programs are responsible for implementing conversation-level security. In this case, the application program is CICS at the mainframe.

Session Level Security

Session level security includes the following:

Session Level Cryptography

Session level cryptography refers to the enciphering of all or selected user data, at the source logical unit, and the later deciphering that occur at the target logical unit. The encryption algorithm uses a cryptographic key, supplied by the control point, and a session seed, generated by one of the logical units when the session is started. These parameters are exchanged at session activation.

LU-LU Verification

The identity of a logical unit's partner is verified by using a LU-LU password and the Data Encryption Standard (DES) algorithm.

Conversation Level Security

Conversation-level security includes end-user verification, already-verified protocols, persistent verification, and password management. The following terms are associated with conversation level security:

End-User Verification

End-user verification confirms the identity of the partner end user. When a transaction program requests access to another transaction program, it must supply adequate security information in the request to satisfy the security requirements of the other transaction program, or the request is rejected. Security information, here, could be the user ID and password supplied by the end user in its ALLOCATE verb initiating the Attach request between the two logical units. When a user ID and password are supplied on the request, they are verified by the logical unit that receives them. If the UserID and password combination is incorrect, the request is rejected. Also, an authorization list associated with the target transaction program can be used. The keys to search the authorization list would be combinations of the UserID and an optional profile supplied on the request, along with the name of the partner logical unit from which the request originated. The authorization list could be made up of combinations of UserID, profile, and partner logical unit name. After the UserID and password combination is verified by the logical unit, the authorization list may be searched using the received UserID and/or profile for access rights to the specific transaction program named in the request. If the additional criterion is not met, the request is rejected.

Already-Verified Protocols

A transaction program in its invocation of partner transaction programs may represent an end user whose identify has been verified locally and need not be verified at each remote partner, provided that partner trusts the invoking transaction program's logical unit. In this case, the Attach invoking the partner transaction program need not carry the already-verified password of the represented UserID. Instead, an already-verified indicator is set in the Attach request; the UserID and optional profile of the user represented by the invoking transaction program are supplied in the request. For security reasons, the password used to initiate the invoking transaction program is never saved. However, the UserID and optional profile used to initiate the invoking transaction program, are saved. The already-verified indicator can be used only if the sender of the indicator is trusted by the receiver of the indicator to have performed the proper verification of the UserID and password that initiated the sender. This level of trust is installation defined at the receiver of the indicator and communicated to the sender of the indicator during session activation in the BIND/RSP(BIND) exchange.

Persistent Verification

Persistent verification (PV) is one way of reducing the number of password transmissions, by eliminating the need to provide a UserID and password on each Attach (Conversation request) during multiple conversations between a user and its partner at a remote logical unit. The user is verified during a sign-on process preceding its initial conversation and remains verified until being signed off by the remote logical unit, which may occur as the result of an explicit request (triggered by a SIGNOFF verb issued at the remote logical unit), or because no active sessions remain between the user's logical unit and the remote logical unit.

Password Expiration Management

Password expiration management involves request and reply exchanges between two programs. The first program is a sign-on requester service transaction program and the second is a sign-on server service transaction program (called the Sign-On/Change-Password TP) identified by the registered transaction program name X'06F3F0F1'. The requester program invokes the server by an Attach carrying this registered transaction program name.

CICS Security Implementation

CICS defines APPC sessions, connections, and partners as resources, all of which have security requirements. CICS provides the following security mechanisms for the APPC environment:

Bind-time security, or in systems network architecture terms session level security, to prevent an unauthorized connection between two LU 6.2. This security check is done when a session is opened between the two LU 6.2 sessions.
Link security defines the authority of the remote system to access transactions or resources to which the connection itself is not authorized.
User security checks that a user is authorized both to attach a transaction and to access all the resources that the transaction is programmed to use.

Link and User security are a CICS implementation of the APPC conversation level security.

Bind Time Security

An eight character (or 16 hexadecimal digit) password is used by both partners to authenticate. The check is done when a new session is created. All binds can be audited, since it is recorded in mainframe SMF files. This type of security is done at the systems network architecture controller level. This security check is not associated with a UserID; both ends of the connection must have the same session key. In CICS, the key is kept in a resource definition in its ESM. On the other end, the key is defined in the remote APPC logical unit in the Microsoft systems network architecture server. The Bind security is done at Bind time (when a session is activated) and it is kept as long as the session is active.

Security For CICS in General

Each link between systems is given an authority defined by a UserID. It is important to note that users cannot access any transactions or resources over a link that is itself unauthorized to access. This means that each user's authorization is a subset of the link's authority as a whole.

To limit the remote system's access to your transactions and resources, you use link security. Link security is concerned with the single user profile that you assign to the remote system as a whole. Similar to user security in a single-system environment, link security governs the following:

Transaction security--Controls the link's authority to attach specific transactions.
Resource security--Controls the link's authority to access specific resources. This applies to transactions, executing on any of the sessions from the remote system, that have RESSEC(YES) specified in their transaction definition.
Command security--Controls the link's authority for the commands that the attached transaction issues. This applies to transactions, executing on any of the sessions from the remote system, that have CMDSEC(YES) specified in their transaction definition.
Surrogate user security--Controls the link's authority to START transactions with a new UserID, and to install resources with an associated UserID.

Security Specific to LU 6.2

Link security further restricts the resources a user can access, depending on the remote system from which they are accessed. The practical effect of link security is to prevent a remote user from attaching a transaction or accessing a resource for which the link UserID has no authority. Link security can be associated with a connection or a session, depending on whether you want to control the link security for each group of sessions separately.

To define link security for a connection as a whole, specify the SECURITYNAME parameter in the CONNECTION definition (this is a CICS definition equivalent to the remote LU 6.2).
To define link security for individual groups of sessions within a connection, specify the UserID in the SESSIONS definition as a UserID (SESSIONS definition in CICS is the same as SESSIONS in LU 6.2).

Each link between systems is given an authority defined by a link UserID. A link UserID for LU 6.2 is a UserID defined on your session's definition for this connection. If not defined, the link UserID is the SECURITYNAME UserID specified on the connection definition. If there is no SECURITYNAME, the link UserID is the default UserID. The CICS default UserID is the UserID used by CICS when a resource check has to be done and there is no other UserID that CICS can use.

User Security

User security causes a second check to be made against a user signed onto a terminal, in addition to the link security described in Link security. A conversation allocation is related to a CICS transaction and security can apply at that level. Again a UserID and a password may be used to protect the CICS transactions being invoked in the conversation. CICS also uses that UserID to protect files and other resources. The user defined for link security must also have the same access that the UserID used in the user security.

User security can be implemented in five different ways however, only one of these options can be selected:

LOCAL--Specifies that a UserID is not to be supplied by the remote system, and if one is received, the attach fails. CICS makes the user security profile equivalent to the link security profile. You do not need to specify ESM profiles for the remote users. LOCAL is the default value.
IDENTIFY--Specifies that a UserID is expected on every attach request. All remote users of a system must be identified to the ESM. If an attach request with both a UserID and a password is received on a link with ATTACHSEC(IDENTIFY), CICS does not reject the attach request. CICS handles the attach request as if the connection was defined with ATTACHSEC(VERIFY).
VERIFY--If a UserID and an invalid password, or a UserID and no password is received for verification, the attach is rejected. If no UserID is received, CICS applies the security capabilities of the default user. The rules that apply to the checking of the UserID for ATTACHSEC(IDENTIFY) also apply for ATTACHSEC(VERIFY). If a valid UserID is received but the password verification fails then CICS rejects the attach request.
PERSISTENT VERIFICATION--Specifies that a UserID and a user password are required with the first attach request for a new user, but all following attach requests for the same user need supply only a UserID. (All remote users of a system must be identified to the ESM.) The first attach signs on the user, even if the attach request is later unsuccessful because the user is not authorized to attach the transaction.
MIXIDPE--Specifies that the sign-on level for the remote user is determined by parameters sent with the attach request. The possibilities are PERSISTENT or IDENTIFY.

Synchronization of Changes

Systems network architecture defines three levels of synchronization for conversation using the APPC protocol:

Level 0 - None--At sync level zero (0), there is no CICS support for synchronization of remote resources on connected systems. However, it is still possible, under the control of the application to achieve some degree of synchronization by interchanging data, using the SEND and RECEIVE commands.
Level 1 - Confirm--At sync level one, you can use special commands for communication between the two conversation partners. One transaction can confirm the continued presence and readiness of the other. Both transactions are responsible for preserving the data integrity of recoverable resources by issuing synchronization point requests at the appropriate times.
Level 2 - Syncpoint--At sync level 2, all syncpoint requests are automatically propagated across multiple systems. CICS implies a syncpoint when it starts a transaction which initiates logging of changes to recoverable resources, but no control flows take place. CICS takes a syncpoint when one of the transactions terminates normally. One abending transaction causes all to rollback. The transactions themselves can initiate syncpoint or rollback requests. However, a syncpoint or rollback request is propagated to another transaction only when the originating transaction is in conversation with the other transaction, and sync level 2 has been selected.

Syncpoint and rollback are not limited to any one conversation within a transaction. They are propagated on every conversation currently active at sync level two.

Error Handling

This section describes the types of errors, how to handle them, and how to find errors. As there are many pieces of hardware and software involved, errors can be generated from many sources: Application program, CICS, VTAM, NCP, the systems network architecture Controller, or the CICS adapter. There are two type of errors:

Application Error--An error detected by the application and reported in a data message returning to the CICS adapter.

CICS program issues an Issue Signal (APPC verb MC_REQUEST_TO_SEND): this advises the partner that it wants to send data, even if it is still in Receive state. The partner may or may not respond to the request.

The CICS program issues an Issue error (APPC verb MC_SEND_ERROR): It requires immediate attention from the partner logical unit.

The CICS program issues an Issue Abend (APPC verb MC_DEALLOCATE TYPE(ABEND_PROG). This command not only signals a problem but also ends the conversation. It is a severe error condition.
System Errors--Errors are usually detected by other components than the application system. Examples of system errors include:
- CICS application program abended. Abend is a term defining a program which is terminated by a control software instance (CICS for the application program, or OS/390 for the CICS program). Usually the local LU 6.2 is advised of the condition and is able to send to the partner logical unit and application program a message telling the condition.
- CICS itself abended--Causes all the conversations in progress to be abended).
- VTAM problems (physical unit type five) or NCP problems (physical unit type four).
- Systems network architecture controller, including the local LU 6.2.

5 Systems Network Architecture Concepts