Skip to main content

Retrieve list of Spooled files on System from SQL - IBM i

Spooled Files

Spooled files are generated when when system writes (prints) the data to an Output Queue. These could be Reports generated by the programs using Printer File (PRTF), System dumps or Job logs. 

Traditional way of getting the list of spooled files is by using WRKSPLF command, which by default displays the list of spooled files for the current user. 

Same can be retrieved from SQL with the use of table function SPOOLED_FILE_INFO. This is available in QSYS2. 

SELECT * FROM TABLE(QSYS2.SPOOLED_FILE_INFO());


Above query is simple and straight forward which returns the list of spooled files for the current user. Information returned is same as WRKSPLF (Work with Spooled files) and API (QGYOLSPL). 

Let's have a look at how output of the query looks like. 

SPOOLED_FILE_INFO


This query returns a full list of columns (we will see all the columns towards the end) for the current user who is running the query. 

We can make use of the parameters of the table function to retrieve spool files of all/other users and/or to narrow down the selection of the spool files. 

SELECT SPOOLED_FILE_NAME, STATUS, CREATION_TIMESTAMP, JOB_NAME, JOB_USER, JOB_NUMBER FROM TABLE(QSYS2.SPOOLED_FILE_INFO(USER_NAME => 'REDDYP'));


In the above query,
  • Parameter USER_NAME is used to select all the spool files for the specific user. 
  • Selecting few columns to look at the data we are interested in. 
    • SPOOLED_FILE_NAME - Name of the spooled file. 
    • STATUS - Status of the spool file. Below are the valid statuses.
      • CLOSED
      • DEFERRED
      • DELETED
      • HELD
      • MESSAGE WAITING
      • OPEN
      • PENDING
      • PRINTING
      • READY
      • SAVED
      • SENDING
      • WRITING
    • CREATION_TIMESTAMP - Timestamp of the spooled file creation. 
    • JOB_NAME - Name of the job that created the spooled file.
    • JOB_USER - Name of the user created the spooled file.
    • JOB_NUMBER - number of the job that created the spooled file.
We could add additional parameters as required. 

SELECT SPOOLED_FILE_NAME, STATUS, CREATION_TIMESTAMP, JOB_NAME, JOB_USER, JOB_NUMBER FROM TABLE(QSYS2.SPOOLED_FILE_INFO         (USER_NAME => 'REDDYP',         STARTING_TIMESTAMP => '2022-06-01-00.00.00.000000',         ENDING_TIMESTAMP => '2022-06-30-23.59.59.999999'));


In the above query, we are using the parameters to retrieve the list of spooled files as per the selection. Below are the valid parameters for the table function. One thing to note here is filtering on multiple values for user name, output queue, user data or status makes the query to run slower.
  • USER_NAME - Name of the user profile. This can contain up to 20 user names separated by blanks. Special values *ALL (all users on the system) or *CURUSR (Current user, default value) can be specified.
  • STARTING_TIMESTAMP - Timestamp of the earliest spooled file to be returned. If not specified all the spooled files are returned (or less than ending_timestamp if specified). 
  • ENDING_TIMESTAMP - Timestamp of the latest spooled to be returned. If not specified all the spooled files are returned (or greater than starting_timestamp if specified). 
  • STATUS - Status of the spooled file. Full list of status values are specified above and '*' needs to be prefixed in order to retrieve the specific status (E.g.: To retrieve spooled files in CLOSED status *CLOSED needs to be specified). Special value of *ALL can be specified if all the statuses are to be considered, *ALL is the default value. 
  • JOB_NAME - Qualified job name. Special values '*' (Current job) and '*ALL' (All jobs matching with any other parameters specified, default) can be specified. 
  • OUTPUT_QUEUE - Name of the output queue to be specified followed by library name (library_name/output_queue_name). Up to 20 values can be specified separated by blanks. *ALL (default) can be used to consider all output queues.  
  • USER_DATA - Value of the user specified data. *ALL (default) can be specified to consider all. 
  • FORM_TYPE - Form type. *ALL (all form types, default) or *STD (Only files that specifies standard form type) can be specified. 
  • SYSTEM_NAME - Name of the system name in which spooled file is created on. Special values *CURRENT (Spooled files created on current system) or *ALL (All spooled files irrespective of system they were created on) can be specified. 
In addition to the parameters of the table function, data can be further filtered by using the columns of the table function. 

SELECT SPOOLED_FILE_NAME, STATUS, CREATION_TIMESTAMP, JOB_NAME, JOB_USER, JOB_NUMBER FROM TABLE(QSYS2.SPOOLED_FILE_INFO         (USER_NAME => 'REDDYP',         STARTING_TIMESTAMP => '2022-06-01-00.00.00.000000',         ENDING_TIMESTAMP => '2022-06-30-23.59.59.999999'))

WHERE STATUS = 'READY';


Full list of columns and more details on the parameters can e found here. 


If you have any Suggestions or Feedback, Please leave a comment below or use Contact Form. 
Labels:

Comments

Post a Comment

Popular posts from this blog

All about READ in RPGLE & Why we use it with SETLL/SETGT?

READ READ is one of the most used Opcodes in RPGLE. As the name suggests main purpose of this Opcode is to read a record from Database file. What are the different READ Opcodes? To list, Below are the five Opcodes.  READ - Read a Record READC - Read Next Changed Record READE - Read Equal Key Record READP - Read Prior Record READPE - Read Prior Equal Record We will see more about each of these later in this article. Before that, We will see a bit about SETLL/SETGT .  SETLL (Set Lower Limit) SETLL accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Corresponding Record (or Next Record if exact match isn't found).  SETGT (Set Greater Than) SETGT accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Next Record (Greater Than the Key value). Syntax: SETLL SEARCH-ARGUMENTS/KEYFIELDS FILENAME SETGT  SEARCH-ARGUMENTS/KEYFIELDS FILENAME One of the below can be passed as Search Arguments. Key Fiel
4 comments
Read more

What we need to know about CHAIN (RPGLE) & How is it different from READ?

CHAIN READ & CHAIN, These are one of the most used (& useful) Opcodes by any RPG developer. These Opcodes are used to read a record from file. So, What's the difference between CHAIN & READ?   CHAIN operation retrieves a record based on the Key specified. It's more like Retrieving Random record from a Database file based on the Key fields.  READ operation reads the record currently pointed to from a Database file. There are multiple Opcodes that start with READ and all are used to read a record but with slight difference. We will see more about different Opcodes and How they are different from each other (and CHAIN) in another article. Few differences to note.  CHAIN requires Key fields to read a record where as READ would read the record currently pointed to (SETLL or SETGT are used to point a Record).  If there are multiple records with the same Key data, CHAIN would return the same record every time. READE can be used to read all the records with the specified Ke
Post a Comment
Read more

Extract a portion of a Date/Time/Timestamp in RPGLE - IBM i

%SUBDT Extracting Year, Month, Day, Hour, Minutes, Seconds or Milli seconds of a given Date/Time/Timestamp is required most of the times.  This can be extracted easily by using %SUBDT. BIF name looks more similar to %SUBST which is used to extract a portion of string by passing from and two positions of the original string. Instead, We would need to pass a value (i.e., Date, Time or Timestamp ) and Unit (i.e., *YEARS, *MONTHS, *DAYS, *HOURS, *MINUTES, *SECONDS or *MSECONDS) to %SUBDT.  Valid unit should be passed for the type of the value passed. Below are the valid values for each type. Date - *DAYS, *MONTHS, *YEARS Time - *HOURS, *MINUTES, *SECONDS Timestamp - *DAYS, *MONTHS, *YEARS, *HOURS, *MINUTES, *SECONDS, *MSECONDS Syntax: %SUBDT(value : unit { : digits { : decpos} }) Value and Unit are the mandatory arguments.  Digits and Decimal positions are optional and can only be used with *SECONDS for Timestamp. We can either pass the full form for the unit or use the short form. Below i
2 comments
Read more