On 11/29/2017 5:34 PM, Nathan Andelin wrote:
On Wed, Nov 29, 2017 at 3:10 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
No. Our volumes are too low to set up a separate subsystem (memory
pool, etc) for this subset of the workload.
If I understand correctly, you're saying that QZDASOINIT Jobs automatically
adopt the Job Description (including library list) that is defined in the
User Profile, when a connection is established via that User Profile?
I don't know exactly what goes on under the covers, but when I fire up a
process that uses a prestarted QZDASOINIT job, I can see my library
list, and not the library list of QUSER.
That seems counter-intuitive to me for prestart Jobs, in that they are
already running. I do understand that IBM could put logic in the program to
change its library list to that of the currently connected user profile.
That's what Dave Clark is doing. You appear to be saying that's already
provided by IBM.
It might be that my setup is special and in the mists of time I've
forgotten how to set it up.
CRTLIB LIB(MIDRANGE) TYPE(*TEST) TEXT('Example for midrange.com')
CRTJOBD JOBD(QGPL/MIDRANGE) TEXT('Example for midrange.com')
INLLIBL(QGPL QTEMP MIDRANGE)
CRTUSRPRF USRPRF(MIDRANGE) TEXT('Example for midrange.com')
JOBD(QGPL/MIDRANGE)
Start ACS SQL Scripts
Sign on as MIDRANGE.
cl: dsplibl output(*print);
In a green screen wrksplf midrange. Look at the spooled file; what's
the library list look like for you?
wrkactjob sbs(qusrwrk) and find the job for user MIDRANGE. What is the
current user profile? Library list? In my case, the particular PJ
started at 0100 this morning: many hours before I created this *LIB,
*JOBD, and *USRPRF. Clearly, my machine made changes when I 'attached'
to the PJ with ACS scripts. There are messages in my job log indicating
the changes, and the program making them belongs to IBM.
I finally found what looks like a good reference:
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzajr/rzajrmst28.htm
Step 4 seems to be the secret sauce.
'Client/Server communication is established in the following steps:
1 To initiate a server job that uses sockets communications support,
the client system connects to a particular server's port number.
2 A server daemon must be started (with the STRHOSTSVR command) to
listen for and accept the client's connection request. Upon accepting
the connection request, the server daemon issues an internal request to
attach the client's connection to a server job.
3 This server job may be a prestarted job or, if prestart jobs are
not used, a batch job that is submitted when the client connection
request is processed. The server job handles any further communications
with the client. The initial data exchange includes a request that
identifies authentication tokens that are associated with the client
user. A user profile and password, or a Kerberos ticket, are examples of
these tokens.
4 Once the authentication tokens are validated, the server job
switches to use the IBM i user profile associated with those tokens, and
changes the job by using many of the attributes defined for the user
profile, such as accounting code and output queue.'
The path to that is...:
Connecting to your system
IBM i Access
IBM i Access Client Solutions
Setting up the IBM i platform
Host server administration
Use IBM i host servers
midrange.com
