On Wed, 19 Dec 2007 17:04:39 -0800, Skip Robinson wrote: >You could argue in favor of some 'basic' set of jobcard parameters, but the >problem for JES2 is the other side of the same coin that gives us the power >through well defined exits to alter most anything in a job stream. Messing >with jobcard syntax might be a bad idea in practice, but it's possible. The >danger of validating a job stream destined for another node is that the >remote system may be capable of handling parameters that the submitting >system cannot. Indeed, the remote node might even *require* parameters that >the submitting node cannot parse. > >I don't see a practical way for absolute parse validation in a true >full-function NJE environment. Perhaps validation could be made an option, >either all or nothing, maybe even on a node-by-node basis. Frankly, it >sounds like a lot of trouble (and development rupees) to catch a handful of >occasional problems. > Wouldn't it then be more practical for the remote system to perform the parse and return status codes to the submitting system indicating "JCL error" and "JOB statement error"?
>-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On >Behalf Of Ed Gould >Sent: Wednesday, December 19, 2007 1:48 PM > >It is my position, that I would like appropriately challenged if one >exists, that JES2 should have "fully" processed the JOB card on the >original system before executing the JES2 command to SEND the JOB. If >the JOB card is syntactically in error, the JOB should be failed on the >system were submitted as would be the case if that were also the >execution system. -- 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
