- When character data is passed between platforms that use different encoding standards (e.g., EDCDIC and ASCII)
- When you want to change the encoding of some character data from one Coded Character Set Identifier (CCSID) to another.
For applications that use a COMMAREA to exchange data, the conversion occurs under the control of the CICS systems programmer, who uses the DFHCNV conversion table, DFHCCNV conversion program and, optionally, DFHUCNV user-replaceable conversion program. By contrast, the data conversion model channel applications use is much simpler than what COMMAREA-based applications use. The data in a channel and container application is converted under the control of the CICS application programmer, who issues EXEC CICS API commands.
The CICS application programmer is responsible only for conversion of user data (i.e., data in containers created by the application programs). CICS automatically converts system data, where necessary. Additionally, the CICS application programmer is concerned only with conversion of character data. The conversion of binary data isn’t supported.
Applications can use the EXEC CICS CONTAINER API as a simple means of converting character data from one code page to another. Figure 3 converts data from codepage1 to codepage2. When you use the combination of EXEC CICS commands shown in Figure 3 for data conversion, remember to add a temporary channel as shown in the CHANNEL(temp) parameter. Otherwise, you’re relying solely on the program having a current channel, and this may not always be the case. Also, if the data is large, you should perform an EXEC CICS DELETE CONTAINER immediately after the EXEC CICS GET CONTAINER statement.
Migrating to Channels and Containers
To migrate programs exchanging data via a COMMAREA on an EXEC CICS LINK command, the format of the command must be changed and EXEC CICS CONTAINER API commands must be added to use channels and containers instead.
Figure 4 shows that Program B doesn’t specify a channel operand on its EXEC CICS CONTAINER commands, thus defaulting to its current channel. The same applies to programs using an EXEC CICS START command, as shown in Figure 5.
When migrating from COMMAREAS to channels and containers, keep these considerations in mind:
- CICS application programs that use traditional COMMAREAs to exchange data will continue to work as before.
- EXEC CICS LINK and EXEC CICS START commands, which can pass either COMMAREAs or channels, can be dynamically routed.
- If you employ a user-written dynamic or distributed routing program for workload management, rather than CICSPlex, you must modify your program to handle the new values that it may be passed in the DYRLEVEL, DYRTYPE and DYRVER fields of the DFHDYPDS communications area.
- It’s possible to replace a COMMAREA by a channel with a single container. While this may seem the simplest way to move from COMMAREAs to channels and containers, it isn’t good practice to do this. You should, instead, consider using separate containers for each logically separate data structure in your COMMAREA. This is beneficial for several reasons such as separating input and output data fields, or fields containing different data types. In addition, the use of multiple containers to separate the data structures of the COMMAREA serves to make the data layout more readable and much easier to understand.
- In previous releases of CICS, because the size of the COMMAREA was limited to 32KB and channels weren’t available, some applications used Temporary Storage Queues (TSQs) to pass more than 32KB of data from one program to another. Typically, this would involve multiple readqs and writeqs to a TSQ. If you migrate such applications to use channels, be aware that:
◆ If the TSQ your existing application uses is in main storage, the storage requirements of the new, migrated application are likely to be similar to those of the existing application. Both TSQ data and container data reside in the CICS address space.
◆ If the TSQ your existing application uses is in auxiliary storage, the storage requirements of the migrated application are likely to be greater than those of the existing application. This is because container data is held in storage (above the line, but below the bar) rather than written to disk.
Since the lifecycle and scope of channels and containers are completely under the control of the CICS system, data integrity and storage resource management can be ensured. Additionally, the use of channels and containers also offers an unconstrained, CICS-supported method of passing data alongside a CICS standard API for optimized exchange of data between CICS programs implemented in CICS-supported languages. A simple, explicit code page conversion technique also is available, as is the freedom to dynamically determine the nature of the passed data and thereby select the appropriate processing required. Z
• IBM Redbook: CICS Transaction Server V3.1 Channels and Containers Revealed (SG24-7227-00)
• CICS Transaction Server for z/OS Version 3.1 Application Programming Guide (SC34-6433-02).