Re: EDITSET
In a recent note, Shane Ginnane said: > Date: Tue, 6 Mar 2007 08:03:58 +1000 > > It'll be ignored. > Well, it wasn't _exactly_ ignored: -IBM -566548801 - 07/03/06-10:16- Hello Gil, When you enter 'SJ', you're getting into ISPF and the EDITSET popup is an ISPF function. I recreated what you described on our system too. I'm in the process of contacting ISPF Level2 to follow up on this for you. Regards, ___ SDSF Support action taken - contacting ISPF Support action plan - update pmr when contact has been made. That would have been my surmise: the dialog has the look and feel of ISPF EDIT and IBM no longer has the glut of personnel to replicate functions wantonly; I'd expect that SDSF calls a common EDIT module. OTOH, I'd generally trust your expertise plus Walt's above mine plus that of an SDSF L1 tech. Right now it's very likely that ISPF will discover that SDSF invoked the ISPF interface incorrectly and bounce it right back at SDSF. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EDITSET
In a recent note, Shane Ginnane said: > Date: Tue, 6 Mar 2007 08:03:58 +1000 > > In this, as in so many other things, it is SDSF that needs to be dragged > kicking and screaming out of its own little cocoon. > Fell free to flick a request their way. > It'll be ignored. > Thanks for the encouragement and redirection. PMR submitted on SDSF (I believe that's the proper form for a "request" that erroneous behavior be repaired). I guess we'll find out how quickly they can reply "WAD". But at least once before, SDSF gave me WAD (on a behavior less clearly erroneous than this -- performance), only to repair it _sua_sponte_ in a (much) later elease. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EDITSET
gil, jumping down Walt throat, wrote on 06/03/2007 03:36:40 AM: > > > > I would say that ISPF does have its act together, gil. It allows > > > Not in my perception. You're showing an unseemly excess of > employee loyalty. Walt is right. In this, as in so many other things, it is SDSF that needs to be dragged kicking and screaming out of its own little cocoon. Fell free to flick a request their way. It'll be ignored. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EDITSET
If you think it's broken or not documented well or even if you just don't like the way it works and want it changed, then contact IBM's SDSF support. IBM-MAIN can't change it - no matter how long and loud you yell. Only IBM can do that. On Mon, 5 Mar 2007 10:36:40 -0700, Paul Gilmartin <[EMAIL PROTECTED]> wrote: >In a recent note, Walt Farrell said: > >> Date: Mon, 5 Mar 2007 12:13:02 -0500 >> >> On 3/5/2007 12:04 PM, [EMAIL PROTECTED] wrote: >> >> >> > ... But in SDSF "SJ" while >> > EDITSET shows "Confirm Cancel" as disabled, SDSF still asks me >> > to confirm Cancel. >> > >> > ISPF really needs to get its act together. >> >> I would say that ISPF does have its act together, gil. It allows >> >Not in my perception. You're showing an unseemly excess of >employee loyalty. > >> applications to run with different application prefixes, settings, >> variable pools, and commands. You've described one of the effects of >> that flexibility. >> >> SDSF runs with a different application profile (ISF) than PDF does >> (ISR). Thus the commands available are different, the settings are >> maintained separately, etc. >> >> You need to do the EDITSET (or any other action that sets profile >> variables) once for each different ISPF application you're using. >> >Do you, then, consider it correct, or a manifestation of "flexibility" >that EDITSET under SDSF displays "Confirm Cancel" as disabled, yet >the Cancel command itself still requests confirmation? > >And "flexibility" can be a PITA when there's no global default >setting and the customer is required to do the profile setting >for each application, and suffers a high astonishment factor when >entering a seldom-used applicaton and encountering a deviation >from behavior that had generally been observed to be uniform and >stable. > >Is there a way to make such settings globally rather than locally? >It would be great to have a checkbox that says "Apply these settings >to all applications." > >-- gil >-- >StorageTek >INFORMATION made POWERFUL > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EDITSET
In a recent note, Walt Farrell said: > Date: Mon, 5 Mar 2007 12:13:02 -0500 > > On 3/5/2007 12:04 PM, [EMAIL PROTECTED] wrote: > >> > > ... But in SDSF "SJ" while > > EDITSET shows "Confirm Cancel" as disabled, SDSF still asks me > > to confirm Cancel. > > > > ISPF really needs to get its act together. > > I would say that ISPF does have its act together, gil. It allows > Not in my perception. You're showing an unseemly excess of employee loyalty. > applications to run with different application prefixes, settings, > variable pools, and commands. You've described one of the effects of > that flexibility. > > SDSF runs with a different application profile (ISF) than PDF does > (ISR). Thus the commands available are different, the settings are > maintained separately, etc. > > You need to do the EDITSET (or any other action that sets profile > variables) once for each different ISPF application you're using. > Do you, then, consider it correct, or a manifestation of "flexibility" that EDITSET under SDSF displays "Confirm Cancel" as disabled, yet the Cancel command itself still requests confirmation? And "flexibility" can be a PITA when there's no global default setting and the customer is required to do the profile setting for each application, and suffers a high astonishment factor when entering a seldom-used applicaton and encountering a deviation from behavior that had generally been observed to be uniform and stable. Is there a way to make such settings globally rather than locally? It would be great to have a checkbox that says "Apply these settings to all applications." -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EDITSET
On 3/5/2007 12:04 PM, [EMAIL PROTECTED] wrote: In a recent note, Dave Salt said: Date: Sun, 18 Feb 2007 19:24:44 + In an edit session, enter EDSET on the command line. You'll see a panel with various selectable options, including the following: Thanks. So, I joyously turned off "Confirm Cancel" (I worked that way for years with no problem before IBM invented "Confirm".) Works as expected in Edit and View. But in SDSF "SJ" while EDITSET shows "Confirm Cancel" as disabled, SDSF still asks me to confirm Cancel. Why is this behavior different? Don't View and SJ use the same editor? Maybe I'll submit a PMR. But I'd hate to see the resolution be that EDITSET would support a separate setting for SJ vs. View. Hmmm. I notice that changes I make with EDITSET in View appear when I display EDITSET in SJ but are variously effective (Target line) or ineffective (Confirm Cancel) in action. Changes I make with EDITSET in SJ do not appear when I display EDITSET in View. ISPF really needs to get its act together. I would say that ISPF does have its act together, gil. It allows applications to run with different application prefixes, settings, variable pools, and commands. You've described one of the effects of that flexibility. SDSF runs with a different application profile (ISF) than PDF does (ISR). Thus the commands available are different, the settings are maintained separately, etc. You need to do the EDITSET (or any other action that sets profile variables) once for each different ISPF application you're using. Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
EDITSET (was: SDSF -- Context for [R]FIND?)
In a recent note, Dave Salt said: > Date: Sun, 18 Feb 2007 19:24:44 + > > In an edit session, enter EDSET on the command line. You'll see a panel with > various selectable options, including the following: > Thanks. So, I joyously turned off "Confirm Cancel" (I worked that way for years with no problem before IBM invented "Confirm".) Works as expected in Edit and View. But in SDSF "SJ" while EDITSET shows "Confirm Cancel" as disabled, SDSF still asks me to confirm Cancel. Why is this behavior different? Don't View and SJ use the same editor? Maybe I'll submit a PMR. But I'd hate to see the resolution be that EDITSET would support a separate setting for SJ vs. View. Hmmm. I notice that changes I make with EDITSET in View appear when I display EDITSET in SJ but are variously effective (Target line) or ineffective (Confirm Cancel) in action. Changes I make with EDITSET in SJ do not appear when I display EDITSET in View. ISPF really needs to get its act together. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
