When developing a Java program to link to a CICS COBOL program with a COMMAREA or to access a VSAM file, you will typically need to map the data fields from a record structure to specific Java datatypes. This article describes a batch process to automate the generation of Java helper classes from a COBOL copybook using the new IBM Record Generator for Java V3.0 and then shows how to use the generated Java classes in a CICS Java application.

IBM Record Generator for Java

The Record Generator is a scriptable Java based utility that takes as input the ADATA from the COBOL compiler, and uses this to generate Java helper classes to access the fields in a COBOL record structure. The ADATA provides additional program data that can be used to extract information about the program for symbolic debugging or cross-reference tools. The Record Generator is based upon function in the IBM JZOS Toolkit which provides field converter classes for mapping byte array fields into Java data types.

Record Generator

Note: IBM Record Generator for Java V3.0 is a new IBM program product generally available as of 29th Sept 2017 and supersedes the IBM alphaWorks version of the JZOS Record Generator V2.4.6, which is now withdrawn. The Record Generator for Java, V3.0, provides the following new and enhanced functions:

  • Support for ADATA files with or without an IBM Record Descriptor Word (RDW) prefix making it easier to transfer the ADATA files from z/OS to distributed platforms.
  • Support for a user-supplied, Java name generator class to control the schema for generating accessor methods from field names
  • Support to ignore OCCURS 1 on COBOL single element arrays, so that fields are generated as an array of size 1
  • Ability to set the string encoding during record generation
  • A set of new generation options to optimize the generated code
  • A new IBM Knowledge Center

The Record Generator for Java V3.0 is freely available to download for all users of z/OS V2.1, or later. License redistribution rights are provided for deployment to non-z/OS platforms to support distributed development and build.



The following steps will be covered in this article

  1. Setup of the environment
  2. Using the Record Generator to create a Java record wrapper class from a COBOL structure
  3. Development of a CICS Java program to use the record wrapper
  4. Deployment of the Java components into a CICS OSGi JVM server

 

1. Setup

First of all you will need to perform the following prerequisites.

  • Download the Record Generator zip archive from the download site
  • Extract ibm-recgen.jar and transfer this to a directory on your zFS as this will be required by the batch job to generate records from the COBOL source.
  • Download the EDUPGM CICS COBOL sample if you want to deploy the example from this tutorial.

 

2.1 Creating the COBOL build job

The first step in creating a record is to modify the compile process to produce ADATA output. To produce the ADATA you simply need to add the ADATA keyword to the COBOL PARM statement and then direct the output to a pre-allocated SYSADATA dataset. This ADATA dataset will then be used as input for the Java record generation in the next step.

Next, if required, link edit the load module for deployment into CICS. The following JCL provides a sample COBOL V5.1 compile job with the ADATA PARM option and SYSADATA DD, based on the sample in the CICS translate and compile job DFHZITCL.

 

//ASMCOBJ JOB (H251620-TSOO),CLASS=A,MSGCLASS=T,NOTIFY=&SYSUID,
// MSGLEVEL=(1,1),REGION=500M
//  SET PROG='EDUPGM'                                               
//COBOL  EXEC PGM=IGYCRCTL,REGION=200M,                               
//            PARM=(NODYNAM,RENT,LIST,MAP,XREF,ADATA,                 
//            'CICS(''SP,COBOL3'')')                                  
//STEPLIB  DD DSN=PP.COBOL390.V510.SIGYCOMP,DISP=SHR                  
//         DD DSN=CICSTS.530.SDFHLOAD,DISP=SHR         
//SYSLIB   DD DSN=USER.CICS.DSECT,DISP=SHR                         
//         DD DSN=USER.CICS.COPY,DISP=SHR                          
//         DD DSN=CICSTS.530.SDFHCOB,DISP=SHR          
//         DD DSN=CICSTS.530.SDFHMAC,DISP=SHR          
//         DD DSN=CICSTS.530.SDFHSAMP,DISP=SHR         
//SYSADATA DD DSN=USER.CICS.COBADATA(&PROG),DISP=SHR               
//SYSPRINT DD SYSOUT=A                                                
//SYSLIN   DD DSN=&&LOADSET,DISP=(MOD,PASS),                          
//            UNIT=SYSDA,SPACE=(TRK,(3,3))                            
//SYSUT1   DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT2   DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT3   DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT4   DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT5   DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT6   DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT7   DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT8   DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT9   DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT10  DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT11  DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT12  DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT13  DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT14  DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSUT15  DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSMDECK DD UNIT=SYSDA,SPACE=(CYL,(1,1))                            
//SYSIN    DD DSN=USER.CICS.SOURCE(&PROG),DISP=SHR           
/*                                                                     
//COPYLINK EXEC PGM=IEBGENER,COND=(7,LT,COBOL)                         
//SYSUT1   DD DSN=CICSTS.530.SDFHSAMP(DFHEILID),DISP=SHR
//SYSUT2   DD DSN=&&COPYLINK,DISP=(NEW,PASS),                          
//            DCB=(LRECL=80,BLKSIZE=400,RECFM=FB),                     
//            UNIT=SYSDA,SPACE=(400,(20,20))                           
//SYSPRINT DD SYSOUT=A                                                 
//SYSIN    DD DUMMY                                                    
//*                                                                    
//LKED   EXEC PGM=IEWL,REGION=200M,                                    
//            PARM='LIST,XREF,RENT,MAP',COND=(7,LT,COBOL)              
//SYSLIB   DD DSN=CICSTS.530.SDFHLOAD,DISP=SHR          
//         DD DSN=PP.ADLE370.ZOS201.SCEELKED,DISP=SHR                  
//SYSUT1   DD UNIT=SYSDA,DCB=BLKSIZE=1024,                             
//            SPACE=(1024,(200,20))                                    
//SYSPRINT DD SYSOUT=A                                                 
//SYSLIN   DD DSN=&&COPYLINK,DISP=(OLD,DELETE)                         
//         DD DSN=&&LOADSET,DISP=(OLD,DELETE)                          
//         DD DDNAME=SYSIN                                             
//SYSLMOD  DD DSN=USER.CICS70.LOADLIB,DISP=SHR                      
//SYSIN    DD *                                                        
    NAME &PROG(R)                                                   
/*                                                                    

 

2.2 Building the Java record

Now create a job step using BPXBATCH to invoke the Java RecordClassGenerator utility class from the ibm-recgen.jar using the ADATA as the input and naming the desired COBOL structure. In the example below we used the ADATA in the input PDS USER.CICS.COBADATA from step 2.1, and generated a record com.ibm.cicsdev.bean.JZOSCommareaWrapper.java. This wrappers the DFHCOMMAREA structure from our EDUPGM COBOL program. The inputs to the job are parameterized to allow this to be scripted later.

Migration from the JZOS Record Generator to the IBM Record Generator for Java V3.0 is simple and requires only that the new JAR file is used in place of jzos_recgen.jar and the new Java packages names com.ibm.recordgen.cobol and com.ibm.recordgen.asm are used in any scripts that drive the RecordClassGenerator utility.

//RECGEN EXEC PGM=BPXBATCH      
//STDENV   DD *               
JAVAHOME=/java/java71_64/J7.1_64       
PKG=com.ibm.cicsdev.bean               
DIR=com/ibm/cicsdev/bean 
PROG=EDUPGM
//STDOUT   DD   SYSOUT=*    
//STDERR   DD   SYSOUT=* 
//STDPARM DD *                    
sh cd /u/cics1/recgen;                                              
$JAVAHOME/bin/java                                                    
  -cp ./ibm-recgen.jar                                              
  com.ibm.recordgen.cobol.RecordClassGenerator                   
  adataFile="//'USER.CICS.COBADATA(${PROG})'"                      
  symbol=DFHCOMMAREA                                                  
  outputDir=.                                                         
  package=${PKG}                                                      
  class=JZOSCommareaWrapper; 
/*                                                

2.3 Compile the Java record class

Lastly we need to build the Java record JZOSCommareaWrapper.java created in step 2.2. This requires compiling using the javac compiler and then packaging as a JAR for deployment using the Java supplied jar utility. You can simply add the following statements to the end of the BPXBATCH job step

$JAVAHOME/bin/javac ${DIR}/JZOSCommareaWrapper.java;                      
$JAVAHOME/bin/jar -cvf ${PROG}.jar ${DIR}/JZOSCommareaWrapper.class;      

 

The job is now ready and can be used as part of a build system to easily rebuild the record when any changes are made to the copybooks. The record can be transferred to your scource code management system and then downloaded for use in an Eclipse development environment to assist with the marshaling of data when interacting with COBOL structures in a COMMAREA or other sequential data records such as VSAM files.

3. Eclipse workstation development

CICS Java development is centered around the use of the CICS Explorer SDK which helps you develop with OSGi. In an OSGi development environment Target Platform definitions are used to define the plugins that applications in the workspace will be built against.

3.1 Creating the Eclipse project

The first step is to create an Eclipse project. We will be using an OSGi development environment so before we generate any code we will first need to create a new OSGi Plug-in project in Eclipse using the wizard File -> New -> Plug-in Development -> Plug-in Project as shown on the right. As you go through the wizard follow these steps:

  1. On the first panel of the Plug-in Project wizard, select the standard OSGi framework option as we do not need any extra Eclipse or Equinox extensions
  2. On the second panel make sure that the Version is set to 1.0.0 without a qualifier as the OSGi JVM server does not support the use of qualifiers. Also ensure the selected Java execution environment is supported in your JVM server and that the option to generate an activator is not selected as this is not required
  3. On the third panel uncheck the box to create a plug-in using a template as we will add our own application code to the project.

3.2 Creating the Target Platform

The CICS Explorer SDK provides a set of sample Target Platforms which provide the JCICS APIs for different CICS TS versions. The Target Platform is set using the Eclipse menu Windows -> Preferences -> Plug-in Development -> Target Platform. Click Add and then from the supplied templates select the CICS TS release for your runtime environment, and click Next and then Finish. You can then select this and apply this to your workspace, and this will allow you to use the JCICS APIs in your application. For further details on the options for defining OSGi package imports refer to this article Configuring OSGi package imports

TargetPlat

3.3 Adding OSGI package imports

In addition to JCICS we also need to consider the Java packages used by the generated records. These records rely on classes in the the com.ibm.jzos.fields package which is provided with the IBM SDK for Java on z/OS in ibmjzos.jar. If you just use the pre-built classes in your application then OSGI package imports are not required when compiling the application, however, they will be required at runtime in the OSGI JVM server as all the dependencies need to be correctly wired when the OSGI bundles are installed. To resolve this import there are 3 options:

  1. Wrapper the ibmjzos.jar as an OSGI bundle, export the required packages and add this OSGI bundle to your Eclipse workspace or target platform and then add an Import-Package statement for com.ibm.jzos.fields to the bundle manifest.
  2. Use a resolution:=optional Import-Package statement in the OSGi bundle manifest. This will allow the bundle to activate if the packages can’t be located. This allows the code to be compiled and exported without the JZOS packages being available in the workspace, but will still allow the JZOS package dependency to be resolved in the JVM server when the bundle is installed. This is because the CICS OSGi JVM server adds the JZOS packages to the default list exported by the OSGI system bundle.
  3. If you are using CICS TS V5.3 or later, you can exploit the OSGi last resort boot delegation behaviour which will load classes from the JVM boot classpath if they fail to load from the bundle class loaders. This means you would not need to add an Import-Package statement unless you modify the default boot delegation behavior of the JVM server. For further details refer to Configuring OSGi package imports

We will use the optional import method (2) as we don’t need to use any other functions of JZOS other than the com.ibm.jzos.fields package and it is good practice to ensure all dependencies are explicitly declared in the bundle manifest.

Add the following Import-Package statements to the bundle manifest for JCICS and JZOS. The JCICS import should be versioned to define the OSGi semantic version referring to the supported JCICS API for instance com.ibm.cics.server;version="[1.300.0,2.0.0)". However, the JZOS package com.ibm.jzos.fields can be listed without a referenced version.

You resulting manifest should now look something like the following:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: com.ibm.cicsdev.jzostest
Bundle-SymbolicName: com.ibm.cicsdev.jzostest
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Bundle-Version: 1.0.0
Import-Package: com.ibm.cics.server;version="[1.300.0,2.0.0)",
 com.ibm.jzos.fields;resolution:=optional

 

3.4 Creating a CICS Java application

Now you are ready to create the Java application. As you will need to use OSGi you first need to ensure the packages required are exported from their corresponding OSGi bundles. We have already discussed access to the JZOS packages in step 3.2, but the CommareaWrapper class was built as an ordinary JAR. We can either create a wrapper project for this to convert it into an OSGi bundle, or we can just add this JAR to the OSGi bundle class path of our new application. We will use the later method and add the JAR to the bundle classpath. This method will limit usage of the CommareaWapper to components in the OSGi bundle we are about to create, which is fine for our example.

Create a new OSGi bundle project in Eclipse using the wizard File -> New -> Other -> Plug-in Project. Next create a new Java package com.ibm.cicsdev.jzostest and add a new class JZOSprog. Copy in the code show below, which will make a JCICS Program.link() call to our EDUPGM CICS COBOL program. Alternatively you can download the sample code here

public class JZOSprog {

	public static String proglink = "EDUPGM";  // Linked to COBOL program

	public static void main(String[] args)          
	{

		// Get details about our current CICS task
		Task task = Task.getTask();
		task.out.println(" - Starting JOZSprog"); 

		// Wrapper objects for input and output commareas
		JZOSCommareaWrapper cwIn = null;
		JZOSCommareaWrapper cwOut = null;

		// Set the input data fields
		Short binarydigit = 1;
		String charstring = "hello";
		Short numericstring = 1234;
		Integer packeddigit = 123456789;
		Integer signedpackeddigit = -100;
		String bool = "1";

		cwIn = new JZOSCommareaWrapper();
		cwIn.setBinaryDigit(binarydigit );
		cwIn.setCharacterString(charstring );
		cwIn.setNumericString(numericstring );
		cwIn.setPackedDigit(packeddigit );
		cwIn.setSignedPacked(signedpackeddigit );
		cwIn.setBool(bool );

		// Create a reference to the CICS program
		Program prog = new Program();
		prog.setName(proglink);	

		// Create byte array for input commarea from wrapper
		byte[] commarea = cwIn.getByteBuffer();

		try {
			// Link to target CICS program
			prog.link(commarea);

			//Create output record from updated commarea
			cwOut = new JZOSCommareaWrapper(commarea);

			// Catch any other exception and force a  rollback of CICS UOW
		} catch (Exception e) {
			String msg = "ERROR: Exception on link to {0} with msg({1})";
			task.out.println(MessageFormat.format(msg, proglink, e.getMessage()));
			// Rollback the CICS Task 
			try 
			{
				task.rollback();
			} catch (InvalidRequestException e1) {		
				// If this fails, then throw Runtime Exception
				throw new RuntimeException(e1);
			}
		} 

		String msg = "Returned from {0} with rc({1}) {2}";
		task.out.println(MessageFormat.format(msg, proglink,cwOut.getResultCode(), cwOut.getResultText()));

	}

}

 

In this sample we use the setter methods from the generated CommareaWrapper to access the individual fields in the record. Each field in the COBOL record can be written to using methods such as setBinaryDigit() and setCharacterString() and also read via corresponding getters. The entire byte array representing the records can be passed into a call using a Java byte[] array returned via the getByteBuffer().

 

Java wrapper
Java wrapper
COBOL source
COBOL source

When generating Java code from COBOL records it is helpful if you rename the COBOL data fields in a Java fashion so that the generated code has a naming convention that would be more familiar to a Java programming style. The picture above shows an example of the renaming used in our COBOL data structure and the the screen shot to the right shows the outline view of the class with all the generated setters and getters for the fields available in this record.

 

 

 

Next transfer the EDUPGM.jar containing the CommareWrapper record onto the workstation. Create a new folder in the project called lib, and then drag the JAR into this folder in your Eclipse project. Then from the OSGi bundle manifest editor add this JAR to the OSGI bundle classpath using the menu Runtime -> Classpath -> Add. This will add the following statement to the manifest.

Bundle-ClassPath: lib/EDUPGM.jar,
 .

 

Also update the Build tab in the manifest editor to add the lib directory to the Binary Build to ensure the EDUPGM.jar gets added to the build output.

Finally add a CICS-MainClass: definition to the bundle manifest to register a MainClass service for our com.ibm.cicsdev.jzostest.JZOSprog class. This will allow the Java class to be LINKed to using a CICS program definition. Your manifest should now look similar to this

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: com.ibm.cicsdev.jzostest
Bundle-SymbolicName: com.ibm.cicsdev.jzostest
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Bundle-Version: 1.0.0
Import-Package: com.ibm.cics.server;version="[1.300.0,2.0.0)",
 com.ibm.jzos.fields;resolution:=optional
Bundle-ClassPath: lib/EDUPGM.jar,
 .
CICS-MainClass: com.ibm.cicsdev.jzostest.JZOSprog

 

4. Testing the application

The application is now ready to be tested, and can simply be deployed into a CICS OSGi JVM server using a CICS Bundle project as follows:

  1. Create a CICS bundle project in Eclipse and add the OSGi bundle project using the menu New -> OSGi Bundle Project Include
  2. Deploy to zFS using the menu Export Bundle Project to z/OS UNIX File System
  3. Create a CICS BUNDLE definition referencing this zFS location and install this
  4. Create a CICS PROGRAM definition for the Java application called JZOSPROG. This should name the CICS-MainClass: com.ibm.cicsdev.jzostest.JZOSprog in the JVMClass attribute
  5. Optionally create a PROGRAM definition for the COBOL EDUPGM if you are not using program autoinstall
  6. Create a transaction definition referencing the JZOSPROG program definition if this is to be run from a 3270 terminal
  7. Install the program and transaction definitions

When invoked our Java class JZOSprog will link to the COBOL EDUPGM using the CommareaWrapper classes to marshall the input to the required COBOL record formats. It should return the following messages if successful indicating the input and output CommareaWrapper records have been successfully used to marshall the data in the COMMAREA.


Starting JZOSprog
Returned from EDUPGM with rc(0) PARAMETERS ARE ALL OK 

 


 

References

Note: An alternative data marshaling solution to IBM Record Generator for Java is the Rational J2C Tools which are described further in this developer center article Generating Java Records from COBOL with Rational J2C.


Change history

27/June/16 – Updated to reflect renaming of CommareaWrapper in sample
26/July/16 – Updated to reference J2C article
08/Sept/16 – Updated to use optional dependency resolution for JZOS
07/June/17 – Added details on creating Eclipse project and setting build.properties
21/June/17 – Corrected references to J2C
01/Aug/17 – Clarified program definitions
29/Sept/17 – Updated for launch of IBM Record Generator for Java V3.0
16/Oct/17 – Updated repo name

29 comments on"Building Java records from COBOL with the IBM Record Generator for Java"

  1. If you see the following exception during the building of the Java Record “java.lang.IllegalStateException: specTree root not a StorageSpec” you should check you are not using the COBOL copybook source as the input to the adataFile parameter for the RecordClassGenerator. Instead ensure the correct SYSADATA input is used as shown.

    • I’m definitely using the SYSADATA file as input to the recgen job but still getting the specTree error. What should the file attributes of the SYSADATA file be? PDS? FB? VB? LRECL?

      Thanks

      • Doesn’t look like anyone is watching this thread now, but just in case, I’ve worked it out. I managed to pick one of your sample programs to try which has no DFHCOMMAREA defined! In fact nothing in working storage or linkage section at all. The error message could be a bit clearer though.

        Cheers

  2. Hi Phil,

    I am getting error when I am executing J2CProg in RAD as “Task cannot be resolved ” looks like my connector.jar is not working properly.
    I have downloaded from zos unix system .RAD says it is corrupted and cannot be executed.

    • Phil_Wakelin April 26, 2017

      It sounds like the connector.jar may be corrupt, did you download in binary, and can you open this up and see the class files?

  3. eileen barkow May 31, 2017

    the BPXBATCH step required sh first in the STDPARM.
    it was missing in the supplied sample above.

    //STDPARM DD *
    sh
    cd /u/dir;
    $JAVAHOME/bin/java

    • Phil_Wakelin May 31, 2017

      Thanks Elieen, I’ve updated the article to correct this issue.

  4. eileen barkow June 02, 2017

    i put an issue in for this in the github sample version of this application. In both cases, either with following the directions in this tutorial to build EDUPGM.jar, or using the github version,
    I always got a ‘java.lang.NoClassDefFoundError for
    com.ibm.cicsdev.bean.JZOSCommareaWrapper when running the JZOSprog class and accessing JZOSCommareaWrapper from the jar file.

    I then copied the JZOSCommareWrapper.class directly into the src directory and the JZOSprog transaction worked.
    using explorer 5.3 and cics ts 5.1.

    Bundle-ManifestVersion: 2
    Bundle-Name: %Bundle-Name
    Bundle-SymbolicName: com.ibm.cicsdev.jzostest
    Bundle-RequiredExecutionEnvironment: JavaSE-1.7
    Bundle-Version: 1.0.0
    Import-Package: com.ibm.cics.server;version=”[1.300.0,2.0.0)”,
    com.ibm.jzos.fields;resolution:=optional
    Bundle-ClassPath: lib/EDUPGM.jar,
    .
    CICS-MainClass: com.ibm.cicsdev.jzostest.JZOSprog
    Export-Package: com.ibm.cicsdev.jzostest

    • Phil_Wakelin June 07, 2017

      Eileen

      I’ve looked into this and the issue you see with ‘java.lang.NoClassDefFoundError” for JZOSCommareaWrapper is because the build/export of the Eclipse bundle project is not adding the lib/EDUPGM.jar to the project build.

      To address this, if you are using an OSGi plugin project (via wizard New -> Plug-in Development -> Plug-in Project) you should ensure the bin.includes line in your build.properties file specifies that the JAR is to be added to the build. You can do this via the Build tab in the manifest editor, and then the build.properties would look like this:
      bin.includes = META-INF/,\
      .,\
      lib/
      If you are using an OSGi bundle project (via wizard New -> OSGi -> OSGi Bundle Project) then you can just copy the EDUPGM.jar into the BundleContent folder and the build.properties should reflect this.

      The alternative as you suggest is to to add the built Java Record class (or source) directly into the OSGi bundle project, as all the packages in an OSGi bundle will be visible to all components.

  5. mario_bezzi January 04, 2018

    Hello, apologize for using a technical blog for a non strictly technical comment. I just tried to download the latest version of IBM Record Generator for Java but apparently the download link at https://developer.ibm.com/mainframe/products/record-generator-for-java/ is broken. Thank you

  6. Ronald OLoughlin January 19, 2018

    Hi, our team just had a presentation of the COBOL to Java record class generator conversion of copybook. Which the person has had it running for a long time.
    Two things.
    One, they mentioned a version 8 vs 7. Reading this posting seems to reference nothing higher than 3. Is that JAVA itself or the generator?
    Two, the reason for the presentation was to make sure others are aware, but more importantly is the future compiler going to COBOL 6.2. It is understood that the ADATA parameter is still active under COBOL 6.2. However since the output from that compiler is so different from COBOL 4.2 (currently in use) will the Java record class generator accept the output as input? If so, can you confirm which version of the generator does so? If not do you know when it will?

    • Phil_Wakelin January 19, 2018

      Ronald

      I think the reference to V7 vs. 8 likely applies to the IBM Java SDK version as the previous version of the IBM Record Generator for Java was known as the JZOS Record Generator v2.4.6.

      As. regard COBOL compilers, yes all the in support IBM COBOL compilers are supported so V4.2 upwards including V6.2, this is detailed in the Knowledge Center and also the latest information is on the IBM support site here at the Software Product Compatibility Reports

      Thanks, Phil

  7. how are pointer variables handled in this Java record. how do we set them before invoking the call to the cobol program.

    • A COBOL pointer data element is mapped to a 4-byte ByteArrayField, for example
      03 POINTER-DATA USAGE IS POINTER.
      generates a setter like so:
      public void setPointerData(byte[] pointerData) {...}
      You would need to build up the COBOL pointer as a 32-bit integer and then pass this in using something like ByteBuffer.putInt()

  8. Tony Clifford October 16, 2018

    $JAVAHOME/bin/jar -cvf ${PROG}.jar ${DIR}/ZJOSommareaWrapper.class; should read $JAVAHOME/bin/jar -cvf ${PROG}.jar ${DIR}/JZOSCommareaWrapper.class;

  9. Phil_Wakelin October 16, 2018

    Thanks Tony, that’s fixed now.

  10. Mike Paparella January 04, 2019

    I tried running Record Generator and I am getting an error message java.lang.IllegalStateException: I-TIME-CHECK-RECORD parent not found. Is this because it can’t find the 01 level. This is from a non CICS program and I created the SYSADATA from COBOL 5.2 using the below options. Any help would be appreciated.
    APOST,LIB,OPT,LANGUAGE(UE),
    ,NOSEQ,DATA(24),ADV,ADATA,
    ,OFFSET,MAP,
    NODYN,DBCS,NS(NAT),

    • Phil_Wakelin January 04, 2019

      Hi Mike, can you supply the copybook structure containing I-TIME-CHECK-RECORD?

  11. Gabor Markon January 22, 2019

    Hello all,

    in 2.3 “$JAVAHOME/bin/jar -cvf ${PROG}.jar ${DIR}/JZOSommareaWrapper.class;” the class name is wrong.
    “$JAVAHOME/bin/jar -cvf ${PROG}.jar ${DIR}/JZOSCommareaWrapper.class;” is OK.

    Regards,
    Gabor

  12. Gabor Markon January 22, 2019

    Hello Community,

    I’ve compiled recently a (harmless) COBOL and generated ADATA. At record generation I’ve received the (vicious) error message below.

    IBM Record Generator for Java V3.0.1 Build 20180227-1206 on: Tue Jan 22 12:34:27 CET 2019
    Error while processing file: //’SA81289.SYSADATA’
    java.lang.IllegalStateException: specTree root is not a StorageSpec. May be caused by invalid or corrupt ADATA file, or incorrect symbol name.
    at com.ibm.recordgen.cobol.RecordSpecTreeBuilder.process(RecordSpecTreeBuilder.java:226)
    at com.ibm.recordgen.cobol.RecordClassGenerator.processFile(RecordClassGenerator.java:395)
    at com.ibm.recordgen.cobol.RecordClassGenerator.processLibrary(RecordClassGenerator.java:506)
    at com.ibm.recordgen.cobol.RecordClassGenerator.main(RecordClassGenerator.java:320)
    RecordClassGenerator failed to process at least one file; exitCode=8

    Can anybody pls. clear me up about the possible reason?

    Kind regards
    Gabor

  13. Phil_Wakelin January 23, 2019

    Gabor, the exception “java.lang.IllegalStateException: specTree root is not a StorageSpec” generally indicates that the ADATA is invalid or that the symbol specified is not present, see this KC page for a few hints https://www.ibm.com/support/knowledgecenter/SSMQ4D_3.0.0/documentation/troubleshooting.html
    You should be able to eyeball the ADATA to check the symbol specified exists.

    Regards, Phil.

  14. Gabor Markon January 24, 2019

    Hello Phil,

    thank you for the hint. As for the ADATA: I’ve run the COBOL compilation + recgen twice, using the same ADATA dataset (VB / LRELCL=1020).
    The first job, using the official IBM sample program run OK. The second one, which used a simple COBOL program of mine,
    throw the above error.
    Logically, the error could be caused only by different code.
    Is there any way for a visual control of the ADATA to find the possible error?

    Regards, Gabor

    • Gabor Markon January 24, 2019

      Hello Phil,

      shame on me, I’ve did not read the documentation carefully. I’ve supposed “recgen” takes ALL COBOL record structures, and generates the identical
      Java pendant.
      Nevertheless, one can use it as a general translator. The trick is, to rename the favored record structure name into DFHCOMMAREA.
      Admitted it is a somewhat silly usage, but it works.
      Anyway, I ask if you plan a general usage of the recgen in the way I’ve painted above?

      Regards
      Gabor

Join The Discussion

Your email address will not be published. Required fields are marked *