×

Good News Everybody!

The new search engine is LIVE!

Please report any problems to david (at) 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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 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.