|
midrange.com
On Tue, 19 Mar 2002, Denis Robitaille wrote:
>
> I am sorry to say this, but if you need a template on your keyboard with
> manual annotation on it, it just gives more argument to those who says
> that this technique is not obvious.
Denis,
I partially agree with you. I agree that IBM could've used a better
naming scheme than they did. However, it's still the easiest way of
the options available to us.
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.
If I bring in a new programmer, who has never used EITHER METHOD, and
I have to teach him this piece of code:
FSCREEN CF E WORKSTN
c exfmt Screen1
c if *inkc = *on
c eval *inlr = *on
c return
c endif
C*.... do something with screen data....
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.
However, if I show him this code:
FSCREEN CF E WORKSTN INFDS(dsScreen)
D dsScreen DS
D dsFuncKey 369 369A
c exfmt Screen1
c if dsFuncKey = x'33'
c eval *inlr = *on
c return
c endif
C*.... do something with screen data....
He's going to be lost. What the heck is an INFDS? Why x'33'? Why
position 369? He'll end up saying "Why is checking F3 so difficult
in RPG? It's not that complicated in any other language!"
But, somehow, some way, people on this list are saying that "*INKx is
obscure". I just can't accept this. You're telling me that defining an
INFDS isn't obscure? Knowing that you have to check position 369 isn't
obscure? knowing that x'33' is F3 isn't obscure?
The primary reason that people use the AID byte is because they can
simply code constants that give more readable meaning to their code.
This makes for (better) code like this:
FSCREEN CF E WORKSTN INFDS(dsScreen)
D KEY_F3 C CONST(x'31')
D dsScreen DS
D dsFuncKey 369 369A
c exfmt Screen1
c if dsFuncKey = KEY_F3
c eval *inlr = *on
c return
c endif
C*.... do something with screen data....
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.
And... this type of "using meaningful names" doesn't do anything that you
couldn't also do with the *INKx indicators!
FSCREEN CF E WORKSTN
D p_KEY_F3 S * inz(%addr(*INKC))
D KEY_F3 S 1N
c exfmt Screen1
c if KEY_F3
c eval *inlr = *on
c return
c endif
C*.... do something with screen data....
The code is still shorter. It's still easier to explain to the
uninitiated.
How about documentation? Try to find the documentation for the *INKx
indicators. It's there, all on one page, in the RPG reference manual.
It takes 2 minutes to find and assimilate that documentation.
Now, lets try to do the same thing with the AID byte. Hmmm... I guess
if I read through the book, I might see the section that tells me that
I can get feedback from a device using the INFDS. Okay, that sounds
promising... Now where in the INFDS?
There are 6 topics that immediately look like possibilities. File
Feedback, Open Feedback, I/O Feedback, Device Feedback, Get Attributes
feedback, file status codes.
So, the new person would probably check Device specific Feedback first,
that seems fairly logical. But after skimming over the manual on that
topic, the only thing it tells me is that the AID byte is in position 369.
He doesn't know he's looking for the AID byte,he just knows he wants to
check an F-key.
So, the new person would probably end up moving on to each of the other
topics, and never really figure it out. So, now maybe someone tells him
that it's the AID byte that he wants. The RPG manual doesn't explain
anything about this byte, but does say that he should read the "Data
Management" manual.
Now, the Data Management manual isn't small. What's called "Device
Specific Feedback" in the RPG manual is actually listed in Appendix A
of this book, as "I/O Feedback Area for ICF and Display Files". The
names aren't really that similar. He goes to that chapter, and
finds a structure that starts with offset 0... so how does he even
know for sure that it's the same structure. Okay, so he eventually
figures that out somehow.
Now, it gives a table of "Function Keys" which lists 1, 2, 3, 4, 5, etc.
and "Hex Codes" of 31, 32, 33, etc. Whew. If he read everything
carefully so far, he'll be able to figure out that the listing for "3"
is actually Function Key 3, or F3. Good. The hex code is 33. Now,
assuming that he knows how to code a hex code in RPG, he can finally
write the code.
So, which way was more obscure?
Don't get me wrong. It's not me who has a hard time figuring these things
out. I've used all of the different methods for YEARS. I've even taken
part in writing a 5250 client, so I'm familiar with the AID byte at a much
lower level than most other RPG programmers.
But, I also get to teach new people how to do these things. I get to
maintain other programmers' work. and believe me, the *INKx method
is MUCH easier to explain. It's MUCH less obscure.
when someone in my shop doesn't understand how something works, they come
to me and ask me two questions. "What does this code do?" and "How could
I have figured that out for myself?" The 2nd question is always the
harder one to answer.
So... again... KEEP IT SIMPLE. Use complex code when you NEED IT, but
not just to define a simple function key!!
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.
