Skip to main content

Retrieve Job log information from SQL - IBM i

Job log

Job log provides information about the job including any errors and is extremely helpful to analyze what has happened. 

Sometimes, it becomes difficult to check all the messages in the job log (especially when the job is running for longer or if there are many messages in the job log) just by using DSPJOB/WRKJOB. 

SQL table function JOBLOG_INFO provides another way of accessing job log from SQL session. Each message from the job log is returned in a new row. This gives the flexibility to query and select the messages as required (E.g.: Requests, Diagnostic Informational etc). 

This table function requires one mandatory parameter Job name and one optional parameter Ignore errors. 

Job Name (JOB_NAME) - Qualified job name (job number/user/job name). For the job log of current job, '*' can be specified. 

Ignore Errors (IGNORE_ERRORS) - This parameter accepts either 'YES' or 'NO'. This determines what needs to be done in case of any error in Query execution. 
  • NO (default) - An error is returned. 
  • YES - A warning is returned. No rows are returned when an error is encountered. 
Let's have a quick look at a query to retrieve the job log of current session. 

1

2

3

4

5

6

7

8

SELECT ORDINAL_POSITION,

       MESSAGE_TYPE, 

       MESSAGE_TIMESTAMP, 

       FROM_LIBRARY, 

       FROM_PROGRAM, 

       MESSAGE_TEXT, 

       MESSAGE_SECOND_LEVEL_TEXT 

FROM TABLE(QSYS2/JOBLOG_INFO(JOB_NAME => '*'))


In the above query, 
  • Lines 1 - 7: Few columns from the table function JOBLOG_INFO. More info on each of these columns can be found below. 
  • Line - 8: JOB_NAME parameter is being passed with '*' to retrieve the job log of current job. 
Below are the few columns used in the above query. 

ORDINAL_POSITION - A unique number of each row in the job log. First message in the job log would contain '1' and incremented by '1' for the next message. 

MESSAGE_TYPE - Type of message from the job log. Below are the valid values for this column. 
  • COMMAND
  • COMPLETION
  • DIAGNOSTIC
  • ESCAPE
  • INFORMATIONAL
  • INQUIRY
  • NOTIFY
  • REPLY
  • REQUEST
  • SCOPE
  • SENDER
MESSAGE_TIMESTAMP - Timestamp when the message was written to Job log. 

FROM_LIBRARY - The library containing the program or service program that sent the message.

FROM_PROGRAM - The program or service program that sent the message.

MESSAGE_TEXT - First level of text message. 

MESSAGE_SECOND_LEVEL_TEXT - Second level of text message. 

There are many other useful columns present in this table function. Full list of columns can be found here.  

Above query returns all the messages in the job log. We can also select the records based on the message type or any other columns as required.

1

2

3

4

5

6

7

8

9

SELECT ORDINAL_POSITION,

       MESSAGE_TYPE, 

       MESSAGE_TIMESTAMP, 

       FROM_LIBRARY, 

       FROM_PROGRAM, 

       MESSAGE_TEXT, 

       MESSAGE_SECOND_LEVEL_TEXT 

FROM TABLE(QSYS2/JOBLOG_INFO(JOB_NAME => '*'))

WHERE  MESSAGE_TYPE = 'DIAGNOSTIC' ;


In the above query, 
  • Line - 9: We are only retrieving the diagnostic messages by adding condition on MESSAGE_TYPE. 
Job log info from SQL - IBM i

This query would only return the diagnostic messages along with it's position in the job log (ORDINAL_POSITION) and timestamp the message was sent to job log (MESSAGE_TIMESTAMP).

In both the queries mentioned above, we are only retrieving the job log of the current job by passing '*' against the job name. 

Let's have a look at retrieving the job log of other job. 

1

2

3

4

5

6

7

8

SELECT ORDINAL_POSITION,

       MESSAGE_TYPE, 

       MESSAGE_TIMESTAMP, 

       FROM_LIBRARY, 

       FROM_PROGRAM, 

       MESSAGE_TEXT, 

       MESSAGE_SECOND_LEVEL_TEXT 

FROM TABLE(QSYS2/JOBLOG_INFO(JOB_NAME => '730621/REDDYP/QPAD202846'))


In the above query, 
  • Lines 1 - 7: Columns from the table function as required. 
  • Line - 8: We are passing qualified job name with job number, user and job name. 
By adding condition on the columns we can extract the specific information required. 

E.g.: List of commands executed in an interactive session. 

This can be achieved by adding condition on MESSAGE_TYPE. 

1

2

3

4

5

6

7

8

SELECT MESSAGE_TYPE, 

       MESSAGE_TIMESTAMP, 

       FROM_LIBRARY, 

       FROM_PROGRAM, 

       MESSAGE_TEXT, 

       MESSAGE_SECOND_LEVEL_TEXT 

FROM TABLE(QSYS2/JOBLOG_INFO(JOB_NAME => '730621/REDDYP/QPAD202846'))

WHERE  MESSAGE_TYPE = 'REQUEST' 


Job log information from SQL - IBM i

Above query can be amended to fetch the first command or last command etc. 

For some reason, if the job doesn't present in the system or any other errors occurs while running the above query, an error is returned. This may cause an issue when running these query as part of procedures or function.

To avoid this, we could consider using optional parameter IGNORE_ERRORS (YES). By passing this parameter, JOBLOG_INFO would only return a warning and no records are returned. 

1

2

3

4

5

6

7

8

9

SELECT MESSAGE_TYPE, 

       MESSAGE_TIMESTAMP, 

       FROM_LIBRARY, 

       FROM_PROGRAM, 

       MESSAGE_TEXT, 

       MESSAGE_SECOND_LEVEL_TEXT 

FROM TABLE(QSYS2/JOBLOG_INFO(JOB_NAME => '730621/REDDYP/QPAD202846', IGNORE_ERRORS => 'YES'))

WHERE  MESSAGE_TYPE = 'REQUEST' 


If this parameter (IGNORE_ERRORS) is not passed, default value 'NO' is considered and an error is returned for any error while running the query. 


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

Comments

  1. Not working with QSYS2/JOBLOG_INFO, working correctly with QSYS2.JOBLOG_INFO

    ReplyDelete
    Replies
    1. Hi Victor,

      This could probably due to the Naming convention set up to *SQL in JDBC settings.

      QSYS2.JOBLOG_INFO can be used if the Naming convention is set up to *SQL. Alternatively Naming convention can be updated to use *SYS which allows both period (.) and back slash (/).

      Thanks,
      Pradeep.

      Delete
  2. I am not able to pass a variable in the JOB_NAME ...
    Trying to do
    SELECT MESSAGE_TYPE,

    MESSAGE_TIMESTAMP,

    FROM_LIBRARY,

    FROM_PROGRAM,

    MESSAGE_TEXT,

    MESSAGE_SECOND_LEVEL_TEXT

    FROM TABLE(QSYS2/JOBLOG_INFO(JOB_NAME => ':JOBNAME',
    IGNORE_ERRORS => 'YES'))

    WHERE MESSAGE_TYPE = 'REQUEST'

    ReplyDelete
    Replies
    1. Hi,

      You do not need to use single quotes when using host variables. Please remove quotes and try.

      JOB_NAME => :JOBNAME

      Thanks,
      Pradeep.

      Delete

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

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

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