Chris > > [1] Your presentation doesn't actually mention a SCHEDxx entry as an > > alternative to or override for a PPT entry - tut! tut!.
> Erm... tut me no tuts! PPT entries are defined in SCHEDxx. Erm. How about actually adding some value to the "correction" rather than merely highlighting an obvious contraction that became inaccurate as a consequence? What I should have said - as, grey beard that I believe you are, you should have seen instantly - is the following: "Your presentation doesn't actually mention a SCHEDxx PPT entry as an alternative to or override for a PPT module entry." If you had taken a bit more trouble with your post, you might have offered something like this as the "correction" instead of just the sort of point-scoring beloved by "Dr No" - who has recently got himself taken of someone else's Christmas card list as well as confirming his absence from that of another of the "usual suspects". Assuming you have been following the thread with the disingenuous subject "Really dumb IPL question" of which this subthread is a part, you would have seen that I got the point over with greater accuracy on 29 Sep 2010 in the form of the following: > ... > ... specific "attributes" set using an entry in the PPT module, > possibly overridden by a PPT entry in the SCHEDxx member of SYS1.PARMLIB, ... The purpose of my comment this time and before was to point out all the places where these "attributes" associated with a program are to be found. Previously the poster had ignored the IEFSDPPT module PPT entries >...> ... is to have its program controlled by the PPT (SCHEDnn member of PARMLIB) to set specific attributes ... or, now I look at it again, may have had both the IEFSDPPT module and the SCHEDxx member in mind but was just not as clear as I would wish. I had assumed that, this time, the SCHEDxx member not being mentioned, that the IEFSDPPT module was being promoted to the detriment of the SCHEDxx member. The truth is more ambiguous since the term "PPT entry" as used in the presentation material can apply to both. Who knows, Edward may have had the SCHEDxx member in mind and have forgotten all about the IEFSDPPT module - possible but unlikely I expect. Being presentation material without attached notes, it may also be that the PPT story was explained clearly but verbally during the presentation. If this is the way it was done I, of course, unreservedly remove my "tuts". Nevertheless I suggest that adding a line item in the presented page the first time PPT is mentioned along the lines of * Either as an entry in the IEFSDPPT module of SYS1.LINKLIB[1] or an entry in the SCHEDxx member of SYS1.PARMLIB is in order. Not, of course, for your benefit or Edward's, it may be worth covering the point at some stage that the reason there are two places where these "attributes" can be specified - statically! - is because the MVS developers imagined that they didn't need to bother making something they could very well ram down the users' throats something with which they could easily mess. Wrong - as always. I remember well having not only to zap bits in the IEFSDPPT entries but also to fiddle with the object module size in order to add entries.[2] What a messy way of going about things - almost as bad as changing the "TCP/IP for MVS" "high-level-qualifier" in the early days of the product. - But you have managed some "added value" by pointing out that, in addition to being able *statically* to specify at least the CANCEL/NOCANCEL "attribute", you can specify "attribute(s?)" *dynamically*. Unfortunately I can't quite follow whether this is an usual or an unusual step to take and hence how common a problem it might be. I would expect that because of the esoteric nature of the programming involved it would be lie on the *unusual* side. What this means for automation is that, in preparing to support the management of any particular program's address space, having found no MODIFY,(shutdown) or STOP option, you might well discover the appropriate way to manage shutting the program down is CANCEL or FORCE ARM by checking the IEFSDPPT module and the planned SCHEDxx member. However at the absolutely unavoidable testing stage, you might find that the developer has played the tricky card of setting NOCANCEL dynamically - or, there being no limit to tricky programming or programmers, of resetting to CANCEL! - > Note that if an address space is marked non-cancelable, there's usually a good reason. The developer who passed the requirement on to the developers managing the IEFSDPPT module for a particular release of these days z/OS may have ***imagined*** he - or she, the female of the species is equally likely to get it wrong - was asking them to set up the NOCANCEL bit for "a good reason". There is no guarantee whatsoever at all in this world that he or she actually understood what he or she was doing. It may be a good idea to set the requirement "in stone" in the IEFSDPPT module or it may not. It may actually have been better to have the possibility documented in the appropriate manual as a specification in the SCHEDxx PPT entry and actually - shock, horror! - let the user - belonging to the organisation actually *paying* for the product - decide.[3] Of course, I have a particular example in mind: the Communications Server (CS) TN3270E server program, newly released from the confines of the main address space into its own address space at the time of z/OS V1R6 and imposed at the time of V1R9. I imagine - to some extent have heard from reliable sources - that what happened here is that, having "gone to town" on the possibilities for customising the TELNET statements - statements such as LUMAP - some customers with bulging wallets severely compromised the structural integrity of the table at which they were sitting opposite their IBM representatives regarding not having to process this mass of customisation every time they needed to restart the main CS address space - particularly in an emergency with end-users frustratedly pounding keyboards. Unfortunately the CS IP developers imagined that this applied to *all* users of CS IP and so just copied the PPT "attributes" from the entry for CS IP main address space program to the entry for the TELNET address space program (the TN3270 server) - except the requirement for "all private area sort-term and long-term fixed pages assigned to preferred (nonreconfigurable and non- V=R) storage frames" to which requirement it would appear some thought was actually given. 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? It's possible to divine what happened by checking the CS IP Configuration Guide. In V1R6, the separate address spare for the TELNET program is introduced. Interestingly enough the imposed PPT entry (in IEFSDPPT, of course) is described as follows in the section 2.2.1.1.5, "Telnet in its own address space": <quote> The MVS default program property table (PPT) has the Telnet module set up as privileged, non-swappable, non-cancelable, running in key 6, and system task. These settings give Telnet the same priority as the TCP/IP stack. Either privileged or system task cause the started job to be assigned to the SYSSTC service class. The priority can be changed by assigning the job name to another service class within the STC subsystem. </quote> The equivalent text in V1R7 is expanded in a very interesting way. Can anyone detect a whiff of cordite?: <quote> The MVS default program properties table (PPT) has the Telnet module set up as privileged, non-swappable, non-cancelable, running in key 6, and system task. These settings give Telnet the same priority as the TCP/IP stack. Either privileged or system task cause the started job to be assigned to the SYSSTC service class. The priority can be changed by assigning the job name to another service class within the STC subsystem. Tip: The default PPT entry sets the TN3270 server to non-cancelable. As a non-cancelable application, the TN3270 server should not be started automatically by a TCP/IP stack using the AUTOLOG function. If the TCP/IP stack is recycled, the following messages will be issued repeatedly: N 0140000 SA6I 2005147 04:59:27.69 STC07087 00000084 EZZ0621I AUTOLOG FORCING IBMTNSI0, REASON: TCP/IP HAS BEEN RESTARTED NR0000000 SA6I 2005147 04:59:27.71 STC07087 00000080 IEE838I IBMTNSI0 NON-CANCELABLE - ISSUE FORCE ARM To prevent this, specify NOAUTOLOG on the PORT reservation statement as follows: PORT 23 TCP TN3270D NOAUTOLOG ; TN3270 server </quote> Is there any mention of now dealing with the requirement of managing the TELNET address space some other way? Well, no! Of course - trying now to be as polite as possible but under enormous strain - the ladies and gentlemen developers and authors appear to have understood that those customers who actually needed the separate address space because of their burgeoning generally TN3270 definition statements would not for a moment consider putting their new TELNET address space program in the AUTOLOG list. However did they try to understand those customers who are just "going with the flow" and who have tamely set up this new address space - like mountaineers climbing Mount Everest - simply because "it is there" quite reasonably assumed - either because their eyes glaze somewhat when faced with descriptions of a PPT entry or because they didn't appreciate the connection between "non-cancelable" and the AUTOLOG mechanism - that, just like all their other server address spaces since Noah found dry land[4], the new server should be set up in the AUTOLOG list - and NOAUTOLOG should *not* feature in the associated PORT statement entry? In other words the remedy for customers who actually saw some merit in the traditional approach to the appearance of a new, independent, no longer "internal client" (INTCLIEN), server was ***NOT*** to suggest discontinuing the AUTOLOG means of automation but to get rid of the - in the case of this "less vocal majority" of customers - pesky <expletives deleted> NOCANCEL "attribute" and to create a SCHEDxx PPT entry - as follows: PPT PGMNAME(EZBTNINI) CANCEL KEY(6) NOSWAP PRIV SYST I hear myself saying to those responsible for that so-called "Tip": "There now, that wasn't too difficult, was it?" Checking on following releases, the manual authors keep fiddling with this "Tip". One might just suppose that there is a some failure of communication - too many links in the chain perhaps - where there are complaints recorded regarding this topic and that the "Chinese whispers" distort the complaints such that the attempted corrections do not address the real problem - or issue! In the next release, V1R8, the instruction to specify NOAUTOLOG on the PORT statement entry for the TELNET address space program has mysteriously disappears! In V1R10, there is a "clarification" which is to change "If the TCP/IP stack is recycled, the following messages will be issued repeatedly:" to "If the TCP/IP stack is recycled, the stack tries to cancel and restart all AUTOLOG applications. A non-cancelable application does not end and the following messages are issued repeatedly:" - Now, just to be clear, with the specification of the SCHEDxx PPT entry above which specifies precisely the same as the IEFSDPPT entry for program EZBTNINI with the sole exception of NOCANCEL changed to CANCEL, it is possible to support the address space running the TN3270E program just like server address spaces have always been supported using the AUTOLOG mechanism. QED. Chris Mason [1] I couldn't recall whether IEFSDPPT was a CSECT or a module (or possibly both) and whether it was to be found in SYS1.LINKLIB or elsewhere so I checked in the V1R12 bookshelf for "IEFSDPPT" and found the following very helpful section in the z/OS V1R1 Distributed FileManager Guide and Reference, SC26-7395-01, manual: <quote> 3.4.3 Verifying PPT Entries for Distributed FileManager To execute correctly, DFM must have entries in the system program property table (PPT). These entries are automatically included in the base PPT for your installation (system LINKLIB member IEFSDPPT). If the need arises to override this base PPT, you can add the entries to system PARMLIB member SCHEDxx (for example, SYS1.PARMLIB(SCHEDxx)). For a sample of the entries, see Appendix I, "PPT Entries for Distributed FileManager" in topic I.0. PARMLIB (SCHEDxx) members for these sample entries should not be created without prior discussion with your IBM service representative. </quote> [2] Wasn't that part of IMS installation long, long ago? [3] Since we appear to be in the business of "amusement and reading pleasure", here's something I found while trying to check whether IEFSDPPT was a module or a CSECT: z/OS V1R12 Communications Server, IP Messages: Volume 4 (EZZ, SNM), SC31-8786-13 <quote> EZZ9299E RESOLVER INITIALIZATION FAILED - RC rc RSN rsn ... Return code (decimal): 12 Reason code (hexadecimal): 00000000 Explanation: MVS PPT entry for EZBREINI is missing or incorrect. Corrective action: Ensure that IEFSDPPT was correctly installed, and that there have been no SET SCH=xx commands entered that would override it, and restart the Resolver. </quote> As is said in what where I sit is mainly an adjacent "geography": "Vertrauen ist gut, Kontrolle ist besser!" If it is possible to manipulate the PPT entry in storage dynamically, shouldn't the clever folk responsible for the CS IP Resolver simply have made good any damage they found? Perhaps it's necessary that there is already a control block in place which it seems logical might not be the case if no IEFSDPPT entry was defined or no SCHEDxx PPT entry was defined. However your logic snippet implies that there always is a "CSCB" with which to tinker. I guess another problem could be that it may not always be a good idea for the program to have the necessary authority to meddle. [4] Actually it was probably a bit wet, but at least it was land. On Wed, 6 Oct 2010 23:25:10 -0500, Chris Craddock <[email protected]> wrote: >On Wed, Oct 6, 2010 at 9:45 PM, Chris Mason <[email protected]> wrote: > >> Edward >> >> I detect some failure properly to make an effort to understand the point >> *I* >> was trying to make! >> >> <snip> >> [1] Your presentation doesn't actually mention a SCHEDxx entry as an >> alternative to or override for a PPT entry - tut! tut!. >> > > >Erm... tut me no tuts! PPT entries are defined in SCHEDxx. In any case I >submit for your amusement and reading pleasure the following brute-force >alternative that doesn't require a PPT entry at all. It assumes certain >things about the environment and current state that I won't bother to >enumerate but suffice to say this, or something close to it is far more >likely to be used by the ISV cognoscente. So the idea of rattling through >the PPT would likely leave non-cancelable ISV products undiscovered. > > > L R1,PSATOLD -> Current TCB > USING TCB,R1 TCB map > ICM R1,7,TCBJSCBB -> JSCB > USING IEZJSCB,R1 JSCB map > L R1,JSCBCSCB -> Current CSCB > USING CHAIN,R1 Map CSCB > NI CHACT,255-CHCL Mark this STC non-cancelable > >(there's another bit elsewhere that makes the address space non-forceable >too, but I probably shouldn't elaborate on that) Note that if an address >space is marked non-cancelable, there's usually a good reason. Issuing FORCE >(with or without ARM) against an address space in that condition should >rightly be seen as loading the gun and aiming it at your foot. If you're >lucky you'll miss. ---------------------------------------------------------------------- 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
