RE: WRKACTJOB leaving part of itself running?

Warren,

>I'd like to prove or disprove a persistent "AS/400 legend":

I've always felt that this myth should be part of the Urban Legends.

>If you WRKACTJOB, then exit the function but remain signed
>on, are any system resources used? Is there any part of
>WRKACTJOB
>that remains running even though you are no longer in the
>command?

Your question starts out a little vague, so the correct answer has to be
yes, there are system resources used when you do a WRKACTJOB and remain
signed on. Is there any part of WRKACTJOB that remains running after you
stop using the command? No, I don't think so. Here's the basis for my
reasoning. (And I've spent a lot of time looking into this.)

When you run the command, there are two internal objects created and saved.
They are QWCCDSACJOBINDEX and QWCCDSACJOBSPACE. These objects are small
(variable depending on the number of jobs running on your system), but for
example, the JOBINDEX object on my system was about 14K. Right now, I don't
have many active jobs on my system. So yes, it is taking up disk space and
while it isn't much disk space, it is a "system resource" being used on an
ongoing basis.

These objects are all kind of stored in your QTEMP library. You can't see
them, of course, if you do a DSPLIB QTEMP. (They also don't go away if you
do a CLRLIB QTEMP.) However, if you look at your Process Control Space after
you do a WRKACTJOB, they are "visible." You can take a look at the structure
of your job if you do a DMPJOB from the command line while the WRKACTJOB is
running. (You can also see them if you dump your QTEMP library.)

On the list of programs, you'll see the program QWCCDSAC, which is the
WRKACTJOB program. If you search for the program QWCCDSAC in the DMPJOB
output, you'll probably see it twice. The first time, the dump is simply
listing all programs in the stack. The second time you find it in the dump,
you'll see the program space associated with the WRKACTJOB program.

At the top of that section, you'll see a bunch of mostly meaningless
pointers and data storage for the program. If you keep paging down, you'll
see a list of resolved pointers for the program. It'll look something like
this:

0080A0   SPP 1A EF SCPF      QSYS      000000
00000000  0000
008220   SPP 1A EF QPADEV0001HOOPES    025609
0000A430  0000
008230   SYP 02 01 QWCSDSAR                        04 01 QSYS
3F10  0000  *PGM
008240   SYP 02 01 QWCSHCFR                        04 01 QSYS
3F10  0000  *PGM
008250   SYP 02 01 QWCSHUIC                        04 01 QSYS
3F10  0000  *PGM
008260   SYP 02 01 QWCSDSMR                        04 01 QSYS
3F10  0000  *PGM
0086D0   SPP 19 EF QWCCDSACJOBSPACE                04 C1 QTEMP
00D87DE6F6BD07470000  00000000  0000
0086F0   SPP 1A EF SCPF      QSYS      000000
00000000  0000
008760   SYP 0E EF QWCCDSACJOBINDEX
0000  0000  *QTIDX
008770   SYP 0E EF QWCCDSACORDERINDEX
FF10  0000  *QTIDX

That list shows the address of the pointer in the program's data space, the
pointer type, the object type and subtype, the object name, the context type
and subtype, the context name, and a bunch of other mostly useless data.
Notice that the QWCCDSACJOBSPACE is stored in QTEMP. You can dump that
object and take a look at what's inside of it, if you're curious. Here's the
command you'd use:

DMPSYSOBJ OBJ(QWCCDSACJOBINDEX) CONTEXT(QTEMP) TYPE(0E) SUBTYPE(EF)

(You can do the same thing for QWCCDSACJOBSPACE, but it's type 19 subtype
EF.) The JOBINDEX object is a user index, so the first thing you see is all
of the index entries. If you page down the primary associated data space,
you'll see that the WRKACTJOB command stores, on disk, a lot of information
about the last state of all jobs on the system when the WRKACTJOB command
was run. So there's no need to keep a background job running. (You can see
the QWCCDSACJOBSPACE object, using the same command but it's type 19,
subtype EF.)

Now to approach the question from a different perspective. If you run the
performance tools, you can see an agonizingly long list of processes on the
system. I've gone through that list many times and have never seen a process
added for the WRKACTJOB command.

One other note since I'm describing every thing you ever wanted to know
(NOT!) about the WRKACTJOB command. If you run the WRKACTJOB command and do
an End Previous Request (option 2 on the system request menu), only the
JOBSPACE object is created. I don't understand that quirk.

Can we officially kill this myth once and for all?

Now I'm going to do something fun and play with Domino for AS/400.

Regards,
Jim H.

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---