Re: Web services behavior -- RPG400-L

I started down the route of leaving LR off for the triggers, but if you
have the possibility of the trigger programs being fired remotely - e.g
your webservice is running SQL after connecting to a remote database, or
you are using an SQL client like Squirrel or whatever, then you will find
your trigger running in the Prestart Jobs in QUSRWRK:

QRWTSRVR - DRDA/DDM ( I get these jobs if I used CONNECT in SQLRPGLE to
access a remote database )
QZDASOINIT - Database host Server ( I get these jobs if I connect from a PC
Client.

Those Prestart jobs hang around in QUSRWRK and get re-used so leaving *INLR
off in a trigger program in them seems like a bad idea, and I could
probably devise a way to eventually tell the trigger program to set on LR
but it would likely be a bit obscure and dodgy to do.

Mostly where I've worked, file overrides in ILE were always scoped to the
job to keep things simple.

People seem to have an inherit mistrust of overrides and if I'm just in RPG
I do like the simplicity of qualified file opens if I can get away with it.
But generally I've found that if I specify SECURE(*YES) and make sure my
code is adding/removing the override correctly ( special care needed if you
have monitor blocks or code which could kick out of the program early )
then you don't run into problems.

I'm not enjoying have to use these Prestart Jobs though. I like to be in
control of things.
I'd much prefer to be able to leave LR off, run some one-time
initialisation and then a proper closedown at the end but I can't see how
that can be implemented at all in my current project with one LPAR running
just a webserver and accessing the production database on another LPAR via
remote SQL.

That said, our testing has shown that even with the webserver LPAR
connecting and disconnecting every time, the trigger on the remote machine
setting on LR every time ( though running in a named activation group )
thatt part of the IBMi still performs amazingly well, and in fact the bulk
of the transaction time is being caused by HTTPS.

Life used to be simpler...

On 25 February 2018 at 15:19, Lynne Noll <lvwnoll@xxxxxxxxxxx> wrote:

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