|
midrange.com
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
Aside from readability, I tend to ignore any characters that are not in the
alphabet in field names - It can cause loads of confusion if you develop in
a multi lingual environment. They sometimes translate in different code
pages to invalid characters.
So I avoid them for compilability!
Cheers,
Martin
> -----Original Message-----
> From: Bob Cozzi (RPGIV) [SMTP:cozzi@rpgiv.com]
> Sent: 19 March 2002 14:40
> To: rpg400-l@midrange.com
> Subject: RE: Defining a function key...
>
> Interesting all this talk about "readability" and then I see # @ symbols
> used in field names.
> I guess this is sort of what Hans said a while ago, (and I paraphrase)
> "The best technique is the one the developer knows best."
>
> Bob Cozzi
> cozzi@rpgiv.com
> Visit the on-line Midrange Developer forum at: http://www.rpgiv.com
>
>
> > -----Original Message-----
> > From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]
> On
> > Behalf Of dmosley@dancik.com
> > Sent: Tuesday, March 19, 2002 7:42 AM
> > To: rpg400-l@midrange.com
> > Subject: RE: Defining a function key...
> >
> >
> > Just curious, but doesn't anybody else RENAME their indicators.
> > Forget all that AID stuff, and even the *INKx stuff.
> >
> > * -- Indicators...
> > d ind@ptr s * inz(%addr(*in))
> > d indicators ds 99 based(ind@ptr)
> > * ---- 01 - 29 : Functions Key indicators...
> > d f3@exit n overlay(indicators:03)
> > d f6@cancel n overlay(indicators:06)
> > d f7@exit n overlay(indicators:07)
> > d f12@cancel n overlay(indicators:12)
> > d pagedown n overlay(indicators:25)
> > d help@key n overlay(indicators:29)
> >
> >
> > To me it makes the code more legible to read, IF F3@EXIT, or IF
> > F3@EXIT = YES.
> > I was also told to make your code as simple as possible. Not for you,
> but
> > for the poor slob that has to come in behind you, and read your code.
> >
> >
> >
> > David L. Mosley, Jr.
> > Systems Analyst
> > 2000 CentreGreen Way
> > Suite 250
> > Cary, NC 27513
> >
> >
> >
> > "Nicolay, Paul"
> > <paul_nicolay@mer To:
> "'rpg400-l@midrange.com'"
> > <rpg400-l@midrange.com>
> > ck.com> cc:
> > Sent by: Subject: RE: Defining
> a
> > function key...
> > rpg400-l-admin@mi
> > drange.com
> >
> >
> > 03/19/02 08:32 AM
> > Please respond to
> > rpg400-l
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > I don't understand the comments about the AID byte in the mail
> > below...EASILY versus GREAT DEAL more complicated ?
> >
> > Anyway, I guess the basic goal for programming should be the creation
> of
> > readable programs to improve maintenance. In that context I don't see
> why
> > people vote for obscure things like *INKG ?
> >
> > I doubt anybody can argue that it is easier than a test like
> >
> > If #Key = #F7
> >
> > While all the necessary pre-requisites for this can be stored in a
> > copymember, I don't see the point why this should be a GREAT DEAL more
> > complicated ?
> >
> > Hopefully the end result is always the same, but this is no reason to
> > create
> > obscure coding styles (after so many years, I at least, still need to
> count
> > on my keyboard before I know which function key was targeted).
> >
> > Kind regards,
> > Paul
> >
> > -----Original Message-----
> > From: MWalter@hanoverwire.com [mailto:MWalter@hanoverwire.com]
> > Sent: 19 March, 2002 14:21
> > To: rpg400-l@midrange.com
> > Subject: Re: Defining a function key...
> >
> >
> >
> > Ditto!!
> >
> >
> > Thanks,
> >
> > Mark
> >
> >
> > Mark Walter
> > Sr. Programmer/Analyst
> > Hanover Wire Cloth a div of CCX, Inc.
> > mwalter@hanoverwire.com
> > http://www.hanoverwire.com
> > 717.637.3795 Ext.3040
> >
> >
> >
> > The TrekTeam
> > <trekteam@pacbell To:
> rpg400-l@midrange.com
> > .net> cc:
> > Sent by: Subject: Defining a
> > function key...
> > rpg400-l-admin@mi
> > drange.com
> >
> >
> > 03/18/02 07:21 PM
> > Please respond to
> > rpg400-l
> >
> >
> >
> >
> >
> >
> > My vote, (are we voting?) goes to the *InK_ indicators...
> > No setup, no external definitions "CF07(07)" ???
> > And my code lines always have a comment, not only to reveal the
> actual,
> > numbered function key but what it does...
> > If *InKG
> > F7=Print Screen (<== This is just second nature)
> > .....
> > EndIf
> >
> > Capt.j
> >
> > ----- Original Message -----
> > From: "Scott Klement" <klemscot@klements.com>
> > To: <rpg400-l@midrange.com>
> > Sent: Monday, March 18, 2002 6:35 PM
> > Subject: Re: Window format clearing the remainder of the screen
> >
> >
> > >
> > > Sigh... not the "*INKC vs *IN03" holy war, again.
> > >
> > > a) *INKx is simple and to the point. KA=F1, KB=F2, etc. Not hard
> > > at all to figure out. And it's immediately obvious what the
> > > programmer is doing. Yes, it would've been nice if they were
> > > called "*INK1 - *INK24", but they were limited to 2-digit
> > > names. Yes, it would've been nice if they didn't arbitrarily
> > > skip over *INKO. But, even with these complications, it takes
> > > 5 minutes to learn.
> > >
> > > b) *IN01, *IN02... Yes, it's easy to figure out what these are when
> > > things are working, but there's an added step when things
> aren't
> > > working of verifying that *in01 is used for F1 and only for
> F1,
> > > and the same for *IN02-*IN24. Is that difficult? No. But
> it's
> > > one step of complication above *INKx, and provides very little
> > > benefit. (Unless the idea of C being the 3rd letter of the
> > > alphabet confuses you)
> > >
> > > c) AID bytes. This is EASILY more complicated than the two steps
> > > above combined. It works great. And it lets you use nicely
> > > named words like "KEY_F1" to represent your function keys.
> > > But... it's a GREAT DEAL more complicated than the indicator
> > > approach, and the end result is EXACTLY THE SAME. What ever
> > > happened to "K.I.S.S."?
> > >
> > > Frankly, Simon, I find your tone frustrating. Apparently in order
> for
> > > my programming standard to be "decent" it has to follow your flawed
> > logic.
> > >
> > > I'm not an "ancient" RPG programmer. I'm way beyond the curve when
> it
> > > comes to modern coding. Activation groups are 2nd nature to me. I
> use
> > > APIs every day. I do network coding. Stream file coding. My
> shop,
> > > unlike most, has been coding RPG IV since 1996. I'm NOT a
> dinosaur.
> > >
> > > (Though, frankly, I think "out of date" whenever I see a CASEQ in a
> > > program, or code that's in all caps, or subroutine names that are
> > > unnecessarily abbreviated to 6 chars long.)
> > >
> > > I use the *INKx indicators because they are THE MOST INTUITIVE OF
> THE
> > > OPTIONS AVAILABLE, not because I'm ancient. I just dont see how
> you
> > > could POSSIBLY be confused by the *INKx indicators.
> > >
> > >
> > > On Tue, 19 Mar 2002, Simon Coulter wrote:
> > > >
> > > > While use of the *INKx indicators could be classed as a style
> issue I
> > > > think they should be avoided. Quickly, what is key *INKM - don't
> count
> > on
> > > > your fingers, sorry you took too long. Compare that with what key
> is
> > > > *IN13 -- instant knowledge! (presumming decent coding standards).
> > > >
> > > > Using the *IN01 to *IN24 indicators for the F-keys and *IN25 to
> *IN31
> > for
> > > > the remaining engraved keys (HOME, ROLLUP, HELP, etc.) is better
> than
> > the
> > > > *INKx rubbish.
> > > >
> > > > Better still is to use the AID byte found at position 369 in the
> > display
> > > > file feedback data structure. Each AID key (read as a key that
> sends a
> > > > response to the host) has a defined value -- documented in either
> the
> > DDS
> > > > Reference or the Data Management Guide (I forget now, I sorted
> this
> > > > technique out decades ago). Here are the F-spec and D-spec
> > definitions.
> > > >
> > > > FDSPF CF E WORKSTN INFDS(DSPDS)
> > > >
> > > > DDSPDS DS
> > > > D cfKey 369 369
> > > >
> > > > Then you can write C-specs that look like (RPG III but that's what
> I
> > had
> > > > to hand):
> > > >
> > > > * Handle user action
> > > > C $F03 CASEQCFKEY ENDPGM Clean up
> > > > C $F05 CASEQCFKEY REFRSH Refresh
> display
> > > > C $F06 CASEQCFKEY CREATE Create
> object
> > > > C $F09 CASEQCFKEY RTVCMD Retrieve
> command
> > > > C $F10 CASEQCFKEY CMDENT Command
> entry
> > > > C $F11 CASEQCFKEY ALTVW Alternate
> view
> > > > C $F12 CASEQCFKEY ENDPGM Clean up
> > > > C $F17 CASEQCFKEY SRTLST Sort list
> > > > C $F23 CASEQCFKEY NXTOPT Next
> options
> > > > C $F24 CASEQCFKEY NXTKEY Next F-keys
> > > > C $ROLUP CASEQCFKEY BLDSFL Next SFL
> page
> > > > C $CLEAR CASEQCFKEY DUMP Dump
> program
> > > > C $F04 CASEQCFKEY PROCES Process
> options
> > > > C $ENTER CASEQCFKEY PROCES Process
> options
> > > > C CAS BADKEY Invalid
> F-key
> > > > C ENDCS
> > > >
> > > > which to my mind is much clearer than either of the *INKx or *INnn
> > forms.
> > > > Note that named indicator support in RPG IV means you could
> accomplish
> > > > similar code clarity by using an indicator data structure which
> would
> > be
> > > > an acceptable alternative to the AID byte.
> > > >
> > > > Only ancient RPG programmers know what *INKx indicators are and
> even
> > they
> > > > need to translate them once they get past *INKF or *INKG. They
> are
> > > > obscure, indirect, and should be avoided.
> > > >
> > >
> > > _______________________________________________
> > > This is the RPG programming on the AS400 / iSeries (RPG400-L)
> mailing
> > list
> > > To post a message email: RPG400-L@midrange.com
> > > To subscribe, unsubscribe, or change list options,
> > > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> > > or email: RPG400-L-request@midrange.com
> > > Before posting, please take a moment to review the archives
> > > at http://archive.midrange.com/rpg400-l.
> > >
> >
> > _______________________________________________
> > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
> list
> > To post a message email: RPG400-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> > or email: RPG400-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> >
> >
> >
> >
> >
> > _______________________________________________
> > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
> list
> > To post a message email: RPG400-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> > or email: RPG400-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> >
> >
> > _______________________________________________
> > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
> list
> > To post a message email: RPG400-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> > or email: RPG400-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> >
> >
> >
> >
> > _______________________________________________
> > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
> list
> > To post a message email: RPG400-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> > or email: RPG400-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
>
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.
