|
midrange.com
I am glad that you are using the if %null instead of %parms. I was going
to suggest that technique. One of my earliest RPGLE programs uses this
technique because I have many parameters, of which few are rarely
requested. Here's the command that calls the program:
Retrieve Job Description (RTVJOBD)
Type choices, press Enter.
Job Description . . . . . . . . Name
Library . . . . . . . . . . . *LIBL Name, *LIBL
Job queue name . . . . . . . . . 10 A
Job queue library name . . . . . 10 A
Job priority (on JOBQ) . . . . . 2 A
Output priority (on OUTQ) . . . 2 A
Print device . . . . . . . . . . 10 A
Output queue . . . . . . . . . . 10 A
Output queue library . . . . . . 10 A
Text 'description' . . . . . . . 50 A
User . . . . . . . . . . . . . . 10 A
Print text . . . . . . . . . . . 30 A
Accounting code . . . . . . . . 15 A
Routing data . . . . . . . . . . 80 A
Request data or command . . . . 256 A
CL syntax check . . . . . . . . 2,0
Initial library list . . . . . . 275 A
End severity . . . . . . . . . . 2,0
Log level . . . . . . . . . . . 1,0
Log severity . . . . . . . . . . 1,0
Log text . . . . . . . . . . . . 10 A
Log CL program commands . . . . 10 A
Inquiry message reply . . . . . 10 A
Hold on job queue . . . . . . . 10 A
Job date . . . . . . . . . . . . 8 A
Job switches . . . . . . . . . . 8 A
Device recovery action . . . . . 13 A
Time slice end pool . . . . . . 10 A
Job message queye maximum size 5,0
Job message queye full action . 10 A
Allow multiple threads . . . . . 10 A
Job Date, CYYMMDD, C=0=1900 . . 10 A
(of course, we can all spot the V5R1 bug, right?)
I'll be happy to pass this command and program on to the API phobic people
out there who still want to retrieve information from a job description.
Rob Berendt
==================
Remember the Cole!
"ron hawkins"
<hwarangron@home. To: <RPG400-L@midrange.com>
com> cc:
Sent by: Subject: RE: PI to replaced
*Entry PLIST (was Because it's there... )
owner-rpg400-l@mi
drange.com
05/04/01 03:12 PM
Please respond to
RPG400-L
<< The problem you describe sounds like a design issue to me to be honest.
I
<< wouldn't expect to be passing through values that I don't need
personally
<< (if you see what I mean). Maybe I just don't understand exactly what
<< you're trying to do here though.
Jon,
Ultimately, it is a design issue, but the problem is that functions get
added to existing programs. When I designed the program, it accepted a set
number of parameters. Every program that called that program passed that
number of parameters. But then, a new function gets added to that program
thats activated by passing in a new parameter. The %parms testing is used
so
that all other programs that call this program dont have to be changed.
Let's say the new parameter is parameter 3. So far, no problem.
Now, another new fucntion is added to the program, again activated by a
parameter being passed to it (now parameter 4). Any existing programs that
are going to be changed to be able to access the new function have to pass
in 4 parameters. This means they have to pass in parameter 3 even tho they
don't want to activate that function.
This is why the If %addr() <> *NULL check is much more consistant to see if
you really want to use the parameter that was passed. The %parms doesnt
work
because you were forced to pass parameter 3 when all you really wanted was
parameter 4.
Obviously, you can code around this by being aware of the potential problem
using %parms. It just seems safer to use the *OMIT and not having to worry
about anybody coming along later.
I guess part of the problem is that new features are constantly being added
to our package and that our package is very modular in nature. A program
can
easily get called from 10 other programs.
Ron
+---
| 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
+---
+---
| 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.
