Re: Defining a function key...

Scott,

>   I partially agree with you.   I agree that IBM could've used a better
>naming scheme than they did.

Like what?  I first used the Kx indicators in RPG II on the S/32 in conjunction
with KEYBORD files.  (I don't recall them on any S/3 model; even the 15D.)

Given the constraints of RPG II syntax, the Kx series seems as good as any other
choice, except for the hare brained idea to skip KO.

>I can't imagine that you have trouble remembering that *INKC is F3, but
>have no trouble remembering that x'33' is the AID byte for F3.   Or
>that the AID byte can be found in position 369 of the INFDS.

The difference is that nobody has to remember the AID byte constants or the
INFDS status values or where they exist in the INFDS.  One simple copy member
and you have a complete INFDS with meaningful names, and named constants for
interesting values like AID codes.  So all you have to remember is to include
the member and name the INFDS on the F-spec.  However, since most people
(especailly beginners) start by cloning a similar program, that tends to happen
by default.

>If I bring in a new programmer, who has never used EITHER METHOD, and
>I have to teach him this piece of code:

This can only happen one time per programmer -- after that he's used at least
one of them. <g>

>     c                   if        *inkc = *on
>The *INKC part isn't where he's going to struggle.   He'll understand when
>I tell him that KC = F3.   He'll accept that.   He'll think it's pretty
>simple -- just check *INKC to find out if F3 was pressed.

It may be "pretty simple", but *IMHO* is not as "readable" as:

>     c                   if        dsFuncKey = KEY_F3

and its ilk.  Aside from readability (a subjective preference), there were two
things I disliked about the Kx indicators back under RPG II:

  1) No equivalent indicators for Enter, Roll/Page, Print, Help, Home, etc

  2) In RPG II, unless the Workstn file was a Combined Primary file (using the
cycle) instead of a Combined Demand file, the Kn indicators were not
automagically set off prior to the next READ (there was no EXFMT).  So you had
to add lines like:

     C                     SETOF                     KAKBKC
     C                     SETOF                     KDKEKF
     C                     SETOF                     KGKHKI

etc.  Worse, it was common to only set off those indicators you thought might be
on from any previous code.  Then during maintenance, some programmer decides to
enable a new Cmd/Fx key and changes the display format but does *not* add it to
the list of indicators reset prior to each READ.  That sets you up to have *more
than one* Kx indicator on at the same time!  Or to still have Kx on even when
Enter is pressed.

Thankfully, RPG III and IV set off Kx indicators as part of the move fields
logic of a READ or EXFMT, so it is a non-issue today.  Its another "obscure"
quirk of RPG II which I don't miss -- much like the failure of Demand file READ
operations to implicity reset the EOF indicator.

It lead to plenty of SETOF statements in legacy code which seem superflous when
spotted in code now, but were sure important at the time.

>     c                   if        dsFuncKey = KEY_F3

>Because of the nice name you gave to the value x'33', it's a lot easier
>to read.   But it's still obscure.  Its still a lot harder to explain to
>a beginner.

I think what is harder to explain to a beginner is why legacy RPG II code uses
both the *STATUS field (for roll/page etc) and also Kx for Cmd/Fx keys.  And why
you had to reset Kx indicators, but not a *STATUS field.  And you still had to
explain the INFDS anyway.

>And...  this type of "using meaningful names" doesn't do anything that you
>couldn't also do with the *INKx indicators!

>     D p_KEY_F3        S               *   inz(%addr(*INKC))
>     D KEY_F3          S              1N

And so what it the equivalent to the above for the Enter key?

>The code is still shorter.  It's still easier to explain to the uninitiated.

You think a pointer variable is easier to explain to the uninitiated then:

     D/Copy WSINFDS

??

>Don't get me wrong.  It's not me who has a hard time figuring these things
>out.  ...  I also get to teach new people how to do these things.  ....   and
>believe me, the *INKx method is MUCH easier to explain.  It's MUCH less 
>obscure.

I take it you are dealing with RPG III and IV code which did not require SETOFs,
and could use DDS indicators for Page etc.

Would you feel the same way if the code you had to explain still had the INFDS
so you could get the *STATUS for Roll/Page, Print, etc but then used Kx for the
"regular" function keys?  Why *STATUS for some and Kx for others?  Why all the
SETOFs?

>So... again... KEEP IT SIMPLE.   Use complex code when you NEED IT, but
>not just to define a simple function key!!

Ironically, that is my argument for *using* the INFDS AID byte and /copy member!

Compared to the RPG II legacy code, the AID byte *is* the KEEP IT SIMPLE method
in my book.  One field tells you exactly what key was pressed -- no checking
both *STATUS and Kx -- and with /copy constants the calcs are very "readable".

YMMV,
Doug