Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
In 636e38e0-85a4-4259-a3e4-02f3e61dd...@comcast.net, on 07/12/2013 at 04:04 PM, Ed Gould edgould1...@comcast.net said: An example (software wise) was the TSO UTILITIES OS/MVT AND OS/VS2 TSO DATA UTILITIES: COPY, FORMAT, LIST MERGE, PROG. NO. 5734-UTl. IBM issued a final round of PTF's which did not in fact correct all of the APAR's listed as corrected. You had a competitor (which I did not know of at the time) ASI Superset Utilities; better functionality, and better support than 5734-UT1 had ever had. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Shmuel Metz asks: You don't think that, e.g., the Honeywell H-200, IBM 650, IBM 1401, RCA 301, UNIVAC 1004, UNIVAC SS-80/SS-90, had already destroyed the reproducer and tabulator markets and that the ubiquity of tape drives had already destroyed the collator and sorter market? Heading in that direction by 1964, agreed. I'll amend my remark to say that IBM held the leading market position in data processing prior to the System/360. Some of that market was electromechanical, and some was electronic. The System/360 was bound to displace most of both segments...or destroy the company. I'll respond to a couple interesting points Peter Farley raised: IBM never seems to have acquired or internalized the value of the concept of a loss leader. I'm not 100% sure what you mean by loss leader here. Certain pricing practices can be illegal, and to my knowledge IBM doesn't do illegal (or unethical). But that point aside I still disagree. There's ample evidence for my disagreement in IBM's annual report. Take a look at IBM's research and development investments. Compare them to other corporations' investments. IBM's management clearly understands the concept of losing money for many, many years before turning a profit on those considerable investments. Or not turning a profit -- many investments simply don't bear fruit despite best efforts. Power servers are a good example of a success. IBM is the leader in the distributed UNIX server market and by quite a margin. Yet rewind the clock a couple decades and *nobody* would have predicted that. IBM doggedly, persistently focused on succeeding in that market. And IBM did it the old fashioned way: with lots of long-term investments to develop and to build better products than the competition. ...IBM is famous for disposing of any money-losing product to maintain the corporate philosophy of always (and only) being in high-margin businesses. I don't know that IBM is particularly famous for spinning off business units. Companies such as ATT, General Motors, USX/U.S. Steel, Westinghouse, and General Electric among others would outrank IBM on that score. I can think of many companies that bear zero resemblance to their pasts, but that's not true of IBM. IBM began as a business data processing solutions company with its Hollerith roots and is still a business data processing solutions company. Moreover, IBM has been transforming itself through practically its entire corporate life. Spinoffs are hardly new. IBM sold its food scale business to Hobart in *1934*, for example. And the food scale business is still a great business for Hobart. Hobart's current models are also much, much better than the 1934 models. But how are spinoffs deliberately reducing the effectiveness of new technology, which was what you accused IBM of doing? Isn't spinning off a particular business to a better steward for the circumstances exactly the opposite? Hitachi builds fantastic hard disk spindles and continues to find ways to improve the state-of-the-art. Lenovo builds great personal computers and has been expanding into new mobile phones and tablets. Lexmark keeps advancing printing technology. Toshiba, which already had a significant retail systems market presence, continues to figure out new ways to make retailing more efficient. But even if Hitachi, Lenovo, Lexmark, and Toshiba aren't increasing the effectiveness of new technology, why would that be IBM's fault? Wouldn't it be the fault of Hitachi, Lenovo, Lexmark, and/or Toshiba? By the way, these were not money-losing businesses, at least not inherently. Otherwise the companies I just named wouldn't be successful in those businesses as they are. Wouldn't a company maniacally focused on expanding the effectiveness of new technology -- on innovating -- be precisely the company that spins off its mature business units? High-margin businesses is practically a synonym for highly innovative products, or at least those terms are highly correlated. Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Hi Timothy, You make many interesting points in your email. I think there are some things about IBM that you don't know, although that may not be the case. As many of you know, I worked a little over 3 years for IBM until February this year in Dubuque, Iowa. They have a very high turnover rate there. The main reason is low pay. Most people, including myself, made about half what they made before working for IBM. This is only the employees that were hired since July of 2009, when the Dubuque center opened. They do get a lot of good people there, but because of poor pay, they are not happy, and many leave as soon as they can. One good thing is they don't discriminate for age. I was hired at 61 years old. One other thing I didn't like was the computer operations was usually run from India. Many of the people were very sharp, but it was very hard to understand them. I really wonder if IBM is on a downhill slide. I can't imagine grossly underpaying so many employees and not starting to slide downhill. Eric Bielefeld z/OS Systems Programmer Milwaukee, Wisconsin - Original Message - From: Timothy Sipples sipp...@sg.ibm.com Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, July 12, 2013 1:37 A Subject: Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers Heading in that direction by 1964, agreed. I'll amend my remark to say that IBM held the leading market position in data processing prior to the System/360. Some of that market was electromechanical, and some was electronic. The System/360 was bound to displace most of both segments...or destroy the company. I'll respond to a couple interesting points Peter Farley raised: ( Deleted text) Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
re: http://www.garlic.com/~lynn/2013i.html#71 Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers 2nd hand about testimony in the gov. legal action ... claim that top executive from one of the seven dwarfs testified that by the late 50s every computer company realized that the single most important market criteria had become a compatible product line ... however, in the 60s, only ibm management was able to force the lab managers responsible for different products to toe the compatibility product requirement. the implication was that since IBM was the only company that provided the single most important market requirement (compatibility) ... they might even be able to get every other detail wrong and still dominate the market. ibm and the 7 dwarfs http://en.wikipedia.org/wiki/BUNCH old post about end of 360 advance computing system http://people.cs.clemson.edu/~mark/acs_end.html mentions that ibm executives shut the project down because they were afraid that it would advance computer technology too fast and they would loose control of the market ... shortly after amdahl leaves and starts his clone 360 company. end of the page has features from ACS-360 showing up in es/9000 more than 25yrs later. note that this was in the time that clone controllers were starting to appear. IBM responded with the Future System effort ... which was to make the controller interface so tightly integrated and complex that it would significantly raise the bar for clone controller businesses. lots of past posts (and various web references) to future system http://www.garlic.com/~lynn/submain.html#futuresys Future System was completely different and incompatible with 360/370 ... and internal politics were shutting down 370 projects ... the resulting lack of 370 products during the period is credited with giving the clone processors a market foothold the subsequent failure of future system effort is claimed to cast dark shadow over the company for decades (as well as significant change in corporate culture to sycophancy and make no waves under Opel and Akers) ... contributing to the big downturn and going into the red in the early 90s ... although another major contributing factor was the strangle-hold that the communication group had on datacenters ... trying to fight off client/server and distributed computing and preserve its (emulated) dumb terminal install base. some past posts http://www.garlic.com/~lynn/subnetwork.html#terminal also it wasn't until 3090 that you see new computer ... both 303x 3081 are qd efforts using left-over technology ... some reference here: http://www.jfsowa.com/computer/memo125.htm trivia ... as an undergraduate in the 60s i did lots of changes to both os/360 and cp/67. when cp/67 was first delivered to univ. it had terminal support for 1052 2741 terminals (and did automatic terminal identification ... any terminal could be connected to any controller port and cp/67 would figure out type of terminal). The univ had lots of tty/ascii terminals ... and I added tty support to cp67 ... doing it so that it was also dynamically recognized (any terminal type on any port). I wanted to have a single dial-up number for all terminals (hunt group) ... finding the available line to the controller ... however it didn't quite work. While the ibm 360 terminal controller allowed type of line-scanner to be dynamically associated with any port ... they had done a short-cut and hard-wired line-speed oscillator to each port. this was major motivation for univ. to start clone controller project ... started with interdata/3 minicomputer (instruction set very similar to 360), reverse engineer the channel interface and built channel interface board for interdata/3, the interdata/3 was programmed to emulate ibm controller ... but in addition to dynamically associate line-scanner type with each port ... it could also dynamically determine terminal baud rate. later four of us are written up as being responsible for (some part of) clone controller business. some past posts http://www.garlic.com/~lynn/subtopic.html#360pcm it was then enhanced with an interdata/4 to handle the channel interface and cluster of interdata/3s handling the port interfaces. later perkin-elmer buys interdata and the product continues to be sold under the perkin-elmer logo. A decade ago, visiting a large east coast financial transaction datacenter ... there is one such perkin-elmer box handling significant percentage of point-of-sale dial-up terminals in the eastern part of the country. -- 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
sipp...@sg.ibm.com (Timothy Sipples) writes: Power servers are a good example of a success. IBM is the leader in the distributed UNIX server market and by quite a margin. Yet rewind the clock a couple decades and *nobody* would have predicted that. IBM doggedly, persistently focused on succeeding in that market. And IBM did it the old fashioned way: with lots of long-term investments to develop and to build better products than the competition. re: http://www.garlic.com/~lynn/2013i.html#71 Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers http://www.garlic.com/~lynn/2013i.html#73 Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers the server market is combined risc cisc (mostly x86) chips. as mentioned the server market is brand name vendors and doesn't include the huge explosion in number of servers being built by the large cloud operators (claim is that the number of cloud servers is larger than the total brand name server market) ... and is the major growth market. news the last couple weeks is IBM is aggresively looking at moving into this high growth cloud market ... but it is meeting steep competition. this is really long-winded discussion on linkedit http://lnkd.in/mGd4j5 on The Cloud is killing traditional hardware and software http://www.infoworld.com/d/cloud-computing/the-cloud-killing-traditional-hardware-and-software-216963 part of the issue is that cloud operators have claimed for some time they are building servers for 1/3rd the price of brand name servers. there are various rumors that some of the large server vendors have moved into white box assemblies for cloud operators (matching large cloud operators price) and selling to smaller private cloud operations (that aren't large enough to setup their own server build operations). -- 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Eric Bielefeld wrote: begin extract One other thing I didn't like was the computer operations was usually run from India. Many of the people were very sharp, but it was very hard to understand them. /end extract Unfamiliar accents are hard to understand; and Americans in particular often have difficultry with them because they mostly live in monoglot, albeit not necessarily anglophone, environments. It helps to try to remember that the person whose accent you find difficult may well be having difficulties of the same kind with your accent. What helps even more is some considerable facility in more than one natural language, but that is not something that most Americans ever acquire. In the past Timothy has argued that market forces will over time adjust IBM salaries upward where they are too low. This does not always happen. The market for displaced, ageing IBM z/OS sysprogs in those parts of the world where the number of mainframe shops is declining steadily has almost none of the characteristics of a traditional 'free' labor market. Moreover, the time frame in which such competitive pressures operate, when they do operate, is often, even usually, very like that 'long run', in which Keynes reminded us that we shall all be dead. IBM throve for many years when its personnel policies were much less hard-nosed, even paternalistic; and its current practices, while they are not nearly so savage as those of other companies in other industries, have been very effective in influencing the ablest of the young to seek employment at Google instead of IBM. Worse, corporate cultures get what they deserve. Labor-market immobility in Western Europe and the other rigidities it brought in train resulted from legislation designed to protect employees from what was perceived to be 'capitalist greed' , and it is now quite likely that as stultifying employment regulations are dismantled there they will be salvaged and exported to the United States to be reerected here. 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Actually, I should have added that most of the time when we did IPLs or upgrades, we used Sametime to communicate with the people from India. Their English is actually pretty good. There was enough times when we had voice chats up though that often made things hard. I have to admit that I only know English. I took French for 2 years in high school, but never had an occasion to use it. In the US we are kind of spoiled, as English has become the standard language for business around the world. I have a son who has lived for the last 6 years in Seoul, S. Korea. When he talks in Korean to someone, he sounds pretty fluent to me, but he says he has a long way to go. Eric Bielefeld Retired z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 Sent: Friday, July 12, 2013 10:33 AM Subject: Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers Eric Bielefeld wrote: begin extract One other thing I didn't like was the computer operations was usually run from India. Many of the people were very sharp, but it was very hard to understand them. /end extract Unfamiliar accents are hard to understand; and Americans in particular often have difficultry with them because they mostly live in monoglot, albeit not necessarily anglophone, environments. It helps to try to remember that the person whose accent you find difficult may well be having difficulties of the same kind with your accent. What helps even more is some considerable facility in more than one natural language, but that is not something that most Americans ever acquire. 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
re: http://www.garlic.com/~lynn/2013i.html#71 Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers http://www.garlic.com/~lynn/2013i.html#73 Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers http://www.garlic.com/~lynn/2013i.html#74 Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers for the fun of it ... from today at computer history museum http://www.computerhistory.org/tdih/July/12/ July 12, 1949 IBM's Watson believes electronics will replace moving parts At an IBM sales meeting, Thomas J. Watson Jr. predicts that all moving parts in machines would be replaced by electronics within 10 years. Watson's visionary ideals of where the fledgling computer industry might go helped lead his company to dominance in production of all varieties of computers, from work stations to personal computers. ... snip ... -- 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
On Jul 12, 2013, at 1:37 AM, Timothy Sipples wrote: ---SNIP-- IBM never seems to have acquired or internalized the value of the concept of a loss leader. I'm not 100% sure what you mean by loss leader here. Certain pricing practices can be illegal, and to my knowledge IBM doesn't do illegal (or unethical). But that point aside I still disagree. There's ample evidence for my disagreement in IBM's annual report. Take a look at IBM's research and development investments. Compare them to other corporations' investments. IBM's management clearly understands the concept of losing money for many, many years before turning a profit on those considerable investments. Or not turning a profit -- many investments simply don't bear fruit despite best efforts. An example (software wise) was the TSO UTILITIES (can't remember if it was a FDP or IUP or... pretty sure it wasn't an PP). This seeming simple product was *MUCH NEEDED* a lot of the functionality (IEBCOPY) was at that point authorized and forbidden (ie going against IBM stated direction of no authorized programs were to run under TSO. You had a competitor (which I did not know of at the time) but for us you were the only game in town. (we were more or less happy campers and would have continued the monthly charge) but IBM yanked it. SORT (at the time) was not a front and center stage product until IBM started to get real competition (ie Syncsort and CA plus one or two other whose names eludes me). Somebody finally put the spurs in IBM's side and it is now a strong competitor to Syncsort. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
On Jul 12, 2013, at 10:33 AM, John Gilmore wrote: In the past Timothy has argued that market forces will over time adjust IBM salaries upward where they are too low. This does not always happen. The market for displaced, ageing IBM z/OS sysprogs in those parts of the world where the number of mainframe shops is declining steadily has almost none of the characteristics of a traditional 'free' labor market. Moreover, the time frame in which such competitive pressures operate, when they do operate, is often, even usually, very like that 'long run', in which Keynes reminded us that we shall all be dead. John, In addition say 1995 IBM was trying to get rid of sysprogs (at least according to several IBMers I talked with). Their current product offering of systems was supposedly the first step. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Ed, Java initially runs intepreted JVM byte code. As the program runs, the JVM invokes a just in time compiler to transform the byte code into native z series instructions. As I understand it, the common back end that is being discussed for COBOL, PL/I, C/C++, et al. is this just in time compiler/optimizer. I wish z/OS did for Java what the i does. The javac compiler creates a byte code .class file. However, attached to this byte code file is actual pSeries native instruction which is what is really run. The i has a lot of interesting things. What blew me away was that the compilers produce TIMI instructions (similar in concept to Java byte code). The first time a program is run, the OS compiles the TIMI into native code and attaches that code to the program object and thereafter runs the program object code. Well, sort of. Because this compiler may be improved. If this happens, or if the TIMI code is moved to another processor, the OS will recompile and recreate the program object. All automatically. Must drive auditors and change control people up the wall. On Thu, Jul 11, 2013 at 12:22 AM, Ed Gould edgould1...@comcast.net wrote: Timothy: It depends... lets see some results before congratulating them. *IF* Java is any indications I suspect there isn't a big enough machine around to run one program. Face it JAVA is a PIG when it comes to burning up cpu resources. Ed On Jul 11, 2013, at 12:06 AM, Timothy Sipples wrote: Peter Farley opines: They [IBM] have, time and again, shown themselves quite capable of deliberately reducing the effectiveness of new technology to preserve their revenue stream for a few more quarters. Examples? I'll offer a counterexample: the System/360. IBM led the electromechanical tabulating and accounting equipment market, and the System/360 utterly destroyed the very market IBM dominated. The System/360 was either going to be history's stupidest act of corporate suicide or one of history's most brilliant business successes, depending on how it turned out. More recent examples are obviously more relevant than older ones. No points awarded if the examples have other plausible motives available. By the way, this question has just been answered for COBOL. Enterprise COBOL Version 5.1 is available, now. Turn on the new compiler optimizations and measure the results. They be good. In my opinion it's delusional to think IBM would invest huge sums and many years developing (and shipping!) an entirely new backend for a product it didn't believe in and that it didn't expect to sell. Utterly, completely delusional, with absolutely no sense of reality -- business or technical. In my personal view. Sometimes people post conspiratorial stuff here and then I think, That individual is not rational in thought. Maybe others' experiences are different, but I haven't persuaded many people to act when I present an irrational argument. They just look at me funny and say something like, OK, that's very interesting. Thank you for sharing. I've learned to be a little more thoughtful in trying to understand the world, rationally. I applaud IBM for Enterprise COBOL V5 and recommend others do the same. Well done, and more, please. --**--** --**-- Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com --**--** -- 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 -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Examples: See Lynn Wheeler's many postings on SNA, TCPIP, FICON, etc., etc. His stories will tell you a lot more than I can. See also the FBA-vs-CKD debates and histories, with MVS+CKD always the winner. See also the (several) deliberate cutbacks and staff reductions over the decades for VM and VSE development staff and repeated increases in VM+VSE pricing because VM+VSE shops had most of the functionality of MVS at less than half the price and requiring less than half the systems staff to monitor, maintain and upgrade. Any threat to MVS profits was always the loser. As a result, there are almost no VM+VSE shops left in the Americas, though I am told there is still a customer base left in the Euro zone. IBM never seems to have acquired or internalized the value of the concept of a loss leader. It really is OK to have products you lose money on when they bring in more business overall, but IBM is famous for disposing of any money-losing product to maintain the corporate philosophy of always (and only) being in high-margin businesses. OK for executive bonuses I guess but rotten for customers who may actually like and/or need the losing products. As for COBOL, at the moment I agree with you, sight unseen. I am not in any position to even ask for the new version of COBOL (though I do expect to see it in my shop sometime in the next year), so I have no chance of testing anything, but I will be very curious to see the actual results when it arrives. I was, as you indirectly accuse me of, engaging in speculative conspiracy theories about the robustness of the new backend for COBOL. It really is not very hard to do because IBM provides so much ammunition with which to do it, and it is thus very hard to resist. But I will desist in this particular speculation until I can see it for myself. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Thursday, July 11, 2013 1:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers Peter Farley opines: They [IBM] have, time and again, shown themselves quite capable of deliberately reducing the effectiveness of new technology to preserve their revenue stream for a few more quarters. Examples? I'll offer a counterexample: the System/360. IBM led the electromechanical tabulating and accounting equipment market, and the System/360 utterly destroyed the very market IBM dominated. The System/360 was either going to be history's stupidest act of corporate suicide or one of history's most brilliant business successes, depending on how it turned out. More recent examples are obviously more relevant than older ones. No points awarded if the examples have other plausible motives available. By the way, this question has just been answered for COBOL. Enterprise COBOL Version 5.1 is available, now. Turn on the new compiler optimizations and measure the results. They be good. In my opinion it's delusional to think IBM would invest huge sums and many years developing (and shipping!) an entirely new backend for a product it didn't believe in and that it didn't expect to sell. Utterly, completely delusional, with absolutely no sense of reality -- business or technical. In my personal view. Sometimes people post conspiratorial stuff here and then I think, That individual is not rational in thought. Maybe others' experiences are different, but I haven't persuaded many people to act when I present an irrational argument. They just look at me funny and say something like, OK, that's very interesting. Thank you for sharing. I've learned to be a little more thoughtful in trying to understand the world, rationally. I applaud IBM for Enterprise COBOL V5 and recommend others do the same. Well done, and more, please. -- 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
john.archie.mck...@gmail.com (John McKown) writes: Java initially runs intepreted JVM byte code. As the program runs, the JVM invokes a just in time compiler to transform the byte code into native z series instructions. As I understand it, the common back end that is being discussed for COBOL, PL/I, C/C++, et al. is this just in time compiler/optimizer. I wish z/OS did for Java what the i does. The javac compiler creates a byte code .class file. However, attached to this byte code file is actual pSeries native instruction which is what is really run. The i has a lot of interesting things. What blew me away was that the compilers produce TIMI instructions (similar in concept to Java byte code). The first time a program is run, the OS compiles the TIMI into native code and attaches that code to the program object and thereafter runs the program object code. Well, sort of. Because this compiler may be improved. If this happens, or if the TIMI code is moved to another processor, the OS will recompile and recreate the program object. All automatically. Must drive auditors and change control people up the wall. I've been in some discussion about whether JAVA was done totally independent of spring ... or with some spring overloap ... from Spring documentation: A Client-Side Stub Interpreter Peter B. Kessler Abstract We have built a research operating system in which all services are presented through interfaces described by an interface description language. The system consists of a micro-kernel that supports a small number of these interfaces, and a large number of interfaces that are implemented by user-level code. A typical service implements one or more interfaces, but is a client of many other interfaces that are implemented elsewhere in the system. We have an interface compiler that generates client-side and service-side stubs to deliver calls from clients to services providing location transparency if the client and server are in different address spaces. The code for client-side stubs was occupying a large amount of the text space on our clients, so a stub interpreter was written to replace the client-side stub methods. The result was that we traded 125k bytes of stub code for 13k bytes of stub descriptions and 4k bytes of stub interpreter. This paper describes the stub interpreter, the stub descriptions, and discusses some alternatives. ... snip ... Disclaimer: after leaving IBM ... we were asked about taking on turning Spring out as commercial product http://en.wikipedia.org/wiki/Spring_%28operating_system%29 and green reference: http://en.wikipedia.org/wiki/Java_%28software_platform%29 trivia: general manager of the sun business group that included JAVA had previously been VP of software development at MIPS ... done some startups before that ... and earlier had been at the Los Gatos VLSI tools group and one of two people responsible for what became IBM's vs/pascal (although I was in research, I also had offices and labs in LSG bldg). -- 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
In of4dd8582a.087bd948-on48257ba5.0018d4de-48257ba5.001c2...@sg.ibm.com, on 07/11/2013 at 01:06 PM, Timothy Sipples sipp...@sg.ibm.com said: I'll offer a counterexample: the System/360. IBM led the electromechanical tabulating and accounting equipment market, and the System/360 utterly destroyed the very market IBM dominated. You don't think that, e.g., the Honeywell H-200, IBM 650, IBM 1401, RCA 301, UNIVAC 1004, UNIVAC SS-80/SS-90, had already destroyed the reproducer and tabulator markets and that the ubiquity of tape drives had already destroyed the collator and sorter market? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
On 10/07/2013 1:04 PM, Farley, Peter x23353 wrote: Based on the announced capability to use new (to COBOL) TUNE and ARCH compiler options, I suspect the answer to that question is that it is the same shared backend. I heard a rumour that COBOL was going to use the same back-end that the Java JIT uses. It was also suggested PL/1 and C/C++ would also be using the same universal back-end in the future. Having seen the output of that backend during a recent research project in MetalC, I am quite impressed by its capabilities to *really* optimize the instruction stream, unlike the sadly lacking current COBOL backend. I think we're going to like it. A *lot*. At least, I have some real hope that we will, though this *is* IBM we are talking about. Do they really want to significantly optimize the existing COBOL executable base as it is recompiled for maintenance and enhancements, reducing MSU usage all over the place? They have, time and again, shown themselves quite capable of deliberately reducing the effectiveness of new technology to preserve their revenue stream for a few more quarters. We will see. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Tuesday, July 09, 2013 9:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers Snipped It has taken us a while, but we now have a modern backend (code generator and optimizer) for COBOL that can exploit the latest hardware, and will support DFP, AMODE 64 and many of the other z/OS system features that we have not be able to exploit in the past. Is that new backend bespoke for COBOL or is it shared with PL/1, C/C++, Java? Cheers, TomR COBOL is the Language of the Future! -- 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
It has taken us a while, but we now have a modern backend (code generator and optimizer) for COBOL that can exploit the latest hardware, and will support DFP, AMODE 64 and many of the other z/OS system features that we have not be able to exploit in the past. Is that new backend bespoke for COBOL or is it shared with PL/1, C/C++, =20 Java? Java used it first, now COBOL will be using it. Next up, PL/I, I think, and then C/C++. Eventually all of the active compilers will use the same backend so that when new hardware comes out we can exploit it with all langs quickly! Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
So should we ZAAP,ZIIP or z??P? In a message dated 07/10/13 19:21:45 Central Daylight Time, tmr...@stlvm20.vnet.ibm.com writes: Eventually all of the active compilers will use the same backend so that when new hardware comes out we can exploit it with all langs quickly! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Forget zAAP for sure on current hardware. For now, zIIP. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of efinnell15 Sent: Wednesday, July 10, 2013 8:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers So should we ZAAP,ZIIP or z??P? In a message dated 07/10/13 19:21:45 Central Daylight Time, tmr...@stlvm20.vnet.ibm.com writes: Eventually all of the active compilers will use the same backend so that when new hardware comes out we can exploit it with all langs quickly! -- 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Peter Farley opines: They [IBM] have, time and again, shown themselves quite capable of deliberately reducing the effectiveness of new technology to preserve their revenue stream for a few more quarters. Examples? I'll offer a counterexample: the System/360. IBM led the electromechanical tabulating and accounting equipment market, and the System/360 utterly destroyed the very market IBM dominated. The System/360 was either going to be history's stupidest act of corporate suicide or one of history's most brilliant business successes, depending on how it turned out. More recent examples are obviously more relevant than older ones. No points awarded if the examples have other plausible motives available. By the way, this question has just been answered for COBOL. Enterprise COBOL Version 5.1 is available, now. Turn on the new compiler optimizations and measure the results. They be good. In my opinion it's delusional to think IBM would invest huge sums and many years developing (and shipping!) an entirely new backend for a product it didn't believe in and that it didn't expect to sell. Utterly, completely delusional, with absolutely no sense of reality -- business or technical. In my personal view. Sometimes people post conspiratorial stuff here and then I think, That individual is not rational in thought. Maybe others' experiences are different, but I haven't persuaded many people to act when I present an irrational argument. They just look at me funny and say something like, OK, that's very interesting. Thank you for sharing. I've learned to be a little more thoughtful in trying to understand the world, rationally. I applaud IBM for Enterprise COBOL V5 and recommend others do the same. Well done, and more, please. Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Timothy: It depends... lets see some results before congratulating them. *IF* Java is any indications I suspect there isn't a big enough machine around to run one program. Face it JAVA is a PIG when it comes to burning up cpu resources. Ed On Jul 11, 2013, at 12:06 AM, Timothy Sipples wrote: Peter Farley opines: They [IBM] have, time and again, shown themselves quite capable of deliberately reducing the effectiveness of new technology to preserve their revenue stream for a few more quarters. Examples? I'll offer a counterexample: the System/360. IBM led the electromechanical tabulating and accounting equipment market, and the System/360 utterly destroyed the very market IBM dominated. The System/360 was either going to be history's stupidest act of corporate suicide or one of history's most brilliant business successes, depending on how it turned out. More recent examples are obviously more relevant than older ones. No points awarded if the examples have other plausible motives available. By the way, this question has just been answered for COBOL. Enterprise COBOL Version 5.1 is available, now. Turn on the new compiler optimizations and measure the results. They be good. In my opinion it's delusional to think IBM would invest huge sums and many years developing (and shipping!) an entirely new backend for a product it didn't believe in and that it didn't expect to sell. Utterly, completely delusional, with absolutely no sense of reality -- business or technical. In my personal view. Sometimes people post conspiratorial stuff here and then I think, That individual is not rational in thought. Maybe others' experiences are different, but I haven't persuaded many people to act when I present an irrational argument. They just look at me funny and say something like, OK, that's very interesting. Thank you for sharing. I've learned to be a little more thoughtful in trying to understand the world, rationally. I applaud IBM for Enterprise COBOL V5 and recommend others do the same. Well done, and more, please. -- -- Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Based on the announced capability to use new (to COBOL) TUNE and ARCH compiler options, I suspect the answer to that question is that it is the same shared backend. Having seen the output of that backend during a recent research project in MetalC, I am quite impressed by its capabilities to *really* optimize the instruction stream, unlike the sadly lacking current COBOL backend. I think we're going to like it. A *lot*. At least, I have some real hope that we will, though this *is* IBM we are talking about. Do they really want to significantly optimize the existing COBOL executable base as it is recompiled for maintenance and enhancements, reducing MSU usage all over the place? They have, time and again, shown themselves quite capable of deliberately reducing the effectiveness of new technology to preserve their revenue stream for a few more quarters. We will see. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Tuesday, July 09, 2013 9:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers Snipped It has taken us a while, but we now have a modern backend (code generator and optimizer) for COBOL that can exploit the latest hardware, and will support DFP, AMODE 64 and many of the other z/OS system features that we have not be able to exploit in the past. Is that new backend bespoke for COBOL or is it shared with PL/1, C/C++, Java? Cheers, TomR COBOL is the Language of the Future! -- 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Understood. Thanks! I am definitely going to take a look a zcobol, just for fun. Frank From: Don Higgins d...@higgins.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Saturday, July 6, 2013 4:15 AM Subject: Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers Frank, all I saw some of the floating point usage type names used in a COBOL standard proposed draft online during the development. I added the types for IBM specific HFP type names which are IBM specific as opposed to international BFP or DFP standards based. The type names used could be easily changed in the zcobol open source once there was agreement on how to define all nine specific floating point formats implemented in IBM hardware which I think would be a requirement for the IBM version of COBOL if it is to be used to process data from other programs that support any of the 9 floating point types. But my only intent in posting response about the zcobol floating point support was to provide an example of what that support might look like. zcobol is still an unfinished open source project with many other standard COBOL features still missing, and I have fully retired from the zcobol and z390 development effort as of last year. Don Higgins d...@higgins.net www.don-higgins.net -- 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
I realize that this is belated but yes I would vigorously dispute him. Mike Cowlishaw of Rexx renown worked diligently on defining decimal floating point and the standard for it. The z series has had decimal floating point for a number of years. It has been supported in PL1, C/C++ and Java. To date it has NOT been implemented in COBOL despite the claim for Java interoperability and the fact that decimal floating point natively supports 6 types of rounding. Clark, if you still attended SHARE and our numerous discussions of what z/OS COBOL customers want added to COBOL, you would know that almost no one is interested in adding a new floating point data type to COBOL, (other than you). OTH, IBM is interested in it, and that is why we have accepted the requirement to add DFP data type support to COBOL, which you would also know if you still attended SHARE or asked someone in IBM. Finally, the new version of COBOL (V5.1) uses DFP instructions to do decimal arithmetic faster on other data types, such as external decimal and packed decimal. Finally, just to explain my email closing, COBOL will always be with us because it does what people need it do efficiently, and because there is so much of it running the world today that even if we spent all of our money and time trying to convert it to some other language, we would still have not completed the job in 20 years. Besides, if you convert an application from one language to another, you end up with the same application that you started with, except maybe with new bugs and maybe less function, and you just lost a lot of money. And whatever language you converted to will be legacy in a few years. Google Java is dead for some fun. Ruby killed Java, Groovy killed Ruby, etc, etc. Yeah, I have heard x is dead before, eh? It has taken us a while, but we now have a modern backend (code generator and optimizer) for COBOL that can exploit the latest hardware, and will support DFP, AMODE 64 and many of the other z/OS system features that we have not be able to exploit in the past. Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
On 8 Jul 2013 11:15:24 -0700, in bit.listserv.ibm-main you wrote: I realize that this is belated but yes I would vigorously dispute him. Mike Cowlishaw of Rexx renown worked diligently on defining decimal floating point and the standard for it. The z series has had decimal floating point for a number of years. It has been supported in PL1, C/C++ and Java. To date it has NOT been implemented in COBOL despite the claim for Java interoperability and the fact that decimal floating point natively supports 6 types of rounding. Clark, if you still attended SHARE and our numerous discussions of what z/OS COBOL customers want added to COBOL, you would know that almost no one is interested in adding a new floating point data type to COBOL, (other than you). OTH, IBM is interested in it, and that is why we have accepted the requirement to add DFP data type support to COBOL, which you would also know if you still attended SHARE or asked someone in IBM. Finally, the new version of COBOL (V5.1) uses DFP instructions to do decimal arithmetic faster on other data types, such as external decimal and packed decimal. I am well aware that the interest in COBOL at SHARE was low up until 2002 when I stopped attending and that requests that did come in for the most part were tactical hitting such things as debugging capability. I would not be surprised that this has continued. I see the requests for XML support as being tactical - meet an immediate need as opposed to strategic. I would agree with anyone who says that top applications management for the most part has no interest in DFP and probably no knowledge of it. I also was an oddball in the systems programming side in that I used COBOL to manipulate the SMF records which would have been easier if COBOL had supported the true binary USAGES and the BIT usages of the 2002 standard. I suspect that there was not that much greater clamor in the C/C++ and PL/1 communities at SHARE for Decimal Floating Point than there was in the COBOL community. The strategic direction for those two languages was to implement Decimal Floating Point. I can make the case that it was too late for all of the systems that needed peculiar rounding rules such as round half to the nearest even. This was also true of the Millenium Language extensions which would have greatly eased the year 2000 project I was on had they been introduced in 1995 or 1996 before we started work in earnest to meet a 1998 deadline for one of the major systems. The case for implementing many of the constructs of the 2002 standard would be what they can do for code generators and for interoperability with other languages (especially JAVA). I also believe that I was clear in my posting that a major selling effort would have to be made to many application managements since they still have not embraced the 1985 improvements and even to those that take advantage of the 1985 standard. I have concluded that many believe that the combined costs of doing the implementation of what I believe would be useful plus the cost of educating the current application managements as to what they can do for their shops isn't worth the effort. Finally, just to explain my email closing, COBOL will always be with us because it does what people need it do efficiently, and because there is so much of it running the world today that even if we spent all of our money and time trying to convert it to some other language, we would still have not completed the job in 20 years. Besides, if you convert an application from one language to another, you end up with the same application that you started with, except maybe with new bugs and maybe less function, and you just lost a lot of money. And whatever language you converted to will be legacy in a few years. Google Java is dead for some fun. Ruby killed Java, Groovy killed Ruby, etc, etc. Yeah, I have heard x is dead before, eh? Here, I have seen packages (SAP, Oracle Financials, etc.) replace major systems and I believe that most of the systems that I worked at one client in the 1990's which were on a 390 are now replaced by packages running on either AIX or Windows. Both the client and those of us who worked on the systems believed that replacement was the only hope for major improvement. While I am skeptical about the language of the day phenomena, COBOL really wasn't designed to handle many of the things on the web and really wasn't that great for writing reports. There is a reason why companies paid big bucks for DYL280, Easytrieve, etc. Ireally liked DYL280 for many things over COBOL. While systems are being just upgraded COBOL will live in a shop. When they are replaced, the replacements probably won't be in COBOL. I am not seeing the demand being that great for either COBOL programmers or mainframe systems programmers so I got out just in time. I don't see COBOL being a major force in the Windows and Unix Environments which have increasing shares of the market. I
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Frank, all I saw some of the floating point usage type names used in a COBOL standard proposed draft online during the development. I added the types for IBM specific HFP type names which are IBM specific as opposed to international BFP or DFP standards based. The type names used could be easily changed in the zcobol open source once there was agreement on how to define all nine specific floating point formats implemented in IBM hardware which I think would be a requirement for the IBM version of COBOL if it is to be used to process data from other programs that support any of the 9 floating point types. But my only intent in posting response about the zcobol floating point support was to provide an example of what that support might look like. zcobol is still an unfinished open source project with many other standard COBOL features still missing, and I have fully retired from the zcobol and z390 development effort as of last year. Don Higgins d...@higgins.net www.don-higgins.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
The lack of full floating point support after all this time in IBM COBOL does seem to indicate a decline in its support. For an example of what full floating point support in mainframe COBOL looks like, check out the portable open source zCOBOL which runs on Windows, Linux, and Apple OSX. The compiler produces readable HLASM assembler source with data field labels which in turn runs on z390 portable mainframe assembler and emulator written entirely in open source J2SE java. zCOBOL supports HFP, BFP, and DFP using the 2002 COBOL standard recommended naming conventions for the 9 different floating point data types. Here is link to article with example floating point compute statement using all 9 floating point types: http://www.z390.org/zcobol/demo/callcomp/zCOBOL_COMPUTE.pdf Don Higgins d...@higgins.net www.don-higgins.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
Interesting. Comments... The COBOL standard does not assign those names you've given. Rather, the proposed followup standard does, except that it does not have those FLOAT-HEX-# usages. And in fact, I'm of the believe that the COBOL 2002 FP usages indicate the following: 1. FLOAT-SHORT COMP-1 2. FLOAT-LONG COMP-2 3. FLOAT-EXTENDED What led you to your belief? Open COBOL has implemented the above equivalences, as has Micro Focus which explicitly states USAGE FLOAT-SHORT is equivalent to USAGE COMPUTATIONAL-1. USAGE FLOAT-LONG is equivalent to USAGE COMPUTATIONAL-2. 12) The usages float-short, float-long and float-extended define signed numeric data items that are held in a floating-point format suitable for the machine on which the runtime module is to run. The size and permitted range of values for these fields is defined by the implementor. Any value that may be held in a data item of usage float-short shall also be expressible in a data item of usage float-long. Any value that may be held in a data item of usage float-long shall also be expressible in a data item of usage float-extended. Do you also support the following? BINARY-SHORT = COMP PIC S9(4) BINARY-LONG = COMP PIC S9(9) BINARY-EXTENDED = COMP PIC S9(18) From: Don Higgins d...@higgins.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, July 5, 2013 5:08 AM Subject: Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers The lack of full floating point support after all this time in IBM COBOL does seem to indicate a decline in its support. For an example of what full floating point support in mainframe COBOL looks like, check out the portable open source zCOBOL which runs on Windows, Linux, and Apple OSX. The compiler produces readable HLASM assembler source with data field labels which in turn runs on z390 portable mainframe assembler and emulator written entirely in open source J2SE java. zCOBOL supports HFP, BFP, and DFP using the 2002 COBOL standard recommended naming conventions for the 9 different floating point data types. Here is link to article with example floating point compute statement using all 9 floating point types: http://www.z390.org/zcobol/demo/callcomp/zCOBOL_COMPUTE.pdf Don Higgins d...@higgins.net www.don-higgins.net -- 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: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
On 21 Jun 2013 11:26:53 -0700, in bit.listserv.ibm-main you wrote: On Fri, 2013-06-21 at 15:18 -0300, Clark Morris wrote: And IBM thinks COBOL is the language of the future. Right and I sell bridges. Well... that's what Tom Ross says anyway. You'd dispute Tom? I realize that this is belated but yes I would vigorously dispute him. Mike Cowlishaw of Rexx renown worked diligently on defining decimal floating point and the standard for it. The z series has had decimal floating point for a number of years. It has been supported in PL1, C/C++ and Java. To date it has NOT been implemented in COBOL despite the claim for Java interoperability and the fact that decimal floating point natively supports 6 types of rounding. Java uses IEEE floating point and instead of adding the IEEE floating point types to COBOL as DEFINED in the 2002 standard and leaving the COMP-1 and COMP-2 type for hex floating point thus keeping upward compatibility, there is a conversion to or from hex floating point when dealing with Java. USAGE BIT and logical operations which are in the 2002 standard have not been implemented. There are OO classes for CICS in C/C++ and PL1. Are there any for COBOL? COBOL as defined in the 2002 standard can handle the SMF 14 and 30 records without going through contortions to handle the bit switches. COBOL 2002 finally has EXIT PERFORM and EXIT PARAGRAPH. Granted that a sales job would be needed to explain why management should care about the improvements made available in that standard but if it were the language of the future, it would be worth the expenditure. On the other hand, given many of the tales told here and probably the stories told about all of the features in the 1985 standard that have remained unused in many or most shops, IBM could well question whether it would be worth the effort. If the long term is movement to packages that are implemented in other languages anyway, improvement is money wasted. I believe that a lot less work is being done by COBOL programs than was done ten or fifteen years ago. Every SAP installation reduces the workload on COBOL by that much more. On other platforms the native COBOL file systems (there is no equivalent of VSAM for example) don't exist and the run-time costs can be high. From my following of comp.lang.cobol and what I see in the market place, COBOL is in its final years. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
On 19 Jun 2013 10:26:45 -0700, in bit.listserv.ibm-main you wrote: Graham, I believe RDz 7.6 does include the COBOL compiler, even 8.0 does. You just have to install and run on XP Pro. I have not tried what Barry mentions, running XP compatible virtual process under Windows 7. I have a co-worker that used it for awhile with mixed results, some things worked and some did not. How about a laptop with dual boot, both XP Pro and Windows 7. And IBM thinks COBOL is the language of the future. Right and I sell bridges. Clark Morris Cheers, Thomas Dunlap On 6/19/2013 11:39 AM, Graham Hobbs wrote: Thomas, Barry, Sorry to bother you again. Any chance you think/know that RDz 7.6 would run under XP virtual machine? If I downloaded/installed 7.6 (from SAC) do you think IBM may have removed the COBOL compiler? Cheers, Graham - Original Message - From: Thomas Dunlap thomas.dun...@att.net Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, June 19, 2013 5:06 AM Subject: Re: RDz or RDzEnterprise developers Graham, The issue is not which version of RDz but rather which version of Windows. Even with RDz 7.6 the COBOL compiler would not install on Windows 7. IBM has not made, plus as I understand it, a COBOL compiler which works on Windows 7. I am in the same position, but do have a System z to connect to as a test platform. I too wish I could test locally on Windows 7. Cheers, Thomas Dunlap On 6/18/2013 5:34 PM, Graham Hobbs wrote: Hello, I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and moved to a new Lenovo with Windows 7. There is no need for host connection, my development world is as a standalone, compile/link/run COBOL programs and COBOL/CICS transaction programs on the Lenovo is the critical need. But I understand that Rational Developer for System z V8.5 does not 'do' COBOL on Windows 7 so am thinking my new world should be Rational Developer for zEnterprise V8.0.3 and would appreciate any comments/advice about that. Graham Hobbs -- ___ Regards, Thomas DunlapChief Technology Officert...@themisinc.com Themis, Inc.http://www.themisinc.com1 (800) 756-3000 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Future of COBOL based on RDz policies was Re: RDz or RDzEnterprise developers
On Fri, 2013-06-21 at 15:18 -0300, Clark Morris wrote: And IBM thinks COBOL is the language of the future. Right and I sell bridges. Well... that's what Tom Ross says anyway. You'd dispute Tom? -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RDz or RDzEnterprise developers
Graham, The issue is not which version of RDz but rather which version of Windows. Even with RDz 7.6 the COBOL compiler would not install on Windows 7. IBM has not made, plus as I understand it, a COBOL compiler which works on Windows 7. I am in the same position, but do have a System z to connect to as a test platform. I too wish I could test locally on Windows 7. Cheers, Thomas Dunlap On 6/18/2013 5:34 PM, Graham Hobbs wrote: Hello, I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and moved to a new Lenovo with Windows 7. There is no need for host connection, my development world is as a standalone, compile/link/run COBOL programs and COBOL/CICS transaction programs on the Lenovo is the critical need. But I understand that Rational Developer for System z V8.5 does not 'do' COBOL on Windows 7 so am thinking my new world should be Rational Developer for zEnterprise V8.0.3 and would appreciate any comments/advice about that. Graham Hobbs -- ___ Regards, Thomas DunlapChief Technology Officert...@themisinc.com Themis, Inc.http://www.themisinc.com1 (800) 756-3000 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RDz or RDzEnterprise developers
You can use the XP Virtual Machine under Win 7 for archaic XP applications. (I'm still running MXG Business on the DOS version of DataFlex, in the XP Box on Win 7 Ultimate). -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Dunlap Sent: Wednesday, June 19, 2013 4:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RDz or RDzEnterprise developers Graham, The issue is not which version of RDz but rather which version of Windows. Even with RDz 7.6 the COBOL compiler would not install on Windows 7. IBM has not made, plus as I understand it, a COBOL compiler which works on Windows 7. I am in the same position, but do have a System z to connect to as a test platform. I too wish I could test locally on Windows 7. Cheers, Thomas Dunlap On 6/18/2013 5:34 PM, Graham Hobbs wrote: Hello, I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and moved to a new Lenovo with Windows 7. There is no need for host connection, my development world is as a standalone, compile/link/run COBOL programs and COBOL/CICS transaction programs on the Lenovo is the critical need. But I understand that Rational Developer for System z V8.5 does not 'do' COBOL on Windows 7 so am thinking my new world should be Rational Developer for zEnterprise V8.0.3 and would appreciate any comments/advice about that. Graham Hobbs -- ___ Regards, Thomas DunlapChief Technology Officert...@themisinc.com Themis, Inc.http://www.themisinc.com1 (800) 756-3000 -- 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: RDz or RDzEnterprise developers
Thomas, Barry, Sorry to bother you again. Any chance you think/know that RDz 7.6 would run under XP virtual machine? If I downloaded/installed 7.6 (from SAC) do you think IBM may have removed the COBOL compiler? Cheers, Graham - Original Message - From: Thomas Dunlap thomas.dun...@att.net Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, June 19, 2013 5:06 AM Subject: Re: RDz or RDzEnterprise developers Graham, The issue is not which version of RDz but rather which version of Windows. Even with RDz 7.6 the COBOL compiler would not install on Windows 7. IBM has not made, plus as I understand it, a COBOL compiler which works on Windows 7. I am in the same position, but do have a System z to connect to as a test platform. I too wish I could test locally on Windows 7. Cheers, Thomas Dunlap On 6/18/2013 5:34 PM, Graham Hobbs wrote: Hello, I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and moved to a new Lenovo with Windows 7. There is no need for host connection, my development world is as a standalone, compile/link/run COBOL programs and COBOL/CICS transaction programs on the Lenovo is the critical need. But I understand that Rational Developer for System z V8.5 does not 'do' COBOL on Windows 7 so am thinking my new world should be Rational Developer for zEnterprise V8.0.3 and would appreciate any comments/advice about that. Graham Hobbs -- ___ Regards, Thomas DunlapChief Technology Officert...@themisinc.com Themis, Inc.http://www.themisinc.com1 (800) 756-3000 -- 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: RDz or RDzEnterprise developers
Graham, I believe RDz 7.6 does include the COBOL compiler, even 8.0 does. You just have to install and run on XP Pro. I have not tried what Barry mentions, running XP compatible virtual process under Windows 7. I have a co-worker that used it for awhile with mixed results, some things worked and some did not. How about a laptop with dual boot, both XP Pro and Windows 7. Cheers, Thomas Dunlap On 6/19/2013 11:39 AM, Graham Hobbs wrote: Thomas, Barry, Sorry to bother you again. Any chance you think/know that RDz 7.6 would run under XP virtual machine? If I downloaded/installed 7.6 (from SAC) do you think IBM may have removed the COBOL compiler? Cheers, Graham - Original Message - From: Thomas Dunlap thomas.dun...@att.net Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, June 19, 2013 5:06 AM Subject: Re: RDz or RDzEnterprise developers Graham, The issue is not which version of RDz but rather which version of Windows. Even with RDz 7.6 the COBOL compiler would not install on Windows 7. IBM has not made, plus as I understand it, a COBOL compiler which works on Windows 7. I am in the same position, but do have a System z to connect to as a test platform. I too wish I could test locally on Windows 7. Cheers, Thomas Dunlap On 6/18/2013 5:34 PM, Graham Hobbs wrote: Hello, I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and moved to a new Lenovo with Windows 7. There is no need for host connection, my development world is as a standalone, compile/link/run COBOL programs and COBOL/CICS transaction programs on the Lenovo is the critical need. But I understand that Rational Developer for System z V8.5 does not 'do' COBOL on Windows 7 so am thinking my new world should be Rational Developer for zEnterprise V8.0.3 and would appreciate any comments/advice about that. Graham Hobbs -- ___ Regards, Thomas DunlapChief Technology Officert...@themisinc.com Themis, Inc.http://www.themisinc.com1 (800) 756-3000 -- 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 -- ___ Regards, Thomas DunlapChief Technology Officert...@themisinc.com Themis, Inc.http://www.themisinc.com1 (800) 756-3000 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RDz or RDzEnterprise developers
Another good suggestion. Will do some investigating, so thanks Thomas and Barry. Graham Ruminating only: being smallfry, what use then is RDz/TXSeries if a mainframe is a must. On 19/06/2013 1:26 PM, Thomas Dunlap wrote: Graham, I believe RDz 7.6 does include the COBOL compiler, even 8.0 does. You just have to install and run on XP Pro. I have not tried what Barry mentions, running XP compatible virtual process under Windows 7. I have a co-worker that used it for awhile with mixed results, some things worked and some did not. How about a laptop with dual boot, both XP Pro and Windows 7. Cheers, Thomas Dunlap On 6/19/2013 11:39 AM, Graham Hobbs wrote: Thomas, Barry, Sorry to bother you again. Any chance you think/know that RDz 7.6 would run under XP virtual machine? If I downloaded/installed 7.6 (from SAC) do you think IBM may have removed the COBOL compiler? Cheers, Graham - Original Message - From: Thomas Dunlap thomas.dun...@att.net Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, June 19, 2013 5:06 AM Subject: Re: RDz or RDzEnterprise developers Graham, The issue is not which version of RDz but rather which version of Windows. Even with RDz 7.6 the COBOL compiler would not install on Windows 7. IBM has not made, plus as I understand it, a COBOL compiler which works on Windows 7. I am in the same position, but do have a System z to connect to as a test platform. I too wish I could test locally on Windows 7. Cheers, Thomas Dunlap On 6/18/2013 5:34 PM, Graham Hobbs wrote: Hello, I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and moved to a new Lenovo with Windows 7. There is no need for host connection, my development world is as a standalone, compile/link/run COBOL programs and COBOL/CICS transaction programs on the Lenovo is the critical need. But I understand that Rational Developer for System z V8.5 does not 'do' COBOL on Windows 7 so am thinking my new world should be Rational Developer for zEnterprise V8.0.3 and would appreciate any comments/advice about that. Graham Hobbs -- ___ Regards, Thomas DunlapChief Technology Officer t...@themisinc.com Themis, Inc.http://www.themisinc.com1 (800) 756-3000 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RDz or RDzEnterprise developers
Hello, I have an old XP laptop with RDz 7.1.1.5 and TXSeries 7.1.0.4 and moved to a new Lenovo with Windows 7. There is no need for host connection, my development world is as a standalone, compile/link/run COBOL programs and COBOL/CICS transaction programs on the Lenovo is the critical need. But I understand that Rational Developer for System z V8.5 does not 'do' COBOL on Windows 7 so am thinking my new world should be Rational Developer for zEnterprise V8.0.3 and would appreciate any comments/advice about that. Graham Hobbs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
