RE: IBM's failure to provide AD tools

> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Buck Calabro
> Sent: Tuesday, November 13, 2001 5:42 PM
> To: 'midrange-l@midrange.com'
> Subject: 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.

a) Lose the "===>" because it makes cut and paste more difficult between C/A
sessions
b) Windoze-style menu option (and shortcut key) to take CL statements in
clipboard and create source member
c) Above turns command entry into a scripting environment (although I'm not
sure precisely what scripting is..;-)
d) The command prompter is part of this interface, and leaves a lot to be
desired
e) Never know, since they took '+++' off top, if enter key will execute a
command
f) DWIM
g) Don't laugh about f).  M$ Word has auto-correct to fix typos, doesn't it?
h) M$ Word is more sophisticated than tools programmers use.
Whazupwitdat...?!?
i) Yada, yada, yada



>
> >I'm looking for tabs for each type of spec.
>
> Code already does intelligent tabbing.

I'm talking Excel-style tab sheets.  One "spreadsheet" per spec, maybe one
for each SR.


>
> >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.

Ya, if you know Java.  I gave up on ReXX in '92.  It might be worth it if
you could learn 10 languages well.  That's impossible.  ReXX would be
towards #10.  Because I already know CL.

If 90% of the user base knows RPG, why not have macro language in RPG?


> How should the macro decide whether to create a global or local variable?

Session defaults that can be over-ridden with a command key.


>
> >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.

I messed that one up.  What I was actually thinking (but not writing) is why
do you need to define fields in DDS, when they're defined in either RPG or
the DB the program is accessing.  Sure, you got reference fields.  Too much
keying.  I don't know how it's implemented in Code Designer, but SDA did not
have a good implementation of reference fields.  (Too many keystrokes,
qualified the field names...)


>
> >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:

Like I said, been about 18 years.  IIRC the label can go on the same line,
but ICBW.  No matter.  There were, in the 1983 version of MI, several
different forms of command structure.  Simple ones had command, factor 1,
factor 2.  More complex ones had commands, and 3 or 4 factors.  About that
time, they were just starting to implement free-form MI with the Compute
Math Function command.

I thought they found an *outstanding* balance between the columnar style and
the free-form style.  The only suggestion I would make is to have the result
field *first* and then the opcode.  Then the factors in columns and/or
free-form code.  So I would code the above code snippet in this proposed
style of RPG C-spec as follows:

LBL/RESULT         OPCODE   FACTOR 1......2......(3......4)
    P_LEN          CMPNV(B) 0/NEQ(SKIPA)
    S_MSGDTA       CPYBLAP  MSGDTAN       ' '
                   B        SKIPB
SKIPA:
    MSGDTAH(11:4)  CPYBLA   A4
    S_MSGDTA       CPYBLAP  MSGDTAH       ' '
SKIPB:

BTW, MI probably has changed significantly in the last 18 years, but then
again I can still understand your snippet.

Note how, if you had an editor ***that was as good as one the average
secretary uses***, you could easily have the capability of shifting the code
to the right of the opcode button, and indent it properly, with one F-key.
And line the opcodes back with by toggling same.  (And you'd have
auto-correct, spell-check, and a host of other features to boot.)

>
> 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

If I wanted to program in anything like BASIC, I wouldn't have chosen
iSeries...;-)  Seriously, nice try, but I'm NOT advocating a return to
something like BASIC.  I don't think BASIC would lend itself to coding
inline MI, like the example above.


>
> >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.

All GREAT enhancements, BTW.  But they ignore the point.


>
> Losses: Columns moved around, Fewer places for indicators.

No loss to me.

But you stopped short, very short IMHO, in finding things that were useful,
that were given up by free-form.  Again, columns moved around and fewer
places for indicator don't seem like ANY disadvantage to me.

The column for result fields is one.  I consider that a HUGE loss.  Being
able to define field on C-spec is another.  (Ya... I know the style-guide.
Editor could have taken care of that.)


>
> >>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!)

Not at all.  That's why you can't see what I'm saying.  You ASSUME I prefer
RPGIII style.

I generally use CX exclusively, to take advantage of the enhancements you
mentioned.  And I lose a lot of screen real-estate.  Because the I/O
operations still require factor 1 (unless they've finished the job in V5R1,
of providing BIF for ALL I/O).

Why would you assume I prefer RPGIII?


> 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.

That's not the case, however.  Everyone wants to perceive this as an issue
of me rejecting the advantages that true ILE offers.  I don't.  I see
disadvantages, and I see areas that RPGIII is STILL better than true ILE
RPG.


> 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.)

Now THIS is starting to look like BASIC to me...;-)

This is my intended direction, when I get V5R1 loaded.  Got it last weekend,
but haven't spent any time looking at it yet.  (So my posts will get
shorter...  Do I hear APPLAUSE...?!?  LOL...)

The above coding is still hosed, IMHO though, because you have to set tab
stops to get the same functionality of prompted C-specs.  If I wanted that,
I coulda been using Cobol all these years, which already had this
"advantage".


>
> 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!

I don't get it.  How did DS change things...?

And, IMV, using a compiler cross-reference, even in Code/400, is too slow
and inefficient.  Not so much for coding purposes, but for debugging
purposes.  When I got an irate user and a crapped-out system, I want to find
the problem as quick as possible.  That can often be done by a simple scan
of the result field column.  Saves me going into debug to track the thing,
sometimes.

>
> 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.'

Not from me.  You misperceive that my view is one wanting to go backwards,
to RPGII or RPGIII.  That is the common assumption.  If you don't like the
way RPG is heading, you MUST prefer RPGII or RPGIII.  Not always the case.

Not hardly.


>
> Best regards,
>   Buck

Likewise,

jt