RE: IBM's failure to provide AD tools

>I'm talking about the fact that the Command Entry
>display has not been enhanced.  I don't recall any
>(ICBW) since it was released with the AS/400
>in '88.  No interface is THAT good, that it couldn't
>see significant enhancements in 13 years.

I can't imagine how to "enhance" an entry line, but I guess I'm just not
that imaginative.

>I'm looking for tabs for each type of spec.

Code already does intelligent tabbing.

>a few example of what I mean by "integrated sufficiently".
>I'm looking for Code/400 to take a field
>defined on a C-spec, and create a D-spec automatically.

That's probably a good place to write a Code macro, either in ReXX or Java.
How should the macro decide whether to create a global or local variable?

>I can't imagine why I have to define a field length
>on DDS, and then define it again in RPG.

When does that need to happen?  Once defined in DDS it's defined in RPG too.

>The primary advantage of free-form is that this is
>where the compiler enhancements are going, more
>than it being inherently superior, in all respects,
>to the old-style code.

If I CVTRPGSRC and re-compile, I find an average 10% speed increase.  That
alone is good enough reason to switch to the new format even if I never
write a line of free-form code.  More on that below.

>I'm talking about the columnar format of MI.
>I'm talking about result-field column on the
>left; opcode column next; followed by either
>factors 1 and 2 or free-form.  It's the layout
>I prefer, because it DOES combine the best
>of both worlds.

Here's some MI.  It does not fit your definition above.
CMPNV(B) P_LEN,0/NEQ(SKIPA);
CPYBLAP S_MSGDTA,MSGDTAN,' ';
B  SKIPB;
SKIPA:
CPYBLA MSGDTAH(11:4),A4;
CPYBLAP S_MSGDTA,MSGDTAH,' ';
SKIPB:

That doesn't invalidate your preference, which looks suspiciously more like
BASIC than any variant of RPG:
100 $LAST = FUNCX$($FULLNAME)

C                   MOVEL     FULLNAME      LAST

>Now according to many, a columnar approach is
>archaic and "bad code".  But according to many,
>it is one of the strengths of RPG, and a strength
>that is found in few other languages.

and

>I've always felt that RPG coders that wanted
>long names and free-form should just program
>in C or even more, Cobol.  Instead, RPG took
>on aspects of these languages.  I'm not against
>that, so much as the fact that (IMV) some of
>the primary benefits were sacrificed.

I'm trying to compile a list of enhancements gained vs. primary benefits
lost.

Enhancements: BIFs, Long names, Mixed case, Pointers,
Date/Time/Integer/Float datatypes, Subprocedures, Service programs.

Losses: Columns moved around, Fewer places for indicators.

>>Don't like free form?  Don't use it!  It's real simple.
>
>Again, very ineffective to use the old-style.  It's not
>getting any enhancements.

It's ineffective to use RPG III style, yet you prefer to use RPG III style
over the extended factor 2 style?  (I hope I got that right!)  If that's the
case, take a long look at free-form combined with procedures and a good
naming convention to set up a custom (all your own) source formatting style.
You can then combine the enhancements of RPG IV and still make the code look
the way you're most comfortable.

Think about using free-form coding to do exactly what you want.
c/free
  if                %parms > 1;
         decPoint = %subst(decComma : 1 : 1);
         comma    = %subst(decComma : 2 : 1);
  endif;

This puts the result field in the same columns everywhere in your C specs.
Of course, that doesn't help you find the I or O specs (don't think O specs
can modify variables?  Think Blank-After.)

Personally, I haven't been able to depend on column scanning since data
structures.  The One True Way to find where variables are modified is the
compiler cross reference.  Now THAT I'd love to see externalised!

To end my one and only post on the topic of AD tools, I'd like to add only
that I heard very similar complaints about Auto Report and externally
defined files, to wit: 'Not "RPG" enough for my taste.'

Best regards,
  Buck