• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Guru: Beefing Up The Job Log, Take Two

    August 6, 2018 Ted Holt

    In Tracing Routines Explain Why The Computer Did What It Did, I wrote about the usefulness of writing information about program execution to determine why a program run gave certain results. Today I want to present a simpler method than the tracing routines. The tracing routines are not obsolete, but they are powerful and I have found them at times to be overkill.

    Just a word about terminology. Since I wrote that article five and a half years ago, my reading has led me to a different understanding of the terms tracing and logging. I’ve since decided that the activity I described in my article was more properly logging, not tracing. For that reason, I use the term logging in this article. In the grand scheme of things, terminology is of little importance.

    I often need a way to determine why a program behaved as it did. Sometimes I can use an interactive debugger to accomplish that. Sometimes an interactive debugger won’t answer the purpose, so I resort to logging. IBM i already has an effective logging mechanism — every job has a job log. An easy way, then, to understand program behavior is to write helpful messages into the job log. To do that, I use the Qp0zLprintf API, which Daniel Long shared with me and I wrote about in Beefing Up The Job Log.

    Here’s a short program that illustrates the process.

    /define LoggingIsOn
    
    H dftactgrp(*no) actgrp(*caller) option(*srcstmt: *nodebugio)
    
    D GrossAmt        s              7p 2
    D Discount        s              7p 2
    D Policy          s              1a
    
    (. . . more code . . .)
    
    C     TAG01         TAG
     /if defined(LoggingIsOn)
       JobLog ('> TAG TAG01');
     /endif
    
    C                   exsr      CalcDiscount
    (. . . more code . . .)
    
    C     CalcDiscount  begsr
    
     /if defined(LoggingIsOn)
       JobLog ('> Enter CalcDiscount. Policy=/' + Policy +
                                 '/ GrossAmt=/' + %char(GrossAmt) + '/');
     /endif
    
    (. . . more code . . .)
    
     /if defined(LoggingIsOn)
       JobLog ('> Leave CalcDiscount, Discount=/' + %char(Discount) + '/');
     /endif
    
    C                   endsr
    
     /if defined(LoggingIsOn)
       dcl-proc JobLog;
    
          dcl-pi JobLog;
                  inMessage  varchar(132)    const;
          end-pi JobLog;
    
       dcl-pr  Qp0zLprintf   int(10)  extproc('Qp0zLprintf');
                  inMessage  pointer  options(*string: *nopass) value;
       end-pr  Qp0zLprintf;
    
       dcl-c  EOL           const(x'25');
    
       Qp0zLprintf (%trimr(inMessage) + EOL);
    
       end-proc JobLog;
     /endif
    

    Let’s look at this code one piece at a time.

    /define LoggingIsOn 
    

    I use this compiler to include logging during development. When the program goes into production, I change the directive to /undefine so that the logging code does not run in production.

    C     TAG01         TAG
     /if defined(LoggingIsOn)
       JobLog ('> TAG TAG01');
     /endif
    
    C                   exsr      CalcDiscount
    (. . . more code . . .)
    C     CalcDiscount  begsr
    
     /if defined(LoggingIsOn)
       JobLog ('> Enter CalcDiscount. Policy=/' + Policy +
                                 '/ GrossAmt=/' + %char(GrossAmt) + '/');
     /endif
    
    (. . . more code . . .)
    
     /if defined(LoggingIsOn)
       JobLog ('> Leave CalcDiscount. Discount=/' + %char(Discount) + '/');
     /endif
    
    C                   endsr
    

    It is a good to log the tags. Spaghetti code is hard to follow, and logging the tags helps greatly to understand program flow.

    You may or may not want to log the entrance to or exit from a subprocedure or a subroutine. In this example, I report that the subroutine to calculate discounts ran, and I log the value of the gross amount and the policy used to calculate the discount. I always surround values with some character, usually a slash or a quotation mark, in case there are embedded blanks of significance in a value.

    The leading greater-than signs are not necessary and are only there to make the messages stand out in the job.

    To write to the job log, I created a wrapper over Qp0zLprintf. The JobLog subprocedure takes care of the messy details, such as passing a string by pointer and appending a line-feed character to the message.

    /if defined(LoggingIsOn)
       dcl-proc JobLog;
    
          dcl-pi JobLog;
                  inMessage  varchar(132)    const;
          end-pi JobLog;
    
       dcl-pr  Qp0zLprintf   int(10)  extproc('Qp0zLprintf');
                  inMessage  pointer  options(*string: *nopass) value;
       end-pr  Qp0zLprintf;
    
       dcl-c  EOL           const(x'25');
    
       Qp0zLprintf (%trimr(inMessage) + EOL);
    
       end-proc JobLog;
     /endif
    

    When I ran this example, the job log had these messages:

    > TAG TAG01 
    > Enter CalcDiscount. Policy=/A/ GrossAmt=/499.49/
    > Leave CalcDiscount. Discount=/24.95/ 
    

    I have two good ways to follow program flow and determine why a program did what it did — the JobLog subprocedure and my trace routines. Both save me a lot of time so that I can do the really important things in life, none of which have anything to do with computers.

    RELATED STORIES

    Tracing Routines Explain Why The Computer Did What It Did

    Beefing Up The Job Log

    An Introduction To Logging For Programmers

    How Logging Made Me A Better Developer

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags: Tags: 400guru, FHG, Four Hundred Guru, IBM i

    Sponsored by
    DRV Tech

    Get More Out of Your IBM i

    With soaring costs, operational data is more critical than ever. IBM shops need faster, easier ways to distribute IBM applications-based data to users more efficiently, no matter where they are.

    The Problem:

    For Users, IBM Data Can Be Difficult to Get To

    IBM Applications generate reports as spooled files, originally designed to be printed. Often those reports are packed together with so much data it makes them difficult to read. Add to that hardcopy is a pain to distribute. User-friendly formats like Excel and PDF are better, offering sorting, searching, and easy portability but getting IBM reports into these formats can be tricky without the right tools.

    The Solution:

    IBM i Reports can easily be converted to easy to read and share formats like Excel and PDF and Delivered by Email

    Converting IBM i, iSeries, and AS400 reports into Excel and PDF is now a lot easier with SpoolFlex software by DRV Tech.  If you or your users are still doing this manually, think how much time is wasted dragging and reformatting to make a report readable. How much time would be saved if they were automatically formatted correctly and delivered to one or multiple recipients.

    SpoolFlex converts spooled files to Excel and PDF, automatically emailing them, and saving copies to network shared folders. SpoolFlex converts complex reports to Excel, removing unwanted headers, splitting large reports out for individual recipients, and delivering to users whether they are at the office or working from home.

    Watch our 2-minute video and see DRV’s powerful SpoolFlex software can solve your file conversion challenges.

    Watch Video

    DRV Tech

    www.drvtech.com

    866.378.3366

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    As I See It: Just Bag IT CIO Summit Brings Execs Up To Speed On IBM i

    Leave a Reply Cancel reply

TFH Volume: 28 Issue: 52

This Issue Sponsored By

  • ProData Computer Services
  • Computer Keyes
  • RPG & DB2 Summit
  • Manta Technologies
  • LUG

Table of Contents

  • Big Blue Moves Up Technology Refreshes For IBM i
  • CIO Summit Brings Execs Up To Speed On IBM i
  • Guru: Beefing Up The Job Log, Take Two
  • As I See It: Just Bag IT
  • IBM i PTF Guide, Volume 20, Number 30

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • FAX/400 And CICS For i Are Dead. What Will IBM Kill Next?
  • Fresche Overhauls X-Analysis With Web UI, AI Smarts
  • Is It Time To Add The Rust Programming Language To IBM i?
  • Is IBM Going To Raise Prices On Power10 Expert Care?
  • IBM i PTF Guide, Volume 27, Number 20
  • POWERUp 2025 –Your Source For IBM i 7.6 Information
  • Maxava Consulting Services Does More Than HA/DR Project Management – A Lot More
  • Guru: Creating An SQL Stored Procedure That Returns A Result Set
  • As I See It: At Any Cost
  • IBM i PTF Guide, Volume 27, Number 19

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2025 IT Jungle