That is weird! It "sort of" makes sense. I wonder why the binder creates the UNIX file output in this case. With NOSTORENX, it doesn't update the PDS directory. If it were me, I'd have the binder unlink() the output file. Actually, I would have the binder write to a temporary file in the proper directory and either unlink() it, if the link "failed"; otherwise do a rename() to the proper name on success, which will replace the existing file if it exists. In addition, I would have the binder create the output file as non-executable and only do a chmod() on it if the RC was 0 or 4. Lack on planning on the binder's architect, IMO.
I wonder if this could be sent as a bug to the Binder support people? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 • N. Richland Hills • TX 76010 (817) 255-3225 phone • [email protected] • www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Paul Gilmartin > Sent: Wednesday, September 26, 2012 3:18 PM > To: [email protected] > Subject: IEWPLMH (was: GIM44336S) > > On Wed, 26 Sep 2012 12:01:28 -0500, McKown, John > <[email protected]> wrote: > > >Just to save me time creating and testing, what happens in that case? > I know that, in batch, when linking into a PDS[E], I use the NOSTORENX > so that the new program is not put/updated in the library. I don't > really see any reason to allow a non-executable module to be placed in > the library. But I run in a simplistic shop, too. IIRC, if you tried to > run such a problem in batch, fetch would cause an abend. > > > exec() correctly detects that Binder has marked it nonexecutable and > reports this in errno to shell. Then, compulsively following POSIX > rules, shell attempts to execute it as a script. Since any program > object, executable or not, begins with CL8'IEWPLMH ', you don't > need to create a test, the following happens: > > 136$ sh /bin/true > IEWPLMH: /bin/true 22: FSUM7351 not found > > Shell stumbles along, reporting additional errors. We can only > hope that it doesn't encounter "rm -rf /" somewhere along the > way. > > Next, the user attempts to find IEWPLMH in Messages and Codes, > and failing that contacts either local help desk or IBM support, > sometimes asking for help on MVS-OE. I reported this to IBM > in a PMR. WAD. Bad design? Just obeying POSIX. They could > do better, perhaps with a redefinition of "nonexecutable". > > I have an IEWPLMH exec in my PATH that issues an error > message then attempts to kill SIGKILL its parent. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
