On 7 March 2012 16:51, Ed Mackmahon <[email protected]> wrote:
> Many thanks for your answers.
>
> Let me provide some more information
>
> I intend that the interface will logon to the mainframe and issue some
> operator commands, read some members etc... gather information and
> send it to the open systems server for further analysis.
In passing, is this server more "open" than the mainframe?
> The user which will be used for logon to the mainframe will have specific
> RACF/TSS/CA1
> display only authorities and the server is on the organization intranet not
> an out side server.
>
> Having that, I am still looking for the preferred way for interfacing in a way
> that most organization will have no problem to authorize and using most
> common services
> available on most organizations (don't want to impose implementing other
> services as a preq)
> - that was the reason I was thinking on FTP and Rexx server...
>
> Any other comments / Ideas ?
Sigh. This is a question we've encountered many times under various
circumstances, and the results have never been good.
In the worst case (1), it's at a customer site, where the sysprogs and
their management are in a snit because they have been [asked|told] to
install a userid with SPECIAL or uid(0) or "root" for the use of some
vendor product that they had never heard of until the request/demand
came in, usually already purchased by another part of the organization
reporting to a different VP.
In a variation (2) perhaps more like today's, we are asked for advice
on how to "log into the mainframe and, you know do some commands to
collect information and list users and stuff". This request has
arrived from every kind of place from surprisingly well known huge
software vendors to one-man-show consultants, and everyone in between.
Usually our first response is to ask "*What* on the mainframe is it
that you want to log on to?", and it usually goes down hill from
there, passing through variations on "telnet", "dumb ASCII", "3270?",
"shell prompt", "there are different operating systems on the
mainframe?", and a few other things on the way.
This all said, I don't want to [mis]caricature your questions or
knowledge, and it is good that you seem closer to category (2) than
(1), but you should be aware that the approach is likely to lead to an
unhappy situation. I trust that you will not take offence at what I
have to say.
Generally these questions arise when a vendor with no z/OS experience
wants to integrate "the mainframe" into their existing or proposed
product. From their point of view, and the customer organizations
they've sold to, installing any kind of software on the mainframe is a
huge barrier, both because it requires cooperation from a customer IT
division they'd rather not be involved with, and because the vendor
has no idea how to write such agent software in the first place. Hence
"agentless", "you don't have to install anything at all on the
{evil|complicated|legacy|etc.} mainframe. We just log on on remotely
and do what we need.".
You should be aware that an agentless approach is not likely to be a
selling point at all to the z/OS maintainers.
Questions likely to be raised by your customers' z/OS sysprogs and
security people when faced by the request for an ID that will be
logging on include: What z/OS application do you want to log on to?
TSO? CICS? UNIX? Something else? Multiple apps? Do you need to log on
to a particular system image, or can we load balance? Exactly what
privileges do you require, and why? Please document your use of each
required privilege in detail, and list all commands you intend to
issue. Are these commands hard coded, or can they be changed/scripted
based on configuration from the non-z/OS platform? How will access to
these commands and their results be controlled on that non z/OS
platform? Will you be making logs available to us from that platform?
Do you have Audit approval for implementation of this product? How
will transmission of sensitive information be protected on the wire?
What is the intended volume of data in each direction, and if it is
significant, how will flow control be managed? Will these commands be
issued at particular times of day? Etc. Etc. Etc.
If they are sufficiently interested, they may point out that screen
scraping is not a defined interface to anything (no matter which
platform it is performed on), and that the layout of various command
output can vary from one system to another, and over time. Certainly
they will not be interested in guaranteeing that the output stays the
same.
So... You mention (System) REXX and FTP, which suggests you know a
fair bit about z/OS (though I'm not sure where FTP exits would come
into play). Others have given you some very good approaches to look
at, and I suggest that you avoid like the plague any kind of remote
logon and scrape approach. Define a data stream of some sort
(preferably using an existing standard), install a small agent with
very well defined privileges, use defined z/OS interfaces to collect
your data, and communicate using a secure protocol to your off the box
server. Be prepared to explain what your agent does in detail
corresponding to the level of privilege that you ask for. And never
let the words "legacy" escape your lips in the same sentence as
"mainframe". :-)
Tony H.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
