× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: how to let my program sleep a while
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Sun, 17 Sep 2000 12:51:21 -0500 (CDT)


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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.