Re: VM TCP/IP Secure Telnet
On Friday, 05/09/2008 at 09:12 EDT, Tim Joyce [EMAIL PROTECTED] wrote: I think the problem is, TUBES really is taking control of port 23. One of the procedures to setup TUBES telnet, is to take (comment) out the PORT 23 statement from PROFILE TCPIP. So, there is no way of letting TCPIP know that port 23 is a SECURE port. I think the fact that Macro4 says secure telnet IS NOT supported, indicates secure telnet will not work. (sigh) There are TWO kinds of secure telnet servers: 1. The SSL tunnel is established BEFORE any telnet traffic begins (static SSL) 2. The SSL tunnel is established AFTER telnet protocol negotiation has started, but before any user data is transferred (dynamic SSL) If your TN3270 client supports static SSL, then it should work with TUBES, as TUBES would be unaware that the SSL session is in effect. Your PROFILE would show 23 TCP TUBESVM SECURE label Alan Altmark z/VM Development IBM Endicott
Re: VM TCP/IP Secure Telnet
On Friday, 05/09/2008 at 12:19 EDT, Les Geer (607-429-3580) [EMAIL PROTECTED] wrote: PVM (AKA VM/Pass-Through Facility) is a session manager product supporting multiple sessions on one terminal. However, it does not support creation of telnet sessions so does not support SSL. With z/VM 5.3's client-side support for SSL, anyone wanting to write a pair of Pascal program or assembler modules can create a nearly-transparent proxy relay. Most would find it easier to use an adjacent Linux guest on each system with ssh port forwarding. Alan Altmark z/VM Development IBM Endicott
Re: VM TCP/IP Secure Telnet
On Friday, 05/09/2008 at 12:50 EDT, David Boyes [EMAIL PROTECTED] wrote: PVM also has the downside of not being easily licensable on IFLs at the moment. The VM guys might be about to do something about that, but at the moment, getting PVM for an IFL install is a lengthy and somewhat complicated process. It's also not cheap. I can't comment on the difficulty; you're the one who experienced it! Generally, the first special bid (by any customer) takes the longest since SWG has to create the electronic gizmos that allow the order and to set a price and TsCs. After that, it's usually smooth sailing using an off-the-shelf price. SOME people might run into problems getting it because their BP or IBMer doesn't know how to handle special bids, but that's a different problem! As to the cost, do the math. How long were you thinking of running the product? How many years of monthly license fees does it cover? After that, all you're paying is an annual maintenance fee. If we stop service, you can stop paying, but you still get to keep using the software. (Unlike ICA.) There is a significant downside to special bids, however: They do not include the rights to free upgrades as you have with our IPLA software and often have limited use clauses. Alan Altmark z/VM Development IBM Endicott
Re: VSWITCH VLAN-aware not connecting
On Friday, 05/09/2008 at 05:11 EDT, Richard Clapper [EMAIL PROTECTED] wrote: Thanks, Nick, for this. I had been using the 5.2 CP Command manual, which didn't have NATIVE. We recently converted to 5.3. I've been playing around with this, and it's still not working for me. Just to clarify, in your example you didn't set VLAN on the SET VSWITCH command, so the Linux Guest would default to VLAN 83. Do you have other guests, for other VLANs, on this VSWITCH, and do you explicitly specify the VLAN number for them? Why would I choose VLAN 83 over any other VLAN number that I want to use? The VLAN parameter does the following: 1. Indicates that you are operating a VLAN-aware VSWITCH. The OSA port MUST be configued as a trunk port in the physical switch. 2. Identifies the default VLAN assignment for any guest who is given authority to connect to the VSWITCH, but for whom no VLAN id was specified. 3. Identifies the DEFAULT VLAN id on the OSA's switch port. Say, what? That is, a trunk port can send untagged frames. If it does, the port's DEFAULT VLAN is assigned by the switch. Likewise, if data is headed TO the VSWITCH and it is coming from the default VLAN, the VLAN tag is not present. Any guest who has PORTTYPE TRUNK -AND- is authorized to use the default VLAN id will receive said frames (sans tag) and will have any untagged frames sent (still untagged) to the OSA as-is. If the DEFAULT VLAN id is not configured for the port in the switch, the NATIVE VLAN id will be used. The initial value for the NATIVE VLAN id in Cisco switches is VLAN 1. It follows, then, that the initial DEFAULT VLAN on a trunk port is VLAN 1. Some installations change the DEFAULT VLAN on the port in order to trap any untagged frames and prevent them from flowing through the switch. In z/VM 5.3 we changed DEFINE VSWITCH to let you specify the default *guest* VLAN assignment SEPARATELY from the DEFAULT VLAN id for the *port*. The default guest assignment is whatever you put on VLAN (consistent with #2 above). You specify the port's DEFAULT VLAN id by using the NATIVE keyword. The rules for the NATIVE vlan ID are as described in #3. If you do not specify NATIVE in z/VM 5.3, it will default to the same value as you specified on the VLAN keyword, providing compatibility with z/VM 5.2 and earlier. Alan Altmark z/VM Development IBM Endicott
Re: Hipersockets
On Friday, 05/09/2008 at 01:58 EDT, Thomas Kern [EMAIL PROTECTED] wrote: Is there an IBM Statement of Direction for a VSWITCH/HiperSocket connection? No. Requirement MR0331062246 was submitted in 2006 and was answered Suggestion. If others want this support, please get with your fave user group and get it submitted. I noticed, too, that both z/OS and z/TPF have requirements open for native VSWITCH support like z/VM has. (Wooo hooo YEAH! (sorry) ) Alan Altmark z/VM Development IBM Endicott
Re: Hipersockets
On Friday, 05/09/2008 at 02:10 EDT, Mark Pace [EMAIL PROTECTED] wrote: I need a LAN connected to real Hipersockets to test this problem. Well maybe not, just to test connectivity I could try just VM's TCPIP and the z/OS guest. If it works, then know I know I have some odd hardware problem. Since you didn't draw a picture (whack!), let me do so based on my observations from your posts. You've got 5 hosts in a single CEC trying to use HiperSockets: CHPID FF 10.6.0.0/24 +-++--+--+ | || | | VM TCP#1 MVS LPARMVS Guest VM TCP#2 VSE Guest 10.6.0.4 10.6.0.310.6.0.5 10.6.0.2 ??.??.??.?? MTU 1496 1496 1496 1496 OK so far? Problem statement: MVS Guest cannot communicate with at least one of the VM TCP/IPs. (I'm not sure which.) You CAN communicate among all other users of the HiperSocket. There was a reference to OSAs, but I considered it to be a red herring since they (the OSAs, not the herring) are not involved in getting data across a HiperSocket. Can you clarify what is communicating successfully via HiperSockets and what isn't? Just to exlude a rare ailment, for each VM guest (incl. TCPIP), 1. Issue #CP Q V (where is the device address of one of the HIPERS devices) 2. Using the Subchannel = yy value on the output from #1, issue #CP D SCHIB yy 3. Verify that the virtual chpid number is FF00 For VM TCP/IP, you can just NETSTAT CP command. No logon required. Alan Altmark z/VM Development IBM Endicott
