Awesome! Yes! Thank you, thank you, thank you. This is great. This should be required reading for every vendor. Mainly, this should be made available to every vendor.
Some of your points I knew and were planned for incorporation in my current project; some were not. I will consider all of them. Judging from some of the posts here I think that those of you in the user sysprog community think we software vendors stay up at night trying to think of ways to annoy you. Nothing could be further from the truth. In many cases our compensation is tied (sometimes 100%!) to how well the product sells. The problem is not willfulness or even laziness. The problem is that many of us came up through a development career path, not a sysprog career path. I wrote my first mainframe program in 1968 but I have never been a sysprog. I have never owned catalogs and parmlibs and SMS and RACF and gotten calls in the middle of the night because MVS crashed. I simply don't understand your problems unless, like Linda, you tell me what they are. While I'm on a rant here you in the sysprog community should keep in mind that you are not the entire audience for our products. We don't typically sell to the guy or gal who maintains SYS1.PARMLIB. So in many cases what you think should be in documentation is not what needs to be in there for the guy or gal who will make the purchasing decision (see above, compensation). We'll put in there what you want to see, but please keep in mind that we may have to put other things in there too. Thanks again, Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Linda Mooney Sent: Tuesday, September 28, 2010 5:04 PM To: [email protected] Subject: Re: Really dumb IPL question 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 ---------------------------------------------------------------------- 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
