On Tue, Oct 12, 2010 at 8:55 AM, Chris Mason <[email protected]>wrote:
> > The archaic IEFSDPPT module is still valid, but for all practical > purposes it is > unusable. > > Unusable for all except IBM would be more accurate - although implied by > your > emphasis on "vendors". As far as I can tell from scanning the section in > the > description of the SCHEDxx member in the Initialization and Tuning > Reference > manual, IBM routinely specifies its real or imagined requirements in > PPT "entries" in the IEFSDPPT module. That tends to challenge your use of > the > adjective "archaic". IBM does continue to "use" IEFSDPPT for some things that only take effect at IPL time. However that isn't terribly flexible or useful for anyone else, so I stand by the term "archaic". > I hope you took the time to appreciate my description of how the > Communications Server (CS) IP component developers and authors had got > their undergarments in a twist over NOCANCEL in the case of the TN3270E > server. > I don't know much about Communications Server in particular, but I do know a little bit about z/OS internals and systems management products in general. I can't comment about whether the CS components really need to run with NOCANCEL. I *can* comment on the technical reasons why a server address space might need to run that way. I don't know whether the TN3270E server has those attributes or not. Do you? Or more directly, do you know for sure that they don't? And does it really matter? > > It is not very common to make address spaces non-cancelable and the > reasons for doing so are usually technically > deep. > > ... or maybe the reasons are accidental because<snip> I can't speak for all software developers but I can tell you that those big-gun decisions are never made by accident. At least not by the major software vendors. There are too many folks looking over your shoulder and second guessing everything you do. Not unlike ibm-main in that respect :-) > Again we have developer arrogance in not leaving it up to the user as to whether or not to allow the user to "advise" his/her > operators > over cancelling the address space by allowing CANCEL or NOCANCEL to be > specified by means of the SCHEDxx member with a proper explanation of the > advantages and disadvantages, including how they relate to the use of the > AUTOLOG facility. > We're just going to have to disagree over this. Giving users a "choice" between things they don't really understand isn't really being helpful to them. Even if the choice is elaborately documented you've added something extra that must be read and understood and actioned and most users don't read everything we give them as it is. If making that choice is of no consequence and it only adds a small amount of work for the user then "ok I guess". But if making the wrong choice can lead to a system outage (or worse) why would you want to have the user make that choice? I would prefer that the software should "do the right thing" for me. You may consider it arrogant and that's fine with me. I have more than enough scars already. > Note that the main CS IP address is one thing and, who knows? - well I > don't > but, of course, the developers do - it may well be that the "tricks" the > main > CS IP address space gets up to are the same or similar to those you > described > in your "concrete" example. Perhaps so and as you say, you don't know. Nor do I. BTW> The "tricks" I was referring too aren't especially tricky. The garden variety things that server address spaces tend to do are likely to result in dependencies between the server space and its clients. If you blow away the server you're very likely to leave the clients in a damaged state. If it is necessary to allow for restart and recovery for such a server space, then the clean way is for the server to accept a STOP command. Upon receipt of that command the server's internal tasks are all still running normally and they can go on about the business of shutting down gracefully. If you use CANCEL or FORCE that's no longer possible. All of the server's tasks are summarily abended and all subsequent resource cleanup has to be co-ordinated through end of task and/or end of memory routines. Trust me when I tell you that accomplishing that is enormously more complex and risky. An impatient operator with an itchy trigger finger can ruin your whole day. If I'm responsible for providing that functionality then minimizing the risk of disaster seems to me not to be the arrogant thing to do, but rather the prudent thing to do. Why are we even debating this? > I can imagine that there are a number of > functions the main CS IP address space could perform which imply NOCANCEL > is a "good idea". However the TN3270E server is just a TCP application with > potentially - not necessarily - a mass of definitions to process on > starting. It > was the time which some customer definition sets needed to get up and > running that prompted the separation of the TN3270 sever application - as > it > should have been from the very beginning when the University of Wisconsin > put the "TCP/IP for VM" program together for IBM. > Once again, I don't know anything about Communications Server. How much knowledge does a typical operator have about the inner workings of the CS address spaces or any other major functional area? Avoiding the need for a non-productive restart of a server address space seems to me to be an equally valid reason to limit the opportunity for operators to blow things away. I would not assume evil (or incompetent) intent. -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- 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
