KEYLISTs
thoma...@swedbank.se
I have a problem with keylists.
I have since long the setting of
"Disable Keylists" through ISPF
selection 0, but now in SDSF keylists
seem to return every time I enter SDSF.
(I do "KEYLIST OFF" but that setting
resets to "KEYLIST ON" whenever I end
a subdialog in SDSF and then go into
that subdialog again.)
Question 1: I there a general way, other
than changing in SDSF, to get rid of keylists
in SDSF ?
Question 2: How does it generally work with
"Disable keylists" in ISPF 0 ? Is there up
to the ISPF applications to heed that setting
or is it normally ISPF that controls the
handling of KEYS/Keylists ?
Regards,
Thomas Berg
__________________________________________
Thomas Berg Specialist IT-U SWEDBANK
Jim Moore
Or perhaps: SETTINGS primary command from SDSF and then turn off KEYLIST?
Concentrated Logic
Mark Zelden
>Hi,
>
>I have a problem with keylists.
>I have since long the setting of
>"Disable Keylists" through ISPF
>selection 0, but now in SDSF keylists
>seem to return every time I enter SDSF.
>(I do "KEYLIST OFF" but that setting
>resets to "KEYLIST ON" whenever I end
>a subdialog in SDSF and then go into
>that subdialog again.)
>
>Question 1: I there a general way, other
>than changing in SDSF, to get rid of keylists
>in SDSF ?
>
>Question 2: How does it generally work with
>"Disable keylists" in ISPF 0 ? Is there up
>to the ISPF applications to heed that setting
>or is it normally ISPF that controls the
>handling of KEYS/Keylists ?
>
>
Gee.. Almost the same thread is going on in IBM-MAIN about the command
line.
Use the SETTINGS command from the SDSF command line and set your
preference there. That will update ISFPROF for SDSF so the settings
will be saved.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
thoma...@swedbank.se
when I exit SDSF and enter it again.
Regards,
Thomas Berg
__________________________________________
Thomas Berg Specialist IT-U SWEDBANK
> -----Ursprungligt meddelande-----
> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU]
> För Mark Zelden
> Skickat: den 12 mars 2009 19:30
> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: KEYLISTs
Ryerse, Robin
Pinnacle
From: <thoma...@SWEDBANK.SE>
Newsgroups: bit.listserv.ispf-l
Sent: Thursday, March 12, 2009 10:18 AM
Subject: KEYLISTs
> Hi,
>
> I have a problem with keylists.
> I have since long the setting of
> "Disable Keylists" through ISPF
> selection 0, but now in SDSF keylists
> seem to return every time I enter SDSF.
> (I do "KEYLIST OFF" but that setting
> resets to "KEYLIST ON" whenever I end
> a subdialog in SDSF and then go into
> that subdialog again.)
>
> Question 1: I there a general way, other
> than changing in SDSF, to get rid of keylists
> in SDSF ?
>
> Question 2: How does it generally work with
> "Disable keylists" in ISPF 0 ? Is there up
> to the ISPF applications to heed that setting
> or is it normally ISPF that controls the
> handling of KEYS/Keylists ?
>
>
Thomas,
The command line application in the SYSLOG display requires the use of
KEYLISTS, therefore, SDSF sets KEYLIST ON upon entry, then resets KEYLIST to
what it was when it entered (like HCD and other well-behaved KEYLIST apps,
MQ excluded). This was my fault. I made the mistake of pointing out to
SDSF that not everyone runs with KEYLIST ON by default, and they need to
take a page out of the HCD handbook.
Regards,
Tom Conley
IBM CA-1/RMM Conversion Team
P: (585)727-3138
thoma...@swedbank.se
Nice to hear from You, nothing is like
talking to the source. :)
But I'm still not quite understand Your
explanation, as the key setting when I enter
SDSF in, e g, the H list is what I have set
once in a time, which is KEYLIST OFF.
The change from old version of SDSF is that some
of the subdialogs, including the "keys setting"
(Sic!) dialog, is always now set to KEYLIST ON.
Like when I using the SE line command for
EDIT mode of job outputs.
I have not used (I don't know how) the SYSLOG
command line app yet, but when I enter LOG
display I still have KEYLIST OFF.
Regards,
Thomas Berg
__________________________________________
Thomas Berg Specialist IT-U SWEDBANK
> -----Ursprungligt meddelande-----
> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU]
> För Pinnacle
> Skickat: den 13 mars 2009 04:50
> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: KEYLISTs
>
Hamilton, Robert L
I also tried to adapt this
Parse Value '0' Stream(filename, 'c', 'QUERY TIMESTAMP') With DaysOld filedate .
If filedate <> '' Then DaysOld = Date('B') - Date('B',Changestr('-',filedate,''),'S')
But cannot get this to work with PDS members. . .
Thnx very much
bobh
-----Original Message-----
From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On Behalf Of thoma...@SWEDBANK.SE
Sent: Friday, March 13, 2009 7:58 AM
To: ISP...@LISTSERV.ND.EDU
Subject: SV: KEYLISTs
Mark Zelden
Under ISPF, display PF keys with PFSHOW, and change with KEYS.
Under TSO, the keys cannot be displayed or changed.
SDSF's pop-ups each have PF keys assigned with an ISPF keylist.
Although ISPF allows you to change the values of the keys
in keylists, and to turn off the use of keylists, you should
use the IBM-supplied key definitions and leave keylists
on to ensure that the pop-ups work correctly.
The PF key definitions for SDSF's panels are shown on the
panel that follows.
Styles, Andy , Group IT
experience, why would anyone leave keylists on?!
(P)F keys work much better, consistently, without keylists on...
--
Andy Styles
Email andy.s...@lloydstsb.co.uk
-----Original Message-----
From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On Behalf Of
From help:
This e-mail is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments.
Lloyds TSB Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales, number 2065. Telephone: 020 7626 1500.
Lloyds TSB Scotland plc. Registered Office: Henry Duncan House, 120 George Street, Edinburgh EH2 4LH. Registered in Scotland, number 95237. Telephone: 0131 225 4555.
Cheltenham & Gloucester plc. Registered Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales, number 2299428. Telephone: 01452 372372.
Cheltenham & Gloucester Savings is a division of Lloyds TSB Bank plc.
Lloyds TSB Bank plc, Lloyds TSB Scotland plc and Cheltenham & Gloucester plc are authorised and regulated by the Financial Services Authority.
Lloyds Banking Group plc. Registered Office: Henry Duncan House, 120 George Street, Edinburgh EH2 4LH. Registered in Scotland, number 95000. Telephone: 0131 225 4555.
Lloyds Banking Group plc is a signatory to the Banking Codes.
Telephone calls may be monitored or recorded.
Mark Zelden
<Andy.S...@LLOYDSTSB.CO.UK> wrote:
>Not that I'm disagreeing with your reference but, from personal
>experience, why would anyone leave keylists on?!
>
>(P)F keys work much better, consistently, without keylists on...
>
That is a religious question / issue , not a technical one.
Ryerse, Robin
to the extent that I will modify (vendor supplied) application panels
just so that I can have KEYLIST within the application.
John P Kalinich
pds 'pdsname'
if: week then(attrib)
>if : week then(attrib
MEMBER VER.MOD CREATED LAST MODIFIED SIZE INIT MOD ID
$PRODCPY 01.00 09/03/09 09/03/09 11:24 85 85 0 TRIDJK
DFASCO 01.00 09/03/09 09/03/09 9:21 341 341 0 TRIDJK
DFASCO2 01.01 09/03/09 09/03/09 11:07 2 2 0 TRIDJK
FTP2PC 01.06 05/07/06 09/03/13 7:38 26 27 0 TRIDJK
MFCT02 01.01 09/03/09 09/03/09 11:25 32 17 0 TRIDJK
PKUNZIPA 01.06 05/07/01 09/03/13 11:03 29 22 0 TRIDJK
PKZIPA 01.13 05/07/01 09/03/13 11:03 35 22 0 TRIDJK
7 MEMBERS COUNTED; CUMULATIVE SIZE IS 550 RECORDS
Regards,
John K
Bob Hamilton of the ISPF discussion list <ISP...@LISTSERV.ND.EDU> wrote on
03/13/2009 11:07:52 AM:
Schwarz, Barry A
BTW, REXX is not a DB2 feature.
Edward Jaffe
> On Fri, 13 Mar 2009 16:28:20 -0000, Styles, Andy (Group IT)
> <Andy.S...@LLOYDSTSB.CO.UK> wrote:
>
>
>> (P)F keys work much better, consistently, without keylists on...
>>
>
> That is a religious question / issue , not a technical one.
>
Agreed. I much prefer KEYLIST ON. It makes ISPF far more usable (IMHO).
Obviously, some people take the opposite view.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Dave Salt
> Not that I'm disagreeing with your reference but, from personal
> experience, why would anyone leave keylists on?!
The issue to me is not whether keylists are good or bad, but whether they are well written or poorly written.
Imagine there is an ISPF application that has 3 panels, none of which can be scrolled left or right. Now imagine that every panel requires the user to enter some values and then type a command on the command line (e.g. 'CONTINUE').
If the application does not have a keylist, the user has to keep entering 'CONTINUE' on the command line, perhaps many times throughout each day. But if the application has a keylist, it 'knows' which PF keys are required on each panel and which PF keys are available for use. For example, it knows that the LEFT and RIGHT PF keys (F10 and F11) are redundant on every panel, and that one of those keys (e.g. F10) could be used to 'CONTINUE'. So by using a keylist and setting F10 to CONTINUE, it is much easier to use the application.
In the scenario above, keylists are a great time saver. In no way do they interfere with the use of regular PF keys; e.g. F1 still equals 'HELP' and F3 still equals 'END' (etc). But the availability of the keylist turned what would have been a completely redundant key (i.e. RIGHT) into something very useful (i.e. CONTINUE). In this scenario I think the use of the keylist is very beneficial.
In a different scenario an application might have been poorly designed so that different keys execute different commands on each and every panel. In this case it would be too scary to press a PF key because the effect might be uncertain (unless PF SHOW is on, but that's a different story). So in this case, it would probably be better to turn KEYLIST OFF.
IMO arbitraily turning KEYLIST OFF might not be in a persons best interest. Instead, each application should be judged on its own merits. If keylists are useful, leave them on. Otherwise, turn them off.
As a final note, I think that any application that comes with keylists should be applauded. If someone doesn't like the keylists, they can always turn them off. But if an application doesn't come with keylists, there is no way to turn them on (unless you go to the trouble of customizing the panels and creating your own keylists). So to me, it's always better that an application has keylists available for those that want to use them, rather than not offering them at all.
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm
_________________________________________________________________
Reunite with the people closest to you, chat face to face with Messenger.
http://go.microsoft.com/?linkid=9650736
Pinnacle
From: "Edward Jaffe" <edj...@PHOENIXSOFTWARE.COM>
Newsgroups: bit.listserv.ispf-l
Sent: Friday, March 13, 2009 2:23 PM
Subject: Re: SV: KEYLISTs
> Mark Zelden wrote:
>> On Fri, 13 Mar 2009 16:28:20 -0000, Styles, Andy (Group IT)
>> <Andy.S...@LLOYDSTSB.CO.UK> wrote:
>>
>>
>>> (P)F keys work much better, consistently, without keylists on...
>>>
>>
>> That is a religious question / issue , not a technical one.
>>
>
> Agreed. I much prefer KEYLIST ON. It makes ISPF far more usable (IMHO).
Ed,
Except when using EDIT, where the PF12 KEYLIST is CANCEL instead of RETRIEVE
;-) When I first installed ISPF V4, I got lots of calls from users whose
2-hour EDIT sessions simply vanished. That's why I run with KEYLIST OFF.
Tom
Mark Zelden
Typically, I just try and get used to new defaults for these sort of
things. In this case, I did. I am so used to hitting SHIFT+PF12 to
RETRIEVE instead of PF12, I wasn't even sure that was what I did
and had to "try it" before responding to this post.
Guess which side of the fence I'm on... :-)
Paul Gilmartin
>>
>> Except when using EDIT, where the PF12 KEYLIST is CANCEL instead
>> of RETRIEVE
>> ;-) When I first installed ISPF V4, I got lots of calls from
>> users whose
>> 2-hour EDIT sessions simply vanished. That's why I run with
>> KEYLIST OFF.
>
> things. In this case, I did. I am so used to hitting SHIFT+PF12 to
> RETRIEVE instead of PF12, I wasn't even sure that was what I did
> and had to "try it" before responding to this post.
>
> Guess which side of the fence I'm on... :-)
>
single-keystroke alias.
But that doesn't negate my wish that bypass confirm delete
data set could be made sticky -- delete is two keystrokes;
I'd never make it one.
-- gil
Edward Jaffe
>
> Ed,
>
> Except when using EDIT, where the PF12 KEYLIST is CANCEL instead of
> RETRIEVE ;-) When I first installed ISPF V4, I got lots of calls from
> users whose 2-hour EDIT sessions simply vanished. That's why I run
> with KEYLIST OFF.
KEYLIST OFF seems like overkill. It affects *all* applications sharing
the same ISPF APPLID (e.g., ISR). The unintended consequence is that
some of those applications will be rendered less usable without access
to their well-designed, custom key lists.
The pervasiveness of the "nuclear" KEYLIST OFF option is a likely reason
why some applications (e.g., HCD, (E)JES, WLM, BookManager, ISHELL,
etc.) whose usability is enhanced by their key lists, run under their
own ISPF APPLIDs.
In EDIT and VIEW, the default key list works great for me. F12=Cancel is
much easier than typing the word CANCEL in the command line. Just as
with the CANCEL command, updated EDIT/VIEW sessions don't "vanish"
unless you respond positively to the Confirm Cancel pop-up.
Shift+F12(F24)=CRetriev works well too by combining the effect of CURSOR
and RETRIEVE. If these defaults are unsatisfactory, the KEYS command can
be used to tailor the ISRSPEC key list to user preference.
[This reference is for John Gilmore if he's listening: Thomas Murner's
(1475-1537) versified satirical book Narrenbeschwörung (1512) contains a
short chapter entitled "Das kindt mit dem bad vß schitten" (To throw the
baby out with the bath water) a treatise on fools who by trying to rid
themselves of a bad thing succeed in destroying whatever good there was
as well.]
Don Leahy
a pretty rare transaction (especially so since VIEW became available),
so I don't mind taking a little more time over it.
(I once had a PFK to perform CANCEL. Then one day I had to borrow my
boss's userid, and found out, the hard way, that he used the same PFK
for SAVE. I switched the PFK definition to the way I liked it, but
then I forgot to switch it back when I was done. Oops.)
Pinnacle
Ed,
When ISPF V4 first came out with KEYLIST support, there was no CANCEL
confirmation. Hitting PF12 blew away hours of EDIT effort. ISPF
development added the confirmation at a later date.
With regards to ISPF keylist apps, I'm not aware of any that don't work with
KEYLIST OFF. What ISPF apps are KEYLIST driven? Option 11 Workplace?
HCD was the first application to heavily exploit keylists. From the
beginning, they did it right. They did not assume that KEYLIST was ON by
default. They turned it ON, invoked HCD, and then reset it to its previous
value after leaving HCD. Unfortunately, SDSF, MQ, TCP/IP, VTAM, and others
were all developed with the assumption that KEYLIST was ON. You've got it
backwards, KEYLIST OFF did not force HCD to create their environment, they
were smart enough to realize that not everyone would run KEYLIST ON. If an
app requires KEYLIST, it should turn it on by itself, it should not force
the ISPF user to have KEYLIST ON globally. You'd like the MQ developers Ed.
They agree with you that KEYLIST should be on globally and refuse to change
their invocation exec to do it the right way. The VTAM, TCP/IP, and SDSF
developers changed their dialogs to follow the HCD model once I pointed it
out to them.
Forcing users to run ISPF in a certain default way is wrong thinking. It
should be discouraged.
Regards,
Tom Conley
John P Kalinich
03/16/2009 12:25:05 PM:
> With regards to ISPF keylist apps, I'm not aware of any that don't work
with
> KEYLIST OFF. What ISPF apps are KEYLIST driven? Option 11 Workplace?
BookMangler and FaultAnalyzer work well with KEYLIST's. But I agree with
Tom, PDF dialogs should not need them.
Regards,
John K
Pinnacle
From: "John P Kalinich" <jkal...@CSC.COM>
Newsgroups: bit.listserv.ispf-l
Subject: Re: SV: KEYLISTs
John's right, I should have said "PDF" dialogs, to distinguish the ISPF/PDF
application we all know and love (EDIT, VIEW, 3.4, etc) from the generic
term "ISPF".
Regards,
Tom Conley
Dave Salt
Assuming an application does have it's own unique application ID and it uses keylists then IMO the proper way for the application to behave is this:
1) When a user enters the application for the very first time, the application should turn KEYLIST ON.
2) When the user exits the application, the application does not need to take any action; i.e. it does not need to turn KEYLIST ON or OFF. This is because the user is exiting the application and going back to some other application (e.g. ISR) whose keylist setting was not affected by the keylist setting of the application they were just in.
3) When the user re-enters the application, the application does not need to take any action; i.e. it does not need to turn KEYLIST ON or OFF. This is because the keylist setting is remembered from session to session, and will be whatever the user set it to during a previous session. Whether this is ON or OFF is up to the user, and the application should not force it to always be ON.
So in summary, I think an application that uses keylists should turn KEYLIST ON when a user goes into that application for the very first time, but should never change that setting ever again.
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm
_________________________________________________________________
Reinvent how you stay in touch with the new Windows Live Messenger.
http://go.microsoft.com/?linkid=9650731
Edward Jaffe
> HCD was the first application to heavily exploit keylists. From the
> beginning, they did it right. They did not assume that KEYLIST was ON
> by default. They turned it ON, invoked HCD, and then reset it to its
> previous value after leaving HCD.
If this is true, it is an abomination and certainly NOT the intended way
to implement KEYLIST support. It shows the lengths to which some
developers are prepared to go to ensure their key lists are seen by the
end user. They do this because they know that KEYLIST OFF will result in
a nearly unusable interface. They are FORCING you to see their key
lists--i.e., they are ignoring the KEYLIST command altogether and
forcing KEYLIST ON for their application.
> Unfortunately, SDSF, MQ, TCP/IP, VTAM, and others were all developed
> with the assumption that KEYLIST was ON.
The applications listed above don't assume KEYLIST ON. Rather, they
honor the user's KEYLIST setting as is customary. No matter how
misguided the unilateral disabling of key lists might be, the end user
is supposed to have control over this. That's why the command was
provided in the first place.
Paul Gilmartin
> Personally, I don't want CANCEL to be too easy! In my work CANCEL is
> a pretty rare transaction (especially so since VIEW became available),
> so I don't mind taking a little more time over it.
>
I always use CANCEL in VIEW. How else can I get out quickly?
END tells me:
- .----------------------- View Warning -----------------------.
V | |
* | |
= | You are currently in View mode: |
= | |
0 | Press Enter to confirm exit from View. No changes |
0 | will be saved. |
0 | |
0 | Enter the END or EXIT command to return to View, |
0 | where you can use the CREATE or REPLACE primary |
0 | commands to save your changes. |
0 | |
0 | Command ===> |
0 | F1=Help F3=Exit F12=Cancel |
0 '------------------------------------------------------------'
-- gil
Pinnacle
From: "Edward Jaffe" <edj...@PHOENIXSOFTWARE.COM>
Newsgroups: bit.listserv.ispf-l
Subject: Re: SV: KEYLISTs
> Pinnacle wrote:
>> HCD was the first application to heavily exploit keylists. From the
>> beginning, they did it right. They did not assume that KEYLIST was ON by
>> default. They turned it ON, invoked HCD, and then reset it to its
>> previous value after leaving HCD.
>
> If this is true, it is an abomination and certainly NOT the intended way
> to implement KEYLIST support. It shows the lengths to which some
> developers are prepared to go to ensure their key lists are seen by the
> end user. They do this because they know that KEYLIST OFF will result in a
> nearly unusable interface. They are FORCING you to see their key
> lists--i.e., they are ignoring the KEYLIST command altogether and forcing
> KEYLIST ON for their application.
>
>> Unfortunately, SDSF, MQ, TCP/IP, VTAM, and others were all developed with
>> the assumption that KEYLIST was ON.
>
> The applications listed above don't assume KEYLIST ON. Rather, they honor
> the user's KEYLIST setting as is customary. No matter how misguided the
> unilateral disabling of key lists might be, the end user is supposed to
> have control over this. That's why the command was provided in the first
> place.
>
Ed,
The problem is that most KEYLIST apps require KEYLIST ON, or they are
unusable (try KEYLIST OFF in HCD and see how far you get). In my default
KEYLIST OFF environment, SDSF, MQ, TCP/IP, VTAM, and IPCS (forgot him
earlier), all failed because they were dependent on keylists and would not
function properly without them unless the user typed the full commands into
the command line. All except MQ agreed to fix their dialogs by turning
KEYLIST ON themselves and restoring the previous setting on exit. For MQ, I
rigged a front-end in my Dynamic ISPF Starter Set just to do that.
The only reason to do KEYLISTs is if you want panel-specific PFKeys. ISPF
PFkeys previously were limited to an application-wide basis. HCD was the
first KEYLIST app in wide use, so for better or worse, it made the rules.
Is there a valid reason why a user would turn KEYLIST OFF for an app that
required them?
Tom
Dave Salt
<49BE7106...@phoenixsoftware.com>
<95A2FBE2831049629A23F7B2CF70A72A@pinnacledesk1>
<49BEA409...@phoenixsoftware.com>
<DFBB7E1955F1468CB2C6F4C7BA9F7A23@pinnacledesk1>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Mar 2009 20:12:20.0128 (UTC) FILETIME=[82B77200:01C9A673]
X-Source-IP: 65.55.116.26
X-Spam: No
X-Spam-Score: 0.00%
X-ND-MTA-Date: Mon, 16 Mar 2009 16:13:35 EDT
X-ND-CM-Score: 0.00%
X-ND-CT-Class: Not-spam
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists-p1.cc.nd.edu id n2GKCMRZ025837
> From: pinn...@ROCHESTER.RR.COM
> Is there a valid reason why a user would turn KEYLIST OFF for an app that
> required them?
Why would an ISPF application 'require' the use of keylists? Keylists are there for the convenience of the user. If a user prefers to type 'MakeItSo' on the command line (instead of pressing PF whatever), they should absolutely be allowed to do that and the application shouldn't care. I just don't see why a well designed application would require that keylists are used?
Ryerse, Robin
I never use View except as forced by an application. I use BROWSE unless
I know I want to make changes (You can even switch to EDIT mode from
within BROWSE). There are those who will question how to act upon
strings in the browsed dataset. Enter @CURSOR (home grown) which is far
more versatile and efficient than having a macro extract the text.
-----Original Message-----
From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On Behalf Of
Paul Gilmartin
Sent: March 16, 2009 3:13 PM
To: ISP...@LISTSERV.ND.EDU
Subject: Re: SV: KEYLISTs
Pinnacle
From: "Dave Salt" <ds...@HOTMAIL.COM>
Newsgroups: bit.listserv.ispf-l
Sent: Monday, March 16, 2009 4:14 PM
Subject: Re: SV: KEYLISTs
Dave,
I'm with you, but they're a fact of life and we have to live with them.
Regards,
Tom Conley
Paul Gilmartin
> ?? Get out quickly ?? Answer: Never get in.
>
> I never use View except as forced by an application. I use BROWSE unless
> I know I want to make changes (You can even switch to EDIT mode from
(Or VIEW mode.) Thanks for the information. Do you mean
by typing EDIT or VIEW on the command line? This puts me
back in the "%%%% Command - Entry Panel" (with the data set
name preselected. ENTER puts me in a member menu in which
I can scroll to the member I was browsing and select it.
Seems the long way around compared to starting in VIEW in
the first place.
> within BROWSE). There are those who will question how to act upon
> strings in the browsed dataset. Enter @CURSOR (home grown) which is far
> more versatile and efficient than having a macro extract the text.
>
> -----Original Message-----
> From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On Behalf Of
> Paul Gilmartin
> Sent: March 16, 2009 3:13 PM
>
> On 03/16/09 10:58, Don Leahy wrote:
>> Personally, I don't want CANCEL to be too easy! In my work CANCEL is
>> a pretty rare transaction ...
>>
> ???
>
> I always use CANCEL in VIEW. How else can I get out quickly?
-- gil
Pedro Vera
a tricky thing to get right. It is easy for a full panel and simple use
setup. But the user can make it more complicated by using different ISPF
settings. For example if the developer wants to display a small popup
window, but the user has opted to show both primary and secondary keys,
then too much of the body of the popup is used up. Keylists simplify this
configuration by not actually showing all keys.
Pedro Vera
Dave Salt
> From: "Dave Salt"
>> are there for the convenience of the user. If a user prefers to type
>> 'MakeItSo' on the command line (instead of pressing PF whatever), they
>> should absolutely be allowed to do that and the application shouldn't
>> care. I just don't see why a well designed application would require
>> that keylists are used?
>>
>
>>> From: pinn...@ROCHESTER.RR.COM
> I'm with you, but they're a fact of life and we have to live with them.
Having said all that I'll now try to reword what I meant to say previously, which is that no application should ever *FORCE* a person to use keylists.
IMO it's okay for an application to turn KEYLIST ON when someone goes into the application for the very first time, but after that it should be completely up to the user whether they wish to continue using the keylists or not. In other words, if the user turns KEYLIST OFF they should *stay* off (unless and until the user turns them back on), but they should never be turned back on by the application.
So, in summary:
1) I think keylists are good.
2) I think it's a bad idea for a user to turn them off.
3) But *IF* a user wants to turn them off, that should be their choice and an application should not ignore a users wishes by turning them back on.
Edward Jaffe
> The problem is that most KEYLIST apps require KEYLIST ON, or they are
> unusable (try KEYLIST OFF in HCD and see how far you get). In my
> default KEYLIST OFF environment, SDSF, MQ, TCP/IP, VTAM, and IPCS
> (forgot him earlier), all failed because they were dependent on
> keylists and would not function properly without them unless the user
> typed the full commands into the command line. All except MQ agreed
> to fix their dialogs by turning KEYLIST ON themselves and restoring
> the previous setting on exit. For MQ, I rigged a front-end in my
> Dynamic ISPF Starter Set just to do that.
Let's see... You set the site-side default to KEYLIST OFF because you
don't like the as-delivered F12 setting in EDIT and then, recognizing
this hurts the usability of many products (e.g., HCD), lobby the
developers to ignore the end user's KEYLIST settings and *FORCE* KEYLIST
ON in that subset of products for which *you* deem key lists to be
necessary.
Ummm... This is completely contrary to what I believe as both a
developer and user of ISPF applications. :-(
Seems to me like you're creating your own conundrum, here. Perhaps it's
time to take a step back and re-evaluate your original position. Maybe
all you have to do is change F12 in the EDIT/VIEW key list to something
other than "Cancel" and you'll be satisfied.
Don Leahy
risk of altering data.
thoma...@swedbank.se
setting mandated by the application) is that it
destroys MY PF key settings !
I have (by historical and practical reasons) dissident
setting of PF key functions. E g the scrolling commands
(UP, DOWN, LEFT RIGHT) and other usual commands plus
some special but for me very usable functions.
As these KEY nearly ALWAYS are destroyed by the
applications KEYLIST settings I have to avoid KEYLISTs
at any cost.
It's a - for me - complete mystery why no ISPF application
seems to heed the users preference of the PF key settings.
Mark Zelden
wrote:
>That is a religious question / issue , not a technical one.
>
It surely must be. This is most activity (especially for a single thread) I've
seen on ISPF-L in a long time. :-)
Pedro Vera
!
I think 'destroy' is a incorrect characterization. When you end the
problem application your normal keys should still be there intact. If
not, it is something different than the use of keylists or not.
Even with keylists on, you can still customize them using the KEYS
command. Its just annoying because there are so many of places where you
would want to.
Pedro Vera
thoma...@swedbank.se
correct.
But it feels that way, especially as that even
if I edit the keylist to my preference, I had
the experience in the past that these settings
dissappeared when there was a new version of
the application installed.
Maybe I have to revisit the keylists and try
to use them despite my bad experience, they
maybe behave better now...
I think I code a command to set the pfkeys
to my liking in the fly...
Regards,
Thomas Berg
__________________________________________
Thomas Berg Specialist IT-U SWEDBANK
> -----Ursprungligt meddelande-----
> Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU]
> För Pedro Vera
> Skickat: den 17 mars 2009 16:52
> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: SV: SV: KEYLISTs
Edward Jaffe
> Well, I admit that the wording is not quite
> correct.
> But it feels that way, especially as that even
> if I edit the keylist to my preference, I had
> the experience in the past that these settings
> dissappeared when there was a new version of
> the application installed.
>
Modified key lists are stored in your ISPF profile library member(s)
xxxxPROF where xxxx is the ISPF APPLID. The application
default-as-distributed key lists are usually delivered in xxxxKEYS.
thoma...@swedbank.se
> Skickat: den 17 mars 2009 19:29
> Till: ISP...@LISTSERV.ND.EDU
> Ämne: Re: SV: SV: SV: KEYLISTs
>
> thoma...@SWEDBANK.SE wrote:
> > Well, I admit that the wording is not quite correct.
> > But it feels that way, especially as that even if I edit
> the keylist
> > to my preference, I had the experience in the past that
> these settings
> > dissappeared when there was a new version of the application
> > installed.
> >
>
> Modified key lists are stored in your ISPF profile library
> member(s) xxxxPROF where xxxx is the ISPF APPLID. The
> application default-as-distributed key lists are usually
> delivered in xxxxKEYS.
>
Yes, it seems to work like that. (I tested.)
Lets hope that a new version does not insist
to update my settings.