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 waaaaayyyyy 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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
