RE: Procedure Problem -- RPG400-L

Sorry Jon, I have to agree with Alan too. The less the user has to know
about using the procedure, the better it is. Now that I think about it, why
does QCMDEXC force you to give the length of the command?

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Alan Campin
Sent: Wednesday, December 22, 1999 2:15 PM
To: 'RPG400-L@midrange.com'
Subject: RE: Procedure Problem


>> Personally I'd pass the length of the output field to the procedure using
%Size.

Would disagree with you there, Jon. I studiously avoid use of passing the
length of the string, especially when writing service program. Including
that parm means that I am forcing the user of the function to understand how
the function works instead of just calling the function. It takes some more
work but I have a cleaner implementation. The whole idea as I see it in
building a function is to completely hide how it works. Passing the string
length means I am asking the user to do part of the work or, at least, that
is my opinion and we know what those are worth <g>.

-----Original Message-----
From: Jon.Paris@halinfo.it [mailto:Jon.Paris@halinfo.it]
Sent: Tuesday, December 21, 1999 9:32 AM
To: RPG400-L@midrange.com
Subject: Re: Procedure Problem




 >> Second, you could simply remove the options(*varsize) from your
prototype/interface.  What good is it really doing you?


The benefit of Varsize is that a generic routine such as the "Center" one
here
can accept any length of parameter from 1 to 256 characters.  Get rid of
Varsize
and the parm always has to be 256 long.

 >> Third, if you do want to use options(*varsize) you could use an
operational
descriptor to get the string length, and then make sure that you only
reference
that length of data...

While you could use descriptors they are a pain in the  backside to
implement
and (since the implementation is far from complete - e.g. numerics aren't
supported) have very limited utility.  Personally I'd pass the length of the
output field to the procedure using %Size.

Also this is a good use for varying length fields together with the keyword
CONST or VALUE - this would avoid having to pass the length of the input
parm.

C* test the center sub-proc
c                   eval      dsshpnm = 'CENTER ME'
c                   eval      output = Center(%TrimR(dsshpnm):%Size(Output))
c                   dsply                   output           35

c                   eval      *inlr = *on


P*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
P*     routine to center text
P*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
P Center          B
D Center          PI           256A
D   InString                   256A   Const Varying
D   OutLen                       3P 0 Const


One other comment to the original writer.  Why are the Overlay keywords
being
used in the ShipToDS ?  They serve no purpose and can be completely omitted
with
no resulting change in layout as far as I can see.  I would also recommend
the
use of the LIKE keyword to define the subfields (or for that matter have the
ShipTo stuff as an externally described ds) this avoids any chance of the
thing
being screwed up by differing lengths in the subproc and the mainline that
invokes it.


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

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