On Thu, 14 Dec 2023 at 08:45, Kris Buelens 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 use
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 ba
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 Buelen
In our case the web server does depend on SFS. The entire document tree is
sfs as well as the web server code itself.
The >SFS stage accepts a work unit number…. So I looked at DMSGETWU. It
clearly states the issuing id must be an SFS administrator to specify the
userid to act as.
S, I’m goi
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
Thanks Alan,
I solved it this way… made the web server id an admin of the sfs pool,
DMSGETWU, use other CSL routines to check the user auth, pass the work
unit number to >SFS and finally DMSRETWU when I’m done.
If I don’t do my own auth checking I assume >SFS stage will get an error.
But the err
