z/OS V1R9.0 UNIX System Services Command ... - Christian Grothoff

BPXBATCH
v If the LRECL of the target STDOUT or STDERR data set is not large
enough to hold a line of output, the data will be truncated and message
BPXM080I will be put out indicating this has occurred. This can happen for
both fixed and variable blocked data sets. For variable block data sets, the
first four bytes of each record, record segment, or block make up a
descriptor word containing control information. You must allow for these
additional 4 bytes in the specified LRECL if you intend to avoid truncation of
the output to the STDOUT and STDERR DDs.
v If you use two members of the same partitioned data set for the STDOUT
and STDERR ddnames, then you must use a PDSE (not a PDS). Using a
PDS instead of a PDSE can result in a 213 abend (and, if running in a
batch job, an abnormal end for the job step) or the output not appearing in
the members as expected.
v When you specify an MVS data set for either the STDOUT or STDERR
ddnames, a child process will be created to run the target z/OS UNIX
program. In some cases, the child process will run in a separate address
space from the BPXBATCH job. In such cases, the job log messages for the
child will not appear in the job log of the BPXBATCH job. To capture the
child's job log messages, set the _BPXK_JOBLOG=STDERR environment
variable. This will cause the child's job log messages to be written to the
STDERR data set specified in the BPXBATCH job.
v In prior releases of z/OS, if a MVS data set is specified on STDOUT or
STDERR, BPXBATCH ignores the data set and defaults to /dev/null. To
remain compatible with this behavior, this new support will do the same
defaulting if the MVS data set type is not supported (e.g. DD Dummy,
Terminal, SYSIN, and so on), or if the MVS data set cannot be opened by
BPXBATCH. A new message BPXM081I will be displayed indicating when
this default behavior is being taken by BPXBATCH.
v If STDOUT or STDERR are allocated as a PDS or PDSE member and
overwriting of the output is expected from multiple runs of the same job or
command, the data set should not be allocated with a disposition of NEW
but rather as SHR or OLD. If the data set is allocated as NEW, the member
will be created on the 1st run, but subsequent runs will cause i/o errors
when attempting to write to the member.
v If STDOUT or STDERR are allocated as a sequential data set and
appending of the output is expected from multiple runs of the same job or
command, the data set should be allocated with a disposition of MOD.
v In general, any I/O errors that occur with an MVS data set defined to the
STDOUT or STDERR (or STDPARM or STDENV, described below)
ddnames will result in an abend (x13 or x37, for instance) and, if running in
a batch job, an abnormal end for the job step. For example: If the user does
not have security access to the data set defined to STDOUT, then when
BPXBATCH attempts to open the data set, a 913 abend will occur and
message IEC150I will provide details about the error.
7. BPXBATCH now supports a parameter string up to 32754 characters when
called from a TSO command environment. Also from both a batch and TSO
environment, up to 65,536 characters can now be supplied via the a new input
DD named stdparm. When the stdparm DD is allocated BPXBATCH will use
the data found in the z/OS UNIX file or MVS data set associated with this DD
rather that what is found on the parameter string or in the stdin DD. As a
warning to the user, an informational message BPXM079I will be displayed
indicating that this is occurring.
Appendix D. Running shell scripts or executable files under MVS environments 895