JURASSIC FAQS

(funny tittle isn'it !!!)

AUTHOR : Jean-Yves MENGANT

IBM' mainframes have been there for almost 40 years, I have started programming(mainly in ASSEMBLY language and sometimes in PLI or COBOL) on an IBM S370 model 148 in 1978 and worked almost for ten years exclusively on MVS/CICS systems.Since I also spent last ten years on misc open systems(misc UNIXes, OS2 ,WINDOWS...and last but not least JAVA) I should look like a kind of Jurassic guy :=).

I do receive some mails about JAVA/MAINFRAME/COBOL questions, the topics covered by those questions may be of great interest, and I hope may help people who plan to link to those 'BIG IRONS', either to collect legacy data using file transfer,or interface CICS or IMS COBOL/PLI programs. So I have decided to start up this page and take some time to answer those questions here and also provide any JAVA utility class I have written on this topic.

The cobolConversion package classes is a tiny JAVA package(GNU licensed) that may be downloaded here :

cobolConversion V0.0.3 package in tar.gzip format.(use right mouse click and save link as function to download)
cobolConversion V0.0.3 package in winzip format.(use right mouse click and save link as function to download).
javadoc + UML documentation in HTML tar.gzip format.
javadoc + UML documentation in HTML winzip format.

This package may help you when faced with MVS / COBOL data exchanges.

Q1 : How to get QSAM file on an ASCII machine ?

QSAM files in FIXED format are just a collection of byte. The record frontier is just a programming convention used by COBOL programs, but no extra bytes are stored inside the file, so you can transport them either as EBCDIC text streams or BINARY text streams. Next question is now how to proceed to file transfert ? Let's assume that you got a TSO/ISPF session as a starting point. then you have two possibilities to transfert your file, mainly depending on your MAINFRAME network infrastructure :

You're FULL SNA : The more general and simple way to proceed is to use the 3270 emulation and the TSO/IND$FILE. On mainframe side just go to the 6 TSO COMMAND ISPF PANEL. On local side the way to procced will depend of your 3270 terminal emulator's provider implementation. Usually it will provide you with both BINARY and TEXT file transfert calpability. Let's take the LINUX X3270 emulation program , the file transfert functions are just a submenu of the File menu of the X3270 session.You're FULL IP : This is the more confortable way(from my point of view), In that case an FTP deamon should sit on top of your OPENMVS region and will provide you with standard FTP functionalities. Q2 : Will the binary data be converted to ASCII ?

let's say that you start a standard FTP session against your HOST, if before the ftp get or put command you type :

> set binary

a TEXT file transfert will take place and NO CONVERSION will be done. The consequence is that locally all the EBCDIC text parts of your file will remain in EBCDIC in all cases. If your MVS file contains standard COBOL records mapping on PIC X , PIC S999 USAGE COMP ....you should definitively proceed with a binary file transfert and proceed with DATA CONVERSIONS into local JAVA classes.(more on that topic below).

Now if before the ftp get or put command you type :

> set ascii

a TEXT file transfert using ASCII to EBCDIC(on put command) or EBCDIC to ASCII(on get command).This implies that your HOST file should only contain EBCDIC TEXT (no binaries , no packed decimal ....).The FTP conversion will be based on CONVERSION TABLES set up by your MVS system administrator and will reflect the country idiosyncrasies PAGE CODE.

Q3 : How to can I read an EBCDIC file in JAVA ?

Let's assume that( as indicated above ) you proceed with a BINARY ftp file tranfert. You now got your file locally and you can read it using the standards FileInputStream and BufferedInputStream class(since you'll proceed with binary data you should use InputStream instead of Readers even if you're inJDK 1.1 or 1.2) :

BufferedInputStream myMvsFile = new BufferedInputSteam( new FileInputStream("mvsftptransfered.data") ) ;

if your file has a reasonable size you can then bring it into memory using following JAVA code :

long fullSize = (new File("mvsftptransfered.data")).fileSize() ;

byte myBuffer[] = new byte[fullSize] ;

myMvsFile.read( myBuffer , 0 , fullSize ) ;

Q4 : How to can I read a FIXED RECORD of 400 bytes ?

FIXED RECORD do not exist any more when you're on JAVA side. But if you want to remap your PHYSICAL 400 byte binary record , just use a 400 byte array size in the Q3 code and loop reading records until you got a JAVA IOException.

Q5 : I got PACKED DECIMAL data inside those records How can I read proceed them in JAVA ?

COBOL PACKED decimal data should be converted to JAVA BigDecimal data type which is just the equivalent JAVA data type( NOTE that this is another good reason to use JAVA instead of C++ which does not implement FIXED decimal as a standard language type). Just fine but the big problem we got is that the COBOL PACKED decimal, we have just transfered in Q3 above is a flat array of byte, how to transform this array of byte in a JAVA BigDecimal format ?

the PackedDecimal JAVA class provided here will do the JOB for you. Just look at the source code if you're curious.

The only thing that the impatients should notice is the the constructor takes a byte array as argument. If your COBOL packed decimal data starts at, let's say offset 20 of your 400 bytes COBOL RECORD. The toString method of the PackedDecimal class will convert the packed decimal data coming from MVS into a java String.If you plan to compute on FIXED DECIMAL numbers in JAVA just use this String as an argument to the BigDecimal JDK class constructor.

PITTFALL : For better performances on binary computation,The MVS RECORDS FIELDS may sometimes force data alignment on FULL WORDS boundaries using the COBOL SYNC keyword.this will insert extra FIILER bytes inside your binary record, and it's up to you to compute the right binary offset of your BINARY DATA inside your record in that case.(I suggest you avoid using SYNC clause inside your FD DATA definition to get rid off this problem).

Q6 : I got EBCDIC string inside those records How can I read proceed them in JAVA ?

EBCDIC should be converted to JAVA UNICODE Strings, lets say that you got the byte buffer we previoulsy load in Q3, the only information you need to proceed with conversions is : at what offset does the EBCDIC string start, what is the length of the EBCDIC data to convert , and you can use the EbcdicString class provided in cobolConversion package to do the job. EbcdicString inherits DataStructure and uses EbcdicTable to proceed with Country independent EBCDIC tp UNICODE conversion.

If you have questions about JAVA/MAINFRAMES problems which are not covered here or if I am not very clear on a given topic , or whatever else do not hesitate to E-MAIL me, just be patient since during the daytime I am out working for customers :

send mail to :


	This dinos Ring site is owned by a JAVA/MVS dino . Want to join the dinos Ring ? [Skip Prev] [Prev] [Next] [Skip Next] [Random] [Next 5] [List Sites]