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



I agree, Jon, about one activation group signing in. But that's way beyond the scope of this application and would complicate everything. Most of the team barely understands activation groups, and they've been converting programs to free form but compiling mostly with *NEW, and *CALLER, sometimes QILE, without much rhyme or reason. I tried to warn them at one point, but it was when one install of a change caused a big mess that they started paying attention.

Thanks for the input.

--Alan C


On 3/5/2022 11:49 AM, Jon Paris wrote:
For that specific problem one possible approach is to have such an AG created during sign on. People tend not to notice an extra second or three while signing on - they just assume that a large number of people just signed on! And of course they are often chatting to neighbours about last night's TV and/getting their first coffee during signon,

Jon P


On Mar 5, 2022, at 11:36 AM, 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
--
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.