Where does ISPF determine how to repsond to "Attention" function?

[Farley, Peter x23353]

[Dual-posted to ISPF-L and IBM-MAIN]

On my employer's z/OS 2.2 system and as far back as they have employed me (OS/390 R10 IIRC), pressing "Attention" (Esc on my PCOMM keyboard map) while in an ISPF screen "refreshes" the screen to the last stable state, so if you accidentally erased a whole line of program code or JCL you can recover what was there before the erase as long as you didn't press Enter or any PF/PA key before pressing "Attention".

On a friend's z/OS system (not sure of the release), pressing "Attention" at any ISPF screen causes the terminal to be taken out of service (VTAM INACT).

My question is where and how does ISPF determine how to respond to "Attention" to refresh the screen instead of making the terminal INACT? Or is that a VTAM function/setting of some kind? If it is VTAM, where is it specified?

Just curious here, no actual problem to be solved ("Doctor! Doctor! It hurts when I do that!"; "Well, don't do that!").

Peter
--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Paul Gilmartin]

On 2019-02-18, at 15:20:08, Farley, Peter x23353 wrote:

> [Dual-posted to ISPF-L and IBM-MAIN]
>
> On my employer's z/OS 2.2 system and as far back as they have employed me (OS/390 R10 IIRC), pressing "Attention" (Esc on my PCOMM keyboard map) while in an ISPF screen "refreshes" the screen to the last stable state, so if you accidentally erased a whole line of program code or JCL you can recover what was there before the erase as long as you didn't press Enter or any PF/PA key before pressing "Attention".
>

On a real 3270 that's more likely to be PA2. Does your emulator have a
graphic pop-up keypad you can experiment with? Of course, keys can be mapped
at both emulator and ISPF.

> On a friend's z/OS system (not sure of the release), pressing "Attention" at any ISPF screen causes the terminal to be taken out of service (VTAM INACT).
>

That's more like classic ATTN. And it may depend further on whether your
LOGON proc sends you to VTAM solicitor, TSO, or ISPF.

Too many knobs and levers, and not the right ones.

And CMS XEDIT provides finer granularity: ERASE EOF at the beginning of any
field causes that field to be refreshed with unmodified content.

-- gil

[Marvin Knight]

ISPF run with a STAX (attention exit active).   If you are not in TEST mode it will treat a PA1 the same as a PA2 and do a reshow..   A second PA1 will take you back to the primary menu..
If you are in TEST mode the PA1 will take you to TSO ready.   From there if you just hit ENTER you are returned to ISPF.  If you enter a TSO command you stay in TSO.  You could also ENTER
TEST and be put in TSO test where you could set up breakpoints on a program and then ENTER GO to return to ISPF.  Keep in mind if you are in a Dialog when hitting the PA1 (or ATTN)  that the
Dialog might also have an attention exit that intercepts the PA1 and processes it before our exit gets control.  As Gil mentioned using PA2 would be the best method to just do a RESHOW.  


Marvin Knight

--
You received this message because you are subscribed to the Google Groups "ISPF discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ispf-l-list...@nd.edu.
To post to this group, send email to ispf-...@nd.edu.

[Ward Able, Grant]

Cross posting to TSO-REXX & ISPF lists

 

A colleague is getting the following error & we are a bit confused about it

 

       >O>       "ispfexec lmcopy fromid(ISR00003) frommem(AZN11100) ,

 todataid(ISR00004) tomem(DB2ANNU7) replace"                       

IKJ56861I  FILE ISPPROF NOT UNALLOCATED, DATA SET IS OPEN 

ERROR ENCOUNTERED IN EXEC ISPFALLO. RC: 12 STMT NUM: 38   

 

 His ISPPROF dataset is already allocated to his ID, so why is it trying to allocate it?

What needs to be done to get this to work?

 

 

 

 

Regards – Grant.

 

In theory, there's no difference between theory and practice. In practice, there is.

 

There is no such thing as the Cloud. It is just somebody else’s computer.

 

If you don't have time to do it right, when will you have the time to do it over? - John Wooden

 

DTCC Internal (Green)

DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

[Marvin Knight]

Grant,
   The ISPF service request should be ISPEXEC and not ISPFEXEC.   I suspect there is an exec called
ISPFEXEC that is being executed instead of calling ISPEXEC and that exec allocates ISPF libraries.


Marvin Knight

[Paul Gilmartin]

On 2019-03-07, at 03:10:29, Marvin Knight wrote:

> Grant,
> The ISPF service request should be ISPEXEC and not ISPFEXEC. I suspect there is an exec called
> ISPFEXEC that is being executed instead of calling ISPEXEC and that exec allocates ISPF libraries.
>

And that shows good reason to ADDRESS ISP[F]EXEC rather than issuing
"isp[f]exec" as a TSO(?) command. Probably performs better, too, without
the additional level of parsing.

> From: "Ward Able, Grant" <GWar...@dtcc.com>
> Date: 03/07/2019 03:12 AM
>

> >O> "ispfexec lmcopy fromid(ISR00003) frommem(AZN11100) ,

-- gil

[Frank Clarke]

I had always been told that "ISPEXEC FTINCL ..." caused a fresh ISPEXEC to be dispatched (by TSO) rather than using one already in residence.  I don't know whether this is true or not, but if true, it hints at deliberately decreased efficiency.

--
You received this message because you are subscribed to the Google Groups "ISPF discussion list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ispf-l-list+unsub...@nd.edu.

[Paul Gilmartin]

On 2019-03-07, at 09:15:45, 'Frank Clarke' via ISPF discussion list wrote:

> I had always been told that "ISPEXEC FTINCL ..." caused a fresh ISPEXEC to be dispatched (by TSO) rather than using one already in residence. I don't know whether this is true or not, but if true, it hints at deliberately decreased efficiency.
>

I have wondered why ISPF Edit doesn't invoke macros with ISREDIT as the
initial command environment.

Perhaps I'm biased by knowing CMS XEDIT, which invokes macros with environment
XEDIT, not CMS.

I suspect that ISPF developers were uncomfortable with Rexx, forcing the
programmer to use MACRO (X) rather than PARSE ARG X.

-- gil