Re: CL pgm and pointer variables

Steve Richter wrote:

Data pointers must be more efficient than the equivalent "DecVar =
CvtCharToDec( string )".

"must" - huh?  I suggested previously that the term "efficiency"
does not readily apply to data pointers.

The conversion from unstructured char string to
numeric variable has to be done and will take multiple steps to do it.  The
data pointer is best because it pushes many details below the abstraction
level the appl programmer operates at.

 d dpVar         s         *      dataptr
 d OrderQty      s        9p 2
 d StdInString   s      999a      varying

 dpVar = %SetDataPtr( OrderQty ) ;
 ParseAndExtractFromEnvString( dpVar: 'OrderQty': StdInString ) ;

First, data pointers won't help one bit for conversion of
unstructured character strings to a numeric type. You still need to
use a %DEC or atoll() function. On the other hand, data pointers
could be used in the assignment of numeric values to numeric targets
with precisions unknown at compile time. But since that never
happens in RPG, data pointers are not necessary or even helpful for
that step.

Your example above does not handle a char to numeric conversion error.

Then wrap the assignment in a MONITOR group.

But I
agree, your method is similar to a conversion that uses a data pointer.  The
problem with the non data pointer method is the hard coding of the data defn
of the target variable. My hypothetical:
  dpVar = %SetDataPtr( OrderQty ) ;
is error and database change proof.  Your example requires the pgmr to
correctly type the "7:2" and also find and change all its instances when the
field is expanded to "9:2" at a later date.

btw, rpg programmers too often have to use this method of hard coding of
variable attributes.  Any chance that %DataType(variableName),
%DataLength(variable), %DataPrecision(variable) built ins will be introduced
to rpg?

As I said, when using a compiled language like RPG, the attributes
of the variables are always known at compile-time. And so there
should be little use for querying these attributes at run-time.
Furthermore, there would still be the problem of assigning
attributes to the data pointers, and so you're just shifting the
problem from one place to another.

I agree that there are a couple of quirks in the language regarding
the handling of BIF's like %LEN and %DECPOS, and they're somewhat
annoying when used in conjunction with %DEC. But these quirks are
not insurmountable, just nuisances. (Oh yeah, if you want
"%DataLength(variable)" and "%DataPrecision(variable)" built-in
functions, have a look at %LEN and %DECPOS.)

If you want a more dynamic language, might I recommend Perl or
Python? Those languages might offer the kind of flexibility you
want, but I don't think you'll find any language that combines both
dynamic flexibility and blazingly fast performance.

Cheers!  Hans