Reason for condition code checking being the way it is was Re: Item on TPF
On 1 Mar 2010 17:23:07 -0800, in bit.listserv.ibm-main you wrote: I guess I should note that I am speaking only as an application developer. So I come at it from a different perspective than most of those on this list. But a few things I miss from VSE: - Superior JCL symbolics. - System level symbolics availble for use in batch JCL. - JCL DATE card to override system date. - Return code checking that actually makes sense (can anyone give a good reason for how COND works?). My theory is it was designed by engineers who were used to dealing with not and and not or gates so the negative way of thinking was natural. As someone who has had to do cute things with condition codes I share your disdain. - LIBDEF statements for setting/overriding a library search chain. - JCL symbolics available to batch FTP client. - JCL (JECL) FNO parm for setting FORMDEF/PAGEDEF/FORMS/etc. by specifying a single name. Those are what I can think of offhand. I notice that all of my beefs with z/OS have to do with JCL. Interesting; I'd never really thought about it in that context. Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
I guess I should note that I am speaking only as an application developer. So I come at it from a different perspective than most of those on this list. But a few things I miss from VSE: - Superior JCL symbolics. - System level symbolics availble for use in batch JCL. - JCL DATE card to override system date. - Return code checking that actually makes sense (can anyone give a good reason for how COND works?). - LIBDEF statements for setting/overriding a library search chain. - JCL symbolics available to batch FTP client. - JCL (JECL) FNO parm for setting FORMDEF/PAGEDEF/FORMS/etc. by specifying a single name. Those are what I can think of offhand. I notice that all of my beefs with z/OS have to do with JCL. Interesting; I'd never really thought about it in that context. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 2/28/2010 at 4:00 PM, in message 527308.35953...@web54604.mail.re2.yahoo.com, Ed Gould ps2...@yahoo.com wrote: From: Frank Swarbrick frank.swarbr...@efirstbank.com To: IBM-MAIN@bama.ua.edu Sent: Sun, February 28, 2010 2:52:46 AM Subject: Re: Item on TPF --SNIP--- In my opinion only. I could list probably 20 things I miss from VSE. But I don't want to bore everyone. The main reason we are converting, as far as I can tell, is that z/OS is just better supported, but by IBM and by ISVs. I don't think anyone here is unhappy with how VSE works. Again, don't get me wrong, z/OS has a lot of good stuff. But it seems to be missing some things that I have found to be very useful on VSE. SNIP--- I do not know about you but there is a list a mile long about the things I hated about DOS. One of the most difficult things that I ran across were split cylinders. DOS documentation was in my opinion horrid. After reading the doc (I used that term loosely) I had to go to our local IBM rep. He read it over and admitted he didn't quite understand it. So he called up a friend of his in Hiedleberg (Germany), and he got a quick lesson so he explained it to me. I guess I understood it but as soon as I saw it used in DOS JCL (that is a laugh) It baffled me so I took the JCL up to my IBM friend and asked him to translate and he couldn't (I did not feel bad). He called his friend again and the friend was puzzled but good through it and I got on the phone and we went step by step through it. I walked away hating DOS forever more. There were other idiosyncrasies that was so stupid I just shook my head and thought I would be so happy never to see DOS again for the rest of my life. I didn't either. I was happy to work on MFT it did make sense. When I got out of the army the OS we were running was MFT and soon upgraded to OS/VS2 then I switched jobs and have been MVS ever since. YUCK DOS SUCKED. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
On 1 March 2010 20:21, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: But a few things I miss from VSE: [...] - Return code checking that actually makes sense (can anyone give a good reason for how COND works?). A reason - no. How it works is not obvious, but not hard either. If whatever you put in the COND= is true, then skip the step. Simple as that. Of course now there's an IF statement, but that's the newfangled way. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
From: Frank Swarbrick frank.swarbr...@efirstbank.com To: IBM-MAIN@bama.ua.edu Sent: Mon, March 1, 2010 7:21:52 PM Subject: Re: Item on TPF I guess I should note that I am speaking only as an application developer. So I come at it from a different perspective than most of those on this list. But a few things I miss from VSE: - Superior JCL symbolics. - System level symbolics availble for use in batch JCL. - JCL DATE card to override system date. - Return code checking that actually makes sense (can anyone give a good reason for how COND works?). - LIBDEF statements for setting/overriding a library search chain. - JCL symbolics available to batch FTP client. - JCL (JECL) FNO parm for setting FORMDEF/PAGEDEF/FORMS/etc. by specifying a single name. Those are what I can think of offhand. I notice that all of my beefs with z/OS have to do with JCL. Interesting; I'd never really thought about it in that context. Frank Frank, The JCL date is rather interesting but the concept is unique to dos as far as I know dos doesn't come close to a shared spool like MVS does. I would suspect that if dos ever allows shared spool the issue would have to disappear or the concept would have to change. As to the cond I would (like you) probably not say it is not one of MVS's best implementations. It truly does make sense in an off handed way, the problem is as always is compatibility. It was not implemented in a user friendly manner and so it was burnt into the OS as far as compatibility forever more. I am not all that familiar with LIBDEF's but if you are talking steplib or joblib there is more enough flexibility as far as I am concerned. I cannot tell you how many times a programmer picked up an incorrect module because of steplib/joblib problems. Since I know nothing about libdefs I would suggest that you look at steplib/joblib and see if it isn't superior to libdef. There are one or two issues that cause issues with the steplib and that is with authorization checking that I am guessing that DOS does not have. But again MVS is vastly more superior in security than DOS is. The JCL symbolics for FTP is a mixed issue as there are both good and bad issues with having them. I suspect (but do not know) if DOS has anything like the MVS convertor/interpreter it is the big green monster from hell (pardon the english) and there is no easy interface to it (that I have seen documented). I would suggest that while it might seem nice to have it, I would suggest that this short coming is really a blessing. As to the pagedef/formdef item. The 3800 was not invented when the C/I was written and adding support for it (from what I heard) raised a ugly head at IBM. I vaguely remember it was rewritten in the 1990's (early) but there was only so much they could do. I am not excusing it but the implementation was pretty much in line with the rest of JCL. I am not claiming JCL is best it works reasonably well with the guarantee of backward compatibility that IBM is famous for. Just remember one thing MVS is IBM's Flagship OS and IBM does a damn (pardon the english) job to make sure there is compatibility between releases. I think its been said on here many times that most of the programs that were compiled and linked 30 years ago still run unchanged today (there are exception of course) but at most sites I have been working at a upgrade in the OS is not any major issue as IBM goes to great pains to maintain compatibility. Its been years since I have worked on DOS (probably 25 and that was dos under VM) it was a PITA then from what little I read its improved a little but noting close to the improvements in MVS in the same time frame. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
On 2/27/2010 at 8:13 AM, in message listserv%201002270913195378.0...@bama.ua.edu, Eric Bielefeld eric-ibmm...@wi.rr.com wrote: I'm curious. How much more does z/OS cost than z/VSE? An approximate percentage is good enough. I have no idea. I'm just an apps guy. What are your reasons for converting? It sounds like from the way you worded your comment below that z/VSE doesn't have some restrictions that z/OS does, although I may have misread your comments. In my opinion only. I could list probably 20 things I miss from VSE. But I don't want to bore everyone. The main reason we are converting, as far as I can tell, is that z/OS is just better supported, but by IBM and by ISVs. I don't think anyone here is unhappy with how VSE works. Again, don't get me wrong, z/OS has a lot of good stuff. But it seems to be missing some things that I have found to be very useful on VSE. I did a conversion back in 1985 from DOS to MVS 1.3.6. I think it took alomost as long to convert from DOS to MVS as it did to get off of the mainframe 4 years ago. In 1985, we ran 5 DOS guests under VM. We've been working on it since, I think, late 2008. Conversion date is scheduled for the end of May this year. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
From: Frank Swarbrick frank.swarbr...@efirstbank.com To: IBM-MAIN@bama.ua.edu Sent: Sun, February 28, 2010 2:52:46 AM Subject: Re: Item on TPF --SNIP--- In my opinion only. I could list probably 20 things I miss from VSE. But I don't want to bore everyone. The main reason we are converting, as far as I can tell, is that z/OS is just better supported, but by IBM and by ISVs. I don't think anyone here is unhappy with how VSE works. Again, don't get me wrong, z/OS has a lot of good stuff. But it seems to be missing some things that I have found to be very useful on VSE. SNIP--- I do not know about you but there is a list a mile long about the things I hated about DOS. One of the most difficult things that I ran across were split cylinders. DOS documentation was in my opinion horrid. After reading the doc (I used that term loosely) I had to go to our local IBM rep. He read it over and admitted he didn't quite understand it. So he called up a friend of his in Hiedleberg (Germany), and he got a quick lesson so he explained it to me. I guess I understood it but as soon as I saw it used in DOS JCL (that is a laugh) It baffled me so I took the JCL up to my IBM friend and asked him to translate and he couldn't (I did not feel bad). He called his friend again and the friend was puzzled but good through it and I got on the phone and we went step by step through it. I walked away hating DOS forever more. There were other idiosyncrasies that was so stupid I just shook my head and thought I would be so happy never to see DOS again for the rest of my life. I didn't either. I was happy to work on MFT it did make sense. When I got out of the army the OS we were running was MFT and soon upgraded to OS/VS2 then I switched jobs and have been MVS ever since. YUCK DOS SUCKED. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
Re: VSE sunset there was also the near-heroic efforts to save VSE by Pete Clark, Bennie Pugh, and Charles Rice. I don't think IBM found out the extent of VSE usage in China; I think they always knew. OS was being developed by an outside source Really? It also might be mentioned that there was an incentive to develop a quick-and-dirty DOS/360 that came from the shortage of machine time on the 7094 simulators (being used to develop OS/360) versus the amount of 360 hardware that was coming out of the factory but unusable due to the lack of an operating system. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of George Henke Sent: Friday, February 26, 2010 5:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Item on TPF IBM was about to sunset VSE a few years ago until it found out that in mainland China, VSE was the operating system of choice. Given their population, I don't think it will be disappearing anytime soon. And to think it all was just a mistake from the beginning. Back in the days when 3rd generation was about to walk upon the scene and OS was being developed by an outside source, IBM was concerned it was too big an undertaking and I might never even come into existence. So that they would not lose the chance to steal the market from UNIVAC which was the vendor of choice in those days and the favorite to win the 3rd generation race to the marketplace, they hastily developed DOS internally just in case and brought it out first. Unfortunately, it has always lacked at least one major control block, the DEB and so tech support has always been shackled with the burden of manually keeping track of every cylinder and track. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
I'm curious. How much more does z/OS cost than z/VSE? An approximate percentage is good enough. What are your reasons for converting? It sounds like from the way you worded your comment below that z/VSE doesn't have some restrictions that z/OS does, although I may have misread your comments. I did a conversion back in 1985 from DOS to MVS 1.3.6. I think it took alomost as long to convert from DOS to MVS as it did to get off of the mainframe 4 years ago. In 1985, we ran 5 DOS guests under VM. Eric Bielefeld On Fri, 26 Feb 2010 16:20:56 -0700, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: When you refer to z/dos, do you mean z/VSE? We are migrating this year from z/VSE to z/OS. I never thought VSE was that great until this project. z/OS has a lot of good stuff, but it also has a lot of annoying limitations (odd restrictions). -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
On Fri, 26 Feb 2010 20:58:32 -0500, George Henke wrote: IBM was about to sunset VSE a few years ago until it found out that in mainland China, VSE was the operating system of choice. ... Unfortunately, it has always lacked at least one major control block, the DEB and so tech support has always been shackled with the burden of manually keeping track of every cylinder and track. ??? I was aware of the deficiency some decades ago. I'm not sure what it has do do with DEB; it seems to be more related to the DSCB in the VTOC. And I thought it was merely that VSE development abdicated the responsibility of automating DADSM. Though now it has been mitigated. At last? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. charl...@mcn.org (Charles Mills) writes: It also might be mentioned that there was an incentive to develop a quick-and-dirty DOS/360 that came from the shortage of machine time on the 7094 simulators (being used to develop OS/360) versus the amount of 360 hardware that was coming out of the factory but unusable due to the lack of an operating system. there was less difference between 360/370 w/o virtual memory and 370 with virtual memory. for 370 virtual memory there was (distributed) development project between the science center and endicott to modify cp67 to support 370 virtual machines with virtual memory (i.e. 370 had some new instructions and the format of the virtual memory tables and definition of control registers were different). since the cp67 service had non-employee users (students and others from various institutions in boston area, BU, MIT, Harvard, etc), the project went on with virtual cp67 in a virtual machine (to help keep information about virtual memory to leaking to the unauthorized). then to test the virtual 370 operation, another version of cp67 was modified to conform to the 370 architecture (instead of 360/67 architecture). A year before first engineering 370, the following was in general use 360/67 real machine cp67l running on real hardware cp67h running in 360/67 virtual machine w/virtual memory cp67i running in 370 virtual machine w/virtual memroy cms when first engineering 370 with virtual memory hardware became operation, a version of cp67i was booted on the machine to test its operation. The first boot failed, and after some diagnostic, it turned out that the engineers had reversed the definition of two of the new opcodes; the cp67i kernel was quickly patched (for the incorrect opcodes) and cp67i came up and ran. things were a little different for MVT-SVS. There were minimal changes to MVT to build a single virtual address table ... and handle page faults and paging operations (not a whole lot of difference between running MVT in a large virtual machine ... with a minimum amount of native virtual memory support). The biggest change for MVT-SVS was that the application channel programs passed via EXCP/svc0 had to be translated, aka a shadow copy of the CCWs built that had real addresses in place of the virtual addresses (along with the associated pinning/unpinning of the virtual pages to real addresses). To do this, a copy of the the corresponding code from CP67 was borrowed (i.e. when cp67 does virtual machine channel programs it had to scan the virtual channel program, creating a shadow copy with real address in place of virtual addresses). When 370s with virtual memory hardware started being deployed internally, cp67i was the standard system that ran on them for a long time (or cp67sj ... which was cp67i with 3330 2305 device support done by a couple engineers from san jose). something different was done for 3081 and TPF. Originally 308x was never going to have non-multiprocessor machine ... however, at the time, TPF didn't have multiprocessor support. The mechanism to run TPF on 3081 was to run vm370 with TPF in a virtual machine. In some number of TPF 3081, that tended to leave the 2nd 3081 processor idle. The next release of vm then had some special modifications to improve TPF thruput ... it added a bunch of multiprocessor chatter overhead that allowed parts of vm kernel execution to be run asynchronous with TPF operation ... this drove up virtual machine overhead by about 10% ... but increased overall TPF thruput ... by having the overhead being executed on the otherwise idle processor. The problem was that (additional multiprocessor overhead chatter) change degraded the thruput of all the other 3081 multiprocessor customers (that normally ran with all processors fully loaded). Finally, the company started to offer 3083 (a 3081 w/o the 2nd processor frame), in large part for TPF. As mentioned in this post http://www.garlic.com/~lynn/2010d.html#79 LPARs: More or Less? the straight-forward would be to leave out the processor 1 frame ... but the processor 0 was built at the top of the box ... and there was some concern that the straight-forward solution would leave the box top-heavy. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
VSE does not support the Format-? (3? 5?) VTOC record that inventories free space. Traditional DASD space management in VSE involves a chart on the sysprog's wall showing which tracks of each volume are free. All traditional DASD space allocation in VSE is what z/OS JCL calls ABSTR (is that the right spelling?). A backstop against oops is that VSE datasets are usually defined with an expiration date (unlike z/OS) which causes VSE to complain if one attempts to overwrite them. The more modern approach in VSE uses large VSAM extents as sub-regions of a disk. VSAM then allocates space for sequential datasets within this area. I think there are also some third-party solutions. I know I set out to write one once (but did not complete the project). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Saturday, February 27, 2010 8:07 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Item on TPF On Fri, 26 Feb 2010 20:58:32 -0500, George Henke wrote: IBM was about to sunset VSE a few years ago until it found out that in mainland China, VSE was the operating system of choice. ... Unfortunately, it has always lacked at least one major control block, the DEB and so tech support has always been shackled with the burden of manually keeping track of every cylinder and track. ??? I was aware of the deficiency some decades ago. I'm not sure what it has do do with DEB; it seems to be more related to the DSCB in the VTOC. And I thought it was merely that VSE development abdicated the responsibility of automating DADSM. Though now it has been mitigated. At last? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
If George is referring to VSAM Managed SAM, then yes it has been mitigated. It does provide some of the disk space management features of z/OS and third party software to the base operating system On 02/27/2010 10:06 AM, Paul Gilmartin wrote: On Fri, 26 Feb 2010 20:58:32 -0500, George Henke wrote: Though now it has been mitigated. At last? -- gil -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2010 - Apr 9-13, 2010 Covington, KY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
I can see free space on a VSE volume with Ditto and native VSE tools. Been like that for as long as I remember. On 02/27/2010 10:56 AM, Charles Mills wrote: VSE does not support the Format-? (3? 5?) VTOC record that inventories free space. Traditional DASD space management in VSE involves a chart on the sysprog's wall showing which tracks of each volume are free. All traditional DASD space allocation in VSE is what z/OS JCL calls ABSTR (is that the right spelling?). A backstop against oops is that VSE datasets are usually defined with an expiration date (unlike z/OS) which causes VSE to complain if one attempts to overwrite them. The more modern approach in VSE uses large VSAM extents as sub-regions of a disk. VSAM then allocates space for sequential datasets within this area. I think there are also some third-party solutions. I know I set out to write one once (but did not complete the project). Charles -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2010 - Apr 9-13, 2010 Covington, KY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: item on TPF, ABSTRK
Almost, but no cigar. 'ABSTRK' is correct; it stands for space allocation using absolute [hardware] tracks [track numbers]. It is of course radically device-dependent; I have used it, but not in OS/PCP and its successors for, probably, 40 years. It continued to be well known by name long after it had ceased to be much if at all used because it figured prominently in error messages generated when SPACE= syntax errors were made in DD statements. John Gilmore Ashland, MA 01721-1817 USA _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/201469229/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
My guess is that it is computed at the time by Ditto. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rich Smrcina Sent: Saturday, February 27, 2010 9:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Item on TPF I can see free space on a VSE volume with Ditto and native VSE tools. Been like that for as long as I remember. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
I should have read your post more closely, 'the VTOC inventories the free space'. OK, that makes sense. I don't have any reason to mistrust current calculations of free space. Haven't used wall charts for a very long time. But, we used to maintain a CMS file of DASD space usage... including OUR view of free space. That was in the 3370/3380 days. And, yes that was a PITA to maintain. On 02/27/2010 11:21 AM, Charles Mills wrote: My guess is that it is computed at the time by Ditto. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rich Smrcina Sent: Saturday, February 27, 2010 9:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Item on TPF I can see free space on a VSE volume with Ditto and native VSE tools. Been like that for as long as I remember. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2010 - Apr 9-13, 2010 Covington, KY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: item on TPF, ABSTRK
I've never seen it referred to as ABSTRK, but I'm not a DOS guy. Who knows what they call it? I've only ever seen it as ABSTR, just like the JCL operand. Date: Sat, 27 Feb 2010 17:20:09 + From: john_w_gilm...@msn.com Subject: Re: item on TPF, ABSTRK To: IBM-MAIN@bama.ua.edu Almost, but no cigar. 'ABSTRK' is correct; it stands for space allocation using absolute [hardware] tracks [track numbers]. It is of course radically device-dependent; I have used it, but not in OS/PCP and its successors for, probably, 40 years. It continued to be well known by name long after it had ceased to be much if at all used because it figured prominently in error messages generated when SPACE= syntax errors were made in DD statements. John Gilmore Ashland, MA 01721-1817 USA _ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/201469227/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
On 26 Feb 2010 17:59:33 -0800, in bit.listserv.ibm-main you wrote: IBM was about to sunset VSE a few years ago until it found out that in mainland China, VSE was the operating system of choice. Given their population, I don't think it will be disappearing anytime soon. And to think it all was just a mistake from the beginning. Back in the days when 3rd generation was about to walk upon the scene and OS was being developed by an outside source, IBM was concerned it was too big an undertaking and I might never even come into existence. So that they would not lose the chance to steal the market from UNIVAC which was the vendor of choice in those days and the favorite to win the 3rd generation race to the marketplace, they hastily developed DOS internally just in case and brought it out first. There also was the little detail that DOS360 could run on 16K and 32K machines while OS360 required a minimum of 64K (and I THINK that was with PCP). Both have evolved since then but I wouldn't be surprised to find that the minimum configuration for zVSE is still much less than that for zOS. Unfortunately, it has always lacked at least one major control block, the DEB and so tech support has always been shackled with the burden of manually keeping track of every cylinder and track. Though now it has been mitigated. Something OS bigots refer to as the DOS mentality. On Fri, Feb 26, 2010 at 6:20 PM, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: When you refer to z/dos, do you mean z/VSE? We are migrating this year from z/VSE to z/OS. I never thought VSE was that great until this project. z/OS has a lot of good stuff, but it also has a lot of annoying limitations (odd restrictions). -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 2/25/2010 at 11:07 PM, in message 676233.52076...@web54605.mail.re2.yahoo.com, Ed Gould ps2...@yahoo.com wrote: In the most recent issue (arrived in todays mail) of Z Journal there is a decent article on TPF. I just looked and its not posted online yet at mainframezone.com . What else is interesting and quite comical (at least to me) is an article about issues with z/dos (or whatever IBM calls it now days). The rather odd restrictions that still haunt the dos people to this day. At least with MVS the restrictions are few and far in between. I still amazed that dos has continued to hang on to this day. I suspect that the die hard dos fans will retire before converting to Z/os. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: item on TPF, ABSTRK
Lucky fella - I guess that means John hasn't had any (usually junior) sysprogs that deleted catalogs or page datasets or TMC or whatever from a live system. Pays to put things like that back in the same spot - quickly. ABSTR is the answer. Shane ... On Sun, Feb 28th, 2010 at 4:20 AM, john gilmore wrote: .I have used it, but not in OS/PCP and its successors for, probably, 40 years. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
From: Charles Mills charl...@mcn.org To: IBM-MAIN@bama.ua.edu Sent: Sat, February 27, 2010 10:56:03 AM Subject: Re: Item on TPF VSE does not support the Format-? (3? 5?) VTOC record that inventories free space. Traditional DASD space management in VSE involves a chart on the sysprog's wall showing which tracks of each volume are free. All traditional DASD space allocation in VSE is what z/OS JCL calls ABSTR (is that the right spelling?). A backstop against oops is that VSE datasets are usually defined with an expiration date (unlike z/OS) which causes VSE to complain if one attempts to overwrite them. The more modern approach in VSE uses large VSAM extents as sub-regions of a disk. VSAM then allocates space for sequential datasets within this area. I think there are also some third-party solutions. I know I set out to write one once (but did not complete the project). Charles Charles: Really?? how curious IBM did away with that a LONG time ago on MVS. My memory is bad on dates but I would guess in the late 80's (??). ANyone? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
-SNIP- There also was the little detail that DOS360 could run on 16K and 32K machines while OS360 required a minimum of 64K (and I THINK that was with PCP). Both have evolved since then but I wouldn't be surprised to find that the minimum configuration for zVSE is still much less than that for zOS. SNIP Not from direct knowledge but here it goes: Back in the early 70's we were running MFT on two mod 50's and DOS (sorry cannot remember the version) on 2 mod 30's . In any case we had a visitor from the Canal Zone and he (without asking) tried to load an object deck onto DOS. It couldn't as our machines were 32K and his DOS machine (according to him was 64K). I walked into the mess and took one look at the output and said our machine only had 32K. He was a warrant officer and I was (IIRC an E6 at the time) and I said well we can't load the deck because of the machine size. He laughed and said something like well we use DOS for important work and I said something to the effect well we do our important work on MOD 50's using a modern OS and reserve the 30's for printers. He did not like my answer so he left and I guess he tried to get me on insubordination but my boss quashed that. He was a GS14 and that pretty well out ranks a warrant officer. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
From: Eric Bielefeld eric-ibmm...@wi.rr.com To: IBM-MAIN@bama.ua.edu Sent: Sat, February 27, 2010 9:13:19 AM Subject: Re: Item on TPF I'm curious. How much more does z/OS cost than z/VSE? An approximate percentage is good enough. What are your reasons for converting? It sounds like from the way you worded your comment below that z/VSE doesn't have some restrictions that z/OS does, although I may have misread your comments. I did a conversion back in 1985 from DOS to MVS 1.3.6. I think it took alomost as long to convert from DOS to MVS as it did to get off of the mainframe 4 years ago. In 1985, we ran 5 DOS guests under VM. Eric Bielefeld -SNIP Eric: I can't address the costs since I did my last conversion in the late 80's (from VS1). As to the reasoning MVS is a a hell of a lot faster with IO (due mainly due to buffering and excp processing. I think you misunderstood what I was saying DOS/VSE has A LOT of restrictions that MVS does not. The article talks about one of them and that is that in DOS/VSE(?) there is a restriction of 999 sysxxx DD statements (in MVS) and even then apparently is less that 999. The article (when is made available online) goes on with other issues so need to clutter up the list here. The article didn't mention the issue of vsam space (as someone on here did) . Please watch the URL to see in detail more on the DOS limitations. I actually was intrigued about TPF its been a long time since I have seen any information on it. Even with z/tpf they have some strange restrictions that are just now being address by IBM. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
From: Frank Swarbrick frank.swarbr...@efirstbank.com To: IBM-MAIN@bama.ua.edu Sent: Fri, February 26, 2010 5:20:56 PM Subject: Re: Item on TPF When you refer to z/dos, do you mean z/VSE? We are migrating this year from z/VSE to z/OS. I never thought VSE was that great until this project. z/OS has a lot of good stuff, but it also has a lot of annoying limitations (odd restrictions). -- Patrick, Well the article mentioned both. I may have inadvertently mixed them up. It was a history so it was fluid as to some of the comparisons they did make. I apologize if I did but read the article (when it becomes available) and I think you will see what I mean. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
Haven't seen the article yet - but I did want to dispel at least my own confusion. TPF is not DOS (or VSE)... TPF continues with a strong following today as z/TPF. VSE continues as z/VSE. Are we talking about z/VSE or z/TPF? ACtually the article talk about *BOTH* and it was fluid as it talked about different things at different times. The artical does make sense but it is quite all encompassing so you have to read it closely as a couple of paragraphs I had to reread to get a sense of what/when/which they were talking about. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
In b53f38421002261758u28245cc0ua7cc259894f71...@mail.gmail.com, on 02/26/2010 at 08:58 PM, George Henke gahe...@gmail.com said: Unfortunately, it has always lacked at least one major control block, the DEB and so tech support has always been shackled with the burden of manually keeping track of every cylinder and track. What does the DEB have to do with space accounting? I might believe that DOS/VSE and later couldn't properly maintain the the VTOC; certainly DOS/360 couldn't. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
In b05jo5tom77v6mm3f3vge70pc76ssc9...@4ax.com, on 02/27/2010 at 05:55 PM, Clark Morris cfmpub...@ns.sympatico.ca said: There also was the little detail that DOS360 could run on 16K and 32K machines while OS360 required a minimum of 64K (and I THINK that was with PCP). The design point of OS/360 was 32 KiB and it was possible to run it on a 48 KiB machine, although you are correct that you would be limited to PCP, and even then you could only run small jobs. As a practical matter I'd want 128 KiB for PCP, 256 KiB for MFT II[1] and 512 MiB for MVT. [1] People ran MFT before MFT II, but it was not a pretty sight. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Gould Sent: Friday, February 26, 2010 1:07 AM To: IBM-MAIN@bama.ua.edu Subject: Item on TPF Snipped What else is interesting and quite comical (at least to me) is an article about issues with z/dos (or whatever IBM calls it now days). The rather odd restrictions that still haunt the dos people to this day. At least with MVS the restrictions are few and far in between. I still amazed that dos has continued to hang on to this day. I suspect that the die hard dos fans will retire before converting to Z/os. Ed, It's called z/VSE today, and I imagine the benefits of running it are the same as they were when I ran a shop that used VM and VSE (SP2 era) -- far lower software costs, far fewer skilled sysprog staff needed to install/tune/diagnose problems, and overall just a much better TCO than z/OS for a small shop. My shop was just me and one junior sysprog, and we kept that baby humming 24/7 just by ourselves. I am surprised it still survives only because IBM has been trying to kill it and abandon all small shops for 30 years. Remember the IBM CEO (Watson Jr.? or was it his successor?) who said IBM will never stay in a low-margin business, and they have proved over and over again that they mean it. So far they've nearly managed to abandon the small ISV (Dallas support is a sore subject among many small ISV's), the entire academic community (with a few notable exceptions like Marist) and almost all of the small commercial shops in the USA. Europe still holds on, probably because z/VSE support and development is in IBM Germany. Peter 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
I still amazed that dos has continued to hang on to this day 15-20 years ago there were over 35,000 VSE licenses. That's a large business segment to kill off. That's a lot of hardware sales to abandon. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
Ed Gould wrote: In the most recent issue (arrived in todays mail) of Z Journal there is a decent article on TPF. I just looked and its not posted online yet at mainframezone.com . What else is interesting and quite comical (at least to me) is an article about issues with z/dos (or whatever IBM calls it now days). The rather odd restrictions that still haunt the dos people to this day. At least with MVS the restrictions are few and far in between. I still amazed that dos has continued to hang on to this day. I suspect that the die hard dos fans will retire before converting to Z/os. Ed Haven't seen the article yet - but I did want to dispel at least my own confusion. TPF is not DOS (or VSE)... TPF continues with a strong following today as z/TPF. VSE continues as z/VSE. Are we talking about z/VSE or z/TPF? - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
Wow, you AND a junior sysprog? I wish I could get some help - this isn't that small a shop ;-) Farley, Peter x23353 peter.far...@broadridge.com 2/26/2010 8:53 AM Ed, It's called z/VSE today, and I imagine the benefits of running it are the same as they were when I ran a shop that used VM and VSE (SP2 era) -- far lower software costs, far fewer skilled sysprog staff needed to install/tune/diagnose problems, and overall just a much better TCO than z/OS for a small shop. My shop was just me and one junior sysprog, and we kept that baby humming 24/7 just by ourselves. I am surprised it still survives only because IBM has been trying to kill it and abandon all small shops for 30 years. Remember the IBM CEO (Watson Jr.? or was it his successor?) who said IBM will never stay in a low-margin business, and they have proved over and over again that they mean it. So far they've nearly managed to abandon the small ISV (Dallas support is a sore subject among many small ISV's), the entire academic community (with a few notable exceptions like Marist) and almost all of the small commercial shops in the USA. Europe still holds on, probably because z/VSE support and development is in IBM Germany. Peter 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
When you refer to z/dos, do you mean z/VSE? We are migrating this year from z/VSE to z/OS. I never thought VSE was that great until this project. z/OS has a lot of good stuff, but it also has a lot of annoying limitations (odd restrictions). -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 2/25/2010 at 11:07 PM, in message 676233.52076...@web54605.mail.re2.yahoo.com, Ed Gould ps2...@yahoo.com wrote: In the most recent issue (arrived in todays mail) of Z Journal there is a decent article on TPF. I just looked and its not posted online yet at mainframezone.com . What else is interesting and quite comical (at least to me) is an article about issues with z/dos (or whatever IBM calls it now days). The rather odd restrictions that still haunt the dos people to this day. At least with MVS the restrictions are few and far in between. I still amazed that dos has continued to hang on to this day. I suspect that the die hard dos fans will retire before converting to Z/os. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Item on TPF
IBM was about to sunset VSE a few years ago until it found out that in mainland China, VSE was the operating system of choice. Given their population, I don't think it will be disappearing anytime soon. And to think it all was just a mistake from the beginning. Back in the days when 3rd generation was about to walk upon the scene and OS was being developed by an outside source, IBM was concerned it was too big an undertaking and I might never even come into existence. So that they would not lose the chance to steal the market from UNIVAC which was the vendor of choice in those days and the favorite to win the 3rd generation race to the marketplace, they hastily developed DOS internally just in case and brought it out first. Unfortunately, it has always lacked at least one major control block, the DEB and so tech support has always been shackled with the burden of manually keeping track of every cylinder and track. Though now it has been mitigated. Something OS bigots refer to as the DOS mentality. On Fri, Feb 26, 2010 at 6:20 PM, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: When you refer to z/dos, do you mean z/VSE? We are migrating this year from z/VSE to z/OS. I never thought VSE was that great until this project. z/OS has a lot of good stuff, but it also has a lot of annoying limitations (odd restrictions). -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 2/25/2010 at 11:07 PM, in message 676233.52076...@web54605.mail.re2.yahoo.com, Ed Gould ps2...@yahoo.com wrote: In the most recent issue (arrived in todays mail) of Z Journal there is a decent article on TPF. I just looked and its not posted online yet at mainframezone.com . What else is interesting and quite comical (at least to me) is an article about issues with z/dos (or whatever IBM calls it now days). The rather odd restrictions that still haunt the dos people to this day. At least with MVS the restrictions are few and far in between. I still amazed that dos has continued to hang on to this day. I suspect that the die hard dos fans will retire before converting to Z/os. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
