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). > >
