• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Two Handy Programs

    November 16, 2005 Ted Holt

    I get quite a bit of email from readers who say they have found something in Four Hundred Guru to be of help to them. I appreciate their taking time to let me know. Today I present two CL programs that I would be hard-pressed to do without. I hope some of you will find them helpful too.

    Here’s the first one, DUMMY1.

    pgm   
    return
    

    Do you like it? At two lines, it would be hard to make a keying error when typing it in, wouldn’t it? I don’t think it matters what activation group it runs in, but I compile it to run in the caller’s activation group.

    CRTBNDCL PGM(mylib/DUMMY1)        
       SRCFILE(mylib/QCLSRC)
       SRCMBR(DUMMY1) 
       DFTACTGRP(*NO)         
       ACTGRP(*CALLER)
    

    I use DUMMY1 for program testing. Suppose I am modifying a CL program that calls a lot of programs, some of which I do not want to run during testing. Maybe some of the called programs take a long time to run and I only want to test the changed logic in the calling program. Maybe one of the programs does something I don’t want to be done, such as sending a fax. In such cases, I clone DUMMY1 as many times as is necessary, creating the clones in QTEMP or one of my development libraries and giving them the same names as the programs that I do not want to run.

    Suppose the program I am modifying looks like this:

    PGM
    CALL       PGM(SOMEPGM)
    

    But I want it to look like this:

    PGM
    CALL       PGM(SOMEPGM)
    SNDPGMMSG  MSG('Program SOMEPGM completed normally') +
                 MSGTYPE(*COMP)
    

    Program SOMEPGM does not need to run in order for me to verify that the SNDPGMMSG command works properly, so I clone DUMMY1.

    CRTDUPOBJ OBJ(DUMMY1) FROMLIB(MYLIB) OBJTYPE(*PGM) +
              TOLIB(QTEMP) NEWOBJ(SOMEPGM)
    

    When the program I’m testing calls SOMEPGM, it calls the copy in QTEMP, which is always at the top of my library list, rather than the copy in the production library.

    Sometimes I like to know that the dummy program ran, even though it didn’t do anything. In those cases, I prefer to use the second program, which I cleverly call DUMMY2.

    pgm                                                            
                                                                   
    dcl   &MsgKey        *char      4                        
    dcl   &PgmName       *char     10                        
    dcl   &Sender        *char     80                        
                                                                   
    /* Determine the name of this program. */                      
                                                                   
    sndpgmmsg   msg('Dummy message') topgmq(*same) +         
                  msgtype(*info) keyvar(&msgkey)             
    rcvmsg      pgmq(*same) msgtype(*info) msgkey(&MsgKey) + 
                  rmv(*yes) sender(&Sender)                  
    chgvar      var(&PgmName) value(%sst(&Sender 27 10))     
                                                                   
    sndmsg      msg('Program' *bcat &PgmName *bcat +         
                          'is running.') tousr(*requester)         
    endpgm
    

    Like DUMMY1, DUMMY2 does no processing of any kind. However, it does have the courtesy to let me know it’s running. When my clone of DUMMY2 runs, I get a message on my screen: Program SOMEPGM is running.

    Create DUMMY2 according to the compilation instructions for DUMMY1.


    Let me add a couple more comments. First, the programs that these CL programs replace do not have to be CL programs. In the example given above, I did not mention what language SOMEPGM was written in. It didn’t matter.

    Second, testing is an art in itself, and entire books have been written about the subject. Too much software is installed without adequate testing, but fortunately, simple techniques, like the use of do-nothing programs, can make the testing process easier.

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    ARCAD Software

    [Webinar] It’s Time to Move from Legacy Change Management to DevOps on the IBM i

    Are you still relying on change management tools from the 1980s? These legacy solutions—many minimally maintained—are creating bottlenecks in your development process and putting your IBM i modernization goals at risk.

    Join our roundtable webinar where ARCAD’s Technical Consultants share real-world insights on transitioning from outdated tools like Turnover and MKS/Implementer to modern DevOps practices.

    What you’ll discover:

    • How legacy change management limits IBM i capabilities (SQL, ILE, and beyond)
    • The advantage of ARCAD’s highly-optimized bi-directional Git integration
    • Why ARCAD’s repository accelerates development and reduces risk and is called ‘golden’ by users
    • Leveraging AI and VS Code for IBM i development
    • Proven migration strategies and automated workflows

    Whether you’re just starting your DevOps journey or ready to leave legacy tools behind, our experts will show you the path forward to faster, safer, and more efficient development.

    Register Now!

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    IBM Unveils New Midrange Storage Systems QlikTech Targets iSeries Base with Business Intelligence App

    Leave a Reply Cancel reply

Volume 5, Number 43 -- November 16, 2005
THIS ISSUE
SPONSORED BY:

T.L. Ashford
Advanced Systems Concepts
WorksRight Software

Table of Contents

  • API Corner: Backup APIs
  • Two Handy Programs
  • Admin Alert: Darn Good FTP Commands You’ve Probably Never Heard Of

Content archive

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

Recent Posts

  • IBM Starts Winding Down Power10 System Sales
  • Guru: Service Programs And Activation Groups – Design Decisions That Matter
  • Strategic Topics To Think About For 2026, Part 1
  • Shield Gooses Performance Of Nagios Monitoring Tool, Adds AI Reporting
  • IBM i PTF Guide, Volume 28, Number 6
  • Rolling The Die In 2026: IBM i Predictions, Take Two
  • Perhaps 2026 Is The Year For Power Systems To Boom A Little
  • Guru: Binder Source Is Your Service Program’s Owner’s Manual
  • Skills Displaces Cybersecurity As Top Concern For IBM i Shops
  • IBM i PTF Guide, Volume 28, Number 5

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