View previous topic :: View next topic
|
Author |
Message |
kranthikumarb
Active User
Joined: 02 Jan 2009 Posts: 115 Location: Hyderabad
|
|
|
|
Hello,
I searched the forum and found some useful information. I tried to use that info, but I wasn't able to succeed. That made me to post this. Please help me if you can.
In the below JCL, I am trying to copy a dataset from z/os to HSS and get the same file back onto mainframes. It works fine for the first time. I can see the contents both in HSS (3.17 option) and also in the copied file back to mainframes.
Now, if I try to resubmit the same JCL, it gives me JCL error saying the HSS file is not found. But the file is actually present out there. In real time scenario, this job has to run more than 300 times a day to send and get back the file. Now, I wonder if this can even be achieved if I am getting issue just in the 2nd run of the job.
Code: |
//SENDFIL EXEC PGM=IKJEFT01,DYNAMNBR=300
//SYSTSPRT DD SYSOUT=*
//INMVS DD DSN=XYT.USZKNB5.FILE2,DISP=SHR
//OUTHFS DD PATH='/SYSTEM/tmp/uszknb5/kk.txt'
//SYSPRINT DD SYSOUT=*
//SYSTSIN DD *
ocopy indd(INMVS) outdd(OUTHFS)
/*
//*************************************************
//GETFIL EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSUT1 DD PATH='/SYSTEM/tmp/uszknb5/kk.txt',
// FILEDATA=TEXT,
// LRECL=150,BLKSIZE=1500,RECFM=FB
//SYSUT2 DD DSN=XYT.FILEFROM.UNIX,DISP=SHR
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
|
The error message is
Code: |
DTMU JOB USZKNB5U REQUEUED TO NONTAPE CLASS
THRUPUT MANAGER V6 R2.0 PROCESSING COMPLETE
DTM1459I 2014.240 20:05:52 JOB USZKNB5U REQUEUED TO CLASS=F PRIORITY=6
ICH70001I USZKNB5 LAST ACCESS AT 20:02:45 ON THURSDAY, AUGUST 28, 2014
IEF212I USZKNB5U COMPOUT OUTHFS - DATA SET NOT FOUND
IEF272I USZKNB5U COMPOUT - STEP WAS NOT EXECUTED.
IEF373I STEP/COMPOUT /START 2014240.2005
IEF032I STEP/COMPOUT /STOP 2014240.2005
CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC
VIRT: 0K SYS: 0K EXT: 0K SYS: 0K
IEF375I JOB/USZKNB5U/START 2014240.2005
IEF033I JOB/USZKNB5U/STOP 2014240.2005
CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC
|
Note, I created the file kk in HFS using the command touch. That gave me a default length of 255. But I am trying to copy a file that is of 150 byte length. On the other hand, I tried to create a file in first step and delete in the last step. But I wasn't able to do that as well.
Any help on this is really appreciated. |
|
Back to top |
|
|
kranthikumarb
Active User
Joined: 02 Jan 2009 Posts: 115 Location: Hyderabad
|
|
|
|
Adding to this, the job is not throwing any error some times and some times it throws the above error message. When it runs fine, for some records it is throwing the below problem.
The file I am transferring is a 150 byte FB PS file. Data from 131-150 is packed decimal. For few records, it is pushing some part of PD data to next line. This is happening only for few records.
The below pic doesn't show complete 150 bytes. But one can see the packed decimal data at position 1.
Can some one help me how to get out of this issue.
Code: |
********************************* Top of Data *******************************
2038184714714715049993517131773145 171 07071 714 2 9 91941
203828471471471504 36171334 91941
..
203818471471471504 361946116619 1 000 1 A
203818471471471504 361946116602 1 000 1 A
203818471471471504041Z61946234338A 110 01 000 9 91941 A
203818471471471504041Z61946116481 118 01 9000 1 91941 A
203818471471471504041Z62126184338A 727 BA 000010 1 91941 A
203818471471471504041Z62126184338A 078 BA 000010 1 91941 A
2038184714714715040043617133440031 172 010139 2 9 91941
..
203818471471471504041Z61946236481 110 01 000 9 91941 A
203818471471471504041Z61946116481 118 01 9000 1 91941 A
203818471471471504041Z62126184338A 727 AA 000020 1 91941 A
203818471471471504041Z62126184338A 078 AA 000020 1 91941 A
203818471471471504041Z61946236481 110 01 000 9 91941 A
203818471471471504041Z61946116481 118 01 9000 1 91941 A
203818471471471504041Z62126186481 727 AA 000020 1 91941 A
203818471471471504041Z62126186481 078 AA 000020 1 91941 A
|
|
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Simple. Don't send "non-display" data to a non-Mainframe system. Some of the values in your packed-decimal fields get interpreted as control-codes. Even if not damaged in that way, your data becomes scrambled.
Make the packed-decimals DISPLAY NUMERIC and all will be fine. If signed, even putting the sign separately is better and more flexible. |
|
Back to top |
|
|
kranthikumarb
Active User
Joined: 02 Jan 2009 Posts: 115 Location: Hyderabad
|
|
|
|
Thank you for your response. The file will be apended with some values by unix scripts and sent back to z/os. This file again is used in some programs which use these packed decimal data.
So I removed these packed data (not sending to unix). But creating a separate file to be used by other program that uses the file from unix.
Thanks again for your suggestion. Any word on the first issue.
It fails with JCL error some times and it doesn't fail some times. The same JCL is submitted in both instances. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Well, since you've not shown what you have for jobsetp COMPOUT, it is difficult to say. |
|
Back to top |
|
|
kranthikumarb
Active User
Joined: 02 Jan 2009 Posts: 115 Location: Hyderabad
|
|
|
|
Sending displayable chars is not allowed due to some very specific application constraints. The file comes back from unix and the same PD values are being used in mainframe again.
I am surprised to see some rows being written properly and some not. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Well, as explained already, I'm entirely unsurprised as it will just plain not work.
Packed-decimal is not EBCDIC. EBCDIC is byte-oriented. Packed-decimal is a separate conventional representation of bit patterns, and, happily for us, IBM Mainframes have machine-code instructions which directly understand it.
However, since it is not EBCDIC and you are transferring it to an ASCII system, if you convert it to ASCII you'll scramble the data and get some bytes treated as control codes. If you don't convert it to ASCII you'll get some bytes treated as control codes. Note that it is only how you are viewing the data, because whatever you are using is interpreting the control codes.
The position of what is interpreted as a control code varies, because it is the content which is being treated as a control code.
It is good practice to only send data that is required to another system. So if they don't need the packed fields (or anything else) don't send them. If it's a nice lazy way to do it, just check it is OK with your auditors, legal and compliance. You may get lucky for an internal system. |
|
Back to top |
|
|
kranthikumarb
Active User
Joined: 02 Jan 2009 Posts: 115 Location: Hyderabad
|
|
|
|
I understand what you are saying. But here is whats happening.
I am sending 100 records that has PD at the end. Some processing happens at unix and appends some data after PD and sends it back. Now based on the PD data my MF programs process the data appended at the end after PD.
I tried to remove PD and have them as spaces and have all PD into a separate file. So I have 100 records in both files. I planned to sort those when the data is added at the end by unix. But unfortunately I don't get all 100 records from unix. I get only few of them which are qualified for unix processing.
I also tried to convert those PD to TEXT and send it to unix, that is increasing the record length which unix process doesn't like. Cant change the unix process to accept a higher record length file, because that is being used by many users (like a common service process).
So I am kind of stuck. I'll post the answer If I find a way to get away with this. I request experts in this forum also to please help me if you have a way.
Thanks. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Where you tried setting the PDs to space, did you also confirm that there were no other "computational" fields in the records?
If you are only getting returned the records which are processed, either there is an error on that end which needs to be fixed, or there is an update of understanding on your side that you are only going to get a sub-set of records returned. Maybe. |
|
Back to top |
|
|
kranthikumarb
Active User
Joined: 02 Jan 2009 Posts: 115 Location: Hyderabad
|
|
|
|
Quote: |
did you also confirm that there were no other "computational" fields in the records?
|
Yes I have PD in the middle. They are sent and returned as is. At the end also I have PD but not all of them have this issue. This is what is making it more puzzling.
Quote: |
If you are only getting returned the records which are processed, either there is an error on that end which needs to be fixed
|
I tried dummying out the process. I am still getting the same values. Infact, the issue is while sending the data to unix itself, i.e. before processing starts on unix. I viewed the file via 3.17 in TSO before process on the unix started. |
|
Back to top |
|
|
kranthikumarb
Active User
Joined: 02 Jan 2009 Posts: 115 Location: Hyderabad
|
|
|
|
Sorry for invoking an old post. But, I am posting this just incase if someone is looking for a solution for something like this.
Code: |
//SYSTSIN DD *
ocopy indd(INMVS) outdd(OUTHFS) TEXT CONVERT((BPXFX311)) FROM1047
/*
|
I am using the above conversion to convert everything I am sending. Let the existing process take the data, process it and create output in binary format. When getting the file back from unix to MF, I am using the reverse conversion shown below.
Code: |
//SYSTSIN DD *
ocopy indd(INHFS) outdd(OUTMVS) TEXT CONVERT((BPXFX311)) TO1047
/*
|
This way I am using PD data to send and get.
I really appreciate every one's help and support on this. |
|
Back to top |
|
|
|