RE: Another RPG Suggestion

[boldt@xxxxxxxxxx]

Rob wrote:
>How would the following be handled?
> D   CustNo        S                7P 2
> D  workCust       S                 A      Like(CustNo)
>
> C                 MOVE      CustNo        WorkCust
>
>CustNo would be 1234567 not 12345.67.
>
>I like the direct method versus the workaround, but I thought
>I'd point out the workaround, (which I am sure you already know).
>
> C                 EVAL      workCust = %editc(CustNo:'Z')
>  * workCust now equals 1234567
>or
> C                 EVAL      workCust = %editc(CustNo:'4')
>  * workCust now equals 12345.67
>
>Those codes are why I still have a cutout of output spec coding
>sheet taped to my wall.

Here's another way of doing things.  I know it's not perfect,
but it's one more thing to add to your bag of tricks.  (Works
only on V4R4, though.)

---------------------------------------------------------------------
D                 ds
D  workCust
D     CustNo                     7s 2 inz(12345.67) overlay(workCust)

C     workCust      dsply
C                   eval      *inlr = *on
---------------------------------------------------------------------

In this case, "workCust" is defined as character with the
same length as field "CustNo".  You would still have a
problem, though, if you wanted to define "CustNo" like a
packed field.  *LIKE DEFINE would define the subfield as
zoned numeric, but D-Spec keyword LIKE (the preferred
method) defines numeric subfields the same as the like
field.

I agree that we should somehow have some more flexibility
in defining internal format in these cases, but I'm not
sure I like the idea of allowing changing the data type.
You can get implicit definition of char subfields today
(in V4R4) based on the lengths of overlaying fields, and
I don't really see the need for anything more substantial.

I just checked the results of our last enhancement poll.
"Format change on like define" placed 20th out of 29 items.
In all of the scenarios provided, the requirement seems to
be the numeric <-> character conversion process.  As Rob
points out, we have BIF %EDITC for numeric to char.  One
item that ranked higher in the poll was new BIFs for the
char to numeric conversion (so you don't have to use "C"
functions such as "atol").  Other more awkward cases of
conversion can be handled using subfields.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *