Upgrading from CICS TS Version 3

3.1 Upgrading CICSPlex SM: considerations for upgrading from CICS TS 3.1

In addition to the actions described in Upgrading CICSPlex SM, you must do the following:

• Replace a CAS with a WUI:

  If you still use CAS (coordinating address space), replace it with a WUI server at CICS TS 3.1. Then, when you upgrade the maintenance point CMAS, upgrade the back-level WUI to the new release.

• Delete previous CICSPlex SM release definitions from CSD files:

  If you are upgrading from CICS TS for z/OS, Version 3.1 or an earlier release, when you successfully upgrade all your systems to CICSPlex SM Version beta.beta, delete the definitions for previous versions and releases from the CSD of each CMAS and MAS.

  From CICS TS for z/OS, Version 3.2 onwards, the CICS resource definitions for CICSPlex SM are created dynamically, so you no longer need to delete those definitions after the upgrade.

  1. Issue the DFHCSDUP UPGRADE command and specify module EYU9Rxxx, where xxx is the release number for the previous release; for example, EYU9R310 for 3.1. This module is supplied in CICSTS62.CPSM.SEYULOAD. For example:

      //CSDUP   EXEC PGM=DFHCSDUP
      //STEPLIB  DD  DSN=cics.index.SDFHLOAD,DISP=SHR
      //         DD  DSN=cpsm.index.SEYULOAD,DISP=SHR
      //DFHCSD   DD  DSN=cics.dfhcsd,DISP=SHR
      //SYSPRINT DD  SYSOUT=*
      //SYSIN    DD  *
       UPGRADE USING(EYU9Rxxx
     )
      /*

     When this JCL is run, EYU9Rxxx attempts to delete all the groups and group lists for that CICSPlex SM version from the CSD. However, because not all of the items that the job attempts to delete are defined in the CSD, DFHCSDUP gives a return code of 04.
  2. Use the DFHCSDUP SYSPRINT output to check the results of the deletions. The output lists the items that were deleted and the items that were not found.

3.1 3.2 Upgrading regions: considerations for upgrading from CICS TS Version 3

In addition to the actions described in Upgrading CICS regions, you must do the following:

• APF-authorize the CICS activation modules:
  CICS TS 5.2 introduced activation modules for each edition: base, Developer Trial, and Value Unit Edition. At the start of upgrading your regions, you must:

  • AFP-authorize the SDFHLIC or SDFHVUE library.
  • Add the SDFHLIC or SDFHVUE library in the STEPLIB of the CICS TS JCL.
  • If you use coupling facility data table servers, temporary storage servers, region status servers, or named counter-servers, also add the SDFHLIC or SDFHVUE library to the STEPLIB of the JCL for each of the servers.
• Migrate the DFHLRQ data set:

  If outstanding BTS activities for BTS processes exist in CICS, you migrate the contents of your local request queue data set, DFHLRQ. You can use a utility such as IDCAMS COPY to update the new data set with the contents of the DFHLRQ data set from your current release. You must apply this to each CICS region, as necessary.

• After you upgrade a CSD, if you plan to share the CSD with CICS TS 3.2, include the DFHCOMPD compatibility group in addition to the compatibility groups listed in CSD compatibility between different CICS releases.

  Table 2. Contents of compatibility group DFHCOMPD

  Resource type	Name
  TDQUEUE	CPLD CPLI
  PROGRAM	DFHPIVAL DFHSJJML IXMI33DA IXMI33D1 IXMI33IN IXMI33UC IXM4C56
  TRANSACTION	CJMJ

3.1 3.2 Upgrading security: considerations for upgrading from CICS TS Version 3

In addition to the actions described in Upgrading security, you must do the following:

• Check Db2® signon exits and resources:

  f you use RACF® for some or all of the security checking in your Db2 address space, the circumstances in which CICS passes the RACF access control environment element (ACEE) to Db2 have changed.

  In previous releases, the ACEE was passed to Db2 only when AUTHTYPE(USERID) or AUTHTYPE(GROUP) was specified for a DB2CONN or a DB2ENTRY resource. This behavior is unchanged, but, in addition, CICS now passes the address of the ACEE to Db2 when you specify AUTHTYPE(SIGN), and the SIGNID attribute specifies the CICS region user ID. This change makes it possible for Db2 to use RACF security when you use the CICS region user ID to control access to Db2. However, you must verify that your existing resource definitions do not introduce this changed behavior unexpectedly. You must also check any Db2 signon exits to ensure that they operate as expected when the CICS region ACEE is passed to Db2.

• Review the setting on USRDELAY:

  From CICS TS for z/OS, Version 4.1, CICS monitors for RACF type 71 Event Notifications (ENFs) that are sent when specific RACF commands affect the group authorization of a user. Notification of a change to the user ID overrides any setting that is specified in the USRDELAY system initialization parameter. Therefore, review your USRDELAY settings. For z/OS 1.13 with the PTF for APAR OA39486 applied, or later, these RACF commands are ALTUSER with the REVOKE option, CONNECT, REMOVE, DELGROUP and DELUSER.

  This change does not apply to a user ID that is signed on to a local region (for example, a TOR that uses the CESN transaction to sign on). In this situation, CICS is not notified of an ENF 71 event code.

  If you do not want CICS to monitor for RACF type 71 ENF events, you can use the RACFSYNC system initialization parameter to specify this behavior. Use this parameter only under direction from IBM Service, and only as an aid to migration.

• Adapt applications to changed ESM output from VERIFY PASSWORD:

  When you issue the EXEC CICS VERIFY PASSWORD command, CICS enforces the revoked status of a user ID or a user's group connection. The method that CICS uses to verify the password is more efficient, but you might notice changes to the output that is produced when verification takes place. CICS attempts to verify a password by using a RACROUTE REQUEST=EXTRACT request to the external security manager. If the password cannot be verified by using this method, CICS uses a RACROUTE REQUEST=VERIFYX request. Before CICS Transaction Server for z/OS, Version 3 Release 1, CICS always used the RACROUTE REQUEST=VERIFYX request, which is more expensive.

  The output that is produced by the external security manager is different for the old and new methods of verifying a password. If your application programs relied on the output that is produced by the old method, you need to change them so that they do not depend on this output. The differences are:

  • ESMRESP and ESMREASON codes are not supplied by the external security manager for the new method of verifying a password by using a RACROUTE REQUEST=EXTRACT call. These codes are produced only if CICS needs to use the RACROUTE REQUEST=VERIFYX call. Your application programs must always check the EIBRESP and EIBRESP2 values that are returned by the EXEC CICS VERIFY PASSWORD command and not rely on the ESMRESP and ESMREASON codes.
  • Message ICH70002I is not produced by the external security manager for the new method of verifying a password. The message is produced only if CICS needs to use the RACROUTE REQUEST=VERIFYX call. The SETR PASSWORD(WARN(nn)) option must also be active in the external security manager for the message to be produced. Your application programs must therefore not rely on receiving this message.

3.1 Upgrading applications: considerations for upgrading from CICS TS 3.1

In addition to the actions described in Upgrading applications, you must do the following:

• Review startup JCL for unsupported language libraries:

  CICS translator support for pre-Language Environment® compilers is withdrawn. Runtime support is provided for existing application programs that were developed with these compilers, except for OS/VS COBOL and OO COBOL programs, which do not have runtime support. For details of the compilers that are supported by CICS, see Changes to CICS support for application programming languages.

  The following JCL procedures that were supplied in earlier releases for translating, compiling, and link-editing with unsupported compilers are also withdrawn:

  COBOL

  The DFHEITVL, DFHEXTVL, DFHEBTVL, DFHEITCL, and DFHEXTCL procedures.

  PL/I

  The DFHEITPL, DFHEXTPL, and DFHEBTPL procedures.

  C

  The DFHEITDL and DFHEXTDL procedures.

  CICS now supplies the following procedures only, for use with compilers that conform to Language Environment:

  Language	CICS-online	Integrated translator	EXCI	EXCI with integrated translator
  C	DFHYITDL	DFHZITDL (without XPLINK) DFHZITFL (with XPLINK)	DFHYXTDL	DFHZXTDL (without XPLINK)
  C++	DFHYITEL	DFHZITEL (without XPLINK) DFHZITGL (with XPLINK)	DFHYXTEL	DFHZXTEL (without XPLINK)
  COBOL	DFHYITVL	DFHZITCL	DFHYXTVL	DFHZXTCL
  PL/I	DFHYITPL	DFHZITPL	DFHYXTPL	DFHZXTPL

  The following CICS translator options, which all relate to the unsupported compilers, are obsolete:

  • ANSI85
  • LANGLVL
  • FE

  The CICS translators ignore these translator options and issue a return code 4 warning message.
• Replace any OO COBOL applications:

  You cannot use COBOL class definitions and methods (object-oriented COBOL). This restriction includes both Java classes and COBOL classes.

  Modules that use OO features and compiled in earlier CICS releases with the OOCOBOL translator option cannot run in this CICS release. The OOCOBOL translator option was used for the older SOM-based (System Object Manager-based) OO COBOL, and runtime support for this form of OO COBOL was withdrawn in z/OS V1.2. The newer Java-based OO COBOL, which is used in Enterprise COBOL, is not supported by the CICS translator.

• Runtime support for programs developed with pre-Language Environment compilers:

  Applications that are compiled and linked with pre-Language Environment compilers usually run successfully with the runtime support that is provided by Language Environment. These applications do not usually need to be recompiled or relink-edited. If required, adjust Language Environment runtime options to allow these applications to run correctly. For more information, see the z/OS Language Environment Runtime Application Migration Guide and the migration information for the language in use. Because pre-Language Environment compilers are not Language Environment-conforming, programs that are compiled by these compilers cannot take advantage of all Language Environment facilities in a CICS region.

  Although application program development support for obsolete compilers is withdrawn, CICS usually continues to provide runtime support for your existing application programs that were developed with these old compilers. However, to apply maintenance to these application programs, use one of the supported compilers that conforms to Language Environment.

  Runtime libraries that are provided by Language Environment replace the runtime libraries that were provided with older compilers such as VS COBOL II, OS PL/I, and C/370. The runtime libraries that are provided with pre-Language Environment compilers are not supported. Language libraries, other than the Language Environment libraries, must not be present in your CICS startup JCL.

3.1 Upgrading MRO: considerations for upgrading from CICS TS 3.1

In addition to the actions described in Upgrading MRO, you must do the following:

• Upgrade to multiple XCF groups:

  If you are not constrained by the limit of 2047 members of an XCF group, you do not need to take any action. You can continue to use the default DFHIR000 XCF group and you do not have to specify DFHIR000 explicitly on the XCFGROUP parameter of the system initialization table and DFHXCOPT EXCI table. If you are constrained, you can split your CICS regions into related XCF groups. For recommendations about how to configure XCF/MRO, see Cross-system multiregion operation (XCF/MRO).

  From 3.2 onwards, although a CICS region can still join only one XCF group, that group does not have to be DFHIR000. Although each group is still limited to 2047 members, an absolute limit no longer applies to the number of CICS regions that a sysplex can support. The effective limit of 2047 CICS regions that a single sysplex can support is lifted.

3.1 3.2 Upgrading connections to IBM MQ: considerations for upgrading from CICS TS Version 3

In addition to the actions described in Upgrading connections with IBM MQ, you must do the following:

• Review availability of TCBs for CICS-WebSphere® MQ connection:

  Before CICS TS for z/OS, Version 3.2 , a CICS region used a pool of eight subtask TCBs to connect to WebSphere MQ queue managers. The subtask TCBs were not owned by the CICS tasks that made the requests to connect to WebSphere MQ. When a subtask TCB returned the results of a request to a CICS task, the subtask TCB became available for other CICS tasks that needed to connect to WebSphere MQ.

  From CICS TS for z/OS, Version 3.2 , a CICS region uses open TCBs in L8 mode to connect to WebSphere MQ queue managers. When a CICS task makes a request to connect to WebSphere MQ, it obtains an L8 TCB from the pool in the CICS region, and keeps the L8 TCB from the time it is allocated to the end of the task. Even if the CICS task switches back to run on the QR TCB or makes no further requests to connect to WebSphere MQ, the L8 TCB is not released until the CICS task ends. Each concurrent CICS task that connects to WebSphere MQ therefore requires one L8 TCB for the duration of the task.

  CICS sets the limit for the number of TCBs in the pool of L8 and L9 mode open TCBs automatically. The limit is based on the maximum number of tasks (MXT or MAXTASKS) specified for the CICS region, using the following formula:

  (2 * MXT Value) + 32

  The availability of L8 TCBs within this limit is determined by the number of other CICS tasks that are using L8 or L9 TCBs, such as CICS applications that connect to Db2. A CICS task is allowed at most one L8 TCB, which the task can use for any purpose that requires an L8 TCB. For example, a task that connected to both WebSphere MQ and Db2 would use only one L8 TCB. Within the overall limit set for the TCB pool, there is no specific limit on the number of L8 TCBs that are allocated for CICS tasks that connect to WebSphere MQ queue managers; these tasks can potentially occupy all of the available L8 TCBs in the pool.

• Review use of common storage in the WebSphere MQ subsystem:

  CICS tasks that connect to WebSphere MQ require storage in the WebSphere MQ subsystem. When you upgrade from a release earlier than CICS TS for z/OS, Version 3.2 , or when the peak number of concurrent CICS tasks that connect to WebSphere MQ changes, review the use of common storage in the WebSphere MQ subsystem. For information about common storage and connections from CICS to WebSphere MQ, see Common storage in IBM MQ documentation.

• Increase the value of CTHREAD (WebSphere MQ V6 only):

  If CICS is connecting to WebSphere MQ 6, you might also need to increase your setting for the WebSphere MQ subsystem tuning parameter CTHREAD. Before CICS TS for z/OS, Version 3.2 , CICS always took up nine of the connections specified by CTHREAD, plus one for each task initiator (CKTI). From CICS TS for z/OS, Version 3.2 , the number of connections depends on the number of CICS tasks that are using L8 TCBs to connect to WebSphere MQ. In WebSphere MQ 6, you can change the value of CTHREAD using the WebSphere MQ SET SYSTEM command. From WebSphere MQ 7, the CTHREAD parameter cannot be adjusted in WebSphere MQ.

• Adapt to the move of CICS-WebSphere MQ components from MQ to CICS:
  In CICS TS 3.2., the CICS-WebSphere MQ adapter, bridge, trigger monitor and API crossing exit moved from WebSphere MQ to CICS . You must take the following actions to use the CICS-WebSphere MQ connection components in their new location:

  • If you are using WebSphere MQ 6, apply the PTF for APAR PK42616 to WebSphere MQ to police the use of the correct adapter. This PTF is not required if you are using WebSphere MQ 7.
  • If you do not share your CSD with earlier releases of CICS , you can remove the existing groups CSQCAT1 and CSQCKB, which contain CSQCxxx definitions, from your CSD.
  • If you do share your CSD with earlier CICS releases, ensure that CSQCAT1 and CSQCKB are not installed for CICS TS 4 or CICS TS 3.2. You must also delete the CKQQ TDQUEUE from group CSQCAT1. For CICS TS releases earlier than CICS TS 3.2, install the CSQCAT1 and CSQCKB groups as part of a group list, after installing DFHLIST. This overrides group DFHMQ and correctly installs the required definitions.
  • Place the WebSphere MQ libraries after the CICS libraries in the CICS STEPLIB and DFHRPL concatenation of the CICS procedure, to ensure the correct adapter, trigger monitor and bridge code is used.
  • Unlike WebSphere MQ, CICS does not support uppercase English. If you want to use uppercase English for your CICS-WebSphere MQ components, you must ensure that ASSIGN NATLANGINUSE returns E (US English), and the system initialization parameter is set to MSGCASE=UPPER . This allows the uppercase English mapset to be used.
  • CICS supplies the program definition for CSQCAPX in group DFHMQ with the parameter CONCURRENCY(THREADSAFE). Specify CONCURRENCY(THREADSAFE) when you define your exit program and any programs that your exit program calls and use only threadsafe CICS commands within the exit. You should also examine any existing API crossing exits to ensure that their logic is threadsafe.
  • CICS-WebSphere MQ messages are changed from the format CSQCxxx to DFHMQ0xxx. Ensure that your message retrieval applications cope with this change.
  • All trace entries produced by the CICS-WebSphere MQ components now use the CICS trace domain. If you have user tracing enabled for WebSphere MQ tracing only, you can turn off user tracing, saving the overhead of application trace.
  • If you want the CICS-WebSphere MQ connection to start automatically at CICS start up, add the system initialization parameter MQCONN to the system initialization table.
  Some additional functional changes do not require any action:

  • Modules are renamed to use CICS naming conventions, except for all WebSphere MQ stubs and exits. The names for these have been preserved so that existing JCL works, and you are not required to re-link-edit applications, unless you modify them to use the new API calls that were added in 7 of WebSphere MQ.
  • CSQCCOPEN, CSQCCLOS, CSQCGET, CSQCPUT1, and CSQCINQ are shipped unchanged, and are all entry points into DFHMQSTB, which is loaded from SDFHLOAD.
  • There are two new transient data queues, CMQM and CKQQ, both defined in group DFHDCTG. CMQM logs all CICS-WebSphere MQ messages issued by the CICS-WebSphere MQ adapter, trigger monitor and bridge. CKQQ logs all messages relating to CICS-WebSphere MQ connection and disconnection.
  • WebSphere MQ statistics can now be reset during the life of a CICS execution. This means that when you use the CKQC DISPLAY commands, you see only active CICS-WebSphere MQ threads, so numbers can go down or reduce to zero.
• Replace DFHMQPRM with MQCONN resource definition:

  To support WebSphere MQ queue-sharing groups, CICS TS 4.1 introduced the MQCONN resource definition and new EXEC CICS and CEMT commands for the CICS-WebSphere MQ connection.

  Before CICS TS 4.1, you used the DFHMQPRM operand of the CICS system initialization parameter INITPARM to specify a default WebSphere MQ queue manager name and initiation queue name for the CICS-WebSphere MQ connection. (The DFHMQPRM operand was called CSQCPARM before CICS TS 3.2.) An example of this statement is as follows:

  INITPARM=(DFHMQPRM='SN=CSQ1,IQ=CICS01.INITQ')

  You can no longer use the INITPARM system initialization parameter to specify these defaults. If the DFHMQPRM or CSQCPARM operand is present on INITPARM, you must remove it. CICS issues a warning message if the DFHMQPRM operand is present on INITPARM when you start the CICS-WebSphere MQ connection, and defaults specified there are not applied to the CICS-WebSphere MQ connection. The INITPARM system initialization parameter itself is still valid with other operands.

  You must now set up an MQCONN resource definition for the CICS region to provide defaults for the connection between CICS and WebSphere MQ. You must install the MQCONN resource definition before you start the connection. The defaults that you specify in the MQCONN resource definition apply when you use the CKQC transaction from the CICS-WebSphere MQ adapter control panels or call it from the CICS command line or a CICS application. CICS uses the defaults when you use the MQCONN system initialization parameter to specify that CICS starts a connection to WebSphere MQ automatically during initialization. This example MQCONN resource definition can replace the example INITPARM statement shown previously:

   MQconn         : MQDEF1
   Group          : MQDEFNS
   DEScription  ==> 
   Mqname       ==> CSQ1
   Resyncmember ==> Yes                  Yes | No
   Initqname    ==> CICS01.INITQ

  You can specify either a WebSphere MQ queue-sharing group as a default in the MQCONN resource definition, or the name of a single queue manager. To use a WebSphere MQ queue-sharing group, the CICS SVC for CICS TS 4.1 or a higher level must be active for the CICS region. When you install a new level of the CICS SVC, an IPL is required to activate it. Message DFHMQ0325 is issued if a CICS region attempts to connect to a WebSphere MQ queue-sharing group when the CICS TS 4.1 or higher level CICS SVC is not active, and a system dump is taken with the dump code DFHAP0002 and the severe error code X'A0C6'.

  You can use new EXEC CICS and CEMT commands to work with the MQCONN resource definition. You can also use the SET MQCONN command to start and stop the CICS-WebSphere MQ connection, as an alternative to issuing CKQC START or STOP commands.

• Review how applications control the CICS-WebSphere MQ connection:

  You can upgrade your application to specify a queue-sharing group, or use the new SET MQCONN command to control the CICS-WebSphere MQ connection instead of linking to another program. The changes are optional but, if you choose not to use SET MQCONN, you might experience new results, depending on the parameters that are used by the application:

  Specifying a queue-sharing group: in the parameter list that your application passes to DFHMQQCN (or CSQCQCON), the CONNSSN parameter maps to the MQNAME attribute in the installed MQCONN definition. You can therefore now use this parameter to specify either the name of a WebSphere MQ queue-sharing group, or the name of a single WebSphere MQ queue manager.

  Replacing EXEC CICS LINK to DFHMQQCN with SET MQCONN: you can start the CICS-WebSphere MQ connection from an application by issuing an EXEC CICS LINK command to link to program DFHMQQCN (or CSQCQCON, which is retained for compatibility) and passing a set of parameters. However, if you continue to use this method of starting the CICS-WebSphere MQ connection, you might experience some new results depending on the parameters that you use in the application. If you upgrade your application to use the new SET MQCONN command to control the CICS-WebSphere MQ connection, you can avoid these results. The results are:

  CONNSSN parameter

  If your application uses the CONNSSN parameter to specify the name of a WebSphere MQ queue manager for the connection, CICS connects to this queue manager as before. In addition, your setting for the MQNAME attribute in the installed MQCONN definition is replaced with the name of the queue manager that you specified on the command. If you want to revert to the original queue manager or queue-sharing group, set MQNAME in the resource definition again.

  CONNIQ parameter

  If your application uses the CONNIQ parameter to specify the name of the default initiation queue for the connection, CICS uses that initiation queue name, and the INITQNAME attribute in the installed MQINI resource definition is replaced with the name of the initiation queue that you specified on the command. (MQINI is an implicit resource definition that CICS installs when you install the MQCONN resource definition.)

  INITP parameter

  If your application uses the INITP parameter, which specifies that the default settings are used, these default settings are now taken from the installed MQCONN resource definition, and not from the INITPARM system initialization parameter. The INITP parameter is therefore now known as MQDEF. When MQDEF is set to Y, the setting from the MQCONN resource definition applies as follows:

  • If the MQCONN resource definition specifies the name of a WebSphere MQ queue manager in the MQNAME attribute, CICS connects to that queue manager.
  • If the MQCONN resource definition specifies a WebSphere MQ queue-sharing group in the MQNAME attribute, CICS connects to any active member of that group. In the event of reconnection, CICS might either connect to the same queue manager or to a different queue manager, depending on the setting for the RESYNCMEMBER attribute in the MQCONN resource definition. You might need to modify your application to take this new behavior into account.

  To stop the CICS-WebSphere MQ connection, you can use either EXEC CICS SET MQCONN NOTCONNECTED or continue to issue EXEC CICS LINK to program DFHMQDSC (or CSQCDSC, which is retained for compatibility). The results of this operation remain unchanged.

  If you want to enable or disable the CICS-WebSphere MQ API-crossing exit while the connection is active, you must still link to the adapter reset program, DFHMQRS (or CSQCRST, which is retained for compatibility).

3.1 3.2 Upgrading SOAP web services: considerations for upgrading from CICS TS Version 3

In addition to the actions described in Upgrading SOAP web services, you must do the following:

• Check that your region size can accommodate the increased memory that is needed for DFHWS2LS and DFHL2WS:

  The web services assistant batch jobs DFHWS2LS and DFHLS2WS require memory to create web service binding files. Since this release, the amount of memory that is required increased to allow the web services assistants to process large and complex web service descriptions.

  The region size must now be at least 300 MB, although some documents might require 400 MB. Either increase the region size, or set the region size to 0M.

  If you redeploy your existing web services in a CICS TS beta.beta region, the regenerated web service binding files are slightly larger.

• Enable MTOM/XOP support in a pipeline:
  MTOM/XOP support is provided as an optional set of elements in the pipeline configuration file. There are some considerations before you enable a pipeline to take advantage of the MTOM/XOP support:

  • If you use your own application handler instead of the default that is provided by CICS web services support, the pipeline processes MTOM messages in compatibility mode. If you want the pipeline to process MTOM messages in direct mode, specify DFHPITP as the application handler in your pipeline configuration file.
  • If you use the default CICS web services application handler, the pipeline processes MTOM messages in direct mode. Ensure that your message handlers can still run successfully when they process containers that hold XOP documents and binary attachments.
  • Configure the attribute send_mtom="yes" in a provider pipeline configuration file only when you are sure that all of your web service requesters can receive MTOM messages. The default value is send_mtom="same", so that MTOM messages are only sent when an MTOM message is received.
  • Consider using zAAP:

    The performance of XML parsing in CICS improved with the introduction of the IBM z/OS XML System Services (XMLSS) parser, which can be accessed directly from CICS. The XMLSS parser uses above-the-bar storage, so there is more below-the-bar storage available for user programs. The XMLSS parser also allows XML parsing to be offloaded to an IBM IBM z Systems® Application Assist Processor (zAAP). The zAAP-eligible proportion of the infrastructure for a web service is small, but if zAAP capacity is available, then using this capacity can reduce the cost of hosting web services in CICS.

    For more information on zAAP, see the IBM Redbooks® publication IBM Redbooks: zSeries Application Assist Processor (zAAP) Implementation.

  • Check that SOAP messages are well-formed:

    Improvements in the XML parsing of SOAP messages mean that CICS rejects some malformed SOAP messages that were tolerated in previous releases.

    For more information on XML parsing in z/OS, see z/OS XML System Services User's Guide and Reference.

  • Adapt to the changed namespace prefix of WS-Addressing elements:

    Web Services Atomic Transactions (WS-AT) use Web Services Addressing (WS-Addressing) elements in their SOAP headers. The default namespace prefix for these WS-Addressing elements that are changed from wsa to cicswsa.

3.1 3.2 Upgrading ATOM feeds from SupportPac CA8K

If you set up Atom feeds with the CA8K SupportPac in CICS TS for z/OS, Version 3.1 or CICS TS for z/OS, Version 3.2 , you can use them unchanged in this release, or you can upgrade them to use the support for Atom feeds that is included in CICS TS.

CICS TS for z/OS, Version beta.beta supports Atom feeds that were set up with the CA8K SupportPac. If you do not want to upgrade your Atom feed yet, you must retain all the resources unchanged, and continue to use the PIPELINE resource support instead of the new ATOMSERVICE resource.

When you upgrade Atom feeds from the CA8K SupportPac, you can continue to use your service routines after some modifications. However, you must replace most of the supporting resources, such as pipeline configuration files, with their CICS TS for z/OS, Version beta.beta replacements, such as Atom configuration files. You can use the CICS Explorer to set up the resources that you need for an Atom feed in this release.