|
|
| Author |
Message |
raviraman sr
New User
Joined: 29 Apr 2008
Posts: 5
Location: U.S.
|
|
|
|
Mr. Frank Yeager,
We have a peculiar situation where we thought ICETOOL to abend but it did not. We take in two different files in one ICETOOL step and assemble both to a common layout on two temp files. Then we back reference the temp files in the same step to concatenate the derived files to one output file.
Please find the code we use below:
| Code: |
//STEPXXR EXEC PGM=ICETOOL
//*
//DDDDDDD1 DD DSN=INPUT1,DISP=SHR
//*
//DDDDDDD2 DD DSN=INPUT2,DISP=SHR
//*
//SORTOF01 DD DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,
// DCB=(LRECL=50,BLKSIZE=27950,RECFM=FB),
// LABEL=RETPD=005,
// SPACE=(TRK,(45,5),RLSE),
// DSN=&USER..TEMPOUT1
//*
//SORTOF02 DD DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,
// DCB=(LRECL=50,BLKSIZE=27950,RECFM=FB),
// LABEL=RETPD=005,
// SPACE=(TRK,(45,5),RLSE),
// DSN=&USER..TEMPOUT2
//*
//MRGINPUT DD DISP=(SHR),
// VOL=REF=*.SORTOF01,
// DSN=*.SORTOF01
//*
// DD DISP=(SHR),
// VOL=REF=*.SORTOF02,
// DSN=*.SORTOF02
//*
//MRGOUTPT DD DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,
// DCB=(LRECL=50,BLKSIZE=27950,RECFM=FB),
// LABEL=RETPD=005,
// SPACE=(TRK,(45,5),RLSE),
// DSN=&USER..ACTULOUT
//*
//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,100)
//SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,100)
//SORTWK03 DD UNIT=SYSDA,SPACE=(CYL,100)
//*
//CTL1CNTL DD *
*HAS THE REFORMAT CARD TO REFORMAT DD1 TO A 50 BYTE COMMON *LAYOUT
SORT FIELDS=COPY
OUTFIL FNAMES=SORTOF01
OUTREC FIELDS=(01:C'XX',
03:C'X',
04:C'XX',
06:06,08,
14:14,08,
22:01,05,
27:30,01,
28:22,08,
36:15X)
/*
//CTL2CNTL DD *
*REFORMAT SECOND FILE TO A 50 BYTE COMMON LAYOUT
SORT FIELDS=COPY
INCLUDE COND=(43,01,CH,EQ,C'X')
OUTFIL FNAMES=SORTOF02
OUTREC FIELDS=(01:C'XX',
03:24,01,
04:25,02,
06:14,08,
14:35,08,
22:01,05,
27:01X,
28:06,08,
36:15X)
/*
//CTL3CNTL DD *
SORT FIELDS=(1,2,CH,A,22,5,CH,A)
/*
//TOOLIN DD *
COPY FROM(DDDDDDD1) TO(SORTOF01)-
USING(CTL1)
COPY FROM(DDDDDDD2) TO(SORTOF02)-
USING(CTL2)
COPY FROM(MRGINPUT) TO(MRGOUTPT)-
USING(CTL3)
/*
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
|
Since the SORTOF01 and SORTOF02 is allocated less primary space, it uses both primary & secondary space and therefore data gets written to mutliple volumes. Then when we back reference the temp files in MRGINPUT and it chops off several thousand records without even issuing a warning.
Please find my questions below:
1. Can you please suggest a solution on how to back reference if we have files that are on multiple volumes being backreferenced?
2. Could you please confirm on how we can make the SORT card in CTL3CNTL return a non zero return code (or make it abend) if it senses that it is trying to chop off records?
3. Could you please confirm if it is okay to proceed with back reference in any of our furture implementation as it seem to result in unpredictable results like in this one (unless we know answer for Question 1). This taking into consideration that if we had to use splice operator in our project we have to rely on this technique and when we really don't have control over data being written on multiple volumes in DISK? |
|
| Back to top |
|
 |
References
|
 Posted: Thu May 01, 2008 7:39 pm Post subject: Re: Reg. issue in ICETOOL step with DSN backref |
|
|
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 1142
Location: At my desk
|
|
|
|
Could this be the know problem with concatinated multivolume datasets?
My search couldn't find it (yet)......  |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Moderator
Joined: 15 Feb 2005
Posts: 4236
Location: San Jose, CA
|
|
|
|
Ravi,
Yes, this is a known system restriction. DFSORT/ICETOOL is just a "victim" here. For more information, see the second bullet on this page:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CA20/1.8.3.1?SHELF=&DT=20060615185603&CASE=
The current DFSORT books do not use this technique for ICETOOL examples. Instead, we use one MOD data set to avoid referback.
Here's a revised version of your job that avoids referback (I also took the liberty of cleaning up your ICETOOL job in several ways):
| Code: |
//STEPXXR EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//DDDDDDD1 DD DSN=INPUT1,DISP=SHR
//DDDDDDD2 DD DSN=INPUT2,DISP=SHR
//T1 DD DISP=(MOD,CATLG,DELETE),
// UNIT=SYSDA,
// DCB=(LRECL=50,BLKSIZE=27950,RECFM=FB),
// LABEL=RETPD=005,
// SPACE=(TRK,(45,5),RLSE),
// DSN=&USER..TEMPOUT1
//MRGOUTPT DD DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,
// DCB=(LRECL=50,BLKSIZE=27950,RECFM=FB),
// LABEL=RETPD=005,
// SPACE=(TRK,(45,5),RLSE),
// DSN=&USER..ACTULOUT
//TOOLIN DD *
COPY FROM(DDDDDDD1) TO(T1) USING(CTL1)
COPY FROM(DDDDDDD2) TO(T1) USING(CTL2)
SORT FROM(T1) TO(MRGOUTPT) USING(CTL3)
/*
//*
//CTL1CNTL DD *
*HAS THE REFORMAT CARD TO REFORMAT DD1 TO A 50 BYTE COMMON *LAYOUT
OUTREC BUILD=(01:C'XX',
03:C'X',
04:C'XX',
06:06,08,
14:14,08,
22:01,05,
27:30,01,
28:22,08,
36:15X)
/*
//CTL2CNTL DD *
*REFORMAT SECOND FILE TO A 50 BYTE COMMON LAYOUT
INCLUDE COND=(43,01,CH,EQ,C'X')
OUTREC BUILD=(01:C'XX',
03:24,01,
04:25,02,
06:14,08,
14:35,08,
22:01,05,
27:01X,
28:06,08,
36:15X)
/*
//CTL3CNTL DD *
SORT FIELDS=(1,2,CH,A,22,5,CH,A)
/*
|
|
|
| Back to top |
|
|
raviraman sr
New User
Joined: 29 Apr 2008
Posts: 5
Location: U.S.
|
|
|
|
Hi Frank Yeager,
Thanks for the immediate response.
The problem with your suggested solution is that we cannot use disposition of MOD in our installation.
Do you have any other way in which this could be accomplished without using MOD as a disposition?
Also, could you please guide us if question 1 in my first post could resolve this issue - "Can you please suggest a solution on how to back reference if we have files that are on multiple volumes being backreferenced?"
I'm planning to use SPLICE operator in one of my future project and will that be an issue now since I'm planning back reference there as well.
Are you suggesting that back reference should be avoided? |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 1142
Location: At my desk
|
|
| Back to top |
|
|
dick scherrer
Global Moderator
Joined: 23 Nov 2006
Posts: 7517
Location: 221 B Baker St
|
|
|
|
Hello,
| Quote: |
| The problem with your suggested solution is that we cannot use disposition of MOD in our installation. |
There might be a reason to prohibit MOD for production (real) datasets, but what business/technical reason might there be to prohibit MOD for a temporary dataset to be used in only one step?
The jcl shows CATLG for the T1 dataset, but i believe this is a really "throwaway" dataset and is not needed after this step completes. |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Moderator
Joined: 15 Feb 2005
Posts: 4236
Location: San Jose, CA
|
|
|
|
| Quote: |
The problem with your suggested solution is that we cannot use disposition of MOD in our installation.
Do you have any other way in which this could be accomplished without using MOD as a disposition? |
Ravi,
Not sure why you can't use MOD. Has you site just banned MOD data sets arbitrarily?
I'm not a JCL expert, but I would think you could just break up your one ICETOOL step into two ICETOOL steps to avoid backreferencing. For example, have the first ICETOOL step with the first two operators (COPY, COPY) and SORTOF1 and SORTOF2, and have the second ICETOOL step with the third operator (SORT or SPLICE) and MRGINPUT using the SORTOF1 and SORTOF2 data set names rather than referback.
Note that there is no difference in efficiency between using one ICETOOL step or two ICETOOL steps in this way - you're still doing the same number of passes over the data.
| Quote: |
| Are you suggesting that back reference should be avoided? |
I'm stating that there is a system restriction associated with back reference that may affect you. It's a system restriction for any product, not just DFSORT. |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Moderator
Joined: 15 Feb 2005
Posts: 4236
Location: San Jose, CA
|
|
|
|
| Quote: |
| the "second or succeeding DD statement" are output that will be concatenated as input together? |
Not sure what you're asking. The situation is that a second DD statement uses referback for a previous output data set.
In the job shown in the first post, MRGINPUT uses referback for two data sets that are concatenated together. But it would be true if MRGINPUT only referred back to a single data set as well. |
|
| Back to top |
|
|
raviraman sr
New User
Joined: 29 Apr 2008
Posts: 5
Location: U.S.
|
|
|
|
Bill,
Thanks. I see that the only solution from your post could be that by specifying the same volume for SORTOF01 & SORTOF02 files in this particular example. But I think it may not be correct to specify volumes for DASD files. Pls. correct me if I'm wrong??
Dick/Frank,
On your question on why not to use MOD?
------------------------------------------------
The usage of MOD requires special permission from our assurance group. This is the reason I tried not to use MOD. I think there was a technical reason to not to use MOD when such a DD was being referenced in a program invoked through say a DB2 Checkpoint/Restart utility like BMC.
But I can double check to see if we still have this restriction.
Frank,
Thanks again. I see that back reference shall be avoided by splitting to multiple steps. The workaround I'm thinking now is to increase the space to a logic level such that the files are on one volume. But going forward I shall go with splitting the format & copy operation into two steps.
Do you see any better workaround for this problem? |
|
| Back to top |
|
|
dick scherrer
Global Moderator
Joined: 23 Nov 2006
Posts: 7517
Location: 221 B Baker St
|
|
|
|
Hello Ravi,
| Quote: |
| But I can double check to see if we still have this restriction. |
Even if the general restriction still exists, you might talk about an exception for this step as it is a "sort" step and the concern about database and/or restart would not apply. Also, the dataset in queston is for use only within the step, i believe. . . FWIW. |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Moderator
Joined: 15 Feb 2005
Posts: 4236
Location: San Jose, CA
|
|
|
|
| Quote: |
| Do you see any better workaround for this problem? |
The aforementioned use of a MOD data set. Hopefully, you can get permission for that. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 2962
Location: Brussels once more ...
|
|
|
|
| Thanks to this problem being highlighted sometime last year, I took the precaution of ending the ICETOOL step when the datasets were written out to the one dataset and then coding a second ICETOOL step to do the SPLICE / SELECT processing, which worked with no problems. |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Moderator
Joined: 15 Feb 2005
Posts: 4236
Location: San Jose, CA
|
|
|
|
| Why - are you trying to avoid MOD data sets too? |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 1142
Location: At my desk
|
|
|
|
| raviraman sr wrote: |
| Thanks. I see that the only solution from your post could be that by specifying the same volume for SORTOF01 & SORTOF02 files in this particular example. But I think it may not be correct to specify volumes for DASD files. Pls. correct me if I'm wrong?? |
Isn't there a way of specifying only a single SYSDA volume?
And why the referback on input for the VOL=, it is a cataloged dataset, isn't it?
Or how about?
| Code: |
//MRGINPUT DD DISP=(SHR),
// DSN=&USER..TEMPOUT1
//*
// DD DISP=(SHR),
// DSN=&USER..TEMPOUT2 |
You will have the same thing you already have now (when it does work) and won't have the referback potential of missing data.
BTW, && temp datasets and MOD is the more elegant form for this kind of JCL, but, to each his own......grin...... |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Moderator
Joined: 15 Feb 2005
Posts: 4236
Location: San Jose, CA
|
|
|
|
| Quote: |
| won't have the referback potential of missing data. |
Hmmm ... I read through the doc again and I don't see where this is restricted to referback situations. The restriction seems to be for any DD statement that requests the same data set as a previous DD statement for output.
I'm guessing that the same problem can occur with catalogued data sets when referback is NOT used such as in the example you show. Anybody know for sure? |
|
| Back to top |
|
|
|
|
|
