Thanks for the idea Matt but I thought the Apache job would use the job
description assigned to the subsystem not the user the job runs under.
Our Apache jobs in QHTTPSRV show a jobd of QZHBHTTP but the user
QTMHHTTP has jobd QDFTJOBD in the profile. Isn't the users job
description only used when the user signons to a 5250 session or submits
a job?
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [
mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Matt.Haas@xxxxxxxxxxx
Sent: Thursday, June 07, 2007 11:07 AM
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Library list control and net.data and RPG CGI apps
Mike,
Another option is to have multiple instances (or virtual hosts in the
same instance) of Apache. You can specify the user name that CGI jobs
run under for each instance/virtual host. The default is QTMHHTP1. If
you copy this profile, you can set up a different library list for each
copy with the library list you need for each environment.
Matt
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [
mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Mike Cunningham
Sent: Thursday, June 07, 2007 11:00 AM
To: Web Enabling the AS400 / iSeries
Subject: [WEB400] Library list control and net.data and RPG CGI apps
For those of you who are using net.data and/or RPG CGI how do you
control the library lists the Apache jobs have from a perspective of
production vs development apps? So far we have used the ADDLIBLE command
in the CGI app to be sure the correct libraries are in the list. This
technique is not the best as a production user could run an app that
adds PRODUCTION to the library list and then the same apache job could
run a development app that adds DEVELOPMENT to the library list. The
production user then submits a request and DEVELOPMENT is at the top of
the list and that apps calls/opens objects in DEVELOPMENT.
I know we need to change how we do this, just looking for the best
option.
One person here thinks the best option is to be sure that the first
thing all net.data or CGI apps do is the ADDLIBLE and then before ending
do a RMVLIBLE for any libraries added. That would work until one of
these apps failed and never did the RMVLIBLE.
Another idea was to use CHGLIBL at the start of each app to set the list
to what that job needs. Could be a maintenance issue if that library
lists needs changed.
The first two both have the problem of someone moving an app from
development to production and forgetting to change the *LIBLE commands
to the right values.
Third idea was to replicate the base IBM QHTTPSRV subsystem under a new
name and setup the JOBD in the base IBM subsystem to use production and
the replicated one to use development.
Forth idea was to still have one subsystem and create new instances with
one listening on 80/443 that would use production and the second
listening on 81/444 and use development but since both these instances
would use the same JOBD they would have the same initial library list so
we are not even sure of this would fix the problem.
Then ran across these other alternate suggestions...
http://209.85.165.104/search?q=cache:CzyDHudipZYJ:www.mcpressonline.com/
mc%3F128%40%40.6aea2555!SearchMark%3D.6aea2555+RPG+CGI+LIBRARY+LISTS&hl=
en&strip=1
Has anyone found the best-of-breed technique for dealing with this
issue?
midrange.com
