Skip Robinson wrote:
It's not a security issue per se, but it did occur to me that SMCS might
encounter one problem that SDSF EMCS would not. An SMCS session behaves
like a real console in that messages continually flow to it according to
the usual rules. If an SMCS session is left unattended--even 'locked' as
others have suggested for security--in Roll Delete mode, messages will
accumulate wherever they live these days. This can eventually lead to a
console buffer shortage condition. In current releases of z/OS, this should
not present a serious problem, but it will not go unnoticed.
Let me be the first to raise my hand as a guilty party on this one. ;-(
Consoles are consoles. And, messages are messages. They can get
backlogged. The fewer routing codes directed to a console, the less of a
problem this will be.
EMCS, whether used by SDSF, Netview, (E)JES, or other similar software,
is a programming interface. If the program does not periodically issue
MCSOPMSG to retrieve messages directed to the console, they will back up
-- just as for any other console. Some EMCS exploiters initialize
ROUTCDE=NONE during MCSOPER ACTIVATE in an attempt to avoid this
situation. However, an active EMCS console can be set via VARY CN to
receive *any* message set.
As you say, one of the best things to come out of the (ongoing) z/OS
console restructure is that console message backlogs no longer harm the
system. Messages will back up as resources allow. At some point, they
are discarded if not "retrieved" or "displayed" in a timely manner.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
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
