Re: how to let my program sleep a while

[jpcarr@xxxxxxxxxxxx]

Scott,

Sorry,  for some reason when I said APIs  I didn't think of/or mean to
include prototyping dynamic calls for some reason. And Yes,  I do alot of
those when appropriate.

With out a doubt, If I wrote in my shop it would have parameters of length
of time to delay, etc.
I thought the person who asked would automatically do that and not leave it
hard coded.

But you bring up a good point,   CLP or QCMDEXEC.    I personally never
liked QCMDEXEC. if you had a problem, the system said,  "You had a problem.
OK?"   ALways reminded me of a PC error message.

Now don't everyone jump on me for the above personal coding sentiment.

CLP's (In the past) along with MONMSG,  always seemed to be more granular
in my control of the logic, adding new things,  trapping errors, etc.

I have found in the last 15 years it to be a pain to enhance systems where
people went wild with QCMDEXC.  Adding new things to the function was
always a pain(changing it from a single command execution to multiple with
program logic) hard coded commands as arrays, named constants, were always
SUCH a dream to find.

I don't know if anyone would say that QCMDEXEC's error trapping was it's
strong point. ( that is without adding more code than the orginal progam,
involving Job Logs, more API's, really lovely stuff)

Prototyping QCMDEXEC is without a doubt the best way to use it though.

Neat looking code Scott.


Respectfully
John Carr
----------------------------------

Hi John,

I disagree with you.  I think your CL program is more complicated, and
I'll illustrate why, below...

On Sun, 17 Sep 2000 jpcarr@TREDEGAR.COM wrote:

> Why make it complicated?   Call a 3 line CLP program to
>
> PGM
> DLYJOB(300)
> ENDPGM
>
> Now don't anyone dare tell me that calling a CLP program is slow when
> the reason for doing it is to delay the job.
>
> I don't think there is an API call that is less code,  easier to
> understand,
> and does the job.
>

It seems silly, and rather awkward, to make a seperate source member just
to do this.  I don't think you can call a QCMDEXC call complicated!

Your "simple" CL program is always delaying the same amount of time, which
makes your code non-reusable, so lets just add simple parms for "RSMTIME"
and "DLY" amounts.

Now, lets compare the "complexity":

RPG Program:
      CALL    MYCLPGM
      PARM    300         MYDLY
      PARM    0           MYRSMTIME

CL Program:
      DCL VAR(&MYDLY) TYPE(*DEC) LEN(5 0)
      DCL VAR(&MYRSMTIME) TYPE(*DEC) LEN(6 0)
      IF  COND(&MYDLY *NE 0) THEN(DO)
             DLYJOB DLY(&MYDLY)
      ENDDO
      ELSE DO
             DLYJOB RSMTIME(&MYRSMTIME)
      ENDDO

A few notes:
      If the CL code is implemented as a module, you need to make sure
      that its compiled seperately, and re-bound to your program each
      time.

      If the code is implemented as a program, you need to make sure that
      its always in the *LIBL when the program is run.  You still need to
      compile it seperately.  When moving this program to/from test
      environments and production enviornments, you have to remember to
      move the silly little CL program.   When installing on someone
      elses machine, you have to remember the CL program.


Now how about the pure RPG approach?
I'm not bothering to use variables for the delay time since Command itself
is a variable, and if a different delay is required, we'd just make a
different "Command" string.

      eval     Command = 'DLYJOB DLY(300)'
      eval     Length = %size(Command)
      CALL     'QCMDEXC'
      PARM                  Command
      PARM                  Length

First of all, its less lines of code.
Its in the same source member.
It doesnt require any additional compilation steps.
No other programs to remember.


Both approaches could be (should be!) prototyped.  But this wouldn't
change the complexity.


D SLEEPCL         PR                  ExtPgm('SLEEPCL')
D   Delay                        5P 0 const
D   RsmTime                      6P 0 const

c                   callp     SLEEPCL(300:0)
Plus the CL program, the extra compile steps, etc as shown above.


D Cmd             PR                  ExtPgm('QCMDEXC')
D   Command                    200A   const
D   Length                      15P 5 const

c                   callp     Cmd('DLYJOB DLY(300)': 200)

Thats it, elegant and simple.

This is also much more self documenting... you can clearly see what its
doing right here without having to read the other source member.  Even if
you didn't have to write a seperate source member or do extra compilation
steps, the QCMDEXC approach is still JUST AS SIMPLE.  As these protyped
examples very clearly illustrate.

>
> John Carr
> PS I love API calls myself.
>

Sorry, John...  didn't mean to pick on you :)


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---