I'm honestly not sure whether my question pertains more to ICETOOL, JCL, or both... but here goes.
I need to execute an ICETOOL application beginning with
COPY FROM(INFILE) ...etc
INFILE will already exist; in fact, it is the logical concatenation of several preexisting datasets. These datasets will be different each time the application runs. I don't want to have to change the JCL each time I run the ICETOOL job; i.e., I don't want to have to change the DD statement for INFILE each time I execute the ICETOOL step.
However, I can programmatically deduce what the input DSNs are that comprise INFILE. So I wrote a standalone assembler application that uses SVC 99 to dynamically allocate and concatenate all of the datasets into a single logical concatenation. Let's call that job step ALLOCATE. My concept is that I would execute the ALLOCATE step just prior to the ICETOOL step.
What I can't figure out is how to make the ICETOOL step aware that INFILE was previously dynamically allocated in step ALLOCATE. I suppose I will need a DD statement in the ICETOOL step for INFILE, but I can't figure out how to write it. I can't just do a referback to the ALLOCATE step, because there is no DD statement to refer back to.
Alternatively, I was wondering whether I could move my dynamic allocation code to execute under ICETOOL itself, perhaps within an E11 exit. Then I could do away with the ALLOCATE step entirely.
I hope this isn't too vague... please let me know if I need to clarify anything further.
a quick and dirty idea...
why not write a front-end <thing> to allocate the needed datasets and call/link icetool??
to simplify everybody' s life it could be a simple REXX script
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
Alternatively, I was wondering whether I could move my dynamic allocation code to execute under ICETOOL itself, perhaps within an E11 exit. Then I could do away with the ALLOCATE step entirely.
Yes you can, but within your program, not within an exit. You can add a call to ICETOOL to your program after your dynamic allocation code. So you dynamically allocate your data sets with a ddname of your choosing and then use that ddname in the ICETOOL control statements where needed.
You can call ICETOOL from your own program in two different ways as documented at:
Thank you for the quick response and for that suggestion; I see what you're saying.
However, I need to ask about the performance implications of that approach. From the DFSORT Application Programming Guide, p. 728: "You can enhance performance by invoking DFSORT with JCL instead of invoking it from a COBOL or a PL/I program. Generally, COBOL or PL/I is used for convenience. However, the trade-off can be degraded performance."
Our application calling ICETOOL would be written in assembler; I don't know if that makes a difference (i.e., over a high-level language). Regardless, this is going to be a relatively complex ICETOOL application involving lots of sorting, splicing, joining, averaging, etc. The input dataset might be approximately 10 million records, and I would anticipate dozens of ICETOOL operators in TOOLIN, with an execution time which may end up being measured in hours (as opposed to minutes). I'm not far enough along yet to do any serious benchmarking, but you see what I mean.
So my question is: are we going to suffer noticable performance degradation if we invoke ICETOOL from within an assembler program, rather than standalone? If so, then I suppose an alternative would be to dynamically allocate everything in the first step, read all 5 million records, and write them to a temporary dataset, which I could then pass to the next (standalone) ICETOOL step. That means having to read all of the records all over again within ICETOOL. It all depends on how expensive it is to invoke ICETOOL from within the assembler program itself.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
are we going to suffer noticable performance degradation if we invoke ICETOOL from within an assembler program, rather than standalone?
No.
Quote:
You can enhance performance by invoking DFSORT with JCL instead of invoking it from a COBOL or a PL/I program. Generally, COBOL or PL/I is used for convenience. However, the trade-off can be degraded performance
COBOL and PL/I use their own internal exits - that's what can cause the performance degradation. Your Assembler program calling DFSORT will not be using its own exits. Note that COBOL's FASTSRT option eliminates the exits for COBOL calls to DFSORT.
