× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. RPG400-L
  3. March 2002

RE: Defining a function key...

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