How can we create a flat file in JAVA with COMP-3 VALUES?

rakesh.v18 · New User Joined: 14 Feb 2006 Posts: 7 Location: India

This file we need to send to mainframes after creating comp-3 values.

Bill Woodger · Posted: Fri Sep 23, 2016 10:55 pm

Well, don't. Seen fixed-width character values, which actual decimal places (or explicit, or implicit, scaling), explicit sign. Can you do that? Then the Mainframe program can make it packed-decimal with no effort, and no code-silliness for you.

Robert Sample · Posted: Fri Sep 23, 2016 11:50 pm

I echo Bill's comment -- you really don't want to creat5e a file with packed decimal data in Java. Because if you want packed decimal, you MUST create the file as an EBCDIC file, not an ASCII file, since the conversion from ASCII to EBCDIC will completely corrupt your packed decimal values. For example, if the value is positive and ends in 3, 3C is the < character in ASCII -- but that translates to 4C in EBCDIC, so your packed decimal value just changed; many other bytes of the packed decimal data would also be changed in an ASCII-to-EBCDIC conversion.

steve-myers · Posted: Sat Sep 24, 2016 12:01 am

Certainly it can be done, but doing it is, well, dumb, to use a polite term more in keeping this site politically correct and using words that can be used in the presence of small children.

I wonder if rakesh.v18 realizes the crested file would require any text in the file to be EBCDIC and the file would have to be sent to the mainframe as a binary transfer?

Rohit Umarjikar · Posted: Sat Sep 24, 2016 1:15 am

This is a JAVA question and nothing to do with COBOL.
First you need to know comp-3 and then if you have any function which does that conversion to packed decimal then its good else you will need to put logic by yourself. But data corrupt may occur during ASCII to EBCDIC conversion. So why not sent the actual values in ZD and let Mainframes side , converts and read that to comp-3?

sergeyken · Posted: Sat Sep 24, 2016 1:23 am

When COMP-3 data (i.e. Packed Decimal, i.e. DS PLn, etc.) are created as fields in a file to be transmitted to mainframe, it is possible, but the file transmission must be done in binary mode. In that case also all text data must be created in EBCDIC, binary fixed/float data - in IBM format, etc. etc. etc.

Usually it doesn't make much sense unless there are very specific reasons to do this (except "these are requirements from TL")

Bill Woodger · Posted: Sat Sep 24, 2016 1:59 am

It is an absurd task which requires substantial coding/processing and all for no possible reason at all.

Yes, people do it, but more fool them. Also ask the audit/compliance/accounting departments. Tell them that instead of just using "print" statements to format your numeric data and allow the built-in ASCII-EBCDIC conversion of your transport mechanism, you want to do all of the conversions yourself, including accurately representing packed-decimal data, and the entire benefit is... nothing. To the detriment is a bag of code you know little about, which you have to cobble together from potentially ropey libraries (I'll bet not a single library actually knows all about packed-decimal data).

I'll show you the code on the Mainframe if you do all that work to provide the data in EBCDIC with packed-decimal numerics:

sergeyken · Posted: Sat Sep 24, 2016 5:55 pm

Such stupid requirements, like "create COMP-3 data in Java" continue to appear more and more often. Usually they are produced by undereducated managers who are crazy on "modern technologies". Whenever they've cought any term new to them immediately it is included in so called "functional specifications" to be implemented by their monkeys.