On 9/13/2006 4:03 PM, [EMAIL PROTECTED] wrote:
This is one of the mystifying things about MVS (there are others).
Why does it take a Papal decree to find the state of one's account?
TSO logon does it readily enough.
Sorry, but TSO logon does -not- do it. RACF does it.
This information ought to be
available via a callable service, as readily to any program in
any environment, such as the FTP "230" message text, as it is to
TSO logon. What were the designers thinking? Were they thinking
much at all? Tunnel vision? ("Why would a TSO user _ever_ want
to use an MVS service except via LOGON to TSO?")
When we started all this, there were NO other applications that
supported RACF except batch jobs and TSO. Remember, you're asking about
processing that is, effectively, 30 years old. (We'll be celebrating
that birthday on Sept. 24.)
For batch jobs, and for TSO logons, RACF can communicate with the user,
and does so to provide the warning information.
For other logon mechanisms, RACF has no way to communicate with the user.
CICS does provide similar information, and they extract information from
the RACF user's profile, and from the RCVT, perform the calculation, and
convey the result to the user because CICS knows how to talk to him.
Other applications could do the same calculation, but do not. RACF
could provide a service to do that calculation, but it does not do so
today and no application has asked us to do so.
Slightly off-topic side notes (sorry, but I don't have a garlic.com
equivalent to point to automatically like Lynn does :-)
(a) We at one point proposed to the CICS folks that RACF return a
message with the expiration info. CICS declined because we could not
meet their needs for national language translation of the message, and
so they felt compelled to do their own calculations.
(b) We considered having the RACROUTE REQUEST=VERIFY return additional
information to allow an application to put out various messages, but ran
into problems figuring out how to tag the returned information so
applications would know what it represented, especially since the amount
and type of information returned might change over time. We could have
solved those, but CICS needed to do something on their schedule.
Lacking any applications wanting to make use of more information, and
lacking a good way to provide it, we never did so.
Feel free to submit requirements to other applications requesting that
they provide password warnings or other information you find necessary.
If they then come to us asking how they can satisfy your requirement,
we can again consider providing the necessary information to them.
Of course, this will to some extent depend on what the application can
pass back (some protocols may not allow for additional info), and even
if the application can pass it back (ftp, for example) that might not
completely resolve the problem. Earlier in this thread I think you
(gil) mentioned automated applications that can't respond to an expired
password properly. It is not obvious that they would be able to respond
to a password warning, either.
Walt Farrell, CISSP
z/OS Security Design, IBM
----------------------------------------------------------------------
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
