Actually, SECUSER still exists and is something quite different. SECUSER defines a secondary user for receiving console messages and entering commands and responses. The entries are done as though they came from, not on behalf of, the user.
Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of John Hall Sent: Wednesday, April 20, 2011 7: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<tel:727-608-8799> johnh...@safesoftware.com<mailto:johnh...@safesoftware.com> On Tue, Apr 19, 2011 at 11:48 AM, Schuh, Richard <rsc...@visa.com<mailto: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<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of John Hall Sent: Tuesday, April 19, 2011 6:41 AM To: IBMVM@LISTSERV.UARK.EDU<mailto: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).
