Hi Charles,
I very much appreciate that you asked the question. I can't tell you how many
hours (maybe hundreds!) I have spent over the last 10 years with vendor
support folks trying to get the information you are planning to give out on a
silver platter. Thank you.
I realize that this goes beyond your initial question by a good bit. Perhaps
it will be useful - if not, I know that you know where the delete key is ;-).
For example -
I have a product suite form a vendor. I really like these products and the
vendor has since fixed their docs. Both A and B require TCP/IP services. A
could come up with or without TCP/IP. It would connect with TCP/IP when TCP/IP
was ready. If TCP/IP went down, A would issue a complaint message every minute
and then connect back up with TCP/IP when it came back up - all by itself.
Product B, on the other hand, would try ONCE to connect with TCP/IP, post one
small, one line scroll message and never try again - and there was no command
to make it try again. The only option was to shut Product B down and restart
it.
I am in a small shop, 2 monplex lpars, and we are back leveled. When I look at
a product - which I haven't lately because our budget is so bad, I really like
to see the -
• Minimum and maximum z/OS requirements for it to run, including USS
• Minimum and maximum z/OS requirements for it to be supported - which may
be different
• What are the co-existance levels between products from the same vendor?
• What are the below the line and above the line storage requirements?
• Any other products required?
• What are the RACF, SAF, or other security requirements? For the
installer, admin, user? It's terrific if these things are clearly spelled
out. It's a royal pain to have to find out by "tripping over it" testing.
• Does it require/psuedo-require SMS? Some products write output either to
one SMS pool or one volume. We use some SMS, but not a lot, just where we
really need it.
• Does it/can it/must it run in LPA/ and why?
• Please don't tell me that it must run in SYS1.PROCLIB, or have parm
entries in SYS1.PARMLIB. That means I can't let the new sysprog install it.
Newbies follow directions too closely sometimes. Tell me something like -
Place this parmlib member in the SYS1 parmlib library concatenation. etc - like
the one who followed the docs to apply and then apply the usermods, then accept
everything - and all of that before enven testing the product!
• Any other products (from the same vendor) that work well in concert with
this product
• Any other products that this product does not play well with (same or
different vendor) and does it mean that I have to choose between products or is
there some way that I can run both? I had this one - 2 programmer support
products - they could co-exist, but it wasn't documented how to do it. Both
product vendors knew about the issues, but didn't want to help until I told
them that if the products wouldn't play nicely together that we would drop one,
maybe both. If there had been just a note that I should call support if I run
abc product or other products of abc type.
• What has to be up before I start the product
• How do I start the product - what are my choices?
• If there are multiple products in the suite, what are the start
dependencies, if any?
• If there are multiple products in the suite, what are the start
timing/order dependencies, if any? We have a group of 5 products, same
vendor. 3 of them are very picky about start order and each must be fully
initialised before the next on starts. Had to figure that on out without
vendor assistance. I built a batch that handles starting those products.
• What happens if one of products the product is dependent on crashes
• How do I run the product - STC, under TSO, VTAM appl, local non-SNA green
tube? - what are all of my choices?
• How many instances of the product can I run in one lpar at the same time
• Are there any product library name dependencies on the product library
names? I have one product that requires that its load modules be in the
product load library and that the entire load library dataset name, except the
HLQ, be exactly as shipped. Of course, that wasn't documented. I needed to
get a new version into the production lpar and had planned to add the product
list into to linklst. For unrelated reasons, I couldn't do that on change day,
so I loaded the contents of the product load library into a nearly empty
linklst library in front of all of the ISV libraries and refreshed. The
product wouldn't work. Had to back it out.
• Are logger datasets required or can the product use regular datasets
instead?
• What are the shutdown options? I have several products that I can issue a
F stc,shutdown and it will finish what it's doing and shutdown gracefully, or P
product for it to save its status and shutdown immediately. On the next start
up, it will pick up right where it left off. Or I can issue F stc,ABEND and
down she goes - now. Very handy. Then there is this other product - to shut
it down, log on as an admin, close out its log, run a job to copy out the
closed log, then log out with a shutdown option which submits a batch job to
finish the shutdown - royal pain that one.
• If/when the product gets into trouble, what are the data gathering,
internal trace, dump options? Are there programs to run against the gathered
data? Some products have some great features along these lines.
• Please include message modification and message routing options where you
can. For some of our products, I push most messages to syslog only, sometimes
I move something that most folks would handle with their automation product to
the console and highlight it. One of our products would get into grief every
once in a blue moon. The greener operators didn't handle it well, as cost us
an outage or two. I modified the message, to include a follow procedure Z
instruction - no more problems.
Also, while many shops have automated ops, many others don't .
Thanks,
Linda Mooney
----- Original Message -----
From: "Charles Mills" <[email protected]>
To: [email protected]
Sent: Tuesday, September 28, 2010 7:19:36 AM
Subject: Re: Really dumb IPL question
Thanks for your kind words. It's easy to feel beat-up here no matter what
you say or do.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Peter Nuttall
Sent: Tuesday, September 28, 2010 7:03 AM
To: [email protected]
Subject: Re: Really dumb IPL question
Hmm ... I worked for a software company as a consultant in a previous life
... Client-server app builder ... They used an IP listener to manage the
upload/download of the application software ... Setting this up as a
started task and then explaining to Ops/Automation that the only way to
stop it was to Cancel the Started task was not fun (against their
operational procedures) ....
However, Credit to Charles for putting these questions out there and
attempting to get a common approach ....
"Charles Mills" <[email protected]>
Sent by: "IBM Mainframe Discussion List" <[email protected]>
28/09/2010 03:51 PM
Please respond to
"IBM Mainframe Discussion List" <[email protected]>
To
[email protected]
cc
Subject
Re: Really dumb IPL question
Thanks, Barbara. I admit I had given no thought (so far) to this issue.
I'm
going to start a new thread on this topic.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf
Of Barbara Nitz
Sent: Monday, September 27, 2010 9:47 PM
To: [email protected]
Subject: Re: Really dumb IPL question
>Since you say it can handle waiting for TCPIP on it's own, what's the
>diff? If I want it during limited function "system checkout time" I'd
>use COMMNDxx. Otherwise the automation.
To reiterate: The difference is shutdown. If TCPIP services are needed for
successful shutdown, then the product MUST be shutdown before TCPIP
services go away. Or there needs to be a lot more code to test that IP
services are always available and to handle a graceful shutdown in the
absence of TCPIP.
Barbara Nitz
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
This e-mail message, including any attachments transmitted with it, is
CONFIDENTIAL and may contain legally privileged information. This message is
intended solely for the use of the individual or entity to whom it is
addressed. If you have received this message in error, please notify us
immediately and delete it from your system. Please visit our website to read
the full disclaimer: http://www.euroclear.com/site/public/disclaimer
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
