Re: SMF LOGGER - Not Ready for Prime Time
Since I'm already using SMF logger, I installed the V1.9 version of the APAR and played with it. At first I was dismayed that it didn't seem to solve one of the main problems in the original design: the inability to run a single canned set of control cards regardless of day or time. Then I got clarification from IBM--and a commitment to include the explanation in the doc, which currently gives no example of the ARCHIVE function. The solution is to use these control cards: LSNAME(log-stream-name,OPTIONS(ARCHIVE)) --- OPTIONS is new RELATIVEDATE(BYDAY,0,1)--- new parameter This results in the following messages: IFA834I RELATIVEDATE PARAMETER RESULTS IN START DATE 2009.161, END DATE 2009.161 IFA836I RELATIVEDATE RANGE EXTENDS INTO FUTURE, END DATE AND TIME USED IS 2009.161 09:34 Some important notes: 1. ARCHIVE instructs the utility to write out records from the log stream and 'delete' them, i.e. make them unavailable for subsequent archiving. 2. Although the stated start and end dates are the same--essentially 'today'--in fact ARCHIVE always starts at the very beginning of the log stream and scans for the first record that has not been previously archived. If the log stream is actually three days old, the operation above will nonetheless process any data not yet archived. 3. Message IFA836I causes a successful archive process to end with CC=4. This is new but consistent with old behavior wherein an actual *error* gets CC=8. Conditional JCL may need modification to allow for 4 being OK. 4. If IFASMFDL does not find any 'new' data at all to archive, it returns CC=8 with this cryptic message: IFA832I INVALID PARAMETER COMBINATION FOR ARCHIVE OPTION This apparently refers to an attempt--documented as invalid--to ARCHIVE (or DELETE, a different operation) an *entire* log stream. For some reason you have to leave a few crumbs behind. OK, this append has turned into my next SHARE pitch. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com Knutson, Sam sknut...@geico.c OMTo Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List ibm-m...@bama.ua Subject .edu Re: SMF LOGGER - Not Ready for Prime Time 06/04/2009 09:35 AM Please respond to IBM Mainframe Discussion List ibm-m...@bama.ua .edu PTFs UA47565 for 1.9 UA47566 for 1.10 now available. http://www.ibm.com/support/docview.wss?uid=isg1OA27037 Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:sknut...@geico.com (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Thursday, May 21, 2009 12:02 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMF LOGGER - Not Ready for Prime Time On Thu, 14 May 2009 14:41:48 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: We were early adopters of SMF logger in order to prepare for a winter SHARE session after a 1.9 ESP. At that time we used it only in the sandbox sysplex where SMF data was throwaway. It's now running also in the development sysplex where SMF data is actually cherished and nurtured. With only a hiccup or two, the process has been reliable if a bit kludgy. The main problems I recall have involved a shortage of DASD space for the offload data sets. Normally there's plenty
Re: SMF LOGGER - Not Ready for Prime Time
PTFs UA47565 for 1.9 UA47566 for 1.10 now available. http://www.ibm.com/support/docview.wss?uid=isg1OA27037 Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:sknut...@geico.com (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Thursday, May 21, 2009 12:02 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMF LOGGER - Not Ready for Prime Time On Thu, 14 May 2009 14:41:48 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: We were early adopters of SMF logger in order to prepare for a winter SHARE session after a 1.9 ESP. At that time we used it only in the sandbox sysplex where SMF data was throwaway. It's now running also in the development sysplex where SMF data is actually cherished and nurtured. With only a hiccup or two, the process has been reliable if a bit kludgy. The main problems I recall have involved a shortage of DASD space for the offload data sets. Normally there's plenty here, but some (dimly recollected) condition caused an offload failure. I don't know whether the weakness is in SMF's use of logger or in logger itself, but once a 'full' condition occurs and the structure gets disconnected, I've had a very hard time jump starting the process without losing data. There are rumblings about improvements on the way that should upgrade the prime time status from 'not ready' to 'get set'. Maybe even 'go'. . More than rumblings now. This showed up in my ASAP this morning. I'm glad IBM was kind enough to roll this support back to z/OS 1.9 in addition to z/OS 1.10.Better late than never :-) APAR Identifier .. OA27037 Last Changed 09/05/20 NEW FUNCTION This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
On Thu, 14 May 2009 14:41:48 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: We were early adopters of SMF logger in order to prepare for a winter SHARE session after a 1.9 ESP. At that time we used it only in the sandbox sysplex where SMF data was throwaway. It's now running also in the development sysplex where SMF data is actually cherished and nurtured. With only a hiccup or two, the process has been reliable if a bit kludgy. The main problems I recall have involved a shortage of DASD space for the offload data sets. Normally there's plenty here, but some (dimly recollected) condition caused an offload failure. I don't know whether the weakness is in SMF's use of logger or in logger itself, but once a 'full' condition occurs and the structure gets disconnected, I've had a very hard time jump starting the process without losing data. There are rumblings about improvements on the way that should upgrade the prime time status from 'not ready' to 'get set'. Maybe even 'go'. . More than rumblings now. This showed up in my ASAP this morning. I'm glad IBM was kind enough to roll this support back to z/OS 1.9 in addition to z/OS 1.10.Better late than never :-) APAR Identifier .. OA27037 Last Changed 09/05/20 NEW FUNCTION Symptom .. NF NFStatus ... CLOSED UR1 Severity ... 4 Date Closed . 09/05/20 Component .. 5752SC100 Duplicate of Reported Release . 740 Fixed Release 999 Component Name 5752 SMF SCHEDU Special Notice ATTENTION Current Target Date ..09/06/05 Flags SCP ...NEW FUNCTION Platform Status Detail: APARCLOSURE - APAR is being closed. PE PTF List: PTF List: Release 740 : PTF not available yet Release 750 : PTF not available yet Parent APAR: Child APAR list: ERROR DESCRIPTION: New function APAR When using the IFASMFDL program to dump SMF log stream data, you can specify the RELEATIVEDATE parameter to filter the data recorded during a specific date range. The LSNAME parameter of the IFASMFDL program supports new OPTIONS keywords to delete data from the log stream: -- ARCHIVE, which deletes data after dumping the log stream to a data set. -- DELETE, which simply deletes the data from the log stream. You can specify the MAXDORM parameter in parmlib member SMFPRMxx for both data set recording and log stream recording. LOCAL FIX: N/A PROBLEM SUMMARY: * USERS AFFECTED: HBB7740 and above installations that use * * SMF recording to logstream * * PROBLEM DESCRIPTION: New function APAR * * RECOMMENDATION: * New function APAR to support additional options for the IFASMFDL utility. PROBLEM CONCLUSION: TEMPORARY FIX: COMMENTS: New function support for the RELATIVEDATE, ARCHIVE and DELETE options for IFASMFDL. For information on new messages IFA832I, IFA833I, IFA834I, IFA835I, IFA836I and IFA837I see the publication updates for z/OS MVS System Messages, Vol 8 (IEF-IGD) (SA22-7638). For information about new ABEND code x'654' see the publication updates for z/OS MVS System Codes (SA22-7626). For information about new RELATIVEDATE, ARCHIVE and DELETE options for the IFASMFDL utility see the publication updates for z/OS MVS System Management Facilities (SMF) (SA22-7630). For the updated behavior of the MAXDORM option in SMFPRMxx see the publication updates for z/OS MVS Initialization and Tuning Reference (SA22-7592). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
We were early adopters of SMF logger in order to prepare for a winter SHARE session after a 1.9 ESP. At that time we used it only in the sandbox sysplex where SMF data was throwaway. It's now running also in the development sysplex where SMF data is actually cherished and nurtured. With only a hiccup or two, the process has been reliable if a bit kludgy. The main problems I recall have involved a shortage of DASD space for the offload data sets. Normally there's plenty here, but some (dimly recollected) condition caused an offload failure. I don't know whether the weakness is in SMF's use of logger or in logger itself, but once a 'full' condition occurs and the structure gets disconnected, I've had a very hard time jump starting the process without losing data. There are rumblings about improvements on the way that should upgrade the prime time status from 'not ready' to 'get set'. Maybe even 'go'. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com Mark Zelden mark.zel...@zuri CHNA.COM To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List ibm-m...@bama.ua Subject .edu Re: SMF LOGGER - Not Ready for Prime Time 05/11/2009 06:24 AM Please respond to IBM Mainframe Discussion List ibm-m...@bama.ua .edu On Sun, 10 May 2009 10:47:36 -0500, Jim Marshall jim.marsh...@opm.gov wrote: But I think IBM was remiss in not understanding the full ramifications of how they have sites implement the LOGGER. If they would have talked to some savy users, then could have made the journey much smoother. That was apparent from the first time real presentation I saw at SHARE. And we've already had plenty of past discussions about that. At this point I still have no plans to implement it since the old way can keep up at our shop and have never had problems with lost SMF data. I do like the concept of multiple logstreams and the convenience it may eventually bring, but for now we'll just split off the different files during our nightly processing.I do have it running in some sandbox LPARs where we don't care about SMF data. In the past, those LPARs just dumped to a GDG in case we wanted the data later or dumped to DD DUMMY. Mark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
On Sun, 10 May 2009 10:47:36 -0500, Jim Marshall jim.marsh...@opm.gov wrote: But I think IBM was remiss in not understanding the full ramifications of how they have sites implement the LOGGER. If they would have talked to some savy users, then could have made the journey much smoother. That was apparent from the first time real presentation I saw at SHARE. And we've already had plenty of past discussions about that. At this point I still have no plans to implement it since the old way can keep up at our shop and have never had problems with lost SMF data. I do like the concept of multiple logstreams and the convenience it may eventually bring, but for now we'll just split off the different files during our nightly processing.I do have it running in some sandbox LPARs where we don't care about SMF data. In the past, those LPARs just dumped to a GDG in case we wanted the data later or dumped to DD DUMMY. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
We are still at 1.8, but I had intended to use this functionality as soon as we have migrated to 1.10. We are loosing SMF data regularly during shutdown of *one* system at a time, because of all the SMF30 termination records that get written at DB2 and IMS shutdown. We cannot increase the SMF buffers any further and we are at the end of any tuning for the SMF data sets. We are at the point where we stagger the DB2/IMS shutdown in hopes that the dumping of SMF records is through when the next comes. I had wondered how LOGGER would handle offload of a huge amount of SMF data right during shutdown. Do you also see this problem if you only shut down one system? Or only when there is no system left that can do the actual offload from the CF? And may I enquire why you regularly do sysplex-wide IPLs? Back when our auditors press us to turn on UAUDIT for RACF, we found during some times when so many RACF records were being sent to SMF it could not keep up; even though the MANx data sets were empty. Thus SMF said data was lost but did not tell us whose (was RACF). Auditors were not pleased about this and therefore IBM's solution was the LOGGER. So for our journey into the SWAMP. I know my guys have created a bunch of REXX routines to cover some of the sortcomings of how the process should work. Our present challenge in the swamp was at shutdown when Z EOD is entered there is no communication to the LOGGER to wait for him/her/it to complete what has to be done so when OPS re'ipls, then nothing is lost. IBM gave us a bunch of commands to have the operator enter although so far these have not worked. Plus even though the LOGGER says it is done, it is actually still off doing its thing with no indication when it honestly is completed. Level 2 agrees with us whole heartily but needed us to open a marketing request which I understand forces different parts of IBM to take notice and communicate with each other. I think this kinda assigns a referee who can get the attention of all parties on behalf of the customer. So in general, shutting down any LPAR can get you in trouble with the hosing up LOG files for that system. The way I am told is each system in a SYSLPLEX does its own thing with its LOG files (am by no means the expert for the techies are more into this than I). We have been having some building power upgrades and without a generator, then indeed we have to put everything to bed when it happens. Then some EMC DASD upgrades with multiple BIN file changes over a number of weekends caused some more total down time. When the swamp has been turned into something manageable, then I will give an update of how things can work. I understand the rationale to change the way SMF was offloaded which goes back my days in OS/MVT. But I think IBM was remiss in not understanding the full ramifications of how they have sites implement the LOGGER. If they would have talked to some savy users, then could have made the journey much smoother. So now, we do it the taumatic way which keeps life interesting here. jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
On Fri, 8 May 2009 00:09:21 -0500, Barbara Nitz nitz-...@gmx.net wrote: We do sysplex-wide IPLs twice a year (on fresh CDSs) as part of our DR testing. I was just wondering how frequent 'frequent' is that it became a real issue for the OP. For one of our businesses we have scheduled change windows once a month (some months get 2). During the window the MVS team does the shutdown and IPLs. We can do sysplex-wide IPLs every time if we wanted to and it works out that we do sometimes just because of the timing of us shutting everything down and re-IPLing. We used to do it on purpose more in the past because of certain things that would only break from a sysplex wide IPL, and I'd rather it break while we are here last Sat. night / Sun. morning than during the day from an unscheduled outage. We had this discussion once before. Skip said to avoid it at all costs after he ran into one of these problems and I stated what I wrote above. Sysplex wide outages do happen, and we were burned once by something that was wrong in the plex after an OS upgrade but the change never took place because of rolling IPLs. This might be in the archives too as part of that thread (I don't recall) ... without going into a lot of detail, a test version of the RACF DSNT that had a single dsn instead of multiple dsns rolled in with an OS upgrade. After a sysplex outage the dsnt change went in and of course there was RACF problems and a huge mess to recover from. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
On Fri, 8 May 2009 00:09:21 -0500, Barbara Nitz nitz-...@gmx.net wrote: We've always done it that way. :-( I feel with you! :-) BUFSIZMAX is set to 512MB on both machines this occurs. We cannot go higher, as this is already 10% of the available real storage, and there are at least 2 DBs with their own buffers set high running on each of those lpars. 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? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
Jim, thanks for that heads-up. We are still at 1.8, but I had intended to use this functionality as soon as we have migrated to 1.10. We are loosing SMF data regularly during shutdown of *one* system at a time, because of all the SMF30 termination records that get written at DB2 and IMS shutdown. We cannot increase the SMF buffers any further and we are at the end of any tuning for the SMF data sets. We are at the point where we stagger the DB2/IMS shutdown in hopes that the dumping of SMF records is through when the next comes. I had wondered how LOGGER would handle offload of a huge amount of SMF data right during shutdown. Do you also see this problem if you only shut down one system? Or only when there is no system left that can do the actual offload from the CF? And may I enquire why you regularly do sysplex-wide IPLs? Best regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Barbara Nitz [ snip ] And may I enquire why you regularly do sysplex-wide IPLs? We've always done it that way. :-( -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
There is a zap avail somewhere on IBM link that addresses this issue by changing the size/expansion limits on SMF Buffers for 1.8 and below. This is avail in 1.9 (Not as a zap) as BUFSIZMAX. Check the init/tuning guide for details. BUFSIZEMAX has solved our issues with lost SMF data at shutdown time. HTH, snip ... I had wondered how LOGGER would handle offload of a huge amount of SMF data right during shutdown. Do you also see this problem if you only shut down one system? Or only when there is no system left that can do the actual offload from the CF? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
Small correction: the parameters BUFSIZMAX and BUFUSEWARN are available from z/OS 1.8 on and the zap was available below 1.8. Kees. Staller, Allan allan.stal...@kbm1.com wrote in message news:6cd8dd927eba514e9db1e36304be38d7117ad...@hou-mail.kbm1.loc... There is a zap avail somewhere on IBM link that addresses this issue by changing the size/expansion limits on SMF Buffers for 1.8 and below. This is avail in 1.9 (Not as a zap) as BUFSIZMAX. Check the init/tuning guide for details. BUFSIZEMAX has solved our issues with lost SMF data at shutdown time. HTH, snip ... I had wondered how LOGGER would handle offload of a huge amount of SMF data right during shutdown. Do you also see this problem if you only shut down one system? Or only when there is no system left that can do the actual offload from the CF? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
And may I enquire why you regularly do sysplex-wide IPLs? We've always done it that way. :-( Somebody should explain to your decision makers that SYSPLEX-wide sort of defeats the purpose of having a SYSPLEX. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
On Thu, 7 May 2009 12:48:22 +, Ted MacNEIL eamacn...@yahoo.ca wrote: And may I enquire why you regularly do sysplex-wide IPLs? We've always done it that way. :-( Somebody should explain to your decision makers that SYSPLEX-wide sort of defeats the purpose of having a SYSPLEX. I would guess that even today the majority of shops have sysplexes for PSLC (price-plex, sham-plex, whatever). Only IBM's largest customers truly exploit it and leverage the 24 x 7 continuous application availability it can provide. I have no real numbers to back this up (I doubt anyone other than IBM does), but I'm going by personal experience from consulting and contacts I have made in this field over the years. Of course, more and more now it's only the larger customers sticking with z/OS on the mainframe, so the percentages have probably changed a little this decade. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
Jim, I have seen the same problem, BUT, only when our coupling facilities are also shutdown as well. If the couplers remain up, you should not experience data loss and logstream corruption. What I see in the log after a Z EOD is issued is IFA705I HALT SMF PROCESS HAS SYNCHRONIZED THE BUFFERED LOGSTREAM RECORDS. This tells me that the SMF buffers are flushed to the logstream where they should live there happily across IPLs unless you shutdown the couplers. In my experience, this happens mostly when ICFs are used and the CECs the ICFs live on are POR'd frequently. We have moved away from ICFs except for our lab and GDPS environments for just this reason (and DB2 datasharing). In both those cases, our SMF output is small enough that we can easily duplex the logstreams and not lose any data. If this is an option for you, try duplexing. When it happened to us, we lost some DB/2 SMF data and OPERLOG. This was significant for us because it was during this failure that we discovered that IBM now stops SYSLOG at two points. When either Z EOD is issued or when JES2 is stopped. Thus I had no log data neither from SYSLOG nor OPERLOG. I pointed out this inconsistency to IBM and I was also directed to pursue a Marketing Request via our local IBM support. I'm told that the Marketing Request approach causes IBM to poll it's user community and see how many accounts are affected. Then they can use that data make a decision whether or not to fix the problem. Jim Holloway - MetLife -- Date:Wed, 6 May 2009 06:59:00 -0500 From:Jim Marshall jim.marsh...@opm.gov Subject: SMF LOGGER - Not Ready for Prime Time If anyone is in the throws of putting the SMF LOGGER into production, I would seriously hold up and wait a while. We have been up on it for about three months and have gone through one problem, hurdle, consequence, challenge, etc, after another. Today the issue is with when you shutdown a system or worse if you need to bring down the entire sysplex. Z EOD does not interface to the SMF LOGGER and the operators usually blow the systems away when they receive the message which says EOD is done. The significance is the logger is still doing its thing and now break it; causing all kinds of grief later. IBM has a temporary fix where you issue a set of commands per LPAR before the Halt EOD but so far they have not worked. Besides so far, the commands do not tell you when the logger is completed doing its think. Although when the set of commands do work, hopefully it will tell an operator something of its completion. Remember, the intent of this is for your operators to visit every LPAR shutting down and wait for each. This will bring new meaning tothe idea of a fast sysplex wide IPL. Everyone including IBM agrees Z EOD needs to be tap everyone on the shoulder to have its logger to do what it should do and then tell HALT, it is now done; thus giving the message which is now real. So to do this, we are submitting as Marketing Request to IBM to get all the players to talk to each other to sort through this situation (not to be confused with a problem). Things are working as intended except no one thought this all the way through and the cardinal word is intended. Will keep you posted as things unravel. jim (WashDC) The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
We've always done it that way. :-( I feel with you! :-) BUFSIZMAX is set to 512MB on both machines this occurs. We cannot go higher, as this is already 10% of the available real storage, and there are at least 2 DBs with their own buffers set high running on each of those lpars. I would guess that even today the majority of shops have sysplexes for PSLC (price-plex, sham-plex, whatever). so true! The contortions software costs cause We do sysplex-wide IPLs twice a year (on fresh CDSs) as part of our DR testing. I was just wondering how frequent 'frequent' is that it became a real issue for the OP. Best regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
IFA705I HALT SMF PROCESS HAS SYNCHRONIZED THE BUFFERED LOGSTREAM RECORDS. I really like the suggestion in the books for this message sarcasm off, which implies to use automation on a 'NOT synchronized' message, even after a z eod. Strangely, z eod is only issued in this installation after *all* address spaces are gone (well, those visible on a d a,l). So no automation. I realize that this message is also issued for switch smf commands. that we discovered that IBM now stops SYSLOG at two points. When either Z EOD is issued or when JES2 is stopped. ??? Why 'now'? It has always been this way, as far as I know. And it makes sense, as the syslog write task in master doesn't have a recipient anymore once JES is stopped. I have *never* seen any z eod command in any syslog I looked at. They all stop after the $Pjes2. And I really hated the problem that said 'JES did not come down via automation, please check'. This was my excuse for having an operlog even on the monoplexes, the only way to see messages issued after jes was down. I'm told that the Marketing Request approach causes IBM to poll it's user community and see how many accounts are affected. Yeah, and if it's not enough customers, that's enough of an excuse for sloppy development and a product broken as designed. (This is a general statement, not directed specifically against SMF using Logger.) You will have to live with the consequences or not use the function and go through some more contortions! Regards, Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF LOGGER - Not Ready for Prime Time
Jim Marshall wrote: If anyone is in the throws of putting the SMF LOGGER into production, I would seriously hold up and wait a while. We have been up on it for about three months and have gone through one problem, hurdle, consequence, challenge, etc, after another. [ ... snipped ... ] Some questions: Are you losing SMF records? One LPAR or all LPARS in SYSPLEX? Are the VSAM staging datasets in use damaged? Or do you have sequence problems or having orphaned sequences? Or are you sitting with half-written SMF records? Say for example, SMF record type 30 with only some subtypes recorded? Are you duplexing your log data? On what z/OS version are you? What is the temporary fix? (APAR, PTF?) Can you switch to MANx just before 'Z EOD' and then after IPL, switch back? Is that approach practical or not? On the other side, isn't it just IEC161I 056-084 or IEC161I 062-086 in other clothes? You get this always at IPL, which is expected because the MANx datasets aren't properly closed during 'Z EOD' Anyway, thanks for this 'just in time' heads-up! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF Logger
On Fri, 31 Oct 2008 11:09:19 -0400, Richards, Robert B. [EMAIL PROTECTED] wrote: We are getting ready to turn on SMF logstream processing. I took a quick look at the archives and haven't seen any new entries for the last six months. Does anyone know the current status of the date card issue as it relates to record extraction? We are z/OS 1.9 going to z/OS 1.10 in early 2009, if that matters. TIA, Bob - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Here are some related links, both the IBM white paper and also info about CA's solution, CA SMF Director, which can address the challenges on duplicate data dumping and data-extraction from the SMF logstream(s). Scott Barry SBBWorks, Inc. IBM white paper: http://ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101130 Cheryl Watson's SHARE prez, mentioning SMF Logger (foil 21): http://www.watsonwalker.com/PR080229.pdf CA Advisor Series, discussion on SMF Logger Challenges - Streaming Without Screaming: CA SMF Director and the System Logger: http://www.ca.com/us/products/collateral.aspx?cid=178381 CA SMF Director product info: http://ca.com/files/ProductBriefs/smf_director_product_brief_us.pdf -- 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
Re: SMF Logger
I asked the same question at the Expo. It's currently not part of the process. You have to do it manually. A lot of people have raised the same concern, so it most likely will become part of it at some point. There are two white papers, if you don't already have them: WP101130 WP101271 Dean -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barry Sent: Friday, October 31, 2008 12:08 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SMF Logger On Fri, 31 Oct 2008 11:09:19 -0400, Richards, Robert B. [EMAIL PROTECTED] wrote: We are getting ready to turn on SMF logstream processing. I took a quick look at the archives and haven't seen any new entries for the last six months. Does anyone know the current status of the date card issue as it relates to record extraction? We are z/OS 1.9 going to z/OS 1.10 in early 2009, if that matters. TIA, Bob - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Here are some related links, both the IBM white paper and also info about CA's solution, CA SMF Director, which can address the challenges on duplicate data dumping and data-extraction from the SMF logstream(s). Scott Barry SBBWorks, Inc. IBM white paper: http://ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101130 Cheryl Watson's SHARE prez, mentioning SMF Logger (foil 21): http://www.watsonwalker.com/PR080229.pdf CA Advisor Series, discussion on SMF Logger Challenges - Streaming Without Screaming: CA SMF Director and the System Logger: http://www.ca.com/us/products/collateral.aspx?cid=178381 CA SMF Director product info: http://ca.com/files/ProductBriefs/smf_director_product_brief_us.pdf -- 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 -- 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
Re: SMF Logger
Scott (and Dean), Thank you for the references. Is anyone using IFASEXIT with the SUBSYS keyword on an IEBGENER as a substitute for the date card issue? Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barry Sent: Friday, October 31, 2008 12:08 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SMF Logger On Fri, 31 Oct 2008 11:09:19 -0400, Richards, Robert B. [EMAIL PROTECTED] wrote: We are getting ready to turn on SMF logstream processing. I took a quick look at the archives and haven't seen any new entries for the last six months. Does anyone know the current status of the date card issue as it relates to record extraction? We are z/OS 1.9 going to z/OS 1.10 in early 2009, if that matters. Here are some related links, both the IBM white paper and also info about CA's solution, CA SMF Director, which can address the challenges on duplicate data dumping and data-extraction from the SMF logstream(s). Scott Barry SBBWorks, Inc. IBM white paper: http://ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101130 Cheryl Watson's SHARE prez, mentioning SMF Logger (foil 21): http://www.watsonwalker.com/PR080229.pdf CA Advisor Series, discussion on SMF Logger Challenges - Streaming Without Screaming: CA SMF Director and the System Logger: http://www.ca.com/us/products/collateral.aspx?cid=178381 CA SMF Director product info: http://ca.com/files/ProductBriefs/smf_director_product_brief_us.pdf -- 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
