OK, after more than 30 years, it appears that Systems Network Architecture (SNA) may not have been such a good idea after all. It had its day in the sun, but now it's being abandoned for the even older protocol of TCP/IP. CICS developers must have seen this coming, because they added support for TCP/IP and sockets in the early 1990s. This column discusses how to define the IBM socket interface as well as a few of its quirks.
Setting up the IBM socket interface
Interestingly, the basic socket setup documentation is not provided in the CICS information centers. Instead, you will find it in the "Communication Server IP CICS Sockets Guide," manual number SC31-8807.
If you starting from scratch, then you should become familiar with several members in the TCP/IP library SEZAINST, which includes many sample programs and CICS resource and file definitions. The CSD statements in member EZACICCT are ready to run through the Resource Definition Online (RDO) batch utility (DFHCSDUP) to define the necessary programs, transactions and configuration file. Member EZACICFG is sample job control language (JCL) for defining the socket's configuration file, EZACONFG.
Like CICS RDO, the socket interface keeps its definitions in a VSAM file called EZACONFG. Sharing this file across multiple regions can be problematic. There is no reason the file won't work with record-level sharing (RLS) if you want only one file. Otherwise, you can create a unique file for each region. There is also the "hopeful" method used in my shop, where we have a single file and assume that only one region at a given time will open it for updating.
CICS socket interface definitions
As mentioned above, the socket interface uses EZACONFG for its data repository. Wi...
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
thout going into detail, there are at least two records for each CICS: one for the sockets interface and another for the listener. As you may know, a listener is a CICS transaction that "listens" on its defined port for incoming messages.
Here is a list of some of the socket information:
- The CICS APPLID for whom the definition applies
- TCP/IP's address space name
- Number of socket subtasks
- Extrapartition transient data queue for TCP/IP messages
Defining the listener is more involved:
- Again the CICS APPLID
- The listener transaction ID (CSKL by default)
- The listener's port number
- Some TCP/IP listening socket attributes
An optional security exit
The security exit is one way to apply control over incoming messages. The listener passes the exit to a communications area (COMMAREA) before starting the application task. The COMMAREA includes the proposed transaction ID and other pertinent information. The exit, in turn, sets flags indicating how things should proceed. There might be sample code for a security exit, but I was unable to find it. Member EZACICSX in SEZAMAC maps the COMMAREA passed from the listener.
There are two ways to get information into EZACONFG. First, there is transaction EZAC, which leads you through a series of panels collecting information about CICS and the listener. But I wouldn't recommend using it. The transaction seems to be built on a weird command language, and I guarantee disappointment if you hit the wrong PF key and lose some of your work.
Second, you can use EZACICD macros. At first, these macros look a lot like the CICS table definitions we all know and love. Instead of creating a load module of literals, however, EZACICD generates a program that uses the input configuration parameters to load the EZACONFG file.
The definitions start with a TYPE=INITIAL macro indicating the configuration file's DD statement and the program name to generate. What follows are TYPE = CICS and TYPE = LISTENER macros specifying the interface's attributes as outlined above. The end is marked by a TYPE = FINAL. For additional information, consult the aforementioned CICS sockets manual.
Member EZACICFG in SEZAINST contains sample JCL for defining and loading EZACONFG. While this job is a good starting point, you may want to tweak it:
Back up EZACONFG before deleting
Conditionally delete/define EZACONFG only after a successful compile
Again, what you decide to do with this job and how you manage the definitions depends on whether you use global or unique files.
At this point, I don't have recommendations for the TCP/IP parameters. The defaults work well. But you have to watch closely for conflicting port numbers, either between CICS regions or other TCP/IP applications. Your network team is the best clearinghouse for that information.
Socket interface operation
The sockets interface can be started manually or automatically. If you prefer automatic initialization, then you may add program EZACIC20 to the initialization (PLTPI) and shutdown (PLTSD) program list tables. The PLTSD entry is important, as it stops the socket interface and detaches the TCP/IP subtask. Failure to include EZACIC20 in PLTSD will elongate shutdowns and cause system ABENDs.
Alternatively, transaction EZAO allows you to start and stop sockets on the fly. Again, this approach is not recommended because it follows EZAC's weird command scheme. For operational simplicity, it's relatively easy to write your own transaction to do the initialization and termination functions. It's also important to note that the sockets interface can be started separately from the listener. This may be convenient if your shop needs to temporarily halt traffic to a region without stopping the entire sockets interface.
At the price of security and data integrity, sockets offer a faster, lower-overhead alternative to SNA. It is also a good way to interact with native Unix applications without contending with the mess of SNA servers that don't work correctly. The CICS sockets interface marks the beginning of a simpler way to provide TCP/IP services.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
