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
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!
Reminds me of a lawyer defending a hopeless case!
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.
To paraphrase; BPXBATCH sucks!
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"?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
