On 9/4/2013 8:52 AM, Paul Gilmartin wrote:
On Wed, 4 Sep 2013 11:27:32 -0400, Shmuel Metz (Seymour J.) wrote:
on 09/03/2013 at 07:30 PM, Paul Gilmartin said:
It's logically impossible for JES3 setup to exploit or even
accommodate the newer features of JCL, even dating back to
IF...THEN...ELSE...ENDIF.
Nonsense.
OK. At least extraordinarily cumbersome. Consider:
Conditional JCL execution works just fine in JES3 no matter if it's done
using COND= or IF/THEN/ELSE. (FYI. At the control block level there is
no difference at all between COND= and IF/THEN/ELSE.) We use conditional
execution all the time in our JES3 environments. For example, we
generally do not bind (like-edit) object modules if the compile step
ends with a return code of eight or higher. We run the same jobs in JES2
and they behave identically.
It has *always* been true that JES3 LOCATE processing (if enabled)
treats every step as if it will execute. There is no choice as LOCATE is
a pre-execution phase. JES3 LOCATE processing ensures a job will not run
for hours only to fail at O-Dark-Thirty with a "Data Set Not Found"
condition. It's difficult to measure how many thousands of hours of
production down-time have been saved worldwide with this feature. Having
worked "on call" at a JES2-only company for years, I wished more than
once that our production jobs could be protected by a feature like JES3
LOCATE. Eventually, we purchased an expensive production control system
with external features that provided the needed protection, but its use
was off limits to non-production work so our dev/test groups just had to
live with things as they were.
It has *always* been true that the objective and implementation of JES3
LOCATE processing is in conflict with the case in which you'd like to
dynamically create a data set and then pass that data sets on to future
steps in the same job. The most common scenario is an IDCAMS DEFINE
(e.g., for an SMP/E CSI) followed by a batch job step that references
the just-created data set via JCL (e.g., EXEC PGM=GIMSMP). The same
issue occurs with batch TSO/E XMIT steps, FTP, etc. This is a
well-known, decades old restriction in JES3 and the workarounds are
tried and true: either a) insert a single, non-executing INFORMJ3 step
at the start of the job that pretends to allocate all of the
"troublesome" data sets or b) split the job into multiple jobs and use
DJC to coordinate them. We use DJC heavily, but tend to use the INFORMJ3
step approach to solve the specific issue under discussion.. For example:
//INFORMJ3 EXEC PGM=ABEND806,COND=ONLY
//PFIMSTR DD DISP=(,CATLG),DSN=EJES.PRODGEN.EJESMSTR.PFI
//NETDATA DD DISP=(,CATLG),DSN=EJES.PRODGEN.EJESMSTR.NETDATA
//PACKAGE DD DISP=(,CATLG),DSN=EJES.PRODGEN.PACKAGE
This restriction has absolutely nothing whatsoever to do with COND= or
IF/THEN/ELSE.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
