|
Post by George on Feb 25, 2023 11:11:15 GMT -5
Hi, The latest full release - 2.7.23056 - has been posted on the SPFLite website (WWW.SPFLite.COM)
Enjoy.
George
|
|
|
Post by Robert on Feb 25, 2023 13:39:37 GMT -5
When I first proposed PA1, I researched the matter carefully. It turns out that depending on what software and O/S is running, sometimes PA1 is used to reload the screen, and sometimes it's PA2. Here is one quote"
"The "PA" keys are Program Attention keys, and are defined by whatever program you are running. For example, under TSO, PA1 will interrupt a command, and PA2 will redisplay the current screen. Under SDSF, PA1/2 will both redisplay the screen contents."
Similar remarks apply to MVS consoles, VM sessions, 3270 emulators, and so on.
|
|
|
Post by George on Feb 25, 2023 15:25:20 GMT -5
Not sure what you're telling us. The current ISPF Doc states PA1 is ATTN and PA2 is RESHOW. But yes, different apps can certainly make PA1 and PA2 mean whatever the heck they like, in their own mainframe oriented world, but we're an ISPF clone, so for us PA2 is RESHOW.
|
|
|
Post by Robert on Feb 26, 2023 23:35:50 GMT -5
Your current change log states, "When the (PA1) KB primitive (cancel screen input) was implemented, we created a small Oops! It turns out it should have been called PA2. So PA1 is now deprecated (but will still work). The proper name for the function is now (PA2)"
The Help says, "As long as you press no other keys, you can repeatedly toggle PA2 to go back and forth between the original and the modified version of the screen. If you do this Back-and-forth toggle, the reset line commands will not be restored."
Finally, you say " we're an ISPF clone, so for us PA2 is RESHOW."
What I am telling you is:
- PA1 was my idea, I researched it thoroughly, and the name I chose for it was not an "oops". PA1 is in fact used for 'reshow' though in the IBM world its usage is admittedly a little ambiguous. The implication that I made an "oops" here is not appreciated.
- The SPFLite implementation of this function does not fully adhere to any PA1 or PA2 behavior on a mainframe. The function was a "new creation" that only partially resembles either PA1 or PA2, and could have been called "(Reshow)" for all the difference it would have made.
- The mainframe 3270 behavior of PA1 / PA2 is managed by the VTAM layer underneath TSO and ISPF; you are certainly not a VTAM clone, so the 'clone' issue is irrelevant.
- By changing the name of a function, when no new functionality is being introduced, and no bug was fixed, is a frivolous and unnecessary change, but because you have introduced an alias name for PA1, you have created needless confusion in the users. That confusion is only made worse by declaring PA1 to be "deprecated" adding to the uncertainty. If users now change their keyboard mapping to use PA2 instead and then try to use a down-level version, the PA1/PA2 issue could result in data loss if they pressed the wrong key at the wrong time when a refresh is needed.
I see the PA1 to PA2 function rename as ill-conceived. It was released without any notice or user discussion, which makes it appear like it was a private change decided by you and one of your users. I could be wrong, but that's how it seems.
That's what I am telling you.
|
|
|
Post by Stefan on Feb 27, 2023 9:26:03 GMT -5
Guys, FWIW, I do not see a (PA1) description under Help -> Appendix -> List of Keyboard Primitives for version 23056. Both (PA1) and (PA2) primitives are recognised and appear to differ only in that repeated (PA2) toggles the display when repeated (PA1) doesn't. Leaving aside any arguments over who introduced what, why and when, an official description would be appreciated.
Personally I'd prefer the function to be called (Reshow) rather than (PA2), because that exactly describes the action performed and would also make sense to non-3270-literate users. In fact, I seem to vaguely recall that on some keyboards there was a key labelled as such (but I may also be mistaken!).
I also struggle with (PA1) being thought of as ATTN, given that, after years with TSO, I expect that key to interrupt/terminate an executing function - e.g. a macro loop. I don't think the (PA1) primitive does this.
Robert,
Dare I say, I don't quite understand your vehement defense of the origins of these primitives.
The protective feeling you have towards your "creations" does not appear to stop you taking others' ideas and completely overriding them with your own functional design, something I've noticed several times recently.
|
|
|
Post by George on Feb 27, 2023 10:23:09 GMT -5
Your current change log states, "When the (PA1) KB primitive (cancel screen input) was implemented, we created a small Oops! It turns out it should have been called PA2. So PA1 is now deprecated (but will still work). The proper name for the function is now (PA2)"
The Help says, "As long as you press no other keys, you can repeatedly toggle PA2 to go back and forth between the original and the modified version of the screen. If you do this Back-and-forth toggle, the reset line commands will not be restored."
Finally, you say " we're an ISPF clone, so for us PA2 is RESHOW."
What I am telling you is:
- PA1 was my idea, I researched it thoroughly, and the name I chose for it was not an "oops". PA1 is in fact used for 'reshow' though in the IBM world its usage is admittedly a little ambiguous. The implication that I made an "oops" here is not appreciated.
Robert: Please, stop the sensitivity. I said "WE created an oops", there was no finger pointing at you.
I don't know what research you did (or even why, the concept isn't difficult), but the ISPF User Guide clearly says: - The SPFLite implementation of this function does not fully adhere to any PA1 or PA2 behavior on a mainframe. The function was a "new creation" that only partially resembles either PA1 or PA2, and could have been called "(Reshow)" for all the difference it would have made.
Huh! ?? Since when has that been a comcern? The majority of our Primary commands that mimic the ISPF version have been extended far beyond 'adhering to mainframe behaviour'. Are you suggesting that we should remove all these extensions and get back to being pure ISPF? Of curse not.
- The mainframe 3270 behavior of PA1 / PA2 is managed by the VTAM layer underneath TSO and ISPF; you are certainly not a VTAM clone, so the 'clone' issue is irrelevant.
And as a mainframe programmer who directly programmed 3270 screens (i.e. NOT under ISPF) let me assure you that PA1 and PA2 are returned to the application to handle, it is not a VTAM responsibility, as VTAM has no knowledge of how the application wants to handle them. Introducing VTAM into this discussion is not helpful, just noise.
- By changing the name of a function, when no new functionality is being introduced, and no bug was fixed, is a frivolous and unnecessary change, but because you have introduced an alias name for PA1, you have created needless confusion in the users. That confusion is only made worse by declaring PA1 to be "deprecated" adding to the uncertainty. If users now change their keyboard mapping to use PA2 instead and then try to use a down-level version, the PA1/PA2 issue could result in data loss if they pressed the wrong key at the wrong time when a refresh is needed.
You're blowing this up needlessly to make some kind of point. I'm not sure what, but this is a needless topic. We've removed or changed functions in the past of a lot more impact than this one without the sky falling.
I see the PA1 to PA2 function rename as ill-conceived. It was released without any notice or user discussion, which makes it appear like it was a private change decided by you and one of your users. I could be wrong, but that's how it seems.
Your concern that this change was made by 'you and one of your users' without consultation is beneath you. Your guess is incorrect.
And as for without consultation. I've made SPFLite open source so it doesn't die along with me. But until somebody actually steps up and starts participating in it's maintenance, and collaboration becomes necessary, I will continue on as I always have, to change things as I see the need.
If someone has a major problem with that, they can take the source and create a fork.
That's what I am telling you.
Yes, I hear. You've said it twice.
George
|
|
|
Post by George on Feb 27, 2023 11:35:24 GMT -5
Stefan: Yes PA2 (or whatever it's called) does need a proper description in the Help. I'll add it. Maybe I'll change to (Reshow) and deprecate both PA1 and PA2.
Re: PA1 not flip/flopping while PA2 does -- is just a dumb error, there IS only one set of code to do it, the names are simply aliases in the command table. (or so I thought). I'll try not to muck it up again if I go with (Reshow).
George [UPDATE]
Turns out PA2 IS described in the Help under "Working with ... Basic Edit Funtions"
[/UPDATE]
|
|