Unpack COBOL packed fields during FTP

[Dave La Mar]

In ftp jobs from IBM mainframe to unix we have some comp 3 fields.
Has anyone had any experience in transmitting files with this type of field to HP-UX 11.0 that would change the comp 3 to an unsigned.

If not via ftp, then once the file arrives is there a utility to unpack only those fields.

Note: This is not a zipped file. Only fields within the file are packed.

Appreciate any input.

dl

[Rodney Hills · Accepted solution]

If I remember my cobol right, a comp-3 has 4 bits per digit (2 digits per byte) and the last digit is a overpunch of the sign.

Although I do not know of any pre-built utility, "perl" is quite capable of parsing text data (see pack/unpack function).

-- Rod Hills

[A. Clay Stephenson]

FTP knows nothing about packed or unpacked data. All you can do is specify a binary transfer. That should be an exact copy. Data conversion can be a complex issue - especially coming from an IBM mainframe because you have the EBCDIC/ASCII conversion as well. This really becomes tricky when you have binary data as well as string data in a record. Dd's conv=ascii can't be used because it will destroy the binary data. In general, you are going to have to copy the data using FTP binary and then if data conversion is needed, you write that as a separate program/script.

[Dave La Mar]

Thanks Rodney. No one here has any perl experience (relatively new shop for HP-UX).
The last time I tried to do something in perl it appeared we do not have it installed.
Will note your answer and assign
mega points shortly.

Thanks again.
dl

[harry d brown jr]

Dave,

get perl from here:

http://hpux.cs.utah.edu/hppd/hpux/Languages/perl-5.6.1/


Remember that you have to use BINARY mode to transfer the files in ftp.

If the file is in EBCDIC, you can convert it to ascii using "dd" and the "conv ascii" or "conv ibm" option.


live free or die
harry

[Dave La Mar]

Thank's people.
I was afraid there was no esay solution.
No wonder "everyone is not doing this" .....

Thanks again.

dl

[A. Clay Stephenson]

Don't be too discouraged Dave. This stuff is usually not difficult but it is tedious. Perl can be made to read binary records (i.e. those that don't enr with LF's) although when I have to do this stuff, I usually use C simply because all my conversion tools are written are C routines. As I said earlier, the bad ones have records which contain text which must be converted from EBCDIC to ASCII and also have binary/packed data which must not go through the EBCDIC/BINARY conversion.

[Bill Hassell]

Perl 4 is installed on all HP-UX systems since 10.00 in /usr/contrib/bin/perl. However, Perl4 is basically obsolete due to forward compatibility issues. To get the latest Perl (5) version for 11.00 and higher, just download it from software.hp.com and install it with swinstall.

[Dave La Mar]

Clay -
Thanks for the encouragement for an old time mainframe systems programmer trying to get into the
90's.

Bill -
That's great news. Looking like I'll be learning another tool.

"Never too old .... "

dl

[Rodney Hills]

One important item on the EBCDIC to ASCII conversion. This will munge your comp-3 fields.

My recommendation is to first write a tool that reads in the ibm file and builds two files. The first will have the comp-3 fields (or other binary like comp-6) and the other the EBCDIC data.

Then you can use "dd" to convert ebcdic to ascii on the second file. The first file will require another program to translate the binary to ascii representations. That same program can then merge back in the first file.

I assume you do not have access to the programs/system that generated the original file. If you did then it would be easier to have convert the comp-3 fields.

My 2 cents.

-- Rod Hills

[Vincent Fleming]

I've always had the mainframe guys unpack the fields and produce a flat-file dataset. That's easily converted in UNIX via 'dd'.

It seems to be easier to do from the mainframe side, since they already have the record descriptions programmed in COBOL, PL/1 or whatever they have been using, and can much more simply output the data in text format.

In UNIX, the packed decimal format is not used, so it would be a nasty conversion of bit shifting.

Good luck!

[harry d brown jr]

Vincent,

putting on my cobol hat - you are right, that's what I used to do, plus they could seperate the fields by building a new record using a filler of ";" and doing a "move like".

live free or die
harry

[Rodney Hills]

I guess you could always buy the cobol compiler for hpux ;-)

-- Rod Hills

[Dave La Mar]

Rodney -
Yeh, I've gotta love your answer because it is the easiest for me with the exception of the fact we
are running both environments and the program is still in use.
So .... copy it, make my changes,
catalog as new prog and add a step to the driver proc.
I just didn't want to have to perform this on all interface programs.

dl

[Dave La Mar]

Vincent -
Ditto my answer to Rodney.

Harry -
Thanks for the confirmation.



Thanks people.
Like to close this thread now.

Thanks again.

dl

[Kes Moodley]

1) Transfer the file from Mainframe to Unix as a binary file

2) Unblock the file and set the record length :
dd if=(infile) of=(outfile) cbs=(reclength) conv=unblock

3) Load the file to to your Oracle8i database using sql*loader. Your control file should look like this: :

Load data
characterset we8ebcdic500
infile '/mims/den/mims_run_t/work/jmc.ldi2'
badfile '/mims/den/mims_run_t/work/jmcjobldi.bad'
Append into table JMC_JOB
(APPL_NBR position(5:11) char "'E'||:APPL_NBR",
JOB position(1:12) char,
SITE_RESP position(13:15) DECIMAL(5,2),
EST_CHG_DEP position(42:46) DECIMAL(9,2),
EST_CHG_CONN position(47:51) DECIMAL(9,2),
EST_CHG_PRIV position(52:56) DECIMAL(9,2),
EST_CHG_PUB position(57:61) DECIMAL(9,2),
EST_CHG_PAFC position(62:66) DECIMAL(9,2),
EST_CHG_XDEP position(67:71) DECIMAL(9,2),
PD_CHG_DEP position(72:76) DECIMAL(9,2),
PD_CHG_CONN position(77:81) DECIMAL(9,2),
PD_CHG_PRIV position(82:86) DECIMAL(9,2),
PD_CHG_PUB position(87:91) DECIMAL(9,2),
PD_CHG_PAFC position(92:96) DECIMAL(9,2),
PD_CHG_XDEP position(97:101) DECIMAL(9,2),
PD_DTE_DEP position(102:109) char,
PD_DTE_CONN position(110:117) char,
PD_DTE_PRIV position(118:125) char,
PD_DTE_PUB position(126:133) char,
PD_DTE_PAFC position(134:141) char,
PD_DTE_XDEP position(142:149) char,
DTE_VOUCHER position(584:591) char,
EST_CHG_VAT position(592:595) DECIMAL(7,2),
PD_CHG_VAT position(596:599) DECIMAL(7,2),
PD_DTE_VAT position(600:607) char
)

[Dave La Mar]

Kes -
Thanks for the input. As I mentioned, I will not be back in the shop for another 2-3 weeks and will give it a shot then.
Presently, we are just changing the progs to output two files, one for the mainframe and a sequential(flat) for unix.
If I can incorporate your suggestion we can script this from the unix side for the said problem.
Thanks again.
dl