Joined: 16 May 2005 Posts: 9 Topics: 2 Location: Somewhere on Earth.. :-)
Posted: Wed Sep 29, 2010 10:04 am Post subject: Writing Detail records and a new Summary record
Hi all,
Can somebuddy give me your hand on solving this problem?
My task is to find out how frequent the programs are being installed into the production environment. For an instance, the program AAAA is installed into the production environment 10 times (4 times for the "project 1" and 6 times for the "project 2").
I have written a assembly program to get the different details along with the Program name, Project name and Installation date and generated the following file.
O/p file from assembly program (LRECL 130):
Code:
AAAAProj1 2010-10-01xxxxxx (<--has other details)
AAAAProj2 2010-10-01xxxxxxxxx
AAAAProj2 2010-10-01xxxxxxxxx
(Included a 'space' here for better readability)
BBBBProj32009-01-01xxxxxxxxx
BBBBProj32009-01-01xxxxxxxxx
BBBBProj32009-01-01xxxxxxxxx
BBBBProj12009-01-01xxxxxxxxx
This is not giving the same result what I am expecting. I know I am doing some stupied mistakes but not able to figure out how to fix this problem! At present, I am reading the manual to check is their anyway to solve this issue.
Please do let me if you have any thoughts on this!
Note:
At present, the TRAILER3 section contains the following:
1. Program Name
2. No. of times it is installed for the given 'project'
3. Total number of times the program installed into the production environment. I am yet to update the following phrase in the TRAILER3 section. Let me try to get the desired result first and then I believe it will be easy for me to incorporate the below phrase.
Module <XXXX> shipped <N> times
Module <XXXX> shipped <NX> due to the <project>
Module <XXXX> shipped <NX> due to the <project>
Summary record contents:
1. Program Name
2. Number of times the program installed for the PARTICULAR project.
3. Total number of times the program is installed into the production
Quick Explanation: This is not exactly producing the result what I want. For example, my JCL is not producing the summary record for the first AAAA entry (AAAAPROJ12010-10-01). The summary record is producing only for the last instance of the program AAAA. Also, it is not writing all the detail records into the o/p file (along with the summary record). Will try to check the forum again to see has anybody come across such problems!
@Sqlcode: There is not limit on the projects. For example, a given program can be edited many times over the years for different projects.
Joined: 26 Nov 2002 Posts: 12367 Topics: 75 Location: San Jose
Posted: Fri Oct 01, 2010 11:20 am Post subject:
mmprasadh,
It gets trickier with 2 level break and also the detail records to accommodate in a single pass of data. Here is a 2 step approach which will give you the desired results
Joined: 16 May 2005 Posts: 9 Topics: 2 Location: Somewhere on Earth.. :-)
Posted: Mon Oct 04, 2010 11:39 am Post subject:
Thanks a bunch Kolusu!
A quick question? I tried to run the above JCL and received the following error:
Code:
ICE201I G RECORD TYPE IS F - DATA STARTS IN POSITION 1
ICE230A 0 135 BYTE HEADER/TRAILER RECORD EXCEEDS 130 BYTE LRECL FOR SORTOUT
ICE751I 0 C5-K51707 C6-K51707 C7-K51707 C8-K51707 E9-K51707 E7-K51707
ICE052I 3 END OF DFSORT
Note:My input files LRECL is FB 130 bytes
Then, I've included the DCB in SORTOUT DD and ran the job. It went through!
Is this correct? It means, DFSORT will throw the error message if the LRECL of SORTOUT is more than the LRECL of the SORTIN. And we need to explicitly code the DCB of the SORTOUT in the JCL!
Joined: 16 May 2005 Posts: 9 Topics: 2 Location: Somewhere on Earth.. :-)
Posted: Mon Oct 04, 2010 11:44 am Post subject:
A correction on my previous update! I've rephrased my understanding again!
DFSORT will throw the error message if the LRECL of SORTOUT is NOT EQUAL to the LRECL of the SORTIN! I believe, we need to explicitly code the DCB of the SORTOUT in the JCL if their is a difference in LREC?
Joined: 26 Nov 2002 Posts: 12367 Topics: 75 Location: San Jose
Posted: Mon Oct 04, 2010 11:47 am Post subject:
Quote:
Is this correct? It means, DFSORT will throw the error message if the LRECL of SORTOUT is more than the LRECL of the SORTIN. And we need to explicitly code the DCB of the SORTOUT in the JCL!
mmprasadh,
No. You don't have to explicitly code the LRECL in the JCL. Use the BUILD, OVERLAY, IFTHEN, or IFOUTLEN operand to force a length for the data records that is longer than any report record, and either let DFSORT compute and set the LRECL, or ensure that the computed LRECL is equal to the existing or specified LRECL.
Your input file length is 130 , so DFSORT assumes that your header/trailer are also within that limit. If you have header/trailer greater than 130 , use BUILD/OVERLAY to specify the length.
If your input lrecl is 130 why are you creating a 135 byte header/trailer? And which step are you trying to do this? _________________ Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Joined: 16 May 2005 Posts: 9 Topics: 2 Location: Somewhere on Earth.. :-)
Posted: Mon Oct 04, 2010 6:31 pm Post subject:
Excuse me Kolusu!
As per your JCL, I've created the 130 FB input file and ran your JCL. But, it has thrown me the error message which I've shared you the details on my previous post. Then, I've included the DCB parameter in the SORTOUT DD of the step STEP0100 and ran the job successfully.
OUTFIL FNAMES=LVLBRK,REMOVECC,NODETAIL,
SECTIONS=(1,9,
TRAILER3=('MODULE ',1,4,' SHIPPED ',COUNT=(M10,LENGTH=5),
'X DUE TO THE ',5,5,131:131,4,C'4',/,131:1,4,C'5'))
//*
I think we need to include DCB in SORTOUT DD since we are updating the count from Pos.131 to 135?
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Mon Oct 04, 2010 7:03 pm Post subject:
When I run the equivalent of your job without the DCB parameters using DFSORT, it runs just fine. Please remove the DCB parameters, run the job again, and show the complete JES log here. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Joined: 26 Nov 2002 Posts: 12367 Topics: 75 Location: San Jose
Posted: Mon Oct 04, 2010 7:24 pm Post subject:
mmprasadh,
I am guessing that your site has changed the default for the SOLRF option from YES to NO which does not let DFSORT calculate the length from INREC/OUTREC/OUTFIL.
Change this statement
Code:
OPTION COPY
to
Code:
OPTION COPY,SOLRF
and re-run your job removing the LRECL in JCL. Now DFSORT should automatically calculate the length for you. _________________ Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Joined: 16 May 2005 Posts: 9 Topics: 2 Location: Somewhere on Earth.. :-)
Posted: Mon Oct 11, 2010 5:44 pm Post subject:
Very sorry for the delayed reply Kolusu! Was very busy on production related issues.
I have tried your suggestion of including the option SOLRF in the SORT card but still it is giving the same error message. I have posted the below error message FYR.
Code:
ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R10 - 16:43 ON MON OC
OPTION COPY,SOLRF
OUTREC OVERLAY=(131:1,4,C'1')
OUTFIL REMOVECC,
SECTIONS=(1,4,
TRAILER3=(131:1,4,C'2',/,'MODULE ',1,4,' SHIPPED ',
COUNT=(M10,LENGTH=5),' TIMES',131:131,4,C'3'))
OUTFIL FNAMES=LVLBRK,REMOVECC,NODETAIL,
SECTIONS=(1,9,
TRAILER3=('MODULE ',1,4,' SHIPPED ',COUNT=(M10,LENGTH=5),
'X DUE TO THE ',5,5,131:131,4,C'4',/,131:1,4,C'5'))
ICE201I G RECORD TYPE IS F - DATA STARTS IN POSITION 1
ICE230A 0 135 BYTE HEADER/TRAILER RECORD EXCEEDS 130 BYTE LRECL FOR SORTOUT
ICE751I 0 C5-K51707 C6-K51707 C7-K54603 C8-K51707 E9-K51707 E7-K51707
ICE052I 3 END OF DFSORT
Infact, the pos.131-135 is being used to maintain the count of the modules. So, I should not get such error message. Interestingly, I am didn't get any error message when I ran the ICETOOL JCL ( that I've posted you initially). Please do let me know if I miss anything!
Note: I am using the input with LRECL as 130.
Hi Kolusu,
I have one more query on this!
The report should be formatted in a sequential order with most
Joined: 26 Nov 2002 Posts: 12367 Topics: 75 Location: San Jose
Posted: Tue Oct 12, 2010 11:21 am Post subject:
mmprasadh,
I couldn't replicate your error on my system. Can you send the complete sysout along with jes messages from the 2(the one you said works with icetool and the other which doesn't) jobs to skolusu@us.ibm.com ? We will take a look at it
It is very easy to get the report as you want but lets fix the initial issue. _________________ Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Joined: 16 May 2005 Posts: 9 Topics: 2 Location: Somewhere on Earth.. :-)
Posted: Mon Oct 18, 2010 10:52 am Post subject:
Hi Kolusu,
I sent a mail to you with all the details. Just done few more testing and found that the job is erroring with U0016 if and only if I don't give the DCB for the SORTOUT DD. But, I changed the JCL to write the intermediate records into the new DD called SORTOUTX (instead of SORTOUT) and ran the job. It went through and received the expected output!
I am really not sure whether the DCB parameter should be coded to the SORTOUT DD all the time.
OUTFIL FNAMES=LVLBRK,REMOVECC,NODETAIL,
SECTIONS=(1,9,
TRAILER3=('MODULE ',1,4,' SHIPPED ',COUNT=(M10,LENGTH=5),
'X DUE TO THE ',5,5,131:131,4,C'4',/,131:1,4,C'5'))
//*
Also, my requirement has slightly changed but I am curious to know the DCB issue first. I will then post my 'requirment change' separately.
Once again thanks to Kolusu and to all! Please do provide some light on this!
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
