Scott, Hearsay, hearsay :-)
We have found that Java performance can be excellent. The biggest problem is that Java programmers commonly write poor performing applications that are bogged down with huge, expensive libraries and frameworks. The same can be said for huge Java applications servers. Java makes it easy to use and resuse literally thousands of Java libraries, but it also makes it easy to use lots of CPU resources. But it doesn't have to be that way, and the Java Languages and SDK/JVM are not to blame. Programmers need to not only know how to use a library, but when to use it, and what the cost trade-offs are. I also don't understand your comments about C, can you elaborate? The z/OS C documentation is quite good I think. A good C programmer with knowledge of z/OS facilities (especially LE) can succeed with the IBM tools, which include debuggers, profilers, assembler listings, etc, etc. Kirk Wolf Dovetailed Technologies http://dovetail.com On Sat, Sep 1, 2012 at 5:15 PM, Scott Ford <scott_j_f...@yahoo.com> wrote: > John, > > With what heard about the Java performance hit, it's relativity a slow > performer. > What I see of C it's ok but, the documentation, good examples are lacking. > The data types especial strings with z/os bring different than Unix....I > know these languages are evolving, my comments are negative criticisms of > IBM. > > Scott ford > www.identityforge.com > > On Sep 1, 2012, at 4:26 PM, John McKown <john.archie.mck...@gmail.com> > wrote: > > > IIRC, both C and PL/I use the same back end code generator, while COBOL > > does its own thing. That may be why COBOL seems to stay behind them. > > On Sep 1, 2012 2:49 PM, "zMan" <zedgarhoo...@gmail.com> wrote: > > > >> Indeed. The lack of improvements for EC12 may simply reflect where the > >> COBOL folks are in their release cycle -- maybe they missed the window, > and > >> it's coming later. Or not. > >> > >> On Sat, Sep 1, 2012 at 1:58 PM, Scott Ford <scott_j_f...@yahoo.com> > wrote: > >> > >>> Clark, > >>> > >>> I seriously doubt COBOL is on a deathbed considering how java performs > on > >>> a z/os. > >>> Secondly, a serious amount of banking is on legacy machines in COBOL. > >>> Banks aren't going to convert if it costs more money > >>> > >>> Scott ford > >>> www.identityforge.com > >>> > >>> On Aug 31, 2012, at 7:39 PM, Clark Morris <cfmpub...@ns.sympatico.ca> > >>> wrote: > >>> > >>>> On 28 Aug 2012 06:55:54 -0700, in bit.listserv.ibm-main you wrote: > >>>> > >>>>> With the new machine,it seems like there is A LOT to read which is > >>> greate! .. You may find it usefull to check this part of Draft EC12 > tech > >>> guide redbook.I think it is nice,because it summaries performance > items > >>> well .... > >>>> > >>>> I notice that the language most used on the z, COBOL has NO > >>>> improvements related to the EC12. There are improvements for PL/1 and > >>>> C/C++. This speaks louder than anything else as to whether IBM thinks > >>>> COBOL is on its deathbed. > >>>> > >>>> Clark Morris > >>>>> > >>>>> Regards > >>>>> Meral > >>>>> > >>>>> 1.9.7 Main performance improvement drivers with zEC12 > >>>>> > >>>>> The zEC12 is designed to deliver new levels of performance and > >> capacity > >>> for large scale > >>>>> consolidation and growth. The following attributes and design points > >> of > >>> the zEC12 contribute > >>>>> to overall performance and throughput improvements as compared to the > >>> z196. > >>>>> /Architecture implementation enhancements: > >>>>> > >>>> Transactional Execution (TX) designed for z/OS, Java, DB2 and other > >>>> exploiters > >>>>> > >>>> Runtime Instrumentation (RI) provides dynamic and self-tuning online > >>>> re-compilation > >>>>> capability for Java workloads > >>>>> > >>>> Enhanced DAT-2 for supporting 2 GB large pages for DB2 buffer pools, > >>>> Java heap size and > >>>>> other large structures > >>>>> > >>>> Software directives implementation to improve hardware performance > >>>>> > >>>> Decimal format conversions for COBOL programs. > >>>>> zEC12 microprocessor design enhancements: > >>>>> > >>>> Six processor cores per chip > >>>>> > >>>> Enhanced Out Of Order (OOO) execution design > >>>>> > >>>> Improved pipeline balance > >>>>> > >>>> Enhanced branch prediction latency and instruction fetch throughput > >>>>> > >>>> Improvements on execution bandwidth and throughput > >>>>> > >>>> New design for Level 2 private cache with separation of cache > >>>> structures for instructions > >>>>> and L2 operands > >>>>> > >>>> Reduced access latency for most of Level 1 cache misses > >>>>> > >>>> Bigger Level 2 cache with shorter latency > >>>>> > >>>> Third level on-chip shared cache is doubled > >>>>> > >>>> Fourth level book-shared cache is doubled > >>>>> > >>>> Hardware and software prefetcher handling improvements > >>>>> > >>>> Increased execution/completion throughput > >>>>> > >>>> Improve fetch and store conflict scheme > >>>>> > >>>> Enhance branch prediction structure and sequential instruction > >>>> fetching > >>>>> > >>>> Millicode performance improvements > >>>>> > >>>> Optimized floating-point performance > >>>>> > >>>> Faster engine for fixed-point division > >>>>> > >>>> New second level branch prediction array > >>>>> > >>>> One cryptographic/compression co-processor per core > >>>>> > >>>> Cryptography support of UTF8<>UTF16 conversions > >>>>> > >>>> Higher clock frequency at 5.5 GHz > >>>>> > >>>> IBM CMOS 13S 32nm SOI technology with IBM eDRAM technology. > >>>>> zEC12 design enhancements: > >>>>> > >>>> Increased total number of PUs available on the system, from 96 to > >>>> 120, and number of > >>>>> characterizable cores, from 80 to 101 > >>>>> > >>>> Hardware System Area increased from 16 GB to 32 GB > >>>>> > >>>> Increased default number of SAP processors per book > >>>>> > >>>> New CFCC code available for improved performance > >>>>> – Elapsed time improvements when dynamically altering the size of a > >>> cache structure > >>>>> – DB2 conditional write to a group buffer pool (GBP) > >>>>> – Performance improvements for coupling facility cache structures to > >>> avoid flooding the > >>>>> coupling facility cache with changed data and avoid excessive delays > >>> and backlogs for > >>>>> cast-out processing > >>>>> – Performance throughput enhancements for parallel cache castout > >>> processing by > >>>>> extending the number of RCC cursors beyond 512 > >>>>> – CF Storage class and castout class contention avoidance by breaking > >>> up individual > >>>>> storage class and castout class queues to reduce storage class and > >>> castout class latch > >>>>> contention. > >>>>> New features available on the zEC12: > >>>>> > >>>> Crypto Express4S performance enhancements > >>>>> > >>>> Flash Express PCIe cards to handle paging workload spikes and improve > >>>> performance > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> This message and attachments are confidential and intended solely for > >>> the individual(s) stated in this message. If you received this message > >>> although you are not the addressee, you are responsible to keep the > >> message > >>> confidential. The sender has no responsibility for the accuracy or > >>> correctness of the information in the message and its attachments. Our > >>> company shall have no liability for any changes or late receiving, loss > >> of > >>> integrity and confidentiality, viruses and any damages caused in anyway > >> to > >>> your computer system. > >>>>> > >>>>> Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere > >>> ozeldir ve gizlidir. Bu mesajin muhatabi olmamaniza ragmen tarafiniza > >>> ulasmis olmasi halinde mesaj iceriginin gizliligi ve bu gizlilik > >>> yukumlulugune uyulmasi zorunlulugu tarafiniz icin de soz konusudur. > Mesaj > >>> ve eklerinde yer alan bilgilerin dogrulugu ve guncelligi konusunda > >>> gonderenin ya da sirketimizin herhangi bir sorumlulugu bulunmamaktadir. > >>> Sirketimiz mesajin ve bilgilerinin size degisiklige ugrayarak veya gec > >>> ulasmasindan, butunlugunun ve gizliliginin korunamamasindan, virus > >>> icermesinden ve bilgisayar sisteminize verebilecegi herhangi bir > zarardan > >>> sorumlu tutulamaz. > >>>>> > >>>>> > ---------------------------------------------------------------------- > >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>>> send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > >>>> > >>>> ---------------------------------------------------------------------- > >>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >>> > >>> ---------------------------------------------------------------------- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >>> > >> > >> > >> > >> -- > >> zMan -- "I've got a mainframe and I'm not afraid to use it" > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
