This post explores some of the key improvements made by the foundation team in the CICS TS V5.3 Open Beta.
The foundation team, as the name suggests, are the foundation of CICS development, responsible for and making changes to the heart of CICS. We have made many improvements in CICS TS V5.3, satisfying 60 customer requirements with more to come. Improvements have been made to monitoring, statistics, API, messaging, dump and trace, as well as to the internal workings of CICS. Here is a short overview of some of the key changes.
Increased security capabilities delivered by the foundation team include ways to avoid transmitting passwords over the network. One method is to request a PassTicket from an external security manager (ESM) such as RACF®, with the new EXEC CICS REQUEST PASSTICKET command. A PassTicket is a secure representation of a password that a program can use to sign on to an application. Using a PassTicket in place of a password means that applications don't have to store passwords, nor ask users to re-enter them, in order to sign on to the target system. Another way to avoid transmitting passwords over the network that provides stronger encryption algorithms than PassTickets is to use the new ability to sign on from 3270 with a Kerberos token rather than a password. The new EXEC CICS SIGNON TOKEN command enables applications to validate a Kerberos token, as determined by an ESM, and to associate the user ID associated with the token with the current terminal.
We have also made it easier to achieve audit compliance, removing HTTP TRACE support and making the HTTP Header Server and User-Agent fields customizable. You can now specify the minimum level of Transport Level Security (TLS) that you want connections to use with the new MINTLSLEVEL option, and have removed support for SSL version 3.0. We have also delivered support for the Enhanced Password Algorithm to enable stronger encryption of passwords, and now allow authentication requests to run on open TCBs so that this function doesn't cause a bottleneck on the system.
We have made several improvements in the area of cloud enablement. You can you can now scope threshold policies to a particular transaction ID, whether deployed within CICS cloud applications or in standalone CICS bundles, as you can now define a TRANSACTION resource as an application entry point. New commands added this release that can be controlled by threshold policies are:
WebSphere MQ MQI commands
DLI commands (EXEC DLI or CALLDLI)
Named counter commands
Total EXEC CICS commands (API or SPI)
We have made the handling of DB2® data in a cloud environment easier and more flexible by allowing CICS to issue the EXEC SQL SET CURRENT PACKAGESET command on behalf of your application, enabling you to specify different DB2 collections across different environments. This is done through use of the new PACKAGESET resource. The availability status of an CICS cloud application is now restored if you start or restart a CICS region in the platform after the time when you make the application available; no need to take any additional action to make the application available for use.
New PHASEIN support for bundles enables the registration of a new version of an OSGi bundle with the OSGi framework, to replace any version currently registered. The new version of any OSGi services that are implemented by the new version of an OSGi bundle will then be used by any new invocation of a Java program defined to use this OSGi service. Existing requests will continue to use the old version until the request completes.
Many changes have been made to the internals of CICS to improve performance. We have improved efficiency especially for trace, monitoring, and MRO connections with high session counts. This is accomplished by exploiting new hardware instructions in the IBM System z9® such as store clock fast, cache alignment of some key CICS control blocks, the use of prefetch and reduced lock contention within monitoring algorithms. Over thirty more commands have been made threadsafe.
We have also introduced performance tuning for HTTP connections to protect CICS regions from unconstrained resource demand. If the region becomes overloaded CICS temporarily stops listening for new HTTP connection requests. If overloading continues, CICS closes existing HTTP persistent connections and marks all new HTTP connections as non-persistent. These actions prevent oversupply of new HTTP work from being received and queued within CICS, allowing feedback to TCP/IP port sharing and Sysplex Distributor, promoting a balanced sharing of workload with other regions that are sharing the same IP endpoint and allowing the CICS region to recover more quickly.
In the CICS TS V5.3 Open Beta we have extended the existing "storm drain" avoidance support to connections from CICS to IMS™, WebSphere® MQ and VSAM RLS. The “storm drain effect” is when workload manager is deluded into routing more work to a CICS region whose connection to a resource manager is not active. When an application running on that region receives a return code indicating the connection is not active and issues an error message and returns normally, the workload manager sees good response times are being achieved by this CICS region for work involving the resource manager, and therefore routes more work down the “storm drain”.
Enhancements made to CICS Explorer for the CICS TS V5.3 Open Beta include the ability to automatically connect to a default connection at startup and improved customization options for table views to make it easier to see the data you are interested in, which can be saved for future use. CICS Explorer is newly available for the OS X Yosemite (10.10) operating system and now provides the ability to connect to a CICS TS for z/VSE® 2.1 system to browse and process supported resources.
Perhaps one of our lesser known programmes, were you aware that the CICS development team can offer a number of different fee-based services to help you manage your systems more effectively? We can share our expertise to help you take advantage of CICS’s latest features, to embrace industry shifts towards Mobile and Cloud solutions, or simply to ensure your system is as efficient and robust as your enterprise demands.
By working with your IBM account team we can discuss your requirements and tailor an engagement that suits you.
So what can we offer?
Learn IBM best practices
If you’re looking to understand a particular area (or areas) of CICS then look no further than the CICS workshops. These on-site offerings allow you to learn from subject matter experts on a number of different CICS topics including:
Upgrade Java in CICS Cloud Performance High Availability Mobile
CICS Health Check
Get a deep dive into your TP infrastructure.
If you want to ensure that your infrastructure is optimally configured to meet service-level agreements on performance and availability, or perhaps are experiencing issues in these areas, then the Health Check could be the right option for you. Here an IBM expert will analyse data from your systems and interview key members of your infrastructure and management teams, then present back their recommendations for improvements and best practices.
More information on both the Workshops and the Health Check can be found at:
An advocate is a personal contact from within the CICS team, who is able to learn - over time - your business needs and requirements from CICS. They are able to communicate and propagate your feedback and requirements to the rest of the development organisation, to ensure your voice is heard. They can also help keep you informed of the latest features that will be of particular interest to you and provide general advice & consultancy. As an added bonus, having an advocate is completely free of charge.
To get in touch about organising a Workshop or Health Check, or to declare your interest in the CICS Advocacy programme, simply send an email to CICSDTS@UK.IBM.COM.
The JCA local ECI feature provides an optimised JCA adapter supporting the CICS Transaction Gateway JCA ECI interfaces. This allows you to port existing JCA applications that use the JCA ECI interfaces from other JEE applications servers into the a CICS Liberty JVM server, and to developed new JEE applications that can link to existing CICS COBOL programs without being tied to the propietary JCICS Java API.
In the March CICS TS 5.3 Open Beta we announced support for JCA 1.6 in CICS Liberty JVM servers, this allowed applications using the CICS TG ECI resource adapter to be run inside CICS. However, these applications still had to go outside of CICS via CICS TG to call a CICS program, which is not an optimal solution.
Since then we've been working with CICS TG on creating a resource adapter which keeps the same API as the ECI resource adapter, but which uses CICS APIs instead of CICS TG to perform a locally optimised call to a CICS program: the JCA Local ECI resource adapter.
The JCA Local ECI resource adapter provides benefits to new applications as well as existing ones: it doesn't require JCICS, so applications can be made to be portable between CICS and distributed system and it provides optimisations for creating multiple containers in a channel on a program call.
The JCA Local ECI feature comes installed on all CICS TS 5.3 Liberty JVM servers. To enable the feature, edit the Liberty JVM servers server.xml to include the following feature cicsts:jcaLocalEci-1.0 in the feature manager element as shown in figure 1.
Figure 1: server.xml snippet to include the JCA Local ECI feature
<!-- Other features -->
<!-- Other content of the server.xml -->
Consolidating an existing application
Consolidating an existing Java EE application into a CICS Liberty JVM server is a 6 step process, which can be easily performed using CICS Explorer
If possible, update the JNDI name of the ConnectionFactory to eis/defaultCICSConnectionFactory. If this is not possible, define a new ConnectionFactory with the required JNDI name in server.xml, see figure 2 for details.
Create a new CICS bundle.
Add the existing application to the CICS bundle, target the Liberty JVM server you want to deploy the application too.
Export the CICS bundle to z/FS.
Create a new CICS bundle definition on the CICS region, targeting the location the of the exported bundle on z/FS.
Install the bundle.
To ensure the application is correctly installed, view the Liberty JVM servers messages.log file. A message should appear the the application has been enabled and the URL path to the root of that application.
There are some differences that owners of existing applications should be aware of in an environment which is local to CICS:
If the CICS program that is linked to issues a SYNCPOINT command then this will commit the CICS UOW, which is only possible if CICS is the transaction coordinator. If the Java web application has initiated a Java transaction using the UserTransation class then the CICS UOW will be subordinate to the Java transaction which is controlled by the Liberty transaction manager. In this case the CICS task will not be permitted to issue a CICS SYNCPOINT, either using an EXEC CICS SYNCPOINT command in a called program or a Task.commit() method using the JCICS API. Instead the Java transaction must user the UserTranaction.commit() or rollback() methods to control the transactional scope. However, if there is no Java transaction created by the web application then the LINKed to program will be able to issue a SYNCPOINT, and further if the linked to program is defined as remote it will be invoked using the SYNCONRETURN option allowing the programs linked to via a DPL to also issue a SYNCPOINT as they will run in a separate UOW to that of the calling program.
Setting the transaction ID using the EciInteractionSpec.setTPNNanme() method to set the name of the mirror transaction only functions on a call to a remote program, and will set the name of the mirror transaction alias that will be used. If you need to modify the transaction name under which a Liberty web application runs then this requires usage of a URIMAP resource definition with the USAGE attribute set to JVMSERVER.
Figure 2: server.xml snippet to create another ConnectionFactory with a different JNDI name
Creating a new application using the JCA Local ECI feature
Creating a new application which uses the JCA Local ECI feature is easily done using CICS Explorer and WebSphere Development Tools. This post will show how to create a basic web application (WAR), but the JCA Local ECI feature can be used in Enterprise Bundle applications (EBA).
Create a new Dynamic Web Project
Create a new Web Servlet
In the one of the inherited do methods, use JNDI to look up the ConnectionFactory object
Create a new ECIInteractionSpec object and configure properties on this object.
ECIInteractionSpec spec = new ECIInteractionSpec(); spec.setProgramName("EC01");
Create Record objects for the input and output of the program call.
RecordImpl input = new RecordImpl(); RecordImpl output = new RecordImpl();
Call the execute method on the Interaction object, passing in the ECIInteractionSpec and Record objects created.
interaction.execute(spec, input, output);
Read the output from the output Record.
ABEND in CICS will be wrapped in a Java ResourceException and the resource adapter will provide sensible error messages. More detailed information can be found in the JVM server's messages log file and STDERR.
The Local ECI resource adapter provides a simple mechanism of creating CICS channels and containers to pass to the CICS program. A special class EciChannelRecord can be created to represent a channel; this class extends the MappedRecord class (and through inheritance the standard Java Map class). Each record in this class represents a container, where the key of the record is the name of the container and the value is the contents of that container.
The data type of the value changes the mode of the container. For a container in BIT mode, a type of byte must be provided and for a container in CHAR mode, a type of String must be provided.
Using this method of calling CICS programs with channels and containers has another advantage: rather than creating individual containers in the channel as they are populated, the Local ECI resource adapter uses the object representation of a channel to create the containers in a single batch just before control is passed to the CICS program, keeping the Java code in the JVM for as long as possible.
This blog post has described how to consolidate an existing Java EE application which used the CICS TG ECI resource adapter to communicate with CICS into a CICS Liberty JVM server and how to create a new application which uses the JCA Local ECI feature. It has also explained how the JCA Local ECI feature can be used to call CICS programs with a channel using simple Java objects, rather than relying on JCICS classes, allowing applications to be portable between CICS Liberty JVM servers and distributed application servers.
Back in April, I posted a blog entry called The CICS TS V5.3 open beta is here (already!), summarising the major new capabilities you could get your hands on, just in time for spring. Well, now it’s July and we’ve updated the CICS TS V5.3 open beta to ‘refresh 1’ level, just in time for your summer holidays. So, order a margarita, sit back in your deck chair and open up your mobile browser of choice to see how we continue to strive to help you “do more, with less, and do it faster/better”. Things are heating up…
Do More. In the first CICS TS V5.3 open beta, we added a raft of new features to the WebSphere Liberty Profile runtime that is integrated with CICS TS V5. In this refresh, we added a few more. Support for JPA (Java persistence architecture) completes the list of capabilities needed for the Java™ EE 6 Web Profile feature set. The addition of the WebSphere embedded messaging features introduces support for JMS 1.1 without the need for additional messaging software. The CICS TS V5.3 open beta now also ships with its own JCA local ECI resource adapter, removing the requirement to use the resource adapter provided by the CICS Transaction Gateway when porting JCA applications into a CICS Liberty JVM server.
Outside of Liberty, updating OSGi bundles in an OSGi JVM server becomes much less disruptive, with the introduction of a new phase-in capability that simplifies the process for updating OSGi bundles in a running JVM server. We have also upgraded the Java infrastructure to support running multiple levels of Java. IBM Java 7.0, IBM Java 7.1 and IBM Java 8 can all be used within the CICS TS V5.3 open beta, with different JVM Servers running on different levels of Java, even within the same CICS region. This can help customers standardise Java levels across the enterprise, remove the need to upgrade Java levels as part of a CICS TS upgrade, and quicken the adoption of latest technologies such as SIMD support in Java 8 with the new IBM z13.
With Less. In addition to the many performance related enhancements delivered in the first CICS TS V5.3 open beta, the performance of running z/OS Connect inside CICS TS is now dramatically improved through the introduction of a new native JSON parser. This new processing infrastructure provides greater throughput whilst using substantially less overall CPU than the current z/OS Connect solution. This CPU usage reduction is predominantly in the Java code path, meaning you should need less zIIP CPU to run the same processing. The new function is made available as a pipeline configuration option, and is thus transparent to the application. This allows you to choose the optimal parsing infrastructure based on preference for zIIP usage or throughput rates.
In our ongoing quest to most efficiently utilise each and every MSU, over 30 additional CICS TS SPI commands have been made threadsafe. A new HTTP flow control mechanism has been introduced to prevent HTTP requests from flooding a CICS region if it has reached capacity, allowing TCP/IP to route HTTP traffic more effectively. This mechanism prevents oversupply of new HTTP connections from being received and queued within a CICS region, enabling CICS to recover more quickly, whilst using less storage and CPU. In addition, for those times when something just doesn’t go according to plan, there is a new all-in-one task dump formatter to help you get up and running at full speed again.
Faster/Better. This is all about CICS DevOps and CICS Cloud. Three major new CICS DevOps capabilities were introduced in the first CICS TS V5.3 open beta: the CICS Build Toolkit, DFHDPLOY and an IBM UrbanCode Deploy Plug-in for CICS TS (which is fully GA and available now for CICS TS V4.1 or later). With this latest beta refresh, the types of bundles that can be built using the CICS Build Toolkit has been expanded to include CICS Liberty profile applications. Also added is support for variable substitutions for attributes in CICS bundle parts, such as high level qualifiers for data set names and JVM server names. This is especially helpful when moving applications through the lifecycle, since variables can be substituted for different values appropriate for target environments such as development, test and production without changing the source.
In the original CICS TS V5.3 open beta blog post, I stated that CICS Cloud is the future of CICS application deployments. This latest beta refresh adds even more credence to that by explicitly adding DB2 schema support into an application. This is important when the DB2 data to be accessed is different depending on the deployment environment, for example whether the application is deployed in test or production. There is also an additional policy added which can be triggered when the total number of EXEC CICS requests executed by a task exceeds a predefined threshold. This brings the total number of policy types to 14, containing more than 40 items that triggers can be set against.
Wow – our software engineering teams have been busy this spring. If you’d like to take any of that new capability for a spin, the CICS TS V5.3 open beta was updated to refresh 1 on the 10th July. You can grab it from here whilst it’s still warm.
As a reminder, you won’t have to install the CICS TS V5.3 open beta to get started with some of these automation capabilities. The CICS Build Toolkit available with the open beta will run on z/OS, Linux, and Microsoft Windows operating systems, and will work with CICS TS V4.1 and later. And don’t forget, the UrbanCode Deploy plug-in for CICS is now fully supported for use with CICS TS V4.1 or later.
As always, please let us know your thoughts in the comments below. We in CICS would love to hear from you.
IBM CICS TS Product Manager.
NOTE: This blog post was updated on 21st July 2015 to clarify that the new JSON processing is a z/OS Connect enhancement.
The following steps will enable you to create a CSV extract using CICS PA and then use the supplied sample JCL and REXX exec to convert the CSV to a format that can be used with the Mobile/zCAP Workload Reporting Tool (MWRT).
Note that this version of the solution only supports CICS TS V5.1 and above because it relies on the presence of the CPUTONCP CMF field, introduced in CICS TS V5.1.
Step 1: Use a CICS PA FORM as below to generate the report JCL for the CICS PA CSV extract.
/ Name + K O Type Fn Description
STOP K A DATEISO Task stop time
STOP K A TIMES Task stop time
MVSID K A MVS SMF ID
TASKTCNT Total Task Termination count
CPU TIME TOT CPU time
CPUONCP TIME TOT CPU time on standard CP
EOR ---------------- End of Report ----------------
EOX ---------------- End of Extract ---------------
You will need to make sure you specify the APPLID(s) you need the CSV extract for. If the CSV extract is for a group of APPLIDs then you can specify this using a CICS PA System Group. You will also need to specify the mobile transaction IDs. You can use a CICS PA Object List for this.
In the example below I have specified MOBAPPL* for APPLID and MOB* for TRAN. When you run the CSV extract report using the form above, the JCL should look something like this:
CICS web support is a collection of CICS services that enable a CICS region to act both as an HTTP server and as an HTTP client. When CICS is an HTTP server, a web client can send an HTTP request to CICS and receive a response. The response can be a static response created by CICS from a document template or static file, or an application-generated response created by a web-aware application program, or a SOAP response from a CICS web service.
Since CICS web support was introduced, it has become one of the most popular methods of interacting with CICS applications. The CICS TS V5.3 open beta offering delivers a number of significant optimizations in this area to help reduce the costs associated with serving HTTP requests:
Removing the need for the web attach task
Reducing TCB switching for CICS-provided SSL support
Support for AT-TLS aware
Removing the need for the web attach task
Prior to the CICS TS V5.3 open beta, a web attach task (CWXN transaction) is started in CICS, to process each HTTP request requiring a dynamically generated response, before passing the request to the user transaction such as CPIH for a web service or CWBA for a web application, which may then link to an AOR to invoke the required business logic application.
The optimizations provided mean that the web attach task is no longer needed for serving HTTP requests. Instead, the HTTP request is passed directly to the appropriate user transaction, thus reducing the CPU and memory overhead. The scenarios supported for optimzsation include any web or web service based application that doesn't use SSL and doesn't use an analyzer. The TCPIPSERVICE and URIMAP resource definitions for these scenarios would be as follows:
If your CICS web support configuration meets the criteria, you will get the benefit automatically by upgrading to the CICS TS V5.3 open beta.
If your configuration doesn't use a URIMAP or requires an analyser, you may want to review the configuration to take advantage of the potential optimization. If your configuration uses SSL in CICS, there have been other performance enhancements in this area but the web attach task is still required. However, it is still possible to remove the web attach task for SSL web requests by migrating from CICS SSL support to AT-TLS.
Reducing TCB switching for CICS-provided SSL support
CICS SSL support runs on S8 TCBs. In previous CICS releases, S8 TCBs were incapable of performing socket I/O. This meant that there would be multiple TCB switches to and from S8 TCBs during SSL handshakes and send and receive of encrypted data. In the CICS TS V5.3 open beta, most of the switches have been eliminated by making the S8 TCBs eligible to perform socket I/O. Therefore, scenarios using CICS SSL support also see performance improvements.
Adding support for AT-TLS aware
The optimization for removing the web attach task can be applied for inbound HTTPS requests, when SSL support is provided by the Application Transparent Transport Layer Security (AT-TLS) feature of IBM z/OS Communications Server. The CICS TS V5.3 open beta has been enhanced to exploit AT-TLS AWARE capability for inbound HTTP connections (those which connect using a TCPIPSERVICE configured with PROTOCOL(HTTP)).
AT-TLS is the component of z/OS Communications Server which can be configured to encrypt/decrypt message flows for specific ports (such as a TCPIPSERVICE port). AT-TLS defines an AT-TLS POLICY to configure properties such as KEYRING, CIPHERS, SERVER CERTIFICATE, TLS PROTOCOL(S) etc.
CICS can already be used today with AT-TLS in BASIC mode. In BASIC mode CICS is unaware that the data flowing on a socket is being encrypted and decrypted by AT-TLS and will only ever see clear text (unencrypted) data, and thus a TCPIPSERVICE will have SSL(NO) defined. A major drawback of this is that a server, such as CICS, is unaware that a client certificate may exist. This means that CICS is unable to exploit certain TCPIPSERVICE security setups when running AT-TLS in BASIC mode. For example, a TCPIPSERVICE cannot be configured with AUTHENTICATE(CERTIFICATE) when it also uses SSL(NO).
There is a second mode of AT-TLS operation called AT-TLS AWARE. In this mode, a server (such as CICS) 'discovers' that AT-TLS is active for a client connection by querying the AT-TLS state. The server retrieves state such as CIPHER used on the handshake, the client certificate (if one exists) and the certificate USERID. With this mode CICS is able to exploit TCPIPSERVICE options such as AUTHENTICATE(CERTIFICATE).
CICS is introducing a new TCPIPSERVICE SSL option :-
SSL(NO) remains the default
SSL(ATTLSAWARE) is only supported on TCPIPSERVICE definitions which also specify PROTOCOL(HTTP).
All new client connections for the SSL(ATTLSAWARE) TCPIPSERVICE will be queried to extract the following AT-TLS attributes :-
Connection status (AT-TLS secured/not secured)
Client Authentication type (NONE/PASSTHRU/FULL/REQUIRED/SAFCHECK)
Client Certificate (if present)
Client Certificate USERID
CIPHER negotiated on handshake
Having extracted the AT-TLS state for a connection CICS imposes certain 'rules'.
CICS expects all client connections to an SSL(ATTLSAWARE) TCPIPSERVICE to have been secured by AT-TLS.
Error message DFHWB0365 is sent to the CICS log if a new client connection is NOT secure.
The non-secure client connection is sent an HTTP 403 error response.
The first non-secure connection received for an SSL(ATTLSAWARE) TCPIPSERVICE causes a DFHSO0147 warning error to be sent to console as this could signify an AT-TLS setup error.
If the connection is secured and AT-TLS is using the ServerWithClientAuth handshake type but the AT-TLS CLIENTAUTHTYPE is set to PassThru then CICS issues message DFHSO0149 and closes both the client connection and the TCPIPSERVICE.
Assuming an SSL(ATTLSAWARE) client connection has been secured by AT-TLS using a supported AT-TLS policy CICS does the following ...
If a client certificate has been provided CICS retrieves the certificate from TCP/IP and saves it in the certificate repository.
Attributes of the client certificate can be retrieved later on by applications by using EXEC CICS EXTRACT CERTIFICATE.
Any client certificate USERID is stashed away. This can be used in conjunction with AUTHENTICATE option of the TCPIPSERVICE to establish the security context for the new web task. For example AUTHENTICATE(CERTFICATE) will require a CERTIFICATE USERID to be present to allow a web request to be processed.
The ID of the CIPHER suite used on the handshake will be saved in the socket and will eventually appear in a performance monitoring record – in existing field SOCIPHER.
The new SSL(ATTLSAWARE) option is supported for both the CICS Explorer and the CICSPlex SM WUI.
Initial performance evaluations show that using AT-TLS to secure HTTP socket connections reduces overall CPU consumption compared with using CICS-SSL support.
If you have any questions, please feel free to reach out.
Performance improvements have now been delivered in the latest CICS TS V5.3 open beta, here is a quick summary of the function recently delivered
Operational efficiency has been a key focus for CICS TS Version 5 and continues to evolve in the CICS TS V5.3 open beta, where there are many improvements worth knowing about. This time around we have targeted a reduction in the CPU usage of CICS routing and data owning regions, to help you continue to lower the overheads of running work in CICS TS.
Given the different ways you are able to drive work into CICS we have focused our efforts between general improvements that help all workloads, and some specific areas that have the biggest impact. From conversations with customers and survey information we found that web and web services based workloads, namely workloads that handle requests using the EXEC CICS WEB API or those that use the CICS pipeline processing to transform requests into the language structures that programs need, are both popular and growing ways of driving work into CICS. Therefore improving the efficiency of these areas will have a beneficial impact for a broad range of users.
How have we done this?
To gain improvements that affect all workloads there have been some internal code algorithm improvements, exploitation of hardware instructions, and control block alignments to improve cache usage. Two areas where these changes have had a beneficial impact are when trace and or monitoring are active in a CICS region. Also, for many workloads that use MRO, the algorithm used when a large number of sessions has been defined has been made more efficient.
For web and web services workloads we looked at the communications layer to determine how things could be made more efficient. A key optimization in this area is that the web attach transaction, CWXN, is no longer needed in many scenarios. Not running the web attach transaction results in reduced CPU usage as well as fewer monitoring records being written to SMF.
For external web connections security is vital and so we spent some effort in this area too. As of CICS TS V5.3 open beta the SSL processing in CICS switches TCB fewer times during SSL handshakes thereby saving CPU. An alternative security set up is to use the AT-TLS support in IBM z/OS Communications Server to provide SSL support. This configuration allows CICS TS to be AT-TLS aware when setting up a transaction’s security context and our testing of this has shown additional reductions in CPU usage per request.
Give it a go!
So for those that try out the CICS TS V5.3 open beta, they are likely to find that the address space monitoring records for their CICS routing regions show them using less CPU, and that benefits can be seen in other types of CICS region too.
The CICS Transaction Gateway V9.1 Software Development Kit (SDK) is now available for download.
So what's in it?
The SDK contains all the CICS TG JARs, RARs, shared libraries, headers, libs, and schemas that you might need to write, compile, and ship a CICS TG application for any edition of CICS TG V9.1. Whether you're writing a client application, implementing one of the exits, processing CICS TG statistics, or creating JSON web services, the SDK has what you need.
If you're developing a client application, the SDK includes the files needed to compile your application, samples showing how to use them, and for remote mode applications, the runtime files to deploy with the application. For example, a .NET developer can find relevant resources in cicstg/api/dotnet. This directory contains IBM.CTG.Client.dll to reference in Visual Studio when writing the application and deploy with the application, sample projects for EciB1 show how to write a basic COMMAREA application, and even the API documentation for reference.
Using one of the SPIs like CICS Request exits or the Java statistics API? The SDK provides the same kind of files as it does for client applications. So if you are developing a new Request Monitoring exit, look in cicstgsdk/exits/monitoring. You'll find ctgrme.jar, which contains the interfaces to implement and compile against, the BasicMonitor sample shows a simple implementation so you have an idea of where to start, and a local copy of the Javadoc is available too.
For creating JSON web services, look in cicstgsdk/webservices. This includes the JSON web services assistant and sample input files for creating WSBind files.
Finally the legal parts in cicstgsdk/license. The most interesting part is REDIST.txt as it explains what files can be redistributed, which is a very useful reference for understanding which files are needed when redistributing an application or just deploying an application on a remote machine without CICS TG installed.
Where do I get it?
The SDK is available in two archives, a zip for Windows and a tar.gz for UNIX/Linux. A readme is available for both.
Stop clicking! Automate your CICS bundle and application builds
The CICS Build Toolkit is a new command-line interface to build your CICS projects created in CICS Explorer, rather than manually clicking through the wizard to export them to zFS. This allows a script within an automated continuous integration process to build these projects in a repeatable and reliable manner - an essential part of DevOps. You can download it now from the CICS TS V5.3 open beta site.
The CICS Build Toolkit will run on z/OS, Windows or Linux. The projects it can build include CICS bundles, applications, application bindings, and referenced projects such as OSGi bundles, OSGi applications(EBAs), enterprise applications(EARs) and dynamic web projects(WARs). It also adds a new level of flexibility to CICS bundle parts by resolving variables within attributes using values in a properties file. Variables are similar in concept to symbols in JCL that are resolved by JES before job execution, and to variables in UrbanCode Deploy processes. This enables the redeployment of built CICS projects to different target systems in your enterprise, such as development / test / production or possibly to several development systems that have a unique setup for different teams, without changing the source code.
This automation is typically run in two separate stages. Your development build system first uses the CICS Build Toolkit to build the projects, then secondly your deployment system uses the CICS Build Toolkit to resolve the variables into concrete values that are specific for the deployment target.
Let's look at an example workflow.
Building CICS projects
A developer receives a defect work item, checks out a Java OSGi bundle from a source code repository, fixes the Java code, checks in the changes, and kicks off a personal build.
The build system, such as Rational Team Concert, will be aware of the parts that have changed, their dependencies, and how to build each of them using scripts.
The build script checks out the source for the CICS bundle and the Java OSGi bundle to a temporary build directory.
The build script runs the CICS Build Toolkit, specifying the input directory that has the projects source, the CICS bundle to build, and where to place the built output. As the toolkit builds not only the CICS bundle but also the dependant OSGi bundle, you also specify the target CICS release so the correct version of the JCICS Java class library is used by the Java compiler.
The build script checks in the built CICS bundle into a binary code repository such as UrbanCode Deploy component called Codestation, IBM Rational Asset Manager, or a file system staging directory such as zFS. Some of these repositories support versioning and dependencies that make it easier to deploy several components together.
Resolving CICS projects
To deploy the built CICS bundle to a target development system, an automated process or a developer runs a deployment script.
The deployment script checks out the built CICS bundle from the binary code repository, and checks out a properties file from the source code repository that has values in for the target development system. The properties file contains name=value pairs, following the Java .properties file format. In this case it contains a variable with the name of the JVM server in which to install Java OSGi bundles.
cics.jvmserver.osgi = DFHJVMS
The deployment script runs the CICS Build Toolkit to resolve the variables and copy the resolved CICS bundle to a directory on zFS for usage by the target development system ready to be installed into CICS. In this case the .program part in the CICS bundle contains a variable that needs to be resolved.
The deployment script then runs the new DFHDPLOY utility provided by CICS TS V5.3 open beta to connect to the development CICSplex, uninstall the previous version of the bundle, define the new CICS bundle resource, install and enable it ready for testing.
CICS Built Toolkit command line examples
To give you an idea of how the CICS Build toolkit command line syntax looks, here is an example of the build, and then resolve command lines.
Here we build the CICS bundle with ID com.ibm.cics.server.examples.jcics and version 1.0.1, and use the CICS TS V5.2 target platform when building referenced Java projects:
Please note in this beta, not all CICS bundle parts are supported for the resolve step - those that you can resolve variables in include PROGRAM, URIMAP, TRANSACTION, LIBRARY, TCPIPSERVICE, JVMSERVER, FILE, PIPELINE, WEBSERVICE. Look out for further enhancements to the number of bundle parts included and CICS Explorer enhancements to make it easy to specify variables using the bundle part editors.
As you might have read in Andy Bates' post last month, the recently announced CICS TS V5.3 open beta has three core themes at its heart: Service Agility, Operational Efficiency and Cloud with DevOps. Or as Andy put it, "do more, with less, and do it faster/better".
As the hill lead for the Liberty JVM server function in CICS I wanted to spend a bit more time discussing the new function the team has been developing to allow you to "do more" with your CICS. A central area we've been working on are the Liberty features supported within the CICS runtime, which provide a rich set of Java web APIs and application frameworks for use within CICS.
As you can see below, we have several new Liberty profile features and enhancements included in the latest CICS TS V5.3 open beta offering (live as of March 2015), which sit nicely alongside the Liberty features already supported at CICS TS V5.2. I'd love to hear what you think about them, so if you have any feedback, please leave a comment!
New Liberty features
Here's a quick look at the new WebSphere Liberty Profile features you can find in the open beta:
Liberty profile features
Enterprise JavaBeans Lite
Support EJBs written to the EJB Lite subset of the EJB 3.1 specification
Java Management Extensions (JMX)
Provides the ability to manage and monitor applications and system objects, either using the JMX client API, or remotely using the JConsole utility supplied with the SDK, as described here.
Managed Beans and Contexts and Dependency Injection (CDI)
Makes it easier to integrate different types of Java™ Enterprise Edition (EE) components
Supports the use of a MongoDB Java Driver configured providing applications with the ability to interact with the popular no-SQL database on a remote system
Helps with run time debugging of applications that use the OSGi framework.
Database session persistence
Provides high availability and recovery when using HTTP session data in web applications. This support is only for data sources that use a JDBC type 4 driver, due to a restriction preventing usage of a local database and the CICS DB2 attachment.
1 Features also supported at CICS TS V5.2
Enhancements to existing functions
Existing Liberty profile features are enhanced, specifically by adding EAR support for deploying EJB project within CICS bundles, adding SQLJ support for use with DB2® type 2 driver data sources, and JTA transaction support for the Blueprint feature. These newly supported and enhanced features make Java-based web applications hosted in the Liberty profile JVM server even more capable and portable.
Linking between COBOL and Java components
Within the CICS JVM server environments, it has long been possible to sandwich Java components with existing non-Java applications such as COBOL or PL/I. To call out from Java to COBOL the Program.link() method is provided in the JCICS API which drives an EXEC CICS LINK into the specified CICS program passing a COMMAREA or channel interface. This provides a simple model for access existing non-Java programs (such as COBOL or PL/I) from Java applications deployed with a CICS region. However, the JCICS API is specific to CICS and so although supported in web applications in a Liberty JVM server, makes the usage of such web application non-portable to other JEE application server environments.
As a first step in addressing the lack of portability of the JCICS API, support has been introduced in the Liberty JVM server for the JEE Connector Architecture (JCA). This supports the deployment of JCA resource adapters into the Liberty JVM server and allows the CICS ECI resource adapter, supplied by the CICS Transaction Gateway, to be deployed into a Liberty JVM server. JCA based applications that use the ECI can then be ported into the Liberty JVM server without modification and can use the facilities of a remote CICS Transaction Gateway to connect into CICS.
Connecting to Java applications through EXEC CICS LINK
Additionally the CICS TS V5.3 open beta provides a preview of the ability to use EXEC CICS LINK calls from non-Java components into Java applications running in a Liberty JVM server. This is intended to provide COBOL and other non-Java CICS applications full access to the API features of a Liberty JVM server, promoting the sharing of Java code components between Web and traditional CICS applications.
Java Applications are exposed to the LINK command by the CICS-MainClass header in an OSGi bundle manifest, in the same manner as used in OSGi JVM servers. The CICS PROGRAM resource definition names the target using the attributes JVMSERVER name and JVM class (or OSGi service name). When a Java program is invoked by a LINK command, the service in the relevant JVM server is located in the OSGi famework, and the main class is invoked and passed the COMMAREA or channel interface. OSGi bundles with a CICS-MainClass can be deployed into a Liberty JVM server using an OSGI Application project and Enterprise Bundle Archive (EBA) as part of a CICS Bundle project, allowing the Java code to be shared between Web components in the EBA and COBOL, PL/I or even other Java applications deployed in the CICS region.
So that's my whistlestop tour - I hope it has been interesting and useful. If you'd like to keep up-to-date on the new features and functions for developing applications with the CICS TS V5.3 open beta you can use this cicsdev query and a great place to look for more detail is the open beta knowledge center.