|
> -----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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.