Chris > 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".
We may have to leave our readers to decide whether something which stands a strong risk of being changed with each release of z/OS is "archaic" or not. > I don't know much about Communications Server in particular, ... This could be the source of a lot of misunderstanding. I will try to compensate for this deficiency where necessary. > ... but I do know a little bit about z/OS internals and systems management products in general. It's at the heart of my irritation in having NOCANCEL "imposed" that the Communications Server (CS) IP component has its own generally effective quite simple - some may say simplistic - bit of "systems management" support. > I can't comment about whether the CS components really need to run with NOCANCEL. We - at least I - am discussing a particular CS component, the actually misnamed TN32760E server program, misnamed because it also supports raw TELNET as well as 3270 TELNET. > I *can* comment on the technical reasons why a server address space might need to run that way. And your comments are well received. > I don't know whether the TN3270E server has those attributes or not. The TN3270E server acts as a cross-over point for a TCP connection - acting as a "listening" server - to an SNA session - acting as a secondary logical unit (LU). When supporting an appearance as a 3270 device to an application such as CICS or TSO using the VTAM API the data supported throughout is the 3270 data stream. This is a quite simple task to perform and these days - in sharp contrast to its early days - is supported by parameters controlling every last aspect of the operation of this cross-over point. There are only two APIs involved: the VTAM API is very straightforward and the TCP API is very straightforward. There are no references to other address spaces.[1] I am not aware of any parameters which indicate that anything very special is happening which could suggest any special use of MVS interfaces. For example, CICS requires a particular VTAM specification, SRBEXIT=YES, on the APPL statement which indicates striving for a performance advantage. It can't be guaranteed, but I would expect any striving for performance advantages by employing - let us call them - the more advanced MVS facilities could very well show up somewhere in the definitions for the TN3270E server. On balance, I deem it most unlikely that anything is to be found in the now separated TN3270E program logic other than straightforward use of the two APIs. > Do you? Questioned address already if not definitively answered. I think I'll see if I can't get it answered through some contacts I still have - and maybe the IBMTCP-L list - somewhat along the lines of "What MVS facilities does the TN3270E server use which could justify NOCANCEL?" - and hope the developers don't see or hear the blade falling! > Or more directly, do you know for sure that they don't? As above. > And does it really matter? Oh yes it most certainly does - or I wouldn't be spending anything like so much time discussing it and taking up so much or your valuable time as well - and that of and those still following with baited breath. This is where being familiar with the CS IP component is rather important. It's all in this paragraph from my earlier post: >...> The "requirement" they did *not* consider sensibly was the NOCANCEL "attribute". For those customers with the sore fists it indeed made sense not to include the program for the newly liberated TELNET address space in the AUTOLOG list - an action usually undertaken for any server program since the beginning of recorded time - but what about the less vocal majority? We are not talking about operators entering a CANCEL command here - as if they dare! We are talking about the AUTOLOG function in the CS IP component which is a crude but effective subsystem management function there to try to guarantee that a server program address space is always running to handle clients. The CS IP component checks that the TCP "listen" port is working. If it is not, there being no provision for individual instruction over how to shut down the server program in an address space - a deficiency you may say and I may even agree with you - a CANCEL command is used. This AUTOLOG function operates only when the name of the server started task procedure is present in the AUTOLOG statement list. Normally a customer will put any server started task procedure name in this list where the nature of the program, a server according to the traditional client-server model, is to take a client's request, get on with it and end the transaction. If the server is not "listening" on the TCP port which the clients use to initiate a transaction, it is a waste of (address) space! As such it needs to be flushed out of the system and set up afresh - according to the simple concepts behind the AUTOLOG list which customers have, by and large, found satisfactory for the best part of 20 years. Oh yes, it really matters! > ... but I can tell you that those big-gun decisions are never made by accident. I already explained that the "accident" was because there was a split of function and the decision needed to be made positively to make a change from NOCANCEL to CANCEL. It was an "If we can't see that it's broke, we ain't goin' to fix it!" lack of decision. That's an "accident". I believe your concept is that, there is only a decision to set NOCANCEL, the default being CANCEL. That may not be so in every case - as I explained - please take the trouble to read what I say very carefully. It all there already! > Giving users a "choice" between things they don't really understand isn't really being helpful to them. Supposing that the user isn't going to understand looks like the sort of overweening arrogance I suffered at the hands of Sterling so-called Commerce. It was absolutely beyond their comprehension that a mere user could actually - unimaginable shock, horror - know as much or more about the interface they were misusing as they - actually the support folk, not even the misguided developer him/herself - did. > 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? Quite clearly and obviously not. However, crediting the user with some intelligence that - shudder - might even exceed that of the developer him/herself and if an enterprising user has the opportunity to make the choice, it's as well to explain why such a choice should not be taken and even do what the CS IP Resolver component appears to be doing which is having a peek at the relevant bits and putting out a polite message about a wrong choice having been made - somehow. > The garden variety things that server address spaces tend to do are likely to result in dependencies between the server space and its clients. You've hit on a problem with terminology here and "TCP/IP for VM", its successor product "TCP/IP for MVS" and now the CS IP component, all assist with enriching that confusion. With these IP-based products running in VM and MVS, there are two "flavours" of the "client-server" model: 1. The traditional client-server model strongly in the IP context and less so in the SNA context involves a communication path between the client and the server over a communication medium - and may very well involve geographical separation. 2. The CS IP component - and the "TCP/IP for whatever" products - also operate a client-server model where there - ignoring recently introduced complications - is a single SERVER address space which controls what might be described as kernel functions such as driving interface, managing the routing table and supporting the APIs, especially in the latter case, operating TCP. There are now a number of CLIENT address spaces which depend on the SERVER address space. The TN3270E program operates as a server according to "flavour" 1 and a CLIENT according to "flavour" 2. It is actually because of this "flavour" 2 role that the TN3270E function used to be described as an "internal client" (INTCLIEN) before it was separated from the main CS IP address space. I'm not even sure that clarification was really necessary. Anyhow with that clarification mind, I hope you can see that there is nothing special in the relationship between the TN3270E server program and the main CS IP address space and that the server program needs only to use the documented API to be a TCP server. Do recall that, until UNIX System Services came along to cause the odd complication with some of these server functions, all the "TCP/IP for MVS" and CS IP component server address spaces and many still today are perfectly happy to be controlled through the AUTOLOG function and, also still today, the documentation steers the user to managing these server address spaces using the AUTOLOG function. > If you blow away the server you're very likely to leave the clients in a damaged state. What I have just explained means that the rest of your paragraph is irrelevant. According to "flavour" 1, the clients will suffer communication timeouts which you may be sure is "par for the course". According to "flavour" 2, the server is indeed vital but is *not* the server we have been talking about but the CS IP address space which I am perfectly happy can retain its NOCANCEL status until the crack of doom. > An impatient operator with an itchy trigger finger ... I am not concerned with real human operators with any sort of finger complaint. rather I refer to a generally handy piece of crude but well-tried automation which seems to fit the context in which it is used, namely that of the CS IP AUTOLOG component. > 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. I'm unclear how I could have led you to consider I might have suggested otherwise. The arrogance is in not troubling to explain why something is necessary when you should be aware there are benefits to be had from not having that something. Or maybe there is no actual reason? Not in your case obviously since I'm sure you do not set restrictions lightly - but I mistrust the CS IP developers in the case of the TN3270E server and I'm pretty sure they got themselves into a corner and having dug a small hole, found themselves digging a bigger one - madly mixing metaphors! > Why are we even debating this? Because many a customer would be delighted to be able to use the well- regarded AUTOLOG function for the TN3270E server as well as for all his/her traditional server functions among which the newly liberated TN3270E server fits well. Please take the trouble actually to read my earlier posts. As I indicated in my previous post, there is a subset of customers who will want not to have operators cancelling the TN3270E address space because it just takes sooooo long to get started and it may not be necessary also to have a restart of the TN3270E server address space. The consideration here is not so damaging the system that an IPL is needed to resolve the mess but possibly to allow the user community to become productive more quickly following an unplanned failure of the main CS IP address space. For this subset of customers judicious setting of NOCANCEL in a SCHEDxx member PPT entry is the obvious solution. > 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? Once again, we are not taking about operators who need a salve on their fingers but a systems programmer planning the installation of CS IP and its related bits and pieces who has been duped into imagining he/she cannot use a well-loved function by developers who have made a mistake - or I - and they - need to see an explanation of how a tame server function could be so "precious" that it needs "cancel" protection. Chris Mason [1] Actually the CS IP Resolver address space is used somehow through some private sort of API. That this cannot be any sort of problem is that it is used by many other "server" functions all of which can be chopped off at the knees at any time with no ill effects. On Tue, 12 Oct 2010 11:26:50 -0500, Chris Craddock <[email protected]> wrote: >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. ---------------------------------------------------------------------- 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
