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

I don't have an example handy but the topic has been discussed on the RPG400 list previously. Basically when you place a new program in the N library (or if you use the normal QREPLOBJ method when you simply compile a new version) you need to have your compile process set a flag somewhere (data area or user space normally) that says a new program is in play. This is checked each and every time the dummy program is called - it decides if the pointer to the program needs to be re-resolved and takes appropriate action as described below.

The reason the dummy program is needed (and yes it gets called from the script alias) is that RPG has log that ensures that the pointer to the program being called is resolved as few times as possible so:

A) If a program is called via a literal the pointer is resolved once and once only.

B) If a program is called via a variable then it is resolved once and the program name is stored and before each subsequent call the requested name is compared with the stored version. If there is no change then the existing pointer is used. If there is a change then the new name is resolved and its pointer used. Since you actually _want_ the original name you have to fake the compiler out by calling once to a different program and then switching the name back and calling again. Since the name has changed on the second call the pointer will be resolved to the new object. This should work regardless of whether you use the usual approach of simply replacing the program in the production library or by using a special library as you do.

Re you questions:

1) As to AGs - the program will run wherever its AG attribute says. If you compiled the RPG program with all the defaults it would be QILE. You could also have specified any named AG or *CALLER. As I noted before *NEW would also work but create a performance overhead.

2) Does the program ever get purged? Other than if you use *New - no it doesn't until the job ends.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Oct 8, 2018, at 2:49 PM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx> wrote:

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.

--
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.

--
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.