Re: Application development paradigms [was: RE: Learning Rexx]
paulgboul...@aim.com (Paul Gilmartin) writes: Are you suggesting that I, as a Class G user, can build and deploy a DVM, no sysprog intervention? re: http://www.garilc.com/~lynn/2014.html#1 Application development paradigms [was: RE: Learning Rexx] that is exactly how the rexx author started out with his multi-user client/server spacewar game. however you typically had to talk to sysadmin if you wanted it automatically brought up at system started up ... rather than manually. I had originally done the autolog command was part of automated benchmarking ... build new system, setup autolog script, reboot to the new kernel, autolog all simulated users, when done, again reboot the system run the next set of simulated user benchmark ... all automatically ... could get through several hundred if I had enough dedicated machine time. misc. past posts discussing automated benchmarking http://www.garlic.com/~lynn/submain.html#benchmark cp67 had done automatic reboot as part expanded service into 7x24 ... and running dark room in the 60s. however, as service virtual machines proliferated ... a lot of services required somebody manually to bring up the increasing numbers of different service virtual machines. my autolog function was quickly adapted to automatically bringing up all the service virtual machines at boot ... it was another thing that I included in my csc/vm system distribution for internal datacenters. http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 during the future system period ... lots of 370 stuff was being suspended and/or shutdown http://www.garlic.com/~lynn/submain.html#futuresys during the FS period I continued to work on 360/370 ... even periodically critidizing the FS activity (which was exactly a career enhancing activity). When FS failed, there was mad rush to get stuff back into 370 product pipelines. That contributed to picking up some of the stuff I had been doing all along and shipping in standard product. The autolog command was one of the things picked up for VM370 release 3 shipping to customers, as part of helping manage service virtual machines. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
peter.far...@broadridge.com (Farley, Peter x23353) writes: PMFJI here, but IMHO the pipeline paradigm, though obviously powerful and useful, is not the major advantage of VM and CMS over z/OS and TSO for developers, Rexx or otherwise. Rather, I would argue that it is the even more the powerful concept of DVM's, Disconnected Virtual Machines, and the resulting ability for even ordinary application developers, not just sysprogs, to very simply arrange to pass data between them via VMCF and/or IUCV. Then add the power of VM Rexx and pipeline support and XEDIT and the other CMS tools as the only code needed to actually run in and interact with those DVM's and many extremely useful and powerful applications can be coded with nary a compiler or assembler in sight, never mind in use. No authorized coding or cross-memory complexity required. Add DB2 and networking support for Rexx and many full-function business applications are added to the possibilities. I bemoan the failure decades ago of the CMS on MVS project. That would, indeed, have changed the history and practice of our computing lives. I recently mentioned pipelines and doing internal adtech conference in spring 1982. http://www.garlic.com/~lynn/2013o.html#91 Learning Rexx there was also a presentation on CMS running on MVS. A couple yrs earlier, Endicott had gotten the corporation to announce that vm370/cms was the strategic online, interactive solution. The TSO product administrator had contacted me if I would redo the dispatcher/scheduler for MVS ... attempting to make MVS much more interactive friendly. I declined since the MVS problems with good interactive human factors went way beyond its dispatchingscheduling. old email ref. http://www.garlic.com/~lynn/2006b.html#email800310 This then further came out in the CMS under MVS work ... they could get it to run functionally ... but because of all the other problems, the question then was why this talks about the internal SPM ... which was superset of VMCF, IUCV SMSG combined ... originally done at Pisa Science Center for cp67 but then moved to vm370. http://www.garlic.co/~lynn/2006k.html#email851017 in this post http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history also http://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history) http://www.garlic.com/~lynn/2007.html#11 vm/sp1 I included it in my internal csc/vm system distribution (for internal datacenters). http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 Original service virtual machine was RSCS ... and as referenced, the later RSCS that eventually shipped to customers ... included SPM support (even if SPM didn't ship to customers). The author of REXX did a multi-user client/server spacewar game that used SMSG (users could be on the same machine with the server ... or because of the RSCS support ... could be anywhere on the internal network). The client had a 3270 GUI ... however the client/server protocol was very straight-forward and rather quickly several people did spacewar bots ... that started to trample all the human players (in part because they moved much faster). The spacewar server was eventually modified to increase the power use non-linearly as the interval between commands/moves dropped ... as a way of trying to provide a level playing field between humans and bots. this is increasingly becoming common in the current virtual machine world ... it has morphed into virtual appliances ... highly customized operating system applications running in service virtual machine ... very much like RSCS. trivia ... some years ago, the author of RSCS was working for company doing some realtime stuff with a major industry realtime system. He eventually realized that the core part of the system appeared similar to parts of RSCS ... with major core RSCS 360 assmbler translated into C language ... but preserving all the same comments. ... and some psuedo device trivia PROFS email (used extensively internal, among customers, and even involved in the white house iran contra affair) used a very early version of an internally developed email client called VMSG. When the VMSG author tried to offer them an updated version ... they tried to get him fired (because they had claimed credit for everything in PROFS). They whole thing quieted down when the VMSG author showed then every PROFS email in the world carried his initials in a non-displayed, control field. After than the VMSG author restricted source distribution to only two other people. The VMSG author also did PARASITE/STORY ... CMS application and HLLAPI like language (in the 70s, predating IBM/PC) for automated scripts for simulating terminals on the same machine or other machines in the internal network (using psuedo device interface). Past post with PARASITE/STORY details: http://www.garlic.com/~lynn/2001k.html#35 ... includes a story for automatically
Re: Application development paradigms [was: RE: Learning Rexx]
re: http://www.garlic.com/~lynn/2014.html#1 Application development paradigms [was: RE: Learning Rexx] http://www.garlic.com/~lynn/2014.html#2 Application development paradigms [was: RE: Learning Rexx] another thing in the wake of FS failure http://www.garlic.com/~lynn/submain.html#futuresys and the mad rush to get stuff back into the 370 product pipelines (during FS, there were being terminated and/or suspended, which is also credited with giving the clone processor makers a market foothold) ... was the head of POK convinced corporate to kill vm370 product and shutdown the VM370 burlington mall development group and move all the people to POK (or otherwise mvs/xa wouldn't ship on time, endicott finally did manage to resurrect the vm370 product mission ... but had to reconstitute a development group from scratch). at the time, somebody in the CMS group had extensively extended the os/360 simulation ... which managed to all get lost in the burlington mall shutdown. the standard CMS OS/360 had fit in less than 64kbytes ... some joke that CMS OS/360 simulation was much better price/performance than the 8mbyte MVS OS/360 simulation. the plan was to not inform the vm370/cms development people until the very last minute (to minimize the people that might escape) ... but it managed to leak early ... and lots of people left IBM and stayed in the Boston area ... in fact there was joke that the head of POK was one of the major contributors to VAX/VMS since so many people left for DEC (including the person that did the major extension in os/360 simulation). later there was some internal IBM significant extensions to os/360 simulation. There were a number of major chip, hardware, and microcode development applications that only ran on MVS. However, some of the internal datacenters were starting to burst at the seams ... even with all the 168s upgraded to 3033s. This was major rise of 4300 machines ... the corporation was installing 4300s out in every departmental supply and/or conference rooms (4300s taking over conference rooms, turned conference rooms into scarce commodity) ... sort of the leading edge of the distributed computing tsunami. for large list of reasons, it wasn't practical to deploy MVS on all the machines (MVS required enormously larger people support, nearly all of them were with FBA disks which MVS doesn't support, MVS consumed much larger percentage of these smaller systems, leaving less to productive work, etc). Some number of internal installations ... extended the CMS OS/360 simulation in order to be able to move these major development applications out onto these distributed vm/4341s. some old 4300 email from the period ... including discussion of extending os/360 simulation (to be able to migrate lots of the MVS workload out into distributed vm/4300s) http://www.garlic.com/~lynn/lhwemail.html#43xx the significant increase in vm/4300s also was major factor in the internal network passing 1000 nodes in summer 1983 ... past post with several '83 internal network references (including list of all corporate locations that added one or more network nodes in 1983) http://www.garlic.com/~lynn/2006k.html#8 past posts mentioning internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
Peter: Your mention of CMS on MVS brings back memories. Karl Finkemeyer and I were picked as the technical team leaders for the two teams that were to actually develop it. We had begun staffing our teams when the project was killed (that was about 1982, as I recall). We had been two of the programmers that had implemented the prototype proving it would work. My part in the prototype was putting the CMS file system in MVS, which was done using VSAM linear data sets and control interval access. Those of you who are big VM fans should be happy the project was killed, as our intention was to make VM unnecessary. We saw the advantages of VM to be the CMS development environment and the ability to run multiple systems side-by-side in the same machine. If you could run CMS in all its glory in MVS and run multiple systems in the same machine with PR/SM (Karl's prototype when he was at the Heidelberg Scientific Center - I believe it was called the Multi-System Mapper - demonstrated the feasibility of LPARs and PR/SM, although we had not named it that yet). Had we been successful, VM might not be an IBM product today (although Gene Amdahl swore he would take and develop it if IBM gave it up). Mike Myers Mentor Services Corporation On 01/01/2014 02:23 PM, Farley, Peter x23353 wrote: PMFJI here, but IMHO the pipeline paradigm, though obviously powerful and useful, is not the major advantage of VM and CMS over z/OS and TSO for developers, Rexx or otherwise. Rather, I would argue that it is the even more the powerful concept of DVM's, Disconnected Virtual Machines, and the resulting ability for even ordinary application developers, not just sysprogs, to very simply arrange to pass data between them via VMCF and/or IUCV. Then add the power of VM Rexx and pipeline support and XEDIT and the other CMS tools as the only code needed to actually run in and interact with those DVM's and many extremely useful and powerful applications can be coded with nary a compiler or assembler in sight, never mind in use. No authorized coding or cross-memory complexity required. Add DB2 and networking support for Rexx and many full-function business applications are added to the possibilities. I bemoan the failure decades ago of the CMS on MVS project. That would, indeed, have changed the history and practice of our computing lives. And a Happy New Year to all. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Sunday, December 29, 2013 11:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Learning Rexx On 29/12/2013 1:07 AM, Paul Gilmartin wrote: On 2013-12-28, at 09:47, Charles Mills wrote: Actually CMS on VM better for rexx than z/OS. Why? (Risking an advocacy thread.) For me, one reason is the CMS HELP facility. In fact, sometimes coding Rexx for z/OS I'll log on to CMS merely to use HELP REXX instruction. Other reasons? Most VMers claim that Rexx is superior on VM because of CMS pipes. That's a pretty strong argument. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
Gerard Schildberger gerar...@rrt.net writes: I would'nt bemoan it. I tried using CMS under TSO (or under MVS, I don't remember), but the response time was lousy (actually, bad lousy) and the functionality wasn't there. Too many restrictions. The same thing kinda happened when the MVS folks said they could support PROFS (Office Vision) better under MVS/TSO than VM/CMS. Boy, was that painful to watch. They got it running for a few dozen users, but when they tried to scale it up to 8,500 (logged on) users, it was choke city. Never even came close getting that many UIDs logged on. I remember when OS/VS2 would crash when getting close to 512 address spaces. Does anybody know when that threshold was lifted? Or is there a new threshold? We had half of an Amdahl V7 (I think that was model) running VM with over 10,400 logged on users/SVMs. The average was at least 9k. The other half of the Amdahl were three more VMs, each had a goodly-sized PROFs system, not to mention PVM (Pass-thru) to the whole company, as well as hosting all the RSCS/net traffic. Gerard Schildberger re: http://www.garlic.com/~lynn/2014.html#1 Application development paradigms [was: RE: Learning Rexx] http://www.garlic.com/~lynn/2014.html#2 Application development paradigms [was: RE: Learning Rexx] http://www.garlic.com/~lynn/2014.html#4 Application development paradigms [was: RE: Learning Rexx] the 23jun1969 unbundle announcement started charging for application software (they managed to make the case that operating system/kernel software would still be free), SE services, and other stuff ... some past posts http://www.garlic.com/~lynn/submain.html#unbundle they had a issue about hands-on training for new SEs ... which previously had occurred as part of teams at the customer accout (couldn't figure out how not to charge for new SEs if they were on site) ... and came up with providing running operating systems in cp67 virtual machines at branch offices ... i.e. HONE system (hands-on network environment) ... some past posts http://www.garlic.com/~lynn/subtopic.html#hone the cambridge science center ... some past posts http://www.garlic.com/~lynn/subtopic.html#545tech had also ported apl\360 to cp67/cms for cms\apl ... mostly required eliminating unnecessary stuff ... like its internal multi-tasking and swapping (to avoid high overhead os/360 services) ... recent discussion http://www.garlic.com/~lynn/2013o.html#54 Curiosity: TCB mapping macro name - why IKJTCB? but its storage management was oriented to 16kbyte workspaces that were swapped as single unit ... which had to be redone for large virtual memory, demand paged environment ... as well as adding API for CMS system services (combination allowing implementation of large real world applications). The HONE group then started deploying apl-based salesmarketing support applications also on HONE ... which came to dominate all HONE activity and the virtual guest operation use withered away. The palo alto science center then did the apl\cms for vm370/cms ... as well as the 370/145 apl microcode assist. As previously mentioned they had also done the 5100 apl work http://www.garlic.com/~lynn/2013o.html#82 One day, a computer will fit on a desk (1974) - YouTube in the mid-70s, the US HONE datacenters were consolidated in a bldg across the back parking lot from the palo alto science center (later a new bldg. went next door for facebook ... before they bought and moved into the old sun campus). For the heavy computation APL workload, machines were large mainframe SMP configured in loosely-coupled operation ... with single-system-image load-balancing and availability fallover (largest single-system-image operation in the world at the time). The single-system-image was then expanded to cover a 2nd datacenter in dallas and then a 3rd datacenter in boulder. Note that this support didn't appear in the customer product until a couple yrs ago: http://www.garlic.com/~lynn/2009p.html#43 From The Annals of Release No Software Before Its Time http://www.garlic.com/~lynn/2009p.html#46 From The Annals of Release No Software Before Its Time HONE was one of my long-time enhanced operating system customers from original cp67 systems ... even in the early days, they asked me to assist with various installations as HONE clones started popping up around the world. Old email reference to csc/vm http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 Pretty much from mid-70s through the 80s, there was re-occurring case of a branch manager being promoted to head of business group that contained HONE and be horrified to find that it ran on vm370 (not MVS). He would then direct the HONE group to move HONE to MVS ... which would take nearly all the HONE resources for 12m-18m ... until it was proven to not be possible ... and then things would settle down for a couple months until
Re: Application development paradigms [was: RE: Learning Rexx]
On Thu, 2 Jan 2014 11:49:40 -0500, Anne Lynn Wheeler wrote: Gerard Schildberger writes: [must have come via BITNET] OS/VS2 would crash when getting close to 512 address spaces. Does anybody know when that threshold was lifted? Or is there a new threshold? There's always a threshold; it might not be a practical limitation. Control blocks; address spaces; swapping space; ... An Old Timer once told me of LOADing a module 257 times, then DELETEing it once. Crash. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
On Thu, 2 Jan 2014 09:30:19 -0500, Anne Lynn Wheeler wrote: (Paul Gilmartin) writes: Are you suggesting that I, as a Class G user, can build and deploy a DVM, no sysprog intervention? that is exactly how the rexx author started out with his multi-user client/server spacewar game. however you typically had to talk to sysadmin if you wanted it automatically brought up at system started up ... rather than manually. I would think you'd first need sysadmin to DEFINE the service machine. Isn't that a directory update, beyond the entitlement of a Class G user? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
Well, you are right about that -- defining VM user id's and facilities is a sysprog function requiring a directory update, not permitted to Class G users. But I have been in a shop that implemented an automated system for VM user definition, within certain parameters controlled by the sysprogs. In that environment, it was possible to request and get new VM's defined without human intervention unless a controlled privilege authority was requested. However, the programming and testing of the code running in DVM's (or SVM's, Service Virtual Machines, as they have also been named) was and is possible to be accomplished by Class G users. That is the sense in which I made that statement. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, January 01, 2014 4:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Application development paradigms [was: RE: Learning Rexx] On Wed, 1 Jan 2014 14:23:58 -0500, Farley, Peter x23353 wrote: Rather, I would argue that it is the even more the powerful concept of DVM's, Disconnected Virtual Machines, and the resulting ability for even ordinary application developers, not just sysprogs, ... Are you suggesting that I, as a Class G user, can build and deploy a DVM, no sysprog intervention? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
Thanks for the history Mike. I would indeed have truly bemoaned the loss of VM had that happened. Being lodged in strictly MVS and z/OS shops for many years without access to VM and CMS at all I just plain miss it. Though I suspect with all the changes since my last experiences I would be a babe in the woods again with current z/VM releases. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Myers Sent: Thursday, January 02, 2014 10:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Application development paradigms [was: RE: Learning Rexx] Peter: Your mention of CMS on MVS brings back memories. Karl Finkemeyer and I were picked as the technical team leaders for the two teams that were to actually develop it. We had begun staffing our teams when the project was killed (that was about 1982, as I recall). We had been two of the programmers that had implemented the prototype proving it would work. My part in the prototype was putting the CMS file system in MVS, which was done using VSAM linear data sets and control interval access. Those of you who are big VM fans should be happy the project was killed, as our intention was to make VM unnecessary. We saw the advantages of VM to be the CMS development environment and the ability to run multiple systems side-by-side in the same machine. If you could run CMS in all its glory in MVS and run multiple systems in the same machine with PR/SM (Karl's prototype when he was at the Heidelberg Scientific Center - I believe it was called the Multi-System Mapper - demonstrated the feasibility of LPARs and PR/SM, although we had not named it that yet). Had we been successful, VM might not be an IBM product today (although Gene Amdahl swore he would take and develop it if IBM gave it up). Mike Myers Mentor Services Corporation On 01/01/2014 02:23 PM, Farley, Peter x23353 wrote: PMFJI here, but IMHO the pipeline paradigm, though obviously powerful and useful, is not the major advantage of VM and CMS over z/OS and TSO for developers, Rexx or otherwise. Rather, I would argue that it is the even more the powerful concept of DVM's, Disconnected Virtual Machines, and the resulting ability for even ordinary application developers, not just sysprogs, to very simply arrange to pass data between them via VMCF and/or IUCV. Then add the power of VM Rexx and pipeline support and XEDIT and the other CMS tools as the only code needed to actually run in and interact with those DVM's and many extremely useful and powerful applications can be coded with nary a compiler or assembler in sight, never mind in use. No authorized coding or cross-memory complexity required. Add DB2 and networking support for Rexx and many full-function business applications are added to the possibilities. I bemoan the failure decades ago of the CMS on MVS project. That would, indeed, have changed the history and practice of our computing lives. And a Happy New Year to all. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Sunday, December 29, 2013 11:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Learning Rexx On 29/12/2013 1:07 AM, Paul Gilmartin wrote: On 2013-12-28, at 09:47, Charles Mills wrote: Actually CMS on VM better for rexx than z/OS. Why? (Risking an advocacy thread.) For me, one reason is the CMS HELP facility. In fact, sometimes coding Rexx for z/OS I'll log on to CMS merely to use HELP REXX instruction. Other reasons? Most VMers claim that Rexx is superior on VM because of CMS pipes. That's a pretty strong argument. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
On Thu, Jan 2, 2014 at 12:29 PM, Farley, Peter x23353 peter.far...@broadridge.com wrote: Thanks for the history Mike. I would indeed have truly bemoaned the loss of VM had that happened. Being lodged in strictly MVS and z/OS shops for many years without access to VM and CMS at all I just plain miss it. Though I suspect with all the changes since my last experiences I would be a babe in the woods again with current z/VM releases. Peter Another lack if VM had been killed would be IBM's Linux on System z. I cannot imagine z/Linux running in an LPAR. I doubt that IBM would have put the effort into the port at all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
paulgboul...@aim.com (Paul Gilmartin) writes: I would think you'd first need sysadmin to DEFINE the service machine. Isn't that a directory update, beyond the entitlement of a Class G user? re: http://www.garlic.com/~lynn/2014.html#1 Application development paradigms [was: RE: Learning Rexx] http://www.garlic.com/~lynn/2014.html#2 Application development paradigms [was: RE: Learning Rexx] http://www.garlic.com/~lynn/2014.html#4 Application development paradigms [was: RE: Learning Rexx] http://www.garlic.com/~lynn/2014.html#5 Application development paradigms [was: RE: Learning Rexx] you started out just running/testing it in your own virtual machine ... it wasn't until later when you wanted to do something more production and wanted a separate virtual machine. as aside, my same adtech conference that had presentations on precursor to pipelines and cms under mvs http://www.garlic.com/~lynn/2013o.html#91 Learning Rexx ... also had talk on modifications for vm370 for BSD unix ... including being able to spawn independent (vm370) virtual address spaces that ran independently ... aka the same userid could have multiple independently running virtual address spaces ... much more like unix. This would have made it possible to spawn a service virtual address space ... without requiring a separate userid for every address space. however, before this shipped the group was redirected to do BSD unix for the pc/rt ... which did ship as AOS. the later unix offerings were self-contained unix implementations that ran in single virtual machine virtual address space (not needing vm370 support for multiple independently running virtual address spaces). aix/370 was a port of UCLA Locus ... for 370 (along with companion part for aix/386) ... Locus had very sophisticated distributed computing support ... with executing application being able to non-disruptbly migrate between different machines in the network ... with some caveats even between different machine architectures ... aka between aix/386 and aix/370. one of the claims for aix/370 (and other unixes) running under vm370 ... rather on the bare machine ... was that field support required mainframe RAS EREP to support the real machine ... and the effort to add such support to native unix was several times larger than the effort to do the straight forward port. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
On Thu, 2 Jan 2014 12:32:58 -0600, John McKown wrote: On Thu, Jan 2, 2014 at 12:29 PM, Farley, Peter x23353 wrote: Thanks for the history Mike. I would indeed have truly bemoaned the loss of VM had that happened. Being lodged in strictly MVS and z/OS shops for many years without access to VM and CMS at all I just plain miss it. Another lack if VM had been killed would be IBM's Linux on System z. I cannot imagine z/Linux running in an LPAR. I doubt that IBM would have put the effort into the port at all. I believe we run a few of our test systems in LPARs; many more as VM guests. Aren't there limits on number of LPARs that don't apply to VM guests? And doesn't even a quiescent system in an LPAR bogart real storage? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
Peter: You're quite welcome. You have to realize that we were members of the MVS design group in Po'k at the time. I won't say MVS bigot though, as my last 2 years in IBM were spent in the VM design group in Kingston, NY. Like you, my VM experience had been a long dry spell until recently. My first 3 consulting assignments after leaving IBM in 1984 were in mixed (VM, MVS, DOS) environments, but after about 20 years away from VM, I am finally back on an assignment where z/OS runs strictly as a guest of zVM. And, you're right, a lot has changed, but not surprisingly, a lot remains the same (which is probably why those old experiences in OS/360 and VM/XA still come in handy today). Mike On 01/02/2014 01:29 PM, Farley, Peter x23353 wrote: Thanks for the history Mike. I would indeed have truly bemoaned the loss of VM had that happened. Being lodged in strictly MVS and z/OS shops for many years without access to VM and CMS at all I just plain miss it. Though I suspect with all the changes since my last experiences I would be a babe in the woods again with current z/VM releases. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Myers Sent: Thursday, January 02, 2014 10:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Application development paradigms [was: RE: Learning Rexx] Peter: Your mention of CMS on MVS brings back memories. Karl Finkemeyer and I were picked as the technical team leaders for the two teams that were to actually develop it. We had begun staffing our teams when the project was killed (that was about 1982, as I recall). We had been two of the programmers that had implemented the prototype proving it would work. My part in the prototype was putting the CMS file system in MVS, which was done using VSAM linear data sets and control interval access. Those of you who are big VM fans should be happy the project was killed, as our intention was to make VM unnecessary. We saw the advantages of VM to be the CMS development environment and the ability to run multiple systems side-by-side in the same machine. If you could run CMS in all its glory in MVS and run multiple systems in the same machine with PR/SM (Karl's prototype when he was at the Heidelberg Scientific Center - I believe it was called the Multi-System Mapper - demonstrated the feasibility of LPARs and PR/SM, although we had not named it that yet). Had we been successful, VM might not be an IBM product today (although Gene Amdahl swore he would take and develop it if IBM gave it up). Mike Myers Mentor Services Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Application development paradigms [was: RE: Learning Rexx]
PMFJI here, but IMHO the pipeline paradigm, though obviously powerful and useful, is not the major advantage of VM and CMS over z/OS and TSO for developers, Rexx or otherwise. Rather, I would argue that it is the even more the powerful concept of DVM's, Disconnected Virtual Machines, and the resulting ability for even ordinary application developers, not just sysprogs, to very simply arrange to pass data between them via VMCF and/or IUCV. Then add the power of VM Rexx and pipeline support and XEDIT and the other CMS tools as the only code needed to actually run in and interact with those DVM's and many extremely useful and powerful applications can be coded with nary a compiler or assembler in sight, never mind in use. No authorized coding or cross-memory complexity required. Add DB2 and networking support for Rexx and many full-function business applications are added to the possibilities. I bemoan the failure decades ago of the CMS on MVS project. That would, indeed, have changed the history and practice of our computing lives. And a Happy New Year to all. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Sunday, December 29, 2013 11:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Learning Rexx On 29/12/2013 1:07 AM, Paul Gilmartin wrote: On 2013-12-28, at 09:47, Charles Mills wrote: Actually CMS on VM better for rexx than z/OS. Why? (Risking an advocacy thread.) For me, one reason is the CMS HELP facility. In fact, sometimes coding Rexx for z/OS I'll log on to CMS merely to use HELP REXX instruction. Other reasons? Most VMers claim that Rexx is superior on VM because of CMS pipes. That's a pretty strong argument. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
Peter, Totally agree with you, worked VM for a long time. Liked all of its features..still do.. Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Jan 1, 2014, at 2:23 PM, Farley, Peter x23353 peter.far...@broadridge.com wrote: PMFJI here, but IMHO the pipeline paradigm, though obviously powerful and useful, is not the major advantage of VM and CMS over z/OS and TSO for developers, Rexx or otherwise. Rather, I would argue that it is the even more the powerful concept of DVM's, Disconnected Virtual Machines, and the resulting ability for even ordinary application developers, not just sysprogs, to very simply arrange to pass data between them via VMCF and/or IUCV. Then add the power of VM Rexx and pipeline support and XEDIT and the other CMS tools as the only code needed to actually run in and interact with those DVM's and many extremely useful and powerful applications can be coded with nary a compiler or assembler in sight, never mind in use. No authorized coding or cross-memory complexity required. Add DB2 and networking support for Rexx and many full-function business applications are added to the possibilities. I bemoan the failure decades ago of the CMS on MVS project. That would, indeed, have changed the history and practice of our computing lives. And a Happy New Year to all. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Sunday, December 29, 2013 11:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Learning Rexx On 29/12/2013 1:07 AM, Paul Gilmartin wrote: On 2013-12-28, at 09:47, Charles Mills wrote: Actually CMS on VM better for rexx than z/OS. Why? (Risking an advocacy thread.) For me, one reason is the CMS HELP facility. In fact, sometimes coding Rexx for z/OS I'll log on to CMS merely to use HELP REXX instruction. Other reasons? Most VMers claim that Rexx is superior on VM because of CMS pipes. That's a pretty strong argument. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Application development paradigms [was: RE: Learning Rexx]
On Wed, 1 Jan 2014 14:23:58 -0500, Farley, Peter x23353 wrote: Rather, I would argue that it is the even more the powerful concept of DVM's, Disconnected Virtual Machines, and the resulting ability for even ordinary application developers, not just sysprogs, ... Are you suggesting that I, as a Class G user, can build and deploy a DVM, no sysprog intervention? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx
On Tue, 31 Dec 2013 13:36:46 +0800, David Crayford wrote: Designing routines to co-operate in a pipeline is a very different programming paradigm to what the vast majority of REXX programmers on z/OS are familar with. s/REXX // Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx
Shane, Not a difficult to we who worked VM or Linux...that's kind of a vague generation Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Dec 31, 2013, at 5:23 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: On Tue, 31 Dec 2013 13:36:46 +0800, David Crayford wrote: Designing routines to co-operate in a pipeline is a very different programming paradigm to what the vast majority of REXX programmers on z/OS are familar with. s/REXX // Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx
scott_j_f...@yahoo.com (Scott Ford) writes: Not a difficult to we who worked VM or Linux...that's kind of a vague generation trivia ... I did internal adtech conf. spring '82 (week before share) ... it was first for a number of yrs since the corporate retrenching after the failure of future system effort (lots of adtech got thrown into the breach in mad rush to get stuff back into the 370 product pipeline). http://www.garlic.com/~lynn/submain.html#futuresys one of the presentations was about precursor to pipelines the toy program ... old post referencing John Hartmann's b'day party http://www.garlic.com/~lynn/96.html#4a fouund here: http://vm.marist.edu/~piper/party/jph-01.html wiki page http://en.wikipedia.org/wiki/Hartmann_pipeline page at marist http://vm.marist.edu/~pipeline/ -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx (was: Need tutorial)
In 5c8fv3f78unypshw9tyopynk.1388251271...@email.android.com, on 12/28/2013 at 12:21 PM, Charles Mills charl...@mcn.org said: The user-friendly interactive nature of CMS. Rhat would seem to describe TSO as well. The only place where CMS has a clear edge, IMHO, is XEDIT. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx (was: Need tutorial)
Gee, I don't want to pose as an expert in the relative benefits of various Rexx environments. I have near-zero experience on 'nix and USS, no recent (15 years) experience on CMS, and although I have written large systems in Rexx, I am not at present writing much Rexx beyond basic TSO helper scripts. I certainly don't want to contribute to an OS war. I was just answering the question about how to learn Rexx, and if you happen to have access to both, IMHO CMS is a more Rexx-friendly place than TSO. It's really a separate topic, but I think there is little doubt that it makes sense to edit code of any sort in some fast character-at-a-time interactive environment even if the target compile and/or execution environment is z/OS. My particular choice is MS Visual Studio, but I only claim that it makes sense for me, not that it is the best for everyone. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, December 29, 2013 2:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Learning Rexx (was: Need tutorial) On 2013-12-28, at 10:21, Charles Mills wrote: The user-friendly interactive nature of CMS. How would you rank CMS vis-a-vis Unix System Services by this criterion? Before USS was available I tended to edit JCL on CMS with XEDIT; nowadays on Solaris, often accessing legacy data sets with NFS. NFS will deal with PDSE; I suspect that CMS would have trouble ACCESSing a PDSE, and writing to any legacy z/OS data set from CMS is questionable, as is catalog search. I use TSO/ISPF, now as earlier, largely for: o SDSF o DSLIST o DDLIST o Testing with a customer-like environment. I keep one ISPF session active, and as many USS or Solaris as convenient; I've never mastered WSA. (and I have one EXEC that uses ISPF LMGET to process RECFM=U (by override) data sets because EXECIO refuses to deal with U. That's reported to get better in 2.1.) Rexx SYSCALL is a boon (or a least it spares me learning Perl). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx (was: Need tutorial)
In 07dd01cf055e$eb92e0d0$c2b8a270$@mcn.org, on 12/30/2013 at 07:59 AM, Charles Mills charl...@mcn.org said: It's really a separate topic, but I think there is little doubt that it makes sense to edit code of any sort in some fast character-at-a-time interactive environment even if the target compile and/or execution environment is z/OS. You can't do only one thing, and the Devil is in the details. There is little doubt that it makes sense to edit code of any sort in some fast character-at-a-time interactive environment that offers the same convenience, functionality and speed as the available alternatives. There is also little doubt that it makes sense to use a block mode editor that offers more convenience, functionality and speed than a GUI alternative. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx
On Mon, 30 Dec 2013 12:20:36 +0800, David Crayford wrote: Most VMers claim that Rexx is superior on VM because of CMS pipes. That's a pretty strong argument. That's analogous to claiming that Rexx is superior on z/OS because of address SYSCALL (others might say ISPEXEC/ISREDIT). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx
Reifying personal preferences into claims of superiority is a lot like arguing from a mystical experience. They may well be personally compelling; but they don't persuade others. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx
On 30/12/2013 11:11 PM, Paul Gilmartin wrote: Most VMers claim that Rexx is superior on VM because of CMS pipes. That's a pretty strong argument. That's analogous to claiming that Rexx is superior on z/OS because of address SYSCALL (others might say ISPEXEC/ISREDIT). Perhaps. But pipes are part of the base CMS product and are considered fundamental to REXX programming on VM. On z/OS they are either a very expensive add-on product or have to run in the POSIX subsystem. Designing routines to co-operate in a pipeline is a very different programming paradigm to what the vast majority of REXX programmers on z/OS are familar with. NetView had pipes and they were incredibly useful for processing message streams. I used to miss that functionality when coding TSO REXX. Of course, IBM are in the business of making a buck; but it's a travesty that they never made pipes, both TSO and batch, part of the base software stack. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx (was: Need tutorial)
On 2013-12-28, at 10:21, Charles Mills wrote: The user-friendly interactive nature of CMS. How would you rank CMS vis-a-vis Unix System Services by this criterion? Before USS was available I tended to edit JCL on CMS with XEDIT; nowadays on Solaris, often accessing legacy data sets with NFS. NFS will deal with PDSE; I suspect that CMS would have trouble ACCESSing a PDSE, and writing to any legacy z/OS data set from CMS is questionable, as is catalog search. I use TSO/ISPF, now as earlier, largely for: o SDSF o DSLIST o DDLIST o Testing with a customer-like environment. I keep one ISPF session active, and as many USS or Solaris as convenient; I've never mastered WSA. (and I have one EXEC that uses ISPF LMGET to process RECFM=U (by override) data sets because EXECIO refuses to deal with U. That's reported to get better in 2.1.) Rexx SYSCALL is a boon (or a least it spares me learning Perl). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx
I have my own edit system: Use Vim to do editing and sytax highligting, auto complete, also Vim calls ftp command and one shell to submit JCL that do send to z/OS and call compiler. Also intergrate with Cygwin can use a lot of GNU utility, such as grep/awk/sed. I think the most powerful thing is grep and Vim. The most inconvience is COBOL enterprise compiler's result is not match real source line number, because it calculates copybook and sql statement. I tried many solutions to solve this problem but not stable and graceful. And use CICS explorer to debug. Because security issue, we don't have NFS enabled, but maybe in the future I can use Vim edit NFS file directly. δΊ 2013/12/30 3:15, Paul Gilmartin ει: On 2013-12-28, at 10:21, Charles Mills wrote: The user-friendly interactive nature of CMS. How would you rank CMS vis-a-vis Unix System Services by this criterion? Before USS was available I tended to edit JCL on CMS with XEDIT; nowadays on Solaris, often accessing legacy data sets with NFS. NFS will deal with PDSE; I suspect that CMS would have trouble ACCESSing a PDSE, and writing to any legacy z/OS data set from CMS is questionable, as is catalog search. I use TSO/ISPF, now as earlier, largely for: o SDSF o DSLIST o DDLIST o Testing with a customer-like environment. I keep one ISPF session active, and as many USS or Solaris as convenient; I've never mastered WSA. (and I have one EXEC that uses ISPF LMGET to process RECFM=U (by override) data sets because EXECIO refuses to deal with U. That's reported to get better in 2.1.) Rexx SYSCALL is a boon (or a least it spares me learning Perl). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx
On 29/12/2013 1:07 AM, Paul Gilmartin wrote: On 2013-12-28, at 09:47, Charles Mills wrote: Actually CMS on VM better for rexx than z/OS. Why? (Risking an advocacy thread.) For me, one reason is the CMS HELP facility. In fact, sometimes coding Rexx for z/OS I'll log on to CMS merely to use HELP REXX instruction. Other reasons? Most VMers claim that Rexx is superior on VM because of CMS pipes. That's a pretty strong argument. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning Rexx (was: Need tutorial)
The user-friendly interactive nature of CMS. Charles Composed on a mobile: please excuse my brevity Paul Gilmartin paulgboul...@aim.com wrote: On 2013-12-28, at 09:47, Charles Mills wrote: Actually CMS on VM better for rexx than z/OS. Why? (Risking an advocacy thread.) For me, one reason is the CMS HELP facility. In fact, sometimes coding Rexx for z/OS I'll log on to CMS merely to use HELP REXX instruction. Other reasons? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
