On 2012-02-22 12:54, Gerhard Postpischil wrote:

While I can't speak to FLOWASM, I use RDJFCB (or occasionally
the equivalent of TIOT search and JFCB look-up) almost as often
as OPEN. I spent a lot of time working for ISVs and service
bureaus, and frequently wrote or modified utility programs.

Programmers unused to JCL, or new to the system, have some bad
habits. These include specification of a PDS name for intended
sequential output, specifying a member name when they should
not, misspelling an input member name, using incorrect DCB
values, etc.. It is fairly simple to use lower level system
functions (RDJFCB, LOCATE, OBTAIN, etc.) to validate a user
request, and provide a clear error message ('Member name XYZ on
DD SYSUT1 does not exist in data set r.s.t') rather than an S013
abend with an IEC020I message (and even the IEC message is a
later addition by IBM).

Do you do all this manipulation in a way that does not interfere
with a user's use of a UNIX file with BSAM/QSAM, nor with use
of a UNIX directory with BPAM?

Beyond that, if IBM or an ISV were to introduce an new device
type or a new I/O subsystem, would your interfaces be transparent
to access method support?

Bad Example: I can use a UNIX directory as Rexx SYSEXEC only
if it's not the first catenand and the first catenand is a
legacy PDS(E).  Why?  Because Rexx in its wisdom checks that
(only) the first catenand has DSORG=PO, and UNIX directories
do not appear that way.

Another: GIMZIP will not let me specify PATHOPTS=OWRONLY
(which seems reasonable otherwise) on its output DD because
GIMZIP first does an OPEN INPUT to perform one of the
validations you mention above.

You can't always assume that because you don't understand
what a programmer is doing the programmer doesn't know
what he's doing.  That's arrogance.

-- gil

Reply via email to