Rick Rodie wrote: >But now we wish to branch out to more LPARs. Our laundry list includes >a COBOL penalty LPAR and a DB2 LPAR, both for the purpose of using the >IBM pricing strategy in VWLC to reduce our costs. COBOL could be priced >at 3 MSUs, and while DB2 would not reduce, at least its heavy lifting >efforts from external sources could be relegated away from adding to our >cost for CICS, IMS, Netview, etc. environment.
Off on a slight (only slight) tangent here, but I assume you'll be running z/OS.e for the DB2 side (and get z/OS.e pricing). If not, I think the COBOL compiler will be charged at the z/OS capacity for the system. Note that you can run (compiled) COBOL DB2 stored procedures -- z/OS.e allows that. Naturally you'll want to weigh other costs (e.g. staff time, storage) against the VWLC benefits when separating certain work into their own LPARs. But if you're fencing into 3 MSUs (softcap I assume) and your DB2 LPAR(s) will be much larger, that's evidence you're probably onto something there. It'll also let you upgrade the DB2 LPAR to z/OS 1.6 (or higher) first, a prerequisite for zIIP support, then come back and get the COBOL LPAR upgraded if for some reason you need extra time there. >And with us considering a z9 BC that would have 8 CPs, 4 MVS, 1 >SAP, 1 zIIP committed, that leaves us just the two with no spares if >they both were employed as ICFs. We have no IFLs or zAAPs, and no >expectation that we will anytime soon. The System z9 BC has a maximum of four CPs configurable for z/OS (or z/OS.e), but that's a maximum. Are you sure you'll be configuring all four? Looking at the tables, there are an awful lot of capacity options even if you're configuring an X0Y model where Y <= 3. You also mentioned lots of external access to DB2. I would recommend visting the idea of an IFL to see if that offers benefits. Examples include DB2 Connect and any sort of ETL from DB2 (even if Linux is not the final destination). There are some really compelling benchmarks in this area. The zIIP is another bonus, but remember that a HiperSocket JDBC/ODBC connection is still zIIP-eligible. Before anyone asks, if you want maximum efficiency then local data access (within the same LPAR) still beats zIIP+IFL (crossing LPARs), often quite substantially. Application proximity to databases still matters, always will. Of course, crossing LPARs is more efficient than crossing physical networks. The zIIP doesn't change the hierarchy, but if you do have to cross LPARs or systems for data access it's definitely a plus. (Also handles certain DB2 utilities work and star schema queries.) You could end up with something like 3 (or fewer) CPs, 1 ICF, 1 zIIP, and 1 IFL. That'd still leave you with a spare and thus some headroom. You can spend that engine later on an IFL, CP, or ICF if you want. Let us know how your zIIP experiences go, OK? - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries Tokyo (Serving IBM Japan and IBM Asia-Pacific) E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- 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
