Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Reg. issue in ICETOOL step with DSN backref

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> DFSORT/ICETOOL
View previous topic :: :: View next topic  
Author Message
raviraman sr

New User


Joined: 29 Apr 2008
Posts: 5
Location: U.S.

PostPosted: Thu May 01, 2008 7:39 pm    Post subject: Reg. issue in ICETOOL step with DSN backref
Reply with quote

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

CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Thu May 01, 2008 7:55 pm    Post subject:
Reply with quote

Could this be the know problem with concatinated multivolume datasets?
My search couldn't find it (yet)...... icon_cry.gif
Back to top
View user's profile Send private message
Frank Yaeger

DFSORT Moderator


Joined: 15 Feb 2005
Posts: 7130
Location: San Jose, CA

PostPosted: Thu May 01, 2008 9:09 pm    Post subject:
Reply with quote

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

New User


Joined: 29 Apr 2008
Posts: 5
Location: U.S.

PostPosted: Thu May 01, 2008 9:31 pm    Post subject: Reg. issue in ICETOOL step with DSN backref
Reply with quote

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

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Thu May 01, 2008 9:44 pm    Post subject:
Reply with quote

Frank,

Just to get this clear, Specifically, when a new output data set is allocated with a unit count and volume count greater than one, but specifies no volume serial numbers, one volume is allocated. If a second or succeeding DD statement within the same step requests the same data set, the same volume is allocated to it. If this job step extends the output data set to more volumes, this new volume information is not available to the second or succeeding DD statement., the "second or succeeding DD statement" are output that will be concatenated as input together?

Thanks in advance,
Bill
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu May 01, 2008 9:50 pm    Post subject:
Reply with quote

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

DFSORT Moderator


Joined: 15 Feb 2005
Posts: 7130
Location: San Jose, CA

PostPosted: Thu May 01, 2008 10:04 pm    Post subject:
Reply with quote

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

DFSORT Moderator


Joined: 15 Feb 2005
Posts: 7130
Location: San Jose, CA

PostPosted: Thu May 01, 2008 10:11 pm    Post subject:
Reply with quote

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

New User


Joined: 29 Apr 2008
Posts: 5
Location: U.S.

PostPosted: Thu May 01, 2008 11:28 pm    Post subject: Reg. issue in ICETOOL step with DSN backref - Reply
Reply with quote

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

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu May 01, 2008 11:40 pm    Post subject:
Reply with quote

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

DFSORT Moderator


Joined: 15 Feb 2005
Posts: 7130
Location: San Jose, CA

PostPosted: Thu May 01, 2008 11:44 pm    Post subject:
Reply with quote

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

Global Moderator


Joined: 14 Mar 2007
Posts: 8593
Location: Back in jolly old England

PostPosted: Fri May 02, 2008 12:06 am    Post subject:
Reply with quote

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

DFSORT Moderator


Joined: 15 Feb 2005
Posts: 7130
Location: San Jose, CA

PostPosted: Fri May 02, 2008 12:35 am    Post subject:
Reply with quote

Why - are you trying to avoid MOD data sets too?
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Fri May 02, 2008 12:48 am    Post subject: Re: Reg. issue in ICETOOL step with DSN backref - Reply
Reply with quote

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

DFSORT Moderator


Joined: 15 Feb 2005
Posts: 7130
Location: San Jose, CA

PostPosted: Fri May 02, 2008 1:08 am    Post subject:
Reply with quote

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

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Fri May 02, 2008 1:29 am    Post subject:
Reply with quote

Frank Yaeger wrote:
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.
Excellent point, after rereading, I have to agree, unless there is something that the (fill in the name of the correct process here) does differently during the referback as opposed to having full and direct access to the cataloged information....
Quote:
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?
Maybe we can get 'raviraman sr' to test it?
Back to top
View user's profile Send private message
raviraman sr

New User


Joined: 29 Apr 2008
Posts: 5
Location: U.S.

PostPosted: Fri May 02, 2008 2:47 am    Post subject: Re: Reg. issue in ICETOOL step with DSN backref - Reply
Reply with quote

Hi,

Do you think the below would work if the files (TEMPOUT*) being created is in the same step? I was of the opinion that the below would not work and this is the reason I thought Splice Operator Examples had it as a back reference.

Am I wrongly interpreting this?

Code:

//MRGINPUT DD DISP=(SHR),                     
//            DSN=&USER..TEMPOUT1
//*                                           
//         DD DISP=(SHR),                     
//            DSN=&USER..TEMPOUT2
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Fri May 02, 2008 3:11 am    Post subject:
Reply with quote

The question came up as to whether or not it was the referback, i.e.,
//MRGINPUT DD DISP=(SHR),
// DSN=*.SORTOF01
or just any reference to a dataset created in the same step. i.e.,
//MRGINPUT DD DISP=(SHR),
// DSN=&USER..TEMPOUT1
that is causing the loss of data....

Based upon your original JCL, see if you have a setup that (regularly) fails with the referback (*.SORTOF01), then try to see if it fails (regularly) with the actual DSN (&USER..TEMPOUT1).

And, unless it is needed, drop the 'VOL=REF=*.SORTOF01' in both cases, (unless somebody knows why it should be needed?)......

Or try it in both, who knows, that may be the culprit....grin.....


Dang, I love debugging...... icon_lol.gif
Back to top
View user's profile Send private message
raviraman sr

New User


Joined: 29 Apr 2008
Posts: 5
Location: U.S.

PostPosted: Fri May 02, 2008 7:44 am    Post subject: Reg. Dataset Refer back
Reply with quote

Hi ,

I have attempted the below earlier and it will give JCL interpreter error for dataset not found. I originally had only temp datasets (&&TEMP**) for the "throwaway" files but due to my site restrictions I catalogued with 2 days retention.

When referred with DISP=SHR as below

Code:

//MRGINPUT DD DISP=(SHR),
// DSN=&USER..TEMPOUT1


The JCL Interpreter tries to check whether the file is in catalogue. Since it is not found/created in the prev. step, it throws up interpreter error.

Only way I think this can be overcome is by specifying DISP=MOD which we will have to check with our assurance team.

Thanks again for your help.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Fri May 02, 2008 8:03 am    Post subject:
Reply with quote

Hello Ravi,

Thank you for posting what you learned - Good luck icon_smile.gif

Someone will be here if there are new "opportunities icon_wink.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> DFSORT/ICETOOL All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts DFHRESPONSE returns issue divated CICS 3 Wed Nov 02, 2016 6:32 pm
No new posts How to delete second instance from Fl... Gunapala CN DFSORT/ICETOOL 6 Tue Oct 18, 2016 11:42 pm
No new posts Can sending 5 MB data between cobol p... Kevin Vaz CICS 12 Tue Oct 18, 2016 4:50 pm
No new posts ICETOOL/SYNCSORT - SYSPRINT output nartcr DFSORT/ICETOOL 17 Wed Oct 05, 2016 10:46 pm
No new posts Icetool or Joinkeys example to compar... ishant chauhan DFSORT/ICETOOL 21 Sat Aug 20, 2016 2:40 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us