IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Issue while copying dataset fom Z/OS to HFS


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
kranthikumarb

Active User


Joined: 02 Jan 2009
Posts: 115
Location: Hyderabad

PostPosted: Fri Aug 29, 2014 6:44 am
Reply with quote

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
View user's profile Send private message
kranthikumarb

Active User


Joined: 02 Jan 2009
Posts: 115
Location: Hyderabad

PostPosted: Fri Aug 29, 2014 8:24 am
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri Aug 29, 2014 12:10 pm
Reply with quote

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
View user's profile Send private message
kranthikumarb

Active User


Joined: 02 Jan 2009
Posts: 115
Location: Hyderabad

PostPosted: Fri Aug 29, 2014 12:20 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri Aug 29, 2014 1:39 pm
Reply with quote

Well, since you've not shown what you have for jobsetp COMPOUT, it is difficult to say.
Back to top
View user's profile Send private message
kranthikumarb

Active User


Joined: 02 Jan 2009
Posts: 115
Location: Hyderabad

PostPosted: Fri Aug 29, 2014 1:55 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri Aug 29, 2014 2:29 pm
Reply with quote

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
View user's profile Send private message
kranthikumarb

Active User


Joined: 02 Jan 2009
Posts: 115
Location: Hyderabad

PostPosted: Fri Aug 29, 2014 2:48 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Fri Aug 29, 2014 6:16 pm
Reply with quote

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
View user's profile Send private message
kranthikumarb

Active User


Joined: 02 Jan 2009
Posts: 115
Location: Hyderabad

PostPosted: Fri Aug 29, 2014 6:22 pm
Reply with quote

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
View user's profile Send private message
kranthikumarb

Active User


Joined: 02 Jan 2009
Posts: 115
Location: Hyderabad

PostPosted: Thu Sep 25, 2014 8:26 pm
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts SFTP Issue - destination file record ... All Other Mainframe Topics 2
No new posts FINDREP - Only first record from give... DFSORT/ICETOOL 3
No new posts Map Vols and Problem Dataset All Other Mainframe Topics 2
No new posts Allocated cylinders of a dataset DB2 12
No new posts Sort First/last record of a subset th... DFSORT/ICETOOL 7
Search our Forums:

Back to Top