DanD wrote:
Yes Ted, it`s a very big kluge with a very big hole.
I am waiting to see what they do to correct the issue.
For those that don`t know what the hole is...
If the job goes into allocation recovery or for whatever other reason the
DISP=(OLD,DELETE) migrated data set gets recalled prior to step
termination
a ``not deleted - nn`` error will be issued and the data set will not get
deleted. I am not logged on at the moment but I believe the reason
code is
14.
The kludge in this case is the hard-coded checking for PGM=IEFBR14 with
the presumption that this program is always the IBM-supplied utility;a
reliance on common practice rather than certainty; the establishment of
(what I believe to be) a new class of restrictions for the z/OS BCP:
i.e., reserved program names on the JCL EXEC card; and no mechanism for
enforcement of the those restrictions.
IMHO, this is akin to various erroneous programming assumptions I've
found and corrected over the years--usually coded by inexperienced
programmers--such as assuming an address space is a z/OS UNIX forked
procedure simply because JES control blocks contain the job name
"BPXAS". To illustrate the folly of these tests, I have "canned" jobs
called ASCHINT, BPXAS, SYSLOG, CATALOG, CONSOLE and others to
demonstrate how poor such name-based approaches are.
Such assumptive, non-canonical, lazy programming seems to work in most
cases, but can lead to failure and confusion in others. I eliminate it
whenever I can. I regard such code as inelegant, yet convenient,
short-cuts that work most of the time. "Kludge".
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
