IBM Mainframe Forum

I've been tasked with writing a JCL proc that creates a PS dataset containing the POSIX cksum of a passed dataset or member. Currently the proc is working fine. It ibgens the dataset over to OMVS, and then I use BPXBATCH to run cksum on the file. Now, when the same dataset is downloaded from the mainframe to a UNIX server via binary download the byte count (and obviously the CRC hash) are different. At this point I'm not sure how to pinpoint where the failure is. It could be the IEBGENER is monkeying around and not doing a faithful copy, or it could be that the FTP binary download is doing something (though to my understanding it shouldn't). To recap, I have a PS dataset that is copied to OMVS where a cksum is performed. Then, the cksum is put into a PS dataset, and then both the cksum dataset and the original PS dataset are FTP'd (client initiated). The number of bytes cksum reports on OMVS is different from the number of bytes reported on the UNIX server.

I would be inclined to think that the problem is with the FTP as I have tested IEBGENER by copying the data to OMVS, then copying that data into a new PS dataset, and then copying it back, and comparing the cksums each time, and they were identical. I would think is IEBGENER changed anything, it would do it both times. So I'm not sure what to try at this point. Any help would be appreciated.

Output from OMVS cksum: 568045815.25549481./tmp/input.ADW832
Output from UNIX cksum: 635370730.25544160.input.ADW832

Here is the JCL in the proc

Hello and welcome to the forum,

FWIW - neither iebgener nor ftp will modify the contents of a file being processed unless specifically told to. . .

What is the content of the ps file? How is it created?

Thanks for the welcome.

The PS file is the output from another batch job and contains semicolon delimited data (text). It has about 250k records, record length of 516, block size of 27998, record format of VB, BIG data class, and allocated 32 cylinders.

Now, I just finished remoting into work, and tried the whole process with a different FTP client, and it worked this time. The only thing I can surmise is that the FTP session was interrupted before seeing as the number of bytes reported in UNIX is less than the number of bytes reported in OMVS, or the FTP client has a bug for large binary downloads. I'll test it a bunch more to be sure, because it failed on me at least 3 times before I was desperate enough to post in a forum, so its sudden cooperation concerns me a bit. Thanks for lending your brain.

Hello,


I noticed that recfm=u has been specified. If this:

record length of 516, block size of 27998, record format of VB,

is the actual attributes, i'd suggest using these rather than recfm=u.

When we transfer data from the mainframe to UNIX or Windows, we "always" use ascii. There have been a couple of exceptons where some code existed on a unix system that could deal with mianframe binary data. I've always transferred to/from the mainframe to the target without doing anything with the uss/omvs.

Good luck and someone will be here if there are questions/problems

The recfm=u that you see is for the new dataset that only contains the cksum of the passed one. The only thing that happens to the dataset with the data copied from the mainframe after getting its cksum is deleting it. Thanks again.

Hi ,
I am a new member to the forum. My requirement is also same , want to get the cksum for a file calculated from MVS. I went throught this discussion and created jcl in the same way as given by bbonner. But when I run the job in MVS , the checksum value which I got is different from the value which I got when I ran cksum command on the same file in unix.

checksum calculated from Unix is :
=============================
2254304259 46375 MCCFXICT

checksum calculated from MVS is :
=============================
2610446388.46144./tmp/chksum_input.fxict

My JCL is given below:
**************************************************************************************************************
//CKSUM011 JOB (AAAA,TXX,000000),'XXXXXXXX',REGION=0K,
// MSGCLASS=X,
// CLASS=D,
// NOTIFY=&SYSUID
//*******************************************************
//* DELETE OUTPUT FILE IF IT EXISTS *
//*******************************************************
//STEP1 EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//LOOKHERE DD DSN=WPH.CHKSUM.OUT,
// DISP=(MOD,DELETE,DELETE),SPACE=(TRK,(1,1))
//*******************************************************
//* COPY FROM input TO CHKSUM_INPUT.FXICT *
//*******************************************************
//IEBGENER EXEC PGM=IEBGENER,REGION=5M,TIME=100
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DSN=WPH.MCCFXICT.CHKSUM,
// DISP=(OLD,KEEP,KEEP)
//SYSUT2 DD PATH='/tmp/chksum_input.fxict',
// PATHOPTS=(OWRONLY,OCREAT),PATHDISP=(KEEP,DELETE),
// PATHMODE=(SIWUSR,SIXUSR,SIRUSR)
//*******************************************************
//* RUN BPXBATCH TO CKSUM PASSED FILE *
//*******************************************************
//BPXBATCH EXEC PGM=BPXBATCH,
// PARM='SH cksum /tmp/chksum_input.fxict'
//STDOUT DD PATH='/tmp/cksmout.fxict',PATHOPTS=(OWRONLY,OCREAT),
// PATHDISP=(KEEP,DELETE),PATHMODE=(SIWUSR,SIXUSR,SIRUSR)
//*******************************************************
//* COPY FROM CKSMOUT.fxict TO output file *
//*******************************************************
//IEBGENER EXEC PGM=IEBGENER,REGION=5M,TIME=100
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD PATH='/tmp/cksmout.fxict',PATHOPTS=(ORDONLY),
// PATHDISP=(DELETE,DELETE),FILEDATA=TEXT,LRECL=4096,RECFM=U,
// BLKSIZE=4096
//SYSUT2 DD DSN=WPH.CHKSUM.OUT,DISP=(NEW,CATLG),
// DCB=(DSORG=PS,RECFM=U,LRECL=80),
// SPACE=(TRK,(1,1))
//*******************************************************
//* RUN BPXBATCH TO DELETE ALL .fxict FILES *
//*******************************************************
//BPXBATCH EXEC PGM=BPXBATCH,
// PARM='SH find /tmp/ -name "*.fxict" | xargs rm -f'
//STDOUT DD PATH='/tmp/std.out',PATHOPTS=(OWRONLY,OCREAT),
// PATHDISP=(DELETE,DELETE),PATHMODE=(SIWUSR,SIXUSR,SIRUSR)
**************************************************************************************************************


Could someone help me out in finding out what is the issue

Are you aware that Unix System Services running on z/OS is using EBCDIC whereas almost all Unix implementations use ASCII? The hex representation of a capital A in ASCII will be x'41' while a mainframe EBCDIC captial A hex representation will be x'C1'. Hence you cannot compare a check sum generated on an Unix system with a check sum on a mainframe since the values are going to be different pretty much at all times.

Yes, indeed. I was about to write a post like Mr. Sample's post, but Mr. Sample hit the nail squarely on its head. I want to add -

A sequential "flat" file in OMVS contains EBCDIC characters, just like a sequential "flat" MVS dataset. An FTP transfer of text data translates the EBCDIC data as used in MVS to some form of ASCII before it leaves the MVS system.

In addition, you must realize "flat" text file in OMVS and Unix is structured differently than a "flat" dataset in MVS, or a "flat" text file in Windoze, and this structure affects the checksum. In OMVS and Unix, each text line is terminated with a "new line" control character. MVS does not use control characters: IBM made this mistake in some second generation systems and did not repeat it in System/360 data structures. For example, when you specify RECFM=FB, LRECL=80, each line contains 80 bytes, no more and no less, and the next line immediately follows the current line with no embedded control information like the "new line" control data used in Unix and OMVS or the "carriage return" and "line feed" characters used in Windoze and MS/DOS and, presumably, CP/M.

Thanks a lot for the answers... But the main use of cksum utiltily is to make sure that data transferred from one system to other has been recieved accurately without any data corruption. In that case I think there should be some way to tackle the issue. Is anybody aware how we can handle this.

Also in the first post in this topic Mr bbonner was tring to compare between the results form unix and mainframe. and finally he got the results correctly also.
So i think this can be handled, but not sure how.

Hi all,

Can we use the chcp command to change code page before running the cksum in BPXBATCH?