On 5/19/06, Westlund, Mats (Mainframe servers) <[EMAIL PROTECTED]> wrote:
SFS do not check the alternate user so the suggested method to create a lock for a file to see what altuser is running do not work if the worker it selves use any sfs files. When the worker first access a filepool the appc connection is assigned the userid/altuserid that the worker has in that moment and that userid is kept in the sfs filepool as long as the appc connection exists so even if the worker is assigned a new altuser the connection to sfs still uses the old (firs) userid. To get the "right" userid the worker has to reset the appc connection to the filepool before accessing files for the new user. This is a problem when developing worker applications using sfs, the worker it selves can't use files in sfs and the order of setting up appc connections to sfs is very important.
This is correct. Often a brute force method is employed when setting up a worker for a transaction set via DMSPURWU. In fact, if the worker is not "trusted", you are forced to do this during worker setup, to ensure that there are no lingering authorizations available from a previous transaction. If your worker and/or server is "trusted", you can use the CSL API to create workunits that specify the altuser and then use that workunit on CSL calls for work for that altuser. If your application is single threaded, you can also change the "default workunit" which will affect all subsequent interactions with SFS. A single-threaded application (that may or may not be multi-client, but serves clients in a serial fashion) can simply obtain a workunit (DMSGETWU), make it the default (DMSPUSWU), perform whatever work it requires, return to the previous work unit (DMSPOPWU), and discard the workunit (DMSRETWU). A multi-threaded application that wishes to use the altuser facility with SFS must limit itself to the CSL set, specifying a workunit as applicable. This allows a worker/server to perform work on behalf of one or more users (via altuser) at the same time. Additionally, one might serialize access to certain CMS functions, so that you can use the "default workunit" (DMSPUSWU/DMSPOPWU) so as to issue traditional CMS commands. For example, you might create a critical section (serial access by all threads) to the ERASE command that issues the series DMSPUSWU, ERASE, DMSPOPWU so that the ERASE runs with the authority and auditing of the altuser associated with the given workunit (poor example, b/c you could just use DMSERASE, but the example holds true). John -- John Hall (+1) 727-397-6373 Safe Software, Inc. JohnHall (at) SafeSoftware.Com http://www.SafeSoftware.Com JohnBeachFL (at) gmail.com
