Useful z/OS Communications Server 'Magic Tricks' …FILE/W21_EXPO2005_SLEEP_MAGIC.pdfIBM GLOBAL SERVICES W21 Gwen Dente Useful z/OS Communications Server 'Magic Tricks' You May Have

IBM GLOBAL SERVICES

W21

Gwen Dente

Useful z/OS Communications Server 'Magic Tricks' You May Have Missed on Your Way to z/OS V1R7

®

San Francisco, CASeptember 19 - 23, 2005

What happened while you were sleeping!

W21_EXPO2005_SLEEP_MAGIC.PRZ Page 1

Copyright IBM 2005C

Well, a lot has happened with Communications Server since z/OS V1R2.

But ... if you were like the rest of us, you were just scrambling to keep your head above water while simply trying to migrate to a supported release. In the process you probably heard or read a lot about all the enhancements in V1R2, V1R4, V1R5, V1R6 -- but did any of this news really register?? Well, probably the really big items did stick with you -- but did you know there were a lot of hidden gems in these releases that could make your life easier?

This session presents practical examples of a pot-pourri of pearls for your Communications Server z/OS implementation. With this knowledge under your belt, you can stop feeling overwhelmed about the impending V1R7 upgrade and feel that playing "catch up" with the previous releases will be a "snap."

Disclaimer: There are no IPv6 and very few Enterprise Extender or Sysplex/VIPA topics in this presentation, as these two subjects have been on the radar screen for quite a while now and are covered extensively in many other presentations. Therefore, you will find some of these items documented in the appendices of this presentation.

Therefore, this session tends to focus on subjects that have been "under the radar" and that have escaped many implementer's attention.

Abstract


Copyright IBM 2005C

While You Were Sleeping: Netstat News


Copyright IBM 2005C

To assist the user in determining where routes in the IP routing table come from, new flags have been added to the netstat route output.

S -- a nonreplaceable static routeZ -- a replaceable static routeO -- a route learned via OSPFR -- a route learned via RIPC -- a route learned by other means

direct connection, OMPROUTE defined default

DESTINATION GATEWAY FLAGS REFCNT INTERFACE .....4.4.4.4 9.67.101.4 UGHO 000000 CTC3TO4 5.5.5.5 9.67.111.3 UGHS 000000 EZASAMEMVS 9.67.101.0 0.0.0.0 UC 000000 CTC3TO4 .....130.200.0.0 0.0.0.0 UC 000000 CTC3TO1 .....197.1.1.99 9.67.102.7 UGHZ 000000 CTC3TO7 197.1.1.99 9.67.111.3 UGHZ 000000 EZASAMEMVS .....

Enhanced NETSTAT Flags z/OS V1R2


1. A route learned by direct connection is a route that OMPROUTE places in the routing table because it is directly connected to a particular network but has not learned about the route using a routing protocol. You may see these routes for the subnet of a point-to-point network, or for the subnet or destination of an interface over which OSPF adjacency is not established.

2. An OMPROUTE defined default route is one defined using the DEFAULT_ROUTE statement in the OMPROUTE configuration file.

3. See more examples of NETSTAT output with the new flags in the routing presentation.

Copyright IBM 2005C

NETSTAT DEVLINKS (INTFNAME OSATRB10MVS TCP/IP NETSTAT CS V1R4 TCPIP Name: NM1ATCP 14:35:31DevName: OSAB10 DevType: LCS DevNum: 0B10 DevStatus: Ready LnkName: OSATRB10 LnkType: TR LnkStatus: Ready NetNum: 1 QueSize: 0 BytesIn: 563521294 BytesOut: 5520044 MacAddrOrder: Non-Canonical SrBridgingCapability: Yes IpBroadcastCapability: Yes ArpBroadcastType: All Rings MacAddress: 08005A8B48CC ActMtu: 17914 BSD Routing Parameters: MTU Size: 04096 Metric: 01 DestAddr: 0.0.0.0 SubnetMask: 255.255.240.0 Multicast Specific: Multicast Capability: Yes Group RefCnt ----- ------ 224.0.0.1 0000000001

INTERFACE/-K filter to specify LINK (IPv4) name or INTERFACE (IPv6) name

New Netstat DEVLINKS/-d INTFNAME Filter V1R4


1. New in V1R42. A new NETSTAT filter was introduced in V1R4:

1. INTERFACE/-K filter to specify LINK (IPv4) name or INTERFACE (IPv6) name displays output with only selected link/interface. Valid for both IPv4 and IPv6 interfaces.

Copyright IBM 2005C

Netstat DEVLINKS/-d Report - IPv4 Interface in V1R5

MVS TCP/IP onetstat CS V1R5 TCPIP Name: TCPCS 12:55:20 DevName: OSAQDIO4 DevType: MPCIPA DevStatus: Ready LnkName: OSAQDIOLINK LnkType: IPAQENET LnkStatus: Ready NetNum: 0 QueSize: 0 Speed: 0000000100 IpBroadcastCapability: No CfgRouter: Non ActRouter: Non ArpOffload: Yes ArpOffloadInfo: Yes ActMtu: 1492 VLANid: 1260 VLANpriority: Enabled ReadStorage: GLOBAL (8064K) InbPerf: Balanced ChecksumOffload: Yes .... Link Statistics: BytesIn = 11476 Inbound Packets = 10 Inbound Packets In Error = 0 Inbound Packets Discarded = 0 Inbound Packets With No Protocol = 0 BytesOut = 6707 Outbound Packets = 10 Outbound Packets In Error = 0 Outbound Packets Discarded = 0

Link Statistics


1. The statistics are displayed for an IPv4 link. 2. The existing BytesIn and BytesOut fields in the Netstat DEVLINKS/-d report are moved into the new statistics section for all

interfaces or links except for VIPAs:3. Programs that are screen-scraping Netstat DEVLINKS/-d reports for byte counters will have to be updated4. Since none of these interface statistics are maintained for VIPAs (including existing BytesIn and BytesOut fields), they are not

displayed for VIPA links or interfaces.

Copyright IBM 2005C

While You Were Sleeping: Interface and LAN News


Copyright IBM 2005C

D NET,TRL provides quick overview of device conditionsFor all TRLEs: SNA, TCP/IP, or Shared

IST350I DISPLAY TYPE = TRLIST1314I TRLE = IUTSAMEH STATUS = ACTIV----E CONTROL = MPCIST1314I TRLE = ML1A2A1 STATUS = NEVAC CONTROL = MPCIST1314I TRLE = ML1A2A2 STATUS = ACTIV----E CONTROL = MPCIST1800I TRLE = ML1A2A2 ** CONGESTED **IST1314I TRLE = ML1A2A3 STATUS = ACTIV----E CONTROL = MPCIST1314I TRLE = ISTT0001 STATUS = ACTIV----E CONTROL = XCFIST1454I 6 TRLE(S) DISPLAYEDIST314I END

D TRL Enhancement Example - V1R2


1. This display demonstrates (in italics) the enhancement to the messages issued when the D NET,TRL command is issued.2. In this example, one of the devices, the TRLE named ML1A2A2, is displayed as **CONGESTED**. The other TRLEs are not

displaying as congested. 3. Note that the devices displayed include SNA MPC and XCF devices as well as TCP/IP devices (all of which are TRLEs, either

CONTROL=MPC or CONTROL=TCP or CONTROL=XCF).

Copyright IBM 2005C

D NET,TRL,TRLE=trlename for Congested OSA QDIO portQueued units of work are broken out by priority queue.IST075I NAME = OF8GETH, TYPE = TRLEIST486I STATUS = ACTIV, DESIRED STATE= ACTIVIST087I TYPE = LEASED, CONTROL = MPC , HPDT = YESIST1715I MPCLEVEL = QDIO MPCUSAGE = SHAREIST1716I PORTNAME = OF8GETHP LINKNUM = 0 OSA CODE LEVEL=314IST1577I HEADER SIZE = 4092 DATA SIZE = 60 STORAGE = **NA**IST1221I WRITE DEV = 2E81 STATUS = ACTIVE STATE = ONLINEIST1577I HEADER SIZE = 4092 DATA SIZE = 60 STORAGE = **NA**IST1221I READ DEV = 2E80 STATUS = ACTIVE STATE = ONLINEIST1221I DATA DEV = 2E82 STATUS = ACTIVE STATE = N/AIST1724I I/O TRACE = OFF TRACE LENGTH = *NA*IST1717I ULPID = TCPSVTIST1757I PRIORITY1: UNCONGESTED PRIORITY2: UNCONGESTEDIST1757I PRIORITY3: UNCONGESTED PRIORITY4: UNCONGESTEDIST1801I UNITS OF WORK FOR NCB AT ADDRESS X'02DEF010'IST18021 P1 CURRENT = 218 AVERAGE = 37 MAXIMUM = 218IST18021 P2 CURRENT = 8 AVERAGE = 7 MAXIMUM = 15IST18021 P3 CURRENT = 2 AVERAGE = 2 MAXIMUM = 2IST18021 P4 CURRENT = 102 AVERAGE = 168 MAXIMUM = 267IST1221I DATA DEV = 2E83 STATUS = RESET STATE = N/AIST1724I I/O TRACE = OFF TRACE LENGTH = *NA*IST314I END

D TRLE for Congested QDIO Device V1R2


1. When displaying a TRLE for an OSA-Express device in QDIO mode, the messages break out units of work according to the four priority queues (P1=Priority 1, etc.).

Copyright IBM 2005C

Pre-V1R4No ability to purge ARP cache entries for devices with the ARP offload function.

New in V1R4 Purge ARP Cache CommandVary TCPIP,proc_name,PURGECache,name

name is the LINK (IPv4) name or Interface (IPv6) name that you want the cache to be purged for.Supported on those devices that provide an ARP offload function and provide ARP cache data to the TCP/IP stack.

V TCPIP,,PURGECACHE,OSAQDIOLNK4 EZZ0060I PROCESSING COMMAND: VARY TCPIP,,PURGECACHE,OSAQDIOLNK4 EZZ9786I PURGECACHE PROCESSED FOR LINK OSAQDIOLNK4 EZZ0053I COMMAND PURGECACHE COMPLETED SUCCESSFULLY

Purge ARP of ARP Offload Devices V1R4


1. If the name matches a link name, the local ARP cache or the outboard OSA cache entries (for QDIO token ring and QDIO ethernet) for that link is purged. If the name matches an interface name, the IPv6 neighbor cache for that interface is purged.

2. When this command is issued against an IPv4 QDIO token ring or ethernet link and the OSA-Express is shared by multiple stacks, then this command will purge the ARP cache for all stacks which share the OSA (because OSA-Express maintains a single ARP cache for all stacks which share it).

3. Translate entries are not deleted for asynchronous transfer mode (ATM) or link channel station (LCS) links.4. For ATM:

1. Permanent virtual channel (PVC) and ATMARP server entries are not deleted.2. ACTIVE switched virtual circuit (SVC) entries are not deleted since TCPIP processing periodically validates these entries.3. A clear may be needed for SVC entries that are not ACTIVE. When the asynchronous clear completes, the entries will be

deleted.5. IPv6 uses multicast for those purposes for which IPv4 used broadcast; consequently, IPv6 does not support broadcast.

Copyright IBM 2005C

LP1 LP2

nonrouternonrouter

OSAExpress

LP1 LP2

prirouter nonrouter

OSAExpress

LPA1 LPA2

secrouter

OSAExpress

prirouterun

know

n/un

regis

tered

Pack

etsdiscard

LPA3

secrouter

unkn

own/

unre

gister

ed

Packe

ts

TCP/IP Profile at LPA1DEVICE QPORTG MPCIPA PRIROUTER LINK QDIOG1 IPAQGNET QPORTGHOME 192.168.1.11 QDIOG1 START QPORTG

TCP/IP Profile at LPA2 and LPA3DEVICE QPORTG MPCIPA SECROUTER LINK QDIOG1 IPAQGNET QPORTGHOME 192.168.1.11 QDIOG1 START QPORTG

Multiple Secondary QDIO Router in V1R4


1. Pre-V1R41. QDIO Mode Only

1. OSA-Express feature allows the setting of two routing stacks/interfaces (one primary and one secondary) that serve as receptors for all Internet Protocol (IP) packets with IP destination addresses not matching a registered IP address on the OSA-Express feature.

2. Only One Primary Router per OSA port1. DEVice dev_name MPCIPA PRIRouter

3. Only One Secondary Router per OSA port1. DEVice dev_name MPCIPA SECRouter

2. New in V1R4 Multiple Secondary Routers3. Announcement Letter 102-209 August 13, 2002

1. Gigabit Ethernet and Fast Ethernet in QDIO Mode Only1. Latest level of zSeries Licensed Internal Code (LIC) is required.

1. zSeries z900 or z800, OSA-E EC J11204.011, J11204.012, MCL 3.202. If the primary is defined, the IP packets will be routed to the primary.

1. If one or more secondary stacks/interfaces are defined and the primary stack/interface is not active, the IP packets will be forwarded to one of the active stacks/interfaces that has the secondary routing indicator enabled.

2. There is no way to explicitly set the order of the secondary routers. 4. DEVICE router parameter defaults to NONRouter.5. All IP addresses in a z/OS TCP/IP stack HOME list are registered with the QDIO adapters.

1. HOME changes are automatically sent to QDIO adapters.6. OSA/SF V2R1 can show which entries are forwarding unknown IP packets; which routing stacks/interfaces are serving as

receptors for all IP packets with IP destination addresses not matching a registerd IP address on the OSA-Express feature.1. OW54990/UW89457 for OSA/SF V2R1 for z/OS

Copyright IBM 2005C

Diagram 1: VLAN Configuration ('Trunk Mode') pre-V1R5

Full VLAN 802.1Q in V1R5

Switch

OSA-A

OSA-D

OSA-C

OSA-B

VLAN 1 VLAN 2

Stack A

Stack B

shared OSA-C

VLAN 1 VLAN 2

Stack A Stack B

OSA-A OSA-B

OSA-B

VLAN 1 (IPv4)VLAN 2 (IPv6)

Stack A Stack C

OSA-A OSA-C

Stack B

IPv4 IPv6

Diagram 2: VLAN Configuration ('Access Mode') V1R5

Diagram 3: VLAN Configuration ('Access Mode') V1R5 - IPv4 vs. IPv6


1. Comparison of configuration modes1. Access mode (support available pre-V1R5)

1. Configure switch in access mode2. Specify VLAN ID in trunk port of switch3. VLAN tagging and filtering performed by switch4. Each stack sharing the OSA must be on same VLAN5. Must use same VLAN ID for IPv4 and IPv6

2. Trunk mode (new z/OS Comm Server V1R5 support)1. Configure switch in trunk mode2. Specify VLAN ID in TCP/IP profile3. VLAN tagging and filtering performed by OSA 4. Each stack sharing the OSA may be on a different VLAN5. Can use different VLAN IDs for IPv4 and IPv66. Can use VLAN priority tagging with VLAN ID

2. Diagram 1:1. This picture shows an example of a LAN subdivided into two VLANs. 2. This configuration is possible pre-V1R5 (if the VLAN IDs are configured on the switch).3. With V1R5, this configuration is also possible by configuring the VLAN IDs in the TCP/IP profiles.4. In either case, the existing interface takeover (ARP takeover) function with redundant connectivity onto a LAN applies within

the VLAN. So, because stack A has redundant connectivity onto VLAN 1, OSA-A can takeover for OSA-B and vice versa3. Diagram 2:

1. This picture shows two stacks sharing an OSA. 2. With V1R5, each stack may specify a different VLAN ID for the same OSA, so OSA-C is configured in VLAN 1 for stack A

and configured in VLAN 2 for stack B.4. Diagram 3:

1. This picture shows stack B using OSA-B for both IPv4 and IPv6. 2. With V1R5, a stack may specify a different VLAN ID for the same OSA for IPv4 and IPv6, so OSA-B on stack B is configured

in VLAN 1 for IPv4 and configured in VLAN 2 for IPv6.

Copyright IBM 2005C

Full VLAN 802.1Q Configuration in V1R5

shared OSA-C

VLAN 1 VLAN 2

Stack A Stack B

OSA-A OSA-B

Diagram 2: VLAN Configuration ('Access Mode') V1R5

>>-LINK--link_name--IPAQENET--device_name--+---------+--+---------------+----> '-IPBCAST-' '-VLANID id-----'

.-READSTORAGE-----GLOBAL-. .-INBPERF-----BALANCED---.>-+------------------------+---+------------------------+--| +-READSTORAGE--+--MAX----+ +-INBPERF--+--MINCPU-----+ +--AVG----+ '--MINLATENCY-' '--MIN----'

.-IFSPEED 100000000-. >--+-------------------+--------------------------------------->< +-IFSPEED ifspeed---+ '-IFHSPEED ifhspeed-'

DevName: OSAQDIO4 DevType: MPCIPA DevStatus: Ready

LnkName: OSAQDIOLINK LnkType: IPAQENET ... NetNum: 0 QueSize: 0 Speed: 0000000100 IpBroadcastCapability: No CfgRouter: Non ActRouter: Non ArpOffload: Yes ArpOffloadInfo: Yes ActMtu: 1492

VLANid: 1260 VLANpriority: Enabled ReadStorage: GLOBAL (8064K) InbPerf: Balanced ChecksumOffload: Yes

New Messages!


1. Access mode (support available pre-V1R5)1. Configure switch in access mode2. Specify VLAN ID in trunk port of switch3. VLAN tagging and filtering performed by switch4. Each stack sharing the OSA must be on same VLAN5. Must use same VLAN ID for IPv4 and IPv6

2. Need new OSA-Express feature (on zSeries 990) or updated OSA-Express microcode level (on zSeries 900) to get the new function

3. If you plug multiple OSA-Express adapters into the same switch and configure the OSAs for different VLAN IDs, then you should specify a native VLAN on each corresponding trunk port of the switch that the OSAs are plugged into

4. To code VLAN ID: 1. Use new keyword on LINK statement for IPAQENET , or ... 2. Use the new keyword on the INTERFACE statement for IPAQENET63. The VLANID can be in range 1-4095

5. New Messages: 1. EZD0001I SETTING VLAN ID NOT SUPPORTED FOR DEVICE devname2.3. EZD0002I ERROR SETTING VLAN ID FOR DEVICE devname4.5. EZD0003I SETTING VLAN ID NOT SUPPORTED FOR INTERFACE intfname6.7. EZD0004I ERROR SETTING VLAN ID FOR INTERFACE intfname8.9. EZD0005I SETTING VLAN USER PRIORITY NOT SUPPORTED FOR INTERFACE intfname10.11. EZD0006I ERROR SETTING VLAN USER PRIORITY FOR INTERFACE intfname

Copyright IBM 2005C

>>-LINK--link_name--IPAQENET--device_name--+---------+--+---------------+----> '-IPBCAST-' '-VLANID id-----'

.-READSTORAGE-----GLOBAL-. .-INBPERF-----BALANCED---.>-+------------------------+---+------------------------+--| +-READSTORAGE--+--MAX----+ +-INBPERF--+--MINCPU-----+ +--AVG----+ '--MINLATENCY-' '--MIN----'

.-IFSPEED 100000000-. >--+-------------------+--------------------------------------->< +-IFSPEED ifspeed---+ '-IFHSPEED ifhspeed-'

New keyword on LINK statement for IPAQENET and IPAQTR INTERFACE statement for IPAQENET6

Coding for Improved Inbound OSA Performance V1R5

Netstat DEVLINKS/-d enhanced to display the INBPERF setting


1. If you use the same OSA-Express for both IPv4 and IPv6 traffic, you need to specify the same INBPERF setting on both the corresponding LINK and INTERFACE statements

2. INBPERF will have no effect if OSA-Express microcode is downlevel

Copyright IBM 2005C

OSA Inbound Performance Enhancement V1R5Can specify one of the following values:MINCPU - instructs the adapter to minimize host interrupts, thereby minimizing host CPU consumption. This mode of operation may result in minor queuing delays for packets into the host, and is not recommended for workloads with demanding latency requirements. MINLATENCY - instructs the adapter to minimize latency, by immediately presenting received packets to the host. This mode of operation will generally result in higher CPU consumption than the other two settings, and is recommended only for workloads with demanding latency requirements. This setting should only be used if host CPU consumption is not an issue. BALANCED (default) - instructs the adapter to strike a balance between MINCPU and MINLATENCYRequires one of the following levels of OSA-Express microcode:

Processor Microcode levelG5/G6 4.28

zSeries 2064 GA2 2.29zSeries 2064 GA3 3.23


1. The performance of an OSA-Express QDIO device is impacted by how frequently the OSA interrupts the host to process inbound packets1. More frequent interruptions lead to minimized latency but increased CPU consumption2. Less frequent interruptions lead to decreased CPU consumption but increased latency

2. Prior to z/OS V1R5, there was no way to configure the desired inbound performance characteristics for a specific device1. With V1R5 we introduced a new keyword in TCP/IP profile to specify the desired inbound performance behavior from an

OSA-Express in QDIO mode2. OSA determines the frequency based on values set by z/OS Comm Server.

Copyright IBM 2005C

While You Were Sleeping: Routing News


Copyright IBM 2005C

Sample CNVROUTED.PROFILE ; ================================================== ; PROFILE.TCPIP ; ================================================== ; Suggested BEGINROUTES indirect and/or default routes ; based on the passive entries of the OROUTED gateways ; file if it exists. You will need to add valid ; direct route entries before these suggested routes. ; BEGINROUTES ; ENDROUTES ; Verify PORT UDP 520 reservation. ; OMPROUTE automatically enables IPCONFIG ; IGNOREREDIRECT and VARSUBNETTING.; ================================================== ; omproute.conf ; ================================================== ; Each non-VIPA interface known by OROUTED at the time; of execution is defined below as an OMPROUTE ; 'RIP_Interface'. ; Each VIPA or DVIPA interface known by OROUTED at the ; time of execution is defined below as an OMPROUTE ; 'Interface'. If OSPF is later used in any way, ; VIPAs should be redefined as 'OSPF_Interface's. ; Please verify any generated DVIPA configuration! ; For point to point interfaces, a destination ; address must be specified.

/tmp/CNVROUTED.PROFILE; conversion comments for ...

PROFILEomproute.conf

orouted -c cnvrouted.profilef orouted,parms='-c ...'

PROFILE.TCPIPHOMEBSDROUTINGPARMS

ETC.GATEWAYS

RTDPROF DD ...(ORouteD Profile)

//EXEC PGM=... PARMS='-hv ...' ...

Established ORouteD Environment

ORouteD Migration Tool > OMPROUTE V1R2


1. z/OS CS supports two routing daemons - OROUTED and OMPROUTE. OMPROUTE is the strategic choice. However, many customers still use OROUTED. In order to persuade OROUTED users to move to OMPROUTE, the migration must be made as easy as possible. Eventually, z/OS CS would like to support only one routing daemon.

2. To make the migration from ORouteD to OMPROUTE easier, z/OS CS has provided a tool which will use information from ORouteD's current environment to create a conversion file which can be used as an OMPROUTE configuration file. The current environment is built from the ORouteD start options, the various ORouteD configuration files, and the PROFILE.TCPIP. The conversion file may indicate necessary changes to other files. Before starting OMPROUTE, the user still must follow the step by step procedure described by the IP Configuration Guide. However, the user does not have to create the OMPROUTE configuration file since it is generated by the tool. The IP Migration Guide has also been updated with a section about moving from OROUTED to OMPROUTE.

3. Conversion tool is a function of ORouteD.1. Invoked via the -c parameter for ORouteD.2. -c may be a modify parameter or a start option3. Specify the filename following -c.4. ORouteD creates the conversion file in the /tmp directory. The conversion file may NOT be placed in an MVS dataset.5. default filename is cnvrouted.profile 6. Input to the conversion tool is the running ORouteD environment that has been established with any ORouteD Start Options,

the PROFILE TCP/IP statements, the etc.gateways contents, and the ORouteD profile designated in the DD card of the started procedure for ORouteD.

4. The ORouteD procedure may be modified with -c, or -c may be specified as a start option in the ORouteD profile. If -c is a start parameter, OROUTED will create the conversion file and terminate. If the file name already exists, an error message will appear indicating conversion file creation failed.

Copyright IBM 2005C

BEGINRoutes ROUTE 9.82.0.0/20 = OSATRB14 MTU 4096 REPL ROUTE 9.82.1.103 255.255.255.255 = OSATRB14 MTU 4096 REPL ROUTE DEFAULT 9.82.1.103 OSATRB14 MTU 4096 REPL ENDRoutes

REPLACEABLE static route in BEGINROUTES/ENDROUTES:A new type of static route introduced in V1R2 Can be replaced by a dynamic route learned by OMPROUTE, but is remembered by the IP stack for reinstatement if dynamic routes are lost. All routes to a destination must be REPL or NOREPL; the two types CANNOT be mixed.Multipath Replaceable Static Routes permitted!

An Example:z/OS learns about NetB and NetA via R1 via dynamic routing updates between R1, R3, and z/OS.R2 routes only statically. z/OS doesn't know that R2 could be a backup router for NetA and NetB.If R1 stops working, z/OS cannot reach nodes on NetA and NetB.SOLUTION: Make R2 a backup or last-resort router for NetA and NetB by coding Replaceable Static Routes.

GATEWAY9 = OSATRB14 4096 0.255.240.0 0.82.0.0DEFAULT 9.82.1.103 OSATRB14 4096 0

BEGINROUTES Preferred!

R1

R2

R3

z/OSNetA

NetB

R2: NO DYNAMIC ROUTING

Replaceable Static Routes in V1R2


1. Prior to z/OS V1R2, the philosophy for static routes was one of two things: they were intended to be used when no routing daemon was running, or they were intended to be used with the assumption that the user knows what he is doing. (The assumption was that the static routes the user defines should always be accepted as the best routes.)1. If a static route was defined to a destination, no other route could be used to reach that destination -- even if the static route was

known to be unavailable, or if a better route was learned dynamically!2. For this reason, we did not recommend using static routes in conjunction with OMPROUTE.

2. Customers desired a more flexible approach, one that would allow static routes to be considered alongside dynamically learned routes when deciding how to reach a destination.

3. Unlike basis static routes, OMPROUTE in V1R2 can replace replaceable static routes. OROUTED cannot. 4. Starting with V1R2, the TCP/IP stack always maintains knowledge of replaceable static routes, even when they are not being used

because of being superseded by dynamic routers. When dynamic routes are lost, replaceable static routes are installed by TCP/IP. Inthis manner they can act as last-resort, backup routes. The ability for replaced static routes to be remembered and reinstated after dynamic routes are lost is key to their ability to act as backup routes.1. Replaceable static routes can be thought of as "last resort" or "worst-case" routes. Any dynamic route learned by OMPROUTE is

considered better than a Replaceable Static Route.2. Nonreplaceable static routes can be thought of as "must-use" routes; no dynamic routes will be learned to a destination served by a

nonreplaceable static route. 5. Since you may define them as replaceable, you may introduce a dynamic routing daemon and yet still retain the static routes as

backup. This can help migration to a dynamic routing daemon.6. You may also define multiple routes to the same destination as being "replaceable."

1. Multipath routes means multiple routes to the same destination. OMPROUTE's 4-multipath limitation applies to all route types that OMPROUTE can process -- static or OSPF. TCP/IP, however, has no such limitation, so you can define many static routes (replaceable or not) to the same destination. However, because of OMPROUTE's limitation of four equal-cost routes to the same destination, it will advertise only up to 4 such multipath routes per destination to other routers.

7. SYNTAX: 1. Replaceable static routes can only be specified on BEGINROUTES statements. GATEWAY does not support this.

BEGINROUTES/ENDROUTES was introduced in CS for OS/390 V2R10. All future enhancements to Static Routing will be made via the BEGINROUTES/ENDROUTES block and not via GATEWAY. Migrate to BEGINROUTES as soon as possible!

2. The REPLACEABLE keyword can be shorted to REPL3. The NOREPLACEABLE keyword can be shorted to NOREPL4. If neither keyword is coded, NOREPLACEABLE is assumed. This will allow customers to get their pre-V1R2 behavior with no

configuration changes.

Copyright IBM 2005C

Delete Device/LinkNew VIPA Support

Gateway DEFAULTNETPre-V2R10, Defaultnet coding supersedes Default on GATEWAY statement.Starting in OS/390 V2R10, GATEWAY statement's DEFAULTNET is equivalent to DEFAULT.

DELETE LINK lnkvipa1DELETE DEVICE devvipa1

;; GATEWAY; Network First Hop Link Name Packet Size Subnet Mask Subnet Value; 9.82.36.2 = TRL2216A 16000 0.255.255.0 0.82.36.0; 9 = TR1 2000 0.255.255.0 0.82.1.0; 9 = LNK2BTCP 4000 0.255.255.0 0.82.67.0; 172.16.0 192.168.1.2 ld2216 1400 0; 192.168.194.0 = LINK1 1500 0.0.0.224 0.0.0.32; 192.168.194.0 192.168.1.2 ld2216 1500 0.0.0.224 0.0.0.32; DEFAULT 9.82.36.2 TRL2216A 4000 0; DEFAULT 9.24.105.127 EN1 4000 0; DEFAULTNET 9.82.1.103 TR1 2000 0

Delete, IPConfig, and Gateway in V1R4


1. New in V1R41. Prior to V1R4 it was possible to use the DELETE statement for deleting a previously defined ATMARPSV, ATMLIS,

ATMPVC, device, link, port, or portrange. In V1R4 Virtual Addresses may be specified on DELETE DEVICE and DELETE LINK statements. IPv6 Interfaces may also be deleted with the DELETE statement. 1. To delete a link, you must first delete any associated HOME entry by | specifying a HOME statement that does not include

the link, and you | must also stop the device. However, you do not need to (and cannot) stop the device when deleting a link for a virtual device.

2. Prior to V2R10, 1. If the DEFAULTNET route existed (was active), it was used and any DEFAULT route coding was ignored.2. If the DEFAULTNET route did not exist or was not active (was considered a "black hole"), the first active DEFAULT route was

used when no specific route matched the destination or source IP address.3. MULTIPATH protocols applied only to the use of DEFAULT routes that were not superseded by a DEFAULTNET statement.

3. New in V2R101. Gateway statement DEFAULTNET is equivalent to DEFAULT.

1. Multiple DEFAULT entries can be specified, allowing for multiple default routes. When multiple routes are specified, all of them are used when multipath is enabled on IPCONFIG statement; otherwise, only the first route specified is used.

2. Migration from Gateway statement to Beginroutes/Endroutes is recommended.3. DEFAULTNET is not documented in the V1R4 manuals, although it is still a valid parameter.

Copyright IBM 2005C

While You Were Sleeping: FTP News


Copyright IBM 2005C

Set of initial SITE commands and CD commandsAre executed immediately after the user's password is verified

Alternative to starting multiple FTP servers with different server options

i.e. Two servers using STARTDIRECTORY=MVS and STARTDIRECTORY=HFS no longer needed

OS/390 FTP Server

Some FTP Client

System-wide FTP server options in hlq.FTP.DATA

User-level initial FTP command file in userID.FTP.RC

SITE SBDATACONN=(IBM-1047,IBM-850)SITE UNIT=3390CD /u/rusty

Sample RUSTY.FTP.RC

FTP User Level Server Options V1R2


1. With z/OS V1R2 Communications Server, configuration files (FTP.RC files) can be used to configure user-level FTP options. SITE and CD commands can be inserted into these.RC files, according to the preferences of each user ID and are executed immediately after the user's password is verified. This provides an alternative to starting multiple FTP servers with different server options, (for example using two FTP servers, one with STARTDIRECTORY=MVS and one with STARTDIRECTORY=HFS).

2. As shown in the example, the configuration file pertaining to the user RUSTY has SITE and CD commands customizing options for this particular user.

Copyright IBM 2005C

This APAR implements a new FTP server FTP.DATA option to control if the server is allowed to include IP addresses and port numbers in its replies:

FTP.DATA: REPLYSECURITYLEVEL 0 / 1

0: Default. No restrictions on information included in server replies (the way it worked before)1: No IP addresses, hostnames, port numbers, or operating system level information included in replies from the server

C:\>ftp mvs098.tcp.raleigh.ibm.comConnected to mvs098.tcp.raleigh.ibm.com.220-FTPABC1 IBM FTP CS V1R4 at MVS098, 16:42:51 on 2002-10-24.

C:\>ftp mvs098.tcp.raleigh.ibm.comConnected to mvs098.tcp.raleigh.ibm.com.220-IBM FTP, 16:45:57 on 2002-10-24.

LEVEL 0

LEVEL 1

PQ58008:OS/390 V2R10 and z/OS V1R2

REPLYSECURITYLEVEL in V1R4


1. In some scenarios, it is considered a security issue to include IP addresses, port numbers, host names, etc. in responses from servers. This feature affects the output of the STAT subcommand as well.

2. Normally, FTP does include such information in various FTP server replies3. This function delivered with the PTFs for this APAR are in the base of V1R4, but they have been retrofitted to V2R10 and V1R2

of z/OS Communications Server.

Copyright IBM 2005C

SERVAUTH resource name is:EZB.FTP.sysname.ftpdaemonname.ACCESS.HFSEZB.FTP.*.*.ACCESS.HFS - will cover all LPARs and all FTP daemons

Users must have READ access to this SERVAUTH CLASSAny Logged-In Users, but not FTP Server's USERID itself

RACF SERVAUTHFacility Class!

MVS

HFSx

RDEFINE SERVAUTH EZB.FTP.MVSNM1.NM1AFTP.ACCESS.HFS SETROPTS CLASSACT(SERVAUTH)EZB.FTP.MVSNM1.NM1AFTP.ACCESS.HFS UACC(NONE)PERMIT EZB.FTP.MVSNM1.NM1AFTP*.ACCESS.HFS CLASS(SERVAUTH) ACCESS(READ) ID(SYSPROG)...

FRED

PQ63326: HFS File Access in General in V1R4


1. Some customers (a few) have expressed a need to be able to disable users from accessing any HFS files.2. The FTP server has implemented use of a new SERVAUTH resource and a new access check to meet this requirement with

this APAR. This was not in the base of V1R4 but is available via APAR for V2R10, V1R2, and V1R4.3. SERVAUTH resource name is:

1. EZB.FTP.sysname.ftpdaemonname.ACCESS.HFS4. The profile may contain wildcards to cover more LPARs and FTP daemons:

1. EZB.FTP.*.*.ACCESS.HFS - will cover all LPARs and all FTP daemons5. If the above resource is defined, then users must have READ access to it in order for the FTP server to allow such users to

access any files in an HFS including directory information.6. Note how FRED has not been granted access to the HFS -- only SYSPROG has!7. Ensure the SERVAUTH class is RACLISTed. If it is not, RACLIST it:

1. SETROPTS RACLIST(SERVAUTH) 8. Refresh the SERVAUTH class before using:

1. SETROPTS RACLIST(SERVAUTH) REFRESH

Copyright IBM 2005C

The FTP server activity logging automatically invokes a reverse name lookup. To disable this reverse name function, see:APAR PQ86472, with PTFs for ...

Release 140 : UQ87654 Release 149 : UQ87655 Release 150 : UQ87656

In addition, a change has been made to the FTP client to issue message EZA2892I if secure port is coded on the start parameters along with -a or -r. Message EZYFS50I will contain "UNKNOWN" for the host name.

FTP.DATA File:

FTPLOGGING TRUENODNS

EZYFS50I ID=NM1AFTP100000 CONN starts Client IPaddr=::ffff:9.82.158.57 hostname=UNKNOWN

Sample FTP Server Activity Log in V1R4


1. It was determined after FTPLOGGING was introduced in z/OS V1R4 that the capability to disable the getnameinfo() call -- used to create an FTP log record when logging is enabled -- was needed for certain customers.

2. There are many name domains where the administrators have chosen not to provide in-addr.arpa domain records for all of the IP addresses in the server's scope. When these records are missing, a nontrivial delay can result while the log record is built, which occurs before the initial greeting response from the server. This delay can cause failures of the FTP session for some network configurations (outside of the scope of the z/OS system).

3. When FTPLOGGING TRUE is coded in the FTP server's FTP.DATA at connection initiation a DNS lookup to resolve the client's host name is done. This can cause significant delays and should be modified to be configurable.

Copyright IBM 2005C

Two definitions:

The FTP daemon started task userID must have READ access to the FACILITY class resource BPX.STOR.SWAP (if defined)1

FTP.DATA: NONSWAPD FALSE | TRUE

FALSE: Do not set the FTP daemon non-swappable (this is the default and as it worked earlier)TRUE: Set the FTP daemon non-swappable

Real Storage

MYFTP2 MYFTP1

Virtual Storage

PERMIT BPX.STOR.SWAP CLASS(FACILITY) ACCESS(READ) ID(MYFTP2)...

V1R2V1R4

PQ63363: NONSWAPD in V1R4


1. Some installations have expressed a desire to make the FTP daemon address space non-swappable. This new support has been provided for both V1R2 and V1R4 via APAR PQ63363. For example, here is a customer scenario in which making the FTP Server non-swappable would be desirable:1. Scenario: TCPIP was processing the network connection requests and was waiting for the FTP server to accept these

connections. The first modify command (to enable the trace) was accepted but the following modify commands were rejected indicating that MVS was still waiting for the FTP server to process the original request. Eventually, 20 minutes later, the FTP server did process the modify command as per message EZY2704I. This indicates that the server was not hung but waiting for some resources. This 20 minutes is too long to wait for most FTP clients application causing them to time-out before the server had a chance to respond. Other information shows that all of the FTP processes are 'swapped-out'.

2. With z/OS V1R2 and above you can have the FTP server marked non-swappable as per APAR PQ63363. 1. A definition in the Security Product for the facility class BPX.STOR.SWAP and and FTP.DATA statement are required to

make MYFTP2 non-swappable as depicted. In our example, "MYFTP21" is the forked address space associated with the daemon. "MYFTP2" is the name of the OMVS userid associated with the daemon.

2. MYFTP1 remains swappable.3. Footnote 1: If the facility class resource is not defined, all applications have access to the facility by default and it is

only necessary to set the FTP.DATA parameter for swapping. If you define the facility class resource, you have more control over tasks that should and should not be made swappable; it is possible to limit the users who can change their swap status.

Copyright IBM 2005C

FTP: Specifying Ephemeral Port Range V1R5

FIREWALLS are a problem for FTP data connections (Active FTP)

This is the well known problem described in RFC 1579 - firewall does not permit connection setup back to client

PORT 9,1,2,3,4,7

firewall200 PORT OK

connect 9.1.2.3, port 1031

listening data socket

FTP client

FTP server

PASV

firewall

227 Entering Passive Mode (9,1,2,3,4,12)



FTP client

FTP server

RFC 1579 suggested solution is PASV instead of PORT (passive Mode)

This solves the problem if the firewall permits all inbound connections from the client to the server

Private network client Public network server


Copyright IBM 2005C

FTP: Specifying Ephemeral Port Range V1R5

RFC 1579 is no panacea ....The firewall permits a connection

from client to port 21, but not to the data socket (ephemeral) port

PASV

firewall

227 Entering Passive Mode (9,1,2,3,4,12)



FTP client

FTP server

Private network client Public network server

"Passive mode FTP"client and server choose ephemeral port for data socket data connection is from an ephemeral port to an

ephemeral porta firewall should be careful allowing this sort of connection

Choose ephemeral port from configured rangeConfigure FTP server to pick the port from specific rangeConfigure TCP/IP to reserve those ports for FTP serverConfigure firewall to allow connections to ports in that

range

PASSIVEDATPORTS (...,...)

Server FTP.DATA

PORTRange 1st_port num_ports TCP

AUTHPORT

PROFILE for TCP/IP


1. FTP.DATA statements for Server1. PASSIVEDATAPORTS (low_port,high_port)

1. the lowest number allowed for low_port is 10242. the highest number allowed for high_port is 65536

2. for EPSV and PASV data ports, the FTP server will pick a port from low_port to high_port, inclusive1. higher port numbers are recommended

3. When PASSIVEDATAPORTS is coded, the server will pick ephemeral ports for listening data sockets only from the range coded

2. PROFILE.TCPIP statements1. PORTRange 1st_port num_ports TCP AUTHPORT 2. AUTHPORT reserves ports for FTP

1. for TCP protocol only3. code same range as on PASSIVEDATAPORTS4. prevents other applications from consuming ports5. SYSPLEX dvipa users

1. if you are distributing the FTP workload, code the same PORTRANGE ...AUTHPORT statement for each participating stack

Copyright IBM 2005C

PASSIVEDATAPORTS AUTHPORT FTP listening data ports

(5000,5050) 5000-5050 FTP uses ports 5000-5050. No other application can use these ports.

(4000,4050) 5000-5050 FTP uses ports 4000-4050. Other applications can use ports 4000-4050. No application can use ports 5000-5050.

not coded 5000-5050 FTP uses normal ephemeral ports outside the 5000-5050 range. No application can use ports 5000-5050.

(5000,5050) not coded FTP uses ports 5000-5050. Other applications can use ports 5000-5050 too.

The following table shows how PASSIVEDATAPORTS and AUTHPORT interact with FTP and other applications.

PASSIVEDATAPORTS and AUTHPORT Interaction in V1R5


Copyright IBM 2005C

USER1.NETSTAT.LOADBACK USER2.NETSTAT.LOADCOPY

z/OS FTP client z/OS FTP server

lcd 'user1.netstat' ; ; Make a new library locally called 'USER1.NETSTAT.LOADBACK' ; based on what server library 'USER2.NETSTAT.LOADCOPY' looks like ; lmkdir loadback (like 'user2.netstat.loadcopy' lcd loadback cd 'user2.netstat.loadcopy' mget * quit

Autoconfigure Load Module Library forTransfer: New PDS(E) on Clientlmkdir ... (like .... V1R5

3390 3390

PDSTYPE ||PDS|PDSE

FTP.DATA


1. Transferring Load Module into PDS or PDSE data sets could be easier than what it has been in the past.1. Target must exist before transfer2. Source and target characteristics have to match3. target of adequate size: DIRECTORY, PRIMARY, SECONDARY4. LRECL, RECFM, BLKSIZE5. PDS type: PDS, PDSE

2. Until V1R5 there was no easy way to create a PDSE with z/OS FTP1. FTP by default always allocates a PDS by default2. If you want something else, you must force FTP to allocate a PDSE

1. code SMS Automatic Class selection (ACS) routines 2. define a DATACLASS to override PDS attribute with LIBRARY attribute3. define DATACLASS to FTP or let ACS routine assign one to the allocation

3. But in V1R5 ... Let FTP allocate a PDSE as well as a PDS1. FTP Configuration option2. locsite subcommand option for client3. site command option for z/OS FTP server4. Benefits everyone who allocates MVS directories5. Not restricted to Load Module Transfer users

Copyright IBM 2005C

USER1.NETSTAT.LOADLIB USER2.NETSTAT.LOADCOPY

z/OS FTP client z/OS FTP server

lcd 'user1.netstat' cd 'user2.netstat' ; ; Make a new library on server called 'USER2.NETSTAT.LOADCOPY' ; based on how local 'USER1.NETSTAT.LOADLIB' looks like ; mkdir loadcopy (like loadlib lcd loadlib cd loadcopy mput * dir quit

mkdir ... (like ....

Autoconfigure Load Module Library forTransfer: New PDS(E) on Server

V1R5

3390 3390

PDSTYPE ||PDS|PDSE

FTP.DATA


1. V1R5 allows a user to allocate a PDS or PDSE similar to another1. mkdir remote_directory (like local_directory2. lmkdir local_directory (like remote_directory

2. FTP client determines characteristics of existing directory, changes configuration so next allocate makes directory of similar characteristics, and then allocates new directory

3. The FTP.DATA at either the client or the servere can be changed as follows 1. FTP.DATA statements

1. PDSTYPE [{PDS | PDSE}] <=== the value is optional1. If no value is specified, allocate MVS directory as PDS unless SMS forces it to be a PDSE. 2. PDS: allocate MVS directory as PDS3. PDSE: allocate MVS directory as PDSE

2. FTP client and FTP server support this statement4. Or the client can issue the commands to change the settings dynamically:

1. locsite subcommand parameter for client session1. locsite PDSTYPE= [{PDS | PDSE}] <== the value is optional

2. SITE command parameter for FTP server session1. SITE PDSTYPE= [{PDS | PDSE}] <== the value is optional

5. Valid on 3390 architecture devices only -- local and remote6. Server and Client can only estimate

1. PRIMARY, SECONDARY, CYLINDERS or BLOCKS or TRACKS2. Server or Client must open and read the (like data_set

1. beware unmounted and migrated data sets1. issue site noautomount noautorecall before lmkdir to prevent XDSI command from hanging indefinitely

Copyright IBM 2005C

FTP Client Error Codes New Descriptive Information

Code Error Examples of Cause 01 FTP_INTERNAL_ERROR Failure to acquire storage, unexpected error in REXX stack 02 FTP_SERVER_ERROR Error reply returned by the server 03 NOT USED <Not returned as an error code>04 FTP_INVALID_PARAM Invalid parameter specified on FTP command 05 FTP_OPEN_IOSTREAM_FAILED Failed to open the INPUT stream 06 FTP_ALREADY_CONNECTED Attempt to OPEN when already connected 07 FTP_USAGE Syntax error in a subcommand, invalid combination of settings 08 FTP_CONNECT_FAILED Attempt to reach unknown host, lost connection, data connect failed 09 FTP_TIMEOUT Timeout waiting for response on the control or data connection 10 FTP_SESSION_ERROR Socket error, other send/receive errors 11 FTP_LOGIN_FAILED Invalid userid, password, or account info 12 FTP_INPUT_ERR Error reading INPUT or STDIN 13 FTP_INPUT_EOF <Not returned as an error code> 14 FTP_NOTFOUND TCP/IP stack not found, resolver not found, translation table not found

or could not be loaded 15 FTP_INVALID_ENVIRONMENT Missing INPUT DD 16 FTP_NOT_ENABLED Improper installation of TCP/IP 17 FTP_AUTHENTICATION Security authentication or negotiation failure, incorrect specification of

security keywords18 FTP_FILE_ACCESS Data set allocation failure, recall failure, open failure 19 FTP_FILE_READ File corrupted20 FTP_FILE_WRITE Out of space condition, close failure21 FTP_CONVERSION Error during data translation or setup not otherwise specified 22 FTP_PROXY_ERR Error during proxy processing not otherwise specified 23 FTP_SQL_ERR Error returned by the SQL process, including connect failure 24 FTP_CLIENT_ERR Other errors in the client, some unrecoverable interface errors

FTP Client Return Codes for Automation V1R5

EZZ9830I

System or Batch Job Log

EZZ9830I

CLIENTERRCODE EXTENDEDLOGCLIENTERR TRUE

FTP.DATA


1. Existing and new client error codes are set much more reliably than before (<100 places increased to over 450).2. The FTP.DATA keyword CLIENTERRCODES has a third option in addition to TRUE and FALSE. CLIENTERRCODES

EXTENDED is used to generate a return code that contains the two-digit client error code concatenated to the two-digit subcommand code. These client return codes provide more information than a client error code alone while avoiding the problems associated with standard return codes.

3. The message EZZ9830I will be issued if LOGCLIENTERR TRUE is specified in FTP.DATA. The message will display in the batch job log and the system log, or at the user's terminal for an interactive client session.

4. EZZ9830I contains information about a failure in the client and is generated regardless of the type of client return code in use and without regard to whether or how the EXIT parameter was specified at client start.

5. If EZZ9830I is generated for a client session that did not specify an EXIT parameter, the information contained in the message refers to the first error that would have caused the client to exit if EXIT had been specified.

6. EZZ9830I can be used to drive automated processing.7. EZZ9830I displays the computed client return code, which may be a standard return code, a client error code, a client error code

extended, or a fixed return code, depending on configuration and parameter settings.

Copyright IBM 2005C

While You Were Sleeping: Telnet News


Copyright IBM 2005C

Different destination IP Address (could be resolved from hostname) or different

Connect to 10.1.1.2 Port 23

VIPADynamic VIPADEFINE 255.255.255.252 10.1.1.1 10.1.1.2EndVIPADynamic

TN3270(E) Server

Never drops, connect to IMSB

z/OS V1R4

Connect to 10.1.1.1 Port 23 Drop after 10 minutes, connect to CICSA

This example could be extended to use different LU pools, different logmodes, different requirements for secure connections, etc.

TelnetParms Port 23, 10.1.1.1 Inactive 600 ;Drop after 10 minutesEndTelnetParmsTelnetParms Port 23, 10.1.1.2 Inactive 0 ;Never dropEndTelnetParms

BeginVTAM Port 23, 10.1.1.1 DefaultAPPL CICSAEndVTAMBeginVTAM Port 23, 10.1.1.2 DefaultAPPL IMSBEndVTAM

Qualifier may be Destination IP Address or Linkname!

linkname but the same default Telnet server port number 23.

New PORT Qualifier in V1R4


1. In V1R2 a new type of mapping was introduced that allowed you to define the Destination IP address or DESTIPGROUP name as a Client Identifier. For example, if a client telneted into one address, he might be assigned default application, APPL1. If he telneted into a different IP address, he might be assigned a different default application, APPL2.

2. Pre-V1R4: Other than using the V1R2 mapping just mentioned, the merge of Telnet Servers that are configured to use different parameters may not be transparent to end users because all users of one Telnet server might need to switch to another port to preserve the different parameters.

3. PORT is not New1. PORT or SECUREPORT on TELNETPARMS

1. PORT Statement1. Defines which port the Telnet server listens on for non-secure connection requests

2. SECUREPORT Statement1. Defines which port the Telnet server listens on for secure connection requests from clients using the SSL protocol

2. PORT on BEGINVTAM block1. Optional PORT Statement

1. Used to associate the BEGINVTAM block with the correct TELNETPARMS block when multiple ports are used4. New in V1R4

1. Ability to qualify a port definition with a destination IP address or with a specific link name1. Allows all users to connect to the same port using different IP addresses

5. TELNETPARMS syntax:6.---+------------------------------------------------+--->< | +---PORT 23---+ | +---+-------------+---PORT num---+-----------+---+ | +---,qual---+ | +---SECUREPORT num---+-----------+---------------+ +---,qual---+1. BEGINVTAM syntax: +---------------------------------+ | |1.---PORT---V---+---num---+-----------+---+---+--->< | +---,qual---+ | +---num1..num2------------+

If all port statements are defined with qualifiers and a connection request arrives that does not match any qualifier, the connection will be dropped.

Copyright IBM 2005C

Open ACBs in VTAMPrior to V1R4, application capacity through VTAM stands at approximately 65,000 open ACBs at a timeIn z/OS V1R4 VTAM's Open ACB table has been expanded to support 1,044,480 open ACBs at a time.

TN3270 Maximum definable LUs:

Storage is not used until the LU name is assigned to a connection.

Maximum LUs in Range

Maximum LUs in Group

OS/390 V2R8 64K No LimitOS/390 V2R10 2Gig No Limitz/OS V1R2 2Gig No Limitz/OS V1R4 4Gig 4Gig

With APAR V2R8 has V2R10 support.

Note: A TN3270 port itself until V1R6 can have only 64K open ACBs by itself because of the MAXFILEPROC restriction in BPXPRMxx! At V1R6 this is increased to 128,000 open connections.

Open ACB limit extended from 64K to 1M in V1R4


1. z/OS V1R4 CS increases application capacity through VTAM to a new limit of 1,044,480. Prior to z/OS V1R4 CS, the limit was approximately 65K open ACBs at a time. 1. A TN3270 port itself at the V1R4 release level can have only 64K open ACBs by itself! However, at V1R4 you can have

multiple TN3270 ports, each with 64K open ACBs, thus staying well within the VTAM Open ACB table limit of 1Meg.2. This enhancement does not require any action; it is automatically enabled. 3. With pre-V2R7 releases of OS/390, VTAM always obtains a low-order (less than 65,535) address for each application when its

Application Minor Node is activated or when it issues OPEN ACB. This address is used when the application is the secondary logical unit (SLU) involved in an LU-LU session. Although the Start Option, ENHADDR, has been available since VTAM V4R2 and allows use of high-order (in the range 65,535 to several million) addresses, these addresses are used only when the application is the primary logical unit (PLU) in a session and the session partner is not running in a node accessed across a subarea (FID4) connection. For environments with large session manager applications (such as TPX or NetView Access Services) or large S/390 TN3270 Gateways, 65,535 addresses can be used up quite quickly, since VTAM assigns low-order addresses to these types of applications, which typically OPEN an ACB (instantiating a separate VTAM application) for each client.

4. With the enhanced addressing for applications function (available with OS/390 V2R7 and higher), VTAM assigns high-order addresses to each non-parallel session capable APPL (PARSESS=NO) when it opens its ACB. If this application later gets in session with a partner where a low-order address is required (that is, a partner across an FID4 connection), VTAM obtains a low-order address for the application. This low-order address is freed when the LU-LU session ends. The enhancement can result in a significant reduction in the number of low-order addresses that are required in large TN3270 server and/or session manager application environments.

5. For applications that are parallel session capable (PARSESS=YES), one low-order address per application is obtained and used for every session where this application is the SLU. For sessions where the application is the PLU, additional high or low-order addresses are obtained, depending upon whether the session partner is across an APPN or subarea connection.

6. Note: Per Telnet port you can have only 64K concurrently active telnet sessions because of the MAXFILEPROC parameter in BPXPRMxx, which is restricted to 64K prioro to z/OS V1R6. Starting with V1R6 of z/OS you can have a MAXFILEPROC of 128K. Therefore, starting with V1R6 you can now have 128K TN sessions per Telnet port.

Copyright IBM 2005C

Raising MAXSockets Limits in V1R5Update the macro API so that MAXSOC values up to 65535 and socket numbers up to 65534 are supported.Update the REXX API so that MAXDESC values and socket numbers up to 65535 are supported.The new 64K sockets support in the macro API indirectly adds 64K sockets support to the CICS, IMS, and Sockets Extended APIs.Update the C Sockets API for CICS so that socket numbers greater than 2000 are not accepted.BPXPRMxx Parameters

MAXFILEPROC If there will be applications exploiting the enhancement that allows more than 2,000 sockets to be opened, then programmers need to examine and potentially modify the MAXFILEPROC parameter in the BPXPRMxx member. They would need to determine the highest possible number of combined sockets requested by applications within a single UNIX System Services process and set MAXFILEPROC to that value.MAXSOCKETS If there will be applications exploiting the enhancement that allows more than 2,000 sockets to be opened, then programmers may need to examine and potentially modify the MAXSOCKETS values in the NETWORK statements in the BPXPRMxx member. For each addressing family (AF_INET, AF_INET6, etc.), they would need to determine the highest combined possible number of sockets in the addressing family that can be opened by all applications in the system, and specify that number as the MAXSOCKETS value.

Storage ConcernsThe macro API allocates 68 bytes for each potential socket. Thus, if a INITAPI is issued with MAXSOC=65535 then 4352 Kbytes of storage are allocated just for the socket arrayWhen an asynchronous SELECT is issued, an OE polling array is created which contains 8 bytes of storage for each socket being monitored by the SELECT. Thus, if the SELECT is monitoring 65535 sockets then 512 Kbytes of storage are allocated just for the polling array.


Copyright IBM 2005C

New V1R4 parameter on LUGROUP and PRTGROUPOptionally define LU Group Capacity Warnings

150 LUs in use: EZZ6007I

Drops to 130 LUs in use ...

Rises to 150: EZZ6007I

TN3270(E) ServerLUGROUP LUCAP80,75% TCPLU001..TCPLU200ENDLUGROUP

---LUGROUP lu_group_name---+---------+---lu_name or lu_range------ENDLUGROUP--->< +--,nnn%--+ +--,EXIT--+

---PRTGROUP prt_group_name-+---------+---prt_name or prt_range---ENDPRTGROUP--->< +--,nnn%--+ +--,EXIT--+

150 LUs in use: EZZ6007I

Drops to 140 LUs in use ...

Rises to 150: No Message

EZZ6007I TELNET LU/PRT GROUP lugroup REACHED pct % OF CAPACITY

LU Capacity Warning V1R4


LU Group Capacity Warnings. Optionally set a threshold on the LUGROUP or PRTGROUP. When the threshold percentage amount is reached, a warning message will be issued.The optional LUGROUP Object statement defines a group of LUs.

---LUGROUP lu_group_name---+-----------+---lu_name or lu_range_def---ENDLUGROUP--->< +---,nnn%---+ +---,EXIT---+

The optional PRTGROUP Object statement defines a group of printer LUs.---PRTGROUP prt_group_name---+-----------+---prt_name or prt_range_def---ENDPRTGROUP---><

+---,nnn%---+ +---,EXIT---+

Because the TN3270E client is assigned an LU immediately, LU availability can be exhausted even though only a few SNA sessions exist.nnn% Checks the capacity left in the LUGROUP when Telnet assigns an LU from that group and issues a message when the specified percentage is reached. After the group goes over the specified capacity, no other message is issued. After the in-use number has dropped 10 percent of the total below the capacity check amount, another capacity warning message is issued.EZZ6007I indicates that the number of LUs in use from this LU group reached the specified capacity warning level. The limit is specified as a percentage of the total number of LUs in the group. Once this threshold is reached, the message will not display again until the in-use count drops below gthe threshold amount by 10% of the total LUs in the group. For example, a group of 200 LUs with a capacity warning level of 75% will report meeting the threshold when 150 LUs are in use. When the number of in-use LUs drops below 130 LUs, Telnet will report again when the in-use count reaches 150. If the in-use count drops to only 140 and then rises over 150, no message will be issued. This is done to reduce the messages issued when the in-use count moves slightly below and above the threshold amount.

Copyright IBM 2005C

LUGROUP LUGRP1,80% LU55..LU77 LUBB..LUDD ENDLUGROUP

When 80% of the LUs get used up:D TCPIP,,TELNET,OBJECT,PORT=23,ID=LUGRP1 (C) EZZ6083I TELNET OBJECT DISPLAY (L) OBJECT CONNS CLIENT ID CLIENT ID DEFAPPL/ (L) NAME USING TYPE NAME OPTIONS ASSOC ---------- ------ --------- ---------------- ---------- -------- LUGRP LUGRP1 0 IPGRP IPGRP1 --G-----C- LUGRP1 0 LINKNAME CTCLNK6 ALSD-F--C- APPL2 LUGRP: LUGRP1 ,80% TCPM1001 TCPM1002 TCPM1003 TCPM1001..TCPM1008..FFFFFFFN 8 LUS 0 IN USE T01DPT01..T99DPTFF..FNNFFFXX 25343 LUS 0 IN USE

EZZ6007I TELNET LU/PRT GROUP LUGRP1 REACHED 80 % OF CAPACITY

LD55 In useLD56 In useLD57 LD4 In useLD5 In useLD6 In useLD7

LUGROUP/PRTGROUP Capacity Warning V1R4


1. The optional LUGROUP Object statement defines a group of LUs.2.---LUGROUP lu_group_name---+-----------+---lu_name or lu_range_def---ENDLUGROUP--->< +---,nnn%---+ +---,EXIT---+1. The optional PRTGROUP Object statement defines a group of printer LUs.2.---PRTGROUP prt_group_name---+-----------+---prt_name or prt_range_def---ENDPRTGROUP--->< +---,nnn%---+ +---,EXIT---+1. Because the TN3270E client is assigned an LU immediately, LU availability can be exhausted even though only a few SNA

sessions exist.2. nnn% Checks the capacity left in the LUGROUP when Telnet assigns an LU from that group and issues a message when the

specified percentage is reached. After the group goes over the specified capacity, no other message is issued. After the in-use number has dropped 10 percent of the total below the capacity check amount, another capacity warning message is issued.

3. Thresholds are checked when PROFILE.TCPIP is processed and when an LU is assigned.4. The message is not issued again until after the number of in-use LUs drops below the threshold by at least 10% of the total.

1. ie. 200 LUs available with 80% threshold defined:1. When 160 LUs are assigned, message EZZ6007I is issued.2. No more EZZ6007I messages are issued until after the number of "in-use" LUs drops to 140 or below.3. Then when 160 LUs are again "in-use", message EZZ6007I is issued again.

5. Checks the capacity left in the LUGROUP when Telnet assigns an LU from that group and issues a message when the specified percentage is reached. After the group goes over the specified capacity, no other message is issued. After the in-use number has dropped 10 percent of the total below the capacity check amount, another capacity warning message is issued.

6. The limit is checked only for the group from which the LU was taken. If the same LU name is used in multiple groups, it is possible LUGRP2 is pushed over its threshold when an LU is taken from LUGRP1. In this case, no message is issued for LUGRP2.

7. If two ranges in an LUGROUP contain the same name, a single connection using that name will result in the in-use count incrementing by 2.

Copyright IBM 2005C

Enhanced in V1R4 D TCPIP,,TELNET,OBJECT,ID=LUGRP1EZZ6083I TELNET OBJECT DISPLAYOBJECT CONNS CLIENT ID CLIENT ID ITEMNAME USING TYPE NAME OPTIONS MAPPED---------- ------ --------- ---------------- ---------- --------LUGRP LUGRP1 0 USERGRP USERGRP1 --G-----C- LUGRP1 0 LINKGRP LINKGRP1 --G-----C- LUGRP1 0 IPGRP IPGRP1 --G-----C-LUGRP: LUGRP1 ,75% LU55..LU77..FFNN 23 LUS 5 IN USE -LU55 iLU56 iLU57 kLU58 LUBB..LUDD..FFAA 55 LUS 0 IN USE B01DAE00..B19DZEZZ..FNNFAFBB 640224 LUS 0 IN USE----- PORT: 23 ACTIVE PROF: CURR CONNS: 0------------------------------------------------------------11 OF 11 RECORDS DISPLAYEDEZZ6007I TELNET LU/PRT GROUP LUGRP1 REACHED 80 % OF CAPACITY

EZZ6083I TELNET OBJECT DISPLAYOBJECT CONNS CLIENT ID CLIENT ID ITEMNAME USING TYPE NAME OPTIONS MAPPED---------- ------ --------- ---------------- ---------- --------LUGRPLUEXIT1 0 USERGRP USERGRP1 --G-----E- LUGRP: LUEXIT1 ,EXIT - DISABLED TCPLU001..TCPLU999..FFFFFNNN 999 LUS 0 IN USE----- PORT: 23 ACTIVE PROF: CURR CONNS: 0------------------------------------------------------------11 OF 11 RECORDS DISPLAYED

Telnet Object Display V1R4


1. Options now includes1. C for LU Capacity percentage defined2. E for LU Exit defined

2. LU Range Rule is displayed, whether or not it was explicitly coded3. Total LUs and LUs in-use by range are displayed4. New state indicator is displayed as LU prefix

1. - indicates actively assigned2. i indicates inactivated3. k indicates kept for a certain client (KEEPLU)

5. Once an LU Name Exit is in use, it cannot be changed dynamically. To change LU Name Exit characteristics, you must change the exit name and then change the profile to use the new name.

Copyright IBM 2005C

Prior to z/OS V1R6, the TN3270 server runs as a subtask of the IBM TCPIP stack address space

In z/OS V1R6, provide customers with a choice:Run the TN3270 server as a separately started address space from TCPIPContinue to run TN3270 server as a subtask of the TCPIP address space

Reasons why an installation may want to run the TN3270 server in a separate address space:

Allows for prioritzation of TCPIP address space vs TN3270 serverMuch less likely for TN3270 server failure to cause a total TCPIP failureAllow for easier problem diagnosis for both TCPIP and TN3270Easier controls for starting and stopping the server

Reminder: Max # of connections increased to 128,000 in V1R6.

TN3270 Server as Separate Address Space in V1R6

TN3270 server

TCP/IP address space

VTAM address space

SNA application

z/OS LPAR


1. Considerations 1. Profile statements are the same (minor considerations) and must be in a file separate from TCPIP2. Commands are the same but must be directed to the intended TN3270 procedure name3. Multiple TCPIP stacks supported

1. One server per stack (affinity)2. One server associated with all stacks (Generic Server)

4. Must runTN3270 server with affinity for the following functions1. TN3270 SNMP subagent (and must be only Telnet to that TCPIP)2. WLM function

5. Requirements1. Separate start up JCL. Sample is provided.2. PPT entry for EZBTNINI. (Is in the MVS default PPT)

Copyright IBM 2005C

TN3270 Server Supports SCS in V1R6

SNA Character Stream (SCS) format supported by the TN3270 server for the USS (Unformatted System Service) processes used by TN3270E (not TN3270) connections.

Until V1R6, only 3270 Data Stream was supported in the Telnet Server for USS Tables and formats, but not SCS format.VTAM supports SCS for SNA terminals and 3270 Data Stream for non-SNA terminals

SNAApplication

TN3270Server

Negotiate Connection

Send Message 10

Send Application Name

Bind from APPL to Terminal

Message 10

* MSG10 FOR TCPIP SYSTEM V2R5 OR HIGHER (3270 Data Stream MSG10 DC AL2(MSG10E-MSG10S) MSG10S DC X'05C2' (ERASE/WRITE, WCC - '05' req. for TCP/IP MSG10) DC X'1140C81D60' SBA W ROW/COL; StartField WITH ATTRIBUTE DC C' /CCCCCCCCCC /SSSSSSSSS /SSSSSSSSS /111'

* USSTAB FOR ALL SNA 3270 TERMINALS * Use SNA Character String with NEWLINE charactersUSSMSG MSG=10,TEXT=(79C'*',X'15',CL5'*',CL73'TERMINAL @@@@@@- @@@@@@@@NQN MVSNM1 + Z/OS V1R4 FOR DLUS/DLUR @@@@TIME',- C'*',X'15',79C'*'),OPT=NOBLKSUP

SCS

3270 Data


1. SNA Character Stream (SCS) format is supported by the TN3270 server for the USS (Unformatted System Service) processes starting with z/OS V1R5.

2. Until V1R6, only TN3270 Data Stream was supported for USS Tables and formats, but not SCS format.3. VTAM supports SCS (can provide the same look to TN3270 users as to SNA users if you are migrating)4. SCS is only supported for TN3270E connections (not TN3270) since this data is sent

on the SSCP-LU session 5. An SCS table can be configured for TN3270E clients in the TN3270 Server Profile

Copyright IBM 2005C

While You Were Sleeping: Miscellaneous News


Copyright IBM 2005C

112

2

3

45

678

9

10

11

Simple Network Time Protocol (SNTP) DaemonSNTP Version 4 RFC is 2030.SNTP uses the same time-request/reply format as NTP.SNTP does not support any of the management functions of NTP.SNTP is a simplified version of NTP and can interoperate with it.An SNTP server is significantly simpler to implement and operate than an NTP server.

SNTP New in V1R4

z/OS V1R4

SNTP Daemon

RouterSNTP or NTP

Client

224.0.1.1: Synchronize your

clocks!

ServerSNTP or NTP

Client

RouterSNTP or NTP

Client

12:10

02:0002:0012:10

12:10

z/OS as a Time Source V1R4


1. z/OS already provides TIMED daemon.1. TIMED not widely supported on clients.2. TIMED protocol allows for a precision of one second.

2. There has been a long-standing requirement to support Network Time Protocol (NTP) on z/OS to provide a source clock.3. Network Time Protocol (NTP) RFC 1305 is a more full function time protocol than SNTP.

1. NTP allows for a precision of 200 pico seconds. A pico second is one trillionth of a second.2. NTP contains functions to estimate network delay.

4. Problems in porting NTP to z/OS:1. Impossible to set or adjust the clock from a program2. Clock can only be adjusted or set from a hardware console or from an External Time Reference (ETR), such as a Sysplex Timer3. z/OS is an EBCDIC platform, most others are ASCII

1. Time-related message formats are mostly binary fields in network-byte-order which are easy for z/OS to handle, but some of the NTP management-related message formats are more complex from a z/OS perspective since they include a combination of binary fields and variable length text fields. The text fields have to be converted from ASCII to EBCDIC on reception, and from EBCDIC to ASCII on transmission.

5. Simple Network Time Protocol:1. Used to synchronize time between a client and a server across a Wide Area Network (WAN) or Local Area Network (LAN).2. An External Time Reference (ETR), named stratum 0, is chosen as the highest timer reference used for synchronization.3. A stratum 1 server is attached to and receives the time from the stratum 0 timer.4. As per RFC, it is appropriate to use an SNTP server at the root of the time synchronization tree (stratum 1), which is where a z/OS system

would be located.1. The z/OS sysplex timer could be a stratum 0 timer.2. A z/OS Communications Server could be a stratum 1 server.3. A client could be a stratum 2 server.4. etc.

6. z/OS Unix SNTP Daemon:1. Compatibility with SNTP V3 and V4 clients and NTP V3 and V4 clients2. Unicast, multicast, or broadcast mode of operation3. Internet Assigned Numbers Authority (IANA) assigned IPv4 multicast group address is 224.0.1.14. Developed in C using the z/OS Unix System Services environment5. Time is always represented on the network in Universal Time Coordinates (UTC) which is GMT time6. There is a 3rd party vendor that makes a box that can act as the ETS for IBM's 9037 Sysplex Timer plus that box can be an NTP server

attached to a LAN at the same time.

Copyright IBM 2005C

http://www.bldrdoc.gov/timefreq/javaclck.htm http://tycho.usno.navy.mil/frtime.html

112

2

3

45

678

9

10

11 Hardware Clock:GMT Time (UTC)

TIMEZONE W.05.00.00or TIMEZONE W.04.00.00

SYS1.PARMLIB(CLOCK00)

CLOCK=00, ...OMVS=07,

SYS1.PARMLIB(IEASYS00)

-e TZ=EST5EDT

/etc/init.options

TZ=EST5EDT

/etc/profile

EST

EDT

REFERENCE: UNIX System Services Command Reference

Setting Time in z/OS and UNIXOne way to fix the problem ...


1. IBM recommends that your system hardware clock (processor timer) be set to local time instead of UTC time. (UTC time is also known as GMT, or Greenwich Mean Time, because Greenwich, England is the site of the Royal Observatory, located at longitude zero.)

2. When you migrate to a UNIX-based z/OS system, you may observe that MVS applications display the local time but some UNIX System Services applications display the GMT time or even an incorrect time.

3. This may occur when you have not synchronized your UNIX timezone settings (TZ=) with the OS/390 timezone settings (CLOCK=...). Note that the offset specified in the "CLOCK" member may apply either to the processor timer (ETRMODE=NO in the CLOCK member) or to the Sysplex Timer (ETRMODE=YES in the CLOCK member).

4. Or, it may occur because certain applications (like TCP/IP) do not consult the TZ settings in UNIX System Services. (More about this later -- there is a way to ensure that even such applications use the local time -- see CEEBINIT discussion later.)

5. Most daemons use the TZ setting in /etc/init.options which affects the initialization of processes invoked from /etc/rc at OMVS initialization; shell users use settings in /etc/profile (sets system-wide user environment) or the $HOME/.profile (which can override the settings in /etc/profile).

6. Other documentation about time issues in MVS are:1. RETAIN ITEM: RTA000156169 (DATE/19990412)2. "OS/390 MVS Initialization and Tuning Reference", SC28-1752 3. "OS/390 MVS Setting Up a Sysplex", GC28-1779 4. "OS/390 MVS System Commands", GC28-1781

Copyright IBM 2005C

Jul 8 15:24:03 WSC1 FSUM1220 syslogd: restartJul 8 19:25:53 WSC1 Config[67108868]: EZZ0300I OPENED PROFILE FILE Jul 8 19:25:53 WSC1 Config[67108868]: EZZ0309I PROFILE PROCESSING .........................................Jul 8 19:28:11 WSC1 ftpd[369098755]: EZYFT18I Using catalog Jul 8 19:28:11 WSC1 ftpd[369098755]: EZYFT08W Unable to get port Jul 8 19:28:11 WSC1 ftpd[369098755]: EZY2697I IBM FTP CS V2R7 Jul 8 19:28:12 WSC1 ftpd[369098755]: EZY2640I Using Jul 8 19:28:12 WSC1 ftpd[369098755]: EZYFT47I dd:SYSFTPD file, .......................................Jul 8 19:28:12 WSC1 ftpd[1577058316]: EZY2702I Server-FTP: Jul 8 19:28:12 WSC1 ftpd[1577058316]: EZYFT41I Server-FTP: process Jul 8 15:36:15 WSC1 inetd[83886093]: FOMN0044 Unable to lock /etc/inetd.pid: EDC5112I Resource temporarily unavailable., rsn=055501B7 Jul 8 15:39:12 WSC1 inetd[134217741]: FOMN0026 otelnet/tcp: unknown service Jul 8 15:47:25 WSC1 telnetd[33554448]: IP address is 9.82.131.114

SYSLOG Daemon Logfile (Timestamps)


1. Unless you manipulate the TZ (timezone) settings in your UNIX and MVS procedures, you can have mismatched Timestamps in the SYSLOG.

2. You see here that SYSLOGD itself is using the local time, whereas the FTP Server is using GMT time.

Copyright IBM 2005C

//FTPT21 PROC MODULE='FTPD',PARMS='' //FTPT21 EXEC PGM=&MODULE,REGION=4096K,TIME=NOLIMIT, // PARM=('POSIX(ON) ALL31(ON)', // 'ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPT21",', // '"_BPX_JOBNAME=FTPT21"', // '"TZ=EST5EDT")/&PARMS')

//OMPRT21 PROC //OMPROUTE EXEC PGM=OMPROUTE,REGION=0K,TIME=NOLIMIT, // PARM=('POSIX(ON)', // 'ENVAR("_CEE_ENVFILE=DD:STDENV",', // '"_CEE_RUNOPTS=HEAP(,,,FREE)"', // '"TZ=EST5EDT")/ ')

Coding TZ in JCL

Another way to fix the problem ...


1. This page shows you one way we cope with resetting the timezone (TZ) variable by inserting the appropriate timezone in the proc that is started.

2. The proper way to code the ENVAR statement (multiline JCL) is: 1. // PARM=('POSIX(ON)', 2. // 'ENVAR("_BPX_JOBNAME=FTPD",', 3. // '"TZ=EST5EDT")/&PARMS')

1. NOTE the format of the ENVAR stmt: 1. ENVAR("<variable>=<value>","<variable>=<value>",...)

3. Another alternative to above: 1. // PARM=('ENVAR("_CEE_ENVFILE=DD:STDENV")') 2. //STDENV DD ....

1. where STDENV DD refers to a VB dataset which contains: 1. TZ=EST5EDT 2. and other environment variables, one per record and starting in column 1.

Copyright IBM 2005C

• Sample CEEPRM

CEEDOPT(ABPERC(NONE) ALL31(ON) rptopts(on) ) /* Storage report */

CEECOPT(anyheap(4k,4080,anywhere,free))

CEEDOPT(ALL31(OFF), ENVAR('TZ=EST5EDT') )

Starting with V1R7, you can specify the Language Environment run-time options by using parmlib member CEEPRMxx.Default parmlib CEEPRMxx is found in CEE.SCEESAMP.

z/OS V1R7 Enhancement: CEEPRM A better way to fix the problem ...


1. Prior to V1R7 of z/OS you either used the mechanisms previously described to manipulate the TImeZone variables, or you could also choose to reassemble the module CEEBINIT to include "ENVAR=(('TZ=EST5EDT'),OVR)," so that the entire LE environment would use the correct timezone.

2. With V1R7 a new variation that is much easier has been introduced. You can set CEEPRM in SYS1.PARMLIB to specify the timezone variable along with other LE runtime options!

Copyright IBM 2005C

Siftdown on Model Major Nodes V1R5

Prior to V1R5:Certain Keywords only valid at LU definition level in Model Major NodesSiftdown not available.

At V1R5:GROUP statement possible in Model Major NodeLU Keywords can be coded at the GROUP Level and can filter/sift down.

Cannot be coded on PU PU keywords are not allowed on the GROUP definition statement.LU keywords are not allowed on the PU definition statement.

VBUILD TYPE=MODELGROUP1 GROUP CERTIFY=YES,CLRSESSQ=YES,ENCR=OPTLU1 LU LOCADDR=1PU2 PU ADDR=2LU2 LU LOCADDR=2PU3 PU ADDR=3LU3 LU LOCADDR=3GROUP2 GROUP CERTIFY=NO,CLRSESSQ=YESPU4 PU ADDR=4LU4 LU LOCADDR=4LU5 LU LOCADDR=5,CLRSESSQ=NO


1. Rather than coding the same keywords on all the LU definitions in a model major node, customers would like a way to code common LU keywords at a single place to sift down to all the underlying LU definitions. This will make coding many LUs in a model major node easier and less error prone.

2. To accomplish this, we will add the capability to code a GROUP statement in the model major node. The system programmer will be allowed to code LU keywords on the GROUP statement and those keywords will sift down to the LU statements below, unless they are overridden on the LU statement or another GROUP statement is encountered.

3. PU keywords are not allowed on the GROUP definition statement.4. LU keywords are not allowed on the PU definition statement.5. Recall that there is no relationship between the PU definition statements and the LU definition statements in the model major

node.6. In the example above, CERTIFY=YES, CLRSESSQ=YES, and ENCR=OPT sift down to LU1, LU2, and LU3.7. CERTIFY=NO and CLRSESSQ=YES sift down to LU4, but only CERTIFY=NO sifts down to LU5 because CLRSESSQ=NO is

explicitly coded on LU5, thus overriding the GROUP2 coding of CLRSESSQ=YES.8. ENCR=NONE is the default that is applied to LU4 and LU5.9. None of the PU definition statements are affected by the GROUP, nor do they have any affect on the sifting of the LU keywords

from GROUP definition statement to LU definition statement.

Copyright IBM 2005C

SWNET & DLRORDER Processing Improvement V1R5

SWNORDER=(CPNAME,FIRST | ONLY) or DLRORDER=(STATNID,FIRST | ONLY) FIRST

If a switched PU is not found using the value specified by the first operand, the alternate value of the first operand will be used to search for a switched PU. This is equivalent to the existing search method, and will be the default for the second operand.

ONLY If a switched PU is not found using the value specified by the first operand value, a search using the alternate value of the first operand will not be performed.

SWNORDER start option syntax:

+-SWNORDER=(CPNAME,FIRST)----------+>--+----------------------------------+->< +-SWNORDER=--CPNAME----------------+ +-STATNID-------------| +-(,FIRST)------------| +-(,ONLY)-------------| +-(CPNAME---,FIRST--)-| | +-,ONLY--+ | +-(STATNID--,FIRST--)-+ +-,ONLY--+

DLRORDER start option syntax:

+-DLRORDER=(STATNID,FIRST)---------+>--+----------------------------------+->< +-DLRORDER=--STATNID---------------+ +-CPNAME--------------| +-(,FIRST)------------| +-(,ONLY)-------------| +-(CPNAME----,FIRST-)-| | +-,ONLY-+ | +-(STATNID--,FIRST--)-+ +-,ONLY-+


1. The problem being addressed is as follows:2. A switched PU attempts to connect to the host (DIAL IN).3. A predefined PU definition exists with an IDBLK/IDNUM that does not match the DIAL IN request, but the CPNAME definition

does match the request.4. SWNORDER=STATNID start option is in effect. 5. A PU is not found by IDBLK/IDNUM, but a find by CPNAME does find a predefined PU. The connection is established using the

predefined PU even though the IDBLK/IDNUM value of the PU does not match the incoming request.6. Later, another PU dials in with an IDBLK/IDNUM that does match the predefined PU definition, but is unable to establish a

connection because the definition is already in use. 7. This can cause significant availability problems. 8. A second operand is added to the SWNORDER start option. 9. Valid values for the first operand remain CPNAME or STATNID. 10. Coding example:11. SWNORDER=(CPNAME,ONLY) 12. The values allowed for the second operand are:13. FIRST 14. If a switched PU is not found using the value specified by the first operand, the alternate value of the first operand will be used

to search for a switched PU. This is equivalent to the existing search method, and will be the default for the second operand.15. ONLY 16. If a switched PU is not found using the value specified by the first operand value, a search using the alternate value of the first

operand will not be performed.17. This second operand is also added to the DLRORDER start option.

Copyright IBM 2005C

Dynamic Reconfiguration for VTAM IOBUF V1R5XPANLIM value specifies the new total size for the IO buffer pool including the base allocation and expansions.

Buffer pool values: |__(__ ________ __,__ _________ __,__ ________ __,__ ___ __,_____________> |_baseno_| |_bufsize_| |_slowpt_| |_F_|

>__ ________ __,__ ________ __,__ _________ __)__________________________| |_xpanno_| |_xpanpt_| |_xpanlim_|

D NET,BFRUSE,BUFFER=io00 IST097I DISPLAY ACCEPTED IST350I DISPLAY TYPE = BUFFER POOL DATA 674 IST920I IO00 BUFF SIZE 670 EXP INCREMENT 15 IST921I TIMES EXP 0 EXP/CONT THRESH 15 / *NA* IST922I CURR TOTAL 100 CURR AVAILABLE 100 IST923I MAX TOTAL 100 MAX USED 70 IST989I EXP LIMIT 140030 BUFFS REQUESTED 0 IST924I -------------------------------------------------------------

f vtam,bfruse,buf=iobuf,xpanlim=24K IST097I MODIFY ACCEPTED IST495I XPANLIM HAS BEEN SET TO 24KIST223I MODIFY COMMAND COMPLETED


1. When the IO Buffer expansion limit (XPANLIM) is reached, storage requests fail with message IST154I EXPANSION FAILED FOR IO BUFFER POOL and I/O functions that require new buffers cannot continue.

2. Prior to z/OS V1R5, to increase the IO Buffer expansion limit, the XPANLIM value on the IOBUF start option must be changed and VTAM must be recycled. The value cannot be modified dynamically.

3. With z/OS V1R5, the XPANLIM value can be modified dynamically - no recycle of VTAM necessary!4. A new VTAM MODIFY command is provided begining with z/OS V1R5 to update the value of the XPANLIM parameter for the IO Buffer pool. 5. Note: This new command applys only to XPANLIM for the IO Buffer pool as it is the only buffer pool that has a limit to the amount of storage

that can be used for buffer expansion.6. A new MODIFY BFRUSE command will contain an XPANLIM operand : 7. F procname,BFRUSE,BUFFER=IOBUF,XPANLIM=value 8. XPANLIM value specifies the new total size for the IO buffer pool including the base allocation and expansions.9. XPANLIM=value ... Specifies the new total size for the IO buffer pool including the base allocation and expansions. (value can be specified

in any of the following forms: n or nK, where n is the number of 1024-byte increments to be used. The value of n is rounded up to the next multiple of 4. Or value can be specified as qM , where q is the number of 1-megabyte increments that are to be used. )

10. MODIFY BFRUSE Command11. _,BUFFER=IOBUF______12. >>__MODIFY procname,BFRUSE,_|____________________|_,XPANLIM=value___>13. |_,BUFFER=_ _IO00__ _|14. |_IO____|15. Example:16. d net,bfruse,buffer=io0017. IST097I DISPLAY ACCEPTED18. IST350I DISPLAY TYPE = BUFFER POOL DATA19. IST920I IO00 BUFF SIZE 334 EXP INCREMENT 5520. IST921I TIMES EXP 0 EXP/CONT THRESH 36 / *NA*21. IST922I CURR TOTAL 110 CURR AVAILABLE 11022. IST923I MAX TOTAL 110 MAX USED 123. IST989I EXP LIMIT 501000 BUFFS REQUESTED 024. IST314I END25. f vtam,bfruse,buf=iobuf,xpanlim=24K 26. IST097I MODIFY ACCEPTED 27. IST495I XPANLIM HAS BEEN SET TO 24K28. IST223I MODIFY COMMAND COMPLETED

Copyright IBM 2005C

New "Integrated IPSec" Including IPv6 on z/OS V1R7

Communications Server is committed to improvements in IPSEC/VPN offering on z/OS. , Introduce a new configuration for IPSEC/VPN with new applications and commands thatalso supports IPv6:

Policy Agent (pagent) - existing application is the central configuration pointreads and parses the new configuration file defining filter rules and vpn rulesapplies rules to the ipsec layer and iked where they are enforced

ike daemon - new but based upon isakmp daemon with:

improvements in configuration improvements in performanceimprovements to diagnostic

messages and loggingipsec command - new

command used to display/modify ipsec information on the local host

trmd (logging daemon)used to capture logged

events from ipsec to syslogdexisting daemon used for

logging Intrusion Detection(IDS) eventsIKE Peer

Policy Agenttrmd

IPSecCommand

Syslogd

Filter TableFilter Table Manual SAs Dynamic Filters Dynamic SAsDynamic Filters Dynamic SAs

UDP Port 500

IKE Daemon

Cached IKE Policy

VPN Policy

Log Buffer

IKE Negotiations

TCP/IP Stack

z/OS


1. Customers found Firewall Techologies difficult to configure and use1. Ex: took several commands to define a simple filter rule2. Integrated IPSEC simplifies configuration of basic filter rules3. When customers encountered failures with commands or functions, problems were difficult to diagnose. Goal is to greatly

improve diagnostic and event logging2. Policy Agent provides common, platform-independent configuration that could be used by other eServer platforms:

1. Networking Quality of Service (QoS) 2. Intrusion Detection Services (IDS) 3. Makes sense to use for IPSEC4. Provides an improved base to build IPv6 IPSEC functions

Copyright IBM 2005C

While You Were Sleeping: Resolver and DNS News


Copyright IBM 2005C

Maintain central control over DNS data.z/OS and OS/390 availability characteristics are often better than other platforms and a name server is a very critical infrastructure component in an IP network.Systems management disciplines are often in place on z/OS and OS/390 for monitoring critical servers and ensuring data is backed up, etc.A caching-only name server on z/OS can be used to improve performance for applications on z/OS that do many name resolver calls (like WebSphere Application Server). A caching-only name server will build up a cache and respond from the cache if possible.

DNS-based workload balancing/availability requirements inside the sysplex where DNS resource names are registered dynamically and load-balancing decisions are made by consulting the Work Load Manager (WLM) on z/OS or OS/390.

Bind 9 in z/OS V1R2 does not support the DNS/WLM functions

CachingName server

Appl Appl Appl

Appl

Other name servers

OS/390

Why Have a Name Server on z/OS?


1. z/OS and OS/390 are industrial strength hosts with high capacity and high availability. It makes sense to maintain central control over DNS data.

2. z/OS and OS/390 availability characteristics are often better than many other platforms and a name server is a very critical infrastructure component in an IP network.

3. Systems management disciplines are often in place on z/OS and OS/390 for monitoring critical servers, ensuring data is backed up, etc..

4. A caching-only name server on z/OS or OS/390 can be used to improve performance for applications on z/OS or OS/390 that do many name resolver calls. A caching-only name server will build up a cache and respond from the cache if possible.

5. DNS-based workload balancing (and availability) requirements inside the sysplex where DNS resource names are registered dynamically and load-balancing decisions are made by consulting the Work Load Manager (WLM) on z/OS or OS/390.

Copyright IBM 2005C

// Two IBM corporate subnets we wish to allow queries from.acl "corpnets" { 9.82.1.0/24; 9.67.43.0/24; };options { directory "/etc/dnsdata"; // Working directory pid-file "named.pid"; // Put pid file in working dir allow-query { "corpnets"; };};// Root server hintszone "." { type hint; file "root.hint"; };// Provide a reverse mapping for the loopback address 127.0.0.1zone "0.0.127.in-addr.arpa" { type master; file "named.lbk";notify no;};

Zone statement with loopback address specifies caching-only DNS:

Sample Caching-Only Configuration: V1R2


1. Here is an example of a caching-only name server for use by clients internal to a corporation. 2. Using the ACL (Access Control List of IP address) queries from outside clients - clients not in the subnets defined on the ACL

statement -- are refused. This coding allows clients in subnets 9.82.1.0/24 and 9.67.43.0/24 to make queries.

Copyright IBM 2005C

Multiple Resolver libraries exist, leading to inconsistent name resolutionNative MVS socket API resolver librariesLE resolver

The search order for the TCPIP.DATA file varies Users may need to know which API an application is using

Has caused a lot of confusion for system administratorsEnd users can override the system administrator's preferred configuration

Resolver logic differs from other platforms (except VM):If DNS specified, it is searched before LOCAL HOSTS fileIn general, only one DomainName can be specified for resolving hostnames

Native MVS Socket Appl.

TCP/IPSocketLibrary

TCP/IPResolver

UNIXSocketLibrary

LEResolver

1. //SYSTCPD2. userID/jobname.TCPIP.DATA3. SYS1.TCPPARMS4. TCPIP.TCPIP.DATA

1. RESOLVER_CONFIG2. /etc/resolv.conf3. //SYSTCPD4. userID/jobname.TCPIP.DATA5. SYS1.TCPPARMS6. TCPIP.TCPIP.DATA

UNIX Socket Appl.

Name Resolution Prior to CS for z/OS V1R2


1. When a sockets program is developed, a decision is made as to which sockets library to be used, i.e. whether the program will be a native sockets program or a UNIX sockets program. 1. Most of the sockets libraries have slightly varying source code syntax, which require source code changes if they need to be

migrated from, for example, the TCP/IP C sockets library to the UNIX C/C++ sockets library.2. A sockets library consists of: header/copy/macro files/members, statically linked stubs, and runtime support.

2. This visual shows only the Native MVS Socket Resolver and the Language Environment (LE, for UNIX Sockets programs) Resolver, although many more exist. Some of the different resolvers that exist in z/OS V1R1 and OS/390:1. CS/390 IP's C/C++ resolver including the DNS V4.9.3 ported resolver2. CS/390 IP's Assembler Callable and Macro resolver3. CS/390 IP's REXX Sockets resolver4. CS/390 IP's PASCAL Sockets resolver5. OS/390 C/C++ LE's resolver

3. The resolvers use different logic to locate the resolver configuration data (i.e. first the SYSTCPD DD dataset, followed by the userID/jobname.TCPIP.DATA, etc. for MVS Sockets applications versus first the RESOLVER_CONFIG environment variable, followed by the /etc/resolv.conf file, etc. for UNIX Sockets applications). Some of the resolvers have unique interpretations of resolver directives (e.g., retries) and content of trace resolver messages.

4. z/OS and OS/390 TCP/IP, prior to z/OS V1R2, has different resolver logic than other platforms, as follows:1. Only one domainorigin can be specified in a TCPIP.DATA file -- other platforms allow searching using multiple domainnames

during name resolution processing. z/OS and OS/390 TCP/IP may be customized with different TCPIP.DATA files associated with different servers to overcome this limitation in some situations, but this becomes quite complex.

2. If a DNS is specified, the DNS is always searched before the LOCAL HOSTS file -- this can be overridden under some circumstances, but otherwise, this logic is used. On other platforms, normally the LOCAL HOSTS file is searched before the DNS.

3. VM uses similar resolver logic to MVS TCP/IP, but other platforms differ as stated above.

Copyright IBM 2005C

New System Resolver ComponentUsed by TCP/IP, USS and LE socket APIsConsistent behavior and functionality

Support for new Resolver DirectivesNDOTS: - number of dots in a name needed before SEARCH list usedSEARCH - list of domain names to be used when resolving hostnamesSORTLIST - returned IP addresses sorted using specified network preferencesLOOKUP - influence order of DNS or local host files usage

Ability to specify a global TCPIP.DATA fileAllows system administrator to set system wide policy for name resolutionHelps eliminate confusion about the location of TCPIP.DATA

Ability to specify data set name for default TCPIP.TCPIP.DATA file Dynamic reconfiguration support for Resolver parameters Improved TRACE RESOLVER output

TCP/IP Socket Library

LE Socket Library

Native MVS Socket Appl. UNIX Socket Appl.

System Resolver

Resolver Setup File

1. MY.GLOBAL.TCPIP.DATA2. //SYSTCPD3. userID/jobname.TCPIP.DATA4. SYS1.TCPPARMS5. MY.DEFAULT.TCPIP.DATA

1. MY.GLOBAL.TCPIP.DATA2. RESOLVER_CONFIG3. /etc/resolv.conf4. //SYSTCPD5. userID/jobname.TCPIP.DATA6. SYS1.TCPPARMS7. MY.DEFAULT.TCPIP.DATA

DEFAULTTCPIPDATA ('MY.DEFAULT.TCPIP.DATA')

GLOBALTCPIPDATA ('MY.GLOBAL.TCPIP.DATA')

USS Socket Library

Resolver Enhancements with z/OS V1R2


1. There are many reasons for the enhancements to the resolver supplied with z/OS V1R2 including:1. Users requested:

1. The ability to specify certain search orders for finding TCPIP.DATA statements2. The ability to be able to control which values are used3. More flexibility in choice of filename to be used for the final search location for the TCPIP.DATA statement4. The ability to be able to determine which statements are being used and where they are located5. Users also requested new resolver directives, which haven't been available in prior releases

2. Additionally, developers requested simplification of the various resolver logic pieces in order to be able to reduce costs and test effort when new enhancements are introduced.

2. z/OS V1R2 enhances the TCP/IP resolver in the many ways shown on the visual.3. The z/OS V1R2 System Resolver consolidates the TCP/IP and LE resolver functions into a single set of facilities. SMTP and

DNS V9 BIND use the new TCPIP.DATA search capabilities but continue to provide their own resolver facilities since they have unique types of queries that they use (e.g., MX records and Zone queries).

4. The single resolver allows for more easily adding new functions, such as the new directives listed, plus it is a base upon which future IPv6 support can be added.

5. The System Resolver can be customized, through use of the GlobalTCPIPData statement in a SETUP file, as shown, to provide a single source of TCPIP.DATA statements.

6. It also allows for customizing, through use of the DefaultTCPIPData statement in the SETUP file, the final search location for TCPIP.TCPIP.DATA. If the DefaultTCPIPData statement is not included in the Setup file, then TCPIP.TCPIP.DATA continues to be the final location searched as was the case prior to z/OS V1R2.

7. The MVS MODIFY command allows for dynamically updating the resolver configuration and refreshing long running applications' resolver TCPIP.DATA settings.

8. Improved Trace Resolver information allows for easier understanding of what values are being used and where their definitions are coming from.

Copyright IBM 2005C

//RESOLVER PROC PARMS='CTRACE(CTIRES00)'//* //EZBREINI EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS //* //* SETUP contains Resolver setup parameters. //* See the chapter on "Understanding Resolvers" in//* the IP Configuration Guide for more information. A sample of //* Resolver setup parameters is included in member RESSETUP //* of the SEZAINST data set. //* //*SETUP DD DSN=TCPIP.TCPPARMS(RESSETUP),DISP=SHR,FREE=CLOSE //*SETUP DD DSN=TCPIP.SETUP.RESOLVER,DISP=SHR,FREE=CLOSE //*SETUP DD PATH='/etc/setup.resolver',PATHOPTS=(ORDONLY)

If SETUP file is protected, Resolver Proc's USERID needs READ authority or 644 permission bit settings if HFS fileEZARACF sample has been updated to add Resolver USERID and add resolver to Started Class

Sample Resolver Procedure V1R2


1. This is a copy of the sample Resolver start procedure, shipped in SEZAINST as RESOPROC. Note the CTRACE parameter for specifying Resolver component trace data to be collected (covered later)

2. The //SETUP DD specifies the name of the "Setup file". This is where the GlobalTCPIPData and DefaultTCPIPData statements are specified. The DD can point to either an HFS (Maximum line length of 256) or MVS data set (member of a PDS or a flat sequential data set). For MVS, the file must be Fixed(F) or Fixed Block(FB) with LRECL between 80 and 256.

3. If there is security on the data sets, then the Userid assigned to the Resolver proc must have READ authority. For HFS that means permission bit settings of 644 are needed.1. NOTE: If you have not customized Resolver and are using the original RESOLVER started by OMVS -- that is, not started

from a PROCLIB -- the Userid that you might authorize to PARMLIB is "RESOLVER" depending on how you have chosen to implement the Started Class Profile or ICHRIN03 and if you have defined PARMLIB with UACC(NONE). See APAR PQ57232.

4. Here is a sample RACF job to setup the RESOLVER security environment. The shipped EZARACF sample has been updated. Not shown is the READ UACC to the MVS data sets.

//RACF JOB USER=USERxx,PASSWORD=yyyyyyyy, // MSGLEVEL=(1,1),MSGCLASS=A,CLASS=A //DAEMONS EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * ADDUSER RESOLVER DFLTGRP(SYS1) OMVS(UID(42) HOME('/')) RDEFINE STARTED RESOLVER.* STDATA(USER(RESOLVER))

Copyright IBM 2005C

; ; The following statement defines the final search location for ; TCPIP.DATA statements. It will replace TCPIP.TCPIP.DATA; It may be an MVS data set or HFS file.;DEFAULTTCPIPDATA('TCPIP.TCPIP.DATA');............;; GLOBALTCPIPDATA('TCPCS.SYS.TCPPARMS(GLOBAL)');.............; GLOBALIPNODES('TCPCS.SYS.TCPPARMS(IPNODES)') ; .......... ; DEFAULTIPNODES('TCPCS.SYS.TCPPARMS(IPNODES)') .......... ; NOCOMMONSEARCH ; ; COMMONSEARCH ; ;

Sample from SEZAINST(RESSETUP):

Sample Setup File: V1R2 & V1R4

Added V1R4

Added V1R4


1. This is a sample Setup file.2. This sample is shipped with Communications Server in SEZAINST as member RESSETUP.3. Remember once again that if the DEFAULTTCPIPDATA statement is omitted, then the old final search location is still used:

TCPIP.TCPIP.DATA.4. You may use sequential datasets, PDS members, or HFS/ZFS files for this information.5. "COMMONSEARCH" and the "IPNODES" setttrings were added in V1R4.

1. We recommend that you use COMMONSEARCH and IPNODES so that you don't have to worry about MAKESITE commands for the HOSTS.LOCAL files.......... IPNODES is much easier syntactically to code and resembles what other platforms use for this funciton.

2. V1R4 enhancements:3. New search order for locating local host files when resolving IPv6 query4. Uses IPNODES files rather than HOSTS.xxxxINFO files5. Ability to specify a default and global file for the local host file6. DEFAULTIPNODES and GLOBALIPNODES7. Ability to allow users to use the same local host file and same search order for both IPv4 and IPv6 queries, and for both MVS

and UNIX environments8. COMMONSEARCH9. Some changes to local host file size restrictions10. /etc/hosts maximum host names per IP address increased from 6 to 3511. /etc/hosts maximum host name characters increased from 24 to 128

Copyright IBM 2005C

If a GLOBALTCPIPDATA file is used, these statements must be coded or defaults are used

Domain or DomainOrigin or SearchNameServer and/or NSInterAddrNSPortAddrResolverTimeOutResolverUDPRetriesResolveViaSortlist

These statements may be used in the GLOBALTCPIPDATA file but, if not coded there, can be located in other TCPIP.DATA (or resolv.conf) files, according to the V2R10 search orders

HostNameTCPIPJobNameDataSetPrefixMessageCaseSockDebugSockNoTestStorTrace ResolverTrace SocketAlwaysWTOOptionsLookUp

Domain is a new statement, functionally equivalent to and mutually exclusive with DomainOrigin; must specify Domain or DomainOrigin or SearchNameServer is a new statement, functionally equivalent to NSInterAddr

"Resolver" Statements: V1R2


1. At the top are listed the "Resolver" statements. If a GLOBALTCPIPDATA file is used, these statements must be coded in it or defaults are applied. If the statements are coded in other TCPIPDATA files, their values will NOT be used.1. Defaults for domain/domainorigin and nameserver/nsinteraddr are null2. Default for NSPortAddr is 533. Default for ResolverTimeOut is 30 seconds4. Default for ResolverUDPRetries is 15. Default for ResolveVia is UDP6. Default for Search is null7. Default for Sortlist is null8. At the bottom are listed other statements that may be coded in TCPIP.DATA files. These statements may be coded in the

GLOBALTCPIPDATA file, in which case their values will be used as coded in the global file. These statements may be coded in other TCPIP.DATA files and their values assigned from these files as long as they haven't been coded in the global file. The search for the statements' values follows the OS/390 V2R10 logic.

2. The statement DOMAIN may be used instead of DOMAINORIGIN, if desired. 3. The statement NAMESERVER may be used instead of NSINTERADDR, if desired. If both NameServer and NSInterAddr are

used, then their definitions are merged. 4. With z/OS V1R2, DOMAIN or DOMAINORIGIN can be specified, NAMESERVER and/or NSINTERADDR can be specified, and #

or ; can be used for comments.5. DOMAIN is a new statement, functionally equivalent to specifying DOMAINORIGIN6. NAMESERVER is a new statement, functionally equivalent to specifying NSINTERADDR; it can even be used together with

NSINTERADDR statements.7. New statements may be coded in the TCPIP.DATA file:8. SORTLIST9. OPTIONS ndots: and/or debug10. LOOKUP11. SEARCH12. The TCPIP.DATA file can be an MVS or HFS file, as follows:13. MVS - Fixed(F)/Fixed Block(FB), LRECL 80 to 25614. 56 is allowed because of resolver's support for SITEINFO file, but current documentation says 80 and 80 to 256 is

recommended 15. HFS with a maximum line length of 256 characters

Copyright IBM 2005C

+--DNS--LOCAL--+>>--+--------------+---LOOKUP-----|--------------|----->< |-system-name:-| |--DNS---------| |--LOCAL-------| |--LOCAL--DNS--|

LOOKUP and SEARCH Statements V1R2

If not specified the order is as pre-V1R2: DNS then LOCALIf multiple LOOKUP statements, the last valid one usedIf multiple parameters the first occurrence is honoredIf an invalid parameter is encountered, the entire line is ignored

<--------->>_____________________SEARCH________|__________|______>< |_system_name:_| |__domain__|

Use the SEARCH statement to specify the list of domain name(s) that are appended, in the order listed, to the host name to form the fully qualified domain name for a host.


1. These enhancements will look familiar to people who have worked on UNIX systems more than on MVS systems. 2. LOOKUP:

1. This support was added by New Function APAR PQ51329, and is not described in the IP Configuration Reference manual at the V1R2 level; it is documented in subsequent releases of the manual. If you are still at the now unsupported z/OS V1R2, you will need to consult the APAR should be used for documentation.

2. If not specified the order is as pre-V1R2 DNS then LOCAL3. If multiple LOOKUP statements, the last valid one used4. If multiple parameters the first occurrence is honored5. If an invalid parameter is encountered, the entire line is ignored 6. A few examples:

1. LOOKUP LOCAL - resolver will only use the local host files for the name or address resolution (i.e., API dependent)2. LOOKUP LOCAL DNS - resolver will use local host files first and if not resolved then use the DNSs specified3. LOOKUP LOCAL LOCAL DNS LOCAL - results in LOCAL then DNS usage4. LOOKUP LOCAL JUNK DNS - results in entire statement being ignored (similar to other statement processing). If no other

valid LOOKUP statement was encountered then defaults of DNS then LOCAL will be used.3. SEARCH:

1. The domain name is appended to the host name for resolver lookups until either the list is exhausted or an IP address is returned from the name server.

2. Up to six(6) names separated by at least one blank are allowed3. If more than 6 domains are specified only the first six are used4. Multiple SEARCH statements are allowed5. The first domain name specified is used as the value for DOMAINORIGIN/DOMAIN6. If both the SEARCH and DOMAINORIGIN/DOMAIN statements are present, the one that appears last will be used7. The domain names are appended for name server queries as well as for searching the HLQ.HOSTS.SITEINFO and/or

/etc/hosts files8. If other than fully qualified names are to be used the SEARCH statement or DOMAINORIGIN/DOMAIN statement should be

specified

Copyright IBM 2005C

MODIFY RESOLVER,DISPLAYDisplays datasets/files of Resolver Setup

Methods for enabling this trace:Specify RESOLVER_TRACE environment variable

UNIX shell export command or in STDENV DDexport RESOLVER_TRACE=STDOUTexport RESOLVER_TRACE=/tmp/myjob.resolv.traceexport RESOLVER_TRACE="//'userid.appl.restrace'"

Allocate SYSTCPT DD - turns on and points to trace file locationTSO ALLOC commandSequential Data set only - LRECL 80 to 256, RECFM FBStandard JCL - recommend SYSOUT=*

TCPIP.DATA statement TRACE RESOLVER, available prior to CS for z/OS V1R2OPTIONS DEBUGNot recommended in GlobalTCPIPData file

C/C++ LE programs by setting the res_state debug bit _res.options |= RES_DEBUG;

See INFO APAR II13398

Diagnostic Aids - DISPLAY & Trace Resolver V1R2


1. The Resolver searches for the following settings, in order, and if found, activates the TRACE RESOLVER:1. For LE C/C++ environments, the RESOLVER_TRACE environment variable which specifies the destination of the trace

output. For example:1. export RESOLVER_TRACE=STDOUT2. export RESOLVER_TRACE=/tmp/myjob.resolv.trace3. export RESOLVER_TRACE="//'userid.appl.restrace'"

2. For all environments including LE, SYSTCPT DD allocation specification. For example:1. TSO alloc fi(systcpt) da(*)2. TSO alloc dd(systcpt) da(appl.restrace)3. //SYSTCPT DD SYSOUT=*4. //SYSTCPT DD DISP=SHR,DSN=USERID.APPL.RESTRACE

2. If the TRACE RESOLVER (not new with z/OS V1R2) or OPTIONS DEBUG statement is found in TCPIP.DATA, the trace output will go by default to STDOUT for UNIX apps and to SYSPRINT for TSO/MVS apps. If the environment variable or SYSTCPT is specified then the output goes to where they indicate.

3. If the application sets the debug bit in the LE "res" structure, the trace will go by default to STDOUT (UNIX) or SYSPRINT (TSO/MVS). If the environment variable or SYSTCPT is specified then it goes to where they indicate.

4. MVS output must be sequential RECFM FB and LRECL 80 to 256. Cannot be a member of a PDS. Recommend SYSOUT=*5. HFS "normal" 256 character line6. If the length of line is 128 or greater then the last 6 characters on the line is the TCB address issuing the resolver API call.

Copyright IBM 2005C

Resolver Trace Initialization Complete -> 2002/07/01 13:36:34.638198 res_init Resolver values: Global Tcp/Ip Dataset = /etc/glblres1 Default Tcp/Ip Dataset = None Local Tcp/Ip Dataset = //DD:SYSTCPD ==> USER3.TCPIP.MYDATA Translation Table = CS390.STANDARD.TCPXLBIN UserId/JobName = TCPCS Caller API = TCP/IP Sockets Extended (G) DataSetPrefix = CS390 (G) HostName = MVSI (G) TcpIpJobName = TCPCS (G) Search = RALEIGH.IBM.COM ibm.com (G) SortList = 9.0.0.0/255.255.255.0 198.133.16.99/255.255.255.255 (G) NameServer = 9.11.25.46 9.67.128.82 (*) NsPortAddr = 53 (*) ResolverTimeout = 30 (*) ResolveVia = UDP (*) ResolverUdpRetries = 1 (*) Options NDots = 1 (L) Options Debug (*) SockNoTestStor (*) AlwaysWto = NO (*) MessageCase = MIXED (L) Trace Socket (*) LookUp = DNS LOCALres_init Succeeded

G - Global dataset

L - Local dataset

D - Default dataset

E - for environment variable

* - for a default value

Trace Resolver - res_init V1R2

F RESOLVER,DISPLAY EZZ9298I DEFAULTTCPIPDATA - None EZZ9298I GLOBALTCPIPDATA - /etc/glblres1 EZZ9298I DEFAULTIPNODES - /etc/ipnodes EZZ9298I GLOBALIPNODES - /etc/ipnodes EZZ9304I COMMONSEARCH EZZ9293I DISPLAY COMMAND PROCESSED


1. After discussion with the IBM Level 2 team, it was decided to model the Trace Resolver output after what the PASCAL resolver displays.

2. Here's an example of the TCPIP Stack TN3270 Server resolver usage. 1. First the res_init portion of the trace output:

1. Date/time line2. Any errors are first3. Data sets used4. UserId/JobName5. API type that issued the res_init

2. Values of all the TCPIP.DATA statements1. The letter in parentheses indicates the origin of the value:

1. G for the Global data set2. L for the Local data set3. D for the Default data set (not used in this example because the local data set was found)4. E for environment variable (not used in this example). Used for LE environment variables LOCALDOMAIN and

MESSAGECASE.5. *for the default value

Copyright IBM 2005C

From TSO: free fi(SYSTCPT)

USER1:/u/user1: >set -A RESOLVER_TRACE USER1:/u/user1: >ping meatball CS V1R2: Pinging host meatball (9.37.80.154) Ping #1 response took 0.000 seconds. USER1:/u/user1: >

READY free fi(systcpt) READY ping meatball Ping CS V1R2: Pinging host MEATBALL (9.37.80.154). Use ATTN ... PING: Ping #1 response took 0.000 seconds. Successes so far 1. READY

From UNIX:set -A RESOLVER_TRACE UPPERCASE!

or ... "TRACE

RESOLVER" still works!

Stopping the Resolver Trace V1R2


1. To stop the resolver trace you use the method that is appropriate for the environment from which you are testing:1. If you are examining the resolver trace from TSO, then use the "free" command to remove the allocation for SYSTCPT.2. If you are examining the resolver trace from UNIX, then use the UNIX command, "set -A RESOLVER_TRACE." WARNING:

The parameters/values of this command are case sensitive; you must use UPPERCASE for both the parameter "-A" and the value "RESOLVER_TRACE."

3. You may continue to use the older method for enabling and disabling Resolver Trace: placing the statement "TRACE RESOLVER" in the TCPIP.DATA file and refreshing if necessary; then removing the statement if necessary and refreshing again.

Copyright IBM 2005C

Use COMMONSEARCH setup statement to simplify the search order choices for IPv4 or IPv6 searches!

New IPv6 search order will be used for IPv4 searches as wellMVS and UNIX environments would utilize the same search order for IPv4 searches as well as IPv6 searches

All local resources can be defined in a single local host file (i.e., ETC.IPNODES) rather than spread across multiple files (i.e., ETC.IPNODES and HOSTS.LOCAL)

Applicable to both new and old Resolver APIs

Using multiple search orders (which is the system default) has its drawbacks:

Same API (such as Getaddrinfo) would use different local files on same invocation, if searching both IPv4 and IPv6Local resources would have to be defined in multiple places, if assigned both types of addresses.

Discard Host.Local! Simplifying Search Order V1R4


1. Although the IPv6 search order was simplified, for migration reasons the IPv4 search order is not modified. The side effect of this, however, is that by default, the user would be required to maintain two different local host files (i.e., HOSTS.LOCAL and ETC.IPNODES) for their system. Also, while the existing APIs (such as Gethostbyname) would be unaffected, the newer APIs would be forced to process two files when, for instance, Getaddrinfo was invoked to search for both IPv4 and IPv6 resources.

2. A much simpler approach is to utilize the new COMMONSEARCH setup statement. By specifying COMMONSEARCH, the user indicates that only the new "IPv6" search order should be used, regardless of whether the search if for IPv6 or for IPv4 resources. This means that only one file, i.e. ETC.IPNODES, now has to be managed for the system, and that all the APIs utilize the same single file.1. IPv6/4 common search order: The resolver uses the IPv6/4 common search order when it determines that any of the following

conditions exist: 1. The resolver setup statement COMMONSEARCH is specified and the getaddrinfo, gethostbyname, getnameinfo,

gethostbyaddr, sethostent, gethostent, or endhostent APIs are invoked. 2. The resolver setup statement NOCOMMONSEARCH is specified (or left to default), and the getaddrinfo API is attempting to

locate an IPv6 address. 3. The resolver setup statement NOCOMMONSEARCH is specified (or left to default), and the getnameinfo API is attempting

to resolve an IPv6 address.4. Note: The IPv6/common search order is never used for the following API socket calls: getnetbyname, getnetbyaddr,

setnetent, getnetent, endnetent 3. The use of COMMONSEARCH not only reduces IPv6 and IPv4 searching to a single search order, but also collapses the UNIX

and MVS environments to a single search order as well.

Copyright IBM 2005C

ETC.IPNODES (a new type of the local host file)IPv4 and IPv6 addressesEach IP address can have up to 35 host namesEach host name has the maximum of 128 characters

IPv6 addresses can only be defined in ETC.IPNODESHOSTS.SITEINFO, HOSTS.ADDRINFO files

IPv4 addresses onlyEach IP address can have up to 6 host namesEach host name has the maximum of 24 characters

/etc/hosts fileIPv4 addresses onlyEach IP address can have up to 35 host names (increased from 6)Each host name has the maximum of 128 characters (increased from 24)

Local Host Files: Simpler than Ever in V1R4

; 9.67.43.100 NAMESERVER 9.67.43.126 RALEIGH 9.67.43.222 HOSTNAME1.RALEIGH.IBM.COM 129.34.128.245 YORKTOWN WATSON 1::2 TESTIPV6ADDRESS1 1:2:3:4:5:6:7:8 TESTIPV6ADDRESS2 ;

IPNODES and ****not**** HOSTS.LOCAL with MAKESITE!

Not Required: IPv6

Enablement!


1. Get rid of HOSTS.LOCAL. Stop having to use the annoying MAKESITE:1. MAKESITE as a TSO command or in a batch job to generate new hlq.HOSTS.SITEINFO and hlq.HOSTS.ADDRINFO data

sets. 2. Switch to IPNODES and COMMONSEARCH and enjoy the esy administration! You don't even have to have enabled IPv6 in

your z/OS system to enjoy the fruits of IPNODES!3. In order to avoid impacting existing IPv4 queries, the use of /etc/hosts, HOSTS.LOCAL, HOSTS.SITEINFO, and

HOSTS.ADDINFO files continues to be supported for IPv4 addresses only.NOTE: Two minor changes were made to /etc/hosts processing. CS with V1R4 allows each IP address to have up to 35 host names, and each host name can be a maximum of 128 characters.

4. The HOSTS.SITEINFO and HOSTS.ADDRINFO files continue to be generated from HOSTS.LOCAL file via the MAKESITE utility.

5. ETC.IPNODES is a new local host file (in the style of /etc/hosts) which may contain both IPv4 and IPv6 addresses. The introduction of this file allows the administration of local host files to more closely resemble that of other TCP/IP platforms and eliminates the requirement of post-processing the files (e.g. MAKESITE).

6. IPV4-mapped addresses may not be present in the ETC.IPNODES file. 7. The sample ETC.IPNODES file can be found as member EZBREIPN (alias IPNODES) in SEZAINST.

Copyright IBM 2005C

MVS and Unix environments1. GLOBALIPNODES 2. RESOLVER_IPNODES environment variable (UNIX only)3. userid/jobname.ETC.IPNODES4. hlq.ETC.IPNODES5. DEFAULTIPNODES6. /etc/ipnodes

New search order defined for selecting new ETC.IPNODES local host files for IPv6 searches:

MVS environment UNIX environment1. userid/jobname.HOSTS.xxxxINFO2. hlq.HOSTS.xxxxINFO

1. X_SITE and X_ADDR environment variables2. /etc/hosts3. userid.HOSTS.xxxxINFO4. hlq.HOSTS.xxxxINFO

Existing search order for local host files (i.e., HOSTS.LOCAL) for IPv4 searches differs based on operating system environment:

Possible Search Orders V1R4


1. For IPv6 searches, CS for z/OS V1R4 merged the MVS and UNIX search orders to simplify the choices available, and to eliminate the need for the MAKESITE step required for the HOSTS.xxxxINFO files.

2. Additionally, steps were added for locating a local host file to be used by every user on the system (i.e, GLOBALIPNODES), and for locating a local host file to be used in the event that an individual user does not have their own host file defined (i.e., DEFAULTIPNODES).

3. As shown in the IPv4 search order table, previously the HFS file (i.e., /etc/hosts) had precedence over MVS files. For IPv6, however, the precedence is inverted for the following reasons:1. Individual users, sharing the same system, are allowed to have their own local host file by specifying a different "userid" or "hlq";

however, there can only be a single /etc/ipnodes on the system, so it should be given less precedent than individual user files.2. Normally, for MVS environments, HFS files are not utilized, so to impact the MVS applications as little as possible, /etc/ipnodes is

placed at the end of the ordering.4. If you specify "NOCOMMONSEARCH" in the Resolver Setup File, the IPv6 search order is used by the new Getaddrinfo and

Getnameinfo APIs. The IPv4 search order can be used by the existing APIs (Gethostbyname, Gethostbyaddr, Gethostent, Sethostent, and Endhostent) and the new APIs (Getaddrinfo and Getnameinfo). For those APIs, please refer to z/OS Communications Server IP Application Programming Interface Guide and z/OS Communications Server IP Configuration Guide manuals for details.

5. If you specify "COMMONSEARCH" in the resolver setup file, then the resolver uses the IPv6/4 common search order when it determines that the getaddrinfo, gethostbyname, getnameinfo, gethostbyaddr, sethostent, gethostent, or endhostent APIs are invoked.

6. Once a given file is located, the search ends.7. Creating new local host file (ETC.IPNODES)8. Copy existing /etc/hosts into a new local host file ETC.IPNODES9. Move HOSTS.LOCAL addresses and host names to the new file10. Add any new IPv6 addresses and host names to the new file11. Sample ETC.IPNODES is SEZAINST(EZBREIPN)12. Using COMMONSEARCH13. Copy the sample Resolver setup from SEZAINST(EZBRECNF)14. Change the setup statement to use COMMONSEARCH15. Issue Resolver MODIFY REFRESH command to dynamically change COMMONSEARCH setting16. If COMMONSEARCH is to be used across Resolver IPLs, change the Resolver proc to use the new setup file in SETUP DD

statement17. Can acquire a copy of the sample Resolver proc from SEZAINST(EZBREPRC)

Copyright IBM 2005C

Problem: Automatic resolution of MVS system symbols was not supported for the Resolver setup file nor for the TCPIP.DATA file. It was necessary to use the EZACFSM1 utility program to resolve MVS system symbols for those files.

Solution: Support automatic resolution of MVS system symbols in the Resolver setup file and in the TCPIP.DATA file. Symbols (such as &SYSNAME, &SYSPLEX, etc.) are resolved as the file records are read.

MVS System Symbols Automatically in V1R6


Copyright IBM 2005C

Appendices


Copyright IBM 2005C

While You Were Sleeping: Management News


Copyright IBM 2005C

z/OS CS Policy Performance Collection V1R6

PerformanceLog

Non-QoS aware appl.

QoS aware appl.

RSVP Agent

Policy Agent

TRM Daemon

Netstat command

1 2 3 4

Active QoS, Sysplex Distributor, and IDS

policies

Set TOS/DS, enforce TCP data rates and

connection limits

Sysplex Distributor workload balancing

Fast Response

Cache Accelerator

(FRCA)

Intrusion Detection

Services (IDS)

TCP/IP KernelActive Queue Management (QDIO)

IPPackets

Collect and maintain: SLA & SLAPM2 performance dataPolicy performance dataSD performance data

Data Traffic

LDAP Server

Policies

Local Policies

Token Bucket traffic enforcer

Set TOS/DS

URI

SSL

Events, statistics

zQoSManager zIDS

Manager

User Performance

MonitorApplicationPAPI

SLA Subagent

(pagtsnmp)NetworkSLAPM2 Subagent(nslapm2)

pasearchcommand

DPI

DPI

PAPIRAPI

Data Traffic

RSVP Traffic

Active Policies

SNMPAgent


1. If policies are coded, performance data collection will always take place in the stack - the PolicyPerformanceCollection statement only enables retrieval of this data by Pagent.

2. Policy performance log file allows you to do offline performance analysis3. Information received from the stack will be written to this file in the same structure in which it is received4. Logged in binary format5. Stack name is appended to the filename defined by the PerformanceLogFile parameter in the PolicyPerformanceCollection

statement6. Data is logged based on the interval defined by the LogSamplingInterval parameter in the PolicyPerformanceCollection

statement7. C Sample file in /usr/lpp/tcpip/samples/pagent/pLogReader.c8. README in the same directory shows how to build the sample9. Displays the binary performance data to the user in a readable format

Copyright IBM 2005C

Pagent Configuration File for Performance Collection V1R6

PolicyPerformanceCollection statementPolicyPerformanceCollection {Enable | Disable}Parameters:

DataCollection {Rule | Action}type of performance data that needs to be collected (can have multiple types)

MinimumSamplingInterval minSampIntsmallest value, in seconds, that can be requested from an application, to retrieve performance data from the stack (default is 30); an algorithm is used to determine the actual interval

LogSamplingInterval logSampIntinterval, in seconds, at which the performance data will be retrieved from the stack and logged into the log file defined by PerformanceLogFile parameter

PerformanceLogFile logFilename of the file to which the collected performance data should be written

SizeOfLogFile logFileSizelog file size, in kilobytes (default is 300)

NumberOfLogFiles numLogFilesnumber of performance log files to be maintained (default is 3)

Note: See z/OS CS IP Configuration Reference for details on this new statement, as well as formulas that will help determine the size and number of log files needed


Copyright IBM 2005C

pLogReader sample output:

time: 04/30/03-15:12:44 version: 1 policy name: defaultRule record type: 1 record id: 1 bytes transmitted: 1072470 packets transmitted: 744 active connections: 1 accepted connections: 2 smoothed rtt avg: 13 smoothed rtt mdev: 8 bytes retransmitted: 0 packets retransmitted: 0 smoothed conn delay avg: 0 smoothed conn delay mdev: 0 accept queue delay avg: 0 accept queue delay mdev: 0 packets transmitted in profile: 0 bytes transmitted in profile: 0 packets received: 386 bytes received: 12949 packets transmitted timed out: 0 denied Connections: 0

pLogReader Sample Output V1R6


Copyright IBM 2005C

While You Were Sleeping: VIPA and Sysplex Distributor News


Copyright IBM 2005C

Lifting the Dynamic VIPA Limits (V1R5)

OS/390 V2R8: Limit of 256 Dynamic VIPAsz/OS V1R5: Increased to 1024 Dynamic VIPAs

Be aware of OSA Limits for storing IP addressesBe aware of OSPF OMPROUTE link state advertisement restrictions for "router LSAs"

If a pre-V1R5 stack is to back up DVIPAs defined on a V1R5 stack, the DVIPAs to be backed up by the pre-V1R5 stack must be among the first 256 DVIPA definitions on the V1R5 stack.

Release Level Maximum # of Dynamic VIPAs Comments

OS/390 V2R8 256

z/OS V1R5 1024 OSA Limits?OSPF Router LSA size?


1. In releases prior to z/OS V1R5, there is a cap of 256 on the number of configured or target DVIPAs that may be defined.2. A configured Dynamic VIPA is one that is created in any of the following ways, and might or might not be active:

1. Using VIPADEFINE2. Using VIPABACKUP3. Using an IOCTL SIOCSVIPA DEFINE when this stack had a covering VIPARANGE 4. Using a BIND when this stack had a covering VIPARANGE5. A target (or destination) DVIPA is one that was created on this stack as a result of a VIPADISTRIBUTE for an active VIPA on another stack.

3. Configurations in which an application instance is associated with a DVIPA might require a large number of DVIPAs. Some customer configurations may require more than 256 DVIPAs per stack. Therfore this rrestriction was lifted in V1R5 of z/OS.

4. Expanding the DVIPA limit from 256 to 1024 allows the user more flexibility in defining a network configuration. In association with this increase, many DVIPA associated control blocks have been moved from common to TCP/IP private storage. Thoughtful consideration should still be used when planning workload and the number of dynamic DVIPAs needed.

5. Moving the DVIPA associated control blocks to TCP/IP private storage should reduce a customer's requirement for common storage.6. A stack is now limited to no more than 1024 configured or target DVIPAs at any one time. 7. OSA-Express devices have a limit on the number of IP address (both IPV4 and IPV6 addresses) that can be registered to the device.

1. The limit is dependent on the microcode level of the OSA-Express device. 2. This limit applies across all TCPIP stacks that share the OSA-Express device. 3. When defining a large number of VIPAs, users should take care not to exceed this limit. 4. If the limit is exceeded, IP addresses beyond the limit will not be registered with the OSA-Express devices, and incoming packets with those IP addresses will not

be routed to the correct stack unless that stack is designated as the Primary Router.8. When defining a large number of DVIPAs, there may be a restriction involving dynamic routing using OMPROUTE when OSPF is used. OSPF currently has a limit on

the number of IP addresses that may be carried in a Link State Advertisement. The limit is based on the MTU size of the network interfaces. 9. The MTU size defined on OSPF_INTERFACE statements limits the size of advertisements that can be sent or received over that interface. OMPROUTE cannot

build an advertisement whose size would exceed the largest MTU size of all its interfaces. Also, OMPROUTE cannot receive an advertisement that is larger than the largest MTU size defined of all its interfaces In either of these cases, you will see the following message:1. EZZ7967I ADVERTISEMENT DISCARDED, OVERFLOWS BUFFER: LS TYPE x ID x.x.x.x ORG y.y.y.y2. When this happens on an originating host, that host will not be able send Router Link State Advertisements and therefore other hosts will not be able to calculate

routes to any destinations (for example, VIPAs) owned by the originating host. OMPROUTE will terminate if it encounters this condition, because if it can't send its router LSA, it is useless as a router. When this happens on a receiving host, that host will not be able to compute routes to any destinations advertised in the discarded LSA. Also note that other OSPF implementations may have similar or stricter limitations, in which case they would be unable to receive or propagate large router LSAs received from OMPROUTE. These scenarios can severely affect network connectivity and routing capability. If large numbers of VIPA interfaces are going to be used, you are well-advised to examine OSPF MTU sizes throughout your network to ensure that large router LSAs can be propagated.

3. Normally this would not be a problem, as Link State Advertisements seldom exceed their allowed MTU sizes. However, if a large number of VIPA or dynamic VIPA interfaces are defined on a host, this may become a consideration. The size of the router LSA will include 52 bytes for headers, plus the number of bytes required to advertise the host's owned interfaces. The number of bytes required for each interface is:1. VIPA: 12 bytes plus 12 bytes for each VIPA subnet 2. Point to Point: 24 bytes3. Point to Multipoint: 12 bytes plus 12 bytes for each neighbor on the interface4. All other types: 12 bytes

Copyright IBM 2005C

Unlimited # of PORTs: Distributed DRVIPA in V1R5! +-DEFINE-+|--VIPADISTRIBUTE--+--------+--+--------------+--ipaddr--+----------------+--> +-DELETE-+ +-SYSPLEXPORTS-+ | | | V------+ | +-PORT-+-num-+--+

>--DESTIP--+-ALL-----------+-->< | | | V----------+ | +-+-dynxcfip-+--+

Pre V1R

5:

OPTIONAL

OS/30 V2R10: Birth of Sysplex Distributor (SD)Maximum of 4 Ports per Distributed Dynamic VIPA

z/OS V1R2Maximum of 64 ports with APAR PQ65205(UQ70170) in V1R2

z/OS V1R5No limit -- ports are dynamically created!All SD participants MUST BE V1R5 and higher.


1. The initial implementation of Sysplex Distributor allowed a maximum of four ports per distributed Dynamic VIPA. Apar PQ65205(UQ70170) in V1R2 raised this limit to 64.

2. However, as large customers began to tailor their applications for use with Sysplex Distributor, this limitation became too restrictive.

3. This change allows applications that bind specifically to an appropriately-configured distributed Dynamic VIPA to have more than four ports - the number of ports is not limited by configuration, but rather by other considerations such as available storage.

4. To preserve current operation, current TCP/IP configuration works unchanged. If a distributed Dynamic VIPA has a VIPADISTRIBUTE statement configured with ports specified, distribution occurs only for those ports (except as required to handle Passive-Mode (or Firewall-Friendly) FTP). However, if the PORT parameter is omitted from the VIPADISTRIBUTE statement, and the application instances bind specifically to the distributed DVIPA on a target stack (so that TCP/IP can tell that distribution is requested), then an entry will be created in the Distributed Destination Port Table (DPT) for that distributed DVIPA and port and target stack, and that stack and application instance will become a candidate for distribution of connections directed at that distributed DVIPA and port.

5. All TCP/IP stacks that participate in distribution in this manner must be at least V1R5:1. Sysplex Distributor routing stack (where VIPADEFINE/VIPADISTRIBUTE) are coded.2. Backup SD stacks..3. All target stacks.

Copyright IBM 2005C

Updated Displays for Unlimited PORTS in SD V1R5 MVS TCP/IP NETSTAT CS V1R5 TCPIP Name: TCPCS 15:37:20Dynamic VIPA Information: VIPA Distribute: IP Address Port XCF Address SysPt TimAff ---------- ---- ----------- ----- ------ ------ 201.2.10.10 n/a 201.1.10.60 No 201.2.10.11 00245 201.1.10.85 No No 201.2.10.11 00245 201.1.10.80 No 20 201.2.10.11 00246 201.1.10.15 No 100

MVS TCP/IP NETSTAT CS V1R5 TCPIP Name: TCPCS 15:37:20Dynamic VIPA Distribution Port Table: Dest IPaddr DPort DestXCF Addr Rdy TotalConn WLM Flg ----------- ----- ------------ --- --------- --- --- 197.11.200.1 00080 199.11.87.104 001 0000410485 01 197.11.200.1 00080 199.11.87.106 001 0000393807 04 197.20.100.102 00500 201.2.10.202 001 0000000010 01 D

"n/a"

The Netstat VIPADCFG/-F report updated to display "n/a" for port number in the VIPADISTRIBUTE The Netstat VDPT/-O report updated to include a "Flg" of "D" for dynamic

"D"


1. The Netstat VIPADCFG/-F report was updated to display "n/a" for port number in the VIPADISTRIBUTE section when no PORT parameter has been specified on the VIPADISTRIBUTE profile statement.

2. The Netstat VDPT/-O report will have to handle an effectively unlimited number of ports for a particular distributed DVIPA, but with IPADDR/-I and PORT/-P filter supports, this should not be a problem. An additional 'Flg' field on each VDPT entry, indicating 'D' for port was created dynamically.

Copyright IBM 2005C

Sysplex Distribution Definitions at SD Stack V1R5

IPCONFIG SYSPLEXROUTING DATAGRAMFWD ... DYNAMICXCF 192.168.5.170 255.255.255.0 1

VIPADYNAMIC VIPADEFINE 255.255.240.0 10.182.6.21 VIPADISTRIBUTE DEFINE DISTM BASEWLM 10.182.6.21 PORT 23 DESTIP ALL ........ ENDVIPADYNAMIC

NM2ATCP NM2BTCP NM1ATCP NM1BTCP

XCF

10.182.6.21

SD

[10.182.6.21] [10.182.6.21] [10.182.6.21]

V1R5

192.168.5.170 192.168.5.171 192.168.5.168 192.168.5.169

V1R4 - PQ76866


1. Sysplex Distributor requires a Dynamic VIPA defined with the VIPADEFINE statement inside the VIPADYNAMIC Block of the TCP/IP Profile. It also requires a VIPADISTRIBUTE statement at the Sysplex Distributing Node. In our network the XCF addresses that are represented in the "DESTIP" parameter are 192.168.5.168 - 171.

2. At z/OS V1R5 it is possible to override the basic WLM distribution method by specifying RoundRobin on the "DISTMethod" parameter of the VIPADISTRIBUTE statement.1. This roundrobin distribution specifies that distribution should be even among available servers at the time the connection

request is received, via round robin distribution, or distribution using normal WLM LPAR displaceable capacity2. BASEWLM (default) preserves current operation using WLM LPAR displaceable capacity - If WLM not used the distribution is

random (roughly even) and not round robin. 3. ROUNDROBIN causes distribution of future connection requests to be round robin - Different stack chosen for each

connection in order. 4. The parameter may be changed via VARY OBEY command.

1. It was made available via PTF on V1R4 - PQ768663.4.

Copyright IBM 2005C

Initial Activation of DRVIPA by VIPABACKUP V1R5

V1R5 allows a VIPABACKUP stack which comes up before the VIPADEFINE stack to own the DVIPA until the VIPADEFINE stack comes up

The original design for Dynamic VIPAs envisioned that the stack with the VIPADEFINE would be activated first, but this is not always the case. The VIPADEFINE profile statement contains definitions (MOVEABLE state and subnet mask) needed to activate the DVIPA. Currently, these are not present on the VIPABACKUP statement.

VIPADEFINE V1

VIPABACKUP 1, V1

SYSA SYSB

Sysplex Start sequence: 12 When should

V1 become active for the first time in the sysplex? When SYSB or when SYSA is started?

Answer: With V1R5 it doesn't matter since VIPABackup can act like VIPADEFINE until the

VIPADEFINE is done.


1. Add MOVEABLE, SERVICEMGR, and the subnet mask as optional parameters on the VIPABACKUP statement2. The presence of MOVEABLE and a subnet mask designates that the DVIPA may be activated on this stack if it is not active

elsewhere in the Sysplex3. MOVEABLE, a subnet mask, and optionally SERVICEMGR, provide the required information for activation of the DVIPA.4. If the DVIPA is already active elsewhere in the sysplex, these parameters are ignored and the DVIPA is configured as a backup

DVIPA on this stack.

Copyright IBM 2005C

Outbound connections can use same IP addresses as subsequent inbound connections to same appl without application changeEasier for accounting and managementEasier for security (firewall admin)Permits source IP address selection controls for applications even when application doesn'tprovide for this programmatically

Introducing Job-specific Source IP Addressing

A new TCPIP.Profile statement BEGINSRCIP/ENDSRCIP allows the selection of a source IP address for outboundTCP connections by job name

Job-Specific Source IP Addressing in V1R6 Need to control source IP address used for outbound connections

COUPLINGFACILITY

Appl1 issues connect()

Appl2 issues connect()

Vipadefine 9.85.112.1Vipadefine 5554:2233::443

BEGINSRCIP Appl1 9.85.112.1 Appl2 5554:2233::443 User1* 888:555::222 ===> Wildcards allowed! ENDSRCIP

Support targeted to jobs started as started procedures from console


1. Important Considerations when using Job-specific Source IP Addressing:1. Can be any IP Address- real IP Address of phsical interface, static VIPA, or dynamic VIPA (DVIPA)2. Can be an interface name for IPv6

1. If interface has multiple ip addresses, source address selection is based upon the destination of theconnect() (consistent algorithm used for any source address selection)

2. In the case of VIPARANGE for IPv6 (can have multiple ip addresses associated with interface name)-this is not recommended since the address selected will be unpredictable unless the range only allows a single address

3. JSSI will not override a specific bind(), but it is effective for those that do a bind() to inaddr_any4. This IP Address should not be a DVIPA that's defined to move (ie for backup/recovery)5. JSSI is not related to or dependent upon SOURCEVIPA or TCPSTACKSOURCEVIPA6. If the application's jobname that is connecting outbound is defined in the BEGINSRCIP block, only that IP address will be

used as the source (no defaulting)7. If the IP Address associated with the jobname is not active at connect() time, the connect() will fail8. If IP Address is a distributed DVIPA, requires SYSPLEXPORTS

Copyright IBM 2005C

While You Were Sleeping: Enterprise Extender News


Copyright IBM 2005C

Prior to V1R4, the AUTOGEN parameter on an XCA Major Node GROUP statement allows automatic generation of up to 4096 lines and PUs.In z/OS V1R4 the maximum value for the AUTOGEN operand's num_stmts parameter on an XCA Major Node GROUP statement is being increased to 65,536 (64K)

This higher maximum applies to Enterprise Extender groups only. (MEDIUM=HPRIP must be coded on the PORT statement.)If coding more than 4096 on Autogen, the "seed" value may not exceed four characters in length (with lower values may be five characters)The following automatically generates 4098 lines named LNEE0000, LNEE0001, etc. and 4098 PUs beginning with PUEE0000.XCAEE VBUILD TYPE=XCA XCAEEP PORT MEDIUM=HPRIP XCAEEG GROUP DIAL=YES,ANSWER=ON,AUTOGEN=(4098,LNEE,PUEE)

Storage is required for additional linesDefine only as many as you need (plus some room for growth)

AUTOGEN in XCA Major Nodes V1R4


1. z/OS V1R4 CS increases the maximum value for the num_stmts parameter for the AUTOGEN operand on the XCA major node from 4096 (4K) to 65 536 (64K).

2. This is useful because increasing the number of line and PU statements that may be generated for each GROUP in an XCA major node will allow you to use AUTOGEN to eliminate the definitional requirement of defining multiple GROUPs or predefining all line and PU names when more than 4096 EE connection partners exist.

3. The previous AUTOGEN limit of 4096 pertains to PORT definitions which do NOT have MEDIUM=HPRIP coded.4. For AUTOGEN specifications of 4097 or higher, the maximum number of line and PU seed characters permitted will be four. Up

to five seed characters will still be permitted for AUTOGEN specifications of 4096 or less. For specifications of 4097 or higher, the CUA will not be included in the generated names.

5. Be aware that each LINE/PU requires VTAM storage, so it is recommended that AUTOGEN be set to a value somewhat approximating the current requirements, rather than a significantly higher number. A good estimate to use for storage requirements is 900 or 1000 bytes per LINE/PU.

Copyright IBM 2005C

Pre-V1R4 V1R4Autogen Maximum for EE XCA

4096 65535

Length of Naming Seed Values

LT/EQ 5 If Autogen Max LT/EQ 4096, Seed LT/EQ 5

If Autogen Max GT/EQ 4097, Seed LT/EQ 4 Autogen Maximum for Other XCA

4096 4096

Length of Naming Seed Values

LT/EQ 5 LT/EQ 5

Naming Seeds

XCAEE VBUILD TYPE=XCA XCAEEP PORT MEDIUM=XXX XCAEEG GROUP DIAL=YES,ANSWER=ON,AUTOGEN=(3000,LNEEZ,PUEEZ)

XCAEE VBUILD TYPE=XCA XCAEEP PORT MEDIUM=HPRIP XCAEEG GROUP DIAL=YES,ANSWER=ON,AUTOGEN=(8192,LNEE,PUEE)

EE XCA

Non-EE XCA

1-4 chars

> 4096 and <= 64K

Increased AUTOGEN for EE XCA V1R4


1. The previous AUTOGEN limit of 4096 pertains to PORT definitions which do NOT have MEDIUM=HPRIP coded.2. On the PORT definition used for Enterprise Extender (MEDIUM=HPRIP) the maximum value that may be specified for

AUTOGEN is 65,536.3. For AUTOGEN specifications of 4097 or higher, the maximum number of line and PU seed characters permitted will be four. Up

to five seed characters will still be permitted for AUTOGEN specifications of 4096 or less.

Copyright IBM 2005C

With V1R4, TGPs or link characteristics parameters may be coded on the GROUP statement

This allows the Global Connection network to have different link characteristics than the local connection networkPrior to this enhancement, allowed only on PORT statement - with two VRNs only one could have customer specific values -- the other uses the default value of 4M for capacity

XCA Major Node at CSS1 (z/OS V1R4):

XCAEETST VBUILD TYPE=XCA PORTEE PORT MEDIUM=HPRIP GRPEEP GROUP DIAL=YES,AUTOGEN=(10,E,X), C CALL=INOUT,ISTATUS=ACTIVE,DYNPU=YES GRPEEG GROUP DIAL=YES,AUTOGEN=(10,G,V),VNTYPE=GLOBAL, C CALL=INOUT,ISTATUS=ACTIVE,TGP=ESCON GRPEEL GROUP DIAL=YES,AUTOGEN=(10,L,R),CAPACITY=1M,UPARM1=52, C CALL=INOUT,ISTATUS=ACTIVE,VNNAME=CSSNET.HPRIP

XCA Major Node Coding - V1R4


This visual shows the coding of an XCA Major Node for Enterprise Extender at the z/OS V1R4 level.With this level, TGP= or other link parameters such as CAPACITY=, COSTTIME=, etc. may be coded on the PORT or GROUP statement for virtual routing nodes.

Here the Global Connection Network (VNTYPE=GLOBAL, defaulting the VNNAME to IP.IP) is coded with a Transmission Group Profile of ESCON on the GROUP statement.The local connection network, CSSNET.HPRIP is coded with two link parameters, CAPACITY= and UPARM1=.

Copyright IBM 2005C

z/OS V1R4 uses high order element addresses for EE Lines/PUs

ENHADDR=YES Start Option must be specified

"High Order" means from the >64K element address pool -- EE Lines/PUs may obtain addresses up to 16MIST1620I replaced with IST1863I/IST1864I in response to D NET,VTAMSTOR

Enhanced Addressing for EE Lines/PUs V1R4


1. z/OS V1R4 Communications Server enhances the addressing for Enterprise Extender's (EE's) logical lines and physical units (PUs) by making their assigned element addresses into extended element addresses. This is reflected in the displays seen with messages IST1863I and IST1864I in response to a DISPLAY VTAMSTOR, RESOURCE or a DISPLAY VTAMSTOR,NETADDR command.

2. The enhancement alleviates the constraint of network addresses for EE by expanding the network address allocations above and beyond the 64K line, up to 16M.

Copyright IBM 2005C

V1R5 will allow the specification of multiple local and/or multiple global EE connection networks.

In the diagram above, Node B defines 2 local VRNs (both IPv4) and 2 global VRNs (one IPv4 and one IPv6)

EE will allow multiple (static) VIPAs, defined on a GROUP basis in the EE XCA major node.

LVRNA

GVRNB6

GVRNB4

LVRNB

Node A

Node B

Node C

IPv4Network

IPv6Network

IPv4Network

IPv4Network

Multiple VRN/VIPA Support in V1R5


Copyright IBM 2005C

********************************************************************** * * NAME: XCAIP (XCA Major Node for Enterprise Extender) * ********************************************************************** XCAIP1A VBUILD TYPE=XCA PORTIP PORT MEDIUM=HPRIP,SAPADDR=4,TIMER=254 * GPIP1 GROUP DIAL=YES,ANSWER=ON,ISTATUS=INACTIVE,CALL=INOUT, X IPADDR=1.1.1.1,VNTYPE=GLOBAL,VNNAME=IP.NETA LN11 LINE PU11 PU * GPIP3 GROUP DIAL=YES,ANSWER=ON,ISTATUS=INACTIVE,CALL=INOUT, X IPADDR=2.2.2.2,VNTPE=GLOBAL,VNNAME=IP.NETB LN31 LINE PU31 PU * GPIP5 GROUP DIAL=YES,ANSWER=ON,ISTATUS=INACTIVE,CALL=INOUT, X IPADDR=3.3.3.3 LN51 LINE PU51 PU

Sample for Multiple Static EE VIPAs V1R5


Copyright IBM 2005C

End of Topic


Documents

Useful z/OS Communications Server 'Magic Tricks' …FILE/W21_EXPO2005_SLEEP_MAGIC.pdfIBM GLOBAL SERVICES W21 Gwen Dente Useful z/OS Communications Server 'Magic Tricks' You May Have