(Our actual ICETOOL application is much more complicated; I've dramatically simplified the example to illustrate my question.)
We are executing an assembler application that invokes ICETOOL via the TOOLIN interface. The temporary datasets T1 and T2 are both allocated from the same STORCLAS. Algorithmically, T1 and T2 have nothing to do with each other; i.e., after ICETOOL is finished with T1, and starts using T2, it doesn't need the data in T1. However (unless I'm missing something) I have to allocate both T1 and T2. What I'm wondering is if I can somehow get away with using only one temporary dataset, or if I can somehow inform DFSORT that I'm "finished" with T1, so that it can reuse the same disk space. Please note that the LRECL for T1 and T2 may be different.
If I were writing this entire application in assembler, and not invoking ICETOOL at all, I would dispense with the DD statements entirely. I would dynamically allocate T1, create OUTFILEA, then dynamically unallocate T1. Then I would do the same thing for OUTFILEB, again using T1 as my temporary dataset. I wouldn't need T2 at all. I just can't figure out how to do that given the TOOLIN above, or if it's even possible.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
Please note that the LRECL for T1 and T2 may be different.
I think this is a JCL question, not a DFSORT question. I suspect that once you use T1 with a specific LRECL, that LRECL is still in the DSCB when the T1 data set is used again so that original LRECL is still used.
I tried an experiment where I just used the same T1 with DISP=(,PASS). The first input file had LRECL=40 and the second input file had LRECL=60. When I copied the LRECL=40 data set to T1, T1 was given LRECL=40 and had just the File1 records. When I copied the LRECL=60 data set to T1, T1 just had the File2 records, but it still had LRECL=40 instead of LRECL=60. I don't know how you could 'cancel out' the first LRECL given to T1 so a different LRECL could be given to T1 the next time. But I'm not a JCL expert. Maybe somebody else knows a way to do that.
I think this is a JCL question, not a DFSORT question. I suspect that once you use T1 with a specific LRECL, that LRECL is still in the DSCB when the T1 data set is used again so that original LRECL is still used.
Frank,
I think you're right about the DSCB, but I don't think that a JCL solution can exist. I can't imagine what I could put into the JCL that would effectively cause a dynamic modification of the LRECL on a subsequent OPEN.
I recreated your test using T1 only, and I got the same results as you. I then tried this:
Code:
OPTION NOSOLRF
RECORD LENGTH=(60,60,60,60,60)
but nothing changed. I also took out the OPTION override and that didn't work either. Nothing changes the original LRECL of 40.
At what point does DFSORT do the OPEN of an output dataset? If I write an E11 exit and programmatically modify the LRECL in the DSCB for T1, might that be an early enough intervention such that it would work? (You might reasonably tell me to just try it.)
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
If the data set already exists and has an LRECL, DFSORT will use that LRECL. I don't see how an E11 exit could change that or how knowing the point at which DFSORT does the OPEN would help.
For the first COPY, DFSORT creates the T1 output data set with the calculated LRECL. For every subsequent use of T1, DFSORT gets and uses that LRECL. The only way to override it would be to specify a different LRECL for T1, but obviously you can't do that if you're trying to use T1 for different LRECLs. DFSORT control statements will not override that LRECL.
As I said, I'm not a JCL expert, but I don't see a way to do what you want due to the way data set attributes work.
For the first COPY, DFSORT creates the T1 output data set with the calculated LRECL. For every subsequent use of T1, DFSORT gets and uses that LRECL.
Okay, got it. I assume that by "every subsequent use" you mean every subsequent use during that invocation of ICETOOL, correct?
My application program calls ICETOOL programmatically via the TOOLIN interface. Suppose I were to change my application to call ICETOOL twice (with different TOOLIN control cards each time, obviously). Suppose further that in between those two ICETOOL calls, I dynamically unallocate and reallocate T1 with a different LRECL. DFSORT would surely use the new T1 LRECL the second time, correct?
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Yes, ICETOOL only sees the data set that is allocated at the time it is invoked. So if you deallocate and reallocate T1 in between calls, ICETOOL would see that as a new T1.
