Re: CA to IBM TCP Conversion
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: IBM-MAIN@BAMA.UA.EDU
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
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
Confidentiality Notice: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
--
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
Re: CA to IBM TCP conversion
the gethostbyname() call prior to attempting to initiate a TCP connection, should try each of the IP addresses in the list in turn before giving up on the connection. Chris Mason - Original Message - From: Johnston, Robert E [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, August 22, 2007 9:51 PM Subject: Re: CA to IBM TCP conversion First off let me thank the previously un-thanked Bob and Shelia for their responses... I have both the CA and IBM stacks running concurrently now. They use different OSA's, different IP addresses, and different host names. I am pausing to apply maint to the CA stack before continuing down my path. I still wonder about some things and would appreciate any discussion. Can you configure 2 tcp stacks to use the same IP address and/or OSA? All traffic comes in one way and gets sorted out from there. I read some about VIPA but it didn't all take the first time. Can you/should you configure one host name that has multiple IP addresses assigned to it? For my purposes (testing apps to convert from CA to IBM), is my system configured ok w/ 2 IP's and host names? Or would it be better another way? These questions may not make sense. I am having trouble understanding all the relationships between host name(s), IP address(es), and the rest of the IP world. Thanks, 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
Re: CA to IBM TCP Conversion
Sheila You should check you understanding of names and IP addresses. The IP address is the entity that really matters, each one associated with one interface - even if some interfaces are virtual. There is an official host name but its usage is whatever you like to make of it - in conjunction with the name server system if used. If a name is to be associated with a node and the node has multiple interfaces, necessarily the name, indirectly, is associated with the multiple IP addresses, each one of which is primarily associated with an interface. You've probably noticed we've been flogging the OSA/VIPA topic to death recently! I'm not sure Robert is quite ready for dynamic VIPAS just yet! Maybe after he has performed his conversion. Also we need to assume he has multiple LPARs ready to benefit from the wandering dynamic VIPA. I've a suspicion that when he talked about sharing an OSA between two programs behaving as IP nodes, both programs were running in the same LPAR. Because it's really a different topic, I am responding to your gethostid() point in a separate thread. Chris Mason - Original Message - From: Sheila Weissborn [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, September 05, 2007 7:30 PM Subject: Re: CA to IBM TCP Conversion Robert, I noticed you had posted some additional questions. I hope the following is helpful. Can you configure 2 tcp stacks to use the same IP address and/or OSA? An OSA can be shared by multiple TCPIP stacks. An IP address can be moved between TCPIP stacks, but can only be assigned to one stack at a time. There is a redbook that has some good information on different possible configurations - SG24-5948-04 OSA-Express Implementation Guide. Can you/should you configure one host name that has multiple IP addresses assigned to it? A host name should be associated with only one IP address. However, one can have multiple IP address/host name pairs associated with one TCPIP stack. The decison on using multiple IP addresses would depend on what requirements there are for separating traffic and moving applications. For instance, VIPA separates the IP address from the hardware. Two OSAs each with their own IP address could provide redundant paths to the same VIPA on a single TCPIP stack. There are various scenarios for moving IP addresses to alternate systems with dynamic VIPA and DVIPA. A good resource is the redbook SG24-7341-00 Communications Server for z/OS V1R8 TCP/IP Implementation Volume 3: High Availability, Scalability and Performance. The OSA-Express Implementation Guide has an Appendix on ARP takeover which I found helpful. ARP takeover is what we implemented here. The configuration used is based on the hardware configuration and the business requirements at your site. ... Sheila Weissborn Ohio Casualty Insurance -- 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
Gethostid() and DB2 (was CA to IBM TCP conversion)
to address mapping, strictly address to name mapping in this case - in the shape of the file identified by your DEFAULTIPNODES statement under the influence of a COMMONSEARCH statement - was set up appropriately. Chris Mason - Original Message - From: Sheila Weissborn [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, September 05, 2007 7:30 PM Subject: Re: CA to IBM TCP Conversion ... For IPV4 links, there is a relationship between links, IP addresses and host names that you will need to know if you are using DB2 or anything else that uses the gethostid function. This may not apply to your environment, but I mention it here because it is hard to track this down in the manuals. In the TCPIP profile there is a parameter PRIMARYINTERFACE which defaults to the first link in the HOME statement. The IP address assigned to this link in the HOME statement is used to get the host name. There is discussion of local host name files in the IP Configuration Guide. We use a sequential file that is referenced by DEFAULTIPNODES in the resolver configuration file. If this is not set up correctly, the resulting error message in DB2 states that gethostid failed. ... Sheila Weissborn Ohio Casualty Insurance -- 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
Re: CA to IBM TCP Conversion
Robert I thought I'd dig further into this IUCV point and I found a reference in the IP Configuration Guide. It appears that IUCV, VMCF and TNF stuff is still available, you just don't necessarily need it. It would appear to have become an *optional* bit of preparation for the use of the Communications Server (CS) IP component from being *required* as it was when I used to teach TCP/IP for MVS. It is described in the CS IP Configuration Guide under Chapter 2. Configuration overview, Required steps before starting TCP/IP as Step 3: Configure VMCF and TNF on page 111 of the z/OS 1.8 manual. It appears that the section headers are logically incorrect since, as far as I can tell, it really is an *optional* step and depends on whether or not the Pascal API is used or not. The clearest indication that this step really is optional is ... therefore, some installations will require setting up VMCF and TNF. at the end of the first paragraph. I then found Dana Mitchell's post where he/she said something of the same as above. Chris Mason - Original Message - From: Johnston, Robert E [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, September 05, 2007 11:44 PM Subject: Re: CA to IBM TCP Conversion ... In Dana Mitchell's post: At the time there were some functions that were supported on one stack but not the other, that caused us problems (IUCV perhaps?) I read that IBM TCP/IP versions later than 3.2 do not support IUCV. I have an old print product that uses IUCV to connect to TSO for printer administration functions. The actual prints work ok (port 515) but I haven't been able to make the Admin panels work. I'm just out of luck on that one, right? Thanks, 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
Re: CA to IBM TCP Conversion
Sheila According to my reading of the Communications Server IP Configuration Reference, the TCPCONFIG default for RESTRICTLOWPORTS or UNRESTRICTLOWPORTS is the latter - which is as expected since this was the behaviour before this pair of parameters was introduced. It is, in general, good practice to specify RESTRICTLOWPORTS since this ensures that only by use of the PORT statement (or PORTRANGE I guess but that's unlikely) can you authorise use of a particular port in the 1 to 1023 range - under TCP - and you tie it to a particular job name. It used to be recommended that you retain all the PORT statement elements as specified in the provided file since that way nobody could inadvertently set up a program which used one of those ports, get away with it, maybe get it established as a vital feature of the production environment and then you discover later that you need it for the intended service function - all a bit far-fetched anyhow! In case this highly unlikely scenario seemed possible, you can now specify RESTRICTLOWPORTS, and ensure that your PORT statement specifies only the services you actually want to run today. This way you can get rid of all the unnecessary and unhelpful garbage in the PORT statement list - and you can see the trees in the wood about which you actually care! Exactly the same - substituting UDP for TCP - can be said for the same pair of parameters on the UDPCONFIG statement. It is a convention for TCP and UDP that ports 1 to 1023 are assigned to well-known server functions such as you will find listed in the equivalent of what on my PC is the C\WINDOWS\system32\drivers\etc\services file. Chris Mason - Original Message - From: Sheila Weissborn [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Thursday, September 06, 2007 6:35 PM Subject: Re: CA to IBM TCP Conversion ... Speaking of port usage, here is another tip. In the TCPIP profile, TCPCONFIG and UDPCONFIG default to restricting usage of ports 1 through 1023. So a port must be reserved for any application using anything in this range or the profile needs to have UNRESTRICTLOWPORTS coded on TCPCONFIG and UDPCONFIG. Normally this range is used by standard applications like ftp which are included in the sample profile. Sheila Weissborn Ohio Casualty Insurance -- 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
Re: CA to IBM TCP Conversion
Robert I've send you a file which summarises the search order issue. You'll see from the end of the document that not everything was clear but this is par for the course in regard to CS IP documentation. - I have a tentative recommendation which goes as follows: - Set up a resolver procedure. You necessarily have a resolver procedure running and, if you haven't created your own, it uses a well-hidden procedure called not RESOLVER, as you might be sure it must be, but IEESYSAS, a general purpose procedure which can be used whenever a DD-statement need not be added to the EXEC statement. - Be sure to specify COMMONSEARCH in your resolver, SETUP, file. If you are using a local file for name to address translation, you can use the sensible format as defined in the CS IP Configuration Guide. section 1.5.4.4, Creating ETC.IPNODES and /etc/ipnodes. - I am assuming you don't want to be too complicated for the moment so define a client[1] data set using the GLOBALTCPIPDATA statement in your resolver, SETUP, file. Note that, when you use the GLOBALTCPIPDATA statement, all parameters which relate to using a name server necessarily reside in the specified file. This becomes important only when you start getting clever and try to concatenate this data set with another data set. - Similarly assuming you don't want to be too complicated for the moment and that you are defining name to address relationships in a local file rather than using the name server system - and you have specified COMMONSEARCH as I suggested above, you should define the name to address data set using the GLOBALIPNODES statement in your resolver, SETUP, file. You may have noticed that Sheila mentions using the DEFAULTIPNODES statement in an earlier post. This is similar to the GLOBALIPNODES statement but comes last in the search order rather than first. - That deals with the Base resolver configuration file and the Local host table. In order to keep the remaining files as simple as possible, given that you are unlikely to need to change the supplied files, simply create TCPIP.ETC.PROTO and TCPIP.ETC.SERVICES files so that they can be dynamically allocated by file name - one of the features of Communications Server (CS) IP which reveals its VM heritage. You can probably simply use the internal version of the translate table. Chris Mason [1] Client here refers to the relationship of CS IP-related address spaces, the client address spaces, which rely on the main CS IP address space, the server address space. The file is otherwise referred to as the TCPIP.DATA file which again reflects the VM heritage. - Original Message - From: Johnston, Robert E [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, September 07, 2007 11:24 PM Subject: Re: CA to IBM TCP Conversion ... All these APIs and search orders and such make my head spin! -- 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
Re: CA to IBM TCP Conversion
Chris Mason wrote: Robert I thought I'd dig further into this IUCV point and I found a reference in the IP Configuration Guide. It appears that IUCV, VMCF and TNF stuff is still available, you just don't necessarily need it. It would appear to have become an *optional* bit of preparation for the use of the Communications Server (CS) IP component from being *required* as it was when I used to teach TCP/IP for MVS. It is described in the CS IP Configuration Guide under Chapter 2. Configuration overview, Required steps before starting TCP/IP as Step 3: Configure VMCF and TNF on page 111 of the z/OS 1.8 manual. It appears that the section headers are logically incorrect since, as far as I can tell, it really is an *optional* step and depends on whether or not the Pascal API is used or not. The clearest indication that this step really is optional is ... therefore, some installations will require setting up VMCF and TNF. at the end of the first paragraph. I then found Dana Mitchell's post where he/she said something of the same as above. Chris Mason the original tcp/ip implementation was done in vs/pascal on vm370 (20 yrs ago) ... but there were some number of implementation bottlenecks ... such that it got about 44kbyte/sec aggregate thruput consuming a 3090 processor. i then did rfc1044 support for the product and in some tuning tests at cray research (between 4341 clone and a cray machine) was getting 4341 channel media speed thruput using only a modest amount of the 4341 clone. http://www.garlic.com/~lynn/subnetwork.html#1044 for some topic drift, recent post mentioning vs/pascal http://www.garlic.com/~lynn/2007o.html#61 (Newbie question)How does the modern high-end processor been designed? which is slightly related to topic in this newsgroup since the los gatos vlsi tools group was responsible for the 370 pascal implementation as well as the LSM http://www.garlic.com/~lynn/2007o.html#67 1401 simulator for OS/360 somewhat drifting back to the topic, a port of the implementation was then done for mvs ... by doing a (vm370) vmcf/iucv emulator for mvs systems. for other background ... internally there was something called spm that was originally implemented on cp67 (precursor to vm370 that ran on 360/67s) which was a superset of the later vmcf and iucv implementations. there was somewhat internal dissension leading up to the initial vmcf release ... since spm had been around for much longer period and had so much more function. Later, iucv was released to cover some additional function (also covered by spm) that was handled by vmcf. some old email with spm reference http://www.garlic.com/~lynn/2006w.html#email750430 http://www.garlic.com/~lynn/2006k.html#email851017 misc. old posts mentioning spm: http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention http://www.garlic.com/~lynn/2004m.html#20 Whatever happened to IBM's VM PC software? http://www.garlic.com/~lynn/2005m.html#45 Digital ID http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history http://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network http://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history) http://www.garlic.com/~lynn/2006w.html#52 IBM sues maker of Intel-based Mainframe clones -- 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
Re: CA to IBM TCP Conversion
Robert, It appears that IUCV/VMCF is still supported with current IBM Communications Server (like I said it was many moons ago that I did this!) There are some configuration steps required in order to get the IUCV/VMCF subsystem started. In the CS 1.7 IP configuration guide it's in the section: 1.2.22.5 Step 3: Configure VMCF and TNF HTH Dana -- 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
Re: CA to IBM TCP Conversion
Hi Dana, Well, I got the Printer Administration panels working that use IUCV (yeah!) but I don't know what I changed to fix it (boo!). Things work with just the IBM stack running or both stacks. I can't find where I read that IBM TCP/IP versions later than 3.2 do not support IUCV or exactly what that was supposed to mean. In the 1.7 IP guide it says: Therefore, in z/OS Communications Server you must continue to configure and start the VMCF and TNF subsystems as you did in TCP/IP V3R2. However, because the VMCF/TNF subsystems are no longer used to communicate directly with the TCP/IP protocol stack in z/OS Communications Server, the amount of CPU they will consume will be significantly lower than in the TCP/IP V3R2 environment. I've got everything working that I have tried so far, but much more to go. All these APIs and search orders and such make my head spin! Thanks again to everyone and have a good weekend... Robert -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Dana Mitchell Sent: Friday, September 07, 2007 8:59 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CA to IBM TCP Conversion Robert, It appears that IUCV/VMCF is still supported with current IBM Communications Server Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- 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
Re: CA to IBM TCP Conversion
Robert, I do not know much about programming applications using tcpip APIs. By old vendor software I guess you mean no longer have any vendor support and you do not have source code. I do not have any solutions to this. Maybe someone else will have some words of wisdom. Speaking of port usage, here is another tip. In the TCPIP profile, TCPCONFIG and UDPCONFIG default to restricting usage of ports 1 through 1023. So a port must be reserved for any application using anything in this range or the profile needs to have UNRESTRICTLOWPORTS coded on TCPCONFIG and UDPCONFIG. Normally this range is used by standard applications like ftp which are included in the sample profile. Sheila Weissborn Ohio Casualty Insurance -- 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
Re: CA to IBM TCP Conversion
Sheila, Thanks again for your advice. You are correct about the print product - no longer supported and no source. We're just going to have to bite the bullet and replace it pretty soon before it breaks. It already exhibits some strange behavior occasionally... Robert Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- 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
Re: CA to IBM TCP Conversion
In [EMAIL PROTECTED], on 09/05/2007 at 12:30 PM, Sheila Weissborn [EMAIL PROTECTED] said: A host name should be associated with only one IP address. Why? It's standard for large server farms to resolve a host name to multiple addresses. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: CA to IBM TCP Conversion
Robert, I noticed you had posted some additional questions. I hope the following is helpful. Can you configure 2 tcp stacks to use the same IP address and/or OSA? An OSA can be shared by multiple TCPIP stacks. An IP address can be moved between TCPIP stacks, but can only be assigned to one stack at a time. There is a redbook that has some good information on different possible configurations - SG24-5948-04 OSA-Express Implementation Guide. Can you/should you configure one host name that has multiple IP addresses assigned to it? A host name should be associated with only one IP address. However, one can have multiple IP address/host name pairs associated with one TCPIP stack. The decison on using multiple IP addresses would depend on what requirements there are for separating traffic and moving applications. For instance, VIPA separates the IP address from the hardware. Two OSAs each with their own IP address could provide redundant paths to the same VIPA on a single TCPIP stack. There are various scenarios for moving IP addresses to alternate systems with dynamic VIPA and DVIPA. A good resource is the redbook SG24-7341-00 Communications Server for z/OS V1R8 TCP/IP Implementation Volume 3: High Availability, Scalability and Performance. The OSA-Express Implementation Guide has an Appendix on ARP takeover which I found helpful. ARP takeover is what we implemented here. The configuration used is based on the hardware configuration and the business requirements at your site. For IPV4 links, there is a relationship between links, IP addresses and host names that you will need to know if you are using DB2 or anything else that uses the gethostid function. This may not apply to your environment, but I mention it here because it is hard to track this down in the manuals. In the TCPIP profile there is a parameter PRIMARYINTERFACE which defaults to the first link in the HOME statement. The IP address assigned to this link in the HOME statement is used to get the host name. There is discussion of local host name files in the IP Configuration Guide. We use a sequential file that is referenced by DEFAULTIPNODES in the resolver configuration file. If this is not set up correctly, the resulting error message in DB2 states that gethostid failed. For my purposes (testing apps to convert from CA to IBM), is my system configured ok w/ 2 IP's and host names? Or would it be better another way? Yes, as long as there are no requirements for redundancy or movement of IP addresses. Even if redundancy will be added later, it is not needed for testing applications. One other thing - if you are using QDIO with OSA-Express2 on a z890, z990, or z9 EC or BC Processors, there is an IBM flash that advises turning off a new feature that was added by APARs to z/OS 1.6 in 2006. I do not know at what release it became part of the base code. Because of unresolved issues IBM advises disabling the feature by coding NOSEGMENTATIONOFFLOAD on the GLOBALCONFIG statement in the TCPIP profile. The title of the Washington Systems Center Flash is OSA-Express2 Segmentation Offload. Sheila Weissborn Ohio Casualty Insurance -- 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
Re: CA to IBM TCP Conversion
Hello Sheila, Thank you very much for taking the time to write. I really appreciate all the info! I will ask another question while I've got the floor... In Dana Mitchell's post: At the time there were some functions that were supported on one stack but not the other, that caused us problems (IUCV perhaps?) I read that IBM TCP/IP versions later than 3.2 do not support IUCV. I have an old print product that uses IUCV to connect to TSO for printer administration functions. The actual prints work ok (port 515) but I haven't been able to make the Admin panels work. I'm just out of luck on that one, right? Thanks, Robert Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- 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
Re: CA to IBM TCP conversion
First off let me thank the previously un-thanked Bob and Shelia for their responses... I have both the CA and IBM stacks running concurrently now. They use different OSA's, different IP addresses, and different host names. I am pausing to apply maint to the CA stack before continuing down my path. I still wonder about some things and would appreciate any discussion. Can you configure 2 tcp stacks to use the same IP address and/or OSA? All traffic comes in one way and gets sorted out from there. I read some about VIPA but it didn't all take the first time. Can you/should you configure one host name that has multiple IP addresses assigned to it? For my purposes (testing apps to convert from CA to IBM), is my system configured ok w/ 2 IP's and host names? Or would it be better another way? These questions may not make sense. I am having trouble understanding all the relationships between host name(s), IP address(es), and the rest of the IP world. Thanks, Robert Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- 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
Re: CA to IBM TCP conversion
It's been a long time, but in my previous place of employment the company acquired another company running Interlink. I recall a nightmare when it came to converting ftp because of differences in option settings for things like the handling of trailing blanks and the truncation or wrapping of data if data exceeds the record length for a fixed length record. I cannot remember if there were differences in the default settings for ftp on the two products or if the customization in the two shops introduced the differences. Since you are already familiar with the current set up, it might not be a big deal to make sure the configurations have the same option settings. Sheila Weissborn Ohio Casualty Insurance Group -- 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
Re: CA to IBM TCP conversion
Robert, We also run both stacks without problems. All our tcp apps can (after some effort) be switched between either. The biggest problem for us is the hundreds of ftp jcl whose syntax must be tweaked to go from TCPaccess to CS: ChangeMgmt, testing, migration, remote disparate platform scripts, etc, etc resulted in the decision to keep both stacks. One thing to pay attention to is your OSA config. If you're running nonQDIO (until recently a rqmt for TCPaccess), and you want to go QDIO, that will take some migration planning. Jeff -- 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
Re: CA to IBM TCP conversion
Thanks Ted, Dana, and Jeff for the info. Seems like FTP may be more of a problem than I thought. All of our socket apps are vendor supplied and some of the vendors are a bit slow to respond. I'm not even sure what socket API some things are using. I'm going to spend a few days experimenting with both stacks and then make a decision on what to do. I think I just IPLed in CINET mode for the first time, although I just have the IBM stack started at the moment. BTW, all work is being done in a test LPAR :). I don't get much direction here from mgmt. My orders amount to get everything done as soon as possible!. If we want to get 1.7 in production ASAP we probably should forget about IBM TCP for now and get on with app testing using CA. Maybe not, though. Right now I could bug y'all to death with questions. I shall return to lurker status for now. If anyone else has something to say, please do. I'll be around... Thanks, Robert Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- 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
Re: CA to IBM TCP conversion
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Johnston, Robert E Sent: Thursday, August 16, 2007 3:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CA to IBM TCP conversion I don't get much direction here from mgmt. My orders amount to get everything done as soon as possible!. If we want to get 1.7 in production ASAP we probably should forget about IBM TCP for now and get on with app testing using CA. Maybe not, though. Right now I could bug y'all to death with questions. I shall return to lurker status for now. If anyone else has something to say, please do. I'll be around Hi Robert, We did this conversion a few years ago. The FTP (batch) input DDNAME is different from CA to IBM TCPIP. The syntax in general (and the search order!) is also different. We run 2 monoplexes with dedicated OSAs in our CEC, so our configuration is pretty simple. Give a holler if you need some help. If you have a list of questions ready, send them to me off-list and I'll try to help. Bob Lester Technical Services OppenheimerFunds Centennial, CO USA Blester (at) Oppenheimerfunds (dot) com -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- 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
CA to IBM TCP conversion
Hi all... We are early in the process of moving from CA to IBM TCP/IP (still reading IP config guide - good manual, BTW). We've used CA since it was Interlink in the early 90's. I have the IBM stack running with a couple of ports and that's about all that has been done with it. I like it so far but there is so much to learn. I'm trying to get a feel about the best way to do things here. We have some special telnet LU mapping that will need to be done but the main thing I am concerned with is testing about a dozen or so socket applications. We also use FTP quite a bit. You can run both stacks at once, right? Is it worth it to try and run both stacks at once? Once an app is tested we would move it from the CA to IBM stack. (It looks kind of messy getting the apps to use the correct stack.) Would you forget about CA and just test everything with IBM? We are also on the middle of z/OS 1.4 to 1.7 conversion. TCP conversion can be included in the 1.7 upgrade or we can handle it separately. We're a small shop, 3-man system team on a z800. I guess all I am looking for right now is comments and suggestions. What say ye? Thanks, Robert Johnston UAMS - Little Rock Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- 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
Re: CA to IBM TCP conversion
You can run both stacks at once, right? Yes. And, I would convert gradually, rather than all at once. - Too busy driving to stop for gas! -- 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
Re: CA to IBM TCP conversion
Robert, I went through this exercise in the late 90's, so memory is sketchy at best. Here's some points that I remember: Conversion method depends on how comfortable you are with changing and testing the TCP apps. You may be able to switch apps from one stack to another for testing successfully one at a time, but you still may run into snags at full cutover time when Interlink is no longer there. You might consider setting up a test window on a weekend or perhaps a test system, where z/OS is brought up with IBM's TCPIP in place and no trace of Interlink/CA. Then shake out each of the apps and decide when to cut over. Seems like IBM products and programs were generally better behaved than ISV products. At the time there were some functions that were supported on one stack but not the other, that caused us problems (IUCV perhaps?) In converting FTP control statements, Interlink ignored cc73-80, IBM's did not. Sequence numbers on control statements would be interpreted by IBM FTP as port number, causing misleading errors such as connection timed out, or invalid port. Dana Mitchell -- 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
