Modified on by AndyBates
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.
Modified on by Phil_Wakelin
This article describes a process which can be used to automate the phase-in of a Java application in a CICS bundle into a running CICS system. This process provides a similar lifecycle to the usage of the SET PROGRAM PHASEIN command used for traditional non-Java CICS programs, with the added benefits OSGi versioning brings to the application development lifecycle.
Whats in a bundle?
Java applications are deployed to CICS in a different manner than traditional COBOL or PL/I applications. Java classes are compiled into byte codes and then packaged in a binary archive called a JAR file. This like other zFS artifacts such as event bindings or policies is referenced from CICS using a BUNDLE resource, which itself is a standard CICS online resource definition similar to a TRANSACTION or PROGRAM definition. The Java code meanwhile must then be packaged using the CICS Explorer SDK within an Eclipse based CICS bundle project and built and exported to a zFS directory structure. This directory is then referenced using the BundleDir attribute on the BUNDLE definition when installing the Java application into a CICS region.
This process of build and deployment can be performed within the CICS Explorer SDK as follows.
- In Eclipse create an OSGi bundle project containing the Java application. This project is versioned using a semantic versioning scheme with the form major.minor.micro (for instance v1.0.0), the importance of which will become clear later.
- Using the CICS-MainClass header annotate the OSGi bundle manifest with details of the Java class which is to be made available as a linkable service from other CICS applications, for instance CICS-MainClass: mypkg.ClassB1
- Create a CICS bundle project and add a reference to the OSGi bundle project, along with any other resources that are part of the CICS bundle. You must also version this CICS bundle, so its simplest to use the same version i.e. v1.0.0.
- Export the CICS bundle project to zFS using the Export Bundle Project to z/OS UNIX File System menu in the CICS Explorer SDK. This builds the project and exports a directory structure containing the CICS manifest (cics.xml), the referenced bundle part file (i.e bundleB1.osgibundle) and the referenced JAR file. Your zFS file system would now look like this if you used the /tmp/cicsbundles directory.
In your CICS region you will then need to perform the following steps to deploy this application.
- Using CEDA or the CICS Explorer create a CICS PROGRAM definition and in the JVMClass attribute name the service defined in step 2.
- Create a BUNDLE resource definition, and wthin this refer to zFS location of #4 in the BundleDir attribute (i.e /tmp/cicsbundles/B_1.0.0)
- Install and enable the BUNDLE definition and PROGRAM into the target CICS system(s). This does the following
- Loads the OSGi bundle(s) into the OSGi framework of the JVM server
- Activates the OSGi bundles, which validates the dependencies.
- Installs the OSGi service(s) into the internal JVM OSGi service registry, making the application available to LINK commands
- Disable any previous versions of the same OSGi bundle that were active using their associated BUNDLE definition
For further details on this process refer to chapter 6 in the IBM Redbook, CICS and the JVM server, Developing and Deploying Java Applications, SG24-8038
OSGi semantic versioning
The OSGi manifest in the OSGi bundle project is used to define the properties of the OSGi bundle. This includes the version according to the scheme <major>.<minor>.<micro>. This version information is a key part of the lifecycle process as the version information will be used by the OSGi framework when multiple versions of the same bundle are loaded at once. In the example the bundle-symbolic name bundleB1 will be used as the name of the CICS BUNDLEPART resource and the bundle is versioned as 1.0.0 and defines a service entry point mypkg.ClassB1, which is the class with the main() method that will be invoked when the service is linked to.
Bundle-Name: My bundle B1
Deploying a fix
Every time a new fix is built for a CICS Java application, steps 1-4 will need to be repeated to build a new version of the OSGi bundle and package as a CICS bundle. In a production environment these would usually be performed by an automated build process rather than manually using the CICS Explorer. In addition steps 6-8 would need to be performed to deploy this new application to zFS and load into a running CICS JVM server. However, a recent PTF available for CICS TS V5 via APAR PI24367 has now simplified this process so that the disabling of the old bundle (step 8) is no longer required to activate the new version. With the APAR applied all new versions of an OSGi service will become active even if they duplicate an existing OSGi service of the same name. In this situation the OSGi service that references the bundle with the highest semantic version will be used for any new EXEC CICS LINK commands as soon as the OSGi service is activated.
This process is fairly simple when used in a development or unit test environment, but in a production system the same process needs to be automated and scripted to allow fixes to be built and and promoted into the production system on demand. The problem in this situation is that the usage of either the CEDA transaction or the batch interface DFHCSDUP, to define RDO resources in a production system can cause further issues because CSD access is often not part of the normal deployment process in production. In addition when sharing a CSD across multiple regions, CSD access for the creation of resources is usually limited to a single region to minimize any CSD locking problems. To address these issues the CREATE SPI command can be used to avoid the need to access the CSD when deploying the new CICS bundle resource.
Using the CREATE command
The EXEC CICS CREATE command is a system programming command that can be used to create any CICS resource without recourse to defining this in the CSD or CICSPlex SM data repository (DREP). This can be used to create new BUNDLE definitions in a running system, and is especially useful if the resources required are temporary resources that do not need to be stored in the CSD for installation on a cold start of the CICS region.
Scripting the process
The following process assumes that the Java application is installed at startup of the CICS region using CICS bundle B0 from a CSD group in the CICS grouplist. Bundle B0 refer to the zFS location /tmp/cicsbundles/B/1.0.0 in its BundleDir attribute, which includes OSGi v1.0.0 of the OSGi bundle B.
- A new version of the CICS bundle project is created with an incremented minor version (v1.0.1) and containing a new minor version (v1.0.1) of the OSGi bundle B. The CICS bundle project is then exported to the zFS location /tmp/cicsbundles/B/1.0.1
- The following CICS SPI commands can then be issued:
- CREATE BUNDLE(B101) ATTRIBUTES('BUNDLEDIR(/tmp/cicsbundles/B_1.0.1) STATUS(ENABLED)' ATTRLEN()
- INQUIRE BUNDLE(B101)
- SET BUNDLE(B0) DISABLED
- DISCARD BUNDLE(B0)
Step (i). dynamically creates a new bundle definition in CICS and enables it. This loads the new version of the OSGi bundle B into the JVM server and activates its new OSGi service. At this point all new LINK commands to any PROGRAM that refers to the service for bundle B will use the new version of the Java application in version 1.0.1 of the OSGi bundle.
Step (ii) inquires on the state of the bundle from step (i) and if enabled (iii) disables the old version of the CICS bundle, which deactivates the OSGi bundle.
Step (iv) destroys the prior version of the CICS bundle resource, which removes the OSGi bundle from the OSGi framework but still allows any in-flight CICS transactions using this version of the OSGi bundle to run to completion.
- Finally the CSD must be updated so that the BUNDLE definition for B0 refers to the new CICS bundle exported to /tmp/cicsbundles/B/1.0.1, in order for this to be used for a subsequent cold start. This can be performed using the DFHCSDUP batch utility to update the BundleDir attribute of the CICS Bundle resource B0, avoiding any need to use the CEDA transaction.
This deployment process can now be fully automated to support the deployment of new versions of a Java applications in a CICS bundle into a running CICS system, without interrupting existing workloads. In addition to backout the fix, the process simply needs to be reversed by enabling the previous version of the CICS bundle and then disabling the new version of the CICS bundle.
The options that are available to automate the SPI commands in steps i-iv from a z/OS batch job are as follows:
- A CICS SPI program that is invoked from batch using the EXCI
- An MVS console automation job which drives the CEMT and CECI commands in a CICS region
- A REXX script using the CICSPlex SM API
- An HTTP client which issues CICSPlex SM commands using the CMCI as described in this cicsdev article
The following references can be used to provide additional information on OSGi bundles and deployment into a CICS JVM server
Modified on by AndyDWharmby
This article describes how it is possible to define a CICS policy and deploy it into a CICS region such that the policies rules are only applied to specific CICS user tasks rather than all user tasks that run in that CICS region.
CICS TS V5.1 introduced the capability to define policies to monitor the resource utilisation of a user task, and to automatically respond when resource usage exceeds the thresholds you define. In this way, excessive resource usage and looping and runaway transactions can be detected and dealt with appropriately. While primarily designed to be deployed with CICS applications and platforms to monitor application tasks they can also be deployed to stand-alone CICS regions to monitor any CICS user task. By default polices deployed to a CICS region apply to all user tasks executing in that region. However deploying polices with such a wide scope may not be suitable in all cases. What if you have a requirement to apply policy to specific tasks rather than all tasks ?. This article walks you through the steps required to restrict a CICS region policy so that its rules are only applied to specific user tasks.
Policy support in CICS TS
CICS Transaction Server V5.1 introduced the capability to define policies to monitor:
- Number of SQL requests
- Number of EXEC CICS file control requests
- Number of EXEC CICS LINK requests
- Number and size of EXEC CICS GETMAIN requests
- CPU time consumed by a task
CICS Transaction Server V5.2 built on this support to add further polices to monitor
- Number of EXEC CICS START requests
- Number of EXEC CICS SYNCPOINT requests
- Number of EXEC CICS transient data requests
- Number and size of EXEC CICS temporary storage requests
- Elapsed time of a task
A CICS policy is defined in a CICS bundle project and each bundle can define one or more policies. Once defined the bundle can then be deployed to a CICS region in one of three ways:
- Add the CICS bundle to a CICS platform. The bundle is deployed with the platform and any policy rules scoped so they apply to any application tasks running on that platform
- Add it to a CICS application or application binding. The bundle is then deployed with the CICS application and any policy rules scoped so they apply only to that particular application's tasks.
- Export the bundle to zFS, and then define, install and enable a CICS BUNDLE resource for the CICS bundle project in a CICS region. In this case any policy rules apply to ALL user tasks running in the CICS region.
This article concentrates on the last of these methods of deployment and shows you how to define a policy such that its rules are only applied to specific user tasks. To find out more information on how to deploy CICS policy with CICS platform and application please refer to "Working with platforms, applications, and policies" in the CICS TS 5.2 Knowledge Center.
For the purpose of this article lets assume we want to enforce the following rules in a CICS region:
- Abend any CICS task that consumes more than 1 second of CPU.
- Emit a CICS event if any of my business critical transactions consume more than 125% of their average CPU consumption.
Defining a region scoped policy
So first lets define a policy to abend any task using more than 1 second of CPU. All policies are created in a CICS bundle project using CICS Explorer. For details of how to create a CICS bundle project please refer to "Creating a CICS bundle project" in in the CICS TS 5.2 Knowledge Center.
Once you have created a CICS bundle project, right click on the bundle project in the Project Explorer view and select New->Policy Definition. The policy is then defined as follows:
Click Finish and a new file "region_CPU_policy.policy" will be added to your bundle project. That completes the definition of a policy that once deployed will apply to all CICS user tasks.
For a more detailed description of how to define a policy in a CICS bundle project please refer to "Creating a policy in a CICS Bundle project" in the CICS TS 5.2 Knowledge Center.
Restricting the scope of a policy
Next we need to define the policy to emit a CICS event if any business critical transaction consumes more CPU than normal. Let's assume one of these transactions is ORDR and we know from the analysis of CICS monitoring SMF records that on average this transaction consumes 400ms of CPU. So allowing a 25% buffer this means we need emit an event if an ORDR transaction consumes more than 500ms.
So first we define a policy to emit an event if a task consumes more than 500ms of CPU. This second policy can either be defined in the same CICS bundle project or a separate one; the choice is yours on how you manage your different policies. In this case we will define the second the policy in the same bundle project so they can be deployed and managed together. So again right click on the bundle project in the Project Explorer view and select New->Policy Definition. The second policy is then defined as follows:
The EP Adapter named here; CPUMON; could be any of the supported types of EP Adapter. For example it could be a simple custom adapter that writes a message to an operator console or a HTTP adapter that routes the event to an event processing product such as IBM Business Monitor to update an operations dashboard. For details on the different types of EP adapter available please refer to "Event processing adapters" in the in the CICS TS 5.2 Knowledge Center.
So far this policy looks no different to the first policy. In fact as it stands if we deploy this policy it will trigger an event if ANY task, including ORDR tasks, uses more than 500ms of CPU which is not what we want; we need to restrict its scope to just ORDR tasks. To do this we exploit two of the new features added in CICS TS 5.1 for CICS application and platform support; namely application entry points and policy scopes. These features enable us to be much more specific about which tasks policies are applied to even when those tasks are not part of a CICS application and by exploiting these features we can restrict a policy to just those tasks that pass through a given entry point. CICS currently supports 2 types of entry point; PROGRAM and URIMAP (CICS TS 5.2 only). You can use either type of entry point to help restrict which tasks a policy is applied to. For web service tasks you might chose to use a URIMAP entry point instead but in this case we will use a PROGRAM entry point.
A program entry point can be defined for ANY program that a given task invokes during its lifetime but please be aware that the set of policy rules applied to a task is based on the FIRST entry point a task passes through during its lifetime; if a task passes through a second entry point program no policy rules associated with the second entry point are applied to the task and the original policy rules all still apply to the task. When selecting the program to define as an entry point a TRANSACTION's initial program is an obvious choice. In many cases this may be an appropriate choice but please bear in mind that:
- the same initial program may be named on other transaction definitions
- the program may be invoked by another task via EXEC CICS LINK or XCTL.
In both cases this could mean a policy may end up being applied to tasks it was not intended for so a program invoked by the initial program may be a more appropriate choice. However if the initial program is only invoked via the transaction it is the perfect choice to use as an entry point program to scope a policy to a particular TRANSACTION.
So if we assume that NEWORDER is the initial program of the ORDR TRANSACTION we define it at a program entry point as follows:
- First open up the CICS Bundle Manifest Editor. To do this double click on the cics.xml file in the CICS bundle projects META-INF folder
- Next select the "Entry Points" tab in the CICS Bundle Manifest Editor, and then
- Press the "Add" button and define the entry point as follows;
i) Set Operation to "new_order_ep". This can be any meaningful string up to 64 characters in length.
ii) Let the Resource Type default to PROGRAM. If you are going to deploy the resulting CICS bundle project to a CICS TS 5.2 region you could chose to define a URIMAP entry point here by selecting it from the list of valid "Resource Type".
iii) Set Resource name. We will set this to the name of the chosen entry point program so in this case its the initial program of the ORDR transaction "NEWORDER".
That's defined the set of tasks we are interested in to be those that pass through the entry point program NEWORDER, next we need to associate critical_task_CPU_policy we defined above with this entry point. To do so we define a Policy Scope. Again this is defined using the CICS manifest editor as follows:
- Select the "Policy Scopes" tab in the CICS Bundle Manifest editor, and then
- Press the "Add" button and define the Policy Scope as follows:
i) Set Operation to the value specified when defining the entry point previously, i.e "new_order_ep".
ii) Set Policy Name to the name of the policy we defined earlier, i.e "critical_task_CPU_policy".
Debug tip: Both Policy Name and Operation are case sensitive attributes. If your policy fails to trigger then the first thing to check is that these 2 names match exactly with the names specified when creating the policy and the entry point.
What if I want to apply the same policy to multiple transactions ?
That's easy. You can just repeat the process above and define further entry points for those transactions and policy scopes to associate the same policy with those entry points.
Deploying the CICS bundle and its policies
For details of how to deploy these polices to a CICS region please refer to "Deploying the policies to a single CICS region" in the CICS TS 5.2 Knowledge Center. After deployment is complete the following rules will be enforced in all CICS regions into which the bundle is deployed:
- Any ORDR task's consuming more than 500ms will cause a CICS event to be emitted to the CPUMON EP adapter.
- Any task, including ORDR tasks, consuming more than 1 second of CPU will be abended,
In this article you have seen how you can use functionality that's been available since CICS TS 5.1 to restrict the affect of CICS policy deployed to a CICS region such that its rules are only enforced on specific user tasks. Thanks for reading and I hope you found the information above useful. If you have any questions please leave a comment below and I will get back to you.
Modified on by Phil_Wakelin
Java in CICS used to be a strange place. When I started working on CICS Transaction Server V3.1, having previously worked on WebSphere Application Server, I was frustrated to find an unusual Java environment inside CICS. It had strange options for its configuration and the idea that each CICS task had its own JVM (yes, a whole one) was baffling, and it didn’t understand Java threads. That was 10 years ago, but everything is different now.
The CICS JVM is a first-class enterprise Java environment. It’s so capable we can host the WebSphere Liberty Profile inside it. It uses the IBM 64-bit JVM, provides direct access to CICS runtime services, and is multi-threaded. Java in CICS is no longer a weird environment; it’s simply Java, as you would find it anywhere else. The CICS JVM server established a new baseline for the Java runtime in CICS. This document (https://ibm.biz/BdFVm4), written at the time of CICS TS V4.2, talks in detail about the JVM server implementation and the capabilities it offers.
The changes to Java in CICS have not been limited to the runtime, but have included new tooling to support Java developers building applications for CICS. The CICS Explorer SDK is the easiest point of entry for building Java applications, providing an Eclipse plugin for developing, packaging, and deploying Java applications into CICS.
The advantage of having Java inside CICS (including the WebSphere Liberty Profile) is that you can build new applications and services in Java and seamlessly integrate them with existing core COBOL applications, all within a single managed runtime environment. Using the JCICS API makes integration easy, and allows new Java components to become part of a CICS workload-managed application.
Serious enterprise application development of this sort needs seriously capable tools that can manage the multi-language environment. Tools like Rational Developer for z that provides the COBOL, PL/I, C++, Java and assembler development tools for building CICS, IMS, and DB2 applications.
On reflection, Java in CICS isn’t just like Java elsewhere – it’s more than Java elsewhere because it’s inside CICS.
Modified on by John Knutson
Hidden in the release notes for the latest CICS Explorer V5.1.1 you will see an enhancement that provides the “Ability to edit a CICS Platform project, CICS Application project, or CICS Application Binding project”. The required server-side APAR PM81540 is now available.
These new editors are a significant improvement to the user experience of working with CICS Applications, CICS Bindings and CICS Platforms so if you are interesting in the cloud enablement capability in CICS TS V5.1 please try out these downloads.
Modified on by Phil_Wakelin
On Friday June 14 we GAed z/OS Explorer V2.1 and CICS Explorer V5.1.1, that is to say, they became generally available for download. That wasn't all - we also made our new repository of compatible plug-ins available, with plug-ins for five CICS Tools, five IBM Problem Determination Tools, IBM Data Studio, Rational Team Concert, a 90-day trial version of Rational developer for System z.
I've been the marketing manager for CICS Explorer, and more recently, z/OS Explorer, for over five years now, so I obviously have an interest. When we started CICS Explorer back in 2008 - earlier if you count the planning and development - we had a SupportPac with read-only support for CICS TS along with plug-ins for three CICS Tools. Now we have a common component used by 15 plug-ins from three IBM brands. So, even though it was Saturday, since I'd been waiting for this for some time, I decided to try the installation.
I started by going to the download tab on the z/OS Explorer page, and selected the download in Scenario 1, which uses IBM Installation Manager (IM). The IM package is about 700MB so took about 10 minutes on my home broadband. Another 10 minuets to unzip it. Then I ran the launchpad.exe in the disk1 folder which first installs IM and then z/OS Explorer. I then ran z/OS Explorer from the Start menu and configured my FTP and z/OSMF connections, and was able to access z/OS datasets, z/FS files, and JES jobs and output.
I then launched IM again, this time from the Start menu and used File/Preferences to create a repository definition with URL http://public.dhe.ibm.com/software/htp/zos/2/1/0 . I then selected Install, and clicked on the Check for other Versions, Fixes and Extensions button, and saw all of the products listed above. I installed them in groups - CICS Explorer and CICS Tools, Data Studio, and the Rational products - so that I could see how long they all took, but you can select and install them all at once. All of the plug-ins are downloaded as part of the install, so you need to be attached to a network, but I think that you can create an internal staging server within your own networks. You need to enter a jazz.net id and password to access the rational products, and an IBM id (like you'd use here on dWorks) to access Data Studio, but once you've entered them once, you can save them for future use.
All in all, it probably took a couple of hours to install everything - some of the downloads are quite large, so it may take longer on some networks. But, after that time, I was able to run z/OS Explorer again and find all of the perspectives, views, and actions contributed by ten different products within a single IDE. The five PD Tools aren't loaded on the IM repository yet, though they are available in the Eclipse P2 repository, but I'm sure they'll be there in the next day or so. With them, and MQ Explorer and IMS Enterprise Explorer - both slated for future delivery in a recent Statement of Direction - you'll be able to run close to twenty products covering z/OS and its key subsystems in a single workbench.
I have to admit that I was concerned that running so many plug-ins in one would really slow down the z/OS Explorer start-up time, and the first time I used it after each install it did take longer to start, but the second and subsequent times it was back to normal, taking about 20 seconds.
All in all, a pretty good showing. Ten plug-ins from three different brands, all installed smoothly. Pretty amazing. I know that many of you have experienced issues trying to get different products working together in Eclipse and I hope that the z/OS Explorer initiative makes your life a lot easier in future.
Thanks to everyone who made it happen. It's a great story and I thought it needed to be told.
Updated Tuesday 18th June 2013
Warning: Long path names A few people have experienced problems unzipping the initial downloads on Windows XP machines. The problem is caused when the package is unzipped to a folder whose path is longer than about 90 characters - our longest file has a path of about 160 characters. Older unzip product like WInzip and Windows compressed folders cannot create files with a pathlength longer than 255. Either unzip the package from a short path, or use something like 7-Zip. Updated 20th June: Apparently the unzip problem is well known, if not well understood. Learn more in this technote.
Overnight, the PD Tools were added to the IM repository, so I reran IM, selected the plug-ins for the five PD tools and within about 15 minutes, the plug-ins were successfully installed, as you can see in the following screenshot. When I restarted z/OS Explorer, it still just took 22 seconds - now with 18 plug-ins!
If you want to see what's going on in a little more detail, take a look at this post on cicsabel's blog: https://www.ibm.com/developerworks/community/blogs/cicsabel/entry/installing_my_first_z_os_explorer?lang=en (thanks, Isabel)
Modified on by DavidMHarris
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:
//CICSPA1 JOB ,NOTIFY=&SYSUID
//S1 EXEC PGM=CPAMAIN
//STEPLIB DD DISP=SHR,DSN=CPA.V5R2M0.SCPALINK
//SYSPRINT DD SYSOUT=*
//SMFIN001 DD DISP=SHR,DSN=SYS1.SMF(0)
//CSV DD DSN=MY.CICS.CSV,
//SYSIN DD *
Step 2: Extract and FTP the following REXX MWPREXX into your MY.SYSEXEC library (used in step 3)
Step 3: Use the following sample JCL to create the MWRT CSV
//CICSPA3 JOB ,NOTIFY=&SYSUID
//S3 EXEC PGM=IRXJCL,PARM='MWPREXX'
//SYSEXEC DD DISP=SHR,DSN=MY.SYSEXEC
//SYSTSPRT DD SYSOUT=*
//SYSUT1 DD DSN=MY.CICS.CSV,DISP=SHR
//SYSUT2 DD DSN=MY.CICS.CSV.MWRT,
Modified on by Phil_Wakelin
CICS has supported Web Services for quite a while now such that it is now a popular CICS technology. This article provides links to some of the many sources of information you might find useful if you're interested to learn more about the family of technologies for the support of web services in CICS TS..
A little history
CICS TS V3.1 was the first release with integrated support for SOAP Web services back in 2004. Some readers may recall the earlier SOAP for CICS Feature (a technical preview from 2003) and the earlier still SOAP for CICS SupportPac (also 2003). In the years since then the technology has evolved considerably, additional specifications have been supported, JSON has arrived, and the use of Web services has become widespread.
Web services can be used to expose CICS assets to off-platform clients using open standards. The technology is also used by CICS applications that call remote Services hosted somewhere on the network. Traditional structured application data can be converted to and from XML and JSON data representations. Sophisticated user identity technologies can be used to track individuals across platforms. Complex business applications can be abstracted into Services, and made available to business partners and app developers, without exposing the CICS implementation details.
There are many tools and technologies that can be used to either implement or call Web services in CICS. These include (in no particular order):
- SOAP Web Services, the integrated technology from CICS TS V3.1. This is sometimes referred to as 'native' Web services, implying that the technology is embedded in CICS and exploits the underlying services of the CICS platform.
- Applications can use the integrated CICS service for transforming SOAP messages to and from application data (using WSBind files)
- Applications can process/generate XML themselves, if preferred.
- JAX-WS, the Java API for XML Web Services. This is a pure Java technology for Web services that can be hosted in the CICS Liberty Profile from CICS TS V5.1 onwards
- Java applications can use the JCICS libraries in order to interact with CICS.
- The Mobile Feature Pack, the initial offering for support of JSON Web Services in CICS. This is available from CICS TS V4.2 onwards, and is integrated into CICS TS V5.2.
- Applications use WSBind files to facilitate JSON data transformations.
- JAX-RS, the Java API for RESTful Services. This is a pure Java technology for RESTful Web services that can be hosted in a CICS Liberty JVM server from CICS TS V5.1 onwards.
- Java applications can use the JCICS libraries in order to interact with CICS resources and the JSON Liberty profile feature for data interchange.
- CICS TG V9.1, the CICS Transaction Gateway includes technology for transforming JSON data to and from structured application data. It can be used with the entire family of CICS products, including older versions of CICS TS and CICS VSE and TxSeries.
- Applications use WSBind files to facilitate JSON data transformations.
- z/OS Connect, a component of the WebSphere Liberty Profile on z/OS, it can be used to transform JSON data to and from structured application data, and interacts with CICS using WOLA.
- Applications use WSBind files to facilitate JSON data transformations.
- z/OS Connect in CICS, as of APAR PI25503, z/OS Connect can be hosted within CICS TS V5.2. It performs the same JSON data transformations as in the WebSphere Liberty Profile, but uses a local connection to CICS.
- Applications use WSBind files to facilitate JSON data transformations.
There are various resources you might find useful if new to Web services, in addition to the CICS Knowledge Center.
A good place to start is the 2014 CICS Web Services, Part 1 - Development Webcast: http://www-01.ibm.com/support/docview.wss?uid=swg27043801 . It introduces SOAP and JSON Web Services from the point of view of an Application Developer. It will introduce you to the tools and techniques that are available.
This is complemented by the 2014 CICS Web Services, Part 2 - Deployment Webcast: http://www-01.ibm.com/support/docview.wss?uid=swg27044014 . This second presentation introduces operational Web Services considerations from the point of view of the Systems Programmer.
A particularly useful link you'll want to save is the Web Services for CICS Knowledge Collection: http://www-01.ibm.com/support/docview.wss?uid=swg27010507 . It holds a collection of links to a diverse set of useful Web Services articles, reports & education offerings.
There is also SupportPac CA1P which contains Web services Samples for CICS TS: http://www.ibm.com/support/docview.wss?uid=swg24020774 .
IBM provides professional training in Application Development for SOA and Web Services: http://www-304.ibm.com/services/learning/ites.wss/zz/en?pageType=course_description&courseCode=WM875G .
Web services can be a large subject. IBM has a diverse collection of Redbooks that can help, including the following:
A Software Architect's Guide to New Java Workloads in IBM CICS Transaction Server
First published in December 2014, Part 3 of this book discusses connecting Mobile Devices to CICS using Java based Web services, both SOAP and JSON.
Implementing IBM CICS JSON Web Services for Mobile Applications
First published in November 2013, this book provides a broad introduction to the CICS Mobile Feature pack, and associated JSON technology.
Application Development for IBM CICS Web Services
Updated in January 2015, this book explores many of the more challenging aspects of Application Development for Web services.
CICS and SOA: Architecture and Integration Choices
Published in March 2012, this book helps IT architects to select, plan, and design solutions that integrate CICS applications as as service providers and requesters.
Implementing CICS Web Services
Published in November 2008, this book begins with an overview of Web services standards and the Web services support provided by CICS TS V3. Complete details for configuring CICS Web services using both HTTP and WebSphere MQ are provided next. It concentrates on the implementation specifics such as security, transactions, and availability.
Considerations for CICS Web Services Performance
Published in May 2009, this book considers performance by using different scenarios including Security, MTOM/XOP, and the use of the IBM Tivoli® Monitoring tools to help identify problems that can affect the performance of Web Services. It uses ITCAM for SOA and OMEGAMON XE for CICS on z/OS to show how these tools can be of benefit to identify the cause when the performance of a Web service in CICS becomes unacceptable.
Securing CICS Web Services
Published in December 2008, this book considers the different ways that CICS Web services can be secured. It considers transport-level security mechanisms such as SSL/TLS and CICS support for the message-based security specifications WS-Security and WS-Trust.
CICS Web Services Workload Management and Availability
Published in March 2008, this book discusses the different techniques that can be used to provide high system availability and workload management for CICS Web service applications and how high availability is provided across a Parallel Sysplex.
SOAP Message Size Performance Considerations
Published in August 2007, this Redpaper examines performance when using different SOAP message sizes in CICS Web Services.
Modified on by Phil_Wakelin
The CICS team are very proud to announce the beta release of the CICS TS plug-in to enable deployment of CICS applications using IBM UrbanCode Deploy.
UrbanCode Deploy is a tool to orchestrate and automate the deployment of applications, middleware configurations and database changes into development, test and production environments. UrbanCode Deploy V6.1 and enhancements in V6.1.1 announced today include the zOS Utility plug-in to deploy zFS files and MVS datasets, and to run your REXX, UNIX, and JCL scripts. DevOps as it relates to z/OS is discussed further in the video Getting to the Promised Land of DevOps with UrbanCode.
The new CICS TS plug-in provides steps to:
Perform a NEWCOPY or PHASEIN of a program or list of programs.
Install a resource definition, group or list from CSD or BAS.
A simple use case, to deploy new load modules and perform a NEWCOPY on the related programs, involves steps from both the CICS TS and the zOS Utility plug-ins. The following diagram shows what this process looks like in the UrbanCode Deploy process editor:
Other examples include binding DB2 DBRMs, moving or copying zFS files, starting automated tests, or seeking approvals. There are over 115 plug-ins
to work with most of today's popular systems that host enterprise applications.
To download the plug-in and for more information on getting started, check out the CICS TS plug-in for UrbanCode Deploy. If you don't already have UrbanCode Deploy, download an evaluation.
We are very interested to hear your feedback, questions, and use cases in the comments below or on the CICSdev forum.
Modified on by Phil_Wakelin
Abstract: CICS CMCI connections can only be defined manually in CICS Explorer. This is suitable if you have to create a small number of connections but does not fit if you have to define a large number of connections. This document will show you how to generate Connections.pref from an Open Office spread sheet. This article is based on CICS Explorer 5.1.1
Objective: Generate Connections.pref from Open Office spread sheet (See picture below)
How you will reach your objective: By following this guide you will define an XML Filter on OpenOffice. You will then use the newly created XML Filter to Export the spread sheet. You will then use Open Office in this way: On OpenOffice Calc, click on File -> Export, on Save as type Select the newly created export type. (See picture below)
What needs to be done:
1 - Store the attached sample files:
1.1 Download the ExportConnectionSampleFiles.zip attachement.
1.2 Unzip the attachment in a suitable place on your workstation
1.3 Explore the content of the unzipped folder. You should find three files:
- XSLTExportConnections.xml - Artifact to be pointed by OpenOffice Calc (See instructions on 2.1)
- Sample.ods - Sample spread sheet file to demonstrate the Export process
- Sample.pref - Sample output generated using this guide
2 - On Open Office Calc. Click on Tools -> XML Filter Settings...
2.1 Click on New.
2.2 Specify values as the followings:
NOTE: XSLTExportConnections.xml points to the file that you have downloaded from the attachments.
Explanation: The XML file that you have referenced in Open Office Calc is a XSLT file. XSLT is language used in many contexts (for example Mobile development) by which you can specify XML transformations.
In this case you wil use an XSLT transforamation to transform a XML file format (Apache Open Office Calc) into another format.
Of course, this transformations can be customized as needed, try editing the XSLT file!