× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Vern,

That would do it -- it invalidates pointers to activated *SRVPGMs and *PGMs in that AG.

But, what code is issuing RCLACTGRP *ELIGIBLE ?  :-/   BAD IDEA!  :-o

IBM has always strongly advised against this ... except for special cases like when you are "debugging"...?   :-/

All the best,

Mark S. Waterbury






On Friday, December 3, 2021, 03:54:31 PM EST, 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





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.