On 09-Oct-2015 17:36 -0600, gio.cot wrote:

Is it possible to retrieve the last spool number for a specific spool
file (in the same job) ?

For a specific spooled file name? Yes.

Retrieve Spooled File Attributes (QUSRSPLA) API
The Retrieve Spooled File Attributes (QUSRSPLA) API returns specific information about a spooled file into a receiver variable. The size of the receiver variable determines the amount of information returned. You can specify the spooled file for which information is returned either with the internal job and spooled file identifiers, or with a specific job name, spooled file name, and spooled file number.


Spooled file number

The unique number of the spooled file. The valid range is 1 through 999999.

The following special values are supported for this parameter:

0 Only one spooled file from the job has the specified file name, so the number of the spooled file is not necessary.

-1 This uses the highest-numbered spooled file with the specified file name.

-2 The spooled file number is not used to determine which spooled file to process. Use this value when you want the Job system name parameter or the Spooled file create date and Spooled file create time parameters to take precedence over the spooled file number when selecting a spooled file.


SPLA0100 Format

The following table shows the information returned for the SPLA0100 format.

Offset Type Field
Dec Hex
0 0 BINARY(4) Bytes returned
4 4 BINARY(4) Bytes available
8 8 CHAR(16) Internal job identifier
24 18 CHAR(16) Internal spooled file identifier
40 28 CHAR(10) Job name
50 32 CHAR(10) User name
60 3C CHAR(6) Job number
66 42 CHAR(10) Spooled file name
76 4C BINARY(4) Spooled file number
... ... ... ...


See my comment about Spooled File Number (SPLNBR) Special-Value of *LAST [i.e. SPLNBR(*LAST)] further-on in my response; in the above API, effectively SPLNBR(-1) correlates:

Example: my job spool files

Effectively the example is WRKSPLF information; reformatted both to fit without wrapping and to assign column headings:

Device or Total File
File User Queue User Data Sts Pages Cpy Nbr


I would need to know that the last spool number for QSYSPRT is 5

I see QSPRILSP API, but it seems to me that I can't get what I would

... would ¿need and\or want from that API? ... apparently?

No, seems not with the QSPRILSP API, not in the scenario [I infer is] alluded. Success with that API is precluded, ever since the SPLNBR(6) was generated; i.e. the call to that API must be made after SPLNBR(5) was generated, but before SPLNBR(6) was generated.

However with the known\expected name QSYSPRT, the special-value *LAST typically serves as a replacement for a specific Spool Number (SPLNBR). Thus the combined identification of Spool-File-Name=QSYSPRT and Spool-File-Number=*LAST can be used with JOB(*) to locate and thus [usually also be able to] identify that "the last spool number for QSYSPRT is 5", via the feedback from whatever is the method into which those values were input; e.g. the msg CPF3485 is issued by Copy Spooled File, and that message supplies replacement data identifying into what numeric value was resolved, the special-value of *LAST. The previously mentioned Retrieve Spooled File Attributes (QUSRSPLA) API has that same support to resolve the SPLNBR() without having to perform copy [or send, or etc.] against the spool file and then refer to whatever is the specific feedback mechanism of that feature; i.e. just use the API to get the return value in a receiver-variable.

How can I do it ?

The aforementioned API seems reasonable given the assumption(s) will hold about the spooled file name. Otherwise, or just of possible tangential interest:

The intent of that Retrieve Identity of Last Spooled File Created (QSPRILSP) API is pretty much\only what the name implies. The intention of the API, is that the program producing a spooled file, or the program calling a program that knowingly will produce a spooled file, can invoke the API to learn what was the Spooled File Name (FILE) and the Spooled File Number (SPLFNBR); typically those are two important values to be used as input on requests like Copy Spooled File (CPYSPLF).

The following two messages might be of interest:

In the given scenario, the control-program that calls the report-generation program [e.g. CLP->RPG] might call that API after calling the reporting program to get the information about the last-spooled-file so something can be done to that just-created SPLF, for which knowing the SPLNBR() and FILE() are pertinent; e.g. CPYSPLF, SNDNETSPLF, SNDTCPSPLF.

What is not clear in the scenario, is if maybe the reporting program might be creating two different QSYSPRT spool files, such that the control program is only able to obtain the information about the latter; while possibly requiring information about both In that case, the reporting program and control program have to work together based on rules and\or assumptions, to get exacting or to infer the prior spool. One possible method could be a callback mechanism, for which the reporting program changes to invoke the procedure after each spool is produced. Another is to list the spools for the job, and exclude any outside of a special naming or other common attribute [such as USRDTA]; e.g. knowing the reporting program uses QSYSPRT and produces one-or-many, the listing can obtain the /group/ of files. Another method again relying on same-named spool files, could use the special-value *LAST can be resolved and subtracted-from in a loop until a known number of SPLF are processed or until the prior file is no longer known by that name. Note: In common naming and\or attributes, the Override With Printer File (OVRPRTF) can be used in a control program to ensure all of the spool files created by the reporting program will be created with the same\specified attributes; including ensuring the HOLD(*YES) and\or SAVE(*YES) to prevent the implicit deletion if the files were to be [accidentally] written by the Writer.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].