Passing data objects between CICS Java environments: Part 1: CICS Java environments

Java is becoming a popular programming language for CICS applications. CICS provides multiple Java environments, each with its own strengths, so passing data objects between the different CICS Java environments is an important topic. This article series gives you the details. Part 1 describes the CICS Java environments, the advantages of each one, and the different ways to pass data between them.  Part 2 uses an example Java class to show you how to pass Java data objects between applications running in a CICS-pooled JVM, an Axis2-based JVM, a CICS Dynamic Scripting environment,  and a CICS OSGi-based JVM. Part 3 shows you how to pass Java data objects from a CICS Transaction Gateway Java client program to a CICS-pooled JVM or CICS OSGi-based JVM.

Dennis Weiand (dweiand@us.ibm.com), Client Technical Specialist for CICS, Web, and Java, IBM Technical Sales team, IBM

Photo of Dennis WeiandDennis Weiand is a Client Technical Specialist for CICS, Web, and Java on the IBM Technical Sales team based in Dallas, TX. You can contact Dennis at dweiand@us.ibm.com.



04 January 2012

Also available in Chinese Russian

Introduction

One of the strengths of IBM® CICS®is that it supports multiple programming languages, and lets you mix them within a single application. But what if your CICS-based applications are using Java only, and you want to leverage the strengths of the various CICS Java™ environments. When passing data between CICS programs, you usually place the data in a field-oriented series-of-bytes structure that can be accessed by an application program coded in any language. But if Java is the only language you are using, it is better to stay in the object-oriented Java world and pass Java data objects between your CICS-based Java programs. This series of articles discusses CICS Java environments available in CICS TS V4.2 or later, and while it is intended for Java programmers developing programs for CICS, it will also be helpful for CICS systems programmers and CICS application programmers who are starting to use Java.

Since its initial support of Java in 1999, CICS has been enabled to control a pool of JVMs where only one Java-based CICS transaction is dispatched to a JVM at a time (hence the need for a pool of JVMs). In CICS TS V4.1 (June 2009), CICS introduced the JVMServer resource, which is a JVM where multiple Java-based CICS transactions can be dispatched concurrently. Initially it was available only for system functions, but as of CICS TS V4.2 (June 2011), the JVMServer can run Java programs using the Apache Software Foundation open-source Web service engine Axis2, and can also be used for customer-written applications using the Open Services Gateway initiative (OSGi).

CICS TS V4.1 provided the CICS Dynamic Scripting Feature Pack in June 2010, which is an implementation of Project Zero technology, and provides agile application development for situational Web applications. The Feature Pack serves Web artifacts, allows the use of the PHP and Groovy scripting languages, and has a model for quick implementation of database access for your situational applications, making it very easy to define and expose a database table with a REST interface. The Feature Pack is implemented in a CICS JVMServer and has a bridge to Java, which provides access to your CICS programs and resources.

In addition to Java as a CICS server-side programming language, Java clients running in a variety of non-CICS environments can invoke programs running in CICS. CICS Transaction Gateway provides a way to pass information from the Java client to CICS using the Java Enterprise Edition (JEE) Java Connector Architecture (JCA). Additionally, WebSphere Optimized Local Adapter (WOLA) provides cross-memory communication from a WebSphere® Application Server to CICS when both are running on the same z/OS® Logical Partition (LPAR).

When passing data between CICS-based programs running in different CICS-provided Java environments, or from Java client programs to CICS-based programs, you can use a communications area (COMMAREA) of up to 32K, or channels and containers to pass larger amounts of data (channels and containers were added in 2005). The COMMAREA and channels and containers are convenient for COBOL and other field-oriented languages supported by CICS, and these communication mechanisms enable a Java program to interact with procedural field-oriented languages running in a CICS environment. For applications implemented in multiple CICS-provided JVM environments, passing objects is not Java-friendly, since extra steps are required to use the CICS program-to-program communications mechanism.

For example, you may want to implement your Java-based business logic in a CICS-provided OSGi environment to take advantage of the capabilities and features of OSGi. You may want to expose some of these Java-based business functions as Web services using the CICS-provided Axis2 environment (which runs in a different JVM server). You may also want to quickly provide a Web interface to your OSGi-based business logic using CICS Dynamic Scripting (another JVM server), or provide access to your OSGi-based business logic to non-CICS Java clients using CICS Transaction Gateway (which runs in a JVM outside CICS).

This article proposes a Java-friendly way to pass objects between Java programs running in different JVMs in the CICS environment, or between CICS-provided Java environments in different CICS regions. The article provides background information on passing Java objects, and explains reasons for using the various Java environments provided by CICS.

Objective

The traditional way to pass data between application programs in a CICS environment is to place the data into a field-oriented series-of-bytes structure and place the structure into a COMMAREA or into a CICS container in a CICS channel. The COMMAREA or channel is then passed when the target program is invoked using an EXEC CICS LINK PROGRAM() command. For COBOL, IBM Assembler, and other CICS-supported languages, no marshalling of the data is required. However, for a CICS-based Java program, Java data objects must be marshalled and de-marshalled to and from a field-oriented series-of-bytes structure. Utilities are available to generate code to do the marshalling, and a COBOL data layout is used for input to the utilities. If you are using multiple programming languages in your CICS application, doing something special for Java is well worth the effort to enable CICS-based Java programs to interoperate with CICS programs written in other languages.

For Java programs running in a single CICS-provided Java environment, you use Java as usual, instantiating classes and invoking methods. If you want to use multiple CICS-provided Java environments to leverage the strength of each environment, you will want to get assistance from CICS to pass your Java data. For CICS-based Java applications that span multiple CICS-provided Java environments, you need a Java-friendly way to pass Java data objects between these environments. For a Java program accessing functions provided by a Java program in a different CICS-provided Java environment, it would be convenient for the Java programmer if passing data were as simple as the following code snippet:

String abc = "Some information to Pass";
Employee emp = new Employee("John Doe");
DDW_CicsObjectTransporter transporter = 
    new DDW_CicsObjectTransporter();
transporter.addObject("abc",abc)
.addObject("emp",emp)
    .execute("TARGET");

// and after the program return

String errorString = (String)transporter.getObject("error");
If (errorString != null) {
    processError();
} else {
    Manager newManager = (Manager)transporter.getObject("mgr");
    // process/display Manager object that was returned
}

For the responding Java program returning data, it would be convenient for the Java programmer if providing a response was as simple as:

DDW_CicsObjectTransporter transporter = 
    new DDW_CicsObjectTransporter();
Employee emp = (Employee)transporter.getObject("emp");
// work with employee object
transporter.removeObject("abc");    // can remove transport object
Manger mgr = new Manger("Joe Bloggs");
transporter.addObject("mgr",mgr);  // add new or changed objects
return;

Part 2 of this series shows you how to enable the above usage, and provides a sample Java class named DDW_CicsObjectTransporter that enables the above interaction to take place. Additionally, for use with transporting objects between a Java client using CICS TG and CICS TS, a DDW_CicsTg_ObjectTransporter object is provided.

Java environments provided by CICS

Each of the CICS-provided Java environments has its strengths, so you will probably want to use more than one for an application. As indicated above, the goal of this article series is to provide a framework to simplify passing Java objects between these various environments.

Pooled JVM

Since 1999, CICS has offered a pooled JVM environment. You specify the maximum number of JVMs that can exist in a pool, and CICS then uses the JVMs to run your CICS Java programs. In the pooled JVM environment, CICS dispatches one Java program at a time to a JVM. While this practice provides great program isolation, that is typically not a concern with Java programs, and the maximum number of Java programs that can run at one time in a CICS region is equal to the number of JVMs in the JVM pool.

When CICS receives a request, it starts a program to provide a response. You therefore need to define Java programs to CICS via a PROGRAM definition, where you specify the initial Java class to be invoked, the storage key in which you want to run (CICS or USER key), and a JVMProfile file that specifies the characteristics of the JVM needed for this program, including the CLASSPATH, LIBPATH, JVM heap sizes, DB2 driver, and so on.

When dispatching a Java program, CICS chooses a JVM from its JVM pool that matches the requirements specified in the program's PROGRAM definition (JVMProfile file and execution key). The Java program is then started in that JVM. Java program execution begins in the specified class in a method with a signature of public static void main(CommAreaHolder ca) or public static void main(String[] args).

Java programs interact with CICS using a Java equivalent to the EXEC CICS commands, referred to as JCICS classes. In addition to interacting with CICS resources and invoking CICS programs written in other languages, Java programs can interact with DB2 or WebSphere MQ and do other Java-specific work. Java programs should always use CICS facilities if they exist (such as CICS DB2 connections) so that CICS can control units of work -- one of the many areas in which CICS excels.

The memory for JVMs comes from the CICS region address space. CICS TS V4.1 or earlier use a 31-bit JVM and therefore 31-bit storage in the CICS region address space, which means that a relatively small number of JVMs can run under the control of a single CICS region. It is common to have multiple CICS regions service a common business function, so for situations where you need more concurrency than a single CICS region can provide, multiple Java Owning Regions (JORs) can be started and work dispatched in them. CICS TS V4.2 uses a 64-bit JVM that can reside above the bar in 64-bit storage, so several JVMs can exist in the JVM pool maintained by a single CICS region, thus lessening or removing the need for multiple CICS regions to service a larger Java workload.

In CICS TS V4.2, customer-written programs can now be run in a JVM server environment (discussed in the next section). In the CICS TS V4.2 announcement letter, IBM stated that the pooled JVM environment will be removed from CICS in a future release.

CICS JVM server environment

CICS TS V4.1 (June 2009) introduced the JVMSERVER resource, which provides a JVM server environment. This JVM server environment enables multiple CICS Java tasks to be dispatched to the same JVM at the same time. When defining a JVMSERVER resource, you specify the maximum number (1 to 256) of concurrent Java tasks that can be dispatched to a single JVM. You can run multiple JVM servers under the control of a single CICS region, but the total number of tasks dispatched to all JVM servers controlled by a single CICS region cannot exceed 1024. In CICS TS V4.1, the JVM server environment is only used by CICS Dynamic Scripting (discussed below), and by SupportPac CN11, which provides a batch container for the WebSphere XD Compute Grid. CICS TS V4.2 (June 2011) changes to a Java 6.0.1 64-bit environment, and adds an OSGi-based JVM server and an Axis2-based JVM server where user-written Java programs can be deployed.

OSGi-based JVM server environment

The OSGi-based JVM server environment in CICS TS V4.2 requires that Java programs are packaged using OSGi bundles. OSGi is a dynamic module system for Java and has been adopted by all major Java application servers. The modularity in OSGi provides a mechanism to divide a system into independent modules known as bundles, separately packaged and deployed, with each having their own independent life cycles. This modularity lets you divide a complex application into independent parts for easier development, testing, and maintenance.

Without OSGi, Java classes and JAR files are made available to a JVM by specifying a CLASSPATH environment variable. This CLASSPATH is static and doesn't change for the life of the JVM. With OSGi, Java classes can be added and removed dynamically from a JVM.

OSGi also provides an in-memory service registry where other modules can find and bind to registered services. Components made from modules can be published in the OSGi service registry, and from there, other modules can find and bind to those services. Components can expose all classes in a bundle or can expose specific interfaces. Likewise, a component can declare its dependencies on other packages or modules. A module can contain life cycle methods that are invoked as the module is installed, uninstalled, or upgraded. You can also provide extension points to let others extend your module's functionality.

One or more Java packages (containing classes) are grouped into an OSGi bundle. The CICS environment lets you group one or more OSGi bundles into a CICS BUNDLE. As the CICS BUNDLE is installed, enabled, disabled, and discarded, the OSGi bundles within the CICS BUNDLE go through the appropriate OSGi life cycle changes, thus enabling you to dynamically add and remove Java classes and packages in a running CICS JVM server. The life cycle state of an OSGi bundle and the CICS BUNDLE can be displayed using the CICS Explorer. The OSGi-based JVM server should be considered the strategic direction for Java-based business logic in CICS.

When CICS receives a request, CICS starts a program to provide a response. You therefore need to define Java programs to CICS via a PROGRAM resource definition. For a CICS-based Java program that is to run in a JVM server, you must define a PROGRAM definition specifying CONCURRENCY(REQUIRED), a storage key of CICS, the name of the JVMSERVER resource in which this program is to run, and the name of the OSGi registry entry that references the Java program.

When packaging your Java programs in an OSGi bundle, for those classes where CICS is to begin execution, you include a CICS-MainClass= keyword in the bundle's manifest that specifies the class where execution should begin. The CICS-MainClass= keyword causes the CICS OSGi environment to register the specified class in the OSGi registry. Like the pooled JVM, Java program execution begins in the specified class in a method with a signature of public static void main(CommAreaHolder ca) or public static void main(String[] args).

As with the CICS pooled JVM environment, Java programs interact with CICS using a Java equivalent to the EXEC CICS commands referred to as the JCICS classes. In addition to interacting with CICS resources and invoking CICS programs written in other languages, Java programs can interact with DB2 and WebSphere MQ, and do other Java-specific work. Java programs should always use CICS facilities if they exist (such as CICS DB2 connections), so that CICS can control units of work (which is one of the many areas in which CICS excels).

The memory for JVM servers comes from the CICS region address space. CICS TS V4.2 uses a 64-bit JVM, which can reside above the bar in 64-bit storage, so multiple JVM servers can exist in a single CICS region. CICS can dispatch between 1 and 256 concurrent tasks in a single JVMServer, with 15 being the default. The sum of all concurrent tasks in all JVM servers for a given region cannot exceed 1024.

Axis2-based JVM server environment

CICS has enabled exposing CICS-based programs as Web services since CICS TS V3.1 (March 2005), and before that using a SupportPac (March 2003) or via the SOAP Feature for CICS (September 2003). Web service support, initially provided with CICS TS V3.1, allows for exposing CICS programs that are invoked using the CICS COMMAREA or channels and containers (both discussed below).

As an additional option to expose Java-based CICS programs as Web services, CICS TS V4.2 (June 2011) includes Axis2, which is an open-source Web services engine from Apache provided with CICS to process SOAP messages in a Java environment. The use of Axis2 technology for Java-based Web services in CICS provides better utilization of the zAAP specialty processor. Java and XML parsing in some situations can be offloaded to a specialty processor like the System z Application Assist Processor (zAAP), instead of running the work on a general processor in an IBM mainframe.

Axis2 support in CICS lets you expose CICS-based Java programs and develop Axis2-style header handler programs in Java. Axis2 supports hot deployment of Web services and handlers, asynchronous Web services, Message Exchange Pattern (MEP) (part of WSDL 2.0), WSDL 1.1 and 2.0, and exposure of Plain Old Java Objects (POJOs) as Web services using the annotations that are part of JAX-WS. Tooling to build Axis2 artifacts is part of Java 6 Java Standard Edition (JSE).

CICS dynamic scripting

In June 2010, CICS provided the CICS Transaction Server Feature Pack for Dynamic Scripting. This Feature Pack runs in a JVM server and is an implementation of the Project Zero technology. The goal of Project Zero is to provide an agile programming environment that enables programmers to quickly implement situational applications, such as application for a temporary marketing effort or a tool to improve departmental or team productivity.

The CICS Transaction Server Feature Pack for Dynamic Scripting lets you quickly provide Web pages and write applications in PHP, Groovy, and Java. Because the Feature Pack is implemented in a Java environment, a bridge to Java is provided. From your PHP or Groovy program, you can instantiate Java classes and invoke methods on those classes. In addition to letting you tap into the power of Java, the Java bridge enables your PHP and Groovy scripts to use the JCICS classes and interface with CICS resources (JCICS classes are the Java equivalent of the EXEC CICS commands). Project Zero also provides the Zero Resource Model (ZRM) to provide a quick way to define tables and access data in those tables using either a REST interface or a simple API that centers on collections and members of those collections. You can also access database information using SQL, and the DB2 and Derby databases are supported.

CICS dynamic scripting applications are accessed via HTTP requests that ask for Web pages (HTML, JavaScript, or cascading stylesheets), the invocation of a PHP or Groovy script, or REST services.

Although you can write entire applications in PHP or Groovy, business logic in these applications can be accessed only via HTTP requests directed at a CICS dynamic scripting application. Therefore, best practice is to run your Java-based business logic in an OSGi-based JVM server so that the business logic can be accessed from any CICS facility or client using any of the CICS interoperability options. You can use CICS dynamic scripting to quickly provide a presentation layer for your OSGi-based business layer.

The CICS Transaction Server Feature Pack for Dynamic Scripting V1.0 runs in CICS TS V4.1, and the CICS Transaction Server Feature Pack for Dynamic Scripting V1.1 runs in CICS TS V4.2.

CICS Transaction Gateway

CICS Transaction Gateway (CICS TG) provides secure transactional communications to CICS from a variety of client programming languages such as C/C++, Java, Microsoft® .NET, Microsoft Visual Basic, PowerBuilder, and workstation-based COBOL.

For a Java client running in a non-CICS environment, CICS TG implements Java Connector Architecture (JCA), which defines a standard way to communicate from Java programs to Enterprise Information Systems (EIS) such as CICS, IMS, JDEdwards, PeopleSoft, and SAP. JCA defines a way to implement managed or non-managed connections using a standard API called the Common Client Interface (CCI). Using a managed connection, a Java Enterprise Edition (JEE) application server can provide connection management, control transactionality, and propagation of a security context. This standard CCI API lets a Java programmer use a common API to access different EIS's.

CICS TG can be set up in multiple configurations -- for more information, see CICS TG information center.

For a scenario where you have a CICS TG client program written in Java and your CICS server-side business logic also implemented in Java, you can use the techniques in this article to pass Java data objects from your CICS TG client program to the CICS-based Java program that implements your business logic.

Passing data between CICS programs

The CICS-provided techniques for passing data between CICS programs include passing a COMMAREA or passing a channel and containers.

COMMAREA

For most of the 40-year history of CICS, the standard way to pass data between programs that make up an application is a block of storage called a communications area (COMMAREA), which can be up to 32 KB. In the past, CICS primarily supported procedural languages such as COBOL and PL/I, in which you could simply define a field-oriented data layout of the COMMAREA. At runtime, the procedural-language program places data into the data layout and LINKs to another CICS program, passing the COMMAREA (a LINK is the CICS equivalent of a program call). The LINK approach was designed to enable passing data between CICS-based programs implemented in the same or different program languages that are running in the same or different CICS regions.

Figure 1 shows an example of programs passing a COMMAREA. Although very convenient for procedural languages that work with fixed-size fields where the total size of data to be passed is less than 32KB, the COMMAREA is not a convenient way to pass data for Java programs. The closest construct that Java has to this field-oriented series-of-bytes is a byte array. But a Java byte array doesn't include the notion of accessing bytes 75 through 100, for example, via a name such as customerAddress. Tools such as the JZOS utilities supplied with IBM z/OS Java and wizards in Rational Application Developer let you generate a Java data object from a COBOL data layout. These tools and wizards are a good solution if you need to move between Java and another programming language in CICS. They provide Java getters and setters for each field in the construct, and have a getBytes()/setBytes() or getByteBuffer()/setByteBuffer() method when the Java program needs to pass data to or get data from CICS.

When passing data between Java programs, if you are staying in a single CICS Java environment, you use the normal Java approach of instantiating an object (such as CheckingAccount), and invoking methods on that object (such as computeInterest(). If your Java application spans different CICS Java environments or your Java-based application spans multiple CICS regions, then your application can invoke the various Java programs in these different CICS-provided Java environments using the CICS LINK command. Using the COMMAREA is one way to pass data between these Java programs, but it does require a transition from Java objects to a field-oriented series-of-bytes structure (a byte array). Also, when LINKing to the target Java program running in a different CICS Java environment, you need to transition from the byte array to one or more Java objects in the LINKed-to target Java program.

Java programmers can serialize objects they wanted to pass (which causes the object to be turned into a byte array), pass the serialized object via the COMMAREA, and deserialize the object in the target Java program. However, you may want to pass multiple objects and you may need to exceed the 32KB limitation. Additionally, the COMMAREA normally has the same length when sent in either direction.

Using a COMMAREA for inter-program communication

Channels and containers

As of CICS TS V3.1 (March 2005), for program-to-program communications, you can now place large amounts of data into a set of named containers associated with a specific channel. You can place any number of containers in a given channel, and then pass the channel (with all of its containers) to the target program, as shown in Figure 2. CICS doesn't limit the size of containers or the number of containers in a channel. However, there are practical limitations depending on your transaction arrival rate and mix of programs, since the space for containers comes from your CICS region storage. As a general rule, you should use the containers that your application needs, but don't get sloppy and waste space or your application may inadvertently cause a CICS short-on-storage condition.

Using channels and containers for inter-program communication

You can see from Figure 2 that containers have a name and can be any size. You can't really see it from figure 2, but if a container is sent from program A to program B and not modified by program B, then CICS knows that the container doesn't need to be returned to program A because program A already has a copy of the container contents. If program B receives a container from program A, program B can change the data in and size of the container. For procedural programming languages, each container can have its own data layout consisting of 0 or more fields. When passing data between Java and procedural languages, you can use the JZOS utilities or Rational Application Developer wizards to generate a Java object from the container layout defined in COBOL. These generated Java objects let you access the data from Java using getters and setters and from your procedural language using the normal procedural field-oriented data layout. The JZOS utilities and Rational Application Developer wizards were described above under "COMMAREA."

There are two types of containers: CHAR and BIT. CHAR containers are intended for character data, and CICS can perform code-page conversion on CHAR containers if requested. BIT containers are intended for binary data, similar to a Java byte array.

You can also see from Figure 2 that channels and containers can be viewed as an associative array similar to a Java hashtable, where the channel is like an array of containers. You can access a container's contents by asking for the container by name.

If you are using a Java client in a non-CICS environment to interact with a CICS-based program, using CICS TG V7.1 or later, using IPIC as the communications type, and communicating to CICS TS V3.2 or later, your Java client can also use channels and containers.

Passing Java objects between CICS Java programs

Based on the information so far, you have probably concluded that if your objective is to pass data from one Java program running in a CICS-provided Java environment to a Java program running in a different CICS-provided Java environment, you could simply pass serialized Java objects using CICS channels and containers. This procedure avoids:

  • Creating a COBOL copybook layout for the data to be passed from between Java programs
  • Running utilities to create a Java data object from the COBOL copybook
  • The need for the Java programmer to understand COBOL
  • The need to maintain the required COBOL copybooks in your source repository
  • The need to perform production turnover on the COBOL copybook
  • The need to update the COBOL copybook if the contents of the passed data changes (and the need to go through the subsequent repository updates and production turnover)

The concepts of object serialization are well understood by the average Java programmer, and there are several examples of the Java code for object serialization on the Internet. Serializing Java objects and passing them in channels and containers provides a straightforward mechanism to pass Java objects between CICS-based Java programs running in the various CICS-based Java environments (or between Java environments controlled by different CICS regions). The LINKing CICS-based Java program (or CICS TG client Java program) can serialize the Java objects to be passed into a series of containers. The LINKed-to Java program can then deserialize the objects, modify them as needed, serialize the modified objects back into a container, and pass it back to the LINKing program.

If you are working with Java classes in a single CICS-based Java program, you work with them as normal -- you instantiate the object and invoke the object's methods. Transporting Java objects between CICS Java environments is needed only if you want to move data between the different CICS Java environments to leverage their individual strengths, if you want to move data to a CICS Java environment in a different CICS region, or if you want to spread your application across multiple CICS Java environments for workload management or application availability.

Part 2 of this article series will show you how to use channels and containers to pass Java data objects, and describe a generalized framework for passing data between CICS applications. Part 2 will also provide Java classes that perform the Java object serialize, deserialize, and LINK functions, letting you concentrate on the Java aspects of your application and not on the details of passing Java objects between the various CICS Java environments.

Conclusion

This article described the different Java environments that CICS provides:

  • The traditional pooled JVM, where only one CICS-based Java transaction runs in a JVM at a time.
  • The CICS JVM server environment, where multiple Java program requests can be dispatched to the same JVM at the same time. Here are the CICS-provided Java environments that use the JVM server (but can't be mixed into a single JVM server):
    • The OSGi-based environment, which provides the OSGi dynamic module system with functionality such as dynamically adding and removing Java classes to the JVM, providing the OSGi registry, exposing only the interfaces to your Java module instead of all classes in the module, and specifying module dependencies to almost eliminate typical ClassNotFound problems.
    • The Axis2 open-source Web service engine, which lets you expose a POJO quickly and easily using JAX-WS annotations, and write handlers in the Axis2 style.
    • CICS Dynamic Scripting, which provides a quick way to develop Web applications using the PHP and Groovy scripting languages. The PHP and Groovy interpreters are implemented in Java, so there is a Java bridge to let you instantiate Java objects and invoke CICS programs
  • CICS Transaction Gateway, which facilitates communications from a Java program running in a non-CICS environment to a CICS TS program.

The article also described the two ways to pass data between CICS-based programs:

  • COMMAREA -- A single block of data up to 32 KB
  • Channels and containers -- Multiple named blocks of data of any length (containers) that are grouped in a named channel

Finally, the article described passing Java data objects between the various CICS-provided Java environments by using the normal CICS channel and containers mechanism, and placing serialized Java data objects into the containers and then deserializing them as needed.

Acknowledgements

The author would like to thank the following IBM colleagues for their help in reviewing this article and providing suggestions for content and improvement:

  • Steve Fowlkes, Certified IT Specialist, CICS Technical Support, IBM USA
  • Leigh Compton, Certified IT Specialist, CICS Advanced Technical Skills Team, IBM USA
  • Mark Cocker, CICS Technical Strategy and Planning, IBM UK
  • Phil Wakelin, CICS Technical Strategy and Planning, Java and Access to CICS, IBM UK

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Java technology
ArticleID=784130
ArticleTitle=Passing data objects between CICS Java environments: Part 1: CICS Java environments
publish-date=01042012