Hi,
Does anyone know of a better way of handling pack decimal & zone (display) number types from Cobol to Java?
Several of our Java Applications will be accessing both VSAM & Sequential data files of which are being maintained by Cobol Programs.
For example, the following is an illustration of Cobol record layout of a sample file:
01 CUSTOMER-APP-REC.
*-- THE APPLICATION KEY IS OF 9 BYTES
05 APP-REC-KEY.
10 CMP-CODE PIC X(02).
*-- NEXT FOLLOWING FIELD OCCUPIES 6 BYTES
10 APP-NUMBER PIC S9(11) PACKED-DECIMAL.
10 REC-TYPE PIC X.
05 FILLER PIC X(1139).
*-- THE FOLLOWING IS A PACKED-DECIMAL NUMBER (2 BYTES)
05 BNB-MEMB-CNT PIC S999 COMP-3.
*-- THE FILLOWING IS A ZONE DECIMAL (4 BYTES)
05 BNB-HIST-CNT PIC S999 USAGE IS DISPLAY.
The following Java Code fragment is to illustrate how the above Cobol record is read as a byte array of 1153 bytes and assuming that the default file encoding is Cp1047.
String fName = "//'BNBVF.A1000718.TYA.BNBM800A'";
ZFile cusFile;
DataInputStream inWorkFile;
byte[] customerAppRec = new byte[1153];
byte[] custRecKey = new byte[9];
byte[] packTemp = new byte[8]; //double word on mainframe
com.ibm.math.BigDecimal bnbMemCnt;
com.ibm.math.BigDecimal bnbHistCnt;
int bytesRead; //size of record read
int i; //size in input field
long l; //size of input field (long)
//... rest of code
try {
cusFile = new ZFile(fName,"rb+,type=record");
bytesRead = sysFile.read(customerAppRec);
inWorkFile = new DataInputStream(
new ByteArrayInputStream(customerAppRec) );
i = inWorkFile.read(custRecKey);
l = inWorkFile.skip(1139); //Skip over filler
i = inWorkFile.read(packTemp,0,2); // get bytes for packed decimal
bnbMemCnt = new BigDecimal( //use long constructor
ByteUtil.unpackLong(packTemp,0,2,true) );
// convert bytes to long
i = inWorkFile.read(packTemp,0,3); // get bytes for zone decimal
bnbHistCnt = new BigDecimal( // use string constructor
new String(packTemp, 0, 3, "Cp1047")); //convert bytes
// to string
Question:
How do I save field: bnbMemCnt back as bytes?
Also, there are times when the trailing digit of the input data for the field: bnbHistCnt has a funny character. Is there a way around this?
pack & zone decimal number types from Cobol to Jav
You might look at using the JRIO record mapping classes (they can be used independant of the "RecordFile" IO routines).
Also, since you are using ZFile with type=record, I wanted to mention something interesting that we found recently:
If you want to open a file for sequential reading in record mode, use a mode like this: "rb,type=record,noseek"
For sequential writing: "wb,type=record,noseek".
Leaving out the "+" indicates that you are either reading or writing, not both. The "noseek" tells the C library that you are doing sequential IO, as opposed to random access. Without "noseek", buffering is disabled! For DASD datasets, adding "noseek" can mean a 100x improvement in both throughput and CPU utilization. The difference is astonishing.
We will be updating the documentation to include notes about this.
Also, since you are using ZFile with type=record, I wanted to mention something interesting that we found recently:
If you want to open a file for sequential reading in record mode, use a mode like this: "rb,type=record,noseek"
For sequential writing: "wb,type=record,noseek".
Leaving out the "+" indicates that you are either reading or writing, not both. The "noseek" tells the C library that you are doing sequential IO, as opposed to random access. Without "noseek", buffering is disabled! For DASD datasets, adding "noseek" can mean a 100x improvement in both throughput and CPU utilization. The difference is astonishing.
We will be updating the documentation to include notes about this.
Hey,
thanks for pointing out the record mapping classes.
I didn't realize that there were 2 separate packages:
com.ibm.recordio – jrio
& com.ibm.record - java record management
However not to sidetrack here, but are there any mode options for improving performance of VSAM files?
Also, according to C/C++ Programming Guide, when a file is open with “rb+”, the file must already exists, prior to being open for reading and writing. However, the “wb+” option opens the file for reading & writing, but deletes the existing contains (this should be equivalent to the “REUSE” process option of VSAM files).
If a file is opened in update mode and depending on shareoptions specification of the VSAM file, can a read operation result in CI lock, even when I don’t intent on updating the current record?
thanks for pointing out the record mapping classes.
I didn't realize that there were 2 separate packages:
com.ibm.recordio – jrio
& com.ibm.record - java record management
However not to sidetrack here, but are there any mode options for improving performance of VSAM files?
Also, according to C/C++ Programming Guide, when a file is open with “rb+”, the file must already exists, prior to being open for reading and writing. However, the “wb+” option opens the file for reading & writing, but deletes the existing contains (this should be equivalent to the “REUSE” process option of VSAM files).
If a file is opened in update mode and depending on shareoptions specification of the VSAM file, can a read operation result in CI lock, even when I don’t intent on updating the current record?
Re: pack & zone decimal number types from Cobol to Jav
However, the “wb+” option opens the file for reading & writing, but deletes the existing contains (this should be equivalent to the “REUSE” process option of VSAM files). ????