Robert
You may be right and CINET is required.
In any case, whether it is of not may be moot for the reason that both
implementations of an IP node are working together so "If it ain't broke,
don't fix it!"
In order to be sure that CINET really is required I would need to be sure of
two things:
1. The Interlink product documents would need to say something about it.
2. There would need to be something about CINET and the BPXPRMxx statements
being an "open" interface. Actually, the statements *look* "open".
In other words, I would need something which gave me confidence that the
Interlink product could use CINET and thereby that something would indicate
that "run multiple z/OS Communications Server TCP/IP stacks concurrently" is
a bit like the many references to RACF which should have said "a SAF
product". Thus, while not actually *welcome*, Tom, Dick and Harry are
allowed to be members of the club as well as the founder.
It may be that the key point you make is in the sentence "I have made
several products work with Interlink when the doc only mentioned IBM
TCP/IP." In other words the purpose of CINET is to direct which IP address
space services the various application programming interfaces (APIs).
I did once put together a little document explaining how to run two
instances of the IP component of Communications Server (CS IP) in the same
system based on a little bit of testing which, of course, relied on setting
up CINET in BPXPRMxx. I have to confess violating one of my rules which is
to *understand what I am doing*. Now that I look into it a little more in
the "UNIX System Services" bookshelf I can see this is a rather large topic
and I think I've seen enough to appreciate that my point 2 above is
satisfied, namely that there is an "open" interface.
And, having looked into it a little more, I'm not sure it's only the API.
At this point I wondered how you had managed to discover that you should use
the name T010PFSA in place of EZBPFINI which is described at one point in
the UNIX System Services manual in the following terms: "The entry point for
INET is usually EZBPFINI, for z/OS Communications Services (TCP/IP
Services)." Since the name EZBPFINI is used only in the context of the
BPXPRMxx member as far as I can see from (a) searching the Configuration
Guide and the Configuration Reference manuals and (b), to be quite sure,
Googling for EZBPFINI, you must have discovered T010PFSA in an Interlink
manual since the IBM equivalent EZBPFINI isn't used in any other context.
Thus point 1 above is satisfied - somewhat indirectly.
Then while checking on EZBPFINI in the UNIX System Services Planning manual,
I found the following:
<quote>
The entrypoints for the SUBFILESYSTYPE statements are usually EZBPFINI for
several instances of the z/OS Communications Services (TCP/IP Services) or
the entry point for a conforming TCP/IP stack that is provided by a vendor.
</quote>
There were "revision bars" so I checked back from the current V1R8 manual.
Well, I have to say "well done" to the authors in this case since they have
spotted a change required by the removal in V1R8 of the AnyNet Sockets over
SNA function - of very blessed memory.
This, in a way, helps to reveal what the BPXPRMxx statements are all about.
When AnyNet Sockets over SNA first appeared, the way you directed your
sockets program to use the AnyNet function was to linkage edit the program
with the AnyNet sockets library rather than the then TCP/IP for MVS sockets
library. The PC OS/2 implementation was much more flexible in that whether
to use the IP network or the SNA network for sockets programs was dynamic.
I recall having a bit of trouble re-linkage editing the NFS program in order
to be able to use AnyNet Sockets over SNA. I see the product is still
proudly independent of CS IP as it was, as a component of DFDSS, of TCP/IP
for MVS at the time.
I wonder precisely what the word "conforming" means. I guess I'm just going
to have to read up on all of this ...
Incidentally, a friend who calls me from time to time for technical help and
who is at the "coal face" - rather than myself who is currently "resting" -
has a customer who is faced with the same conversion/migration. His major
concern - for now - is whether Interlink has some SMTP functions which CS IP
does not have - a query I may have to put to the list - probably IBMTCP-L
for better focus - in rather general terms. I asked him about the
possibility of running both CS IP and Interlink together and whether
Interlink participated in CINET. He also thought it may not but I think he
hadn't actually considered that yet - so thanks for the help with that
issue.
Well, having been so successful Googling for EZBPFINI and raising the matter
of whence T010PFSA originated, I decided that a Google for T010PFSA was in
order. This yielded 4/7 hits, one of which was *very* useful. In fact the
following URL, derived from the first of the hits, provides access to all
the TCPAccess (Interlink) manuals as far as I can see:
http://www.workers.com.br/manuais/
It's odd that one needs to go all the way to Brazil in order to find them!
Anyhow, the participation of Interlink in CINET is well confirmed.
Incidentally I guess you spotted this line, taken from the second hit - in
red:
<quote>
CAUTION ! You should be aware that there are performance considerations when
using common Inet support and it is not recommended.
</quote>
Maybe this is some FUD in an effort to try to persuade you not to migrate to
CS IP!
Perhaps a last "incidentally", in order to test your careful migration,
don't you need to be able to direct the socket calls of an application to
one of the IP node implementations or another? I think I understand that, in
the absence of such direction, a *default* implementation is selected which
is whichever system happens to be active first overridden by, if that system
is active, the system identified with the DEFAULT parameter in the
SUBFILESYSTYPE statement.
Well, not the last! While trying to check on what exactly the effect of the
DEFAULT parameter was, I came upon the following statement in Table 3, File
System Types, in 3.8.1.1 FILESYSTYPE in z/OS UNIX System Services Planning,
GA22-7800-10:
<quote>
If you want to use CINET, you must be using z/OS Communications Server
(TCP/IP Services).
</quote>
I plead "not guilty" on account the balance of my mind was disturbed by IBM
manuals!
And, if the manual is to be trusted, I correctly described the significance
of the DEFAULT parameter.
Chris Mason
----- Original Message -----
From: "Johnston, Robert E" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Wednesday, September 12, 2007 8:38 PM
Subject: Re: CA to IBM TCP Conversion
Chris,
Thanks for the information and document. I already had some of your
recommendations in place and I am still reviewing everything. There is one
thing that I would like to ask you about.
You quoted the IP Guide and said:
<quote>
Common INET physical file system (CINET PFS)
If you wish to run multiple z/OS Communications Server TCP/IP stacks
concurrently, you must use the Common INET (CINET) configuration. In this
configuration, up to a maximum of eight TCP/IP stacks can be active at any
time.
</quote>
You may be sure that IBM means just the IBM-supplied software for creating
the appearance of an IP node and absolutely not software from any other
Tom, Dick or Harry!
Why don't you think I need a CINET environment if one of the stacks is
Interlink? It's true that the guide says z/OS CS but since I have used
Interlink for so long I tend to ignore when manuals say IBM TCP/IP - an IP
stack is an IP stack, right? (I know all stacks aren't exactly created
equal,
but...) I have made several products work with Interlink when the doc only
mentioned IBM TCP/IP.
The OMVS proc has a steplib for Interlink and the BPX parm entry looks like:
SUBFILESYSTYPE NAME(TCPIPCA) /* Name of file system */
TYPE(CINET) /* Type matching Cinet's TYPE */
ENTRYPOINT(T010PFSA) /* Entry point of load module */
PARM('SYSID(ACSS)') /* SSID of CA TCPAccess stack */
When OMVS comes up, these msgs are displayed:
T01OE101I TCP/IP PFS Name:TCPIPCA Initialization Started
T01OE104I TCP/IP PFS Name:TCPIPCA Subtask:00AE76F8 Started
IEF196I T01OE104I TCP/IP PFS Name:TCPIPCA Subtask:00AE76F8 Started
T01OE102I TCP/IP PFS Name:TCPIPCA Using TCPaccess Subsystem Name:ACSS
T01OE115I TCP/IP PFS Name:TCPIPCA FILESYSTYPE PARM:
T01OE116I SYSID(ACSS)
T01OE103I TCP/IP PFS Name:TCPIPCA Initialization Complete
This may be a moot point anyway if everything checks out ok with IBM and I
can just drop CA. Whenever I get a chance I will try taking out the CA stuff
and see what happens to it with no OMVS. For now I am trying to not run the
CA stack at all. Also, you are correct in one of your posts that I am not
doing anything real complicated - everything is in 1 LPAR, no plex, etc.
Thanks for the help...
Robert
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
