To anyone who doesn't like searching job log spools for errors...

[Vectorspace]

...like when you have a compile fail on the binding step.

I recently discovered the existence of two IBMi system SQL table functions:
* SPOOLED_FILE_INFO(), which lists spool files matching certain criteria like name, number, user, job, and time (similar to WRKSPLF)
* SYSTOOLS/SPOOLED_FILE_DATA(), which extracts the content of a specified spool file by name/number/job

Quote useful on their own - Join the two table functions together to extract some or all of your job log spools:

    -- get id of my last job log spool
    with lastSpool as (
      select * from (
        select *
          from table(Spooled_File_Info()) s
         where Spooled_File_Name = 'QPJOBLOG'
      )
       order by Creation_Timestamp desc,
                Qualified_Job_Name desc,
                Spooled_File_Number desc
       limit 1 -- comment out to return all my joblog spools instead of just the last
    )
    -- Get content of this spool
    select j.*, s.*
      from lastSpool s,
           table(SYSTOOLS.SPOOLED_FILE_DATA(
             s.Qualified_Job_Name,
             s.Spooled_File_Name,
             s.Spooled_File_Number
     )) j
     order by s.Creation_Timestamp,
              s.Qualified_Job_Name,
              s.Spooled_File_Number,
              j.Ordinal_Position;​

This is, to me, already more readable than viewing the joblog with greenscreen or iACS Printer Output. Plus you can easily filter out lines like the page header lines, sort, etc.

To make even more usable I then wrote a custom formatter SQL table function in SQLRPGLE, that wraps SYSTOOLS.SPOOLED_FILE_DATA() and converts all the optional multiline key/value data lines (Message, To procedure, etc.) to column data, so each joblog entry rakes up only one result line (similar format to the IBMi system SQL function JOBLOG_INFO() that displays the job log for a specified active job).
Unfortunately it depends on the english spellings of the page headers in i7.3, so it might need modifying for OS updates or other languages. Also when messages are line-break-ed this is not done consistent, so any method of joining them back into one line will always be inaccurate - e.g. a job log entry for an executed command with long string parameters, may not be reassembled correctly.

The result of this is a simple SQL query I can ruin to view my last job log spool, neatly formatted with one record per entry. For me at least, it's quicker to access and much more readable than any other method.

Unfortunately since I wrote the spool formatter SQL table function at at work on work time I cannot share it, but it wasn't complicated so I suspect most people reading this would be capable of making their own version. Read next line, identify line type by looking for specific values at specific positions, and set/append to the appropriate substrings to the appropriate output columns.