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, email@example.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: firstname.lastname@example.org * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.