Historically, what I had (VCTCA and IUCV connections), was P2P. With
P2P
you don't have a router address nor do you have a broadcast address.
Just
wasn't needed.
Well, you do have a router address; it's just the other end of the link.
The presence of broadcast depends on the type of media.
At the time, I sat down and wrote a sort of 'cookbook'
approach to what I wanted, and how I got it, and David Boyes
generously volunteered to set ut up as a pdf document
on SNA's website.
I'll be happy to provide similar service for this document as well.
Anything that gives me an opportunity
On Monday, 01/22/2007 at 07:59 EST, David Boyes [EMAIL PROTECTED]
wrote:
And I assume the reason why Linux shows me a netmask of
255.255.255.255 for P2P connections is there is some code,
No, there's only one host on the other end of the link, so you don't
actually have a subnet on a P2P
In this I would agree, except to say watch out if you get into
OSPF/RIP,
because (according to our z/OS brethren) the OSPF protocol doesn't
recognize non-subnetted networks and subnets are required (RFC 3021's
31-bit masks notwithstanding, I guess).
Hmph. Class D routes and non-subnetted
This is why the OSPF configuration in z/VM 5.2 no longer allows a mask
of
255.255.255.255. I'm not saying z/OS is necessarily correct, I'm just
pointing it out to avoid further confusion. (Yeah, right. Sure.)
Bug, IMHO. Valid route, should be valid syntax. The fact you *can* shoot
On Jan 22, 2007, at 12:00 PM, Miguel Delapaz wrote:
I agree, allowing customers to shoot them selves in various parts
of their
anatomy is *not* the tool's problem. However, it does become our
problem
when the shot is taken, they call us and their overall user
experience is
less than
Bug, IMHO. Valid route, should be valid syntax. The fact you *can*
shoot
yourself in the head is not the tool's problem. Your gun, your foot.
[snip]
I agree, allowing customers to shoot them selves in various parts of
their
anatomy is *not* the tool's problem. However, it does become our
Hi Shimon
The SNA website (Sine Nomine Associates, not SNA/VTAM), might solve
half the problem, that is how to distribute the document. But, SNA is
more of a Linux oriented company. Yes, there also has some VM related
stuff. But I don't think that a VM shop without Linux, would really
come to
But, SNA is
more of a Linux oriented company.
Definitely *not* the case. That's just a small part of what we do.
Part of my question to all, is there a VM oriented site for
documentation and other practices? VSE has one. Linux has many. VM
has a download area for tools, but I don't see
On 19 Jan 2007 at 12:38, Tom Duerbusch wrote:
I'm not thinking of something as formal as a manual, or even a Redbook.
Perhaps something a little more than the foils of some presentation.
(Usually a presentation doesn't happen at the right time, and the right
time here is prior to a
Well, imagine that, my test node (linux27) worked.
I guess things work right when you do it the legit way..
Who would have thunk?
So, now as I go back to try to correct my knowledge defect and get me on the
right path...
Historically, what I had (VCTCA and IUCV connections), was P2P. With P2P
On Wednesday, 01/17/2007 at 06:47 PST, Thomas Kern [EMAIL PROTECTED]
wrote:
You mean people actually get paid for this?
You betcha! If you get yourself some Cisco router and switch education,
along with VM, VSE, MVS, and Linux network configuration expertise, you
have a marketable skill.
I'm still having problems after last nights tests...
Where Miguel says you don't have to have a HOST entry, when I leave it
out, I don't get connected. When I put one in, I do get connected (but
routing is still off).
I'm now using the IUCV connection to a SLES9 31 bit with SP 1 machine
that
I believe Alan brought this up yesterday, but I'll mention it again...the
IP address on you VM system (in your HOME statement) *MUST* be different
from the IP address on your linux system (i.e. the IP address on the HOST
GATEWAY route):
HOME
192.168.099.227 255.255.255.000 LLINUX27
It is different. But we might be talking about different things:
HOME
205.235.227.74 255.255.255.000 QDIO1
; 192.168.099.227 HOST
; HOST PRODUCES:
You see the HOME statement. You see the 192.168.099.227 in the HOME statement. That must not be the
same as the address of the Linux system. It is the same. I must be different. Two people have told
you this. Maybe, if three do you will believe it.
[EMAIL PROTECTED] wrote:
It is different.
On Wednesday, 01/17/2007 at 11:32 CST, Tom Duerbusch
[EMAIL PROTECTED] wrote:
I'm still having problems after last nights tests...
Where Miguel says you don't have to have a HOST entry, when I leave it
out, I don't get connected. When I put one in, I do get connected (but
routing is still
Hi Ed, not a problem.
I might be intelligent in some areas, but I'm hitting a brick wall with
a dense head, here G.
I wish I was hung over or something in order to have a valid excuse on
this one.
Tom Duerbusch
THD Consulting
[EMAIL PROTECTED] 1/17/2007 1:17 PM
Two people have told you
Hi Stephen
Since VM/ESA 370 mode, I don't think I ever had HOME statements for
anything other than my VM system. That includes last week when we were
on z/VM 5.1. Now, I think I'm being told that I need a HOME statement
for each link statement. And now told that these few dozen HOME
On Jan 17, 2007, at 1:58 PM, Tom Duerbusch wrote:
I wish I was hung over or something in order to have a valid excuse on
this one.
Could be arranged. For tomorrow, anyway.
Come on over. I'm expecting to knock off work about five today.
Adam
I wish I was hung over or something in order to have a valid excuse
on this one.
Could be arranged. For tomorrow, anyway.
Come on over. I'm expecting to knock off work about five today.
Can I come too please? Maybe I can learn to tone down my reaction
to listserv posts.
Sorry I
On Wednesday, 01/17/2007 at 02:10 CST, Tom Duerbusch
[EMAIL PROTECTED] wrote:
Since VM/ESA 370 mode, I don't think I ever had HOME statements for
anything other than my VM system. That includes last week when we were
on z/VM 5.1. Now, I think I'm being told that I need a HOME statement
Hi Allen
I'm starting to see where you are coming from with this. Obviously,
historically, there have been multiple ways of coding these entries.
And I have been able to get away with my way for a couple decades (not
bad, huh?) But it may be time to pay the piper on this one.
It didn't last
Perhaps now would be a good time for IBM to release a tutorial for the
pre-5.2 - 5.2+ migrations. Lots of real-life examples and examples of
migration from oldder network architectures to the new GuestLans/Vswitch
architectures and then onto the VLAN stuff. Please remember that most of
the
VM
Quoting Tom Duerbusch [EMAIL PROTECTED]:
Hi Stephen
Since VM/ESA 370 mode, I don't think I ever had HOME statements for
anything other than my VM system. That includes last week when we were
on z/VM 5.1. Now, I think I'm being told that I need a HOME statement
for each link statement.
Of course this throws things off even more as on the z/VM 5.1 system, I
only had the single HOME entry (for 205.235.227.74) and I had (working
correctly) about 3 dozen other interfaces. Attached is the old config
file for z/VM 5.1. I agree that I may have gotten away with things that
now,
Tom,
See the attached PDF diagram -- it might help you to understand the
overall approach. All the white circles in the diagram need to have
unique IP addresses, and the ones on the ends of the CTC/IUCV links need
addresses in the same subnet.
1. I do need a HOME statement for each
My other post goes into more detail on the answers to these...but I'll
reiterate here
1. I do need a HOME statement for each interface, 30 some odd HOME
statementsright?
Essentially, yes.
2. The IP statement on the HOME statement:
a. Cannot duplicate any other IP address in the
On Jan 17, 2007, at 2:58 PM, Tom Duerbusch wrote:
So, in the latest post towards Miguel:
1. I do need a HOME statement for each interface, 30 some odd HOME
statementsright?
If you have VCTCs hanging off each of them, yes.
2. The IP statement on the HOME statement:
a. Cannot
On Wednesday, 01/17/2007 at 03:11 CST, Thomas Kern [EMAIL PROTECTED]
wrote:
Perhaps now would be a good time for IBM to release a tutorial for the
pre-5.2 - 5.2+ migrations. Lots of real-life examples and examples of
migration from oldder network architectures to the new GuestLans/Vswitch
Collections of real-world network pictures and their matching configs
would be an excellent candidate for the Wiki.
Where is this Wiki???
See the attached PDF diagram -- it might help you to understand the
overall approach. All the white circles in the diagram need to have
unique IP addresses, and the ones on the ends of the CTC/IUCV links
need
addresses in the same subnet.
Blech. The attachment got stripped by the mailing
On Jan 17, 2007, at 4:10 PM, Tom Duerbusch wrote:
Hi Adam
That might be doable Thursday. I have an AA meeting tonight...just
kidding.
Got a favorite watering hole in mind?
My living room was what I had in mind...I rarely go out to drink:
see the first panel of
On Jan 17, 2007, at 4:10 PM, Tom Duerbusch wrote:
Hi Adam
That might be doable Thursday. I have an AA meeting tonight...just
kidding.
Got a favorite watering hole in mind?
John's Town Hall is the place I was thinking of with the fried
chicken.
Adam
You mean people actually get paid for this?
To be more realistic, I have been able to configure two OSA driven VSWITCHes
for separate inside/outside linux servers and to do cross-LPAR communications
via a hipersocket, but it is still rather simplistic compared to a raft of
point-to-point
OK, so I took out the statements in the HOME area. When I did that, VSE
(via VCTCA, or the sole Linux image that is still using IUCV) wouldn't
connect anymore.
On the VSE side (guest machine NEWESA4), I now get the following, no
matter what other changes I make to the VM side:
0016: IPL380I
On Tuesday, 01/16/2007 at 08:22 CST, Tom Duerbusch
[EMAIL PROTECTED] wrote:
OK, so I took out the statements in the HOME area. When I did that, VSE
(via VCTCA, or the sole Linux image that is still using IUCV) wouldn't
connect anymore.
Sorry for not being clearer:
- You must have a HOME
On Jan 16, 2007, at 9:00 AM, Alan Altmark wrote:
Sorry for not being clearer:
- You must have a HOME entry for each interface
- You may not duplicate any IP address in the HOME list. Each must be
unique.
- You should put each VM--VSE connection in its own .252 subnet.
To the
extent you are
You don't *have* to have the HOST entry if you have the subnet route. It
doesn't hurt, and will make some things more clear. For example, the
P-t-P address on the IFCONFIG output is taken from the HOST routing entry.
Regards,
Miguel Delapaz
z/VM TCP/IP Development
The IBM z/VM Operating
It has taken me a while to recall why I havn't been using more than 1
HOME statement.
I did this many years ago and got the same result.
When I update the configuration to:
HOME
205.235.227.74 255.255.255.000 QDIO1
192.168.099.227
On Monday, 01/15/2007 at 03:02 CST, Tom Duerbusch
[EMAIL PROTECTED] wrote:
HOME
205.235.227.74 255.255.255.000 QDIO1
192.168.099.227 255.255.255.000 LLINUX27
192.168.099.024 255.255.255.000 LNEWESA4
192.168.099.010 255.255.255.000 LY2KESA2
; (End HOME Address information)
GATEWAY
;
On Saturday, 01/13/2007 at 03:56 CST, Tom Duerbusch
[EMAIL PROTECTED] wrote:
I'm in the mist of converting from z/VM 5.1 to z/VM 5.2 and having an IP
problem.
Actually, I couldn't just take my ZVMV5R10 TCPIP statements and put
them on the newer system. I had to rewrite many of them.
Eh?
I'm in the mist of converting from z/VM 5.1 to z/VM 5.2 and having an IP
problem.
The VM stack is connected to a vswitch. And as far as the VM side is
concerned, all is well, (FTP, PING, TN3270, etc).
My, more modern VSE guests (2.5 and above) are connected to the vswitch
and all seems to be
43 matches
Mail list logo
