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