Re: VTAM R.I.P. -- SNATAM anyone?
Jim Bohnsack wrote: I remember the SNATAM name now. There was an Englishman, Graham Pursey, who used to attend the VNET Project Team meetings that were held once or twice a year. It seems to me that he was involved in some kind of VM based VTAM project. Was that it or was there something else? It seems to me that there was something besides SNATAM. Getting old and memory is the second thing to go. Don't remember what the first was. from the 26-28feb80 VMITE schedule: Graham Pursey - SNATAM. This system is being perfected in Hursley to operate SNA devices from a CMS based system. The current direction is to make this into a product. 45 minutes to 1 hr ... snip ... there were constant battles with the communication group ... I got into all sort of problems with hsdt (high speed data transport) project ... http://www.garlic.com/~lynn/subnetwork.html#hsdt to place things in better perspective ... SNA wasn't networking ... it was dumb terminal communication. example of gap between the communication group and hsdt project: and also working with various parties associated with getting NSFNET going. http://www.garlic.com/~lynn/subnetwork.html#nsfnet recent retelling http://www.garlic.com/~lynn/2008e.html#45 of an announcement (one friday) by the communication group for a new internal conference. included in the announcement were these definitions (to be used for the conference): low-speed: 9.6kbits medium-speed: 19.2kbits high-speed 56kbits very high-speed 1.6mbits the next monday on a business trip to the far east, definition on the conference room wall low-speed 20mbits medium-speed 100mbits high-speed200-300mbits very high-speed 600mbits eventually we weren't allowed to bid on nsfnet backbone ... even tho a nsf audit of the high-speed backbone claimed that what we already had running (internally) was at least five years ahead of all NSFNET bid submissions. some related old email from the period http://www.garlic.com/~lynn/lhwemail.html#nsfnet including some stuff forwarded to us about communication group spreading FUD that sna vtam could be used for NSFNET. http://www.garlic.com/~lynn/2006w.html#email870109 for other topic drift, the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet (which wasn't SNA until the late 80s) was technology from the science center http://www.garlic.com/~lynn/subtopic.html#545tech and was larger than the arpanet/internet from just about the beginning until sometime mid-85. this was about the time that serious efforts were made to try and get the internal network converted over to sna (and also contributed to the internet exceeding the internal network). in this period there was a big explosion in internet nodes from workstations and PCs. SNA was still treating internal network as something that was purely (mainframe) host-to-host ... and the exploding numbers of PCs were to continue to be served by terminal emulation. some past posts http://www.garlic.com/~lynn/subnetwork.html#emulation
Re: VTAM R.I.P. -- SNATAM anyone?
I can't help but toss in two cents here... Back many years ago when I worked up at IBM Boulder we had an edict to install VTAM access to our VM system so all the sales people around the country could get PROFS. There was no GCS at the time, and the whole VS/1, VTAM, VSCS thing was a mess, unstable, and devoured our machine... We stumbled into a project from the Rochester MN lab called SNATAM. A true VM-based implementation of SNA. As I recall... It ran in a couple CMS userids and all the config files were just CMS files. It talked to MVS by CTCs and also supported attached 3745s. It was small, neat and efficient. Then management found our that we were running it instead of VTAM on such a high visibility project and forced us to switch to the VS/1 VTAM VSCS mess. Then eventually GCS etc. Then, when the Notes edict killed PROFS, it killed the need for VTAM there... The silly part was that the sales people across the country never even knew they were using VM -- just PROFS... If they knew they used VM all the time maybe they wouldn't have talked down about it so much... Sigh... Lee (no VTAM on my lab systems!) Jim Bohnsack wrote: We still have it here, but I suspect that it is not long lived. Some of my worst memories involve VTAM on VM. I was the VM team leader for the IBM Education support center in Dallas in 1985 and told my manager and my 2nd level that we should get VM/SP R4 for the remote locations we suppported and HPO R4 for the central site 3081's. R4 was the release with native VTAM support. VTAM had been supported for a while with VS/1 or DOS/VS hosting VTAM but someone decided that GCS was the way to go. They took a gutted MVS/XA and quickly fitted it into VM. I don't remember that GCS abended all the time, but CP certainly did. VM/SP R4, with and without HPO was an absolute disaster. If we went thru a day without a CP abend, we celebrated. R4 was probably the shortest lived VM release ever. I think it went GA in December of 1985 and was replaced with VM/SP 4.3 in about March. It was a great improvement. During the fall of '85, Barton Robinson practically lived with us being the expert from the East sent to help us. I remember the arguments inside IBM regarding VTAM vs. TCPIP. IBM was going to be pure VTAM. It's too bad that internal IBM was so stuck on SNA and VTAM that there could not have been an earlier combination of the two disciplines. Jim Schuh, Richard wrote: Lee Stewart, Senior SE Sirius Computer Solutions Phone: (303) 798-2954 Fax: (720) 228-2321 Email: [EMAIL PROTECTED] Web: www.siriuscom.com
Re: VTAM R.I.P. -- SNATAM anyone?
I remember the SNATAM name now. There was an Englishman, Graham Pursey, who used to attend the VNET Project Team meetings that were held once or twice a year. It seems to me that he was involved in some kind of VM based VTAM project. Was that it or was there something else? It seems to me that there was something besides SNATAM. Getting old and memory is the second thing to go. Don't remember what the first was. Jim Lee Stewart wrote: I can't help but toss in two cents here... Back many years ago when I worked up at IBM Boulder we had an edict to install VTAM access to our VM system so all the sales people around the country could get PROFS. There was no GCS at the time, and the whole VS/1, VTAM, VSCS thing was a mess, unstable, and devoured our machine... We stumbled into a project from the Rochester MN lab called SNATAM. A true VM-based implementation of SNA. As I recall... It ran in a couple CMS userids and all the config files were just CMS files. It talked to MVS by CTCs and also supported attached 3745s. It was small, neat and efficient. Then management found our that we were running it instead of VTAM on such a high visibility project and forced us to switch to the VS/1 VTAM VSCS mess. Then eventually GCS etc. Then, when the Notes edict killed PROFS, it killed the need for VTAM there... The silly part was that the sales people across the country never even knew they were using VM -- just PROFS... If they knew they used VM all the time maybe they wouldn't have talked down about it so much... Sigh... Lee (no VTAM on my lab systems!) -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
z/Linux versus z/OS costs (was VTAM R.I.P.)
On Thu, 3 Apr 2008 17:45:09 -0400, Said, Nick [EMAIL PROTECTED] wrote: Our management came up with: Per MIP Cost Analysis EnvironmentOnetime Ongoing z/OS $7,300 $1,980 z/Linux$447$61 Of course, this does not include the cost of any Velocity Software products on z/VM :) I'd very much like to know how you came up with those numbers. Can you br eak it out in any more detail? (Software versus hardware, for example?) I'm charged with lo oking at moving z/OS work to z/Linux. The price for an IFL engine is $125,000. I don't think t he cost for a standard engine is fixed, but someone at SHARE once said the cost ratio was about 4:1 (standard:IFL) FWIW. People here won't give me a cost number for the software because we have an enterprise license. The biggest problem I have run into is that most z/OS program products do n't have equivalents in z/Linux. (The exceptions are in the Tivoli and WAS spaces.) Most applicat ions we have depend on these program products. Of course a new application would not have this problem, but around here, those are being written for the midrange. Server consolidation should handle this, but so far we have not gotten this through the political hoops. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: z/Linux versus z/OS costs (was VTAM R.I.P.)
On Mon, Apr 7, 2008 at 12:14 AM, in message [EMAIL PROTECTED], Alan Ackerman [EMAIL PROTECTED] wrote: -snip- People here won't give me a cost number for the software because we have= an enterprise license. Then ask them for the cost of the enterprise license. Theoretically you wouldn't be able to eliminate that cost unless you completely eliminate all uses of the software. But, if the level of use gets low enough, you can stop paying for an enterprise license and only buy licenses for what is being used. The biggest problem I have run into is that most z/OS program products do= n't have equivalents in z/Linux. (The exceptions are in the Tivoli and WAS spaces.) Most applicat= ions we have depend on these program products. Well, of course not. That's why moving workload from z/OS to Linux would be considered a porting effort, not just a workload move. Mark Post
Re: VTAM R.I.P.
I haven't heard that one before, Neale (maybe because I never worked in a VM-VTAM environment, lucky me), but it is laugh out loud funny. Neale Ferguson wrote: John Akers answers the phone: Hello Caller: John Akers? JA: Yes. Caller: John Akers of IBM? JA: Yes. Caller: John Akers of IBM, White Plains? JA: Yes! Caller: John Akers of IBM, White Plains, NY, USA? JA: Yes, WTF do you want!!! Caller: Just wanted to let you know how it feels to set up an SNA session. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: VTAM R.I.P.
Actually, the version I saw years ago had many more questions and responses, but the gist of the VTAM binding process is here. :-) -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/4/08 7:44 AM, Dave Jones [EMAIL PROTECTED] wrote: I haven't heard that one before, Neale (maybe because I never worked in a VM-VTAM environment, lucky me), but it is laugh out loud funny. Neale Ferguson wrote: John Akers answers the phone: Hello Caller: John Akers? JA: Yes. Caller: John Akers of IBM? JA: Yes. Caller: John Akers of IBM, White Plains? JA: Yes! Caller: John Akers of IBM, White Plains, NY, USA? JA: Yes, WTF do you want!!! Caller: Just wanted to let you know how it feels to set up an SNA session.
Re: VTAM R.I.P.
I haven't heard that one before, Neale (maybe because I never worked in a VM-VTAM environment, lucky me), but it is laugh out loud funny. Right up there with Ole and Lena. 8-) Worse yet, it's a general SNA issue, not just VM. APPN session setup is even weirder...
Re: VTAM R.I.P.
It is the same with any VTAM. MVS, VSE, or VM VTAM jumps through the same hoops when establishing a SNA connection. Dave Jones wrote: I haven't heard that one before, Neale (maybe because I never worked in a VM-VTAM environment, lucky me), but it is laugh out loud funny. Neale Ferguson wrote: John Akers answers the phone: Hello Caller: John Akers? JA: Yes. Caller: John Akers of IBM? JA: Yes. Caller: John Akers of IBM, White Plains? JA: Yes! Caller: John Akers of IBM, White Plains, NY, USA? JA: Yes, WTF do you want!!! Caller: Just wanted to let you know how it feels to set up an SNA session. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: VTAM R.I.P.
I am not sure that you were defending VTAM. All of the interesting things that you did were done to overcome deficiencies. That seems quite the opposite of a defense. Richard Schuh On the matter of defense of VTAM, one thing that VTAM (and SNA networking in general) does do well is lend itself to predictive modeling of network behavior. The lockstep model used in SNA is very amenable to standard simulation techniques, which make it very easy to determine the impact of a change, or determine the capacity of the network in the abstract. The completely define the world approach makes it much easier to construct full topology graphs and diagnostics tools. SNA also has much better engineered instrumentation for measurement. TCP networks are self-similar, which complicates prediction by a lot, and SNMP is a real hack. It's all we have at the moment, but it lacks a lot for sampling and performance analysis.
Re: VTAM R.I.P.
Those are features that can be entered in the plus column :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Friday, April 04, 2008 9:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. I am not sure that you were defending VTAM. All of the interesting things that you did were done to overcome deficiencies. That seems quite the opposite of a defense. Richard Schuh On the matter of defense of VTAM, one thing that VTAM (and SNA networking in general) does do well is lend itself to predictive modeling of network behavior. The lockstep model used in SNA is very amenable to standard simulation techniques, which make it very easy to determine the impact of a change, or determine the capacity of the network in the abstract. The completely define the world approach makes it much easier to construct full topology graphs and diagnostics tools. SNA also has much better engineered instrumentation for measurement. TCP networks are self-similar, which complicates prediction by a lot, and SNMP is a real hack. It's all we have at the moment, but it lacks a lot for sampling and performance analysis.
Re: VTAM R.I.P.
Does it include the cost of Omegamon on zOS? Melissa Curry Sales Representative Velocity Software, Inc. 196-D Castro Street Mountain View, CA 94041-1202 Office: (650) 964-8867 Cell: (415) 994-4579 fax: (650) 964-9012 [EMAIL PROTECTED] www.velocitysoftware.com - Original Message - From: Said, Nick [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Sent: Thursday, April 03, 2008 2:45 PM Subject: Re: VTAM R.I.P. Our management came up with: Per MIP Cost Analysis Environment Onetime Ongoing z/OS $7,300 $1,980 z/Linux $447 $61 Of course, this does not include the cost of any Velocity Software products on z/VM :) -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, April 03, 2008 12:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. Gee, next it will be the high cost of z/OS that you will be looking at. How much do you save if you move an application from z/OS to z/Linux? Colin Allinson wrote: Rob van der Heij [EMAIL PROTECTED] wrote :- Z NET,QUICK Couldn't be 'QUICK' enough for us. We managed to eliminate it from VM by the middle of last year. We went back to using basic mode CTC connections to z/OS until they got themselves up to 1.7 with the ability to use TCPNJE. The interesting thing was that it was the huge cost of VTAM that was the main motivation for us. Given that the product was functionally stabilised and needed virtually zero support for a number of years we were struggling to see why. Once we looked at VTAM, and eliminated it, this led us to look at a number of other relatively high cost products that we have ways to eliminate, replace or reduce. I am not saying that we would not have looked at these anyway but the high cost of VTAM was the catalyst to start looking. Colin Allinson Amadeus Data Processing GmbH This email is intended for the recipient only. If you are not the intended recipient please disregard, and do not use the information for any purpose.
Re: VTAM R.I.P.
On the z/OS side, yes. Not on the z/VM side. Perfkit is the z/VM tool and it feeds Omegamon XE which is already collecting from all our distributed boxes. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Melissa Curry Sent: Friday, April 04, 2008 3:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. Does it include the cost of Omegamon on zOS? Melissa Curry Sales Representative Velocity Software, Inc. 196-D Castro Street Mountain View, CA 94041-1202 Office: (650) 964-8867 Cell: (415) 994-4579 fax: (650) 964-9012 [EMAIL PROTECTED] www.velocitysoftware.com - Original Message - From: Said, Nick [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Sent: Thursday, April 03, 2008 2:45 PM Subject: Re: VTAM R.I.P. Our management came up with: Per MIP Cost Analysis Environment Onetime Ongoing z/OS $7,300 $1,980 z/Linux $447 $61 Of course, this does not include the cost of any Velocity Software products on z/VM :) -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, April 03, 2008 12:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. Gee, next it will be the high cost of z/OS that you will be looking at. How much do you save if you move an application from z/OS to z/Linux? Colin Allinson wrote: Rob van der Heij [EMAIL PROTECTED] wrote :- Z NET,QUICK Couldn't be 'QUICK' enough for us. We managed to eliminate it from VM by the middle of last year. We went back to using basic mode CTC connections to z/OS until they got themselves up to 1.7 with the ability to use TCPNJE. The interesting thing was that it was the huge cost of VTAM that was the main motivation for us. Given that the product was functionally stabilised and needed virtually zero support for a number of years we were struggling to see why. Once we looked at VTAM, and eliminated it, this led us to look at a number of other relatively high cost products that we have ways to eliminate, replace or reduce. I am not saying that we would not have looked at these anyway but the high cost of VTAM was the catalyst to start looking. Colin Allinson Amadeus Data Processing GmbH This email is intended for the recipient only. If you are not the intended recipient please disregard, and do not use the information for any purpose. This email is intended for the recipient only. If you are not the intended recipient please disregard, and do not use the information for any purpose.
Re: VTAM R.I.P.
Rob van der Heij [EMAIL PROTECTED] wrote :- Z NET,QUICK Couldn't be 'QUICK' enough for us. We managed to eliminate it from VM by the middle of last year. We went back to using basic mode CTC connections to z/OS until they got themselves up to 1.7 with the ability to use TCPNJE. The interesting thing was that it was the huge cost of VTAM that was the main motivation for us. Given that the product was functionally stabilised and needed virtually zero support for a number of years we were struggling to see why. Once we looked at VTAM, and eliminated it, this led us to look at a number of other relatively high cost products that we have ways to eliminate, replace or reduce. I am not saying that we would not have looked at these anyway but the high cost of VTAM was the catalyst to start looking. Colin Allinson Amadeus Data Processing GmbH
Re: VTAM R.I.P.
I was basing that on what an MVS sysprog told me. I will stand by my stmt, tho, that HPO 4 was the most unstable operating system release I've seen in 41+ years of working in this racket. Also that it was one of the shortest lived releases. Jim Alan Altmark wrote: On Wednesday, 04/02/2008 at 09:30 EDT, Jim Bohnsack [EMAIL PROTECTED] wrote: R4 was the release with native VTAM support. VTAM had been supported for a while with VS/1 or DOS/VS hosting VTAM but someone decided that GCS was the way to go. They took a gutted MVS/XA and quickly fitted it into VM. Nonsense. There is no more MVS/XA code in GCS than there is in CMS. Alan Altmark z/VM Development IBM Endicott -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: VTAM R.I.P.
Gee, next it will be the high cost of z/OS that you will be looking at. How much do you save if you move an application from z/OS to z/Linux? Colin Allinson wrote: Rob van der Heij [EMAIL PROTECTED] wrote :- Z NET,QUICK Couldn't be 'QUICK' enough for us. We managed to eliminate it from VM by the middle of last year. We went back to using basic mode CTC connections to z/OS until they got themselves up to 1.7 with the ability to use TCPNJE. The interesting thing was that it was the huge cost of VTAM that was the main motivation for us. Given that the product was functionally stabilised and needed virtually zero support for a number of years we were struggling to see why. Once we looked at VTAM, and eliminated it, this led us to look at a number of other relatively high cost products that we have ways to eliminate, replace or reduce. I am not saying that we would not have looked at these anyway but the high cost of VTAM was the catalyst to start looking. Colin Allinson Amadeus Data Processing GmbH
Re: VTAM R.I.P.
Yeah, it was a gutted OS/360 MFT system. MVS/XA was not even a gleam in its daddy's eye. Those first days of either a DOS or a VS1 system to run VTAM were the pits. I remember the announcement of VM/VTAM at Guide (my employer at the time viewed SHARE as a bunch of Hippies getting together to have a party, while Guide was for serious business people). That announcement was greeted with all the enthusiasm it deserved. People were either silent or they booed and hissed. And the presenters seemed shocked. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, April 02, 2008 10:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. On Wednesday, 04/02/2008 at 09:30 EDT, Jim Bohnsack [EMAIL PROTECTED] wrote: R4 was the release with native VTAM support. VTAM had been supported for a while with VS/1 or DOS/VS hosting VTAM but someone decided that GCS was the way to go. They took a gutted MVS/XA and quickly fitted it into VM. Nonsense. There is no more MVS/XA code in GCS than there is in CMS. Alan Altmark z/VM Development IBM Endicott
Re: VTAM R.I.P.
Still have the VTAM cow here though it may have gone to its final lonely pasture. (NETVIEW, SAS and other cows are gone now). From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Colin Allinson Sent: Thursday, April 03, 2008 3:47 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. Rob van der Heij [EMAIL PROTECTED] wrote :- Z NET,QUICK Couldn't be 'QUICK' enough for us. We managed to eliminate it from VM by the middle of last year. We went back to using basic mode CTC connections to z/OS until they got themselves up to 1.7 with the ability to use TCPNJE. The interesting thing was that it was the huge cost of VTAM that was the main motivation for us. Given that the product was functionally stabilised and needed virtually zero support for a number of years we were struggling to see why. Once we looked at VTAM, and eliminated it, this led us to look at a number of other relatively high cost products that we have ways to eliminate, replace or reduce. I am not saying that we would not have looked at these anyway but the high cost of VTAM was the catalyst to start looking. Colin Allinson Amadeus Data Processing GmbH * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. *
Re: VTAM R.I.P.
VM/SP1 may have it beat. I remember the Vulture with the inscription VM/SP is waiting for you that Jim Bergsten created for it. We actually did not have much trouble with HPO4 at Piedmont Airlines. Compared to today's systems, it did have some stability issues; however, it was nowhere near as bad as SP1 or, for that matter, the earlier releases of VM. I remember some of the nightmares of the VM/370 Release 2 days. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Thursday, April 03, 2008 5:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. I was basing that on what an MVS sysprog told me. I will stand by my stmt, tho, that HPO 4 was the most unstable operating system release I've seen in 41+ years of working in this racket. Also that it was one of the shortest lived releases. Jim Alan Altmark wrote: On Wednesday, 04/02/2008 at 09:30 EDT, Jim Bohnsack [EMAIL PROTECTED] wrote: R4 was the release with native VTAM support. VTAM had been supported for a while with VS/1 or DOS/VS hosting VTAM but someone decided that GCS was the way to go. They took a gutted MVS/XA and quickly fitted it into VM. Nonsense. There is no more MVS/XA code in GCS than there is in CMS. Alan Altmark z/VM Development IBM Endicott -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: VTAM R.I.P.
None of those hold a candle to the shortly lived, thank God, VM/IS.
What an ill conceived, poorly implemented, piece-o-doodoo that was.
On Thu, Apr 3, 2008 at 12:18 PM, Schuh, Richard [EMAIL PROTECTED] wrote:
VM/SP1 may have it beat. I remember the Vulture with the inscription
VM/SP is waiting for you that Jim Bergsten created for it. We actually
did not have much trouble with HPO4 at Piedmont Airlines. Compared to
today's systems, it did have some stability issues; however, it was
nowhere near as bad as SP1 or, for that matter, the earlier releases of
VM. I remember some of the nightmares of the VM/370 Release 2 days.
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack
Sent: Thursday, April 03, 2008 5:13 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VTAM R.I.P.
I was basing that on what an MVS sysprog told me. I will
stand by my stmt, tho, that HPO 4 was the most unstable
operating system release I've seen in 41+ years of working in
this racket. Also that it was one of the shortest lived releases.
Jim
Alan Altmark wrote:
On Wednesday, 04/02/2008 at 09:30 EDT, Jim Bohnsack
[EMAIL PROTECTED]
wrote:
R4 was the release
with native VTAM support. VTAM had been supported for a
while with
VS/1 or DOS/VS hosting VTAM but someone decided that GCS
was the way
to go. They took a gutted MVS/XA and quickly fitted it into VM.
Nonsense. There is no more MVS/XA code in GCS than there is in CMS.
Alan Altmark
z/VM Development
IBM Endicott
--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]
--
Mark Pace
Mainline Information Systems
Re: VTAM R.I.P.
I second that. VM/IS R4 - module replacement only. No service available, a manager was supposed to be able to install it. And I've never seen it on a historical timeline of VM. - Dave Hansen Hennepin County Mark Pace [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc 04/03/2008 11:49 AM Subject Re: VTAM R.I.P. Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU None of those hold a candle to the shortly lived, thank God, VM/IS. What an ill conceived, poorly implemented, piece-o-doodoo that was. On Thu, Apr 3, 2008 at 12:18 PM, Schuh, Richard [EMAIL PROTECTED] wrote: VM/SP1 may have it beat. I remember the Vulture with the inscription VM/SP is waiting for you that Jim Bergsten created for it. We actually did not have much trouble with HPO4 at Piedmont Airlines. Compared to today's systems, it did have some stability issues; however, it was nowhere near as bad as SP1 or, for that matter, the earlier releases of VM. I remember some of the nightmares of the VM/370 Release 2 days. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Thursday, April 03, 2008 5:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. I was basing that on what an MVS sysprog told me. I will stand by my stmt, tho, that HPO 4 was the most unstable operating system release I've seen in 41+ years of working in this racket. Also that it was one of the shortest lived releases. Jim Alan Altmark wrote: On Wednesday, 04/02/2008 at 09:30 EDT, Jim Bohnsack [EMAIL PROTECTED] wrote: R4 was the release with native VTAM support. VTAM had been supported for a while with VS/1 or DOS/VS hosting VTAM but someone decided that GCS was the way to go. They took a gutted MVS/XA and quickly fitted it into VM. Nonsense. There is no more MVS/XA code in GCS than there is in CMS. Alan Altmark z/VM Development IBM Endicott -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED] -- Mark Pace Mainline Information Systems Disclaimer: Information in this message or an attachment may be government data and thereby subject to the Minnesota Government Data Practices Act, Minnesota Statutes, Chapter 13, may be subject to attorney-client or work product privilege, may be confidential, privileged, proprietary, or otherwise protected, and the unauthorized review, copying, retransmission, or other use or disclosure of the information is strictly prohibited. If you are not the intended recipient of this message, please immediately notify the sender of the transmission error and then promptly delete this message from your computer system.
Re: VTAM R.I.P.
My recollection of SP and HPO 4 are probably tainted by the fact that were ran ESP code until it shipped GA. As bad as the ESP was, I'm surprised IBM went GA with it and it was only a few months before HPO 4.3 was announced. Jim Schuh, Richard wrote: VM/SP1 may have it beat. I remember the Vulture with the inscription VM/SP is waiting for you that Jim Bergsten created for it. We actually did not have much trouble with HPO4 at Piedmont Airlines. Compared to today's systems, it did have some stability issues; however, it was nowhere near as bad as SP1 or, for that matter, the earlier releases of VM. I remember some of the nightmares of the VM/370 Release 2 days.=20 Regards,=20 Richard Schuh=20 =20 -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: VTAM R.I.P.
On Thursday, 04/03/2008 at 11:58 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Yeah, it was a gutted OS/360 MFT system. MVS/XA was not even a gleam in its daddy's eye. My unmade point: GCS was cloned from CMS as it existed in VM/SP 3. Additional code added to tighten file system security, support cross-virtual machine multitasking and to run applications in problem state is VM-written code. We did not import code from OS/360 MFT. I know this: I was there, writing the code for the GCS recovery machine, as well as working on DEB security in the OS simulation for READ, WRITE, POINT, GET, and PUT. Where the existing CMS MVS/SP (at the time) simulation was not sufficient to meet VTAM's and NetView's requirements, the GCS versions of those interfaces were updated with extra function. Alan Altmark z/VM Development IBM Endicott
Re: VTAM R.I.P.
Whilst I never had the luxury of working in the labs I did do a lot of work on implementing code on GCS. When SP4 came out I was working for the University of Salford who at the time, in conjunction with IBM UK, produced a package of software and hardware that allowed VM to be connected to an X.25 network. The software consisted of service machine that was basically an X.25 switch, and which talked to X.25 via a Series/1 on the channel, and to other virtual machines via IUCV. When GCS and VTAM came out we modified the service machine to run in GCS. Initially it still talked to the Series/1 via the channel cards, but we then modified it to talk to X.25 via VTAM and NPSI. Appart from a few minor changes to WAITCB code and copying the LINEDIT code from CMS we made virtually no changes to the code to get it running on GCS. I am pretty sure we had access to the GCS source, (on fiche perhaps, my memory starts to fail at this point) and it looked very like the equivalent CMS code. What I really don't understand is why they didn't put more of the enhanced OS Support back into the original CMS. That would have been really usefull Dave P.S. still no VM at work. Corrupt HMC disks -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: 03 April 2008 20:22 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. On Thursday, 04/03/2008 at 11:58 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Yeah, it was a gutted OS/360 MFT system. MVS/XA was not even a gleam in its daddy's eye. My unmade point: GCS was cloned from CMS as it existed in VM/SP 3. Additional code added to tighten file system security, support cross-virtual machine multitasking and to run applications in problem state is VM-written code. We did not import code from OS/360 MFT. I know this: I was there, writing the code for the GCS recovery machine, as well as working on DEB security in the OS simulation for READ, WRITE, POINT, GET, and PUT. Where the existing CMS MVS/SP (at the time) simulation was not sufficient to meet VTAM's and NetView's requirements, the GCS versions of those interfaces were updated with extra function. Alan Altmark z/VM Development IBM Endicott
Re: VTAM R.I.P.
With all the bad mouthing that poor old VTAM has been copping I will jump to its defence. Some of the most interesting things I got to play with were due to it and GCS. First off we modified our OS/PLI 2.3 source code and added some function to GCS such that we could write apps in proper multi-tasking PL/I. We created some VTAM support routines and we were able to create a system that allowed us to switch messages from our VSE systems to our Series/1 (yes we had these babies too). When we phased out the Series/1s, which were responsible for talking an async protocol to the racecourses around the state to combine pools, we used the DATE support of NPSI to bring that function into a virtual machine. I used to talk to VMSHARE using another GATE-based NPSI application. All this was written in PL/I and served us for years and made the company a lot of money. Now as far as the joys of NCP generation and VTAM topologies, and SNA protocols in general yes I am happy to live without them now. It reminds me of an ancient joke: John Akers answers the phone: Hello Caller: John Akers? JA: Yes. Caller: John Akers of IBM? JA: Yes. Caller: John Akers of IBM, White Plains? JA: Yes! Caller: John Akers of IBM, White Plains, NY, USA? JA: Yes, WTF do you want!!! Caller: Just wanted to let you know how it feels to set up an SNA session.
Re: VTAM R.I.P.
On Thursday, 04/03/2008 at 04:58 EDT, Dave Wade [EMAIL PROTECTED] wrote: Whilst I never had the luxury of working in the labs I did do a lot of work on implementing code on GCS. When SP4 came out I was working for the University of Salford who at the time, in conjunction with IBM UK, produced a package of software and hardware that allowed VM to be connected to an X.25 network. The software consisted of service machine that was basically an X.25 switch, and which talked to X.25 via a Series/1 on the channel, and to other virtual machines via IUCV. When GCS and VTAM came out we modified the service machine to run in GCS. Initially it still talked to the Series/1 via the channel cards, but we then modified it to talk to X.25 via VTAM and NPSI. z/VM 5.3 is the end of the line for X25IPI, the SNA X.25 NPSI device driver for VM TCP/IP. Alan Altmark z/VM Development IBM Endicott
Re: VTAM R.I.P.
I am not sure that you were defending VTAM. All of the interesting things that you did were done to overcome deficiencies. That seems quite the opposite of a defense. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Neale Ferguson Sent: Thursday, April 03, 2008 2:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. With all the bad mouthing that poor old VTAM has been copping I will jump to its defence. Some of the most interesting things I got to play with were due to it and GCS. First off we modified our OS/PLI 2.3 source code and added some function to GCS such that we could write apps in proper multi-tasking PL/I. We created some VTAM support routines and we were able to create a system that allowed us to switch messages from our VSE systems to our Series/1 (yes we had these babies too). When we phased out the Series/1s, which were responsible for talking an async protocol to the racecourses around the state to combine pools, we used the DATE support of NPSI to bring that function into a virtual machine. I used to talk to VMSHARE using another GATE-based NPSI application. All this was written in PL/I and served us for years and made the company a lot of money. Now as far as the joys of NCP generation and VTAM topologies, and SNA protocols in general yes I am happy to live without them now. It reminds me of an ancient joke: John Akers answers the phone: Hello Caller: John Akers? JA: Yes. Caller: John Akers of IBM? JA: Yes. Caller: John Akers of IBM, White Plains? JA: Yes! Caller: John Akers of IBM, White Plains, NY, USA? JA: Yes, WTF do you want!!! Caller: Just wanted to let you know how it feels to set up an SNA session.
Re: VTAM R.I.P.
Our management came up with: Per MIP Cost Analysis Environment Onetime Ongoing z/OS$7,300 $1,980 z/Linux $447$61 Of course, this does not include the cost of any Velocity Software products on z/VM :) -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, April 03, 2008 12:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. Gee, next it will be the high cost of z/OS that you will be looking at. How much do you save if you move an application from z/OS to z/Linux? Colin Allinson wrote: Rob van der Heij [EMAIL PROTECTED] wrote :- Z NET,QUICK Couldn't be 'QUICK' enough for us. We managed to eliminate it from VM by the middle of last year. We went back to using basic mode CTC connections to z/OS until they got themselves up to 1.7 with the ability to use TCPNJE. The interesting thing was that it was the huge cost of VTAM that was the main motivation for us. Given that the product was functionally stabilised and needed virtually zero support for a number of years we were struggling to see why. Once we looked at VTAM, and eliminated it, this led us to look at a number of other relatively high cost products that we have ways to eliminate, replace or reduce. I am not saying that we would not have looked at these anyway but the high cost of VTAM was the catalyst to start looking. Colin Allinson Amadeus Data Processing GmbH This email is intended for the recipient only. If you are not the intended recipient please disregard, and do not use the information for any purpose.
Re: VTAM R.I.P.
What type of things are you still using it for? On 4/3/08 5:52 PM, Burch, Aubrey Dennis CIV DISA GS4B [EMAIL PROTECTED] wrote: Coincidentally, our contracting office called me today because we are planning to expand our VTAM license to an IFL LPAR. It appears VTAM is available for IFLs only via special pricing.
Re: VTAM R.I.P.
WOW, I really had no idea it would be this significant. No wonder IBM sales people don't sell Linux to replace z/OS. So conservatively, 90% reduction in costs for any application that moves? So about 5 mips (a p390 worth) would pay for any Velocity costs? Amazing. Said, Nick wrote: Our management came up with: Per MIP Cost Analysis Environment Onetime Ongoing z/OS $7,300 $1,980 z/Linux $447 $61 Of course, this does not include the cost of any Velocity Software products on z/VM :) -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, April 03, 2008 12:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. Gee, next it will be the high cost of z/OS that you will be looking at. How much do you save if you move an application from z/OS to z/Linux? Colin Allinson wrote: Rob van der Heij [EMAIL PROTECTED] wrote :- Z NET,QUICK Couldn't be 'QUICK' enough for us. We managed to eliminate it from VM by the middle of last year. We went back to using basic mode CTC connections to z/OS until they got themselves up to 1.7 with the ability to use TCPNJE. The interesting thing was that it was the huge cost of VTAM that was the main motivation for us. Given that the product was functionally stabilised and needed virtually zero support for a number of years we were struggling to see why. Once we looked at VTAM, and eliminated it, this led us to look at a number of other relatively high cost products that we have ways to eliminate, replace or reduce. I am not saying that we would not have looked at these anyway but the high cost of VTAM was the catalyst to start looking. Colin Allinson Amadeus Data Processing GmbH This email is intended for the recipient only. If you are not the intended recipient please disregard, and do not use the information for any purpose.
Re: VTAM R.I.P.
You certainly will not get any of the updates and enhancements that z/OS gets. The push here, not a very hard push, was to create a Linux instance that runs Comm. Server. It was easier and cheaper to convert our TPX users to TN3270 and our NJE links to TCPNJE. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Neale Ferguson Sent: Thursday, April 03, 2008 2:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. What type of things are you still using it for? On 4/3/08 5:52 PM, Burch, Aubrey Dennis CIV DISA GS4B [EMAIL PROTECTED] wrote: Coincidentally, our contracting office called me today because we are planning to expand our VTAM license to an IFL LPAR. It appears VTAM is available for IFLs only via special pricing.
Re: VTAM R.I.P.
We have an elaborate remote logon architecture that requires VTAM for logins. It was designed with our dozens of z/OS LPARs in mind, and is the only *security-approved* logon access method for z/OS and z/VM. Telnet, even SSL, is no longer allowed in and out of our networks due to DOD port restrictions. I also use VTAM for SNANJE connections since I have it (along with the RSCS Communications feature). Denny -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Neale Ferguson Sent: Thursday, April 03, 2008 17:55 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. What type of things are you still using it for? On 4/3/08 5:52 PM, Burch, Aubrey Dennis CIV DISA GS4B [EMAIL PROTECTED] wrote: Coincidentally, our contracting office called me today because we are planning to expand our VTAM license to an IFL LPAR. It appears VTAM is available for IFLs only via special pricing.
VTAM R.I.P.
At 23:55 GMT on Monday, March 31, VTAM was removed from our VM system. May it rest in peace (as it has been doing since 1995). One more cash cow bites the dust. The only remnant left will be one of the large, old manuals. It is the perfect weight to silence the vibrations in the case of the Dell GX620 that sits on my desk. When the GX620 is replaced in about a year, I hope that even that manual can be put to rest. Regards, Richard Schuh
Re: VTAM R.I.P.
On Wednesday, 04/02/2008 at 03:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: At 23:55 GMT on Monday, March 31, VTAM was removed from our VM system. May it rest in peace (as it has been doing since 1995). One more cash cow bites the dust. (head bowed...silent...I sure am gonna miss that cow...(sniff)...I sooo wanted to buy a new car this year with my share of the license fees) Alan Altmark z/VM Development IBM Endicott
Re: VTAM R.I.P.
Z NET,QUICK
Re: VTAM R.I.P.
VM/VTAM was an MVS product shoe-horned (with some pretty clever work) into VM. Wouldn't the appropriate VM and MVS-ish command be: Z NET,EOD Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Rob van der Heij [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 04/02/2008 05:13 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: VTAM R.I.P. Z NET,QUICK The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: VTAM R.I.P.
Why bother? It was going away for good. Actually, I had a VTAM (MVS) expert in the office when I laid the tired old thing to rest. He couldn't remember the command and neither did I, so #CP LOGOFF is what I used :-) I had already removed any trace of VTAM from our service machine list, so there was no chance of it being resuscitated before I could tell VM:Secure to get it out of the directory. The strange thing is that even though there were 60 people accessing the system via TPX Monday morning and there were frequently as many as 150 concurrent TPXers in the weeks leading up to the decommissioning ceremony, I have been contacted by only 4 people who apparently could not click on the link to a document giving step-by-step, screenshot-by-screenshot, instructions on how to set up a TN3270 emulator session that would connect to VM. I expected the number to be more in line with the number who try to reply to mail that starts with Do not reply to this email ..., a much higher number. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, April 02, 2008 3:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. VM/VTAM was an MVS product shoe-horned (with some pretty clever work) into VM. Wouldn't the appropriate VM and MVS-ish command be: Z NET,EOD Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Rob van der Heij [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 04/02/2008 05:13 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: VTAM R.I.P. Z NET,QUICK The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: VTAM R.I.P.
We still have it here, but I suspect that it is not long lived. Some of my worst memories involve VTAM on VM. I was the VM team leader for the IBM Education support center in Dallas in 1985 and told my manager and my 2nd level that we should get VM/SP R4 for the remote locations we suppported and HPO R4 for the central site 3081's. R4 was the release with native VTAM support. VTAM had been supported for a while with VS/1 or DOS/VS hosting VTAM but someone decided that GCS was the way to go. They took a gutted MVS/XA and quickly fitted it into VM. I don't remember that GCS abended all the time, but CP certainly did. VM/SP R4, with and without HPO was an absolute disaster. If we went thru a day without a CP abend, we celebrated. R4 was probably the shortest lived VM release ever. I think it went GA in December of 1985 and was replaced with VM/SP 4.3 in about March. It was a great improvement. During the fall of '85, Barton Robinson practically lived with us being the expert from the East sent to help us. I remember the arguments inside IBM regarding VTAM vs. TCPIP. IBM was going to be pure VTAM. It's too bad that internal IBM was so stuck on SNA and VTAM that there could not have been an earlier combination of the two disciplines. Jim Schuh, Richard wrote: This is a multi-part message in MIME format. --_=_NextPart_001_01C894F4.805C40E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable At 23:55 GMT on Monday, March 31, VTAM was removed from our VM system. May it rest in peace (as it has been doing since 1995). One more cash cow bites the dust. The only remnant left will be one of the large, old manuals. It is the perfect weight to silence the vibrations in the case of the Dell GX620 that sits on my desk. When the GX620 is replaced in about a year, I hope that even that manual can be put to rest.=20 Regards,=20 Richard Schuh=20 --_=_NextPart_001_01C894F4.805C40E4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN HTML HEAD META HTTP-EQUIV=3DContent-Type CONTENT=3Dtext/html; = charset=3Dus-ascii META NAME=3DGenerator CONTENT=3DMS Exchange Server version = 6.5.7652.24 TITLEVTAM R.I.P./TITLE /HEAD BODY !-- Converted from text/rtf format -- PFONT SIZE=3D2 FACE=3DArialAt 23:55 GMT on Monday, March 31, VTAM = was removed from our VM system. May it rest in peace (as it has been = doing since 1995). One more cash cow bites the dust./FONT/P PFONT SIZE=3D2 FACE=3DArialThe only remnant left will be one of = the large, old manuals. It is the perfect weight to silence the = vibrations in the case of the Dell GX620 that sits on my desk. When the = GX620 is replaced in about a year, I hope that even that manual can be = put to rest. /FONT/P PFONT FACE=3DArialRegards,BR Richard Schuh /FONT /P BR /BODY /HTML --_=_NextPart_001_01C894F4.805C40E4-- -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: VTAM R.I.P.
On Wednesday, 04/02/2008 at 09:30 EDT, Jim Bohnsack [EMAIL PROTECTED] wrote: R4 was the release with native VTAM support. VTAM had been supported for a while with VS/1 or DOS/VS hosting VTAM but someone decided that GCS was the way to go. They took a gutted MVS/XA and quickly fitted it into VM. Nonsense. There is no more MVS/XA code in GCS than there is in CMS. Alan Altmark z/VM Development IBM Endicott
