Re: HTTP instance - apache configuration/directive quesiton - updated program deployment

Jon,

For clarity, and do you have any examples you could point me to.

I follow your use of the dummy program.
The dummy program would the one defined HTTP directive script alias, (this basically would never change, correct)

I'm not clear on why you need to change name/lib.
We're using library lists, via a jobd.
The purpose of the N library is that they system will always look there first for the program, if not there, defaults back to base library.
So why would there need to be code to changing/hardcoding the call?

The other issues possibly could be:

1) Hhow the RPGLE program is called and which activation group is used.
My question here is?
When an RPGLE program is called from an HTTP instance, which catorgy/activation group is used?
https://www.itjungle.com/2004/02/11/what-you-should-know-about-activation-groups/

2) Does the RPGLE program ever get purged if the HTTP instance (job from where it was called) is always active and running?

Paul

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Monday, October 08, 2018 11:28 AM
To: Web400@Midrange. Web400
Subject: Re: [WEB400] HTTP instance - apache configuration/directive quesiton - updated program deployment

I would say that the option you describe as #2 would be the norm. Your method of having a completely different library seems a little odd and I can't think of any real advantage to doing it that way rather than a straight replacement.

This is not really an HTTP problem as it would apply with any long running NEP type scenario. The main problem is that you have to come up with a mechanism to have the server job re-resolve the program when needed. There have been several solutions proposed on these lists to deal with this but in essence they all come down to the same thing.

The program that is _calling_ the one subject to replacement needs to be using a variable (name and lib) for the program being called - not a straight call with LIBL control. It must then check some kind of flag (data area, user space, whatever) to see if a re-resolve is needed. If it is then it must first change the name/lib being used and do a call. In your case I guess this could be to the N library. Normally it is to a dummy do-nothing program that simply returns. The caller then changes the call target variable back to the correct nam/lib and calls again. This second call will force re-resolution of the program pointer.

Another alternative that works with regular program replacement is to use a *New AG - but that is expensive CPU wise.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Oct 8, 2018, at 10:44 AM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx> wrote:

We have several HTTP instances calling various RPGLE pgms AAA from library BBB via ScriptAlias, see below.
ScriptAlias /ptm /qsys.lib/bbb.lib/aaa.pgm.

We use a “NEW” or “N” library to install changes for our applications.
BBBN is included in all jobd/library lists for the applications.

We have an updated version of program AAA that is installed in library BBBN.
The problem is that the HTTP instance does not see the new program in library BBBN.

After much research, and PMR with IBM, There is no method to reference a program in a different library, BBBN.

ScriptAlias points to a specific library/directory/program... It does not function to pick up objects from multiple locations like a library list.
You either need a new script alias or to overlay the original program (as specified in the script alias)
​There is no other directive which would allow you to pick up programs from multiple locations.

Solutions given, but not preferred,
1) Reconfigure the HTTP instance ScriptAlias - ScriptAlias /ptm /qsys.lib/bbbn.lib/aaa.pgm
2) Replace the aaa program with the new version aaa program, NOT using the bbbn library.

How are others in the group handling HTTP instance configurations when a new program has to be deployed, to a n library.

Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx<mailto:psteinmetz@xxxxxxxxxx>
http://www.pencor.com/

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.