Re: QRPLOBJ objects in use?

Yes, such solution and decoupling is indeed sounding.Also, activation group provides the proper controls.RPG can of course be stateless, or use static storage to its own advantages (like caching etc.). One can treat it to be referentially transparent, *PGM CALLed dynamically is basically a (but performant) microservice with no de/serialization overhead (by default).

In my case, having already it, I've a "virtual terminal" Openaccess solution that basically drives the display, using the classic "push" control of 5250 (EXFMT) from RPG side, it creates its own interactive job per session, like a normal interactive 5250. The output is unattended (js timeouts advance the screen).
ciao

On Monday, March 2, 2026 at 02:27:17 PM GMT+1, Marco Facchinetti <marco.facchinetti@xxxxxxxxx> wrote:

Correct "I have some RPGs that drives (web) unattended digital signal" we
call them "listeners" maybe not the correct name but sounding.

The sole purpose of listeners is to coordinate the dumb programs IWS
implements by indicating "where" the job that can execute the request is
located. And only in rare cases, to restart the executors. Restarting is
probably the cheapest and simplest solution, since the executors are
designed to rebuild the state from scratch.

The benefits of this structure are essentially 3:
- The status of the programs is maintained by always using the same job
against the same credentials
- Programs called by IWS do not access database and do not use srvpgm so
they do not create problems when they are replaced (the service must be
regenerated if the interface changes)
- The decoupling between back-end, application server and front end is real
and not just theoretical

Sometimes I like to think of this solution as a 5250 on steroids but
without the limitations of the 5250 :-)

Best regards
--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco


Il giorno lun 2 mar 2026 alle ore 12:41 cesco via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> ha scritto:

  Let IBMi do its thing regarding object replacement... you need to solve
the problem with some sort of process in the code (if you need performance).
Use activation groups (named) if you want the control, and reclaim there
(use a simple controller outside the "real" group).

I.e. one idea you can have a simple main program that after checking a
"currency" value somewhere or some other signal, file, DTAQ etc. then call
the programs graph downstream, or "refresh" the activation group if
required, use a named activation group.
For example, I have some RPGs that drives (web) unattended digital signal
display running 24h / 24h showing graph/data/kpi directly from DB data
etc... we can swap the programs as we wish, alter logics etc. , live ,
without needing a restart. There I also use a lot of dynamic CALL using a
variable for the target pgm, so we can evolve in both directions,
parametric via data or static via program replacements, without restarts.







    On Friday, February 27, 2026 at 04:57:34 PM GMT+1, David Gibbs via
MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

  On Wed, Feb 25, 2026 at 3:37 PM Daniel Gross <daniel@xxxxxxxx> wrote:

probably they're replacing service programs or programs in production -
now you want to know, which jobs have to be restarted, to "re-load" their
service programs or program objects.

Yes, exactly that.

Specifically, we have many web services running through IWS and we never
turn
on lr so the programs stay active (very high volume, so we avoid having to
open & close files).

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


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