Gil, thanks. Yes, I am modifying (actually, repeatedly building on the fly) the member itself in the PDS referenced by JCLLIB, not changing the member name in the INCLUDE statement.
This is not some "I think I'll improve the user's job" sort of thing. This is a test process for a batch product. I've got 20 or so jobs that exercise the product in various ways, and then I have been using two INCLUDE files to parametize certain aspects of those jobs, so by commenting out or "un-commenting" certain defined statements in the INCLUDE files, the total number of variations in the whole suite is quite high: Does feature X work? Does feature X work if you also turn on option A? Etc. I have been doing this manually, working from a checklist: - Set the INCLUDE files in a certain way. - Run a certain six jobs and watch for zero return codes - Make certain modifications to the INCLUDE files - Run a specific set of seven jobs And so forth. I'm getting bored with this three-hour manual process, and boredom makes it more likely that I skip some step and thereby skip some part of the release regression test, or OTOH generate a false error that ruins my day until I figure out it is a testing error, not a last minute software bug. So I'm trying to automate it. (Automate just the submission part -- I can scan ISPF pretty quickly for seventy 0000 return codes.) I have an exec that effectively does the INCLUDE file modifications (building), and then I started on a "meta" script to drive the whole thing: - Build the INCLUDE files a certain way - Submit six specific jobs - Build the INCLUDE files in a certain variant way - Submit seven specific jobs Etc. So these are not "general purpose" INCLUDE files that I am whacking on. Are there other ways I could do this? Of course. Could I build the entire test job on the fly? I suppose so, but that is a major change from what I am doing today. Building test jobs that will run in a development environment in a constant way and give a can't-miss zero or not, go or no-go return code is not a trivial process, and I don't find it to be much fun. I really want to minimize the re-do of that part. Unfortunately, in the current setup, the jobs in question don't INCLUDE the subject INCLUDE files directly, they're nested (only one deep!) in INCLUDEs that have certain "constant" (for a given round of testing) things like the load library name, but I suppose I can work with that somehow. Thanks again, Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, October 16, 2006 4:41 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Collisions between converter(?) and TSO? In a recent note, Tony Harminc said: > Date: Mon, 16 Oct 2006 17:35:35 -0400 > > > Are you implying that the basic job file is completely read > > before the TSO SUBMIT command returns to the issuer? In other words, that > > the following sequence would be safe? > > > > "SUB X.CNTL(ABC)" > > Allocate, modify, and free X.CNTL(ABC) Your OP said "Modify a JCL INCLUDE used by the job." I take this to mean you're updating the INCLUDE member in JCLLIB, rather than changing the member named in the "INCLUDE" in the primary JCL. > > "SUB X.CNTL(ABC)" > I'd place far less weight on Tony's "Sure" than on "Some time later, ... the converter ... may read INCLUDE members ..." This strikes me as a major serialization hazard -- you don't know how many additional jobs you may have submitted and how many times you have updated the INCLUDE member in vain before the converter gets around to reading the INCLUDE member for the first job. Since you're in a script anyway, I'd recommend scanning for the "INCLUDE", converting it to a comment, and copying the INCLUDE member inline, modifying on the fly. Serialization concerns vanish, and you need never modify the primary copy of the INCLUDE member. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
