Also, it used to be the case that only one instance of the SMP/E dialog
was allowed within a single TSO/ISPF session -  a 2nd concurrent
invocation in split screen was not allowed and would produce a failure
message..

I had suffered that, and attributed the problem mostly to DDNAME conflicts.
Do both splits try to allocate SMPCSI?

They used to, yes.  But no longer.

Not so any more.  Check out APAR IO18093 (and its subsequent fixes).

Much appreciated.  Concurrent updates are still prohibited; a reasonable
restriction.  Does this also prohibit concurrent updates, one from ISPF
and one from batch?

Yes, GIMSMP and the SMP/E ISPF dialogs play well with each other and ensure only one will update a CSI at a time. But that is not new.

Kurt Quackenbush -- IBM, SMP/E Development

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to