On Tuesday, October 29, 2019, 01:45:18 PM PDT, Paul Gilmartin <0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
