Booth Martin wrote:
Narrowed down further. Here is the command:
WRKOUTQ OUTQ(QUSRSYS/PRT01) OUTPUT(*PRINT)
10,000 spoolfiles are in this queue.
Run from the command line = 2+ minutes.
Run again immediately, = 3 seconds
Run again 5 minutes later = 3 seconds
Booth:
There are a number of similar behaviors in different 'things'.
Here's a very basic CL example that can show similar behavior over a
library object:
PGM PARM(&LIB)
DCL VAR(&LIB) TYPE(*CHAR) LEN(10)
DCL VAR(&LIBDTA) TYPE(*CHAR) LEN(256)
Qsys/call QLIRLIBD ( +
&libdta +
x'00000100' +
&lib +
X'000000020000000600000007' +
x'0000000000000000' +
)
RETURN
ENDPGM
Compile that as a CLP (or CLLE) and call it for a decent sized
library (assuming you have authority to use the library you pass as
the parm). Note how long it takes.
Then signon to a different session and run the exact same CALL. Note
how long it takes. Pick a library with a large number of objects,
maybe one with source files with lots of members, and note the time
differences between first and subsequent calls.
The QLIRLIBD API in this call extracts some basic info about the
objects contained in the library. As you can see, it doesn't _do_
anything except the extract. It requests two keys -- 6 and 7,
Library size information and Number of objects in library.
The system can create and use numerous temporary, internal spaces
and indexes to do the work you ask of it. Whenever it can, it'll use
ones that already exist; otherwise, they have to be created and
probably populated. Along the way, as intermediate objects are
accessed, elements such as authorities need to be resolved. When
info is available and still "fresh", there's a good chance it can
simply be reused, with very little overhead in that process. (All
very simplified...)
Given the objects in QSPL, authorities on output queues and spooled
files, and everything that goes on behind WRKOUTQ, I have no problem
seeing an extension of the basic behaviors.
Been that way for a long time.
Tom Liotta
midrange.com
