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



Alan, in generally speaking, to get a better pgm performance and if you know that a pgm or series of pgms are going to be called more than once in a job then it's better to use a 'named' activation group and have the called pgms use that one or *CALLER.The reasoning behind this, is that named actgrps are not deleted/destroyed when the job ends, they remain inactive/dormant for when the pgm(s) are called again.
In the case that you describe "he first program called from one of the menu options, the one that gets most use, takes anywhere from a new seconds 
to a literal 48 seconds..." this could be many things, since you don't specify if it gets run interactive or if it submits a job and waits until it gets done to get back to the menu option, or if loads a subfile, etc.
Assuming it loads a subfile, it might be loading file(s) completely instead of by page or range, and if the loaded file(s) are high volume it could be part of the cause, another could be that each time it's called it open/close files instead of user cntrolled open/close, it can also be that files(s) have not been reorganized in a long time, it could be that recs get locked, etc etc.
I hope you find a good solution to your need
Ramon S.
On Saturday, March 5, 2022, 10:36:42 AM CST, Alan Cassidy <cfuture@xxxxxxxxxxx> wrote:

Thanks Jon!

Kind of confirms for me what I had been thinking.

I had forgotten to mention that one of the things in the back of my mind
was that these programs (written by somebody else, ahem) have a big
performance issue. The first program called from one of the menu
options, the one that gets most use, takes anywhere from a new seconds
to a literal 48 seconds and sometimes two full /literal/ minutes to get
to the first screen. The guy that wrote this (RIP) even wrote a warning
pop-up for when they hit F3 (exit to menu) by mistake, so that they
wouldn't have to wait that time to get back in.

I converted the main file driver loop to a multi-row SQL, which helped
some, but not much.

So putting the programs in one named activation group will save them
/some/ time, at least, as they navigate other called programs, buying
time to work out the performance thing.

--Alan


On 3/5/2022 11:14 AM, Jon Paris wrote:
Personally I like the idea of using *NEW for programs called from what I would describe as a root menu.  By this I mean one that you don't repeatedly return to every 15 minutes.

If you are popping in and out all day then a named group makes more sense.

One more consideration for the folks who "might use one or two" - if they really are hopping back and forward between two different areas I would not want to use *NEW.

Just my 5 cents worth.


Jon P

On Mar 5, 2022, at 11:09 AM, Alan Cassidy<cfuture@xxxxxxxxxxx>  wrote:


I'm working on organizing the programs called from a menu (or a program submitted for a batch job).

I remember guru-tech suggestions to run a program A as *NEW if it is called directly from a menu, and when that program calls program B or C, to create B or C as *CALLER.

But in the case of a user that is working all day on one thing, like making appointments with customers for pickup or delivery for example, they might use one or two. I'm just wondering if there are case where a named activation group vs. *NEW is the better value for the parameter. Or is this just noise in my head?

--Alan

--
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
athttps://archive.midrange.com/rpg400-l.

Please contactsupport@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 ...

Follow-Ups:
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.