Not everyone will see it that way, of course, but I thought I’d throw that out there

But then, he would have to go up there to see what the other fields looked like anyway, so why would that be a problem? One data structure. one calculation line, and we’re done.

Thanks a lot.

Perhaps I didn’t think of the %editw BIF as effectively making it a string issue. I’ve been a little gun-shy of the EVAL statement ever since I first attempted to multiply a number by another (using EVAL) to create a number that would overflow and truncate the high end digits (as with the famous “magic number” method of flipping dates), and got a runtime error.

I was, of course, aware of the possibility of creating a subprocedure in a service program, but when it came to creating a subprocedure or an inline calculation, it really didn’t make any difference. In either case, the nested BIFs would be ugly - even if I was the only one that knew it.

Again, thanks for reading and responding.

Programmers from other languages (like C) will find the data structure example fairly easy, although using QUALIFIED will help that even more. People from a pure RPG II environment might have an easier time with the explicit %subst()

For the record, I am an RPG II programmer, System/3. I don’t have much of a problem with the newer stuff in general. MOVE almost always had some head scratcher. A simple mis-definition of either the source or target and something odd would occur. And that old code was loaded with MOVE and MOVELs. Variables were defined wherever and looking up the definition of the variables involved invariably meant having a printed copy of the compiler listing handy (cross reference at the bottom.)

Of course, I’m talking about maintenance. Writing new code wasn’t nearly as stressful because one keeps all the variables straight. But walking into someone else’s code… I can’t tell you how many times I scratched out the variables on scrap paper as I tried to decipher MOVE-laden code.

Kudos for doing this blog. There aren’t any other RPG programmers doing what you do, and I hope this spurs discussion about the peculiarities of our craft. My comments are not intended as a criticism; my opinion is only one among many, and I have learnt much by being exposed to others - like yours.

H DFTACTGRP(*NO) ACTGRP(’QILE’)

d ds
d BACTNO 11 0
d ACC6 6 overlay(bactno: 6)
d ACC_co 2 overlay(bactno: 6)
d ACC_maj 3 overlay(bactno:
d ACC_min 1 overlay(bactno: 11)

d formatted S 8 INZ

C/FREE
eval bactno = 99999012345;

// explicit movement of data elements
eval formatted = %subst(acc6: 1: 2) +
‘-’ +
%subst(acc6: 3: 3) +
‘-’ +
%subst(acc6: 6: 1);
dsply formatted;

// implicit movement of data elements
eval formatted = acc_co +
‘-’ +
acc_maj +
‘-’ +
acc_min;
dsply formatted;

/END-FREE
C EVAL *INLR= *ON

EVALR ACC6 = %EDITW(%DEC(%SUBST(%EDITC(BACTNO:’X'):6:6):6:0):ACCW);

I suggest:

D ACCW C ‘ 0 - - ‘

EvalR = %EditW(BActNo:ACCW);

Using the EvalR will truncate the leading 5 numbers anyway.

Secondly, when you do encounter a nasty situation like your original nested BIF’s, wrap it in a subprocedure in a service program and no one will have to know exactly how it works. That’s the whole point behind “Modern” RPG.

As for replacing us geezers, I fear the answer is going to be a canned package on commodity hardware.

Today I use RPG IV, free-form, BIFs, multi-language (C, RPG) ILE service programs and many hundreds of APIs.

I agree with the general thesis but disagree on the cause. I believe that the midrange habit of being exposed to one language (RPG) is the cause. Lack of formal computer education might be considered a contributing factor…