Re: Example of what a very small JCL Interpreter can do to your installation.
On Wed, 30 Jul 2008 08:57:49 -0500, Jeff Holst wrote: Problem came when the 370 arrived and we upgraded to a new COBOL compiler. Now, a character moveof more that 256 characters were compiled as a MVCL. For MVCL, when source and target fields overlap, a condition code is set and no data movement occurs. The new COBOL did not check the return code, the COBOL move statement effectively became a NO-OP. No error statments in the COMPILE and the program would either abend when it later found some field uninitialized or it would produce incorrect results. I once dealt with a compiler from a vendor I mentioned here recently (but didn't name then, either). I looked at the code it generated for a character move. If the leftmost character of the target lay within the source (same criterion as MVCL), it moved character-by- character in a loop, starting at the right of both operands. Otherwise it moved left-to-right, perhaps with MVC or MVCL. The effect was that the final content of the target was identical to the initial content of the source, although the source might be obliterated in the process. How did the RM specify the effect of this painstaking effort? It stated that if the operands overlapped the result was unpredictable. -- gil -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Wed, 30 Jul 2008 09:02:48 -0500, Jeff Holst wrote: On Tue, 29 Jul 2008 09:45:44 -0500, Paul Gilmartin wrote: Hmmm. I wonder what happens when there are two (or more) overriding DD statements referring to the same DDNAME in the PROC. Absent any explicit exclusion, I'd expect from the general description both (all) to be effective, and parameters on them to be merged into the PROC DD. But in what order? Actually, this is covered in the reference manual, as it states that all but the first will be processed for allocation purposes (new data sets will be allocated and the DISP parameter will be honored) but only the first will actually be merged into the PROC DD. Empirically, that seems to be true. But I don't see where it says so in the RM. The governing section would seem to be: 5.2.1.2 z/OS V1R9.0 MVS JCL Reference Coding an Overriding OUTPUT JCL or DD Statement To override, nullify, or add parameters to a procedure OUTPUT JCL or DD statement, code in the name field of the overriding OUTPUT JCL or DD statement the name of the procedure step containing the overridden statement, followed by a period, followed by the name of the procedure OUTPUT JCL statement or the ddname of the procedure DD statement. //pstepname.name OUTPUT parameters //pstepname.ddname DD parameters I don't see an explicit only the first here, so it might equally be read that all overriding DD statements with the name of an overriden statement will be merged with that statement. Likewise, I see nothing in 12.1.2 or 12.1.6 that states that only the first will override. I take the statement: 12.1.2 z/OS V1R9.0 MVS JCL Reference 12.1.2 Name Field When specified, code a ddname as follows: * Each ddname should be unique within the job step. If duplicate ddnames appear in a job step, processing is as follows: + In a JES2 system: The system performs device and space allocation and disposition processing for both DD statements; however, it directs all references to the first DD statement in the step. to govern the use of DD statements appearing in the step, not the overriding dd statements. -- gil -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Wed, 30 Jul 2008 08:57:49 -0500, Jeff Holst wrote: IBM's out was that they had said that the results of the overlappping MOVE were unpredictable, so this did not violate their compatablity statement that programs would be source level compatable if they were coded according to the language reference. As we commented at the time, the results were predictable (the compiler does not take random actions), but the results might change with future releases. I dealt once with a compiler vendor when I had a program that got an error trap which vanished when I enabled debugging/tracing (which then generated unoptimized code). The vendor shrugged and pointed out (accurately) that the construct I misused was documented as having unpredictable (perhaps undefined) effect. Didn't help me much with my debugging. -- gil -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Tue, 29 Jul 2008 10:05:15 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: Copout! This is irresponsible language design. If the JCL developers had any pride of craftsmanship, they would remove all references to unpredictable and unsupported from the language specification by variously either: o Specifying clearly the predictable behavior of supported constructs o Reporting as JCL errors all remaining (unsupported) constructs. As for the compatibility implications of reporting as errors use of constructs that might not work in the future, better that progammers foolishly exploiting such constructs be informed today rather than in the future. I quite agree. I have been in IT for a long time. (We didn't call it IT when I started.) My first job was on an IBM 360, coding in COBOL. I haven't looked at a COBOL reference manual lately, but back at that time it stated that if the source and target fields of a MOVE statement overlapped, the results were unpredictable. However, the compiler did not generate an error - it simply compiled any character move statement (numerics were another matter) as one or more MVC commands. (More than one would be needed if the move involved more than 256 characters.) Programmers would routinely initialize large arrays by initializing the first row and doing an overlapping move. Problem came when the 370 arrived and we upgraded to a new COBOL compiler. Now, a character moveof more that 256 characters were compiled as a MVCL. For MVCL, when source and target fields overlap, a condition code is set and no data movement occurs. The new COBOL did not check the return code, the COBOL move statement effectively became a NO-OP. No error statments in the COMPILE and the program would either abend when it later found some field uninitialized or it would produce incorrect results. IBM's out was that they had said that the results of the overlappping MOVE were unpredictable, so this did not violate their compatablity statement that programs would be source level compatable if they were coded according to the language reference. As we commented at the time, the results were predictable (the compiler does not take random actions), but the results might change with future releases. -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Tue, 29 Jul 2008 09:45:44 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: Hmmm. I wonder what happens when there are two (or more) overriding DD statements referring to the same DDNAME in the PROC. Absent any explicit exclusion, I'd expect from the general description both (all) to be effective, and parameters on them to be merged into the PROC DD. But in what order? Actually, this is covered in the reference manual, as it states that all but the first will be processed for allocation purposes (new data sets will be allocated and the DISP parameter will be honored) but only the first will actually be merged into the PROC DD. -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Mon, 28 Jul 2008 15:58:53 EDT, IBM Mainframe Discussion List wrote: In a message dated 7/28/2008 10:55:50 A.M. Central Daylight Time, PaulG writes: I certainly remember (though obviously not as clearly as Mr. Blair) a day and age when overriding DD statements were required to appear in the same order as the overridden DDNAMEs in the proc. I was delighted to see the constraint relaxed. Suppose someone who does not know that proc X is used by 10 other jobs with overriding DDs in them decides to rearrange the DD statements within proc X. Why ever would anyone do that? Which mode of processing by IBM would be better? Another possibility is that beaucoup jobs use overrides for a universally available vendor proc like ASM, LKED, FDRxxx, CAwhatever, etc., and then the vendor decides to rearrange the DD statements within the distributed machine-readable PROCLIB containing that proc. Yes, I know, we can blame change control when the inevitable errors are found. But it would be better to avoid the errors than to find someone I believe that the recent behavior where overriding DDNAMEs are associated regardless of order would be more robust under such a change than the older behavior where DDNAMEs newly out-of-order would be treated as added rather than overriding. to blame when they occur. This situation seems to me to be analogous to users' building job streams that use output from utilities like IDCAMS as their input and require data set names to begin in column X and volser in column Y, e.g. Then IBM changes the format of the utility's output. And it's not limited to IBM. Data centers also have locally developed programs that generate SYSOUT which is then used as input for other programs, and the developer in charge of a utility cannot be expected to know all the downstream users of his SYSOUT. We have a program that postprocesses assember and binder SYSOUT. It was broken by HLASM and we adapted it. It is further broken by Tachyon, so that to use that postprocessor we revert to HLASM. But it's unthinkable that HLASM wouldn't support 31-bit addressing. Perhaps in some distant future it will even be 64-bit savvy. And there will be LPA above-the-bar. -- gil -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
In a message dated 7/29/2008 3:25:25 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Suppose someone who does not know that proc X is used by 10 other jobs with overriding DDs in them decides to rearrange the DD statements within proc X. Why ever would anyone do that? Possible reasons: 1. When I create JCL, I put my DD statements in alphabetic order by ddname within each step. It helps me find one later if I need to. My JCL is not used by others, so I am free to reorder my own DD statements according to whim. Someone with the same desire to alphabetize everything may cluelessly reorder a proc that others use without understanding the repercussions of what he is doing. 2. People make mistakes regardless of how clueless or anal retentive they are. Maybe somebody is editing a proc, accidentally deletes a DD statement, then realizes his mistake, recreates the now missing DD statement, and puts it in the wrong place because he doesn't remember exactly where it was in relation to the 20 or 30 other DD statements and he doesn't know that exact placement may be critically important. 3. Why would anyone ever do anything stupid? Never. Does that mean that stupid things never happen? 4. My program can never get to this point in the logic, so I don't need any code here to handle this situation. 5. As Donald Rumsfeld said, Stuff happens. Bottom line: software and procedures should be bullet-proof enough to survive situations that occur for reasons that make no sense to those of us who are rational, competent, wise, and blessed with huge amounts of experience. Bill Fairchild Rocket Software **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Mon, 28 Jul 2008 10:55:40 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: I'll sometimes disable a lot of JCL with IF. Which is why I regret that IF FALSE is documented as not supported and unpredictable in behavior (although no error is reported and the construct has (almost) the intuitive effect). If one takes the JCL reference literally, most of the examples they give are in fact not supported and unpredictable. Why? The manual states; A relational-expression consists of: Comparison operators Logical operators NOT (¬) operators Relational-expression keywords. A value, such as 8 in the relationship-expression RC = 8 is none of these. I recently opened an ETR to clarify this, and was told that what they test is relationship-expressions of the form keyword comparison-operator value, in that order. Yet value is not listed as one of the allowed components of a relationship expression. While the documentation does not rule out such expressions as STEP1.RC = STEP2.RC (and it does work), I was told that this was not something that it is not in fact supported and might not work in the future. What prompted my ETR was that I had encontered some installation JCL from CA that contained a construct something like // SET VAR1 = 1 intervening JCL // IF VAR1 = 1 THEN more JCL // ENDIF which works, but CA-JCLCHECK flagged this as an error. After some arguement with CA-JCLCHECK support, where I argued VAR1 is not a keyword (by the time the system evaluates the truth of the expression, it has been replaced by the value 1), and that the JCL Reference was clearly incomplete in its definition, I expressed my observations to IBM in an ETR. -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Thu, 24 Jul 2008 15:56:17 -0500, Jeff Holst wrote: However, on page 5-4 of that same manual it says: Place modifying OUTPUT JCL and DD statements in the following order, after the EXEC statement that calls the procedure: For each procedure step in the invoked procedure: 1. Overriding statements can appear in any order when they explicitly specify the step that is being overridden. Added statements can appear in any order when they specify the step explicitly. Hmmm. I wonder what happens when there are two (or more) overriding DD statements referring to the same DDNAME in the PROC. Absent any explicit exclusion, I'd expect from the general description both (all) to be effective, and parameters on them to be merged into the PROC DD. But in what order? Also, in: 5.2.1.2 z/OS V1R9.0 MVS JCL Reference ___ 5.2.1.2 Modifying OUTPUT JCL and DD Statements ... Supplying In-stream Data for a Procedure To supply a procedure step with data from the input stream, code a DD * or DD DATA statement in the calling step after the last overriding and added DD statement. ... This appears to say that SYSIN DD statements must appear last among overrides. Has this ever been enforced? I hate JCL! -- gil -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Tue, 29 Jul 2008 09:18:54 -0500, Jeff Holst wrote: On Mon, 28 Jul 2008 10:55:40 -0500, Paul Gilmartin wrote: I'll sometimes disable a lot of JCL with IF. Which is why I regret that IF FALSE is documented as not supported and unpredictable in behavior (although no error is reported and the construct has (almost) the intuitive effect). If one takes the JCL reference literally, most of the examples they give are in fact not supported and unpredictable. Why? The manual states; A relational-expression consists of: Comparison operators Logical operators NOT (¬) operators Relational-expression keywords. A value, such as 8 in the relationship-expression RC = 8 is none of these. I recently opened an ETR to clarify this, and was told that what they test is relationship-expressions of the form keyword comparison-operator value, in And even this doesn't cover IF KEYWORD, which is tolerated, whatever its effect. It appears almost as if the developer was considerably more skilled at language design than the tech writer. that order. Yet value is not listed as one of the allowed components of a relationship expression. While the documentation does not rule out such expressions as STEP1.RC = STEP2.RC (and it does work), I was told that this was not something that it is not in fact supported and might not work in the future. Copout! This is irresponsible language design. If the JCL developers had any pride of craftsmanship, they would remove all references to unpredictable and unsupported from the language specification by variously either: o Specifying clearly the predictable behavior of supported constructs o Reporting as JCL errors all remaining (unsupported) constructs. As for the compatibility implications of reporting as errors use of constructs that might not work in the future, better that progammers foolishly exploiting such constructs be informed today rather than in the future. I hate JCL! -- gil -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Fri, 25 Jul 2008 17:56:35 -0500, William H. Blair [EMAIL PROTECTED] wrote: Jeff Holst noted that an IBM SRL states: 1. Overriding statements can appear in any order when they explicitly specify the step that is being overridden. This is apparently the missing documentation. However, it is not completely technically correct, because it is obviously not, in fact, necessary that they explicitly specify the step that is being overridden. Thanks for the heads-up. -- WB If you go on to read the next paragraph it explains what happens when the step is not specified (it uses the step name from the last DD statement that did specify a step name, and if none exists the first step in the proc is overridden.) The paragraph that follows further clarifies things by stating that overriding DD statements must appear in the order of the steps in the proc. It is misleading to take one paragraph in isolation. jh -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Mon, 28 Jul 2008 09:22:03 -0500, Jeff Holst wrote: On Fri, 25 Jul 2008 17:56:35 -0500, William H. Blair wrote: Jeff Holst noted that an IBM SRL states: 1. Overriding statements can appear in any order when they explicitly specify the step that is being overridden. If you go on to read the next paragraph it explains what happens when the step is not specified (it uses the step name from the last DD statement that did specify a step name, and if none exists the first step in the proc is overridden.) The paragraph that follows further clarifies things by stating that overriding DD statements must appear in the order of the steps in the proc. It is misleading to take one paragraph in isolation. I certainly remember (though obviously not as clearly as Mr. Blair) a day and age when overriding DD statements were required to appear in the same order as the overridden DDNAMEs in the proc. I was delighted to see the constraint relaxed. It makes JCL coding easier and more robust because it's easier to spot coding errors because of the decreased likelihood that the coded overriding SYSIN would have no effect. I don't know how long ago the ordering constraint was removed -- it's documented in 5.2.1.2 z/OS V1R1.0 MVS JCL Reference, but surely that's the source of most of the objections in this thread, so I'm puzzled that there was no shrill outcry back then -- it should have created major incompatibilities. But the reordering occurs only when both DDNAMES match DDNAMES in the overridden PROC; else at least one is an added DD statement. Prior to the reordering facility, a misordering would have resulted in a duplicate DDNAME within a step, and I read in 12.1.2 z/OS V1R1.0 MVS JCL Reference: 12.1.2 Name Field When specified, code a ddname as follows: * Each ddname should be unique within the job step. ... (yes, it then goes on to specify (partially) the effect of duplicate DDNAMES within a step, including different behavior for JES3 and JES3). So programmers who relied on the duplicate SYSIN introduced by the GENERATE STATEMENT were at least ignoring a should and should have recognized their behavior as risky and perhaps not portable between JES2 and JES3. I find the whining about APAR OA05951 simply incredible. As I read it, prior to the fix, contents of various instream data sets were treated positionally, ignoring the specific DDNAMES. With the fix, the content matches the DDNAMEs. I can see this only as repair of a blatant Programming ERror. Finally, I mostly concur with Tom Marchant's reply to Mark Zelden's What's wrong with comments? I use the bogus DDNAME largely to select among different versions of SYSIN for development and testing. One exception is when I have a large header comment. Then I may use: //DOC EXEC PGM=IEFBR14 //COMMENTS DD * Text that I can easily reflow and reformat. I suppose that if I were more proficient with ISPF's facilities for limiting column ranges and reformatting text, I would use those instead. But yet, it avoids the distraction of the //* for the reader. I'll sometimes disable a lot of JCL with IF. Which is why I regret that IF FALSE is documented as not supported and unpredictable in behavior (although no error is reported and the construct has (almost) the intuitive effect). -- gil -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
In a message dated 7/28/2008 10:55:50 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: I certainly remember (though obviously not as clearly as Mr. Blair) a day and age when overriding DD statements were required to appear in the same order as the overridden DDNAMEs in the proc. I was delighted to see the constraint relaxed. Suppose someone who does not know that proc X is used by 10 other jobs with overriding DDs in them decides to rearrange the DD statements within proc X. Which mode of processing by IBM would be better? Another possibility is that beaucoup jobs use overrides for a universally available vendor proc like ASM, LKED, FDRxxx, CAwhatever, etc., and then the vendor decides to rearrange the DD statements within the distributed machine-readable PROCLIB containing that proc. Yes, I know, we can blame change control when the inevitable errors are found. But it would be better to avoid the errors than to find someone to blame when they occur. This situation seems to me to be analogous to users' building job streams that use output from utilities like IDCAMS as their input and require data set names to begin in column X and volser in column Y, e.g. Then IBM changes the format of the utility's output. And it's not limited to IBM. Data centers also have locally developed programs that generate SYSOUT which is then used as input for other programs, and the developer in charge of a utility cannot be expected to know all the downstream users of his SYSOUT. Bill Fairchild Rocket Software **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
Jeff Holst noted that an IBM SRL states: 1. Overriding statements can appear in any order when they explicitly specify the step that is being overridden. This is apparently the missing documentation. However, it is not completely technically correct, because it is obviously not, in fact, necessary that they explicitly specify the step that is being overridden. Thanks for the heads-up. -- WB -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
In [EMAIL PROTECTED], on 07/16/2008 at 08:43 PM, John Mattson [EMAIL PROTECTED] said: Perfect example of a program being TOO HELPFUL. If it's changing the order then it's not helpful, just wrong. So, is this a bug or working as designed? Did you report it? It sure sounds like a bug. Even if someone deliberately broke it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
In [EMAIL PROTECTED], on 07/17/2008 at 03:54 PM, Matthew Stitt [EMAIL PROTECTED] said: The confusing issue was begun a very long time ago. If there is apparent input data with no specific DD statement to match it up with, there was a SYSIN dd statement generated above it. Until recently, that extraneous SYSIN dd statement had no effect on the JCL except to prevent either a JCL error or an invalid jcl error as this SYSIN was ignored since it was out of sequence (in most cases) with the specification of SYSIN (if there was one) in the procedure. WTF? There are plenty of cataloged procedures with no SYSIN DD, and the generated SYSIN DD most definitely has an effect with those. In particular, the compiler procs typically have no SYSIN DD in the compile step. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
In [EMAIL PROTECTED], on 07/17/2008 at 12:05 PM, Gibney, Dave [EMAIL PROTECTED] said: I guess this shouldn't have changed for the sake of backass compatibility. But, I've always been bothered (and debugged application JCL) when overrides didn't match the order in procs (and the messages there were almost non-existent). IBM distributed procs that depended on the old behavior four decades ago. The change is just dumb. Folks relying in //SYSIN DD * GENERATED STATEMENT are getting what they deserve. :) Others have reported that the bug occurs even if the DD * is explicit, and the APAR text confirms that. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
In [EMAIL PROTECTED], on 07/17/2008 at 02:21 AM, William H. Blair [EMAIL PROTECTED] said: Regardless, IT'S STILL DOCUMENTED TO WORK THE OLD WAY. Since it is hard for me to believe that this behavior is not intentional, you probably have as your only recourse a Readers' Comments form submission His proper recourse is to open a PMR. This is clearly an intentional change in behavior, Perhaps, but that doesn't guaranty that IBM will reject an APAR. It's broken as designed (BAD). -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
In [EMAIL PROTECTED], on 07/17/2008 at 08:55 PM, Paul Gilmartin [EMAIL PROTECTED] said: Now advancing technology has relieved those constraints and IBM is DTRT in making JCL infinitesimally closer to what it should have been from the beginning. Not all change is progress. This change was ill conceived. I'd be glad to see more changes for robustness and clear reporting of user errors. This was not such a change. Nor are the other changes you suggest. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Thu, 17 Jul 2008 02:21:29 -0500, William H. Blair [EMAIL PROTECTED] wrote: Note that page 12-14 of the z/OS V1R9.0 MVS JCL Reference SRL _still_ states: To override more than one DD statement in a procedure, place the overriding DD statements in the same order as the overridden DD statements in the procedure. However, on page 5-4 of that same manual it says: Place modifying OUTPUT JCL and DD statements in the following order, after the EXEC statement that calls the procedure: For each procedure step in the invoked procedure: 1. Overriding statements can appear in any order when they explicitly specify the step that is being overridden. Added statements can appear in any order when they specify the step explicitly. 2. Overriding and added statements that do not explicitly specify the step are applied to the step named in the previous overriding or added OUTPUT JCL or DD statement. If no previous override statement named a step, then they are applied to the first step in the procedure. For all procedure steps in the invoked procedure, place the modifying statements for each procedure step in the same order in which the procedure steps are specified. The 1.7 version of the manual reads the same. I have not looked to see how far back this section of the manual has read this way. It appears to me that the change brought about in z/OS 1.8 in response to APAR OA05951 (which was accepted in 2004 for inclusion in a future release) brings the behavior of the JCL interpreter in compliance with page 5-4. IMO page 5-4 describes the syntax for overrides in the JCL and page 12-14 describes the best practive for coding overrides. Note that APAR OA05951 gave as a local fix coding the JCL as described on page 12-14. -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Mon, Jul 21, 2008 at 3:18 PM, McKown, John [EMAIL PROTECTED] wrote: I agree, in part. I tried to use DisplayWrite/370. shudder. But the main problem, as usual, is management. The mainframe has been around a long time. We have a lot of policies and procedures. Some of which are good and necessary. Some of which make no sense (to me). At least around here, in the past, the Windows environment could change quickly to demands. Why? Because they were allowed to. There was little change control. There was almost no review of what was going on. Now that management here is implementing this, two things have happened: (1) the cowboys has gone on to greener pastures where they are allowed to get work done, not fill out paper and (2) change has slowed down to almost mainframe-likeness. John McKown And in some cases even slower Last year we created a *new* mainframe application because the distributed platform guys could not commit to the project's delivery dates (which were legislation-driven and could not be changed). -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
---snip ... or a DC-3. But like them, it still works. --unsnip The durability of the DC-3 saved my a** in Viet Nam three times; I'd really hate to see anyone bash it. It's old and slow, but it still works very well. The same holds true of an awful lot of programs; they're old and slow but THEY WORK. -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Monday, July 21, 2008 1:16 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Example of what a very small JCL Interpreter can do to your installation. ---snip ... or a DC-3. But like them, it still works. --unsnip The durability of the DC-3 saved my a** in Viet Nam three times; I'd really hate to see anyone bash it. It's old and slow, but it still works very well. The same holds true of an awful lot of programs; they're old and slow but THEY WORK. Unlikely today's programs which tend to crash quickly and often. Not mentioning any particular OS, but you can see through that, can't you? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
snip Unlikely today's programs which tend to crash quickly and often. Not mentioning any particular OS, but you can see through that, can't you? ---unsnip-- Bet your sweet bippy... :-)) -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On 21 Jul 2008 11:32:07 -0700, in bit.listserv.ibm-main you wrote: snip Unlikely today's programs which tend to crash quickly and often. Not mentioning any particular OS, but you can see through that, can't you? ---unsnip-- Bet your sweet bippy... :-)) Given the user surly nature of some of the systems that I have seen and some of the interesting abend situations, I don't know that the mainframe platform is much better. One of the main reasons that many using departments went to non-mainframe was the perceived lack of support and cooperation from IT. Getting problems fixed in some organizations was worse than dealing with Microsoft. Having used PROFs and the CICS based replacement for e-mail, I find even Outlook far superior (I use Agent 4.x). -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris Sent: Monday, July 21, 2008 2:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Example of what a very small JCL Interpreter can do to your installation. On 21 Jul 2008 11:32:07 -0700, in bit.listserv.ibm-main you wrote: snip Unlikely today's programs which tend to crash quickly and often. Not mentioning any particular OS, but you can see through that, can't you? ---unsnip-- Bet your sweet bippy... :-)) Given the user surly nature of some of the systems that I have seen and some of the interesting abend situations, I don't know that the mainframe platform is much better. One of the main reasons that many using departments went to non-mainframe was the perceived lack of support and cooperation from IT. Getting problems fixed in some organizations was worse than dealing with Microsoft. Having used PROFs and the CICS based replacement for e-mail, I find even Outlook far superior (I use Agent 4.x). I agree, in part. I tried to use DisplayWrite/370. shudder. But the main problem, as usual, is management. The mainframe has been around a long time. We have a lot of policies and procedures. Some of which are good and necessary. Some of which make no sense (to me). At least around here, in the past, the Windows environment could change quickly to demands. Why? Because they were allowed to. There was little change control. There was almost no review of what was going on. Now that management here is implementing this, two things have happened: (1) the cowboys has gone on to greener pastures where they are allowed to get work done, not fill out paper and (2) change has slowed down to almost mainframe-likeness. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On 21 Jul 2008 11:26:40 -0700, [EMAIL PROTECTED] (McKown, John) wrote: The durability of the DC-3 saved my a** in Viet Nam three times; I'd really hate to see anyone bash it. It's old and slow, but it still works very well. The same holds true of an awful lot of programs; they're old and slow but THEY WORK. Unlikely today's programs which tend to crash quickly and often. Not mentioning any particular OS, but you can see through that, can't you? There was a DC-3 that crashed into a mountain - without stopping its flight. It was pretty messed up, but finished its mission. Software crashes can be like that DC-3 crash as well. -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Thu, 17 Jul 2008 20:55:10 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: I have long been in the habit of using: //HIDDEN DD * (text to be ignored) All the unprocessed text that I want. I think this makes my intent far more clear than relying on your What's wrong with comments? //* //* All the unprocessed text //* that I want. //* -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Thursday, July 17, 2008 2:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Example of what a very small JCL Interpreter can do to your installation. I guess this shouldn't have changed for the sake of backass compatibility. But, I've always been bothered (and debugged application JCL) when overrides didn't match the order in procs (and the messages there were almost non-existent). Folks relying in //SYSIN DD * GENERATED STATEMENT are getting what they deserve. :) I agree with that. If I had been the coder, and allowed to by management, I would have made it: //IDIOT DD * GENERATED STATEMENT Of course, back in the day, most utilities used SYSIN for their control statements. And they were usually on physical punched cards. So generating the SYSIN automagically could be argued as being a good design point. It saved the user from punching a card. And saved having to read said card. And you didn't need to worry about the card becoming damaged. OK, so maybe it was a good idea. Back in the day. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Zelden On Thu, 17 Jul 2008 20:55:10 -0500, Paul Gilmartin wrote: I have long been in the habit of using: //HIDDEN DD * (text to be ignored) All the unprocessed text that I want. I think this makes my intent far more clear than relying on your What's wrong with comments? //* //* All the unprocessed text //* that I want. //* Too obvious. :-) -jc- -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
Date: Fri, 18 Jul 2008 09:47:14 -0500 From: [EMAIL PROTECTED] Subject: Re: Example of what a very small JCL Interpreter can do to your installation. To: IBM-MAIN@BAMA.UA.EDU -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Zelden On Thu, 17 Jul 2008 20:55:10 -0500, Paul Gilmartin wrote: I have long been in the habit of using: //HIDDEN DD * (text to be ignored) All the unprocessed text that I want. I think this makes my intent far more clear than relying on your What's wrong with comments? //* //* All the unprocessed text //* that I want. //* Too obvious. :-) -jc- Nothing to whine about. ;-) _ Stay in touch when you're away with Windows Live Messenger. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_messenger2_072008 -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Fri, 18 Jul 2008 07:47:20 -0500, Mark Zelden wrote: On Thu, 17 Jul 2008 20:55:10 -0500, Paul Gilmartin wrote: I have long been in the habit of using: //HIDDEN DD * (text to be ignored) All the unprocessed text that I want. I think this makes my intent far more clear than relying on your What's wrong with comments? //* //* All the unprocessed text //* that I want. //* Comments are good. But for effectively deleting in-stream data temporarily, I prefer to use Paul's approach. It's easier if there are more than a very few statements, especially in cases where all 80 columns are used. If I want to temporarily delete a lot of JCL, I might code a DD DATA. That one needs to be used with greater care though because it can be very confusing. -- Tom Marchant -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Thu, 17 Jul 2008 20:55:10 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: ... o Duplicate DDNAMEs within a step should be treated as a JCL error. (I understand JES3 already does this.) This itself would have blocked the pitfall described in this thread. ... I've seen jobs that actually made use of this. It certainly gives nothing that can't be achieved in other (and easier to understand) ways, but somebody found it useful. Now it can't be changed without breaking something. (... unless OPEN's behavior has changed so that the dup DDnames can't be referenced any more.) I think I'd rather here some people whine that obtuse techniques are allowed than hear others whine that obtuse techniques that used to work have been fixed. Maybe. Pat O'Keefe -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
John Mattson wrote: Somewhere between OS390 2.10 (our old system) and zos 1.08 (our new system) the JCL interpreter changed. Funny you should notice that ... was wondering if anybody would. The change was first introduced in z/OS 1.8. It worked the old way in z/OS 1.7. When I first found this, I tested it all the way back to z/OS 1.4. So, is this a bug or working as designed? IBM will have to say, unless someone can find something in the z/OS 1.8+ SRLs that describes this new behavior. The old behavior adheres to the rules of JCL in effect since OS/360 Release 13 MVT (where it was first possible to have multiple in-stream [DD *] data sets). But I have an opinion: it's a WAD, as I will attempt to demonstrate. Regardless, IT'S STILL DOCUMENTED TO WORK THE OLD WAY. Since it is hard for me to believe that this behavior is not intentional, you probably have as your only recourse a Readers' Comments form submission -- but all that will do is just get this new behavior documented. Note that page 12-14 of the z/OS V1R9.0 MVS JCL Reference SRL _still_ states: To override more than one DD statement in a procedure, place the overriding DD statements in the same order as the overridden DD statements in the procedure. That is the OLD rule and behavior, not the NEW (as of z/OS 1.8). This behavior occurs even if you provide a //SYSIN DD * statement in front of the second in-stream data set. Doing so merely causes the statement that would be automatically generated had one not been provided NOT to be generated (obviously, as you would expect). So, the fact that you have a missing //SYSIN DD is not relevant, and does not affect its behavior. The results are identical. Thus, if you submit this JCL: //AFITJLMU JOB CLASS=S,MSGCLASS=X,TYPRUN=SCAN //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE //SYSINDD DISP=SHR,DSN=QALC.UNVLIB //MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB //SYSPRINT DD SYSOUT=* //PEND - //* //JS001 EXEC PROC=UNVTEST //MYSCRIPT DD * WHATEVER /* //SYSIN DD * WHEREEVER /* where the overriding DD statements [i.e., MYSCRIPT and SYSIN] are NOT in the same order as the overridden DD statements in the procedure then, starting with z/OS 1.8, both DD statements in the PROC _are_ overridden, despite the fact that they aren't explicitly [or implicitly] presented in the same order. This is clearly an intentional change in behavior, and can only be explained as someone's unthinking idea of how it should be working I suspect. The fact that this behavior is not documented (even in the SRL for the next release after the behavior was first introduced) indicates to me that it was not thought to be of any importance. They probably actually thought they were doing us a big favor. But, wait! It's only going to get worse. Hang on to your hats, folks. I had some job streams where multiple in-stream data sets with the same DDname are defined (intentionally). So, I tested this with a few of those jobs. What the converter apparently does is to reach down into the JOB's JCL where it finds the first match on an overriding (it thinks!) DDname and then reorders the JCL to match that in the PROC! Yes, you read that right. I did not make that up. It reorders the input JCL! Programs that depend upon different or matching DDnames in the TIOT in a specific order will now be broken (but only if they are invoked using a model [so to speak] PROC). In-stream JCL that does not use a PROC apparently still works as before (no DD statements are reordered). But, I didn't want my existing SYSIN DD statement in the PROC to be overridden, WHICH IS WHY I PUT IT AFTER A DD STATEMENT THAT IS IN THE PROC AT THE END, SO THAT THE NEW DD STATEMENT IN THE INPUT STREAM WOULD GET _ADDED_ TO THE STEP'S JCL! (Apparently, whoever made this change did not read, nor understand, the distinction between OVERRIDING and ADDING JCL DD statements to a step in a PROC -- a concept that has been cast in concrete [at least until now] since 1965. So, IBM broke the old behavior. Normally, this would make me consider it to be a bug. But it can't possibly be a bug. Too much code had to be written to make it work like this. Thus, it must be a feature. In fact, further testing reveals that this behavior is general and ALL overriding DD statements in the instream JCL are just simply reordered to match those in the PROC. For example, if you submit this JCL: //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //FIRSTDD DD DISP=SHR,DSN=SYS1.LPALIB //REMOTE DD DISP=SHR,DSN=SYS1.PROCLIB //SYSINDD DISP=SHR,DSN=SYS1.PARMLIB //MYSCRIPT DD DISP=SHR,DSN=SYS1.LINKLIB //SYSPRINT DD SYSOUT=* //PEND
Re: Example of what a very small JCL Interpreter can do to your installation.
On Wed, 16 Jul 2008 20:43:03 -0700, John Mattson [EMAIL PROTECTED] wrote: There has been some talk about changing JCL interpretation. Sure it is old, and ugly, but we are used to it, and it does work. Here is what happened going from os390 to zos 1.08 Somewhere between OS390 2.10 (our old system) and zos 1.08 (our new system) the JCL interpreter changed. Here is a simplified example of some JCL we have been running for years. //AFITJLMU JOB CLASS=S,MSGCLASS=X,TYPRUN=SCAN //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE //SYSINDD DISP=SHR,DSN=QALC.UNVLIB //MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB //SYSPRINT DD SYSOUT=* //PEND - //* //JS001 EXEC PROC=UNVTEST //MYSCRIPT DD * WHATEVER /* WHEREEVER /* Note the Extra sysin which the programmer left there in case he ever needed it again, soft of self documenting. Worked just fine... until zOS 1.08 Here is how OS390 2.10 handles the GENERATED SYSIN //JS001 EXEC PROC=UNVTEST ++UNVTEST PROC ++PS001 EXEC PGM=IEFBR14 ++REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE ++SYSINDD DISP=SHR,DSN=QALC.UNVLIB //MYSCRIPT DD * +/MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB ++SYSPRINT DD SYSOUT=* //SYSIN DD * GENERATED STATEMENT Here is how zOS 1.08 handles the GENERATED SYSIN 4 ++UNVTEST PROC 5 ++PS001 EXEC PGM=IEFBR14 6 ++REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE 7 //SYSIN DD * GENERATED STATEMENT +/SYSINDD DISP=SHR,DSN=QALC.UNVLIB 8 //MYSCRIPT DD * +/MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB 9 ++SYSPRINT DD SYSOUT=* The os390 way, the JCL works. zOS 1.8 it gets the old WHEREVER junk in the sysin dd and fails. Sigh. Notice that zos 1.08 neatly lines up the sysin from way down at the bottom with the existing SYSIN. Perfect example of a program being TOO HELPFUL. It wasn't broke, why did you fix it. So, is this a bug or working as designed? Or maybe there is an option somewhere that I can change and have it work the way it used to. MUCH better than changing hundreds of pieces of JCL. Really. APAR Identifier .. OA12842 Last Changed 08/06/10 PROC DD STMTS OVERRIDEN BY DD * INCORROUT CONTENTS OF FILES SWAPPED ( OA05951 ) Symptom .. IN INCORROUT Status ... CLOSED UR3 Severity ... 2 Date Closed . 06/04/13 Component .. 5752SC1B9 Duplicate of Reported Release . 709 Fixed Release 708 Component Name 5752 CNVRTR/INT Special Notice Current Target Date ..06/04/15 Flags SCP ... Platform Status Detail: APARCLOSURE - APAR is being closed. PE PTF List: PTF List: Release 708 : No PTF planned Release 709 : No PTF planned Release 720 : No PTF planned Release 730 : No PTF planned Parent APAR: Child APAR list: ERROR DESCRIPTION: When DD statements within a procedure are overridden with instream data (DD * or DD DATA), the data within the data sets represented by those input stream DD statements may be swapped (exchanged) if the overriding DDs are not in the correct order; that is, in the order in which the overridden stmts appear in the procedure. This can happen because the MVS Converter may reverse the sequence of two or more instream DD stmts with respect to each other, but the data within the files referenced by those DD stmts does not move along with the DD stmts themselves. Running the same JCL in R707, the out of sequence instream DD statements were simply ignored. This issue was previously reported in OA05951, which was closed SUG. Additional Symptoms: IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT SPECIFIED (msgIEF655I) May occur if a SYSIN DD * statement is GENERATED and now properly finds and overrides a SYSIN DD DSN= statement. Additional Keywords: SYSIN reversed reversal, asterisk, instream -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
How on earth can IBM make a change as significant as this and not even document the change in behavior? I can imagine this affecting many job streams with negative consequences. Mark Zelden [EMAIL PROTECTED] 7/17/2008 8:54 AM APAR Identifier .. OA12842 Last Changed 08/06/10 PROC DD STMTS OVERRIDEN BY DD * INCORROUT CONTENTS OF FILES SWAPPED ( OA05951 ) Symptom .. IN INCORROUT Status ... CLOSED UR3 Severity ... 2 Date Closed . 06/04/13 Component .. 5752SC1B9 Duplicate of Reported Release . 709 Fixed Release 708 Component Name 5752 CNVRTR/INT Special Notice Current Target Date ..06/04/15 Flags SCP ... Platform Status Detail: APARCLOSURE - APAR is being closed. PE PTF List: PTF List: Release 708 : No PTF planned Release 709 : No PTF planned Release 720 : No PTF planned Release 730 : No PTF planned Parent APAR: Child APAR list: ERROR DESCRIPTION: When DD statements within a procedure are overridden with instream data (DD * or DD DATA), the data within the data sets represented by those input stream DD statements may be swapped (exchanged) if the overriding DDs are not in the correct order; that is, in the order in which the overridden stmts appear in the procedure. This can happen because the MVS Converter may reverse the sequence of two or more instream DD stmts with respect to each other, but the data within the files referenced by those DD stmts does not move along with the DD stmts themselves. Running the same JCL in R707, the out of sequence instream DD statements were simply ignored. This issue was previously reported in OA05951, which was closed SUG. Additional Symptoms: IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT SPECIFIED (msgIEF655I) May occur if a SYSIN DD * statement is GENERATED and now properly finds and overrides a SYSIN DD DSN= statement. Additional Keywords: SYSIN reversed reversal, asterisk, instream -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Note that my email domain has changed from jo-annstores.com to joann.com. Please update your address book and other records to reflect this change. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Thu, 17 Jul 2008 10:37:50 -0400, Scott Rowe [EMAIL PROTECTED] wrote: How on earth can IBM make a change as significant as this and not even document the change in behavior? I can imagine this affecting many job streams with negative consequences. May occur if a SYSIN DD * statement is GENERATED and now properly finds and overrides a SYSIN DD DSN= statement. Perhaps because they used MAY occur Could be my english , but i would have expected something like will occur it is a bit difficult to document a may be just wondering Bruno Sugliani zxnetconsult(at)free(dot)fr -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
I guess this shouldn't have changed for the sake of backass compatibility. But, I've always been bothered (and debugged application JCL) when overrides didn't match the order in procs (and the messages there were almost non-existent). Folks relying in //SYSIN DD * GENERATED STATEMENT are getting what they deserve. :) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruno Sugliani Sent: Thursday, July 17, 2008 7:46 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Example of what a very small JCL Interpreter can do to your installation. On Thu, 17 Jul 2008 10:37:50 -0400, Scott Rowe [EMAIL PROTECTED] wrote: How on earth can IBM make a change as significant as this and not even document the change in behavior? I can imagine this affecting many job streams with negative consequences. May occur if a SYSIN DD * statement is GENERATED and now properly finds and overrides a SYSIN DD DSN= statement. Perhaps because they used MAY occur Could be my english , but i would have expected something like will occur it is a bit difficult to document a may be just wondering Bruno Sugliani zxnetconsult(at)free(dot)fr -- 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 -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
I'm confused. Are you saying that APAR OA12842 broke it? or that it fixed it? It looks to me like they fixed a problem. It says The solution for this APAR has been shipped in the base code of z/OS 1.8 (HBB7730), JES2 1.8 (HJE7730) and JES3 1.8 (HJS7730). If I understood the original poster, he has //AFITJLMU JOB CLASS=S,MSGCLASS=X,TYPRUN=SCAN //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE //SYSINDD DISP=SHR,DSN=QALC.UNVLIB //MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB //SYSPRINT DD SYSOUT=* //PEND - //* //JS001 EXEC PROC=UNVTEST //MYSCRIPT DD * WHATEVER /* WHEREEVER /* and the WHEREEVER causes a system generated //SYSIN which overrides his original //SYSINDD DISP=SHR,DSN=QALC.UNVLIB I also like to leave junk at the bottom of my JCL members as notes. But I always have a // hard end of job card before the junk at the bottom so I never see this problem. Roger Bolan infoprint.com Boulder, Colorado, USA P Think before you print IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/17/2008 08:37:50 AM: How on earth can IBM make a change as significant as this and not even document the change in behavior? I can imagine this affecting many job streams with negative consequences. Mark Zelden [EMAIL PROTECTED] 7/17/2008 8:54 AM APAR Identifier .. OA12842 Last Changed 08/06/10 PROC DD STMTS OVERRIDEN BY DD * INCORROUT CONTENTS OF FILES SWAPPED ( OA05951 ) Symptom .. IN INCORROUT Status ... CLOSED UR3 Severity ... 2 Date Closed . 06/04/13 Component .. 5752SC1B9 Duplicate of Reported Release . 709 Fixed Release 708 Component Name 5752 CNVRTR/INT Special Notice Current Target Date ..06/04/15 Flags SCP ... Platform Status Detail: APARCLOSURE - APAR is being closed. PE PTF List: PTF List: Release 708 : No PTF planned Release 709 : No PTF planned Release 720 : No PTF planned Release 730 : No PTF planned Parent APAR: Child APAR list: ERROR DESCRIPTION: When DD statements within a procedure are overridden with instream data (DD * or DD DATA), the data within the data sets represented by those input stream DD statements may be swapped (exchanged) if the overriding DDs are not in the correct order; that is, in the order in which the overridden stmts appear in the procedure. This can happen because the MVS Converter may reverse the sequence of two or more instream DD stmts with respect to each other, but the data within the files referenced by those DD stmts does not move along with the DD stmts themselves. Running the same JCL in R707, the out of sequence instream DD statements were simply ignored. This issue was previously reported in OA05951, which was closed SUG. Additional Symptoms: IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT SPECIFIED (msgIEF655I) May occur if a SYSIN DD * statement is GENERATED and now properly finds and overrides a SYSIN DD DSN= statement. Additional Keywords: SYSIN reversed reversal, asterisk, instream -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Note that my email domain has changed from jo-annstores.com to joann.com. Please update your address book and other records to reflect this change. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send
Re: Example of what a very small JCL Interpreter can do to your installation.
The confusing issue was begun a very long time ago. If there is apparent input data with no specific DD statement to match it up with, there was a SYSIN dd statement generated above it. Until recently, that extraneous SYSIN dd statement had no effect on the JCL except to prevent either a JCL error or an invalid jcl error as this SYSIN was ignored since it was out of sequence (in most cases) with the specification of SYSIN (if there was one) in the procedure. Now with OA12842, (and I have seen other similar changes) the JCL specified outside of the procedure (mostly for override purposes) does not have to be in the same sequence as the JCL in the procedure. The overriding JCL statements will now be matched up irregardless of the sequence. APAR OA12842 is fixing the problem where the input data is not moved along with the matching overriding JCL statement, especially in the case of multiple sets of input data. This is where the original poster encountered the problem. The internally generated SYSIN dd statement has now been matched up with the SYSIN dd statement in the procedure, and the input data following this generated statement was moved along with it.This is where the original poster encountered the problem. WAD/BAD? Depends on whether the end results are what makes you happy. To me you were doing something that was puzzling at the least. Now you are being forced to follow what was an assumed correct way of doing JCL coding. On Thu, 17 Jul 2008 13:44:52 -0600, Roger Bolan [EMAIL PROTECTED] wrote: I'm confused. Are you saying that APAR OA12842 broke it? or that it fixed it? It looks to me like they fixed a problem. It says The solution for this APAR has been shipped in the base code of z/OS 1.8 (HBB7730), JES2 1.8 (HJE7730) and JES3 1.8 (HJS7730). If I understood the original poster, he has //AFITJLMU JOB CLASS=S,MSGCLASS=X,TYPRUN=SCAN //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE //SYSINDD DISP=SHR,DSN=QALC.UNVLIB //MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB //SYSPRINT DD SYSOUT=* //PEND - //* //JS001 EXEC PROC=UNVTEST //MYSCRIPT DD * WHATEVER /* WHEREEVER /* and the WHEREEVER causes a system generated //SYSIN which overrides his original //SYSINDD DISP=SHR,DSN=QALC.UNVLIB I also like to leave junk at the bottom of my JCL members as notes. But I always have a // hard end of job card before the junk at the bottom so I never see this problem. Roger Bolan infoprint.com Boulder, Colorado, USA P Think before you print IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/17/2008 08:37:50 AM: How on earth can IBM make a change as significant as this and not even document the change in behavior? I can imagine this affecting many job streams with negative consequences. Mark Zelden [EMAIL PROTECTED] 7/17/2008 8:54 AM APAR Identifier .. OA12842 Last Changed 08/06/10 PROC DD STMTS OVERRIDEN BY DD * INCORROUT CONTENTS OF FILES SWAPPED ( OA05951 ) Symptom .. IN INCORROUT Status ... CLOSED UR3 Severity ... 2 Date Closed . 06/04/13 Component .. 5752SC1B9 Duplicate of Reported Release . 709 Fixed Release 708 Component Name 5752 CNVRTR/INT Special Notice Current Target Date ..06/04/15 Flags SCP ... Platform Status Detail: APARCLOSURE - APAR is being closed. PE PTF List: PTF List: Release 708 : No PTF planned Release 709 : No PTF planned Release 720 : No PTF planned Release 730 : No PTF planned Parent APAR: Child APAR list: ERROR DESCRIPTION: When DD statements within a procedure are overridden with instream data (DD * or DD DATA), the data within the data sets represented by those input stream DD statements may be swapped (exchanged) if the overriding DDs are not in the correct order; that is, in the order in which the overridden stmts appear in the procedure. This can happen because the MVS Converter may reverse the sequence of two or more instream DD stmts with respect to each other, but the data within the files referenced by those DD stmts does not move along with the DD stmts themselves. Running the same JCL in R707, the out of sequence instream DD statements were simply ignored. This issue was previously reported in OA05951, which was closed SUG. Additional Symptoms: IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT SPECIFIED (msgIEF655I) May occur if a SYSIN DD * statement is GENERATED and now properly finds and overrides a SYSIN DD DSN= statement. Additional Keywords: SYSIN reversed reversal, asterisk, instream -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO
Re: Example of what a very small JCL Interpreter can do to your installation.
Dave Gibney wrote: Folks relying in //SYSIN DD * GENERATED STATEMENT are getting what they deserve. :) You didn't read everything I wrote. This has nothing to do with the automatically-generated //SYSIN DD * statement. Explicit DD statements are being reordered. What is happening happens long after (and despite) any automatically-generated DD statements. -- WB -- 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
Re: Example of what a very small JCL Interpreter can do to your installation.
On Thu, 17 Jul 2008 02:21:29 -0500, William H. Blair wrote: But, 42 years of experience with IBM tells me that this is how it is going to be, so I'm going to have to find some other way of hiding in-stream data sets. (You're not the only one to use this technique. It's not unheard of. I've seen it in many production JCL streams. Other folks are going to get burned by this, but I have no clue how many. I would hope not many.) I have long been in the habit of using: //HIDDEN DD * (text to be ignored) All the unprocessed text that I want. I think this makes my intent far more clear than relying on your convention of using an undeclared SYSIN as a collateral comment. I consider the latter irresponsibly lazy and lacking in referential transparency. It's redolent of trying to assure one's job security by writing incomprehensible code. I wonder if anybody at IBM even thought about the possibility that this slick new feature might break existing customer JCL. Probably not. They probably got an award just for their bright idea. Oh, well. Whine, whine, whine! JCL has sucked for those 42 years. This has frequently been attributed in this forum to resource constraints in those early systems. Now advancing technology has relieved those constraints and IBM is DTRT in making JCL infinitesimally closer to what it should have been from the beginning. Hooray! It's similar to USERKEYCSA -- some things that have to be fixed should be fixed. I'd be glad to see more changes for robustness and clear reporting of user errors. E.g.: o Duplicate DDNAMEs within a step should be treated as a JCL error. (I understand JES3 already does this.) This itself would have blocked the pitfall described in this thread. o The SYSIN DD * GENERATED STATEMENT behavior should be removed from the language. The last time I encountered this, I had inadvertently left a '/' off a JCL statement (perhaps a comment) before my actual intended SYSIN. The utility then saw an empty SYSIN. Took me far too long to spot. At least there should be an option such as GENSYSIN(YES|NO) on the JOB statement. I'd use NO. o All the usages described in the JCL manual as having unpredictable effects should be reported as JCL errors (or those with repeatable behaviors documented). Perhaps a conversion utility should be provided to tidy up legacy careless JCL. -- gil -- 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
