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



Read and study the "ILE Concepts" manual ... (RTFM)

Ensure that all of your bound programs, any calling *PGMs and all of the *SRVPGMs they use/call, all run in the same named activation group, then have a separate program that runs in the *DFTACTGRP or another named or *NEW activation group that issues RCLACTGRP for that named AG, and it all gets "cleaned up" just like when you sign-off and sign-on again.

This is the rationale for activation groups -- it's like a job within a job.   Just as end-of-job cleans up everything, so does end of activation group, but only for that AG's resources.

Another way to manage this is to ensure all of your "main" top-level bound *PGMs are created with ACTGRP(*NEW) and all the bound *PGMs and any *SRVPGMs they use or call are created with ACTGRP(*CALLER).  So, then when a "top-level" (main) program returns, the corresponding *NEW AG gets destroyed and all the resources allocated within it get cleaned up, automatically.

If you use only "named" activation groups, you (or a program) must issue:

    RCLACTGRP ACTGRP(name) 

for each AG, otherwise they never get cleaned up until the entire job ends.

(It's not "rocket science.")

Hope that helps,

Mark S. Waterbury


On Wednesday, May 5, 2021, 9:35:26 PM EDT, x y <xy6581@xxxxxxxxx> wrote:

I've had the same problem for years.  You're running the program in a named AG.  You recompile the program, STRDBG, and crash with MCH3402.  You try RCLACTGRP {named-AG} and it crashes,  You try RCLACTGRP *ELIGIBLE (Jon Paris is experiencing a burning pain), rerun the program, and get the same error.  Sometimes rerunning my initial program solves the problem; other times I have to sign off.  It is a burr under my saddle.

On Wed, May 5, 2021 at 3:07 PM Brian Garland via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

Background:

I'm working with a system that has service programs that run in a named
activation group.
We have multiple library lists for different environments (different sets
of test data in different libraries) and like to switch between them.
These library list changes could include the library that contains the
service programs.
The service programs use native I/O have an "open" procedure that opens the
files (among other things) and registers a "close" procedure (closes files)
with CEE4RAGE.

I'm working on some changes to this process and we now have a CL program to
manage the library list for us when we change environments.  Part of that
CL is RCLACTGRP on that named activation group.

Problem:

I'm seeing the dreaded MCH3402 Tried to refer to all or part of an
object... after RCLACTGRP and changing the library list at the point the
first program in the call stack tries to call a procedure from one of the
service programs.

Do I have the concept wrong here?  What could I be doing wrong?

Thanks in advance.



  ---
Brian J. Garland
Vermont Information Processing, Inc.
brian.garland@xxxxxxxxxx

--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or company to whom they are
addressed.
Do not disclose, distribute, or copy this email to others outside your
company. If you have received this email in error, please notify the
sender
immediately and delete this email from your system.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-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.