If the webserver does not depend on accessed SFS directories you could also
consider using DMSPURWU to break all connections with SFS before you issue
Diag D4, then >SFS will connect with the alternate userid, and after Diag
D4 reset, issue DMSPURWU again.
I'll send you my SFSDISC EXEC
Kris Buelens,
--- VM/VSE consultant, Belgium ---
-----------------------------------------------------------------------
Op do 14 dec 2023 om 15:40 schreef Donald Russell <[email protected]>:
> Is making the web servers sfs admins the correct solution? I can do that
> and “query auth” to limit access as needed.
>
> The application will still use diag d4 to influence cp link and the spool
> orig id when it sends files tother users. (This application links to other
> mdisks and I need that to be based on the user who logged into the web
> server, and it sends files to other users. I want those to show they came
> from the user that logged in instead of the web server itself.
>
> That part all works fine, just the sfs part was causing me a bit of grief.
> Now I have a solution.
>
> Thank you.
>
> On Thu, Dec 14, 2023 at 01:30 Rob van der Heij <[email protected]> wrote:
>
> > On Thu, 14 Dec 2023 at 08:45, Kris Buelens <[email protected]>
> 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
> >
>
