When you CD to an SFS directory, the FTP server obtains a workunit (DMSGETWU). Then, with each subsequent FTP operation you perform, it pushes your workunit onto the stack via DMSPUSWU, does what you ask, then pops it back off with DMSPOPWU.
Some things it does via command and some things it does via CSL routine. The CSL routines are always provided the workunit id. The FTP server does not do any authorization checking. The SFS server does that based on the ID associated with the workunit. In any case, if you're going to depend on the alternate userid, you have to set it before you do ANY SFS functions. If QUERY IUCV shows you already have a connection to the SFS server, you need to purge the workunits or re-IPL CMS. If you use the admin workunit functions of SFS, you can avoid worrying about when, exactly, and APPC connection is established. (APPC is an IUCV-like connection, but it has different semantics.) Alan Alan Altmark IBM Senior z/VM Engineer and Consultant 1 607 321 7556 (Mobile) alan_altm...@us.ibm.com > -----Original Message----- > From: CMSTSO Pipelines Discussion List <CMS-PIPELINES@VM.MARIST.EDU> > On Behalf Of Rob van der Heij > Sent: Thursday, December 14, 2023 4:30 AM > To: CMS-PIPELINES@VM.MARIST.EDU > Subject: [EXTERNAL] Re: [CMS-PIPELINES] >SFS ERROR 1180 > > On Thu, 14 Dec 2023 at 08:45, Kris Buelens <kris.buel...@gmail.com> wrote: > > > I have some relatively vague memories that someone with SFS admin > > rights could connect to SFS using different authorities concurrently. > > Thinking a bit deeper: the FTP server uses this during an FTP PUT or > > GET with SFS. I don't think it uses Diag D4 to start talking to SFS. > > > > Correct. You must enroll FTPSERVE as ADMIN to FTP to SFS directories. I > believe it's just restraining itself and checking SFS grants to restrict the > user. > > Rob
