|
> From: David Gibbs > > 1. Program starts, user profile is QTMHHTTP > 2. Retrieve current user from the PSDS and save it. > 3. Switch to the user profile identified in the REMOTE_USER environment > variable. > 4. Do work > 5. Switch back to the saved user profile (QTMHHTTP) A couple of points. First, I thought the idea was to: 1. Get a handle to the current profile and save it 2. Get a handle to the desired profile 3. Switch to the desired profile 4. Do work 5. Switch back to the current profile 6. Release both handles This does a number of things, but most importantly it doesn't require you to even know what profile you're initially running under. Perhaps this will work better in your case. Also, there are a limited number of available handles, so releasing all the ones you create is important. Second, this is a good example of why I prefer batch jobs. Whenever a session starts up, you could submit a batch job and communicate with it via data queues or whatever. Your CGI program is very simple, just doing sends and receives. You have full control over the batch job, including subsystem and job attributes. It runs under the correct user profile, and everything, including auditing and trigger programs, all run correctly. You have full control over everything from activation groups to authorities. I know there's overhead in the data queue connection. But it's not much; just memory to memory. And you only submit the batch job once when the session starts. Joe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.