> Check: ASM_LOCAL_SLOT_USAGE > Adding more locals is always an option (again), my question was more on > experiences people have with locals on WebSphere LPARs. We're using quite > large locals (as big as the DASDs they are located on - 10k CYLS, one full > model 9 3390 DASD). > Does it make sense to also add more physical storage? (WebSphere seems a bit > acquisitive :o) How much locals do others have on WebSphere LPARs? How many > servers are running there?
Well, I forgot to mention that the lpar where this check hit earliest was the one all of the 'USS work' runs, including WAS and something I called "the brokers" (some MQS application; WBI?). That lpar had the most real storage in that productive sysplex (even more than the beloved IMS lpar), and the most locals. The situation got worse when we migrated from 1.10 to 1.12 - in 1.11 there were changes that required more real storage. So that lpar got 3GB more real and had about 20 full mod9 page data sets. Slot usage was then down to 20%. WAS and the DB2 DBMR address space are the biggest offenders in terms of hogging storage. (It is their god-given right, apparently.) The broker stuff (as a JAVA application) also filled up the page data sets at startup, and only ever seemed to use that storage again during shutdown. > Check: XCF_SIG_STR_SIZE > Mike & Barbara - don't you loose definitions if you start the sysplex with an > empty CDS? You would then have to re-apply all policies? > How would the first system IPL without a proper CFRM policy? :) IPL into > monoplex -> submit policy jobs -> reIPL into sysplex? Yes, you loose all information in the old data sets. In any case, it is a VERY good idea to have a central repository that every sysprog knows about where you keep the definition jobs for all CDSs, all policies (well, except WLM), and preferably all joblogs formatting them (on DASD, not in some archival product). I kept all of our CDSs with a unique name across the installation and uncatalogued (that enables me to define a CDS and write a CFRM policy from any system still up for any sysplex that is completely down without the awkward 'come up in GRS=NONE and then reIPL' thing). You start a CFRM policy via COUPLExx (parameter CFRMPOL). But that only works on freshly formatted CFRM CDSs where there is nothing in the slot reserved for the 'active policy'. If the CFRM CDSs were active before, that slot isn't empty, so that COUPLExx parm doesn't help. In my opinion, it isn't such a big deal to start from freshly formatted sysplex and CFRM CDSs. The problem is the LOGR CDS. Using a freshly formatted LOGR CDS, you cannot put any policy in beforehand, and you will loose all of the offloaded data addressable via the old CDS. Since you're using RRS, that means an RRS cold start. (CICS might 'cold-start', too, no experience with SMF). For LOGR and WLM, you can IPL the first system in the sysplex without it. Then, when the first system is up (no products needing LOGR will come up, obviously), define both primary and alternate LOGR and WLM CDS, write both policies into those data sets and activate them. Update your COUPLExx and IPL all other systems in the plex. I am not sure about the SFM data set. It may be writable before an IPL without a fuss. And we never used shared HFS, so I have no idea if OMVS would sputter on a freshly formatted CDS, but I cannot imagine why it should. I repeat my warning: If you lower MAXSYSTEM, make sure ALL of your CDSs are formatted to the same values of MAXSYSTEM, otherwise you might see some bad surprises. It is easy to increase that value dynamically, but impossible to decrease it dynamically. > Check: IXGLOGR_ENTRYTHRESHOLD > Barbara - does this mean AUTOALTER can/should (by IBM) be used for list > structures? (Sorry, I can't find a good reference on this). If you hear IBM, they want you to use AUTOALTER on any structure that supports it (you still need to have the structure defined in such a way that altering it either automatically or via setxcf alter command is possible). Again, I have seen that AUTOALTER lost me full signalling connectivity, so that was a definite no-no allowing it on signalling structures. I deleted this LOGR check since it never was a 'good warning' anyway last I looked. If you check the books what triggers offload in a LOGR structure, it is the defined threshold of either entries or elements getting exceeded. So LOGR will offload on that condition and *also* write an exception message (why?!?). That nobody can act upon, since reaching that threshold is an integral part of the design. Add to that AUTOALTER (done by a different component), and you will not really have a chance to detect any (real) problem early. As far as I am concerned, I'd rather do an offload than have two components work on the same structure at the same time. Other than signalling structures and LOGR structures, AUTOALTER was allowed (defaulted to). Hope that helps, Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
