RE: Web services behavior -- RPG400-L

"Based on my experience, running in the default activation group does not seem to be the horror show people think it is."

Absolutely!!!!

I have to work under a "thou shalt not use named activation groups" policy, and I get along just fine with my ILE.

-----Original Message-----
From: Lynne Noll [mailto:lvwnoll@xxxxxxxxxxx]
Sent: Sunday, February 25, 2018 9:19 AM
To: RPG programming on the IBM i (AS/400 and iSeries) <rpg400-l@xxxxxxxxxxxx>
Subject: Re: Web services behavior

No, that is just my bad memory. I've never remembered it correctly. I just WRKOBJ QR* when I need to find it.

This won't help with triggers. I never set on LR with triggers, which does make them hard to replace, but when I set on LR, performance was dreadful. (1998 was the last time I tried it, though).

Named activation group is fine except for the scope of overrides. I've had issues with overrides with legacy code overrides and service programs, although not especially with triggers. When I want to take an OPM program to ILE, I always have to check the way its environment uses overrides.

Based on my experience, running in the default activation group does not seem to be the horror show people think it is. The main issue occurs if you have service programs and run RCLRSC, things break, since you close the files and the service program still thinks they are open. If you don't use RCLRSC, the service program works fine (or at least it worked at V4R1M0, last time I saw this.) It can have advantages for scope of overrides from programs running in the default activation group. But for a trigger, it would be hard to make sure that no software uses RCLRSC.

Now if the top program runs in *NEW, you can also have issues with overrides if any of the overrides it issues repoint a table that the trigger is supposed to access, but only if the table in the trigger would need to pick up the override. *CALLER avoids this.

Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxx> on behalf of Craig Richards <craig@xxxxxxxxxxxxxxxx>
Sent: Sunday, February 25, 2018 9:17 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Web services behavior

Hi Lynne,

It's good to hear someone else running things the same way as we are ( named activation group and setting on LR )

We still have some wrinkles to iron out but I think that is because our transactions then run SQL to access a remote database on another LPAR.
That means that we end up using the prestart jobs QRWTSRVR ( DRDA/DDM Servers ) and the main file being accessed has a trigger on it.

The trigger program is setting on *INLR but is running in a named activation group because I didn't want the overhead of a *NEW activation group but I also didn't want to use *CALLER and have this ILE program potentially running in the Default Activation Group.
I understand that in a lot of cases trigger should use *CALLER so that they can be included in an appropriate commit transaction, but there is only a single record being inserted in our case.

Anyway, at the moment if we change the trigger programs we get that old
SQL0818 Consistency tokens do not match errror unless we restart the webserver.

PS did you mean QRPLOBJ?
Or is QRPLIBL something I don't know about ( yet )

best regards,
Craig

On 25 February 2018 at 14:04, Lynne Noll <lvwnoll@xxxxxxxxxxx> wrote:

I run about 150 external stored procedures that are accessed by .net
web services. Most are programs rather than service programs, and
since they run whole functions that complete themselves, they do set
on LR. All run in a named activation group.

I'm not going to talk about speed, since my site is slow (analysis
says this is due to excessive resizing images in our repository rather
than service calls) but persistence.

If I install a new version of the procedure,the web site will run the
old one out of QRPLIBL.

HOWEVER, if I recreate the procedure (run an SQL script that drops it
and recreates the sql procedure), the site will pick up the new version.
Evidently, this signals something to the server job.

I don't know what will happen with service programs rather than
programs, but this works for me, and has become a normal part of
installing a new version, even when the interface doesn't change.

Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxx> on behalf of Craig
Richards <craig@xxxxxxxxxxxxxxxx>
Sent: Saturday, February 24, 2018 9:14 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Web services behavior

Sorry Basilio I mis-spelled your name

On Sat, 24 Feb 2018 at 10:49, Craig Richards <craig@xxxxxxxxxxxxxxxx>
wrote:

Hi Basilo,

I'm not any kind of expert in this area but I have seen similar
issues recently.

In our environment at least, when a client connects to the web
service , what I see on the IBMi is that a job running with user
QTMHHTP will

start a

new thread running with user QTMHHTP1 and that thread seems to
remain active until the web server is restarted.

If you have recompiled the program, it could either be destroyed now
or running out of QRPLOBJ depending on how you recreated it.

Also it depends on what Activation group it is running in as to what
happens next time you call it.
If it is running in Activation Group *NEW then you shouldn't have a
problem with any old version running but it is expensive to start a
new activation group each time.
It if is running in a named activation group, then you may have
resources open until you RCLACTGRP even if the program sets on *INLR.
Or is it running in the default activation group or *CALLER?

It's probably a good idea to restart the web server when you
recompile

the

code if that is practical to do in your situation.

But that's just my opinion based on my small experience in this area.

If you want to see the program running there are a few ways you can
do

it:

One way is to use RDi if you have it and set a SEP for the program
and User QTMHHTP1.

Another, if the program is running in a named activation group and
you

are

using SQL, once it has run the SQL more than one time it will
probably leave what looks like a shared lock on the tables it uses (
though it's

not

quite the same thing ) and if that is the case you might be able to
find the job by looking for object locks on a table it accesses via
SQL -

again

this will only be the case if it has run the SQL more than one time.

best regards,
Craig

On 24 February 2018 at 10:06, Merlino, Basilio <

b.merlino-nisext@xxxxxxxxx

wrote:

Dear All
Let's me describe the following scenario.
Program A is called by a web service request Program A in one point
call a second program "B"
Program "B" have 2 file under journal and write on it On Tuesday I
have recompile pgm B without end the apache server and I

was

wondering to discover (on Wednesday) that all the transactions was
not written on the file defined in program "B"
Initially I was thinking a bug on the program but neither Wednesday
and the day after I faced the problem I didn't find any kind of log
so my question is this behavior is

correct?

It's seem that the ws "lost" the program. It's mandatory to close
and restart the server Why as happen in a normal case new object is
not use?
Thanks to all for your answers
Basilio

************************************************************

***********************************************

CONFIDENTIALITY NOTICE

This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information.

If you receive this message in error, please immediately delete it
and all copies of it from your system, destroy any hard copies of
it and

notify

us by email to email.security@xxxxxxxxxxxxxxxxx with a copy of this
message. You must not, directly or indirectly, use, disclose,

distribute,

print or copy any part of this message if you are not the intended
recipient. NISSAN EUROPE and any of its subsidiaries each reserves
the right to monitor all e-mail communications through its networks.

NISSAN EUROPE is neither liable for the proper, complete
transmission of the information contained in this communication nor
any delay in its receipt. This email was scanned for the presence
of computer viruses. In the unfortunate event of infection NISSAN
EUROPE does not accept

liability.

Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is
authorised

to

state them.

************************************************************

***********************************************

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: http://amzn.to/2dEadiD

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD