Re: z/VM 5.2 conversion IP problem (solved)

2007-01-22 Thread David Boyes
> 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

Re: z/VM 5.2 conversion IP problem (solved)

2007-01-22 Thread Tom Duerbusch
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 o

Re: z/VM 5.2 conversion IP problem (solved)

2007-01-22 Thread David Boyes
> > 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

Re: z/VM 5.2 conversion IP problem (solved)

2007-01-22 Thread Adam Thornton
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 favora

Re: z/VM 5.2 conversion IP problem (solved)

2007-01-22 Thread Miguel Delapaz
>> 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 >

Re: z/VM 5.2 conversion IP problem (solved)

2007-01-22 Thread David Boyes
> 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-subnette

Re: z/VM 5.2 conversion IP problem (solved)

2007-01-22 Thread Alan Altmark
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 o

Re: z/VM 5.2 conversion IP problem (solved)

2007-01-22 Thread David Boyes
> 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 opportun

Re: z/VM 5.2 conversion IP problem (solved)

2007-01-22 Thread David Boyes
> 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 medi

Re: z/VM 5.2 conversion IP problem (solved)

2007-01-21 Thread Shimon Lebowitz
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 co

Re: z/VM 5.2 conversion IP problem (solved)

2007-01-19 Thread Tom Duerbusch
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 y