Mark, >Why not? Didn't you say it was only a problem a system shutdown time? >Do you care about some extra paging while you shut down?
Your question made me look up the system commands book. Yes, there is a setsmf command that would allow me to only increase the buffer size during shutdown! (I'll try to get that implemented - thanks). My colleagues refused to have them permanently set to 1G, because on these lpars the same workload executes as in production (they use production data sent over for testing), only with a lot less resources. And these systems have an average usage of 20% for all our page data sets, so there is enough paging going on already! As for how logger works: Here is my understanding, and this appears to be true in 1.8 still: Assuming log streams mapped to a structure, any data written to the log stream will end up first in the structure. Once the structure is filled 80% (the default or whatever is set for LOGR parm HIGHOFFLOAD) for either entries or elements, LOGR will start a race condition across all IXGLOGR address spaces connected to this logstream to do the offload. Whichever system wins that race will write out data to DASD. (LOGGERDUPLEX(UNCOND) would harden the data immediately to DASD in the duplex data sets, conditional LOGR duplexing only if the structure is in a volatile CF - the normal place to hold all data sent to the CF is storage, data space, I think). During shutdown there is always offload done called 'directed offload'. I just checked the last IPLs for operlog, and msgIXG303I is issued from a system that *is not* shut down, after the vary xcf,offline command. So for SMF log streams the behaviour should be the same: Directed offload from *another* system to get the data out to DASD where they can be read in again later. Now, when a *sysplex-wide* IPL is done, then there is no 'surviving' system, and the system where the v xcf,offline is done *last*, ends up doing the directed offloads. That goes on until an actual wait state is loaded on the last system, too. Three systems plex, A, B and C: C is shut down via v xcf,offline. B does directed offload. While that is still running (and no way to *see* it is running), B gets v xcf,offline. The loading of the wait state will interrupt offload processing, possibly leaving log streams corrupted. So my understanding is that the requirement is to only allow the wait state for the *last* system in the plex until offload is done *or* (more probable) to *not* issue the IEE334I HALT EOD SUCCESSFUL message until the SMF log data offload is complete. (Which may be hard to do as it requires XCF communication to find out when *another* system has finished, or else to change the logger design to do directed offload on the same system). The way I see it, first order of business is to turn on LOGGERDUPLEX (UNCOND). Next order of business is to write an MPF exit that changes IXG304I DIRECTED OFFLOAD FOR LOGSTREAM smf-whatever-the-name IS COMPLETE so that it is not issued hardcopy only but instead red on the console. Operators need to get threatened with termination if they dare to issue the v xcf,offline command to another system *before* that message was issued. (Mark, sysprogs too, if too many of them are shutting down systems at the same time causing sysplex-IPLs :-) ). Did IBM ask to turn on loggerduplex(uncond)? Best regards, Barbara ---------------------------------------------------------------------- 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
