John I have been reminded in another thread - where the topic of the "program properties table" (PPT) arose - that I missed a point when I suggested what was minimally required in order to split off the TN3270E server.
There have been no replies so I guess you didn't try my suggestion. There is another probably necessary change so I'll mention it in case anyone uses the archive in order to see what has to be done in order minimally to split the TN3270E server from the main Communications Server (CS) IP address space. Note that there is a lot of explanation following - including an indictment of the IP developers - but the customisation work needed is trivial. - It may be that you have an entry in the PORT statement list similar to the following: PORT ... 23 TCP INTCLIEN ; Telnet 3270 Server ... It was never absolutely required that this is specified and, after the introduction of the TCPCONFIG and UDPCONFIG statement RESTRICTLOWPORTS parameters, diligent system programmers may have taken the trouble to remove pointless entries from their PORT statements lists. However, from the time that the TN3270E server function becomes a separate address space, this entry is no longer appropriate. Now the question is "Do I just remove it or do I replace it?" This is where the "program properties table" entry for the TN3270E program, EZBTNINI, matters. What also matters is the extent to which you have invested in implementing "client identifiers" in the customisation of your TN3270E server and possible whether you have an automation package of some sort to help keep your system running. If 1. You have a large number of statements in your TN3270E customisation so that it takes "for ever" to initialise the TN3270E server address space - previously the CS IP address space itself 2. You have some automation package available you do not need a PORT statement entry - for the purposes of automation - because you will not be tempted also to specify the name of the TN3270E server started task procedure name in your AUTOLOG statement list. Even if you do not have some automation package available but you are prepared to start the TN3270E server manually when necessary, typically only during the IPL sequence, the same can apply - no PORT and AUTOLOG statement entries are needed. If you are using an additional capability of the PORT statement such as the BIND parameter perhaps for the purposes of using port number 23 for both the TN3270E server and the otelnetd daemon, obviously, you need the PORT statement entry in such a case. If you have a small number of statements in your TN3270E customisation so that it takes only the blinking of an eye to initialise the TN3270E server address space, you might like to benefit from the automation built into the CS IP main program which has always from the dawn of TCP/IP for MVS provided the AUTOLOG function in order to keep server (quixotically referred to as "client"[1]) address spaces active whenever the CS IP main address space is active. Thus you should change the PORT statement entry for, typically, port number 23 and specify the name you have decided on for the TN3270E started task procedure, say TN3270E: PORT ... 23 TCP TN3270E ; Telnet 3270 Server ... or - just to encourage some "good practice" PORT ... 23 TCP TN3270E BIND 10.1.1.1 ; Telnet 3270 Server ... where 10.1.1.1, that is whatever VIPA you have assigned to the TN3270E service, is assigned in your name servers to the name your clients use to access your TN3270E service. You will also need an entry in your AUTOLOG statement list as follows: AUTOLOG ... TN3270E ... ENDAUTOLOG This will ensure that the TN3270E server address space is started shortly after the CS IP main address space is started and that the TN3270E server is kept active *only* when port number 23 is in a TCP "listening" state. In the manuals you will find all sorts of "warnings" about *not* doing this for the TN3270E server. Why? Well, I think it's an initial lack of imagination followed by a combination of laziness and arrogance on the part of the developers. What I think happened is that when, in V1R6, the possibility to run the TN3270E server as a separate address space was introduced, the developers, faced with the problem of what to specify for the "program properties table" entry for the new program, EZBTNINI, decided that, not to have to think about it too deeply, they would use much the same characteristics as used by the main CS IP program, EZBTCPIP. From the description of this decision given in the V1R6 Configuration Guide <quote> The MVS default program property table (PPT) has the Telnet module set up as privileged, non-swappable, non-cancellable, 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> it seems that they worried themselves over priority but gave nary a neuron to the fact that they had converted an *internal* client[1] address space to an *external* client address space, in support of which their ancestors had provided the o-so-handy AUTOLOG function. Then the balloon went up! The customers who jumped on this tidy enhancement, as could have so easily been predicted, immediately set up their TN3270E servers with an entry in the AUTOLOG list and gasped in horror - I may be exaggerating slightly! - as they found that the TN3270E address space could not be cancelled when the main address space was "recycled" for whatever reason. It is in the V1R7 manuals that we find the developers having to explain that, since they had made EZBTNINI "noncancellable", the AUTOLOG function would not work. How to solve the problem? To the paragraph above was added the following: <quote> Tip: The default PPT entry sets the TN3270 server to non-cancellable. As a non-cancellable 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> I think they must have found a Homer Simpson clone to write that. I see that, by V1R8, the NOAUTOLOG advice disappeared! There's nothing in its place so I expect the developers reckoned that, mentioning the "noncancellable" attribute provided sufficient of a hint that the TN370E server started task procedure name should just not be specified in the AUTOLOG statement list, What, of course, the developers did not manage to work out was a solution which could be expressed as the addition "if you do remove the "noncancellable" attribute" - under their wiser breath - "which is causing all the <expletive deleted> trouble in the first place!!!" I think this is where the arrogance came in. It would have been so easy and so logical to have provided the advice to override the "noncancellable" attribute with an entry in the SCHEDxx member of SYS1.PARMLIB - but that would have meant admitting to a blunder! For customers who see merit in using the AUTOLOG function, the way to solve the problem is as follows: The internal PPT entry currently specified for the EZBTNINI program maps to the following SCHEDxx member PPT entry: PPT PGMNAME(EZBTNINI) NOCANCEL KEY(6) NOSWAP PRIV SYST In order to have precisely the same attributes but without the interfering "noncancellable" attribute, simply place the following entry in your SCHEDxx member: PPT PGMNAME(EZBTNINI) KEY(6) NOSWAP PRIV SYST No "NOCANCEL", the most QED among QEDs!!! - The developers have a defence of sorts in not supporting the AUTOLOG function. It is said - as I emphasised above - that, when there is extensive TN3270E server customisation, it makes sense not to subject the now independent TN3270E server address space to the manipulation it can suffer when included in the AUTOLOG function. For all I know - and it is very likely - the main customer requirement satisfied by the tidying up process of having a separate TN3270E address space may well have been customers with extensive customisation who deplored the time taken to get their CS IP up and running when the TN3270E function was embedded. To my mind that is not an excuse which washes with those customers who are happiest with CS IP doing all the IP-related automation for them. Chris Mason [1] The "client/server" relationship here is that between the address spaces, what, in application terms, are "server" address spaces are "client" address spaces to the main CS IP address space as the, one can say, "master" "server" address space. It is only with this sort of sophistry that one can explain the now defunct token "INTCLIEN" standing for "internal client". On Thu, 11 Feb 2010 21:31:38 -0600, Chris Mason <[email protected]> wrote: >Wayne > >> It was possible to separate these functions earlier, but if you haven't, >> that >would be the first thing to look at. > >Droll! Understated to a T! > >- > >John > >"Digging in the install docs" could have revealed the following for you: > >z/OS Communications Server IP Configuration Guide Version 1 Release 8 > Chapter 10. Accessing remote hosts using Telnet > TN3270E Telnet server > ><quote> > >Getting started > >Whether Telnet is running within the TCP/IP stack or in its own address space, >the following steps must be taken to start a Telnet session: > >1. Set up VTAM LUs for use by Telnet. >2. Start Telnet, either with TCP/IP or in its own address space. >3. Start a client emulator and log on to a SNA application. > ></quote> > >But in Version 1 Release 9 > ><quote> > >Getting started > >Perform the following steps to start a Telnet session: > >1. Set up VTAM LUs for use by Telnet. >2. Start Telnet. >3. Start a client emulator and log on to a SNA application. > ></quote> > >Note the lack of choice! > >In Release 10 there is a rewrite and so in place of "Getting Started" in the >Release 10 and 11 manuals, you find the following: > ><quote> > >Steps for starting the TN3270E Telnet server > >... > >Perform the following steps to start the TN3270E Telnet server: > >1. Create a new data set member in your procedure library for the TN3270E >Telnet server JCL. > >A sample procedure is in SEZAINST(EZBTNPRC). ... > ></quote> > >I've an idea that you can simply take your existing PROFILE data set and copy >it as the PROFILE data set of this new procedure. The basic Communications >Server IP program just ignores the TN3270E statements - hence the >frustration with your clients - and the new TN3270E program *only* bothers >about the TN3270E statements - I think. Give it a try and see if it is that >simple! - and, of course, let us know so we can advise future list subscribers >who have also somehow missed the furore over splitting out the TN3270E >server function. > >Chris Mason > >On Thu, 11 Feb 2010 15:23:12 -0600, Wayne Driscoll <[email protected]> >wrote: > >>IIRC, in z/OS 1,9 the TN3270 server process was no longer supported in the >>stack, but had to be run in it's own address space. It was possible to >>separate these functions earlier, but if you haven't, that would be the >>first thing to look at. >> >>=============================================== >>Wayne Driscoll >>OMEGAMON DB2 L3 Support/Development >>wdrisco(AT)us.ibm.com >>=============================================== >> >> >> >>From: >>John Mattson <[email protected]> >>To: >>[email protected] >>Date: >>02/11/2010 03:14 PM >>Subject: >>Rumba on zOS 1.11 telnet connection refused >>Sent by: >>IBM Mainframe Discussion List <[email protected]> >> >> >> >>I am going from zOS 1.8 to 1.11 and have most of it up and running. >>One problem is that Rumba, Hummingbird, and other TN3270E apps get their >>connections refused by zOS 1.11. I have dug in the install docs, and >>applied the RACF updates in the ServerPac. My only guess is that >>something has tightened up the security. Anyone help? ---------------------------------------------------------------------- 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
