Re: Change printer -- RPG400-L

I prefer SYSTEM() but only because I don't have to tell how many
characters.


With the way I program, system() requires *extra* work!

I make every effort to write error-free programs, but even so, errorsoccur. I always make it my business to make sure that when an erroroccurs, it's as easy as possible to troubleshoot and fix the problem --the point at which the user is the most frustrated is when an erroroccurs, and if I can't find and solve his errors, I look bad.


Consider the following code:

     H DFTACTGRP(*NO) BNDDIR('QC2LE')

     D system          PR            10I 0 extproc('system')
     D   command                       *   value options(*string)

      /free

          system('CPYF . . .');

I'm assuming that my CPYF will always work. Always. Except whensomething stops it from working :) You know what I mean? I don't want tocode for a condition where it'll fail, because I want to be as productiveas possible. But, I don't want to do what I did above and simply ignoreany errors and proceed, either! If that CPYF fails, I want to know aboutit, and I want to know WHY it failed so that I can fix the user's problem.So I have to code the following, at a bare minimum:


     H DFTACTGRP(*NO) BNDDIR('QC2LE')

     D system          PR            10I 0 extproc('system')
     D   command                       *   value options(*string)

     D systemErr       s              7A   import('_EXCP_MSGID')
     D wait            s              1A
     D errMsg          s             50A

      /free

           if system('CPYF . . .') <> 0;
               errMsg = systemErr + ' when running CPYF command!';
               dsply errMsg '' wait;
               *inlr = *on;
               return;
           endif;

       /end-free

Actually, in a production program I wouldn't use DSPLY, I'd call theQMHSNDPM API to end the program with an *ESCAPE message so my caller wouldknow that if failed, too... but even if I cut corners and used DSPLY (asabove) I've still added a significant amount of code to my program.

Even with that extra code, when the error occurs, all I'd get is a msgidlike CPF0006 (or whatever) and I'd then have to look up that message ID tosee what the problem is. If there are any fill-in fields in the msgid, Iwouldn't know what they are. I'd probably have to try to re-create theproblem on my own machine to get enough information to help the user.

The user himself would NEVER figure out the problem from the message"CPF0006 when running CPYF command!"


On the other hand, I could use QCMDEXC.  For example:

     D QCMDEXC         PR                  ExtPgm('QCMDEXC')
     D   command                  32702A   const options(*varsize)
     D   len                         15P 5 const

     D cmd             s            200A   varying

      /free

          cmd = 'CPYF . . . ';
          QCMDEXC(cmd: %len(cmd));

          *inlr = *on;
      /end-free

What I did was put the command in a VARYING variable and then used %LEN()to determine it's length so that I don't have to count the characters.Yes, that's one extra line of code over using system()! However, if theQCMDEXC call fails, my program receives and exception message and stopsprocessing! That saves me having to code a routine to detect the errorand display it. Furthermore, all of the error information is in the joblog. It won't just be the msgid, but it'll be the exact details of theerror.

There's a good chance that a more advanced user or system operator typeperson will be able to look at the job log and solve the problem from theinformation there. If not, he'll have the option to dump the program,which gives me additional diagnostics, plus I can look at the job log foreven more diagnostics.


All in less code than it took to call system()!

If you want QCMDEXC to work like system() where it counts the charactersfor you and returns a success/fail indicator, you can easily stick it in asubprocedure and add a few lines of code to make it work like system().(but with full job log information).

I have to admit, I see people suggest system() as an "easier" alterativequite often, and I really wonder if they're thinking it all the waythrough.