[top posting]
When I made my post I forgot to mention the one qualm I had
right away: 'PL/1' instead of 'PL/I'. I quickly sent off an
email to the redbooks folks. You might do the same with your
comments on OSA.
On 10/10/2011 9:25 AM, Chris Mason wrote:
Steve
Thanks for the reference. I hope you don't mind the subject change although I guess it's
a topic which will interest all subscribers and "Redbook" as a subject is
designed to intrigue all!
Probably it's absolutely superb throughout and, of course, I will need much
more time to become impressed.
-
There is one[1] minor snag in the "OSA-Express" section in the "4.5.3 System z
network connectivity" section.
Referring to xxxROUTER - NONROUTER, PRIROUTER and SECROUTER - indicates that the authors are not on
the crest of the wave regarding the way the OSA features of today should be being employed.
Although it is lamentably presented in the regular manuals, legacy mode of operation of OSA
features should be replaced by "virtual MAC" mode of operation as soon as the "ducks
are aligned"[2] which permit this mode of operation.
With the "virtual MAC" mode of operation, preferably using the QDIO IPv4
INTERFACE statement rather than the DEVICE etc. statements[3], the VMAC parameter should
be included in order to activate this preferred mode of operation in the OSA feature
logic. The xxxROUTER parameter is replaced by the ROUTExxx subparameter of the VMAC
parameter - ROUTEALL in order to implement the *spirit* of PRIROUTER and SECROUTER or
ROUTELCL precisely for NONROUTER.
Part of the lamentable failure in the regular manual - or indeed in any source of which I
know[4] - properly to describe the "virtual MAC" mode of operation is the total
insensitivity to the problem faced by each and every systems programmer wanting to update
to a capability in the system newly made available which can involve multiple systems
sharing a resource, in this case, an OSA feature.
How do I migrate from the legacy mode of operation to the "virtual MAC" mode of operation in n
systems sharing the OSA feature when my "change control" group, in obeisance to the members of
which I regularly wear out my knees (also the "SAF/RACF" group!), when I know I can change only one
system each Sunday?
Actually, you just have to understand the "virtual MAC" mode of operation in
contrast to the legacy mode of operation in order to see that there should be no concerns
mixing the two in respect of one OSA feature port. Is this explained in the regular
manuals? It is not! Has this been demonstrated in a redbook? Not to my knowledge!
What a shame that this brand new shiny redbook is shown to have paint flaking
off already![5]
-
[1] Possibly only one but I won't know until I've read the rest.
[2] From z/OS V1R8 Communications Server New Function Summary, a section within
"2.2.21 OSA-Express virtual MAC":
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1f220/2.2.21?SHELF=F1A1BK81.bks&DT=20060712163120
<quote>
2.2.21.2 Dependencies
To enable the virtual MAC support, you must be running at a minimum with an IBM
System z9 EC or z9 BC and OSA-Express2 in QDIO mode (CHPID type OSD). Refer to
the OSA-Express2 Preventive Service Planning (PSP) bucket for further
information.
</quote>
[3] The QDIO IPv4 INTERFACE statement appeared in V1R10.
[4] Say OSA-Express Implementation Guide which has a lovely whole chapter on the
"virtual MAC" mode of operation and a worked example of two systems sharing an
OSA feature port. However it seems not to have occurred to the authors to deal with the
practical matter of actually being allowed to introduce the function!
http://www.redbooks.ibm.com/abstracts/sg245948.html
[5] It is the following text in the redbook from the indicated section which is
already out of date:
<quote>
OSA-Express also provides primary (PRIRouter) and secondary (SECRouter) router
support. This function enables a single TCP/IP stack, on a per-protocol (IPv4
and IPv6) basis, to register and act as a router stack based on a given
OSA-Express port. Secondary routers can also be configured to provide for
conditions in which the primary router becomes unavailable and the secondary
router takes over for the primary router.
</quote>
One possible replacement text could be as follows:
<suggestion>
When using the current "virtual MAC" capability of the OSA-Express (by specifying the
VMAC parameter of the QDIO INTERFACE statement for both IPv4 (preferred) and IPv6), it is possible
to allow an IP node running of Communications Server IP logic to be only a destination node
(ROUTELCL) or also to be a routing node (ROUTEALL). This is in contrast to the limited design
choices imposed prior to the availability of the "virtual MAC" capability.
</suggestion>
-
Chris Mason
On Mon, 10 Oct 2011 07:36:41 -0600, Steve Comstock<st...@trainersfriend.com>
wrote:
The weekly redbooks announcement includes this book:
Considerations for Transitioning Highly Available Applications to System z
http://www.redbooks.ibm.com/redbooks/pdfs/sg247824.pdf
which, on a quick perusal, seems to be really good. Recommended reading,
I think.
--
Kind regards,
-Steve Comstock
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
