Re: Why are z/OS people reluctant to use z/OS UNIX? (Are settlements a good argument for overnight batch COBOL ?).
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. Anne Lynn Wheeler l...@garlic.com writes: somewhat related recent post (mentions that long ago and far away my wife had been con'ed into going to POK to be in charge of mainframe loosely-coupled architecture) http://www.garlic.com/~lynn/2009h.html#1 z/Journal Does it Again now two of the other people that were also in that Jan92 meeting, moved on to a small client/server startup and we brought in as consultants because they wanted to do payment transactions on their server. The small client/server startup had also invented this technology called SSL which they wanted to use ... in any case, that work is now frequently called electronic commerce. re: http://www.garlic.com/~lynn/2009i.html#23 Why are z/OS people reluctant to use z/OS UNIX? (Are settlements a good argument for overnight batch COBOL ?). recent item somewhat related to electronic commerce ... 20 Years Ago Today: Birth of the Dot-Com Era http://www.pcworld.com/businesscenter/article/166302/20_years_ago_today_birth_of_the_dotcom_era.html from above: In those days, the Internet consisted of regional networks, who were mostly non-profit cooperatives, and the government funded 'NSFNet' backbone which linked them up, writes Templeton, a friend of many years' standing. ... snip i.e. tcp/ip was the technology basis for the modern internet, NSFNet backbone was the operational basis for the modern internet (inter-networking networks), and CIX was the business basis for the modern internet. misc. past posts mentioning NSFNet: http://www.garlic.com/~lynn/subnetwork.html#nsfnet and some old NSFNet related email http://www.garlic.com/~lynn/lhwemail.html#nsfnet for other drift ... SLAC (slac vm370 system) first webserver outside cern/europe (some mainframe content): http://www.slac.stanford.edu/history/earlyweb/history.shtml GML had been invented at the science center in 1969 and then standardized as SGML in the 70s ... misc. past posts mentioning GML, SGML, etc http://www.garlic.com/~lynn/submail.html#sgml CMS script command did document formating using dot commands ... somewhat from similar/earlier CTSS command. After, GML was invented, support for GML tag processing was added to script. Waterloo had done a clone of the cms command ... webpage tracking evolution from GML/SGML into HTML at CERN: http://infomesh.net/html/history/early/ above includes references to Waterloo SCRIPT GML User's Guide. science center also responsible for for virtual machines ... 1st cp40 on specially modified 360/40 with virtual memory hardware and then morphed into cp67 for 360/67. http://www.garlic.com/~lynn/subtopic.html#545tech science center also responsible for technology used for the internal network (which was larger than arpanet/internet from just about the beginning until possibly late-85/early-86) http://www.garlic.com/~lynn/subnetwork.html#internalnet -- 40+yrs 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: SEs History Lessons (was: Why are z/OS people reluctant to use z/OS UNIX?)
On Fri, 5 Jun 2009 10:43:38 -0400, Anne Lynn Wheeler l...@garlic.com wrote: -- 40+yrs virtualization exerience (since Jan68), online at home since Mar1970 Those who do not learn from history are doomed to repeat it. (Or something like that.) Thank you for sharing - once again I learned something(s) new. I never knew what HONE stood for, nor it's original purpose. In the services arena, we attempted to keep this self-training exercise going, but IBM had such a hard time deciding what to do about small mainframes and their customers, that our regional P/390 died a slow and painful death (though it did serve a useful purpose for a couple of years). Since we could not fund a Multiprise to replace it (which had a short shelf life itself), we began investigating VM accounts in Pok or Kingston as a way to keep it going (son of HONE?), but before that could gain traction, I was let go, and shortly thereafter, what was left of my team was disbanded and scattered to the four winds. We are fortunate here to be large enough to have dedicated LPARs for a sandbox / training environment, but we are using VM guests for another major project. Works quite well, including full-blown parallel sysplex. That was one of the shortcomings of our P/390 sandbox - the CF guest support wasn't yet available to us. Regards, Art Gutowski Ford Motor Company -- 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: SEs History Lessons (was: Why are z/OS people reluctant to use z/OS UNIX?)
On Sun, Jun 7, 2009 at 6:26 AM, Arthur Gutowskiaguto...@ford.com wrote: On Fri, 5 Jun 2009 10:43:38 -0400, Anne Lynn Wheeler l...@garlic.com wrote: -- 40+yrs virtualization exerience (since Jan68), online at home since Mar1970 Those who do not learn from history are doomed to repeat it. (Or something like that.) Thank you for sharing - once again I learned something(s) new. I never knew what HONE stood for, nor it's original purpose. Actually HONE was Hands-On Network Environment, not Experience. At least, that's what I was always told, and Google seems to support it, albeit only 41 to 13. -- 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: Why are z/OS people reluctant to use z/OS UNIX?
Shane writes: ...Should have been zLinux from the start. I completely disagree. z/OS UNIX System Services and Linux on System z are very different, and both are extremely useful. It would be pretty much impossible to have Java for z/OS, for example, without z/OS UNIX System Services. (That's a huge percentage of shops right there.) Most people don't use z/OS USS. That's not the right question. They use the many things that use z/OS USS. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.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: Why are z/OS people reluctant to use z/OS UNIX?
On Sat, 2009-06-06 at 16:26 +0900, Timothy Sipples wrote: Most people don't use z/OS USS. That's not the right question. They use the many things that use z/OS USS. And when customers ask: If z/OS USS is a strategic direction why are vendors like (*especially*) Tivoli with TSM server abandoning the platform ? My response would be: Bloody good question. Shane ... -- 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: Why are z/OS people reluctant to use z/OS UNIX?
For my 2 cents worth, I totally agree with Barbara. We don't have any use for Unix at our installation. The only real reason we have to keep up with and maintain UNIX is for TCP/IP. We don't have any substantial use for UNIX. Okay, ServerPac, but, I could just as easily use the tapes. By choices made by the Powers that be or did be, the Mainframe and new application development have been functionally stabilized and sunsetted. That was 10 years ago, but the exile order is still in place. I have no burning desire to learn UNIX when I am trying to maintain my knowledge of MVS, OEM products, and, develop my own solutions for the requirements here. If IBM were to scrap MVS and say 1.11 will not have a MVS nucleus but rather a UNIX kernel to drive everything else, then I would have a new direction. Until then, I remain, and quite happily, a MVS systems programmer who tolerates UNIX like an itch I can't scratch. -- 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: Why are z/OS people reluctant to use z/OS UNIX?
I always enjoys Arts posts - well worth the read. But on this one, I'll have to demur. OMVS on initial launch was an unmitigated disaster. Plenty of us (customers) tried it, way before IBM even thought of the New Workload sales pitch. It was a crock - pure and simple. It's usable now, but the horse has well and truly bolted. Should have been zLinux from the start. Shane ... -- 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: Why are z/OS people reluctant to use z/OS UNIX?
I consider there are 2 reasons why the implementation of Unix into MVS has been BAD. 1. EBCDICall UNIX files should have been ASCII from day 1. WebSphere Application Services for z/O(S has got it correct now by having all files in ASCII format. 2. The price of the IBM C compiler$$ All those simple things you would like to create under UNIX were originally done in C. So easy...just compile under z/OS.cant do...too expensive. But now that we also get to have Linux on zSerieswhy bother with coding under Unix System Services.much much cheaper on Linux. Regards Bruce Hewson -- 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: Why are z/OS people reluctant to use z/OS UNIX?
Shane wrote: OMVS on initial launch was an unmitigated disaster. Plenty of us (customers) tried it, way before IBM even thought of the New Workload sales pitch. It was a crock - pure and simple. Show me piece of IBM mainframe software that wasn't a crock when it first started. Remember the days when CICS didn't have storage protection? It's usable now, but the horse has well and truly bolted. Should have been zLinux from the start. OE was around when Linus was still at Uni. Don't knock it until you've really tried it mate ;). It's not perfect but it's useful and it's getting better all the time. Shane ... -- 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: Why are z/OS people reluctant to use z/OS UNIX?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, June 04, 2009 4:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Why are z/OS people reluctant to use z/OS UNIX? Considering the number of times the application code will be executed in production, the cpu time invested in optimizing it can be time well spent. YES! 100% As a capacity analyst since 1981, I've fought the battle of the compiler vs the execution. Run the compiler steps in a low priority service class and stop complaining! B*tch about poor transaction CPU consumption, not about poor compiler consumption! Generally agreed. But for any one off, be sure to not over optimize! -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: Why are z/OS people reluctant to use z/OS UNIX?
Generally agreed. But for any one off, be sure to not over optimize! Beware of the mythical one off! Rarely, is it only one. And, I meant general production. - Too busy driving to stop for gas! -- 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: Why are z/OS people reluctant to use z/OS UNIX?
McKown, John wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, June 04, 2009 4:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Why are z/OS people reluctant to use z/OS UNIX? Considering the number of times the application code will be executed in production, the cpu time invested in optimizing it can be time well spent. YES! 100% As a capacity analyst since 1981, I've fought the battle of the compiler vs the execution. Run the compiler steps in a low priority service class and stop complaining! B*tch about poor transaction CPU consumption, not about poor compiler consumption! Generally agreed. But for any one off, be sure to not over optimize! I agree for hand optimized code. Leave it to the compiler, it knows best. -- 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: Why are z/OS people reluctant to use z/OS UNIX?
I agree for hand optimized code. Leave it to the compiler, it knows best. Not always. I've seen optimisation introduce bugs. But, I don't think it's that common, any more. - Too busy driving to stop for gas! -- 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: Why are z/OS people reluctant to use z/OS UNIX?
On Fri, 5 Jun 2009 16:32:51 +1000, Shane ibm-m...@tpg.com.au wrote: I always enjoys Arts posts - well worth the read. But on this one, I'll have to demur. OMVS on initial launch was an unmitigated disaster. Plenty of us (customers) tried it, way before IBM even thought of the New Workload sales pitch. It was a crock - pure and simple. It's usable now, but the horse has well and truly bolted. Should have been zLinux from the start. Shane, you are the yang to my yin. I appreciate someone who can boil it down without losing the point. Sometimes I just overthink it. Guess I drank the kool-aid. IBM hired me in at the time they were jumping into the services business (another unmitigated disaster, IMHO, was getting rid of SE's and creating billable resources, but that's another rant). They trained me for two things - Parallel Sysplex and OpenEdition. Both had significant challenges in the beginning, and both arguably still have limited application (LARGE shops?), but both have evolved. Based on (lack of) adoption of USS, I can't disagree with you - Elvis has left the building (but I hear he still makes the occasional appearance in Kalamazoo). Cheers, Art -- 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: SD (was: Why are z/OS people reluctant to use z/OS UNIX?)
Still drifting around, but it's Friday, so... On the ride in this morning, whilst realizing it was a bloody good thing I washed my feet before I hit send yesterday, my comment about software development hit me square in the forehead, and I see a couple of similar comments in this morning's digest. Having been in countles ETR's, CritSits, etc., over the few (20) years I've been at this, I have come to realize SD is an almost utterly thankless job. We customers (users) are a demanding lot, so I recognize it is tough to get it right, and even if successful, someone will inevitably use the lawnmower to trim the hedges. We'll do something with a piece of code that no developer in his right (or wrong) mind could ever conceive. What hit me was the irony that we use software and hardware, invented by humans, to reduce the opportunity for error through automation and reduction of the human element. Strange deal. Think I'll go watch the latest Terminator sequel this weekend... Cheers, Art -- 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: Why are z/OS people reluctant to use z/OS UNIX?
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. aguto...@ford.com (Arthur Gutowski) writes: Guess I drank the kool-aid. IBM hired me in at the time they were jumping into the services business (another unmitigated disaster, IMHO, was getting rid of SE's and creating billable resources, but that's another rant). They trained me for two things - Parallel Sysplex and OpenEdition. Both had significant challenges in the beginning, and both arguably still have limited application (LARGE shops?), but both have evolved. Based on (lack of) adoption of USS, I can't disagree with you - Elvis has left the building (but I hear he still makes the occasional appearance in Kalamazoo). some of that started to happen with 23jun69 unbundling announces. Lots of SEs got their experience as kind of apprentice activity as part of large group of SEs at customer accounts. With 23jun69 unbundling announcement, there was start for charging for application software (the case was made that kernel/operating system software should remain free). However, as part of unbundling ... no mechanism was arrived at to continue the apprentice type training at customer accounts (requirement charging for SE time at the customer site w/o charging for inexpierenced SE time). misc. past posts mentioning unbundling http://www.garlic.com/~lynn/submain.html#unbundle An attempt to compensate for that training avenue was setting up some number of (virtual machine) CP67 (HONE -- hands-on network experience) datacenters to provide online access to branch office people to practice their operating system skills (in virtual machines). The science center ... misc. past posts http://www.garlic.com/~lynn/subtopic.html#545tech had also ported apl\360 to cms for cms\apl. HONE started deploying some number of online applications supporting sales marketing. eventually these applications completely croweded out the virtual machine experience for SEs. Eventually it wasn't even possible for branch office to submit mainframe order that had first been processed by HONE application(s). Misc. past posts mentioning HONE http://www.garlic.com/~lynn/subtopic.html#hone one could claim that the aging/retiring of the SEs from pre-23jun69 has contributed to change in policy. re: http://www.garlic.com/~lynn/2009i.html#9 Why are z/OS people reluctant to use z/OS UNIX? http://www.garlic.com/~lynn/2009i.html#21 Why are z/OS people reluctant to use z/OS UNIX? http://www.garlic.com/~lynn/2009i.html#23 Why are z/OS people reluctant to use z/OS UNIX? (Are settlements a good argument for overnight batch COBOL ?) previously mentioned, long ago far away, my wife had been con'ed into going to POK to be in charge of loosely-coupled architecture. while there she established peer-coupled shared data architecture ... some number of past posts http://www.garlic.com/~lynn/submain.html#shareddata the battles with the communication group contributed to her not staying very long in the position (although there was a temporary truce that she wouldn't have to use SNA for loosely-coupled within the boundaries of the datacenter). the other contributing factor was that there was very little uptake except for IMS hot-standby ... until (parallel) sysplex. part of the issue was that in the early SNA days ... she had been co-author of peer-to-peer networking architecture (AWP39) ... which the SNA group may have possibly viewed as competitive (in most other environments, networking implicitly implied peer-to-peer ... it was only in an environment when networking was used to apply to communication that it was necessary to use the peer-to-peer qualifier) It wasn't until APPN (AWP169) that there was some semblance of peer-to-peer network. Even then, the SNA organization non-concurred with the announcment ... and the escalation took several weeks while the APPN announcement letter was carefully rewritting to avoid implying any relationship between APPN and SNA. -- 40+yrs virtualization exerience (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: Why are z/OS people reluctant to use z/OS UNIX?
On Thu, 2009-06-04 at 00:43 -0500, Barbara Nitz wrote: c) Don't even get me started on Java applications running on z/OS. In fairness, it should be noted that java is a pox in _all_ environments. And now that Larry E has added it as another (no doubt) nice little future revenue earner, things are hardly likely to improve. But maybe I digress. Maybe. Shane ... -- 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: Why are z/OS people reluctant to use z/OS UNIX?
Barbara Nitz wrote: I am one of those who hate UNIX on z/OS. Here's why: 2. A pain with regard to system controls. a) USS is expected to be exempt from all controls MVS has - look at iefusi and the huge warnings surrounding it if you *DON'T* give a USS address space what it wants! Same holds for other things. I can understand the reason for those IEFUSI warnings. Java! Also those of us who compile using the C/C++ compiler in USS need a lot of memory because the compiler is a memory hog when optimizing. It's no different when compiling using batch. b) Try to use WLM on one of those USS applications! We have one that routinely runs around 65 address spaces that all wake up (timer driven) at the same time. Having (at least) 65 tcbs ready to run on 2 cps plays havoc with WLM PI Please name and shame the application! Sounds like a forker. It's also not uncommon to see Java applications using thread pools with 50 times more threads then cpus. As soon as notifyAll is called the thundering herd comes a running. Most of these problems are due to poor programming practice, not necessarily the environment. a) Just seen yesterday on WAS V6: I tried to use the WAS console to install a IVP on our z/800. Response times were several minutes. I guess IBM are building hardware to make it perform (z10) just like they did back in the day for DB2. Didn't DB2 used to be a dog once? I hate USS because architecturally it does not fit into z/OS. UNIX probably has it uses, but not in z/OS. Just my opinion, of course. Fair point. It's a software stack not a real kernel. I like USS because I like *nix. I've found it to be very useful for my needs. Barbara Nitz -- 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: Why are z/OS people reluctant to use z/OS UNIX?
I can understand the reason for those IEFUSI warnings. Java! Well, the warnings for IEFUSI were there long before Java came along. And it was only the precursor for things to come. Also those of us who compile using the C/C++ compiler in USS need a lot of memory because the compiler is a memory hog when optimizing. It's no different when compiling using batch. Not to mention a cpu hog. Please name and shame the application! Sounds like a forker. Can I say the good old 'check the archives'? I have complained about it at length. It's also not uncommon to see Java applications using thread pools with 50 times more threads then cpus. As soon as notifyAll is called the thundering herd comes a running. Most of these problems are due to poor programming practice, not necessarily the environment. My point of contention is that most of the 'programmers' (That's why I called that 'clicking') don't care that their code is poor. My neighbour - a nice young man of 25, just finished his IT-education, and he is sharp! - stated the mind set of those I call 'clickers': If it works on my PC, I don't care if it has a performance problem in production. Someone else in the project hierarchy has to fix it. (like the architect for the project or the customer). With this attitude, about 99% of the 'ported' code is really bad for the environment it is supposed to run in productively. And the 1% that isn't so bad has a lot of customer blood attached to it. I guess IBM are building hardware to make it perform (z10) just like they did back in the day for DB2. Don't know about DB2, but performance problems caused by extremely poor programming in a zLinux environment were dealt with by doing what is done in the mickey mouse world - throw more hardware at it (in our case more IFLs). That one single application cannot function with less than 8 IFLs. To compare - our 'holy cow' production system has only 7 general cps, and it runs IMS, DB2 and tons of batch without them crashing, even when we execute 1400 IMS transactions per second for at least a minute (with response times *a lot* less than 50ms). Guess I should shut up now. Barbara -- 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: Why are z/OS people reluctant to use z/OS UNIX?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Barbara Nitz I can understand the reason for those IEFUSI warnings. Java! Well, the warnings for IEFUSI were there long before Java came along. And it was only the precursor for things to come. Also those of us who compile using the C/C++ compiler in USS need a lot of memory because the compiler is a memory hog when optimizing. It's no different when compiling using batch. Not to mention a cpu hog. Please name and shame the application! Sounds like a forker. Can I say the good old 'check the archives'? I have complained about it at length. It's also not uncommon to see Java applications using thread pools with 50 times more threads then cpus. As soon as notifyAll is called the thundering herd comes a running. Most of these problems are due to poor programming practice, not necessarily the environment. My point of contention is that most of the 'programmers' (That's why I called that 'clicking') don't care that their code is poor. My neighbour - a nice young man of 25, just finished his IT-education, and he is sharp! - stated the mind set of those I call 'clickers': If it works on my PC, I don't care if it has a performance problem in production. Someone else in the project hierarchy has to fix it. (like the architect for the project or the customer). With this attitude, about 99% of the 'ported' code is really bad for the environment it is supposed to run in productively. And the 1% that isn't so bad has a lot of customer blood attached to it. I guess IBM are building hardware to make it perform (z10) just like they did back in the day for DB2. Don't know about DB2, but performance problems caused by extremely poor programming in a zLinux environment were dealt with by doing what is done in the mickey mouse world - throw more hardware at it (in our case more IFLs). That one single application cannot function with less than 8 IFLs. To compare - our 'holy cow' production system has only 7 general cps, and it runs IMS, DB2 and tons of batch without them crashing, even when we execute 1400 IMS transactions per second for at least a minute (with response times *a lot* less than 50ms). Guess I should shut up now. Maybe that's part of the reason they're called developers instead of programmers nowadays. Drop in the film; take out the pictures. Who cares how well or poorly it works, as long as it works? And if occasionally it blows up and ruins the pictures, we'll give you a fresh roll of film as compensation. -jc- -- 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: Why are z/OS people reluctant to use z/OS UNIX?
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. nitz-...@gmx.net (Barbara Nitz) writes: My point of contention is that most of the 'programmers' (That's why I called that 'clicking') don't care that their code is poor. My neighbour - a nice young man of 25, just finished his IT-education, and he is sharp! - stated the mind set of those I call 'clickers': If it works on my PC, I don't care if it has a performance problem in production. Someone else in the project hierarchy has to fix it. (like the architect for the project or the customer). With this attitude, about 99% of the 'ported' code is really bad for the environment it is supposed to run in productively. And the 1% that isn't so bad has a lot of customer blood attached to it. recent references to billions spent (mostly by financial industry) on failed attempts to leverage large farms of PCs to implement straight through transaction processing in the 90s ... as alternative to (mostly) large cobol batch processing that ran in overnight batch windows doing things like settlement to complete online transactions that had occured during the day. the issue was that some number of them got past the pilot stage and into full scale deployment before the scale-up issues appeared on their horizon. it turns out that implementations were doing things that resulted in 100 times bloat in the implementation (compared to the batch cobol) ... totally swamping any anticipated through-put improvements from using large PC farms. http://www.garlic.com/~lynn/2009.html#87 Cleaning Up Spaghetti Code vs. Getting Rid of It http://www.garlic.com/~lynn/2009c.html#43 Business process re-engineering http://www.garlic.com/~lynn/2009d.html#14 Legacy clearing threat to OTC derivatives warns State Street http://www.garlic.com/~lynn/2009f.html#55 Cobol hits 50 and keeps counting http://www.garlic.com/~lynn/2009h.html#1 z/Journal Does it Again http://www.garlic.com/~lynn/2009h.html#2 z/Journal Does it Again -- 40+yrs 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: Why are z/OS people reluctant to use z/OS UNIX?
Barbara Nitz wrote: Also those of us who compile using the C/C++ compiler in USS need a lot of memory because the compiler is a memory hog when optimizing. It's no different when compiling using batch. Not to mention a cpu hog. That's why we suggest doing those compiles with our C/C++ compiler running in IBM compatibility mode on a local workstation... saves a lot of memory CPU.. and, if you are being billed for those, it can save a ton of $$$. - 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: Why are z/OS people reluctant to use z/OS UNIX?
Barbara Nitz's masterful rant snipped Barbara, you are my hero. You are a goddess. I want to be you when (if) I grow up. Well said, madam, well said. Cheers,,,Steve Steve Conway Lead Systems Programmer Information Systems Services Division Computer Network Operations Phone: (703) 450-3156 Fax:(703) 450-3197 A veteran is someone who, at one point in his life wrote a blank check made payable to ' The United States of America ' for an amount of 'up to and including my life.' That is Honor, and there are too many people in this country who no longer understand it. -- 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: Why are z/OS people reluctant to use z/OS UNIX?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Thursday, June 04, 2009 12:43 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Why are z/OS people reluctant to use z/OS UNIX? I am one of those who hate UNIX on z/OS. Here's why: snip 2. A pain with regard to system controls. a) USS is expected to be exempt from all controls MVS has - look at iefusi and the huge warnings surrounding it if you *DON'T* give a USS address space what it wants! Same holds for other things. Amen! If UNIX work needs to be exempt from IEFUSI controls, then write z/OS to ignore IEFUSI values for it! b) Try to use WLM on one of those USS applications! We have one that routinely runs around 65 address spaces that all wake up (timer driven) at the same time. Having (at least) 65 tcbs ready to run on 2 cps plays havoc with WLM PI, which is routinely in the three-digit-range. sarcasm on One would think that IBM by now had introduced the concept of a 'UNIX transaction' that can be classiifed via a response time goal. sarcasm off No such luck. I have complained about this before, check the archives! Double agreeded. I also hate the fact that I don't have a way to assign a different SRVCLASS depending on batch or interactive OMVS work. A batch job which fork()s ends up with the fork()ed address space being reclassified and I cannot propogate the parent's SRVCLASS to the child. So a prod and test batch job which fork()s get a child with the same, usually wrong, SRVCLASS. snip snip I hate USS because architecturally it does not fit into z/OS. UNIX probably has it uses, but not in z/OS. Just my opinion, of course. I guess I still soet of like it because we don't use it for very much. Barbara Nitz -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: Why are z/OS people reluctant to use z/OS UNIX?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thomas David Rivers Sent: Thursday, June 04, 2009 9:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Why are z/OS people reluctant to use z/OS UNIX? Barbara Nitz wrote: Also those of us who compile using the C/C++ compiler in USS need a lot of memory because the compiler is a memory hog when optimizing. It's no different when compiling using batch. Not to mention a cpu hog. That's why we suggest doing those compiles with our C/C++ compiler running in IBM compatibility mode on a local workstation... saves a lot of memory CPU.. and, if you are being billed for those, it can save a ton of $$$. - Dave Rivers - Dave, Do you have any documentation on how to do this? Do you require the IBM C *.h files on the PC? Is the output usable for a UNIX command environment (your output is/is not LE?), CICS transaction, CGI? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: Why are z/OS people reluctant to use z/OS UNIX?
McKown, John wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thomas David Rivers Sent: Thursday, June 04, 2009 9:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Why are z/OS people reluctant to use z/OS UNIX? Barbara Nitz wrote: Also those of us who compile using the C/C++ compiler in USS need a lot of memory because the compiler is a memory hog when optimizing. It's no different when compiling using batch. Not to mention a cpu hog. That's why we suggest doing those compiles with our C/C++ compiler running in IBM compatibility mode on a local workstation... saves a lot of memory CPU.. and, if you are being billed for those, it can save a ton of $$$. - Dave Rivers - Dave, Do you have any documentation on how to do this? Do you require the IBM C *.h files on the PC? Is the output usable for a UNIX command environment (your output is/is not LE?), CICS transaction, CGI? -- John McKown Systems Engineer IV IT Hi John, Our compilers operate in several modes - one of which is IBM Compatibiltiy mode. When IBM Compatibiltiy mode is enabled, you need the IBM headers to compile with (you can do that with a SAMBA server on your mainframe; or an NFS server on your mainframe.) The resulting object is just like the IBM compiler had compiled it. Of course, since it's not the same compiler, the code is not identical - but it is LE, just as if the IBM compiler had compiled it. The resulting objects would then be linked with the IBM LE runtime for execution. Our pre-linker can also stand-in for the IBM pre-linker, if you wanted to use that instead of the binder. And, our linker can do binding as well, creating a TSO transmit file that is RECEIVED on the mainframe (although, it will only create old-style LOAD MODULES, not the newer PROGRAM OBJECTS.) The output is usable in all the same ways as the IBM compiler's output is usable. As well as compilers, we also have a CICS preprocessor and DB2 preprocessor - so all of that can happen on your PC as well. More information can be found in our Systems/C documentation (http://www.dignus.com/dcc/doc.html) and our Utilities documentation on that same link. - 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: Why are z/OS people reluctant to use z/OS UNIX? (Are settlements a good argument for overnight batch COBOL ?).
It's interesting to link (trade) settlements to overnight batch COBOL. That's not really an option(sic) in today's trading world - you need to support same day settlements and various intraday business functions. This type of need would be reflected in a multitude of business functions across various industries that need real time (or close to real time) updates, and that historically used the 'key in during the day - run batch updates at night' model. (There are still tons of apps that are using this model successfully because it supports their business functions). That doesn't rule out mainframe COBOL at all - any mainstream Java/.NET or other mainstream web based architecture will support calling COBOL/DB2 stored procedures. 'During the day' batch jobs using COBOL can be scheduled to augment the SP processing if necessary. This model works like a champ and will usually allow for major reuse of legacy COBOL code. XML can be used as a common format to transfer data between platforms. Cheers, Brendan Date: Thu, 4 Jun 2009 08:27:43 -0400 From: l...@garlic.com Subject: Re: Why are z/OS people reluctant to use z/OS UNIX? To: IBM-MAIN@bama.ua.edu The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. nitz-...@gmx.net (Barbara Nitz) writes: My point of contention is that most of the 'programmers' (That's why I called that 'clicking') don't care that their code is poor. My neighbour - a nice young man of 25, just finished his IT-education, and he is sharp! - stated the mind set of those I call 'clickers': If it works on my PC, I don't care if it has a performance problem in production. Someone else in the project hierarchy has to fix it. (like the architect for the project or the customer). With this attitude, about 99% of the 'ported' code is really bad for the environment it is supposed to run in productively. And the 1% that isn't so bad has a lot of customer blood attached to it. recent references to billions spent (mostly by financial industry) on failed attempts to leverage large farms of PCs to implement straight through transaction processing in the 90s ... as alternative to (mostly) large cobol batch processing that ran in overnight batch windows doing things like settlement to complete online transactions that had occured during the day. the issue was that some number of them got past the pilot stage and into full scale deployment before the scale-up issues appeared on their horizon. it turns out that implementations were doing things that resulted in 100 times bloat in the implementation (compared to the batch cobol) ... totally swamping any anticipated through-put improvements from using large PC farms. http://www.garlic.com/~lynn/2009.html#87 Cleaning Up Spaghetti Code vs. Getting Rid of It http://www.garlic.com/~lynn/2009c.html#43 Business process re-engineering http://www.garlic.com/~lynn/2009d.html#14 Legacy clearing threat to OTC derivatives warns State Street http://www.garlic.com/~lynn/2009f.html#55 Cobol hits 50 and keeps counting http://www.garlic.com/~lynn/2009h.html#1 z/Journal Does it Again http://www.garlic.com/~lynn/2009h.html#2 z/Journal Does it Again -- 40+yrs 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 _ Lauren found her dream laptop. Find the PC that’s right for you. http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290 -- 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: Why are z/OS people reluctant to use z/OS UNIX? (Are settlements a good argument for overnight batch COBOL ?).
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. bjpafr...@hotmail.com (Brendan Friel) writes: It's interesting to link (trade) settlements to overnight batch COBOL. That's not really an option(sic) in today's trading world - you need to support same day settlements and various intraday business functions. This type of need would be reflected in a multitude of business functions across various industries that need real time (or close to real time) updates, and that historically used the 'key in during the day - run batch updates at night' model. (There are still tons of apps that are using this model successfully because it supports their business functions). re: http://www.garlic.com/~lynn/2009i.html#21 Why are z/OS people reluctant to use z/OS UNIX? in the 90s period, the overnight batch window was experiencing severe strain, in part because of business growth was increasing the work that had to be done in the window and some amount of globalization was decreasing the size of the window ... as well as increasing the amount of work. when we were doing (our/)ibm's ha/cmp product ... some reference http://www-03.ibm.com/systems/power/software/availability/aix/index.html we went into siac several times to talk about thier (trading) operation. we also had this Jan92 meeting on ha/cmp scaleup http://www.garlic.com/~lynn/95.html#13 in fact, my choice of product name ha/cmp ... reflected all the work we had been doing for cluster scaleup ... some old email http://www.garlic.com/~lynn/lhwemail.html#medusa but then that part of the effort got transferred (and announced as a numerical intensive product) and we were told to not work on anything with more than four processors (however, the ha/cmp seem to stick). shortly after that, we decided to leave. somewhat related recent post (mentions that long ago and far away my wife had been con'ed into going to POK to be in charge of mainframe loosely-coupled architecture) http://www.garlic.com/~lynn/2009h.html#1 z/Journal Does it Again now two of the other people that were also in that Jan92 meeting, moved on to a small client/server startup and we brought in as consultants because they wanted to do payment transactions on their server. The small client/server startup had also invented this technology called SSL which they wanted to use ... in any case, that work is now frequently called electronic commerce. In the mid-90s, somewhat as a result of the electronic commerce work, we were invited to particate in the x9a10 financial standard working group which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (i.e. *ALL* as in *ALL*, POS, internet, debit, credit, stored value, unattended, face-to-face, transit turnstyle, etc, i.e. *ALL*). We did some detailed threat and vulnerability studies and eventually came up with x9.59 retail financial standard transaction protocol ... some references http://www.garlic.com/~lynn/x959.html#x959 somewhat as a result of the electronic commerce and x9.59 work, we were invited into NSCC (since merged with DTC for DTCC) to look at doing something similar for all trading operations. After a short while, the work was suspended ... possibly because a side effort would have been significantly increased transparency and visibility ... which apparently wasn't naturally part of trader culture. note in the recent congressional hearings into the Madoff Ponzi scheme, a reoccuring theme by the person that had been trying for a decade to get SEC to do something about Madoff ... was that much more important than new regulations is the requirement for transparency and visibility. -- 40+yrs 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: Why are z/OS people reluctant to use z/OS UNIX? (Are settlements a good argument for overnight batch COBOL ?).
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Anne Lynn Wheeler [ snip ] somewhat as a result of the electronic commerce and x9.59 work, we were invited into NSCC (since merged with DTC for DTCC) to look at doing something similar for all trading operations. After a short while, the work was suspended ... possibly because a side effort would have been significantly increased transparency and visibility ... which apparently wasn't naturally part of trader culture. note in the recent congressional hearings into the Madoff Ponzi scheme, a reoccuring theme by the person that had been trying for a decade to get SEC to do something about Madoff ... was that much more important than new regulations is the requirement for transparency and visibility. What?? No more under-the-table deals? Pay no attention to that man behind the curtain.. -jc- -- 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: Why are z/OS people reluctant to use z/OS UNIX?
All that and, maybe it's just personally visceral, but I am not fond of alp -H -a bet so | up I'm sure when I'm again required to be more practiced in *nix, hopefully zLinux is on the horizon, I'll find the old brain cells from my unix days in college :) Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Steven Conway Sent: Thursday, June 04, 2009 7:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Why are z/OS people reluctant to use z/OS UNIX? Barbara Nitz's masterful rant snipped Barbara, you are my hero. You are a goddess. I want to be you when (if) I grow up. Well said, madam, well said. Cheers,,,Steve Steve Conway Lead Systems Programmer Information Systems Services Division Computer Network Operations Phone: (703) 450-3156 Fax:(703) 450-3197 A veteran is someone who, at one point in his life wrote a blank check made payable to ' The United States of America ' for an amount of 'up to and including my life.' That is Honor, and there are too many people in this country who no longer understand it. -- 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: Why are z/OS people reluctant to use z/OS UNIX?
On Thu, 4 Jun 2009 10:18:11 -0400, Thomas David Rivers riv...@dignus.com wrote: ... That's why we suggest doing those compiles with our C/C++ compiler running in IBM compatibility mode on a local workstation... saves a lot of memory CPU.. and, if you are being billed for those, it can save a ton of $$$. ... Ok. I know that the C/C++ compiler and z/OS Unix are not the same thing, but let me take your suggestion and stretch it a bit (perhaps beyond appropriateness). We can lessen the pain of using z/OS Unix by not using it. Effectiv. But performing such tricks is not likely to incresse our fondness of the product. Pat O'Keefe -- 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: Why are z/OS people reluctant to use z/OS UNIX?
Also those of us who compile using the C/C++ compiler in USS need a lot of memory because the compiler is a memory hog when optimizing. It's no different when compiling using batch. Not to mention a cpu hog. It's true, our compiler can take up a lot of memory and cpu. We provide several choices of optimization levels, and a highly optimized application can use significantly less cpu than an unoptimized app. The IPA level of optimization, for example, does whole program optimization, which exposes many more optimization opportunities than optimizing one source file at a time. However, optimizing an entire program requires significantly more memory, and cpu. One of the ways we have tried to mitigate this is to move memory used by the IPA compile phase above the bar, i.e., into 64-bit virtual storage. Considering the number of times the application code will be executed in production, the cpu time invested in optimizing it can be time well spent. Regards, Kel IBM C/C++ Compiler Development http://www.ibm.com/software/rational/cafe/community/ccpp -- 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: Why are z/OS people reluctant to use z/OS UNIX?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kelly Arrey Sent: Thursday, June 04, 2009 3:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Why are z/OS people reluctant to use z/OS UNIX? Also those of us who compile using the C/C++ compiler in USS need a lot of memory because the compiler is a memory hog when optimizing. It's no different when compiling using batch. Not to mention a cpu hog. It's true, our compiler can take up a lot of memory and cpu. We provide several choices of optimization levels, and a highly optimized application can use significantly less cpu than an unoptimized app. The IPA level of optimization, for example, does whole program optimization, which exposes many more optimization opportunities than optimizing one source file at a time. However, optimizing an entire program requires significantly more memory, and cpu. One of the ways we have tried to mitigate this is to move memory used by the IPA compile phase above the bar, i.e., into 64-bit virtual storage. Considering the number of times the application code will be executed in production, the cpu time invested in optimizing it can be time well spent. SNIP How much memory does the PL/1 (optimizing) compiler take? Are there any lessons that can be learned and applied? Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- 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: Why are z/OS people reluctant to use z/OS UNIX?
Considering the number of times the application code will be executed in production, the cpu time invested in optimizing it can be time well spent. YES! 100% As a capacity analyst since 1981, I've fought the battle of the compiler vs the execution. Run the compiler steps in a low priority service class and stop complaining! B*tch about poor transaction CPU consumption, not about poor compiler consumption! - Too busy driving to stop for gas! -- 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: Why are z/OS people reluctant to use z/OS UNIX?
Apologies in advance, this is going all over the map... and, I don't intend to offend anyone's sensibilities (I'm an avid mainframe guy, but I am tempered by an effort to understand how things came to be). Hopefully this will spark more thought and questions than religious railing. DB2 was perhaps considered a dog at one time, and TSO was known as The Slow One (AFAIK, it's unofficial mascot is still a Turkey - kind of a misrepresentation if you've ever hunted wild turkey). The thing is, most new applications, features, platforms, et al, are fraught with problems when introduced. We can probably count on one hand the number of times a vendor or in-house programmer ever got it right the first time. Oversimplification, perhaps, but the POS assessment turned me inward a bit... One reason that Linux exploded onto the scene is that it has a user community that embraces it and collectively improves upon it, as many open- source projects have. Come to think of it, MVS started out that way, did it not? Hm... somewhere around 3.8, IIRC, that began to change. Another is that it runs, almost literally, anywhere. I firmly believe that if IBM would embrace this concept, vis-a-vis Hercules, the mainframe would not be so denigrated out in the real world. My point is, lack of adoption and perceived POS software usually go hand-in- hand. This doesn't excuse putting out shoddy software and passing it off as enterprise-class. However, a first cut is sometimes taken whilst keeping in mind that you don't exactly yet know how wide your target audience is going to be. Was it TJ Sr. or TJ Jr. who figured there wouldn't ever be more than about 4 mainframes in the world? Didn't IBM also poo-poo the idea of a PC in every home? The effects of these two misses seem very different, yet eerily similar, and either way, quite far-reaching. USS has evolved quite a bit, actually, even as it started out as the first fully POSIX-compliant Unix kernel (I know I sound like a marketing rep, and I apologize, but I did work for IBM as a services guy in the mid-90s when this stuff first hit the market). Admittedly, OMVS had serious shortcomings to those of us weaned on a reasonably bullet-proof platform, and it still has some unwarranted restrictions (or needs), but isn't IEFUSI itself out-dated? I mean, come now, IBM gave us MEMLIMIT for 64-bit throttling, why on this green earth can't they give us REGLIMIT, and while they're at it, can't they allow it to be specified at a subsystem level instead of system-wide? But, I digress... Part of the problem comes from fundamental differences, not merely inherent in the platforms, but in how these platforms are managed. Both sides will say they got that way out of necessity, but both lines of reasoning will likely end in their mutual demise. Almost as disappointing, a merging of the platforms (which at some level is what USS attempts), or reconciliation between these disparate worlds is unlikely as well. *nix (and *86) exploded in part due to business customers' perceived lack of adaptability of the datacenter to their needs. One reason we mainframers despise the *nix farm is a perceived wild west landscape. Some are trying (with zero to limited success) to tame this frontier, while some are demanding (and even exploiting) ways to make the enterprise platform more flexible, while keeping a reasonably rigid set of controls over how, who, when and where to use it. To me, it comes down to mindset, and a balance between adaptability and manageability. Here, we exploit USS in small pockets. Like most things on my favorite platform, it takes time, diligence, persistence, and many other forms of attention, but acceptance of it has grown, if slowly, if even grudgingly since it was first 'mandated' by OS functions like TCP/IP. My observation is that this is mostly just a 'resistance to change' that has been overcome by necessity and a gradual changing of the guard. Same is hopefully coming to pass with Linux on z (hey, if we're stuck with it, let's at least wrap some process, DR, and other enterprise sensibilities around it so we aren't running around like chickens with our heads cut off). My bottom line is that if it's useful and it can be managed, why not at least give it a shot? As a IBMer, I had several, varied (in terms of industry and scale) customers that implemented a variety of vendor and in-house applications, successfully no less, on OMVS/OE/USS (even Lotus Notes). As a customer, we have found it useful in some business applications, and it has not become the three-headed monster at the gates of hell, as it has for others. If it doesn't work out, know when to say when, and walk away from it. If it does work, get some discipline around it and put it to good use. Regards, Art Gutowski Ford Motor Company Do something. If it works, do more of it. If it doesn't do something else. Franklin Delano Roosevelt
Re: Why are z/OS people reluctant to use z/OS UNIX?
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. st...@trainersfriend.com (Steve Comstock) writes: That's the other windmill I'm tilting at these days: the benefits of insourcing - using local people for local work. Working to once again build trust and loyalty in the workplace, acknowledging that the workplace of the 21st century is different from the workplace of the 20th century. one of the big internet refrains has been telecommuting ... and by implication, lots of work becoming distance insensitive. i've repeatedly claimed that the trust issue was significantly affected by the Y2K issue ... there was big spike in demand for resources as part of Y2K remediation ... which happened to occur at the same time as the internet bubble. the result was lots of employers were forced to go overseas for resources for their Y2K remediation efforts (internet bubble having sucked up nearly every spare resource with promises of enormous equity wealth). The trust established as part of Y2K remediation greatly accelerated subsequent outsourcing in this decade. -- 40+yrs 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
Why are z/OS people reluctant to use z/OS UNIX?
When I grew up in the mainframe world, UNIX was considered to be the enemy. But I was working for IBM, and UNIX products were competitors, so that's kind of an expected perspective. Today, z/OS provides a rich set of UNIX services, including HFS/zFS files, a shell, a UNIX kernel, and more, to supplement / complement the classic MVS facilities. People who grew up with UNIX seem to despise or denigrate z/OS UNIX as missing a lot of features or behaviors that they are used to. But those of us who grew up in the OS/360-and-successors world don't know what we're missing, so it all seems to be pretty handy as is. Of course, there's always something new in the next release. There has been a perception that UNIX is less secure than z/OS. But I think that is an old perception. And when you utilize z/OS UNIX, your primary security comes from z/OS security services (RACF, Top Secret, ACF2, and so on), so that applications using z/OS UNIX should be as secure as any other z/OS applications. Several people on the list talk about their manager's dislike, distrust, disdain for z/OS UNIX (for example, John McKown recently wrote, speaking of people at his installation that would be left if he were to lose his job: They seem to regard UNIX on z/OS as an abomination.) I'd like to understand this visceral reaction, with an eye to seeing what can be done to moderate it down to at least a level of skepticism (OK, what can this do for me?). Of course, I have an agenda in doing this: I've written a number of courses on using z/OS UNIX, and I'd like to see some interest in companies taking this training. I'm just finishing up a course on writing COBOL CGIs, and it seems to me that if IT management truly wants to keep costs down, they would look at using z/OS for web hosting. This can be done very inexpensively: * IBM provides two free HTTP servers, one comes automatically with z/OS, the other is free but must be ordered separately * Most installations already have a COBOL compiler for writing CGI code, so there's no additional cost for software and you have staff that already knows the language or you can write CGIs in Assembler (a less attractive option in most shops) * Your installation already has VSAM and probably some database product such as DB2, so there's no need for any additional software to serve up data * Although you don't need Java to do this, if you want to use Java facilities, IBM provides it at no charge You don't need WebSphere; you don't need Java. Just the free facilities available with your z/OS system and your current programming staff. But you do need to use at least some parts of z/OS UNIX. So what's the hangup about z/OS UNIX? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.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: Why are z/OS people reluctant to use z/OS UNIX?
I hear you, Steve. I'm a 50-something mainframe systems programmer and still work on the big iron. But I also have been playing with Linux since it came on 36 floppy disks and to install you had to create ram disks. Just getting it to boot was a major success. In the early 90's I had Red Hat serving a handful of people with UUCP to send/receive e-mail (list serv) from all over the world. This was way before Al Gore invented the WWW. I don't know how I knew Linux and *nix was going to be so big but when IBM came our with USS I was overjoyed. And when IBM announced Linux for a mainframe LPAR it felt like a prophecy revealed. Here's one systems guy all for taking advantage of all platforms (except Windoze). Ken Klein Sr. Systems Programmer kenneth.kl...@kyfb.com 502-495-5000 x7011 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Steve Comstock Sent: Wednesday, June 03, 2009 8:42 AM To: IBM-MAIN@bama.ua.edu Subject: Why are z/OS people reluctant to use z/OS UNIX? When I grew up in the mainframe world, UNIX was considered to be the enemy. But I was working for IBM, and UNIX products were competitors, so that's kind of an expected perspective. Today, z/OS provides a rich set of UNIX services, including HFS/zFS files, a shell, a UNIX kernel, and more, to supplement / complement the classic MVS facilities. People who grew up with UNIX seem to despise or denigrate z/OS UNIX as missing a lot of features or behaviors that they are used to. But those of us who grew up in the OS/360-and-successors world don't know what we're missing, so it all seems to be pretty handy as is. Of course, there's always something new in the next release. There has been a perception that UNIX is less secure than z/OS. But I think that is an old perception. And when you utilize z/OS UNIX, your primary security comes from z/OS security services (RACF, Top Secret, ACF2, and so on), so that applications using z/OS UNIX should be as secure as any other z/OS applications. Several people on the list talk about their manager's dislike, distrust, disdain for z/OS UNIX (for example, John McKown recently wrote, speaking of people at his installation that would be left if he were to lose his job: They seem to regard UNIX on z/OS as an abomination.) I'd like to understand this visceral reaction, with an eye to seeing what can be done to moderate it down to at least a level of skepticism (OK, what can this do for me?). Of course, I have an agenda in doing this: I've written a number of courses on using z/OS UNIX, and I'd like to see some interest in companies taking this training. I'm just finishing up a course on writing COBOL CGIs, and it seems to me that if IT management truly wants to keep costs down, they would look at using z/OS for web hosting. This can be done very inexpensively: * IBM provides two free HTTP servers, one comes automatically with z/OS, the other is free but must be ordered separately * Most installations already have a COBOL compiler for writing CGI code, so there's no additional cost for software and you have staff that already knows the language or you can write CGIs in Assembler (a less attractive option in most shops) * Your installation already has VSAM and probably some database product such as DB2, so there's no need for any additional software to serve up data * Although you don't need Java to do this, if you want to use Java facilities, IBM provides it at no charge You don't need WebSphere; you don't need Java. Just the free facilities available with your z/OS system and your current programming staff. But you do need to use at least some parts of z/OS UNIX. So what's the hangup about z/OS UNIX? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search
Re: Why are z/OS people reluctant to use z/OS UNIX?
I asked this question to an IBM'er who does z/OS release level stress testing this past weekend in at a family party in Orange County NY. He works in the Poughkeepsie Labs and he admitted customer adoption of Unix systems services is slow, although he said they use it internally! Seems your point about Mainframe security not to mention the reduction of server sprawl are valid points that would only help prolong and diversify the use of our beloved platform. I know of at least one account Nationwide Insurance that has told me they have made successful use of this option. But back to my IBM acquaintance he seemed more concerned with IBM jobs going to India and picking up the workload of a recently laid off friend that he must now see around town. Michael Sullivan On Wed, Jun 3, 2009 at 8:41 AM, Steve Comstock st...@trainersfriend.com wrote: When I grew up in the mainframe world, UNIX was considered to be the enemy. But I was working for IBM, and UNIX products were competitors, so that's kind of an expected perspective. Today, z/OS provides a rich set of UNIX services, including HFS/zFS files, a shell, a UNIX kernel, and more, to supplement / complement the classic MVS facilities. People who grew up with UNIX seem to despise or denigrate z/OS UNIX as missing a lot of features or behaviors that they are used to. But those of us who grew up in the OS/360-and-successors world don't know what we're missing, so it all seems to be pretty handy as is. Of course, there's always something new in the next release. There has been a perception that UNIX is less secure than z/OS. But I think that is an old perception. And when you utilize z/OS UNIX, your primary security comes from z/OS security services (RACF, Top Secret, ACF2, and so on), so that applications using z/OS UNIX should be as secure as any other z/OS applications. Several people on the list talk about their manager's dislike, distrust, disdain for z/OS UNIX (for example, John McKown recently wrote, speaking of people at his installation that would be left if he were to lose his job: They seem to regard UNIX on z/OS as an abomination.) I'd like to understand this visceral reaction, with an eye to seeing what can be done to moderate it down to at least a level of skepticism (OK, what can this do for me?). Of course, I have an agenda in doing this: I've written a number of courses on using z/OS UNIX, and I'd like to see some interest in companies taking this training. I'm just finishing up a course on writing COBOL CGIs, and it seems to me that if IT management truly wants to keep costs down, they would look at using z/OS for web hosting. This can be done very inexpensively: * IBM provides two free HTTP servers, one comes automatically with z/OS, the other is free but must be ordered separately * Most installations already have a COBOL compiler for writing CGI code, so there's no additional cost for software and you have staff that already knows the language or you can write CGIs in Assembler (a less attractive option in most shops) * Your installation already has VSAM and probably some database product such as DB2, so there's no need for any additional software to serve up data * Although you don't need Java to do this, if you want to use Java facilities, IBM provides it at no charge You don't need WebSphere; you don't need Java. Just the free facilities available with your z/OS system and your current programming staff. But you do need to use at least some parts of z/OS UNIX. So what's the hangup about z/OS UNIX? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four == == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.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 -- 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: Why are z/OS people reluctant to use z/OS UNIX?
On Wed, 2009-06-03 at 06:41 -0600, Steve Comstock wrote:
So what's the hangup about z/OS UNIX?
Maybe the fact that for so much of its existence it was such a POS ?.
The initial iterations were bloody abysmal - poorly conceived, poorly
implemented and bloody near useless.
This have improved (there was only one direction it could go), but only
after inexcusable angst imposed on the user community.
I still have a hard time accepting
OMVS/OE/USS/whatever-the-marketing-people-called-it-this-week.
Shane ...
(and that from someone currently perusing the {Linux} memory management
source whilst watching the footy.)
--
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: Why are z/OS people reluctant to use z/OS UNIX?
Michael Sullivan wrote: I asked this question to an IBM'er who does z/OS release level stress testing this past weekend in at a family party in Orange County NY. He works in the Poughkeepsie Labs and he admitted customer adoption of Unix systems services is slow, although he said they use it internally! Seems your point about Mainframe security not to mention the reduction of server sprawl are valid points that would only help prolong and diversify the use of our beloved platform. I know of at least one account Nationwide Insurance that has told me they have made successful use of this option. But back to my IBM acquaintance he seemed more concerned with IBM jobs going to India and picking up the workload of a recently laid off friend that he must now see around town. That's the other windmill I'm tilting at these days: the benefits of insourcing - using local people for local work. Working to once again build trust and loyalty in the workplace, acknowledging that the workplace of the 21st century is different from the workplace of the 20th century. 21st century employees are unlikely to have company sponsored health benefits or pensions beyond any contributions to 401(k)-type plans. But they should have some stability in the workplace: we all need to have some kind of job / work. More will work at least part time from home or maybe local business service centers. Sorry, rambling. Michael Sullivan On Wed, Jun 3, 2009 at 8:41 AM, Steve Comstock st...@trainersfriend.com wrote: When I grew up in the mainframe world, UNIX was considered to be the enemy. But I was working for IBM, and UNIX products were competitors, so that's kind of an expected perspective. Today, z/OS provides a rich set of UNIX services, including HFS/zFS files, a shell, a UNIX kernel, and more, to supplement / complement the classic MVS facilities. People who grew up with UNIX seem to despise or denigrate z/OS UNIX as missing a lot of features or behaviors that they are used to. But those of us who grew up in the OS/360-and-successors world don't know what we're missing, so it all seems to be pretty handy as is. Of course, there's always something new in the next release. There has been a perception that UNIX is less secure than z/OS. But I think that is an old perception. And when you utilize z/OS UNIX, your primary security comes from z/OS security services (RACF, Top Secret, ACF2, and so on), so that applications using z/OS UNIX should be as secure as any other z/OS applications. Several people on the list talk about their manager's dislike, distrust, disdain for z/OS UNIX (for example, John McKown recently wrote, speaking of people at his installation that would be left if he were to lose his job: They seem to regard UNIX on z/OS as an abomination.) I'd like to understand this visceral reaction, with an eye to seeing what can be done to moderate it down to at least a level of skepticism (OK, what can this do for me?). Of course, I have an agenda in doing this: I've written a number of courses on using z/OS UNIX, and I'd like to see some interest in companies taking this training. I'm just finishing up a course on writing COBOL CGIs, and it seems to me that if IT management truly wants to keep costs down, they would look at using z/OS for web hosting. This can be done very inexpensively: * IBM provides two free HTTP servers, one comes automatically with z/OS, the other is free but must be ordered separately * Most installations already have a COBOL compiler for writing CGI code, so there's no additional cost for software and you have staff that already knows the language or you can write CGIs in Assembler (a less attractive option in most shops) * Your installation already has VSAM and probably some database product such as DB2, so there's no need for any additional software to serve up data * Although you don't need Java to do this, if you want to use Java facilities, IBM provides it at no charge You don't need WebSphere; you don't need Java. Just the free facilities available with your z/OS system and your current programming staff. But you do need to use at least some parts of z/OS UNIX. So what's the hangup about z/OS UNIX? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html==
Re: Why are z/OS people reluctant to use z/OS UNIX?
Don't you hate it when Shane is so reluctant to express his true feelings?
G,D,R
Steve Conway
Lead Systems Programmer
Information Systems Services Division
Computer Network Operations
Phone: (703) 450-3156
Fax:(703) 450-3197
A veteran is someone who, at one point in his life wrote a blank check
made payable to ' The United States of America ' for an amount of 'up to
and including my life.' That is Honor, and there are too many people in
this country who no longer understand it.
Shane ibm-m...@tpg.com.au
Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
06/03/2009 09:47 AM
Please respond to
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To
IBM-MAIN@bama.ua.edu
cc
Subject
Re: Why are z/OS people reluctant to use z/OS UNIX?
On Wed, 2009-06-03 at 06:41 -0600, Steve Comstock wrote:
So what's the hangup about z/OS UNIX?
Maybe the fact that for so much of its existence it was such a POS ?.
The initial iterations were bloody abysmal - poorly conceived, poorly
implemented and bloody near useless.
This have improved (there was only one direction it could go), but only
after inexcusable angst imposed on the user community.
I still have a hard time accepting
OMVS/OE/USS/whatever-the-marketing-people-called-it-this-week.
Shane ...
(and that from someone currently perusing the {Linux} memory management
source whilst watching the footy.)
--
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: Why are z/OS people reluctant to use z/OS UNIX?
IMO, there are two sides to z/OS Unix adoption story: 1) I think that z/OS Unix literacy amongst z/OS sysprogs is actually improving. Between 06 and 08 we taught a SHARE lab z/OS Tomcat in an hour and there was a big improvement in the attendees' comfort with z/OS Unix in that time. 2) Adoption of z/OS Unix by non-z/OS users is another story. Although z/OS does a good job of conforming to POSIX standards, it is weak compared to other Unix systems in that common open source tools are not available, and porting is often difficult. (See the http://oss4zos.org Wiki) Kirk Wolf Dovetailed Technologies http://dovetail.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: Why are z/OS people reluctant to use z/OS UNIX?
Developing a product under z/os UNIX raises the complexity but just does not add that much value. Using a ZFS/HFS file over a z/os dataset is just a matter of personal preference by the developers but can be a huge PITA for us support folks. We ask why we have to have two completely different infrastructures. That raises the cost of doing business, sometimes more so than the value added by the product. Complexity breeds fragility. Just my $0.02 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Steve Comstock Sent: Wednesday, June 03, 2009 7:42 AM To: IBM-MAIN@bama.ua.edu Subject: Why are z/OS people reluctant to use z/OS UNIX? ..snip So what's the hangup about z/OS UNIX? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: Why are z/OS people reluctant to use z/OS UNIX?
There's always some people afraid of change. Nothing can be done to fix that. I've been happily using IBM's mainframe Unix (for a lack of a better term) since OE first came out. Ignorant of so-called true Unix, I was eager to learn all I could about IBM's offering. Good stuff that keeps getting better! Guy Gardoit z/OS Systems Programming On Wed, Jun 3, 2009 at 5:41 AM, Steve Comstock st...@trainersfriend.comwrote: When I grew up in the mainframe world, UNIX was considered to be the enemy. But I was working for IBM, and UNIX products were competitors, so that's kind of an expected perspective. Today, z/OS provides a rich set of UNIX services, including HFS/zFS files, a shell, a UNIX kernel, and more, to supplement / complement the classic MVS facilities. People who grew up with UNIX seem to despise or denigrate z/OS UNIX as missing a lot of features or behaviors that they are used to. But those of us who grew up in the OS/360-and-successors world don't know what we're missing, so it all seems to be pretty handy as is. Of course, there's always something new in the next release. There has been a perception that UNIX is less secure than z/OS. But I think that is an old perception. And when you utilize z/OS UNIX, your primary security comes from z/OS security services (RACF, Top Secret, ACF2, and so on), so that applications using z/OS UNIX should be as secure as any other z/OS applications. Several people on the list talk about their manager's dislike, distrust, disdain for z/OS UNIX (for example, John McKown recently wrote, speaking of people at his installation that would be left if he were to lose his job: They seem to regard UNIX on z/OS as an abomination.) I'd like to understand this visceral reaction, with an eye to seeing what can be done to moderate it down to at least a level of skepticism (OK, what can this do for me?). Of course, I have an agenda in doing this: I've written a number of courses on using z/OS UNIX, and I'd like to see some interest in companies taking this training. I'm just finishing up a course on writing COBOL CGIs, and it seems to me that if IT management truly wants to keep costs down, they would look at using z/OS for web hosting. This can be done very inexpensively: * IBM provides two free HTTP servers, one comes automatically with z/OS, the other is free but must be ordered separately * Most installations already have a COBOL compiler for writing CGI code, so there's no additional cost for software and you have staff that already knows the language or you can write CGIs in Assembler (a less attractive option in most shops) * Your installation already has VSAM and probably some database product such as DB2, so there's no need for any additional software to serve up data * Although you don't need Java to do this, if you want to use Java facilities, IBM provides it at no charge You don't need WebSphere; you don't need Java. Just the free facilities available with your z/OS system and your current programming staff. But you do need to use at least some parts of z/OS UNIX. So what's the hangup about z/OS UNIX? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.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 -- 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: Why are z/OS people reluctant to use z/OS UNIX?
On Wed, 3 Jun 2009 06:41:53 -0600, Steve Comstock st...@trainersfriend.com wrote: ...They seem to regard UNIX on z/OS as an abomination.) I'd like to understand this visceral reaction, with an eye to seeing what can be done to moderate it down to at least a level of skepticism (OK, what can this do for me?). ... Here's what I said on the MVS-OE list. It's quite a different take on the topic than others have posted. It boils down to We've been spoiled by IBM which, I suspect may prompt an argument. Here are a couple reasons that seem to be mind-set differences, and my mind is too set to easily adjust. Messages: From syslog (truncated by me during cut/past) localhost snmpagent[33685543]: S_AGV123(837): localhost snmpagent[33685543]: setibmopt established affinity with stack TCPIP localhost snmpagent[33685543]: IBM SNMPBASE, 3.1.04-v3, Feb 28 2000, Compiled ... localhost snmpagent[33685543]: EZZ6267I Tracing set to 0 Now how in heaven's name do I look up those messages? I happen to know that the last 3 are ok, but what is the significance of the first one? The colon seems to imply it may be a header for the following messages, but I have no way of knowing for sure. And is S_AGV123(837) good or bad? Or commands: ping 1.2.3.4 -c 10 -s 10.9.8.7 -t 15 -l 1024 vs. ping 1.2.3.4 Count 10 SRCIP 10.9.8.7 Timeout 15 Length 1024 Just a matter of familiarity, I guess. But if I understand PING I can pretty much guess what the parms in the TSO command mean, even if I've never seen the command before. Not so, the Unix format. Having spent the last 36 years working on various IBM operating systems (mostly flavors of MVS) I am definitely a Unix novice. I get the very strong impression that developers of Unix applications either assume there is no such thing as a Unix novice, or that novices are not welcome. I'm not at all surprised that MVSers are reluctant to join the Unix world. It doesn't want us. Pat O'Keefe -- 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: Why are z/OS people reluctant to use z/OS UNIX?
I am one of those who hate UNIX on z/OS. Here's why: 1. A pain (as Shane had indicated) to install products. We're running WAS, and my colleague is complaining all the time. I remember when WAS was called Component Broken (ups, Broker), and those that introduced the 'concept' of it came from the UNIX world and had absolutely no clue how z/OS (back then OS/390) works, much less how to make a program perform. That hasn't changed, especially as IBM bases licence fees on 'new applications' and promotes USS as another unix to port to. It is NEVER easy to port to USS, and it usually messes up everything else. 2. A pain with regard to system controls. a) USS is expected to be exempt from all controls MVS has - look at iefusi and the huge warnings surrounding it if you *DON'T* give a USS address space what it wants! Same holds for other things. b) Try to use WLM on one of those USS applications! We have one that routinely runs around 65 address spaces that all wake up (timer driven) at the same time. Having (at least) 65 tcbs ready to run on 2 cps plays havoc with WLM PI, which is routinely in the three-digit-range. sarcasm on One would think that IBM by now had introduced the concept of a 'UNIX transaction' that can be classiifed via a response time goal. sarcasm off No such luck. I have complained about this before, check the archives! c) As was indicated before, performance of anything USS (even the telnet login similar to a TSO User) takes *a lot* more resources and consumes a lot more CPU. The USS users here were complaining when I put their 'TSO-alike' work into response time goals imposed by the TSO class. The high- performance short period was always way to short! d) Cannot tolerate being cpu-starved (by lpar code) and takes revenge by using thrice as much cpu once it gets it from lpar code. That was the main reason we got rid of Lotus Notes on z/OS and moved it to z/Linux on IFLs, with a magical increase in the number of Linux instances that supported the same amount of users. And don't get me talking about IBM software support when we had real problems! It was abysmal both on z/OS and on z/Linux! 3. A pain to support/debug. Try finding a bug in one of those stupid USS- applications! a) Just seen yesterday on WAS V6: The bloody thing got an abend0c4-28, and by the time they got around to requesting the dump, just about everything showing you the actual page fault had already gotten rid of (including the rtm2wa). Try getting the concept of 'seeing' an error like this from the task structure across to IBM software support - hopeless! b) The best excuse IBM has to NOT find a problem - they can almost always say that this or that crucial information was not in the dump, mostly because that information is littered across several OMVS data spaces, with anchors somewhere in OMVS asid, plus 'supporting address spaces' like ZFS or SMSPDSE/1. The application I alluded to earlier with the 65 address spaces? *One* of those things held some sort of 'other end' to a pipe, preventing automatic termination of the application. We were told to dump 'all of those address spaces' (never mind that wildcard support for the pesky number in 8th place only supports 16 address spaces). So the perfect excuse because the address space holding that pipe was not dumped because there was no way to determine which asid it is before a dump. That problem still pops up now and again, but we all have resigned to the fact that it will mess up system shutdown. c) Don't even get me started on Java applications running on z/OS. The oh-so- portable Java. That again cannot deal with being in any way resource constrained. And those that 'program' Java (if you call clicking here and there 'programming') have absolutely no clue what is involved when a problem occurs- Try getting java (in the UK), the java batch launcher (in the US), LE support, MQSeries support (because the application uses some MQ interfaces), DB2 support (because the application uses some DB2 interfaces), and OMVS support to actually talk to each other! Everyone pointed their finger at another component, sending the ETR round and round. Well, after the first round I started complaining. Loudly. The Java lab (with infinite patience) found out who had violated architecture (when clicking) and those that had screamed loudest that it wasn't them got to fix the problem. A sev1, by the way, in a productive environment. I hate USS because architecturally it does not fit into z/OS. UNIX probably has it uses, but not in z/OS. Just my opinion, of course. Barbara Nitz -- 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
