Tom > >...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.
> So this is the crux of it. The AUTOLOG process that you like to use is not capable of stopping a process except to cancel it. Not really. As I indicated in a number of places, this is a way of behaviour, while a bit crude, which has been well-accepted by customers and which suits the MO of IP-based server functions - as I took some pains to point out. I would prefer it if - in addition, incidentally, to the provision of a character string to be added to the name of the started task procedure - it were also possible to provide character strings for commands to use in order to try first to close down the server address space more gracefully. Against this one must reflect that the CANCEL command may well be used often to deal with a program running in an address space which has gone wrong in some way and so may actually not be responding to commands such as STOP and MODIFY,<close>. Thus CANCEL may not really be such a bad choice after all - and it has stood the test of time, the better part of 20 years. > Arrogance? PKB. Well, you have been very lucky not to encounter a so-called support person who refuses to appreciate that you may have a valid opinion over something that he - in the case I have in mind but it could well have been a "she" - considers himself an expert in and demonstrably is not. Yes, (I think) he knew the product; no, he was incapable of realising that it defied conventional - and therefore expected - behaviour in the use of an API I happened to know really rather well and certainly better than this idiot! Actually as far as knowing his product was concerned, it was impossible really to be sure since he didn't deign to discuss the real problem. If this is arrogance, arrogance doesn't always have negative connotations! I would prefer to think of it as being rightly sure of one's ground. > "Finger complaint"? Very funny. Not. CANCEL is an operator command. The fact that there is other software that is also capable of issuing it does not change that in the least. ... which in this discussion is irrelevant. Whether it is an operator with fingers in any state of health or a "programmed operator" matters not if the program can quite happily be cancelled. > I think CC explained that. It was clear to me. Not to me it wasn't. CAV please. Are you sure you can respond to that if you only "think"? > Software vendors do not generally explain all the details of why the software needs to be set up in the way that it does. Is that a good thing or a bad thing? In this case, it is very clearly a bad thing - as I have been at extreme pains to point out. > ... your previous (lengthy) posts. The posts are "lengthy" because they attempt actually to explain things, a "position" in this case. If you consider that a bad thing, then we must part in disagreement on this point! > If AUTOLOG doesn't know any other way to stop TN3270E the fault is not with TN3270E having NOCANCEL. This is illogical and follows from what was obviously a mistake in putting emphasis on the AUTOLOG mechanism being rather crude. I'm not aware of any Communications Server IP server function which cannot tolerate being cancelled when - either it is sick and its "listening" port has been lost - or - it is still hanging around after a CS IP main address space failure. I have a very strong suspicion that the newly liberated TN3270E server would be equally equanimous if also liberated from the NOCANCEL restraint. Fortunately this afternoon I had the chance to discuss this topic with a colleague who reminded me of another reason that the TN3270E server function was separated from the CS IP main address space. Apparently, apart from the concern that there may be an enormous volume of definition statements relating to the TN3270E server to process during start-up, there was also a general problem with - as he put it - "stability". As a consequence of this concern, the IBM recommendation was to create two instances of CS IP, one responsible for what one might call "kernel" functions - interfaces, routing and the like - while another instance supported the TN3270E function - with some interconnection it isn't too difficult to set up. Apparently, the separate TN3270E server evolved from this recommended structure. Starting from the same program, all that was necessary was to block the TN3270E function in the main CS IP address space and block everything else in the TN3270E address space. All this being so, I believe the developers just copied the PPT entry without giving it too much thought. In support of this I happened - while working up my ire over the so-called session manager support in V1R12 today - to spot in a presentation Communications Server z/OS® V1R5 and V1R6 Technical Update TN3270 Server which you can access through http://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/index.jsp that somehow the customer needed to be told about the PPT entry: <quote> - The latest default MVS Program Property Table (PPT) contains the Telnet procedure. If not using the latest PPT, add a PPT entry into your own table. PPT PGMNAME(EZBTNINI) PPT Program Name NOCANCEL Non-Cancellable KEY(6) KEY(6) NOSWAP Non-Swappable PRIV Privileged SYST System Task (not timed) - These settings are the same as the TCP/IP stack. </quote> It's not strictly true that the PPT "attributes" are precisely the same as "the TCP/IP stack".[1] The TN3270E server misses having all private area short- term and long-term fixed pages assigned to preferred (nonreconfigurable and non-V=R) storage frames - for whatever that might be worth ... Of course, if I still had a "sandbox" of some sort in which to kick sand about I would have tried this all out - just as, when I had my test/education systems, I used to try things out when development were either clearly wrong or could possibly be wrong and, in that latter case, sometimes were or may have been right in some circumstances and not in others - and we could all be taken off tenterhooks! Chris Mason [1] Yuk. What "stack" supports only 3 layers out of 5? - more closely a "demi- stack" - but I'll let that point pass - today! On Wed, 13 Oct 2010 08:10:36 -0500, Tom Marchant <m42tom- [email protected]> wrote: >On Tue, 12 Oct 2010 16:09:43 -0500, Chris Mason replied to CC: > >>...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. > >So this is the crux of it. The AUTOLOG process that you like to use is >not capable of stopping a process except to cancel it. > >>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. > >Arrogance? PKB. > >>> 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. > >"Finger complaint"? Very funny. Not. CANCEL is an operator command. >The fact that there is other software that is also capable of issuing it >does not change that in the least. > >> >>> 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. > >I think CC explained that. It was clear to me. > >>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. > >Software vendors do not generally explain all the details of why the >software needs to be set up in the way that it does. > >>> 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. > >Again, the admonition to read your previous (lengthy) posts. I have >been reading this exchange between you and Chris Craddock with >amusement. Much of what CC writes is over my head, but I often >learn something from reading what he writes. If AUTOLOG doesn't >know any other way to stop TN3270E the fault is not with TN3270E >having NOCANCEL. > >-- >Tom Marchant ---------------------------------------------------------------------- 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
