Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
multi-line STDPARM shell script for BPXBATCH
506 views
Skip to first unread message
Peter Bishop
Oct 1, 2019, 9:31:51 PM10/1/19
to
Hi,
in case anyone wants it, after much trial and error I finally found this working example of a multi-line STDPARM shell script for BPXBATCH. I still haven't found a way to have #comment lines, which seem to generate syntax errors, but if I accept that limitation, I am happy enough with this.
// EXPORT SYMLIST=*
// SET BCDHOME='/usr/lpp/bcp/' home directory for BCP
// SET E='/u/xxxxx/' error messages here
//*
//* multiline shell script with complex control structures
//*
//* haven't found a way yet to include #comments without error
//*
//BPXBATCH EXEC PGM=BPXBATCH
//OUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDOUT DD SYSOUT=*
//STDPARM DD *,SYMBOLS=(EXECSYS,OUT)
SH (
set -o verbose ;
set -o errexit ;
set -x ;
for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ;
do
if [ -z "$(echo $jarname | grep Doc\.jar)" ] ;
then
echo adding to ClassPath ;
CLASSPATH="$CLASSPATH":"$jarname" ;
fi
done ;
echo CLASSPATH is $CLASSPATH ;
)
> &E.bcd-write.out 2>&E.bcd-write.err
//
What I like about this is when there is a syntax error I get the message in STDERR, and when there isn't the normal and error output goes to my specified files. I needed this as the placement of the semicolons was a bit hard to glean from the manual, e.g. 'for' needs one but not 'then' or 'fi', etc.
If anyone can suggest how to put a comment it that works without error, I'm all ears.
For example of the error, this code that has the #comment added to the 'for',
SH (
set -o verbose ;
set -o errexit ;
set -x ;
for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` #comment ;
do
if [ -z "$(echo $jarname | grep Doc\.jar)" ] ;
then
echo adding to ClassPath ;
CLASSPATH="$CLASSPATH":"$jarname" ;
fi
done ;
echo CLASSPATH is $CLASSPATH ;
)
> &E.bcd-write.out 2>&E.bcd-write.err
gives this error in STDERR:
FSUM7332 syntax error: got EOF, expecting do
I'm still learning the ins and outs of SH but I was surprised to read that a comment is "EOF".
best regards,
Peter
(MVS-OE seems a little quiet so I thought I might start here).
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
in case anyone wants it, after much trial and error I finally found this working example of a multi-line STDPARM shell script for BPXBATCH. I still haven't found a way to have #comment lines, which seem to generate syntax errors, but if I accept that limitation, I am happy enough with this.
// EXPORT SYMLIST=*
// SET BCDHOME='/usr/lpp/bcp/' home directory for BCP
// SET E='/u/xxxxx/' error messages here
//*
//* multiline shell script with complex control structures
//*
//* haven't found a way yet to include #comments without error
//*
//BPXBATCH EXEC PGM=BPXBATCH
//OUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDOUT DD SYSOUT=*
//STDPARM DD *,SYMBOLS=(EXECSYS,OUT)
SH (
set -o verbose ;
set -o errexit ;
set -x ;
for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ;
do
if [ -z "$(echo $jarname | grep Doc\.jar)" ] ;
then
echo adding to ClassPath ;
CLASSPATH="$CLASSPATH":"$jarname" ;
fi
done ;
echo CLASSPATH is $CLASSPATH ;
)
> &E.bcd-write.out 2>&E.bcd-write.err
//
What I like about this is when there is a syntax error I get the message in STDERR, and when there isn't the normal and error output goes to my specified files. I needed this as the placement of the semicolons was a bit hard to glean from the manual, e.g. 'for' needs one but not 'then' or 'fi', etc.
If anyone can suggest how to put a comment it that works without error, I'm all ears.
For example of the error, this code that has the #comment added to the 'for',
SH (
set -o verbose ;
set -o errexit ;
set -x ;
for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` #comment ;
do
if [ -z "$(echo $jarname | grep Doc\.jar)" ] ;
then
echo adding to ClassPath ;
CLASSPATH="$CLASSPATH":"$jarname" ;
fi
done ;
echo CLASSPATH is $CLASSPATH ;
)
> &E.bcd-write.out 2>&E.bcd-write.err
gives this error in STDERR:
FSUM7332 syntax error: got EOF, expecting do
I'm still learning the ins and outs of SH but I was surprised to read that a comment is "EOF".
best regards,
Peter
(MVS-OE seems a little quiet so I thought I might start here).
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
Oct 1, 2019, 10:42:35 PM10/1/19
to
On Tue, 1 Oct 2019 20:31:39 -0500, Peter Bishop wrote:
>
>in case anyone wants it, after much trial and error I finally found this working example of a multi-line STDPARM shell script for BPXBATCH. I still haven't found a way to have #comment lines, which seem to generate syntax errors, but if I accept that limitation, I am happy enough ...
>
Depends on what you need:
#! /bin/sh -x
uname -a;
: '
This is a no-op
masquerading
as a comment';
date;
exit;
Or, use JCL concatenation:
//STDPARM DD *
uname -a;
//* This
//* an embeddfed
//* JCL comment.
// DD *
date;
exit;
-- gil
>
>in case anyone wants it, after much trial and error I finally found this working example of a multi-line STDPARM shell script for BPXBATCH. I still haven't found a way to have #comment lines, which seem to generate syntax errors, but if I accept that limitation, I am happy enough ...
>
Depends on what you need:
#! /bin/sh -x
uname -a;
: '
This is a no-op
masquerading
as a comment';
date;
exit;
Or, use JCL concatenation:
//STDPARM DD *
uname -a;
//* This
//* an embeddfed
//* JCL comment.
// DD *
date;
exit;
-- gil
Peter Bishop
Oct 1, 2019, 11:10:23 PM10/1/19
to
Thanks heaps.
Firstly, the inline 'no op' which is handy but needs care.
STDPARM:
STDPARM:
FSUM7332 syntax error: got Word, expecting do
The JCL concatenation worked, and I'm going to use it as it's foolproof. As long as the comment and the resumption of SYSIN are moved together, they can go pretty much anywhere. If you need the symbols, remember to keep the SYMBOLS keyword on the resumed SYSIN.
// EXPORT SYMLIST=*
// SET BCDHOME='/usr/lpp/bcp/' home directory for BCP
// SET E='/u/bhpprq/' error messages here
// DD *,SYMBOLS=(EXECSYS,OUT)
Peter
Firstly, the inline 'no op' which is handy but needs care.
STDPARM:
SH (
set -o verbose ;
set -o errexit ;
set -x ;
for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ;
do
: 'any old comment' ;
set -o verbose ;
set -o errexit ;
set -x ;
for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ;
do
if [ -z "$(echo $jarname | grep Doc\.jar)" ] ;
then
echo adding to ClassPath ;
CLASSPATH="$CLASSPATH":"$jarname" ;
fi
done ;
echo CLASSPATH is $CLASSPATH ;
)
> &E.bcd-write.out 2>&E.bcd-write.err
STDERR is empty for this one. Works as expected. This next one fails, probably reasonably as it's in the middle of a 'for'.
then
echo adding to ClassPath ;
CLASSPATH="$CLASSPATH":"$jarname" ;
fi
done ;
echo CLASSPATH is $CLASSPATH ;
)
> &E.bcd-write.out 2>&E.bcd-write.err
STDPARM:
SH (
set -o verbose ;
set -o errexit ;
set -x ;
for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ;
: 'any old comment' ;
set -o verbose ;
set -o errexit ;
set -x ;
for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ;
do
if [ -z "$(echo $jarname | grep Doc\.jar)" ] ;
then
echo adding to ClassPath ;
CLASSPATH="$CLASSPATH":"$jarname" ;
fi
done ;
echo CLASSPATH is $CLASSPATH ;
)
> &E.bcd-write.out 2>&E.bcd-write.err
STDERR
if [ -z "$(echo $jarname | grep Doc\.jar)" ] ;
then
echo adding to ClassPath ;
CLASSPATH="$CLASSPATH":"$jarname" ;
fi
done ;
echo CLASSPATH is $CLASSPATH ;
)
> &E.bcd-write.out 2>&E.bcd-write.err
FSUM7332 syntax error: got Word, expecting do
The JCL concatenation worked, and I'm going to use it as it's foolproof. As long as the comment and the resumption of SYSIN are moved together, they can go pretty much anywhere. If you need the symbols, remember to keep the SYMBOLS keyword on the resumed SYSIN.
// EXPORT SYMLIST=*
// SET BCDHOME='/usr/lpp/bcp/' home directory for BCP
//*
//* multiline shell script with complex control structures
//*
//*
//* multiline shell script with complex control structures
//*
//*
//BPXBATCH EXEC PGM=BPXBATCH
//OUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDOUT DD SYSOUT=*
//STDPARM DD *,SYMBOLS=(EXECSYS,OUT)
SH (
set -o verbose ;
set -o errexit ;
set -x ;
for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ;
do
//* any old comment
//OUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDOUT DD SYSOUT=*
//STDPARM DD *,SYMBOLS=(EXECSYS,OUT)
SH (
set -o verbose ;
set -o errexit ;
set -x ;
for jarname in `ls &BCDHOME.batch/*.jar 2>/dev/null` ;
do
// DD *,SYMBOLS=(EXECSYS,OUT)
if [ -z "$(echo $jarname | grep Doc\.jar)" ] ;
then
echo adding to ClassPath ;
CLASSPATH="$CLASSPATH":"$jarname" ;
fi
done ;
echo CLASSPATH is $CLASSPATH ;
)
> &E.bcd-write.out 2>&E.bcd-write.err
//
cheers,
then
echo adding to ClassPath ;
CLASSPATH="$CLASSPATH":"$jarname" ;
fi
done ;
echo CLASSPATH is $CLASSPATH ;
)
> &E.bcd-write.out 2>&E.bcd-write.err
//
Peter
Paul Gilmartin
Oct 1, 2019, 11:35:46 PM10/1/19
to
On Tue, 1 Oct 2019 22:10:12 -0500, Peter Bishop wrote:
>Thanks heaps.
>
Yaay! You're welcome.
>Firstly, the inline 'no op' which is handy but needs care.
>
Oops!
Other thoughts:
BPXWUNIX supports DD:STDIN, DD:STDOUT, and DD:STDERR, for the
cost of a trivial Rexx driver. Then you get true multi-line code in
STDIN and comments work. But the FB80 afflicts you with trailing
blanks which interfere with continuation.
(You can code such a Rexx driver instream and REPRO it into SYSEXEC,
or keep it in a library.)
If you're using an editor such as ISPF that lets you insert binary
characters in hex, you can code:
SET NL='newline'
CHANGE 'newline' x'15'
... and use STDPARM SYMBOLS to insert linebreaks. You need
this only once, in a JCLLIB member. Code the &NL at the front
of each STDPARM line rather than the back to avoid leading blanks.
I hate JCL!
>Thanks heaps.
>
Yaay! You're welcome.
>Firstly, the inline 'no op' which is handy but needs care.
>
Other thoughts:
BPXWUNIX supports DD:STDIN, DD:STDOUT, and DD:STDERR, for the
cost of a trivial Rexx driver. Then you get true multi-line code in
STDIN and comments work. But the FB80 afflicts you with trailing
blanks which interfere with continuation.
(You can code such a Rexx driver instream and REPRO it into SYSEXEC,
or keep it in a library.)
If you're using an editor such as ISPF that lets you insert binary
characters in hex, you can code:
SET NL='newline'
CHANGE 'newline' x'15'
... and use STDPARM SYMBOLS to insert linebreaks. You need
this only once, in a JCLLIB member. Code the &NL at the front
of each STDPARM line rather than the back to avoid leading blanks.
I hate JCL!
Peter Bishop
Oct 2, 2019, 12:43:57 AM10/2/19
to
I love JCL (errr....at least I don't hate it quite as much as you).
I guess I'm just used to it and its infrastructure, e.g. automatic SYSOUT archiving (admittedly beyond the scope of JCL itself, but based on JCL-specified SYSOUT to start with). Lots of other good options from you below for those yet to acquire a taste for it. I for one am very happy to have multi-line STDPARM which greatly increases the utility of BPXBATCH for me. JCL and shell scripts: best of both worlds if you do it right.
best regards,
Peter
I guess I'm just used to it and its infrastructure, e.g. automatic SYSOUT archiving (admittedly beyond the scope of JCL itself, but based on JCL-specified SYSOUT to start with). Lots of other good options from you below for those yet to acquire a taste for it. I for one am very happy to have multi-line STDPARM which greatly increases the utility of BPXBATCH for me. JCL and shell scripts: best of both worlds if you do it right.
best regards,
Peter
Kirk Wolf
Oct 2, 2019, 11:46:06 AM10/2/19
to
BPXBATCH still sucks IMO. It only sucks a bit less than it used to suck.
It is probably the most to blame for slow uptake of z/OS Unix.
Thankfully, there are much better alternatives. Some even work the way
that you would expect to be able to run z/OS Unix programs / the shell in
batch.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Download and use COZBATCH free using our Community License:
https://dovetail.com/docs/cozbatch/intro.html#intro_features
It is probably the most to blame for slow uptake of z/OS Unix.
Thankfully, there are much better alternatives. Some even work the way
that you would expect to be able to run z/OS Unix programs / the shell in
batch.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Download and use COZBATCH free using our Community License:
https://dovetail.com/docs/cozbatch/intro.html#intro_features
Paul Gilmartin
Oct 2, 2019, 12:54:49 PM10/2/19
to
On Wed, 2 Oct 2019 10:45:39 -0500, Kirk Wolf wrote:
>BPXBATCH still sucks IMO. It only sucks a bit less than it used to suck.
>It is probably the most to blame for slow uptake of z/OS Unix.
>Thankfully, there are much better alternatives. Some even work the way
>that you would expect to be able to run z/OS Unix programs / the shell in
>batch.
>
AOPBATCH at least allows instream DD STDIN. IBM is unlikely to add that
>BPXBATCH still sucks IMO. It only sucks a bit less than it used to suck.
>It is probably the most to blame for slow uptake of z/OS Unix.
>Thankfully, there are much better alternatives. Some even work the way
>that you would expect to be able to run z/OS Unix programs / the shell in
>batch.
>
capability because that would enhance a bundled program to compete
with a separately charged program.
(I've heard a rumor that AOPBATCH is distributed with base z/OS, but
can't be used legally without a license.)
Would a SYSEXEC wrapper for BPXWUNIX be useful? What additional
features should it have beyond those of BPXBATCH?
John McKown
Oct 2, 2019, 12:59:38 PM10/2/19
to
On Wed, Oct 2, 2019 at 11:54 AM Paul Gilmartin <
0000000433f0781...@listserv.ua.edu> wrote:
> On Wed, 2 Oct 2019 10:45:39 -0500, Kirk Wolf wrote:
>
> >BPXBATCH still sucks IMO. It only sucks a bit less than it used to suck.
> >It is probably the most to blame for slow uptake of z/OS Unix.
> >Thankfully, there are much better alternatives. Some even work the way
> >that you would expect to be able to run z/OS Unix programs / the shell in
> >batch.
> >
> AOPBATCH at least allows instream DD STDIN. IBM is unlikely to add that
> capability because that would enhance a bundled program to compete
> with a separately charged program.
>
> (I've heard a rumor that AOPBATCH is distributed with base z/OS, but
> can't be used legally without a license.)
>
> Would a SYSEXEC wrapper for BPXWUNIX be useful? What additional
> features should it have beyond those of BPXBATCH?
>
> -- gil
>
>
Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12!
0000000433f0781...@listserv.ua.edu> wrote:
> On Wed, 2 Oct 2019 10:45:39 -0500, Kirk Wolf wrote:
>
> >BPXBATCH still sucks IMO. It only sucks a bit less than it used to suck.
> >It is probably the most to blame for slow uptake of z/OS Unix.
> >Thankfully, there are much better alternatives. Some even work the way
> >that you would expect to be able to run z/OS Unix programs / the shell in
> >batch.
> >
> AOPBATCH at least allows instream DD STDIN. IBM is unlikely to add that
> capability because that would enhance a bundled program to compete
> with a separately charged program.
>
> (I've heard a rumor that AOPBATCH is distributed with base z/OS, but
> can't be used legally without a license.)
>
> Would a SYSEXEC wrapper for BPXWUNIX be useful? What additional
> features should it have beyond those of BPXBATCH?
>
> -- gil
>
>
//PS001 EXEC PGM=BPXBATCH,REGION=0M
//*PARM='SH printenv '
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDIN DD DUMMY
//STDPARM DD *
SH awk 'BEGIN {count=0;file="";}
file != FILENAME && file != ""
{print "file " file " has " count " records"}
FNR == 1 {file=FILENAME;count=0;}
{count++;}
END {print "file " file " has " count " records"};
'
"//'sys1.maclib(getmain)'"
"//'sys1.maclib(read)'" |
cp /dev/fd/0 "//'tsh009.stdout.txt'"
/*
//
--
I find television very educational. The minute somebody turns it on, I go
into the library and read a good book
-- Groucho Marx
Maranatha! <><
John McKown
Paul Gilmartin
Oct 2, 2019, 2:15:22 PM10/2/19
to
On Wed, 2 Oct 2019 11:58:35 -0500, John McKown wrote:
>>
>Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12!
>
Easy enough when you have only one shell command and no comments.
>>
>Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12!
>
(I didn't know semicolons were optional between awk pattern-action statements. YLSED.)
It's a pity that "//DD:DDNAME" isn't supported as an operand of "cp".
Some say it works regardless, just if it breaks you get to keep both pieces.
>//PS001 EXEC PGM=BPXBATCH,REGION=0M
>//*PARM='SH printenv '
>//STDOUT DD SYSOUT=*
>//STDERR DD SYSOUT=*
>//STDIN DD DUMMY
>//STDPARM DD *
>SH awk 'BEGIN {count=0;file="";}
> {print "file " file " has " count " records"}
> FNR == 1 {file=FILENAME;count=0;}
> {count++;}
> END {print "file " file " has " count " records"};
> '
> "//'sys1.maclib(getmain)'"
> "//'sys1.maclib(read)'" |
> cp /dev/fd/0 "//'tsh009.stdout.txt'"
>/*
>//
-- gil
> FNR == 1 {file=FILENAME;count=0;}
> {count++;}
> END {print "file " file " has " count " records"};
> '
> "//'sys1.maclib(getmain)'"
> "//'sys1.maclib(read)'" |
> cp /dev/fd/0 "//'tsh009.stdout.txt'"
>/*
>//
John McKown
Oct 2, 2019, 2:22:36 PM10/2/19
to
On Wed, Oct 2, 2019 at 1:15 PM Paul Gilmartin <
0000000433f0781...@listserv.ua.edu> wrote:
> On Wed, 2 Oct 2019 11:58:35 -0500, John McKown wrote:
> >>
> >Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12!
> >
> Easy enough when you have only one shell command and no comments.
>
You can do multiple shell commands by using the semi-colon "end of command"
0000000433f0781...@listserv.ua.edu> wrote:
> On Wed, 2 Oct 2019 11:58:35 -0500, John McKown wrote:
> >>
> >Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12!
> >
> Easy enough when you have only one shell command and no comments.
>
character. But you're very correct about no comments. Well, sort of. there
is the "colon" command which is the equivalent of IEFBR14 in batch.
SH cd /tmp2;
pwd;
: sort of a comment;
ls -l;
Will work too. Output from above:
/LIH1/tmp2
total 2
drwxr-x--- 3 AXRUSER TSHG 288 Oct 13 2016 AXRUSER
--
I find television very educational. The minute somebody turns it on, I go
into the library and read a good book
-- Groucho Marx
Maranatha! <><
John McKown
Kirk Wolf
Oct 2, 2019, 3:53:01 PM10/2/19
to
You really like all of this mangling of the shell syntax?
What about "here" documents (quoted or otherwise) ?
The addition of STDPARM only makes it suck slightly less than before :-)
For heaven's sake, why doesn't it just read the input from DD:STDIN and
then send that to fd0 of the /bin/sh process?
That should be required for a passing grade. Extra credit if you can get
it to run /bin/sh as a *login* shell in the same address space, but not
much.
On Wed, Oct 2, 2019 at 1:22 PM John McKown <john.arch...@gmail.com>
wrote:
What about "here" documents (quoted or otherwise) ?
The addition of STDPARM only makes it suck slightly less than before :-)
For heaven's sake, why doesn't it just read the input from DD:STDIN and
then send that to fd0 of the /bin/sh process?
That should be required for a passing grade. Extra credit if you can get
it to run /bin/sh as a *login* shell in the same address space, but not
much.
On Wed, Oct 2, 2019 at 1:22 PM John McKown <john.arch...@gmail.com>
wrote:
Paul Gilmartin
Oct 2, 2019, 4:02:40 PM10/2/19
to
On Wed, 2 Oct 2019 14:52:32 -0500, Kirk Wolf wrote:
>You really like all of this mangling of the shell syntax?
>What about "here" documents (quoted or otherwise) ?
>The addition of STDPARM only makes it suck slightly less than before :-)
>
>For heaven's sake, why doesn't it just read the input from DD:STDIN and
>then send that to fd0 of the /bin/sh process?
>
BPXWUNIX can do that.
>You really like all of this mangling of the shell syntax?
>What about "here" documents (quoted or otherwise) ?
>The addition of STDPARM only makes it suck slightly less than before :-)
>
>For heaven's sake, why doesn't it just read the input from DD:STDIN and
>then send that to fd0 of the /bin/sh process?
>
Too many incomplete solutions.
>That should be required for a passing grade. Extra credit if you can get
>it to run /bin/sh as a *login* shell in the same address space, but not
>much.
>
Long ago, I posted my BPXWUNIX wrapper at:
http://vm.marist.edu/htbin/wlvtype?MVS-OE.26963
Some of the mangling I did there is now unnecessary with more
recent enhancements to BPXWUNIX.
-- gil
Peter Bishop
Oct 2, 2019, 5:16:48 PM10/2/19
to
Fully agree about the "too many solutions". If I could just use COZBATCH everywhere by default, I would, but I'm stuck with BPXBATCH and can now at least comment the multi-line shell scripts it supports, subject to correct placement of semicolons and other "mangled" shell and JCL.
The bit that bit me was the sparsely-documented semicolons ('do' and 'for' especially tricky) and the "EOF" from the '#' comment. Once bitten twice shy :-)
Thanks also to John M for his awk example which was educational.
best regards,
Peter
The bit that bit me was the sparsely-documented semicolons ('do' and 'for' especially tricky) and the "EOF" from the '#' comment. Once bitten twice shy :-)
Thanks also to John M for his awk example which was educational.
best regards,
Peter
Jon Perryman
Oct 5, 2019, 2:35:24 PM10/5/19
to
On Wednesday, October 2, 2019, 12:52:56 PM PDT, Kirk Wolf wrote:
> You really like all of this mangling of the shell syntax?
In all Unix systems, we simply avoid situations where this mangling is needed (e.g. "sh -c some-mangled-statements"). Why do you think this a good practice in BPXBATCH when it's considered a bad practice in Unix? The commonly accepted solution is to create a proper script file and call it.
> You really like all of this mangling of the shell syntax?
By the way, "#" comments must be terminated by a newline. The ";" command terminator character is considered to be part of the comment which is why you cannot terminate comments properly.
> For heaven's sake, why doesn't it just read the input from DD:STDIN
For IBM to do as you suggest, the DD:STDIN would be copied to FD0 ( Unix stdin ) which introduces several much larger problems and would cause confusion for the user. Scripts should always be in a script file otherwise the behavior changes and will cause confusion.
If you truly need the newline feature from inline JCL data, then have STDPARM copy your script DD (including newlines) and execute this copied script..
Alternatively, you could have an edit macro that submits a BPXBATCH job calling the script file you are currently editing.
Jon.
Kirk Wolf
Oct 6, 2019, 11:10:49 AM10/6/19
to
Jon,
I don't understand what you are saying.
On Sat, Oct 5, 2019 at 1:35 PM Jon Perryman <jper...@pacbell.net> wrote:
> On Wednesday, October 2, 2019, 12:52:56 PM PDT, Kirk Wolf wrote:
> > You really like all of this mangling of the shell syntax?
>
> In all Unix systems, we simply avoid situations where this mangling is
> needed (e.g. "sh -c some-mangled-statements"). Why do you think this a good
> practice in BPXBATCH when it's considered a bad practice in Unix? The
> commonly accepted solution is to create a proper script file and call it.
>
> What exactly are you referring to as good or bad practice? I don't
understand your point here at all.
> By the way, "#" comments must be terminated by a newline. The ";" command
> terminator character is considered to be part of the comment which is why
> you cannot terminate comments properly.
>
> > For heaven's sake, why doesn't it just read the input from DD:STDIN
>
> IBM simply followed the Unix standard practice. They start the shell and
> pass STDPARM data as an argument. Probably "sh -c
> data-from-stdparm-as-a-string". I suspect that newline is not supported
> because it's should be interpreted as end of the "sh" command.
>
> Which Unix standard practice? You never seem to address why taking
DD:STDIN as stdin to /bin/sh isn't the most desirable way for it to work?
BTW: You are correct: the concatenated lines from STDPARM are passed as the
arg to "sh -c". This is why all sorts of things work much differently
than if the script was in a file (either real or pipe). Another example
is that an an error message that refers to a line number in the input is
lost since it appears as one line.
> For IBM to do as you suggest, the DD:STDIN would be copied to FD0 ( Unix
> stdin ) which introduces several much larger problems and would cause
> confusion for the user. Scripts should always be in a script file otherwise
> the behavior changes and will cause confusion.
>
> Exactly what problems do you refer to?
I don't understand what you are saying.
On Sat, Oct 5, 2019 at 1:35 PM Jon Perryman <jper...@pacbell.net> wrote:
> On Wednesday, October 2, 2019, 12:52:56 PM PDT, Kirk Wolf wrote:
> > You really like all of this mangling of the shell syntax?
>
> In all Unix systems, we simply avoid situations where this mangling is
> needed (e.g. "sh -c some-mangled-statements"). Why do you think this a good
> practice in BPXBATCH when it's considered a bad practice in Unix? The
> commonly accepted solution is to create a proper script file and call it.
>
understand your point here at all.
> By the way, "#" comments must be terminated by a newline. The ";" command
> terminator character is considered to be part of the comment which is why
> you cannot terminate comments properly.
>
> > For heaven's sake, why doesn't it just read the input from DD:STDIN
>
> IBM simply followed the Unix standard practice. They start the shell and
> pass STDPARM data as an argument. Probably "sh -c
> data-from-stdparm-as-a-string". I suspect that newline is not supported
> because it's should be interpreted as end of the "sh" command.
>
DD:STDIN as stdin to /bin/sh isn't the most desirable way for it to work?
BTW: You are correct: the concatenated lines from STDPARM are passed as the
arg to "sh -c". This is why all sorts of things work much differently
than if the script was in a file (either real or pipe). Another example
is that an an error message that refers to a line number in the input is
lost since it appears as one line.
> For IBM to do as you suggest, the DD:STDIN would be copied to FD0 ( Unix
> stdin ) which introduces several much larger problems and would cause
> confusion for the user. Scripts should always be in a script file otherwise
> the behavior changes and will cause confusion.
>
Jon Perryman
Oct 6, 2019, 2:07:15 PM10/6/19
to
On Sunday, October 6, 2019, 08:10:44 AM PDT, Kirk Wolf <ki...@WOLF-ASSOCIATES.COM> wrote:
> I don't understand what you are saying.
I'm saying that IBM can't fix this problem because the problem lies with Unix shell design. This same exact problem exists in products that utilize "sh -c some-mangled-commands" (e.g. system automation). For those products, it's considered a bad practice to use script statements (e.g. IF) as part of the the mangled command. Even use of ";" command stacking should be limited. Instead, a script file is the preferred method. The BPXBATCH STDPARM example in this thread should be a script file because of it's complexity.
> I don't understand what you are saying.
Copying STDPARM to FD0 ( Unix stdin or pipe to stdin) is not an acceptable solution because commands and programs may consume the script. Script files do not get consumed. The mangled command does not get consumed.
Creating a script file really is not a good option. Unique file names and finding a directory for the script file can be a problem. Ensuring the script file is deleted at script termination could be a problem. I'm sure there are other problems that would need to be resolved.
Additionally, there are many shells available. All shells support passing a single line of commands which is the interface designed specifically for situations such as BPXBATCH. Sadly, shell design doesn't give us the best solution.
Jon.
Paul Gilmartin
Oct 6, 2019, 3:10:14 PM10/6/19
to
On Sun, 6 Oct 2019 18:06:16 +0000, Jon Perryman wrote:
>
>I'm saying that IBM can't fix this problem because the problem lies with Unix shell design. This same exact problem exists in products that utilize "sh -c some-mangled-commands" (e.g. system automation). For those products, it's considered a bad practice to use script statements (e.g. IF) as part of the the mangled command.
>
Why?
>
>I'm saying that IBM can't fix this problem because the problem lies with Unix shell design. This same exact problem exists in products that utilize "sh -c some-mangled-commands" (e.g. system automation). For those products, it's considered a bad practice to use script statements (e.g. IF) as part of the the mangled command.
>
The problem lies with JCL design, namely JCL's inability to pass a multi-line PARM.
Even use of ";" command stacking should be limited. Instead, a script file is the preferred method. The BPXBATCH STDPARM example in this thread should be a script file because of it's complexity.
>
>Copying STDPARM to FD0 ( Unix stdin or pipe to stdin) is not an acceptable solution because commands and programs may consume the script. Script files do not get consumed. The mangled command does not get consumed.
>
>Creating a script file really is not a good option. Unique file names and finding a directory for the script file can be a problem. Ensuring the script file is deleted at script termination could be a problem. I'm sure there are other problems that would need to be resolved.
>
to be consumed rather than persist.
(sh invisibly creates and deletes temp files for constructs such as
command substitution and here-documents.)
>Additionally, there are many shells available. All shells support passing a single line of commands which is the interface designed specifically for situations such as BPXBATCH. Sadly, shell design doesn't give us the best solution.
>
lies in BPXBATCH's (in fact all of JCL's) inability to pass multiple arguments.
I can't even pass an alternate DDNAME list to a classic utility.
POSIX shell allows great complexity in a single line. An example:
695 $ cat x
#! /bin/sh
: Define a multiple command string:
S="p() { echo; echo \"The argument passed was:\"; echo \" \$1\"; return; }; p foo; p bar"
: Execute it with sh:
/bin/sh -c "$S"
696 $ ./x
The argument passed was:
foo
The argument passed was:
bar
697 $
Jon Perryman
Oct 6, 2019, 11:04:59 PM10/6/19
to
The Unix concept of line implies the new line character which is not standard z/OS. Multi-line JCL parm does not make sense in this context.
JCL does in fact pass multiple arguments but it is not compatible with Unix (PARM=(A,B) ).
Specifying alternate DD names has nothing to do with JCL. If I remember correctly there are several utilities that allow this. BPXBATCH could easily support this if needed.
Ask yourself why there are so many variations on running a shell in batch. First, they are extremely easy to create. Second, everyone has their own idea what is needed.
As for FD0 (stdin) being consumed, I could care less. I'm just stating that implementing this in BPXBATCH would cause confusion. A command or readline could potentially be reading part of the script as if it were data.
I don't know where you get the idea I'm arguing against myself. Using a file as a possible solution poses a unique set of problems. Ultimately you don't want a command to use the script as data.
Creating complex commands is not a problem as such but do they make sense to use in STDPARM outside of personal use? I would think it's less desirable for production where operations makes changes that could easily be error prone and difficult for those with less experience.
Jon.
JCL does in fact pass multiple arguments but it is not compatible with Unix (PARM=(A,B) ).
Specifying alternate DD names has nothing to do with JCL. If I remember correctly there are several utilities that allow this. BPXBATCH could easily support this if needed.
Ask yourself why there are so many variations on running a shell in batch. First, they are extremely easy to create. Second, everyone has their own idea what is needed.
As for FD0 (stdin) being consumed, I could care less. I'm just stating that implementing this in BPXBATCH would cause confusion. A command or readline could potentially be reading part of the script as if it were data.
I don't know where you get the idea I'm arguing against myself. Using a file as a possible solution poses a unique set of problems. Ultimately you don't want a command to use the script as data.
Creating complex commands is not a problem as such but do they make sense to use in STDPARM outside of personal use? I would think it's less desirable for production where operations makes changes that could easily be error prone and difficult for those with less experience.
Jon.
David Crayford
Oct 6, 2019, 11:14:42 PM10/6/19
to
On 2019-10-07 2:06 AM, Jon Perryman wrote:
> I'm saying that IBM can't fix this problem because the problem lies with Unix shell design.
I have no idea what you're talking about!
> I'm saying that IBM can't fix this problem because the problem lies with Unix shell design.
IBM can and have fixed the problem! BPXBATCH is so bad they wrote a
replacement AOPBATCH which works just as Kirk describes.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.aokfa00/batdd.htm#batdd
https://dovetail.com/products/cozbatch.html
>
> Copying STDPARM to FD0 ( Unix stdin or pipe to stdin) is not an acceptable solution because commands and programs may consume the script. Script files do not get consumed. The mangled command does not get consumed.
>
> Creating a script file really is not a good option. Unique file names and finding a directory for the script file can be a problem. Ensuring the script file is deleted at script termination could be a problem. I'm sure there are other problems that would need to be resolved.
>
> Additionally, there are many shells available. All shells support passing a single line of commands which is the interface designed specifically for situations such as BPXBATCH. Sadly, shell design doesn't give us the best solution.
Jon Perryman
Oct 29, 2019, 4:25:11 PM10/29/19
to
On Sunday, October 6, 2019, 08:14:36 PM PDT, David Crayford <dcra...@gmail.com> wrote:
>On 2019-10-07 2:06 AM, Jon Perryman wrote:
>> I'm saying that IBM can't fix this problem because the problem lies with Unix shell design.
> IBM can and have fixed the problem! BPXBATCH is so bad they wrote a
> replacement AOPBATCH which works just as Kirk describes.
IBM does not consider BPXBATCH bad. AOPBATCH is not a replacement for BPXBATCH. The AOP group wanted something different than BPXBATCH. I believe that BPXBATCH was documented as running a Unix command but we stacked commands by using the semicolon command separator.
> replacement AOPBATCH which works just as Kirk describes.
AOPBATCH simply changes the problems. IBM doesn't need to address those problems because they are outside the scope of AOP.
Jon.
Paul Gilmartin
Oct 29, 2019, 4:45:24 PM10/29/19
to
Welcome back.
On Tue, 29 Oct 2019 20:21:07 +0000, Jon Perryman wrote:
An often-criticized limitation of BPXBATCH is that it does not tolerate
instream data sets or classic data sets as STDIN. AOPBATCH removes
that limitation and introduces no new limitations (AFAIK?) Stacked
commands using a semicolon separator do not allow "#" comments.
Comments are widely considered a valuable aspect of coding technique.
Are you arguing for a semantic distinction between "fixing a problem"
and "removing an onerous limitation"?
-- gil
On Tue, 29 Oct 2019 20:21:07 +0000, Jon Perryman wrote:
>
> On Sunday, October 6, 2019, 08:14:36 PM PDT, David Crayford wrote:
>
> >On 2019-10-07 2:06 AM, Jon Perryman wrote:
>
>>> I'm saying that IBM can't fix this problem because the problem lies with Unix shell design.
>
>> IBM can and have fixed the problem! BPXBATCH is so bad they wrote a
>> replacement AOPBATCH which works just as Kirk describes.
>
>IBM does not consider BPXBATCH bad. AOPBATCH is not a replacement for BPXBATCH. The AOP group wanted something different than BPXBATCH. I believe that BPXBATCH was documented as running a Unix command but we stacked commands by using the semicolon command separator.
>
>AOPBATCH simply changes the problems. IBM doesn't need to address those problems because they are outside the scope of AOP.
>
Oh, my. True Blue!
> On Sunday, October 6, 2019, 08:14:36 PM PDT, David Crayford wrote:
>
> >On 2019-10-07 2:06 AM, Jon Perryman wrote:
>
>>> I'm saying that IBM can't fix this problem because the problem lies with Unix shell design.
>
>> IBM can and have fixed the problem! BPXBATCH is so bad they wrote a
>> replacement AOPBATCH which works just as Kirk describes.
>
>IBM does not consider BPXBATCH bad. AOPBATCH is not a replacement for BPXBATCH. The AOP group wanted something different than BPXBATCH. I believe that BPXBATCH was documented as running a Unix command but we stacked commands by using the semicolon command separator.
>
>AOPBATCH simply changes the problems. IBM doesn't need to address those problems because they are outside the scope of AOP.
>
An often-criticized limitation of BPXBATCH is that it does not tolerate
instream data sets or classic data sets as STDIN. AOPBATCH removes
that limitation and introduces no new limitations (AFAIK?) Stacked
commands using a semicolon separator do not allow "#" comments.
Comments are widely considered a valuable aspect of coding technique.
Are you arguing for a semantic distinction between "fixing a problem"
and "removing an onerous limitation"?
-- gil
David Crayford
Oct 30, 2019, 1:27:14 AM10/30/19
to
On 2019-10-30 4:45 AM, Paul Gilmartin wrote:
>>> On 2019-10-07 2:06 AM, Jon Perryman wrote:
>>>> I'm saying that IBM can't fix this problem because the problem lies with Unix shell design.
>>> IBM can and have fixed the problem! BPXBATCH is so bad they wrote a
>>> replacement AOPBATCH which works just as Kirk describes.
>> IBM does not consider BPXBATCH bad. AOPBATCH is not a replacement for BPXBATCH. The AOP group wanted something different than BPXBATCH. I believe that BPXBATCH was documented as running a Unix command but we stacked commands by using the semicolon command separator.
How do you know? Do you work for IBM? Only the village idiot would
>>> On 2019-10-07 2:06 AM, Jon Perryman wrote:
>>>> I'm saying that IBM can't fix this problem because the problem lies with Unix shell design.
>>> IBM can and have fixed the problem! BPXBATCH is so bad they wrote a
>>> replacement AOPBATCH which works just as Kirk describes.
>> IBM does not consider BPXBATCH bad. AOPBATCH is not a replacement for BPXBATCH. The AOP group wanted something different than BPXBATCH. I believe that BPXBATCH was documented as running a Unix command but we stacked commands by using the semicolon command separator.
consider BPXBATCH not to be *bad* :) Maybe you've never been unlucky
enough to have to use it!
>> AOPBATCH simply changes the problems. IBM doesn't need to address those problems because they are outside the scope of AOP.
>>
> Oh, my. True Blue!
> An often-criticized limitation of BPXBATCH is that it does not tolerate
> instream data sets or classic data sets as STDIN. AOPBATCH removes
> that limitation and introduces no new limitations (AFAIK?) Stacked
> commands using a semicolon separator do not allow "#" comments.
> Comments are widely considered a valuable aspect of coding technique.
I have used COZBATCH for years but recently had a requirement to be able
to ship something similar so we could install a web application from a
PAX member using a batch job.
I wrote my own batch shell utility using a tip from Kirk Wolf. It was
very simple to implement, another reason why it's so disappointing that
BPXBATCH is so wretched.
Anyway, we already had this conversation 10 years ago and it's not worth
dragging it up again.
> Are you arguing for a semantic distinction between "fixing a problem"
> and "removing an onerous limitation"?
John McKown
Oct 30, 2019, 7:45:43 AM10/30/19
to
Here is my "solution". Actually, I got it from someone R Zenuk. It consists
of a PROC, and a REXX program.
=== proc ===
//BPXJCL PROC USSCMD=,
//*******************************************************************
//* PROC: BPXJCL *
//* *
//* PURPOSE: RUN A USS COMMAND USING THE BPXJCL EXEC *
//* *
//* SYMBOLICS: *
//* *
//* USSCMD - THE USS COMMAND TO EXECUTE *
//* EXECLIB - DSN WHERE BPXJCL EXEC LIVES *
//* *
//* CHANGE LOG *
//* *
//* USER REASON DATE *
//* -------- ------------------------------------- -------- *
//* R. ZENUK INITIAL SETUP 01/20/00 *
//* *
//*******************************************************************
// EXECLIB=SYS1.LI.CLIST.CNTL
//*******************************************************************
//* *
//*******************************************************************
//BPXJCL EXEC PGM=IKJEFT01,PARM='%BPXJCL &USSCMD'
//SYSEXEC DD DSN=&EXECLIB,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
/*********************************************************************/
/* REXX */
/*********************************************************************/
/* Purpose: Use BPXWUNIX to redirect STDOUT and STDERR to SYSOUT */
/*-------------------------------------------------------------------*/
/* Syntax: BPXJCL command */
/*-------------------------------------------------------------------*/
/* Parms: command - Any USS command */
/* */
/*********************************************************************/
/* Change Log */
/* */
/* Author Date Reason */
/* -------- --------- ----------------------------------------- */
/* R. Zenuk Jan 2000 Initial Creation */
/* */
/*********************************************************************/
parse arg command
say mvsvar('SYSNAME') mvsvar('SYMDEF','JOBNAME') date() time()
say
say 'Executing command:' command
say
exit BPXWUNIX(command,'DD:stdin','DD:stdout','DD:stderr','0')
=== Sample JOB ===
//TSH009X3 JOB (H00000I),'BPXJCL',
// CLASS=Z,TIME=NOLIMIT,
// MSGCLASS=X, SER=BPXROOT,
// NOTIFY=&SYSUID
//*
//STEP1 EXEC PROC=BPXJCL,USSCMD='/bin/sh -L'
//STDIN DD *
set -x
df
//
--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown
of a PROC, and a REXX program.
=== proc ===
//BPXJCL PROC USSCMD=,
//*******************************************************************
//* PROC: BPXJCL *
//* *
//* PURPOSE: RUN A USS COMMAND USING THE BPXJCL EXEC *
//* *
//* SYMBOLICS: *
//* *
//* USSCMD - THE USS COMMAND TO EXECUTE *
//* EXECLIB - DSN WHERE BPXJCL EXEC LIVES *
//* *
//* CHANGE LOG *
//* *
//* USER REASON DATE *
//* -------- ------------------------------------- -------- *
//* R. ZENUK INITIAL SETUP 01/20/00 *
//* *
//*******************************************************************
// EXECLIB=SYS1.LI.CLIST.CNTL
//*******************************************************************
//* *
//*******************************************************************
//BPXJCL EXEC PGM=IKJEFT01,PARM='%BPXJCL &USSCMD'
//SYSEXEC DD DSN=&EXECLIB,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDIN DD DUMMY
=== REXX program ===
//STDERR DD SYSOUT=*
//STDIN DD DUMMY
/*********************************************************************/
/* REXX */
/*********************************************************************/
/* Purpose: Use BPXWUNIX to redirect STDOUT and STDERR to SYSOUT */
/*-------------------------------------------------------------------*/
/* Syntax: BPXJCL command */
/*-------------------------------------------------------------------*/
/* Parms: command - Any USS command */
/* */
/*********************************************************************/
/* Change Log */
/* */
/* Author Date Reason */
/* -------- --------- ----------------------------------------- */
/* R. Zenuk Jan 2000 Initial Creation */
/* */
/*********************************************************************/
parse arg command
say mvsvar('SYSNAME') mvsvar('SYMDEF','JOBNAME') date() time()
say
say 'Executing command:' command
say
exit BPXWUNIX(command,'DD:stdin','DD:stdout','DD:stderr','0')
=== Sample JOB ===
//TSH009X3 JOB (H00000I),'BPXJCL',
// CLASS=Z,TIME=NOLIMIT,
// MSGCLASS=X, SER=BPXROOT,
// NOTIFY=&SYSUID
//*
//STEP1 EXEC PROC=BPXJCL,USSCMD='/bin/sh -L'
//STDIN DD *
set -x
df
//
--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown
Don Poitras
Oct 30, 2019, 9:37:16 AM10/30/19
to
When I looked into this a while back, here's what I came up with. I really don't
like the semi-colons and I really want to see the output along with the commands.
I'm also a fan of having everything contained in one member so that I don't have
to maintain stuff in different spots.
---
//DONBPX2 JOB (,R282),POITRAS,NOTIFY=SASDTP,TIME=(0,10),CLASS=A,
// REGION=1M,MSGCLASS=A
//*
//* The idea here is that I'd like to see the commands printed
//* along with the output. set -x will do that (while printing
//* a "+" in front of the commands, but that's ok), but sends
//* it's debugging output to stderr. By setting stdout and
//* stderr to the same file, the output is interleaved and the
//* final step prints the result.
//*
//COPY1 EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSUT1 DD *
set -x
cd /u/sasdtp/temp
pwd
ls -Fartl
date
/*
//SYSUT2 DD PATH='/u/sasdtp/donbpx2.txt',
// PATHOPTS=(ORDWR,OTRUNC,OCREAT),PATHMODE=SIRWXU,
// PATHDISP=(KEEP,DELETE),FILEDATA=TEXT
//SYSPRINT DD SYSOUT=*
//BPXBAT EXEC PGM=BPXBATCH,PARMDD=PARMINDD
//STDIN DD DUMMY
//STDOUT DD PATH='/u/sasdtp/donbpx2.out.txt',
// PATHOPTS=(OWRONLY,OTRUNC,OCREAT),PATHMODE=SIRWXU,
// PATHDISP=(KEEP,DELETE),FILEDATA=TEXT
//STDERR DD PATH='/u/sasdtp/donbpx2.out.txt',
// PATHOPTS=(OWRONLY,OTRUNC,OCREAT),PATHMODE=SIRWXU,
// PATHDISP=(KEEP,DELETE),FILEDATA=TEXT
//PARMINDD DD *
sh /u/sasdtp/donbpx2.txt
/*
//COPY2 EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSUT1 DD PATH='/u/sasdtp/donbpx2.out.txt',
// PATHOPTS=(ORDONLY),
// RECFM=VB,LRECL=1024,BLKSIZE=3000
//SYSUT2 DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//
---
Running this job sends the output to sysout:
---
+ cd /u/sasdtp/temp
+ pwd
/u/sasdtp/temp
+ ls -Fartl
total 20172
-rw-r--r-- 1 SASDTP CCD 5797 Jan 19 2011 hexdump.C
-rwxr-xr-x 1 SASDTP CCD 118784 Jan 19 2011 hexdump*
-rwx------ 1 SASDTP CCD 129024 Jan 20 2011 hexdump.pax*
-rw-r--r-- 1 SASDTP CCD 10000000 Jul 30 2018 tmp.txt
drwxr-xr-x 2 SASDTP CCD 8192 Jul 30 2018 ./
drwxr-xr-x 130 SASDTP CCD 32768 Oct 4 15:29 ../
+ date
Wed Oct 30 09:34:09 EDT 2019
---
--
Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
sas...@sas.com (919) 531-5637 Cary, NC 27513
like the semi-colons and I really want to see the output along with the commands.
I'm also a fan of having everything contained in one member so that I don't have
to maintain stuff in different spots.
---
//DONBPX2 JOB (,R282),POITRAS,NOTIFY=SASDTP,TIME=(0,10),CLASS=A,
// REGION=1M,MSGCLASS=A
//*
//* The idea here is that I'd like to see the commands printed
//* along with the output. set -x will do that (while printing
//* a "+" in front of the commands, but that's ok), but sends
//* it's debugging output to stderr. By setting stdout and
//* stderr to the same file, the output is interleaved and the
//* final step prints the result.
//*
//COPY1 EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSUT1 DD *
set -x
cd /u/sasdtp/temp
pwd
ls -Fartl
date
/*
//SYSUT2 DD PATH='/u/sasdtp/donbpx2.txt',
// PATHOPTS=(ORDWR,OTRUNC,OCREAT),PATHMODE=SIRWXU,
// PATHDISP=(KEEP,DELETE),FILEDATA=TEXT
//SYSPRINT DD SYSOUT=*
//BPXBAT EXEC PGM=BPXBATCH,PARMDD=PARMINDD
//STDIN DD DUMMY
//STDOUT DD PATH='/u/sasdtp/donbpx2.out.txt',
// PATHOPTS=(OWRONLY,OTRUNC,OCREAT),PATHMODE=SIRWXU,
// PATHDISP=(KEEP,DELETE),FILEDATA=TEXT
//STDERR DD PATH='/u/sasdtp/donbpx2.out.txt',
// PATHOPTS=(OWRONLY,OTRUNC,OCREAT),PATHMODE=SIRWXU,
// PATHDISP=(KEEP,DELETE),FILEDATA=TEXT
//PARMINDD DD *
sh /u/sasdtp/donbpx2.txt
/*
//COPY2 EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSUT1 DD PATH='/u/sasdtp/donbpx2.out.txt',
// PATHOPTS=(ORDONLY),
// RECFM=VB,LRECL=1024,BLKSIZE=3000
//SYSUT2 DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//
---
Running this job sends the output to sysout:
---
+ cd /u/sasdtp/temp
+ pwd
/u/sasdtp/temp
+ ls -Fartl
total 20172
-rw-r--r-- 1 SASDTP CCD 5797 Jan 19 2011 hexdump.C
-rwxr-xr-x 1 SASDTP CCD 118784 Jan 19 2011 hexdump*
-rwx------ 1 SASDTP CCD 129024 Jan 20 2011 hexdump.pax*
-rw-r--r-- 1 SASDTP CCD 10000000 Jul 30 2018 tmp.txt
drwxr-xr-x 2 SASDTP CCD 8192 Jul 30 2018 ./
drwxr-xr-x 130 SASDTP CCD 32768 Oct 4 15:29 ../
+ date
Wed Oct 30 09:34:09 EDT 2019
---
--
Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
sas...@sas.com (919) 531-5637 Cary, NC 27513
Kirk Wolf
Oct 30, 2019, 12:52:28 PM10/30/19
to
On Wed, Oct 30, 2019 at 12:27 AM David Crayford <dcra...@gmail.com> wrote:
> I have used COZBATCH for years but recently had a requirement to be able
> to ship something similar so we could install a web application from a
> PAX member using a batch job.
> I wrote my own batch shell utility using a tip from Kirk Wolf. It was
> very simple to implement, another reason why it's so disappointing that
> BPXBATCH is so wretched.
>
> Anyway, we already had this conversation 10 years ago and it's not worth
> dragging it up again.
>
> FWIW, it was much longer than that! We originally released COZBATCH in
> I have used COZBATCH for years but recently had a requirement to be able
> to ship something similar so we could install a web application from a
> PAX member using a batch job.
> I wrote my own batch shell utility using a tip from Kirk Wolf. It was
> very simple to implement, another reason why it's so disappointing that
> BPXBATCH is so wretched.
>
> Anyway, we already had this conversation 10 years ago and it's not worth
> dragging it up again.
>
2007 as a free download (at that time named "DTLSPAWN"). We wrote it in a
day after utter frustration with how much list traffic was posted *for
years* on BPXBATCH issues. The mvs-oe list was almost completely
dedicated to it. It has been enhanced with lots of little creature
comforts over the years, but it is still about 1000 lines of code.
Kirk Wolf
Dovetailed Technologies
https://dovetail.com/docs/cozbatch/intro.html#intro_features
https://dovetail.com/support.html
Paul Gilmartin
Oct 30, 2019, 1:29:19 PM10/30/19
to
On Wed, 30 Oct 2019 09:36:59 -0400, Don Poitras wrote:
>....
and STDERR, so the COPY2 step is unnecessary.
STDOUT and STDERR can be merged with the shell command:
exec 2>&1
BPBATCH still sucks. IBM is unlikely to enhance it because it competes
with the separately priced AOPBATCH.
-- gil
>....
>//* The idea here is that I'd like to see the commands printed
>//* along with the output. set -x will do that (while printing
>//* a "+" in front of the commands, but that's ok), but sends
>//* it's debugging output to stderr. By setting stdout and
>//* stderr to the same file, the output is interleaved and the
>//* final step prints the result.
>//*
Nowadays (for several releases) BPXBATCH can use SYSOUT for STDOUT
>//* along with the output. set -x will do that (while printing
>//* a "+" in front of the commands, but that's ok), but sends
>//* it's debugging output to stderr. By setting stdout and
>//* stderr to the same file, the output is interleaved and the
>//* final step prints the result.
>//*
and STDERR, so the COPY2 step is unnecessary.
STDOUT and STDERR can be merged with the shell command:
exec 2>&1
BPBATCH still sucks. IBM is unlikely to enhance it because it competes
with the separately priced AOPBATCH.
-- gil
Kirk Wolf
Oct 30, 2019, 1:44:38 PM10/30/19
to
On Wed, Oct 30, 2019 at 12:29 PM Paul Gilmartin <
0000000433f0781...@listserv.ua.edu> wrote:
> BPBATCH still sucks. IBM is unlikely to enhance it because it competes
> with the separately priced AOPBATCH.
>
> It seems very unlikely to me that this is the reason.
0000000433f0781...@listserv.ua.edu> wrote:
> BPBATCH still sucks. IBM is unlikely to enhance it because it competes
> with the separately priced AOPBATCH.
>
Frank Swarbrick
Oct 30, 2019, 6:07:29 PM10/30/19
to
As someone who rarely uses BPXBATCH, and doesn't have an alternate program, I'm curious as to some of the major issues with BPXBATCH.
Actually, I am curious to the need of BPXBATCH altogether. I ponder, occasionally, if JCL could be changed somehow to support a kind of EXEC statement that would allow for a lower case parameter that would be the name of, or path to, a USS program. But I don't have any idea what other requirements these "batch" programs fulfill.
________________________________
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Kirk Wolf <ki...@WOLF-ASSOCIATES.COM>
Sent: Wednesday, October 30, 2019 10:52 AM
To: IBM-...@LISTSERV.UA.EDU <IBM-...@LISTSERV.UA.EDU>
Subject: Re: multi-line STDPARM shell script for BPXBATCH
Actually, I am curious to the need of BPXBATCH altogether. I ponder, occasionally, if JCL could be changed somehow to support a kind of EXEC statement that would allow for a lower case parameter that would be the name of, or path to, a USS program. But I don't have any idea what other requirements these "batch" programs fulfill.
________________________________
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Kirk Wolf <ki...@WOLF-ASSOCIATES.COM>
Sent: Wednesday, October 30, 2019 10:52 AM
To: IBM-...@LISTSERV.UA.EDU <IBM-...@LISTSERV.UA.EDU>
Subject: Re: multi-line STDPARM shell script for BPXBATCH
Farley, Peter x23353
Oct 30, 2019, 6:39:53 PM10/30/19
to
Frank,
As one example, consider text manipulation and reformatting. In the *ix worlds (including z/Linux), (g)awk and/or perl seem to be the languages of choice for searching and/or rearranging and/or selecting data from text files. z/OS Unix has at least a version of the awk utility that supports the POSIX version of the language, and I have used it myself quite often in off-the-cuff data analysis and formatting tasks for management reports. "awk" is one program you might indeed want to run in a batch JCL process.
BPXBATCH or one of its replacements (AOPBATCH, COZBATCH) is how you do that in JCL. Could JCL support z/OS Unix programs directly rather than via an interface program like BPXBATCH? Sure, SMOP. But not very likely to get IBM's attention or resources (ROI, don'cha know). Tools or system facilities that make programmers jobs easier but don't predictably result in a (larger) IBM profit are never very high on that scale.
Could you use Rexx for these kinds of tasks? Sure you could, but sometimes the other languages let you do it with less person-time and effort because of the facilities that each offers that Rexx may not, or at least not as easily.
I'm not trying to start a language flame war here, just providing an example from my own experience.
Peter
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
As one example, consider text manipulation and reformatting. In the *ix worlds (including z/Linux), (g)awk and/or perl seem to be the languages of choice for searching and/or rearranging and/or selecting data from text files. z/OS Unix has at least a version of the awk utility that supports the POSIX version of the language, and I have used it myself quite often in off-the-cuff data analysis and formatting tasks for management reports. "awk" is one program you might indeed want to run in a batch JCL process.
BPXBATCH or one of its replacements (AOPBATCH, COZBATCH) is how you do that in JCL. Could JCL support z/OS Unix programs directly rather than via an interface program like BPXBATCH? Sure, SMOP. But not very likely to get IBM's attention or resources (ROI, don'cha know). Tools or system facilities that make programmers jobs easier but don't predictably result in a (larger) IBM profit are never very high on that scale.
Could you use Rexx for these kinds of tasks? Sure you could, but sometimes the other languages let you do it with less person-time and effort because of the facilities that each offers that Rexx may not, or at least not as easily.
I'm not trying to start a language flame war here, just providing an example from my own experience.
Peter
Paul Gilmartin
Oct 30, 2019, 9:59:57 PM10/30/19
to
On Wed, 30 Oct 2019 22:07:13 +0000, Frank Swarbrick wrote:
>
>Actually, I am curious to the need of BPXBATCH altogether. I ponder, occasionally, if JCL could be changed somehow to support a kind of EXEC statement that would allow for a lower case parameter that would be the name of, or path to, a USS program. But I don't have any idea what other requirements these "batch" programs fulfill.
>
o Support UNIX directories as STEPLIB catenands. Using Data Sets states
>
>Actually, I am curious to the need of BPXBATCH altogether. I ponder, occasionally, if JCL could be changed somehow to support a kind of EXEC statement that would allow for a lower case parameter that would be the name of, or path to, a USS program. But I don't have any idea what other requirements these "batch" programs fulfill.
>
that a Partitioned Concatenation may mix PDS, PDSE, and UNIX directories.
This works for HLASM SYSLIB. Why not likewise for STEPLIB and Binder
SYSLIB?
o Allow a quoted argument in EXEC PGM='MixCase'. Relaxing the 8-character
limit would be added value, but not essential. There should be no need for
a new "kind of EXEC statement".
This leaves unaddressed the need for STDIN, STDOUT, and STDERR; pretty
much required by POSIX.
-- gil
David Crayford
Oct 31, 2019, 6:00:11 AM10/31/19
to
That's quite nifty. Does it support local spawn and using DD names in
the script?
the script?
Jon Perryman
Nov 2, 2019, 2:55:40 PM11/2/19
to
On Tuesday, October 29, 2019, 01:45:18 PM PDT, Paul Gilmartin <0000000433f0781...@listserv.ua.edu> wrote:
> Oh, my. True Blue!
> AOPBATCH removes that limitation and introduces no new limitations (AFAIK?)
How many people ignore that AOPBATCH and COZBATCH execute in the callers address space and think it's always a good thing! When called from a program, you are exposing anything running in the address space to various problems and security exposures. BPXBATCH eliminates this consideration. If IBM fixes this exposure, then AOPBATCH loses the features you treasure.
There are situations where you don't care but you should always review AOPBATCH's use when called from a program. When I was a developer for a system critical OEM product, I occasionally encountered failure situations where customers were using AOPBATCH within the product. Our standard answer was that AOPBATCH is not documented for this use.
Jon.
> Oh, my. True Blue!
> AOPBATCH removes that limitation and introduces no new limitations (AFAIK?)
> Are you arguing for a semantic distinction between "fixing a problem" and "removing an onerous limitation"?
IBM knows that people will do things regardless of the risk. In this case, they avoid responsibility by not documenting and maintaining AOPBATCH as a BPXBATCH replacement. Oh my, True Blue doing one more smart thing by letting you take responsibility for the risk.
How many people ignore that AOPBATCH and COZBATCH execute in the callers address space and think it's always a good thing! When called from a program, you are exposing anything running in the address space to various problems and security exposures. BPXBATCH eliminates this consideration. If IBM fixes this exposure, then AOPBATCH loses the features you treasure.
There are situations where you don't care but you should always review AOPBATCH's use when called from a program. When I was a developer for a system critical OEM product, I occasionally encountered failure situations where customers were using AOPBATCH within the product. Our standard answer was that AOPBATCH is not documented for this use.
Jon.
Paul Gilmartin
Nov 2, 2019, 3:38:42 PM11/2/19
to
On Sat, 2 Nov 2019 18:53:35 +0000, Jon Perryman wrote:
> ...
Doesn't any program object invoked by // EXEC PGM= execute in the initiator's
address space? Else ENQs and DDNAMEs created by the initiator would not be
available to the target program. Does this create the same exposure? Does the
initiator protect itself by keeping its own storage all in system key or protected
by segment protection? Is AOPBATCH not protected the same way? Is there the
same exposure for any user-coded program that uses LINK or ATTACH? How
does the exposure compare with BPX1SPN BPX_SHAREAS=MUST /bin/sh?
-- gil
> ...
>How many people ignore that AOPBATCH and COZBATCH execute in the callers address space and think it's always a good thing! When called from a program, you are exposing anything running in the address space to various problems and security exposures. BPXBATCH eliminates this consideration. If IBM fixes this exposure, then AOPBATCH loses the features you treasure.
>
I see. But I need enlightment.
>
Doesn't any program object invoked by // EXEC PGM= execute in the initiator's
address space? Else ENQs and DDNAMEs created by the initiator would not be
available to the target program. Does this create the same exposure? Does the
initiator protect itself by keeping its own storage all in system key or protected
by segment protection? Is AOPBATCH not protected the same way? Is there the
same exposure for any user-coded program that uses LINK or ATTACH? How
does the exposure compare with BPX1SPN BPX_SHAREAS=MUST /bin/sh?
-- gil
Jon Perryman
Nov 2, 2019, 7:03:34 PM11/2/19
to
On Saturday, November 2, 2019, 12:38:38 PM PDT, Paul Gilmartin wrote:
> Doesn't any program object invoked by // EXEC PGM= execute in the initiator's
> address space?
Sorry. I forgot to say EXEC PGM=AOPBATCH is safe.
> Doesn't any program object invoked by // EXEC PGM= execute in the initiator's
> address space?
> Is there the same exposure for any user-coded program that uses LINK or ATTACH?
Address space sharing has rules and it's been far too long for me to remember the specifics. Those rules could easily have changed since I last used it. BPXBATCH always ensured you worked in a safe environment without the need to understand those rules.
> How does the exposure compare with BPX1SPN BPX_SHAREAS=MUST /bin/sh?
Jon.
Paul Gilmartin
Nov 2, 2019, 10:35:13 PM11/2/19
to
On Sat, 2 Nov 2019 23:03:16 +0000, Jon Perryman wrote:
>
>> Doesn't any program object invoked by // EXEC PGM= execute in the initiator's
>> address space?
>
>Sorry. I forgot to say EXEC PGM=AOPBATCH is safe.
>
That might be true if AOPBATCH were installed with AC=0
>
>> Doesn't any program object invoked by // EXEC PGM= execute in the initiator's
>> address space?
>
>Sorry. I forgot to say EXEC PGM=AOPBATCH is safe.
>
in an authorized library.
>> Is there the same exposure for any user-coded program that uses LINK or ATTACH?
>
>The AOPBATCH exposure is with LINK or ATTACH. For example, calling it from ISPF exposes everything running in that ISPF session. TSO region size tends to be smaller than dubbed processes. Unix programs tend to consume lots of storage. Things like MALLOC do not abend and program's don't always check for success. Using & in scripts could leave forked processes running. I could come up with more
>
>Address space sharing has rules and it's been far too long for me to remember the specifics. Those rules could easily have changed since I last used it. BPXBATCH always ensured you worked in a safe environment without the need to understand those rules.
>
>> How does the exposure compare with BPX1SPN BPX_SHAREAS=MUST /bin/sh?
>
>It's been a long time. If I remember correctly, it has the exposure. What makes this acceptable is that you know there are risks but willing to accept those risks.
>
an ISPF macro invokes BPX1SPN BPX_SHAREAS=MUST /bin/sh,
only IBM code is involved and SoI applies. SoI has no "willing
to accept" loophole.
Is AOPBATCH an IBM product? If not, SoI applies if it's installed
only in non-authorized libraries.
COZBATCH is not an IBM product so SoI applies if it's installed
only in non-authorized libraries.
-- gil
Jon Perryman
Nov 3, 2019, 1:46:38 AM11/3/19
to
On Saturday, November 2, 2019, 07:35:08 PM PDT, Paul Gilmartin wrote:
>> Sorry. I forgot to say EXEC PGM=AOPBATCH is safe.
> That might be true if AOPBATCH were installed with AC=0 in an authorized library.
AOPBATCH and COZBATCH must be linked AC=0 because the shell runs in problem state.
>> Sorry. I forgot to say EXEC PGM=AOPBATCH is safe.
> That might be true if AOPBATCH were installed with AC=0 in an authorized library.
>>> How does the exposure compare with BPX1SPN BPX_SHAREAS=MUST /bin/sh?
>> It's been a long time. If I remember correctly, it has the exposure.
>> What makes this acceptable is that you know there are risks but willing to accept those risks.
> How does this interact with the z/OS Statement of Integrity?
, > If an ISPF macro invokes BPX1SPN BPX_SHAREAS=MUST /bin/sh,
> only IBM code is involved and SoI applies. SoI has no "willing
> to accept" loophole.
.I don't understand your point here. If your code (or macro) specifies shared address space, the exposure is your responsibility. You need to fully understand shared address space concept if you are going to use it.
> to accept" loophole.
> Is AOPBATCH an IBM product? If not, SoI applies if it's installed
> only in non-authorized libraries.
> COZBATCH is not an IBM product so SoI applies if it's installed
> only in non-authorized libraries.
Jon.
Seymour J Metz
Nov 3, 2019, 1:20:03 PM11/3/19
to
The Initiator attaches the jobstep with a few privileged options on the ATTACH. The new jobstep runs in the same address space but does not share job-related control blocks with the Initiator. SVC 99 uses a privileged option of ENQ to use the Initiators TCB for the queue head. The Initiator does not retain any key 8 storage.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000000433f0781...@LISTSERV.UA.EDU>
Sent: Saturday, November 2, 2019 3:38 PM
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000000433f0781...@LISTSERV.UA.EDU>
Sent: Saturday, November 2, 2019 3:38 PM
Gadi Ben-Avi
Dec 30, 2019, 2:33:35 AM12/30/19
to
Thanks
Is this a onetime setup, or would I have to do this twice a year?
Gadi
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin
Sent: Monday, December 30, 2019 9:28 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Chaning time zone for Unix based tasks
On Mon, 30 Dec 2019 07:09:19 +0000, Gadi Ben-Avi wrote:
>I know, bit that requires editing a file.
>I want something that can be done using automation.
>
A better approach, extracting information from Linux, which does it right:
503 $ tail -1 /usr/share/zoneinfo/Asia/Tel_Aviv
IST-2IDT,M3.4.4/26,M10.5.0
So:
TZ=IST-2IDT,M3.4.4/26,M10.5.0 export TZ
See: https://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html
Unfortunately, this must be set in several places.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Email secured by Check Point
Is this a onetime setup, or would I have to do this twice a year?
Gadi
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin
Sent: Monday, December 30, 2019 9:28 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Chaning time zone for Unix based tasks
On Mon, 30 Dec 2019 07:09:19 +0000, Gadi Ben-Avi wrote:
>I know, bit that requires editing a file.
>I want something that can be done using automation.
>
A better approach, extracting information from Linux, which does it right:
503 $ tail -1 /usr/share/zoneinfo/Asia/Tel_Aviv
IST-2IDT,M3.4.4/26,M10.5.0
So:
TZ=IST-2IDT,M3.4.4/26,M10.5.0 export TZ
See: https://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html
Unfortunately, this must be set in several places.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Giliad Wilf
Dec 30, 2019, 10:42:16 AM12/30/19
to
On Mon, 30 Dec 2019 14:47:35 +0000, Allan Staller <allan....@HCL.COM> wrote:
>One time setup.
>Is this a otetime setup, or would I have to do this twice a year?
>Gadi
>
>One time setup.
>
Yes, it flips automatically, Gadi.
Note the M3 and M10 in the expression, for March and October.
What does not flip automatically is the CLOCKxx's TIMEZONE parameter value.
A JES2 automatic command can be manually set, up to seven days in advance,
before the date, to do the flip "unattended", as it has to occur at 2am...
>One time setup.
>
>-----Original Message-----
>From: I M Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Gadi Ben-Avi
>Sent: Monday, December 30, 2019 1:33 AM
>To: IBM-...@LISTSERV.UA.EDU
>Subject: Re: Chaning time zone for Unix based tasks
>
>Thanks
>-----Original Message-----
>From: I M Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Gadi Ben-Avi
>Sent: Monday, December 30, 2019 1:33 AM
>To: IBM-...@LISTSERV.UA.EDU
>Subject: Re: Chaning time zone for Unix based tasks
>
>Is this a otetime setup, or would I have to do this twice a year?
>Gadi
>
>One time setup.
>
Yes, it flips automatically, Gadi.
Note the M3 and M10 in the expression, for March and October.
What does not flip automatically is the CLOCKxx's TIMEZONE parameter value.
A JES2 automatic command can be manually set, up to seven days in advance,
before the date, to do the flip "unattended", as it has to occur at 2am...
Kirk Wolf
Dec 30, 2019, 12:23:54 PM12/30/19
to
>
>
> Unfortunately, this must be set in several places.
>
> -- gil
>
>
> Depends on what you mean by "several". Might be dozens, hundreds, etc.
>
> Unfortunately, this must be set in several places.
>
> -- gil
>
>
The correct place to set TZ (as documented in the UNIX Planning book) is
/etc/init.options.
This will be picked up by any shells or programs (cron, etc) that are
started by the "init" process.
Unfortunately, this doesn't help much since z/OS UNIX is brain dead in this
regard, and the "init" process environment is not inherited by blind-dubbed
processes.
See this five year old RFE (where requirements go to die):
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=59716
Vote for it if you actually think that it will matter :-(
Paul Gilmartin
Dec 30, 2019, 1:26:45 PM12/30/19
to
On Mon, 30 Dec 2019 09:42:05 -0600, Giliad Wilf wrote:
>...
conceptual error. In fact the TZ environment variable is a parameter
to a function that takes as an argument a TOD (sort of) value from
any time in the past, present, or near future and returns the matching
local civil time as a result. If six months from now with the same TZ
in the environment, I use TOD argument I save today, it will return
the same local time it did today.
Nothing "changes."
>What does not flip automatically is the CLOCKxx's TIMEZONE parameter value.
>A JES2 automatic command can be manually set, up to seven days in advance,
>before the date, to do the flip "unattended", as it has to occur at 2am...
-- gil
>...
>Yes, it flips automatically, Gadi.
>
>Note the M3 and M10 in the expression, for March and October.
>
Imagining something that changes or "flips" semiannually is a
>
>Note the M3 and M10 in the expression, for March and October.
>
conceptual error. In fact the TZ environment variable is a parameter
to a function that takes as an argument a TOD (sort of) value from
any time in the past, present, or near future and returns the matching
local civil time as a result. If six months from now with the same TZ
in the environment, I use TOD argument I save today, it will return
the same local time it did today.
Nothing "changes."
>What does not flip automatically is the CLOCKxx's TIMEZONE parameter value.
>A JES2 automatic command can be manually set, up to seven days in advance,
>before the date, to do the flip "unattended", as it has to occur at 2am...
Paul Gilmartin
Dec 30, 2019, 1:53:13 PM12/30/19
to
On Mon, 30 Dec 2019 11:23:29 -0600, Kirk Wolf wrote:
> ...
There should be *one* point of control that governs both z/OS UNIX and
Classic MVS. Or at least a provision to omit specifying one to default to the
value of the other.
> ...
>The correct place to set TZ (as documented in the UNIX Planning book) is
>/etc/init.options.
> ... z/OS UNIX is brain dead in this
>/etc/init.options.
>regard, and the "init" process environment is not inherited by blind-dubbed
>processes.
>
>See this five year old RFE (where requirements go to die):
>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=59716
>
I read; I voted long ago. It doesn't matter. And it leaves a 100% surfeit.
>processes.
>
>See this five year old RFE (where requirements go to die):
>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=59716
>
There should be *one* point of control that governs both z/OS UNIX and
Classic MVS. Or at least a provision to omit specifying one to default to the
value of the other.
Kirk Wolf
Dec 30, 2019, 2:08:37 PM12/30/19
to
Gil,
I agree - maybe there should be a special setting for TZ (or another envar)
that will cause TZ to automatically follow the MVS time.
Maybe open another RFE? :-)
I agree - maybe there should be a special setting for TZ (or another envar)
that will cause TZ to automatically follow the MVS time.
Maybe open another RFE? :-)
Paul Gilmartin
Dec 30, 2019, 2:27:27 PM12/30/19
to
On Mon, 30 Dec 2019 13:08:12 -0600, Kirk Wolf wrote:
>
>... maybe there should be a special setting for TZ (or another envar)
the opposite way, setting MVS time from TZ. Consider that today
Colorado and Arizona have the same CVTLDTO, but:
711 $ tail -1 /usr/share/zoneinfo/America/Denver | tail -1
MST7MDT,M3.2.0,M11.1.0
712 $ tail -1 /usr/share/zoneinfo/America/Phoenix | tail -1
MST7
And those TZ values provide sufficient information to schedule
the (however misconceived) semiannual SET TIMEZONE.
>
>... maybe there should be a special setting for TZ (or another envar)
>that will cause TZ to automatically follow the MVS time.
>Maybe open another RFE? :-)
>
Wrong approach because of insufficient information. It must go
>Maybe open another RFE? :-)
>
the opposite way, setting MVS time from TZ. Consider that today
Colorado and Arizona have the same CVTLDTO, but:
711 $ tail -1 /usr/share/zoneinfo/America/Denver | tail -1
MST7MDT,M3.2.0,M11.1.0
712 $ tail -1 /usr/share/zoneinfo/America/Phoenix | tail -1
MST7
And those TZ values provide sufficient information to schedule
the (however misconceived) semiannual SET TIMEZONE.
Seymour J Metz
Dec 30, 2019, 3:19:43 PM12/30/19
to
From *which* time zone? You may have different processes running with different values for TZ.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000000433f0781...@LISTSERV.UA.EDU>
Sent: Monday, December 30, 2019 2:27 PM
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000000433f0781...@LISTSERV.UA.EDU>
Steve Smith
Dec 30, 2019, 6:42:49 PM12/30/19
to
It is impossible to please everyone all the time :-D. The only solution is
to use UTC everywhere for everything; except of course, that would please
almost no one who doesn't live in Iceland.
sas
On Mon, Dec 30, 2019 at 3:19 PM Seymour J Metz <sme...@gmu.edu> wrote:
> From *which* time zone? You may have different processes running with
> different values for TZ.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
to use UTC everywhere for everything; except of course, that would please
almost no one who doesn't live in Iceland.
sas
On Mon, Dec 30, 2019 at 3:19 PM Seymour J Metz <sme...@gmu.edu> wrote:
> From *which* time zone? You may have different processes running with
> different values for TZ.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
Gadi Ben-Avi
Dec 31, 2019, 12:52:05 AM12/31/19
to
I changed TZ to the value you suggested, and when I issue the time command I get UTC.
Gadi
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin
Gadi
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin
Sent: Monday, December 30, 2019 9:28 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Chaning time zone for Unix based tasks
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Chaning time zone for Unix based tasks
On Mon, 30 Dec 2019 07:09:19 +0000, Gadi Ben-Avi wrote:
>I know, bit that requires editing a file.
>I want something that can be done using automation.
>
A better approach, extracting information from Linux, which does it right:
503 $ tail -1 /usr/share/zoneinfo/Asia/Tel_Aviv
IST-2IDT,M3.4.4/26,M10.5.0
So:
TZ=IST-2IDT,M3.4.4/26,M10.5.0 export TZ
See: https://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html
>I know, bit that requires editing a file.
>I want something that can be done using automation.
>
A better approach, extracting information from Linux, which does it right:
503 $ tail -1 /usr/share/zoneinfo/Asia/Tel_Aviv
IST-2IDT,M3.4.4/26,M10.5.0
So:
TZ=IST-2IDT,M3.4.4/26,M10.5.0 export TZ
See: https://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html
Unfortunately, this must be set in several places.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Email secured by Check Point
Paul Gilmartin
Dec 31, 2019, 11:02:47 AM12/31/19
to
On 2019-12-30, at 22:51:40, Gadi Ben-Avi wrote:
>
> I changed TZ to the value you suggested, and when I issue the time command I get UTC.
>
"time"? Try "date" instead.
>
> I changed TZ to the value you suggested, and when I issue the time command I get UTC.
>
Troubleshooting:
o Run the commands in the attached TAtry.txt file (This is not a shell script.)
Paul Gilmartin
Dec 31, 2019, 9:23:44 PM12/31/19
to
On Tue, 31 Dec 2019 05:51:40 +0000, Gadi Ben-Avi wrote:
>I changed TZ to the value you suggested, and when I issue the time command I get UTC.
>
So the TZ mailing list gently scolded me for rehashing old news and mentioned:
>I changed TZ to the value you suggested, and when I issue the time command I get UTC.
>
http://austingroupbugs.net/view.php?id=1252
This proposal would address Austin Group issue 0000661 "grammar of TZ variable is insufficient for describing Israel Daylight-saving time", as TZ='IST-2IDT,M3.4.4/26,M10.5.0' represents current rules for Israel, with the '/26' exercising the proposed extension. It would also let POSIX TZ strings represent the current daylight-saving scheme for Godthab, via TZ='<-03>3<-02>,M3.5.0/-2,M10.5.0/-1' where the '/-2' and '/-1' exercise the proposed extension.
...
The two minor extensions are specified in Internet RFC 8536 section 3.3.1 "TZ String Extensions" <https://tools.ietf.org/html/rfc8536#page-13>, [^] and the proposed action is to add these to POSIX.
And in RFC 8536:
...
Example: <-03>3<-02>,M3.5.0/-2,M10.5.0/-1
This represents a time zone that observes daylight saving time
from 22:00 on the day before March's last Sunday until 23:00 on
the day before October's last Sunday. Standard time is 3 hours
west of UT and is abbreviated "-03"; daylight saving time is 2
hours west of UT and is abbreviated "-02".
So Israel needs only wait until POSIX assimilates RFC 8536 then z/OS
conforms to the updated POSIX.
RFE, anyone?
>-----Original Message-----
>From: Paul Gilmartin
>Sent: Monday, December 30, 2019 9:28 AM
> ...
>A better approach, extracting information from Linux, which does it right:
>
> 503 $ tail -1 /usr/share/zoneinfo/Asia/Tel_Aviv
> IST-2IDT,M3.4.4/26,M10.5.0
Gadi Ben-Avi
Jan 1, 2020, 12:53:48 AM1/1/20
to
This is the result:
# cat TZlog.txt
Script command is started on Wed Jan 1 05:50:11 2020.
# date
Wed Jan 1 05:50:29 2020
# export -p | grep TZ
export TZ="IST-2IDT,M3.4.4/26,M10.5.0"
# echo "$0 $SHELL"
/bin/sh /bin/sh
# exit
Script command is complete on Wed Jan 1 05:51:14 2020.
#
I am using z/OS v2.3
Gadi
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin
Sent: Tuesday, December 31, 2019 6:02 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Chaning time zone for Unix based tasks
# cat TZlog.txt
Script command is started on Wed Jan 1 05:50:11 2020.
# date
Wed Jan 1 05:50:29 2020
# export -p | grep TZ
export TZ="IST-2IDT,M3.4.4/26,M10.5.0"
# echo "$0 $SHELL"
/bin/sh /bin/sh
# exit
Script command is complete on Wed Jan 1 05:51:14 2020.
#
I am using z/OS v2.3
Gadi
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin
Sent: Tuesday, December 31, 2019 6:02 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Chaning time zone for Unix based tasks
Email secured by Check Point
Paul Gilmartin
Jan 2, 2020, 1:38:32 PM1/2/20
to
On Mon, 30 Dec 2019 11:23:29 -0600, Kirk Wolf wrote:
>See this five year old RFE (where requirements go to die):
>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=59716
>
A couple further thoughts (it's probably discourteous to amend an RFE ex post facto):
>See this five year old RFE (where requirements go to die):
>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=59716
>
POSIX says: https://pubs.opengroup.org/onlinepubs/9699919799/functions/tzset.html#tag_16_629_03
DESCRIPTION ... If TZ is absent from the environment, implementation-defined
default timezone information shall be used..
It might be less disruptive to blind-dubbed processes not to set TZ but to
use "implementation-defined default timezone information". A couple OSes
I know do this as follows:
528 $ uname -a; ls -l /etc/localtime
Darwin PaulGilm.wifi.belezacoffeebar.com 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
lrwxr-xr-x 1 root wheel 40 Nov 23 11:46 /etc/localtime -> /var/db/timezone/zoneinfo/America/Denver
1064 $ uname -a; ls -l /etc/localtime
Linux Bunsen5-PG 4.9.0-11-686-pae #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) i686 GNU/Linux
lrwxrwxrwx 1 root root 34 Sep 18 18:35 /etc/localtime -> /usr/share/zoneinfo/America/Denver
z/OS might just use the value in BPXPRMxx but not set TZ.
And: https://tools.ietf.org/html/rfc8536#section-3.3
3.3. TZif Footer
The TZif footer is structured as follows (the lengths of multi-octet
fields are shown in parentheses):
+---+--------------------+---+
| NL| TZ string (0...) |NL |
+---+--------------------+---+
TZif Footer
The elements of the footer are defined as follows:
TZ string: ... e as defined in Section 8.3 of the "Base
Definitions" volume of [POSIX] with ASCII encoding
Elsewhere I found suggestions that an implementation might rely only
on the TZif Footer (with reduced function) to avoid greater code
changes or performance impacts, or install only the footers to save
storage.
-- gil
0 new messages