Nora, Is there ever a case where the command (EXEC, or whatever) fails when it is NOT run in a VMBATCH worker?
If they never fail outside of VMBATCH workers, John probably has a good handle on the diagnosis. You may have to read a little bit more in the VMBATCH documentation about how VMBATCH workers get initialized, end, and especially: how the post-job "cleanup" process works. It might be as simple as changing the program to release the SFS directory before ending (and perhaps examining the connection and looping until it has been cleared). BTW, the other common VMBATCH product is from CA, called VM:Batch. Many moons ago there were other publically available freeware VMBATCH solutions, too -- IIRC, from colleges. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. "Graves Nora E" <nora.e.gra...@irs.gov> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 04/20/2011 09:17 AM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: SFS problem I do not believe that this is the problem. I was giving you information on the failing job that I am most familiar with. Other jobs that fail are submitted to VMBatch by the ID that also owns the SFS directories. FYI, "VMBatch" is the IBM VM Batch Facility Version 2.2, I was not aware until recently that there are other products also known as "VMBatch". If this has caused confusion, I apologize. Nora Graves nora.e.gra...@irs.gov Main IRS, Room 6531 (202) 622-6735 Fax (202) 622-3123 SE:W:CAR:MP:D:KS:BRSI From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of John Hall Sent: Wednesday, April 20, 2011 10:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem If I recall correctly, DIAG D4 is the one that manipulates the secondary ID, aka "Alternate ID". (SECUSER is an old term). Diag 88 provides the ability to link minidisks and perform userid/password validations (if the issuer has appropriate authority). An interesting usage note for this is that DIAG D4 does not change the userid associated with any existing (already active) SFS connections. This is because it is a CP function and manipulates the VMDBK. Once set, future connections (via APPC/VM Connect) will utilize the Alternate ID. ... This is why severing all connections prior to setting the AltID will "fix" this type of problem, because CMS will (re) connect and use the AltID. If this is Nora's problem, an easy work around would be wrap the job with an exec that uses DMSGETWU and DMSPUSWU to set a new default work unit that contains the appropriate user, then run the job from the exec, then finally reset with DMSPOPWU. (If I'm remembering all of this correctly) John -- John Hall Safe Software, Inc. 727-608-8799 johnh...@safesoftware.com On Tue, Apr 19, 2011 at 11:48 AM, Schuh, Richard <rsc...@visa.com> wrote: Isn't that DIAG 88, instead of SECUSER? Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of John Hall Sent: Tuesday, April 19, 2011 6:41 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem Nora, Batch jobs normally run with the privileges of the "owner" of the job, using the SECUSER facility in z/VM. With SFS, this can lead to unexpected results when a prior batch job leaves the worker with a connection to the filepool under a different user's id. If the job ordering/selection of batch workers is somewhat random, you could see the outcome that you're experiencing (sometimes it works, sometimes it fails). The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
