Passing data objects between CICS Java environments: Part 3: Transporting Java data objects from a CICS transaction Java client program to a CICS TS Java program

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 three-part article series gives you the details. Part 3 describes the API that enables CICS TG Java client programs to interact with a CICS TS program. It also provides an object transporter that you can use in a CICS TG Java client along with the wizards in Rational Application Developer to generate code to communicate from a CICS TG Java client to a CICS TS program.

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.



08 February 2012

Also available in Russian

Introduction

Part 1 of this three-part series described the different Java™ environments that IBM® 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 (CICS TG), which facilitates communications from a Java program running in a non-CICS environment to a CICS Transaction Server (CICS TS) program.

As you would expect, if you are working with Java classes within a single CICS-based Java program, you work with them as normal: you instantiate the object and invoke the object's methods. However, when your application is coded in Java, but you want to leverage the strengths of the different CICS-provided Java environments, or you want to distribute parts of your Java-based application over multiple CICS regions, using a Java-like approach to transporting Java data objects is preferable to the traditional series-of-bytes field-oriented approach to transporting data. This traditional approach to passing data is needed and performs well if you are using multiple programming languages, which is one of the strengths of CICS.

Part 1 described that the CICS version of a call, the EXEC CICS LINK command, which lets you invoke another program written in the same or a different programming language in a CICS environment. The CICS-architected facilities for passing data between CICS programs are the COMMAREA and channels and containers. The COMMAREA is a block of storage up to 32 KB, while a container is a named block of storage with no size limit. Containers are grouped into a channel, which can be passed from one CICS program to another. The COMMAREA, and channels and containers are mutually exclusive -- a program can receive data using only one of the two techniques at a time. When you LINK from program A to program B, program A can pass a COMMAREA or a channel, but not both.

When passing data between CICS programs, you usually place the data in a field-oriented series-of-bytes structure. Programs written in Java can participate in this environment, but when your CICS-based application is only using Java, a Java application programmer will find it more convenient to stay in the object-oriented Java world and pass Java data objects between your CICS-based Java programs. So Part 1 concluded that if a CICS-based application is only written in Java, and you need to move from one CICS Java environment to another, it is simpler to stay in a Java paradigm and pass Java data objects between the CICS-based Java environments. You can do that by serializing a Java data object into a CICS container, passing the container to another Java program running in a different CICS Java environment, and then deserializing the object in the target Java program.

Parts 1 and 2 discussed why a Java programmer would find it easier to pass Java data objects between CICS-based Java programs instead of the traditional CICS field-oriented series-of-bytes that you would use to pass data between programs implemented in different programming languages. Part 2 described a technique for passing Java data objects that uses object serialization, the CICS-provided Java API to place data into and get data out of CICS containers, and the CICS-provided Java API to LINK from one CICS program to another. Part 2 also provided sample Java classes that showed you how to write a generalized Java object that can transport Java data objects between different CICS Java environments. The technique described in Part 2 enables Java data objects to be passed between CICS-provided Java environments using the following coding approach:

     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
     }

Here is some sample code for the responding Java program to return data:

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

A CICS TG Java client program can communicate to a CICS TS environment using channels and containers, so the same technique described in Part 2 for passing Java data objects between CICS TS-provided Java environments can be used to pass Java data objects between a CICS TG Java client program and a Java program running in CICS TS. You can even use the same object transporter class on the CICS TS side, but you need a different implementation of the object transporter on the CICS TG Java client side to accommodate the differences in the CICS TG programming API.

This article (Part 3), describes the API that enables CICS TG Java client programs to interact with a CICS TS program. It also provides an implementation of an object transporter that you can use in a CICS TG Java client along with the wizards in Rational Application Developer and Rational Developer for System z to generate code to communicate from a CICS TG Java client to a CICS TS program.

The wizards provided with Rational Application Developer normally take a COBOL copybook as input and generate code to marshal the data to be passed into a COBOL-like field-oriented series-of-bytes. The two major advantages of this approach are that your CICS TG Java client program can pass data to a COBOL, PL/I, C, C++, Java, or Assembler program running in CICS TS, and this approach is fast. However, if both the client- and server-side programs are in Java, it will be easier for a Java application programmer to use a Java-like paradigm and pass Java data objects between the Java client and Java server programs. This article shows you how to use the provided object transporter with the Rational Application Developer wizards, giving you the benefits of code generation from the wizards and the convenience for the Java application programmer of passing Java data objects.

As described previously, the goal of this article series is to make it convenient for the Java application programmer to pass data objects between the different CICS-provided Java environments. Since there is some overhead to serializing and deserializing Java objects, you will need to benchmark your application to verify that this approach to passing Java data objects performs acceptably for your application. For more information on issues associated with Java object serialization, see Part 2.

CICS Transaction Gateway

CICS TG provides secure transactional communication to CICS from a variety of client programming languages, such as C#, Java, Microsoft® .NET, Microsoft Visual Basic, PowerBuilder, and workstation-based COBOL to a program running in CICS TS.

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 (EISs) 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 EISs.

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 Java objects from a CICS TG Java client to a CICS-based Java program

Two APIs are available for working with the CICS TG and channels and containers: the original API provided when CICS TG first started supporting Java around 1996, and the JCA API (also called the Common Client Interface or CCI) that was added later. Although both APIs support channels and containers, this article focuses on the CCI because it is the strategic API for CICS TG. For additional details on using CCI with CICS TG, see the IBM Redbook Developing connector applications for CICS, and the two developerWorks articles by Phil Wakelin: Exploiting the J2EE Connector Architecture and Exploiting CICS channels and containers from Java clients.

When writing a CICS TG Java client using the CCI, you work with an ECIChannelRecord, which represents a channel and contains methods to work with the containers in a channel. The ECIChannelRecord is used in CICS TG Java client programs instead of the Channel and Container classes that were discussed for CICS TS programs in Part 2.

The ECIChannelRecord contains methods to put(), get(), and delete() containers, whereas for CICS TS, the put() and get() methods are used with a Container object, and you delete containers with a deleteContainer() method. Additionally, error checking is different between the CICS TG methods and the CICS TS methods. There are two types of containers: BIT and CHAR (described in Part 1). How you create and access a BIT versus a CHAR container using the CICS TG-provided ECIChannelRecord is different from using the CICS TS-provided Channel object. Also, with a CICS TS Java program you use a Program object and a link() method to invoke a program, but from a CICS TG Java client program, you use the execute() method on an Interaction obtained from a Connection (more on this in a few paragraphs).

The object serialization and deserialization is the same for any Java implementation, so you can use the same serialization and deserialization code in the CICS TG and CICS TS object transporters. The methods to get, add, and delete Java objects are similar for both object transporters, which provides a consistent interface to both transporters. But the underlying interactions with the Channel / Container objects versus the ECIChannelRecord object is quite different.

The DDW_CicsObjectTransporter (provided with Part 2) provides a thin façade on top of the existing CICS TS channel and container infrastructure. For the CICS TG object transporter, the ECIChannelRecord was extended into a DDW_CicsTg_ObjectTransporter, which allows the DDW_CicsTg_ObjectTransporter to be used anywhere an ECIChannelRecord can be used, including both the CCI and the Rational Application Developer wizards. Examples of both are provided below.

Using the CCI in a CICS TG Java client program

If you, as a CICS TG Java client programmer, were to code to CCI yourself instead of generating code using the Rational Application Developer wizards, it would look similar to the code snippet below. The CCI is straightforward: You create a connection object or get one from a pool of connections. From the connection, you create an Interaction, and use the execute() method of the Interaction to invoke the back-end program. These parts of the CCI are the same regardless of your back-end system -- CICS, IMS, JDEdwards, and so on.

The part of the CCI that is different depending on the back-end system is the interaction specification (the specifics of the interaction) and the format of the data being passed. To invoke a CICS-based program, the interaction specification is an ECIInteractionSpec, which contains the name of the CICS program to be invoked, the userid and password, and other specifics of the interaction with the CICS-based program. In the code sample below, you pass an ECIChannelRecord that contains the containers to be passed or retrieved from the CICS TS program. The channel and container mechanism is specific to CICS TS and is not used with other EISs:

ConnectionFactory cf = createAConnectionFactory();  // non-managed connection
Connection conn = cf.getConnection();
Interaction interaction = conn.createInteraction();
byte [] someBytes = "some characters".getBytes();   // bytes for container 
ECIChannelRecord myChannel = new ECIChannelRecord(CHANNEL_NAME);
myChannel.put(REQUEST_INFO_CONTAINER, someBytes);  // BIT container
ECIInteractionSpec ixnSpec = getMyECIInteractionSpec();
interaction.execute(ixnSpec, myChannel, myChannel);  // invoke the target program

In the above code, note the ECIChannelRecord object that represents the channel, and the put() method of the ECIChannelRecord, where you specify both the name of the container and its contents. When you put a byte array in a container in the ECIChannelRecord, it becomes a BIT container. Neither CICS TS nor CICS TG will do any conversion on BIT containers. At the top of the code segment, you create a connection factory for a non-managed connection for simplicity in the code example. In a WebSphere Application Server or WebLogic Java program, you would get a connection from a connection pool maintained by the application server using a JNDI lookup. When using a connection pool maintained by the application server (called a managed connection), the application server can assist with maintaining the pool of connections, controlling transactionality, and propagating a security context to the CICS TS-based program.

In the code sample above, you delegate the construction of the ECIInteractionSpec to a method named getMyECIInteractionSpec(). This method creates an ECIInteractionSpec and assigns the appropriate properties (CICS TS program name, userid, password, and so on). For more information on the creation of an ECIInteractionSpec, see the CICS TG information center and the two developerWorks articles by Phil Wakelin: Exploiting the J2EE Connector Architecture and Exploiting CICS channels and containers from Java clients.

Using the DDW_CicsTg_ObjectTransporter with the CCI

To use the DDW_CicsTg_ObjectTransporter class to pass Java objects to a CICS TS Java program, the above code would look as shown below, since the DDW_CicsTg_ObjectTransporter class extends ECIChannelRecord. Everything is the same with the CCI -- the only difference is that the addObject() method of the DDW_CicsTg_ObjectTransporter class is used to serialize the specified Java object and add it to a container. The execute() method specifies the object transporter, which is allowed since it extends ECIChannelRecord. Upon return from the CICS TS Java program, use the getObject() method of the object transporter to access the returned Java data object.

DDW_CicsTg_ObjectTransporter transporter = new DDW_CicsTg_ObjectTransporter();
String inputData = "12345";
transporter.addObject("inputData", inputData);
// and 
ConnectionFactory cf = createAConnectionFactory();  // non-managed connection
Connection conn = cf.getConnection();
Interaction interaction = conn.createInteraction();
ECIInteractionSpec ixnSpec = getMyECIInteractionSpec();
interaction.execute(ixnSpec, transporter, transporter);  // invoke target program
// and
String responseData = (String)transporter.getObject("responseData");

As before, in the code sample above, delegate the construction of the ECIInteractionSpec to a method named getMyECIInteractionSpec().

in any coding example that uses an ECIChannelRecord, you could use the DDW_CicsTg_ObjectTransporter.

Using the DDW_CicsTg_ObjectTransporter with the Rational Application Developer wizards

Although as you have seen above, the CCI API is straightforward, use of the J2C wizards in Rational Application Developer is quite popular. They use an ECIChannelRecord, so by having the DDW_CicsTg_ObjectTransporter extend the ECIChannelRecord, you can use the DDW_CicsTg_ObjectTransporter with the Rational Application Developer wizards.

Also with the Rational Application Developer wizards, you can generate an object that uses an unmanaged connection (as shown in the above code snippets), or gets a CICS TG connection from a connection pool provided by your Java Application Server (such as WebSphere Application server or WebLogic). Using a CICS TG connection pool provided by your Java application server lets you leverage your Java application server's ability to provide CICS TG connection pool management, provide transactionality, and propagate a security context to CICS.

The detailed steps to use the Rational Application Developer wizards are listed below, but at a high-level, you can copy the provided DDW_CicsTg_ObjectTransporter class to your project in Rational Application Developer, invoke the J2C => J2C Bean wizard, and:

  1. Specify if you are using a managed or non-managed connection. If managed, specify the JNDI name of the CICS TG connection pool.
  2. On the second page of the wizard, specify your project name, the name of the package to contain the generated code, and the interface and implementation name of the generated code.
  3. On the third page of the wizard, specify the name of the method to be added to the generated code. Click Add to bring up a sub-wizard where you specify the class name, and for input, specify the DDW_CicsTG_ObjectTransporter.
  4. On the next page, specify the target program name to be invoked on CICS TS as the function name, and then click Finish.

The next section shows you how to use the DDW_CicsTg_ObjectTransporter with the Rational Application Developer J2C wizards. The wizards are not installed into Rational Application Developer by default -- you must ask for them to be installed or added.

  1. Create a Java project or a dynamic Web project and give it a name such as CICSTG-FUNDPROG-Client.
  2. Copy the com.ibm.ddw.cicstg.object.transporter.DDW_CicsTg_ObjectTransporter and the com.ibm.ddw.cicstg.object.transporter.DDW_CicsTg_ObjectTransporterException (both are provided with this article) into your project. You may have some unresolved references to some J2C classes. The DDW_CicsTg_ObjectTransporter cannot be seen by the J2C wizards unless all references are resolved. You can resolve the references in a few different ways:
    • If you have a CICS TG ECI adapter project already in your workspace (the name of the project will be something like cicseci8001), then you can add that project to your project's build path: Right-click on your project and from the context menu, select Build Path => Java Build Path. Under the Projects tab, add the CICS TG ECI adapter project to your project's build path.
    • If you don't have the CICS TG ECI adapter project already in your workspace, you can add the CICS TG ECI adapter project by running through the J2C Bean wizard and creating a dummy implementation. You can then delete the classes for the dummy implementation.
    • To make a dummy implementation, right-click on your project and select New => Other, then select J2C => J2C Bean. On the Resource Adapter Selection page, select the ECIResourceAdapter and then click Next. On the Connector Import page, specify a Target server of WebSphere Application Server V7.0 and then click Next. On the Connection Properties page, specify a Managed or non-managed connection, depending on your desired environment. On the J2C Java Bean Output Properties page, specify a dummy package and a dummy interface name, and then click Finish. After the wizard completes you should have a CICS TG Adapter project in your workspace with a name something like cicseci8001, and that project should be in your project's build path. Delete the generated dummy package, interface, and impl class.
  3. After using either of the above approaches to resolve the references in the DDW_CicsTg_ObjectTransporter class, the following items should be in your workspace:
  4. Now that you have a CICS TG ECI Adapter project and it is in your project's build path, you can generate your real interface and implementation class.
  5. Right-click on your project and select New => Other. From the Select a wizard dialog select J2C => New J2C Bean, and then click Next.
  6. From the New J2C Bean dialog, select the CICS ECIResource Adapter project that was either already in your workspace or the one you created above:
  7. From the Connections Properties page of the New J2C Bean dialog, specify whether you want a managed or non-managed connection and the connection characteristics, and then click Next. Configuration of CICS TG is beyond the scope of this article -- for more information, see the CICS TG information center.
  8. From the J2C Java Bean Output Properties page of the New J2C Bean dialog, specify the name of package that will contain the generated classes. This article used com.ddw.cicstg.test for the package name with an interface name of FUNDPROG. Then click Next. FUNDPROG is also the name of the CICS-based program you are invoking. The name of the actual CICS TS program to be invoked is specified in a later step.
  9. On the Java Methods page of the New J2C Bean dialog, click Add to specify the name of the method that will be generated into your J2C Bean. Click Add to open the Java Method dialog.
  10. On the Java Method dialog, specify the name of the method that will be generated into your J2C Bean. This article used invokeProgram. Click Browse across from Input type.
  11. In the Select a data type wizard, type ddw at the top, then select DDW_CicsTg_ObjectTransporter and click OK.
  12. Back on the Java Method page, click Finish: .
  13. Back on the Java Methods page, specify the name of the CICS program to be invoked as the Function name (in our case it is FUNDPROG), and then click Finish.

Writing a CICS TG Java Client Program using the implementation generated from the J2C Wizards

Assuming that when you ran the Rational Application Developer wizard, your implementation (generated object) name was FUNDPROGImpl, and the method name you specified to be added was invokeProgram(), you could invoke the generated implementation code from your CICS TG Java client program using the following code snippet:

DDW_CicsTG_ObjectTransporter transporter = new DDW_CicsTG_ObjectTransporter();
String inputData = "12345";
transporter.addObject("inputData", inputData);
FUNDPROGImpl fundProg = new FUNDPROGImpl();  
// pass a transporter, receive a transporter
transporter = fundProg.invokeProgram(transporter); // invoke CICS TS program
String responseData = (String)transporter.getObject("responseData");
// work with the response data

Taking this approach has several advantages:

  1. If you specify a managed connection, the code generated by Rational Application Developer uses the Java application server's capability to manage a pool of CICS TG connections, control transactionality (if you used the ECIXAResourceAdapter), and propagate a security context.
  2. The generated code uses the JCA CCI API under the covers so that you don't need to know the details of the CCI API.
  3. Your CICS TG Java client program doesn't have to deal with the details of the CICS TG connection.
  4. And best of all, you can use the CICS TG object transporter from your CICS TG Java client program. The above example passes only one object, but you can pass as many objects as you need to and you are not limited to the object type (as long as the objects implement the Serializable interface, as described in Part 2).

Receiving Java objects into a CICS pooled JVM or a CICS OSGi-based JVMServer

The following code snippet can be used to receive Java objects from the CICS TG Java client into a CICS TS-based Java program running in a CICS pooled JVM or a CICS OSGi-based JVM server.

DDW_CicsObjectTransporter transporter = new 
     DDW_CicsObjectTransporter();
String inputData = (String)transporter.getObject("inputData");
// work with inputData object
String responseData = "Whatever the response data is";
transporter.addObject("responseData", responsedata); // new object
return;

The above code uses the DDW_CicsObjectTransporter class supplied with Part 2. All details associated with the DDW_CicsObjectTransporter were discussed in Part 2.

Performance

There is overhead associated with object serialization and deserialization. When using the provided object transporter, benchmark your application early in the development life cycle to verify that your application has the performance characteristics you need. Although passing data between CICS-based Java programs using the traditional field-oriented series-of-bytes approach requires the Java application programmer to run additional utilities and know some details of a procedural language such as COBOL or PL/I, this traditional field-oriented series-of-bytes approach to passing data may perform better.

Error-checking was added to the sample transporter provided with this article and most of the error checking is enabled by default. To improve the performance of the provided transporter sample code, you can use the methods listed below to disable some of the error checking. Also, by default, when version mismatch errors are detected, a warning is issued and the transporter continues to function. If you would like the transporter to become disabled if a remote transporter at a different level is detected, use the setStopTransporterActivityIfLocalRemoteVersionsDifferent(true) method.

setCheckForTransporterErrorsInChannel(false);
     // don't check for errors from previous requests
setCheckForSerialVersionUIDBeforeSerialization(false);
     // don't take time to check for serialVersionUID field on objects to be serialized
setCheckTheTransporterLevelWithWhichWeAreCommunicating(false);
     // don't take time to check if local and remote transporter are at same level

As indicated before, only use the object transporter when moving between CICS-based Java environments. When staying within a single CICS-based Java environment, use normal Java programming, instantiating objects and invoking methods.

The DDW_CicsTg_ObjectTransporter class is intended to implement a technique familiar to the Java application programmer, and to make passing objects simple. Since the object transporter is so easy to use for a Java application programmer, it is easy to get sloppy. If you pass objects that contain more information than you need to pass, or the objects you pass reference other objects that don't need to be passed, you will be wasting time needlessly serializing data and transferring extra data, both of which will decrease performance.

Debugging object-passing issues

For information on this topic, see Part 2.

Conclusion

This article (Part 3 of 3) showed you how to pass Java data objects from a CICS TG Java client to a CICS TS-based Java program running in an OSGi JVM server environment or in a CICS pooled JVM environment.

  • Since CICS TG lets you pass a channel and containers, the same approach of passing serialized objects discussed in Part 2 can be used with CICS TG.
  • Although CICS TG can work with a channel and containers, the API used in a CICS TG client program to interact with the channel and containers is different from the API used in a CICS TS-based Java program.
  • Communications between your CICS TG Java client program and a CICS program uses the JCA CCI API. You can code to the CCI API directly or you can use wizards in Rational Application Developer to generate code that implements the communications. The generated code can leverage an application server's capability to control a pool of connections to a CICS region, control transactionality, and propagate a security context.
  • This article provides a DDW_CicsTg_ObjectTransporter class that you can use in a CICS TG Java client program that can interoperate with a DDW_CicsObjectTransporter in a CICS TS-based Java program to enable passing Java data objects.
  • The article provides code samples that use the DDW_CicsTg_ObjectTransporter with the CCI API, as well as detailed steps on how to use the DDW_CicsTg_ObjectTransporter with the J2C wizards in Rational Application Developer.
  • Although the DDW_CicsTg_ObjectTransporter and the DDW_CicsObjectTransporter classes should work fine, they have not been submitted to official IBM testing and therefore should be considered "as-is" code, and intended only to illustrate the concepts in this article series.

For your CICS-based applications that are solely implemented in Java, give the object transporter a try and see if you agree that this approach provides a Java-friendly way to pass Java data objects between CICS-provided Java environments. This approach does involve object serialization and deserialization and its related overhead, so benchmark your application to verify that this approach to passing Java data objects performs as needed for your application.

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:

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

Download

DescriptionNameSize
Code samplecom.ibm.ddw.cicstg.object.transporter.zip15 KB

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=792360
ArticleTitle=Passing data objects between CICS Java environments: Part 3: Transporting Java data objects from a CICS transaction Java client program to a CICS TS Java program
publish-date=02082012