Mike "Horses for Courses!"
> Seeing subarea 1 is a good reminder you've got rid of the subarea functions > from VTAM. Seeing an identifying subarea number is a good reminder to which system the trace or dump belongs and VTAM maintenance folk will thank you for it! > If you omit HOSTSA you'll get SACONNS=NO. This point doesn't jump out at me from Table 70, "Node type functional summary" and yet I believe you must be right - and I'll have to revise my just created diagrams. In principle the default value for the SACONNS start option is YES - just take a look as the description! - but, in order to reproduce the rules as they applied before the SACONNS start option appeared, not specifying HOSTSA and specifying NODETYPE *must* eliminate external subarea, in other words, SACONNS=NO must be assumed. Time for yet another "reader's comment form"! ----------------------------------------------- | SACONNS | NODETYPE | NODETYPE | NODETYPE | | = | not | = | = | | YES | specified | EN | NN | | (default) | | | | |-----------+-----------+----------+----------| | HOSTSA | pure | pure | pure | | not | subarea | APPN | APPN | | specified | host | host | host | | | | End | Network | | | | Node EN | Node NN | | |-----------+---------------------| | |subarea = 1|internal subarea = 1 | |-----------+-----------+---------------------| | HOSTSA | pure | Migration| Inter- | | specified | subarea | Data | change | | | host | Host | Node | | | | MDH | ICN | | |---------------------------------| | | subarea = HOSTSA | ----------------------------------------------- Chris Mason On Fri, 7 Oct 2011 16:22:19 +0100, Mike Wawiorko <mike.wawio...@barclays.com> wrote: >"For better manageability we recommend defining or keeping a unique subarea >number using HOSTSA" > >There's no benefit in unique APPN-only HOSTSAs that I know except this odd one. > >Some systems we've inherited have automation that examines the subarea number >to decide on actions to take. We've left HOSTSA and coded SACONNS=NO. > >If you look at a network management tool like NetView NLDM or run VTAM traces >of application FID4s you'll see subarea number 1 under the wraps. Seeing >subarea 1 is a good reminder you've got rid of the subarea functions from VTAM. > >"and running VTAM as a pure EN/NN by coding SACONNS=NO." > >Running as a straight APPN node NN or EN, rather than as an ICN or MDH, is the >way to go. If you've inherited VTAMs with subarea and the complex subarea PATH >statements, VRs, ERs and the like it is time to simplify to APPN only. >If you omit HOSTSA you'll get SACONNS=NO. > >Regards, >Mike Wawiorko >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of >Hansen, Dave L - Eagan, MN >Sent: 07 October 2011 15:01 >To: IBM-MAIN@bama.ua.edu >Subject: Using unique HOSTSA (running VTAM as pure EN/NN) = 'Better >Manageability'? > >Group, > > I have been reviewing the Enterprise Extender Implementation guide > (SG24-7359) in Chapter 3 it talks about HOSTSA and SACONNS. It says "For > better manageability we recommend defining or keeping a unique subarea number > using HOSTSA, and running VTAM as a pure EN/NN by coding SACONNS=NO.". The > default HOSTSA is 1 and I see it on a few End Nodes. I did see under ENHADDR > is says "Even with VTAM running as a pure APPN node, internally all resources > are represented using a FID4 subarea address format.". So internally it > looks like it references HOSTSA. I have been trying to evaluate EE > performance and have been doing a lot of different displays. I don't recall > seeing subarea 1 when doing these displays. > >Q). What "better manageability" would the authors be talking about? > > > Thank you in Advance, Dave > > >Dave Hansen >Eagan Software Systems Branch >651-406-1208 >dave.l.han...@usps.gov ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
