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