Re: MCH3402 received when calling getHtmlIfsMult -- RPG400-L

For future reference...
https://authory.com/JonParisAndSusanGantner/The-Seven-Deadly-Sins-of-ILE

Fifth deadly sin: Failing to use RCLACTGRP only when necessary and using
RCLACTGRP(*ELIGIBLE) in production code.
RCLACTGRP(*ELIGIBLE) is very useful to the programmer - but it's lethal in
production. Here's a hint as to how concerned the IBM developers are that
you should use this option with great care: Issue the RCLACTGRP command and
prompt it (F4). Most special values for parameters appear on the prompt
screens. Do you see *ELIGIBLE? Don't strain your eyes; it isn't there! Only
by pressing F1 can you confirm that the option exists. This isn't an
accident. IBM probably would've done away with the option had it realized
how much trouble it would cause. As it is, IBM has buried it as best it
could.

So to correct myself, *ELIGILBLE is in the help, but isn't on the prompt
screen like most special values.

Also for reference...
https://archive.midrange.com/rpg400-l/200409/msg00220.html

CWilt@xxxxxxxxxxxx wrote:

* Just an FYI in regards to RCLACTGRP *ELIGBLE*

* I recall seeing a message from Barbara Morris of the IBM RPG compiler team*
* stating basically that *ELIGBLE was never intended to be used in a*
* production environment. That it really was meant to be used during*
* testing/development to easily reset the environment.*

If I said that, I was wrong. At least about the "easily reset the
environment" part. To save half a minute signing off and back on, I've
used RCLACTGRP *ELIGIBLE and then spent a couple of hours debugging a
problem that turned out to be caused by the RCLACTGRP. After the second
time I did that (I know, "fool me twice, shame on me"), I never use
*ELIGIBLE.

- Barbara Morris

Can't believe I forgot 17yr old details ;)

I've never used *ELIGIBLE that I can recall...

Charles

On Fri, Dec 3, 2021 at 3:23 PM Vern Hamberg via RPG400-L <
rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:

Thanks, Mark and Charles, et al.

We did a test, running the CGIDEV2 program, then the one with RCLACTGRP
*ELIGIBLE, then the CGIDEV2 program again - BOOM!

And now I took out the RCLACTGRP - all good.

We have some work ahead - one of us identified 30-some programs using
that command, by a fellow now retired. As always, need to verify it does
no harm to make the change.

Thanks again! This has been a sticky thing to peel off the wall! And now
we know something more than we did!

Cheers
Vern

On 12/3/2021 3:27 PM, Charles Wilt wrote:

Agree with Mark...

RCLACTGRP *ELIGIBLE is not something that should be run in production.

There's a reason IBM doesn't even show it as an option in the online
help for RCLACTGRP ;)

Charles

On Fri, Dec 3, 2021 at 1:54 PM Vern Hamberg via RPG400-L <
rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:

I may have found the problem - RCLACTGRP *ELIGIBLE. I have 2 examples
now of the user running the program that uses CGIDEV2, one time she uses
it 16 times, then MCH3402 - another program does RCLACTGRP, and CGIDEV2
AG is removed. Another time, over 35 uses, then MCH3402 - and again,
RCLACTGRP precedes it.

Oy!! One solution is to RCLACTGRP individually, I suppose - and not do
that to CGIDEV2. I know, probably not the ultimate answer, but maybe
good enough.

So, again, thoughts are welcome - I'll be talking this over with another
developer here, see what he thinks. But this fits. There was a support
KB from IBM based on Jon and Susan's work, that described this when
using RCLRSC, too.

Thanks all
Vern

On 12/3/2021 10:26 AM, Vern Hamberg via RPG400-L wrote:

Job log doesn't show anything - I'm wondering, how do we know what
can't be found anymore? MCH3402 is not very informative.

In this case, the error comes back to the RPG program when calling the
procedure - does it mean that the reference to the procedure is no
longer known? Or is it something IN the procedure that can't find
something?

Which brings us to ask - does CGIDEV2 somehow suppress or remove all
joblog messages? If so, is there a way to see what happens internally?
I do see a statement in one of the source members to change the job to
LOG(4 0 *SECLVL) when ending things. Did not see the opposite when
looking fairly quickly at the code. I think our jobs are using the
latter logging level - another thing to verify, eh?

Thoughts are welcome, as always here!
Vern

On 12/1/2021 8:11 AM, Vern Hamberg via RPG400-L wrote:

Hi Brad

I have the job log, will post it here or where y'all can see it. I
don't remember seeing anything, though. Opens and closes would be
done by the functions of CGIDEV2. I do wonder about the template file
itself, it has to be opened every time, but supposedly only if it has
changed. Also, the user has responded to the messages with a C until
there are no more, then can repeat the operation and is successful.

But I'll bring more info here.

Thanks
Vern

On 12/1/2021 7:58 AM, Brad Stone wrote:

Can you post the job log? Maybe there's a clue there. It could be
something like too many open sockets/files. Especially if in your
program
you are opening stream files and maybe not closing them all the time.

On Tue, Nov 30, 2021 at 5:00 PM Vern Hamberg via RPG400-L <
rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:

Y'all

We have one user who gets an MCH3402 a couple times a week when
creating
receipts - the programs uses CGIDEV2 to create HTML files used to
email.

It seems to happen after a busy morning of this. And it is to only
1 user.

Generally, the program does things in this order -

getHtmlIfsMult (only 1 template, though)
clrHtmlBuffer
updHtmlVar/wrtSection as needed
wrtHtmlToStmf

There is no information in CGIDEBUG that helps.

MCH3402 generally means that something a pointer points to is gone,
right? But it has to be in the getHtmlIfsMult.

I don't think we are running out of memory, and that isn't the
cause for
MCH3402, is it, anyhow?

Our solution right now is to wrap a monitor/endmon around the call

to

getHtmlIfsMult, display something to the user, then back to the
caller.
They are able to go to a different app and resend the receipts.

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our

affiliate

link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com