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



Hi Mark,

Thanks for the link. I read it, and the only thing it has to say about OVRSCOPE is pretty much the same help text I quoted. And none of that explains the discrepancy between jobs submitted from the Advanced Job Scheduler (WRKJOBJS) or the ordinary job scheduler (WRKJOBSCDE).

I guess my question wasn't too clear. Let me try again.

1) When I submit a job via the old job scheduler, in this case, a command CmdA with cpp PgmA which is compiled with *DFTACTGRP, it apparently ran in the default activation group.

2) When I submit a job via the advanced job scheduler, the same CmdA with cpp PgmA compiled with *DFTACTGRP, it does NOT appear to run in the default activation group.

Why?

Scenario 1 seems to be straight forward; the joblog shows a SBMJOB with CMD(CmdA).

Scenario 2 is a little more complicated; the joblog shows a SBMJOB with CMD(CALL PGM(QIJS/QIJSCRUN) PARM('jobname' ' ' '00' 'QUSRIJS ' '*LCL ' ' ' '*LOC ' '*LOC '). QIJSCRUN is compiled with *DFTACTGRP. It uses "jobname" to get the list of commands for the scheduled job, and looks like it uses procedure QIJSC1ALG to execute the individual commands, in this case CmdA. Since the initial program, QIJSCRUN, is compiled with *DFTACTGRP, I would expect PgmA to be running in the default activation group, but it does not.

*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /


On 3/14/2010 12:26 PM, Mark S. Waterbury wrote:
Hi, Peter:

Read "Data Management Scoping Rules" (on pp. 48-50 in V5R4, pp. 41-44 in
V6R1) of the *ILE Concepts manual* in the InfoCenter:

http://publib.boulder.ibm.com/iseries/

Select V5R4 or V6R1 ... then click on the link for "i5/OS PDF files and
manuals" in the right pane, and look for the "ILE Concepts" manual.

V6R1 ILE Concepts
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/books/sc415606.pdf

V5R4 ILE Concepts
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/books/sc415606.pdf

HTH,

Mark S. Waterbury

> Peter Dow wrote:
Hi Rob,

I'm no expert on this, but the help for the OVRSCOPE parm says for
*ACTGRPDFN "When the activation group is the default activation group,
the scope equals the call level of the calling program." and for
*CALLLVL "The scope of the override is determined by the current call
level. All open operations done at a call level that is the same as or
higher than the current call level are influenced by this override."

Which I take to mean that if the program issuing the overrides is in the
default activation group (which PgmA is), then it is as if OVRSCOPE was
*CALLLVL, and when that's the case, the fact that PgmB is in a new
activation group does not matter.

*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx<mailto:pdow@xxxxxxxxxxxxxxx> /



On 3/13/2010 2:09 PM, rob@xxxxxxxxx wrote:

Peter,
If PGMA does an override *ACTGRP and then calls PGMB in ACTGRP(*NEW) then
the fact that the override EVER worked is only through the power of some
deity. But I'll admit, I've never read the ILE Concepts Guide.


Rob Berendt



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.