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



Hello, Charles:

The executable code within *PGMs and *SRVPGMs is "reentrant" so the executable code is "shared" (read-only pages) across multiple jobs (and so is a lot of other stuff in the vast single-level-storage address space).

Unique to each job is the "activation" of each program and service program, which includes the allocation of static and automatic (dynamic) storage for the programs, etc. The "activation group" is the container for all of these various 'activations' of *PGMs and *SRVPGMs, allowing for programs to control "clean-up" by activation group. You can think of each job as initially having just one activation group. (Actually, there are always at least two AGs, the DAG or default activation group where OPM programs must run, and an ILE activation group where ILE *PGMs run.) There is also a "System-wide Activation Group" (or SAG) where many ILE components of OS/400 run, so they are initialized once (usually at IPL) and they can remain activated and "in use" across the entire system.

As others have pointed out, one way you can do something similar is to create a (never-ending) "server job" to service requests.

Traditionally, (going back to System/38 CPF), you would implement this approach using data queues. Today, you might also want to consider using a TCP/IP sockets interface. One advantage of the TCP/IP sockets approach is that the client programs can run on a PC under Windows or Linux, or on another Unix or Linux server, or even another iSeries system, while the "server jobs" run on your System i. There are various approaches for spawning multiple jobs (or threads) so that as the frequency of requests (or volume of transactions) increases, your server can "keep up" or "scale up" as needed. (In fact, this is exactly what most HTTP servers do.)

I hope this explanation helps?

All the best,

Mark S. Waterbury

> Charles St-Laurent wrote:
Hi!
I wonder if what I want to do is possible on iSeries (V5R4).
I want to load many service programs in a kind of shared memory and then use
the loaded service programs from interactive or batch jobs, so the loaded
programs won't be loaded each time I start a new batch or interactive job
that wants to use them.
For example:
1) I load all my service programs once and initialize them correctly
2a) I submit a job and I want the submitted job to use the loaded service
programs that have been loaded previously and passing them parameters
2b) I launch an interactive job and I want this interactive job to use
service programs that have been loaded previously and passing them
parameters
I read about activation groups. Activation groups are effective within the
same job. But in my case, I also want to use persistent programs between
jobs (each batch job is a new job and I don't want my service programs to be
allocated/released each time). I want my batch jobs to execute previously
loaded service programs, each time with different parameter values.

Charles St-Laurent
Consultant Berco
Technologies
Industrielle Alliance, Assurance auto et habitation Téléphone : 418 650-4600, poste 3216
Sans frais : 1 800 463-4382
Télécopieur : 418 650-4612
Sans frais : 1 877 650-4612
Courriel : charles.st-laurent@xxxxxxx <mailto:pcharles.st-laurent@xxxxxxx> www.inalco.com/assurancegenerale

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.