Re: TFRGRPJOB vs ACTGRP

[Mark S Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>]

Hi, again, Dave:

As others have suggested, you could also do something like this:

   create a CL "wrapper" for this program, such that each time this
   "wrapper" program is called, it saves the current *LIBL, then alters
   the library list as needed, and then calls the actual program, and
   then, just prior to returning to its caller, it restores the saved
   *LIBL.

Another way to isolate this program from the rest of the job, with its 
own library list, etc., is to have it run in its own (batch) server job, 
and your other (interactive) job(s) just communicate with that server 
job, e.g. using data queues.

Does this program that needs to be isolated "stay active" (e.g. return 
with *INLR=*OFF)?

Does this program call other programs?  Or is everything bound into one 
large ILE *PGM?

If the main issue is working with the alternate set of files, and if the 
code is all ILE RPG IV, you can use the ability to open a file driectly, 
by specifying the library, file and member name in the program, without 
having to modify the *LIBL, and without having to issue any OVRDBFs; see 
the EXTFILE and EXTMBR keywords on the F-Spec.  That way, this program 
can open the alternate files, without "messing with" the *LIBL. In this 
case, I would put this program in its own named activation group, just 
to keep things simple, as far as shutting down this program and closing 
all files and cleaning up its resources, etc. -- If the program does not 
"stay active" (exit with LR OFF), then you might also be able to use 
ACTGRP(*NEW), so the system will clean up the AG automatically when the 
program returns.

Hope that helps,

Mark
On 7/24/2012 2:07 PM, Dave wrote:
> Thanks Gary,
> The program running with library list libl1 shows a subfile, an option on
> the subfile runs another application that must use identically named files
> residing in different libraries so uses library list libl2. In your step 3,
> the called program will use any files that are already open in libl1.
>
> 2012/7/24 Monnier, Gary <Gary.Monnier@xxxxxxxxx>
>
> > Hi Dave,
> >
> > I'm a bit confused as to why you are looking at using group jobs.  Why not
> > just change the job's library list to be what you need?  You can always
> > change the library list back when the program completes.
> >
> > The basic steps are...
> >
> > 1.  Save the jobs' current library list settings.  You can use command
> > RTVJOBA or API QUSRJOBI with format JOBI0700.
> > 2. Set the job's library list to what you need.  Use command CHGLIBL or
> > API QLICHGLL.
> > 3. Perform the necessary processing.
> > 4. Set the job's library list back to what it was in step 1.  Use command
> > CHGLIBL or API QLICHGLL.
> >
> > The APIs can be used in OPM or ILE RPG if you don't want to call CL
> > programs/modules.
> >
> > In CL the 4 Binary in the APIs can be defined as
> >
> >          Dcl  Var(&parmname) Type(*INT) Len(10 0)
> >
> > 2 Binary can be defined as
> >
> >          Dcl  Var(&parmname) Type(*INT) Len(5 0)
> >
> > HTH,
> >
> > Gary Monnier
> >
> >
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
> > midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dave
> > Sent: Tuesday, July 24, 2012 5:55 AM
> > To: Midrange Systems Technical Discussion
> > Subject: TFRGRPJOB vs ACTGRP
> >
> > Hi,
> >
> > Been looking at the possibilities of running a program using a different
> > library list than the caller. Particularly as the program is a large OPM
> > calling lots of others all copybooked in, I've been looking at TFRGRPJOB. I
> > have to submit my analysis, and I'm pretty sure I'll be told to convert
> > everything to ILE and use an ACTGRP to keep things isolated from the
> > calling program. I'm hard put to think of an advantage of running the
> > program in an activation group rather than a group job. Here's one: when
> > using STRDBG you can step into the called program.
> > Any more?
> > Thanks!
> > --
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
> > unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
> > moment to review the archives at http://archive.midrange.com/midrange-l.
> >
> > --
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.