Re: Any way to duplex SMF data?
In [EMAIL PROTECTED], on 10/19/2007 at 03:08 PM, Birger Heede [EMAIL PROTECTED] said: SLR was non-DB2 (even announced as such in V3 R3.1 - the last release I think). Only if you count a name change as a new product. Long before Tivoli there was a new product with the same code base. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Any way to duplex SMF data?
In [EMAIL PROTECTED], on 10/18/2007 at 10:58 AM, Martin Packer [EMAIL PROTECTED] said: SLR is based on VSAM databases - which is why I stick with it for my mode of usage. I vaguely recall that they added DB2 support to it, but I'm not sure whether that was before the first (4 letter) name change. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Any way to duplex SMF data?
Shmuel, SLR was non-DB2 (even announced as such in V3 R3.1 - the last release I think). The product marketing by IBM that supported DB2 was: SystemView Enterprise Performance Data Manager/MVS (EPDM, 5695-101) that was renamed into IBM Performance Reporter again renamed into the Tivoli Performance Reporter - that again.. Birger Heede IBM Denmark Shmuel Metz , Seymour J. wrote: In [EMAIL PROTECTED], on 10/18/2007 at 10:58 AM, Martin Packer [EMAIL PROTECTED] said: SLR is based on VSAM databases - which is why I stick with it for my mode of usage. I vaguely recall that they added DB2 support to it, but I'm not sure whether that was before the first (4 letter) name change. -- 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: Any way to duplex SMF data?
Seymour wrote: The closest I've seen was SLR, whatever they're calling it these days. They're calling it unsupported for 10 years :-) though I still run it and rely on it for my day job (and am enhancing our record mappings and reporting even as we type). :-) Cheers, Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: Any way to duplex SMF data?
SLR moved thru Tivoli Performance Reporter that again migrated into: 5698-A07 Tivoli Decision Support for z/OS Birger Heede IBM Denmark Martin Packer wrote: Seymour wrote: The closest I've seen was SLR, whatever they're calling it these days. They're calling it unsupported for 10 years :-) though I still run it and rely on it for my day job (and am enhancing our record mappings and reporting even as we type). :-) Cheers, Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: Any way to duplex SMF data?
Yes BUT note there is no REAL resemblance between the 2 products... SLR is based on VSAM databases - which is why I stick with it for my mode of usage. TDS is based on DB2 databases - which wouldn't suit my case but WOULD be good for a regular installation. If you wonder why MY usage drives me to VSAM-based it's because I get a tranche of data in from a customer, do my thing with it, and then let it go off to ML2. Rather more complex to do with DB2. Cheers, Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: Any way to duplex SMF data?
On Thu, 18 Oct 2007 09:02:00 +0100, Martin Packer [EMAIL PROTECTED] wrote: Seymour wrote: The closest I've seen was SLR, whatever they're calling it these days. They're calling it unsupported for 10 years :-) though I still run it and rely on it for my day job (and am enhancing our record mappings and reporting even as we type). :-) Isn't Tivoli Decision Support the new name for what used to be SLR? http://www-306.ibm.com/software/tivoli/products/tds-390/ Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any way to duplex SMF data?
Mark Zelden wrote... Isn't Tivoli Decision Support the new name for what used to be SLR? No, it's a replacement product, with zero code base in common. Cheers,. Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: Any way to duplex SMF data?
In [EMAIL PROTECTED], on 10/10/2007 at 05:11 PM, Ed Finnell [EMAIL PROTECTED] said: BUILDPDB? Shirley you jest. Or, at least, the last time I looked there was nothing there to manage SMF dumps, just to convert SMF data to SAS. The closest I've seen was SLR, whatever they're calling it these days. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Any way to duplex SMF data?
Shirley you jest Can't you be nice to anybody? Honey? Flies? Vinegar? - Too busy driving to stop for gas! -- 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: Any way to duplex SMF data?
On Fri, 12 Oct 2007 09:19:52 -0500, Ed Gould [EMAIL PROTECTED] wrote: OK, I was looking at it from the SMF side. If you want to do other things with it then that is a different creature. I suppose you could route transactions with it as well but it would have to be written to DASD first and then read again then processed then written to DASD then read. It would seem to me a CTC (or similar facility) would be faster, no? Ed 'scuse me? System Logger is a write and READ mechanism. An application could use the logger browse interface to read records directly from the stream, regardless of the current location (CF structure, offload dataset). This is precisely how IFASMFDL manages to build an IFASMFDP 'looking' output dataset. There are also subsystem mechanisms that can make a logstream appear to be a regular old dataset... Scott Fagen Enterprise Systems Management (and no longer a contact for the previously mentioned Share presentation: http://shareew.prod.web.sba.com/client_files/callpapers/attach/SHARE_in_San _Diego/S2853SJ125141.pdf - Appendix I, page 36) -- 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: Any way to duplex SMF data?
On Oct 16, 2007, at 12:22 PM, Scott Fagen wrote: On Fri, 12 Oct 2007 09:19:52 -0500, Ed Gould [EMAIL PROTECTED] wrote: OK, I was looking at it from the SMF side. If you want to do other things with it then that is a different creature. I suppose you could route transactions with it as well but it would have to be written to DASD first and then read again then processed then written to DASD then read. It would seem to me a CTC (or similar facility) would be faster, no? Ed 'scuse me? System Logger is a write and READ mechanism. An application could use the logger browse interface to read records directly from the stream, regardless of the current location (CF structure, offload dataset). This is precisely how IFASMFDL manages to build an IFASMFDP 'looking' output dataset. There are also subsystem mechanisms that can make a logstream appear to be a regular old dataset... Scott, I guess I was not clear in my entry. I was talking across systems being able to read the smf file. My understanding (it may be mistaken) is that the smf data is written to the logstream on system a and read from the logstream on system B. If my understanding is incorrect I am sorry. Ed -- 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: Any way to duplex SMF data?
On Tue, 16 Oct 2007 13:22:08 -0500, Ed Gould [EMAIL PROTECTED] wrote: I guess I was not clear in my entry. I was talking across systems being able to read the smf file. My understanding (it may be mistaken) is that the smf data is written to the logstream on system a and read from the logstream on system B. If my understanding is incorrect I am sorry. Ed Ah, ok, no apology necessary. What you are talking about would work just fine in a parallel sysplex environment with CF logstreams, but not for DASD- only logstreams or single system environments*. The logger inventory, CF structures and offload datasets are available to all systems within that sysplex, so any arbitrary system could be consuming the SMF data produced by any other. There may be applicability for writing certain record types from ALL systems in the sysplex into a single logstream some kind of near real time analysis of system activities by an application consuming the aggregated stream. Scott Fagen Enterprise Systems Management * - I suppose one could use disk mirroring and some sort of magic logstream decoder ring to unwind a DASD-only stream that didn't originate on the system of execution, but I'll presume that's an academic exercise left to only the most sleepless of programmers. -- 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: Any way to duplex SMF data?
On Fri, 12 Oct 2007 15:41:24 -0500, Ed Gould [EMAIL PROTECTED] wrote: While a overhaul is needed in some areas SMF processing of writing to its own data sets has never been a major issue (that I have seen). that you have seen - exactly. There have been one or two instances in the past where a program loop would cause SMF processing to be delayed in writing of the data, I have never heard of it as a hot issue (I don't recall of a GUIDE/ SHARE requirement). I would think basic changes in the catalog structure and or the ability to create tape files of more 255 volumes would be of higher priority. Why would that be a priority, when a single volume can hold hundreds of gigabytes now and a change would introduce so much backward incompatibility. I know there is still a small shakeout of issues with the console rewrite but overall no big buyback (I have seen). Again as you have seen. I guess you've never had a system or sysplex outage due to the old limitations / design. I am sure there are other hotspots that could be addressed that everybody would see an immediate benefit. While the improved SMF processing is nice (don't get me wrong) I am just wondering if its that big of a payback. Speaking of revamping SMF records could be user of bigger buyback than faster writing, IMHO. This new facility is nice (don't get me wrong) and its reasonably internal code only and probably won't make any difference to the users I just think there could have been something given to help the sell Z/os a little more to the pointy headed types. As I'm sure even you know... some things IBM does for the platform are done for a some very large clients that represent a very small percentage of the client base. But since those clients pay big bucks and outages no doubt cost them more than smaller shops, changes like the console restructure and the new SMF processing have to be done. IBM doesn't spend the few precious z/OS development resources and time they have on big projects just because someone thinks it would be a nice thing to do. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any way to duplex SMF data?
On Oct 15, 2007, at 9:30 AM, Mark Zelden wrote: On Fri, 12 Oct 2007 15:41:24 -0500, Ed Gould [EMAIL PROTECTED] wrote: While a overhaul is needed in some areas SMF processing of writing to its own data sets has never been a major issue (that I have seen). that you have seen - exactly. I don't recall it being asked for in a SHARE/GUIDE requirement. I think if others had experienced it they would have asked. There have been one or two instances in the past where a program loop would cause SMF processing to be delayed in writing of the data, I have never heard of it as a hot issue (I don't recall of a GUIDE/ SHARE requirement). I would think basic changes in the catalog structure and or the ability to create tape files of more 255 volumes would be of higher priority. Why would that be a priority, when a single volume can hold hundreds of gigabytes now and a change would introduce so much backward incompatibility. Not necessarily IBM has moved bits around and found new uses for current mapping to introduce changes and essentially has made big changes pretty much transparent. I am suggesting that the stuff frozen in time needs to be thawed (a little). I know there is still a small shakeout of issues with the console rewrite but overall no big buyback (I have seen). Again as you have seen. I guess you've never had a system or sysplex outage due to the old limitations / design. I have seen console task bring down a system (a few times) but I am talking here about the new console redesign. There was a rumor floating around a few months ago that IBM was floating the idea of making a PC work as a console. Whether it will ever happen is mute in this discussion as I was talking about spending $$ for something that (while needing revamping) was of no immediate gee wiz now I can do X so I can save . something the pointy heads can understand and see/ get relief. I am sure there are other hotspots that could be addressed that everybody would see an immediate benefit. While the improved SMF processing is nice (don't get me wrong) I am just wondering if its that big of a payback. Speaking of revamping SMF records could be user of bigger buyback than faster writing, IMHO. This new facility is nice (don't get me wrong) and its reasonably internal code only and probably won't make any difference to the users I just think there could have been something given to help the sell Z/os a little more to the pointy headed types. As I'm sure even you know... some things IBM does for the platform are done for a some very large clients that represent a very small percentage of the client base. But since those clients pay big bucks and outages no doubt cost them more than smaller shops, changes like the console restructure and the new SMF processing have to be done. IBM doesn't spend the few precious z/OS development resources and time they have on big projects just because someone thinks it would be a nice thing to do. I am sure they don't either. Its nice they are attempting to modernize z/os a little. I am just asking basically from IBM for something to bring to the bosses so everyone can say hey I can save this $$ because of z/os can now do without xxx. I like the changes, don't get me wrong, but with the looses to the other platforms IBM has got to come up with real cost savings, IMO. Ed -- 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: Any way to duplex SMF data?
So, Ted - How would you know that things have changed? For a long time now, you've been too busy driving to stop for gas! Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Ted MacNEIL [EMAIL PROTECTED] So, sit in your ivory tower. Things have changed. - Too busy driving to stop for gas! -- 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: Any way to duplex SMF data?
Ed Gould wrote: On Oct 10, 2007, at 8:56 AM, R.S. wrote: Ed Gould wrote: [...] Agreed (if we hearing all of the story). Going to tape does take a fair amount of work to accidentally loose data. As a semi back up use retpd of a week (if you run a weekly merge). Using SMS/HSM gives you duplexing on tape (easily), fast access, retpd. -- Radoslaw Skorupka Lodz, Poland Yes that is an option in a DASD rich environment, but you must be DASD rich, IMO to do it. Of course if they are a smallish shop that might not be true at all. The SMF data *USUALLY* is only referenced infrequently. At a reasonably middle of the road place I worked for two systems created 15 reels of tape in a month. IIRC this was a cartridge and blocked 32K. IIRC a weeks worth was about 4 reels . We had a robot mounting tapes so it didn't particularly hurt any operator, except it tied up the initiator for about 25 minutes spinning through the tapes. We were DASD poor and anything that stayed on DASD for more than a day had to be signed off on (if it was larger than a cylinder), so TAPE was really the only answer for *US*. Reels ??? I saw reels in museum g Yes, I have a lot of DASD, including old boxes, some of them purchased in second hand for peanuts. DASD is cheap nowadays. My SMF data are referenced frequently, so keeping it on DASD is quite convenient for me. Last, but not least, it is irrelevant for SMS/HSM solution. You can migrate SMF archives on daily basis, hourly basis or directly after it is offloaded. BTW: I don't like to rely on tape drive availability. Almost all shops I know are tape drive constrained. Tape drives are expensive. When a drive is unavailable for a few hours it can be dangerous for production processes. HSM migration is asynchronous process. Much more safe from this point of view. Just my $0.02 Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: Any way to duplex SMF data?
On Oct 13, 2007, at 5:46 PM, R.S. wrote: SNIP-- Reels ??? I saw reels in museum g Yes, I have a lot of DASD, including old boxes, some of them purchased in second hand for peanuts. DASD is cheap nowadays. My SMF data are referenced frequently, so keeping it on DASD is quite convenient for me. Last, but not least, it is irrelevant for SMS/HSM solution. You can migrate SMF archives on daily basis, hourly basis or directly after it is offloaded. BTW: I don't like to rely on tape drive availability. Almost all shops I know are tape drive constrained. Tape drives are expensive. When a drive is unavailable for a few hours it can be dangerous for production processes. HSM migration is asynchronous process. Much more safe from this point of view. Just my $0.02 Not every shop is as lucky as your shop. Even now days more than a few US shops do not have electronic DASD. Even if they do there is a consideration amount remote duplexing (copy) that may come into play . Yes I recognize that SMF being online is semi reasonable thing to do would I trade my next raise on it? NOPE its not that important, IMO. Nice? you betcha. But if there is a difference between a raise and not being online I would opt for TAPE any day. Duplexing SMF (live or dumped) is a interesting issue that only your management can answer. I am not familiar with SOX and its implications to SMF, someone on here (IIRC thought there was) . I don't know if other countries have other rules (laws(?) ) that govern SMF keeping, that is why management has to make the decision. Ed -- 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: Any way to duplex SMF data?
On Fri, 12 Oct 2007 09:19:52 -0500, Ed Gould [EMAIL PROTECTED] wrote: On Oct 12, 2007, at 8:53 AM, Mark Zelden wrote: On Thu, 11 Oct 2007 15:43:19 -0500, Ed Gould [EMAIL PROTECTED] wrote: About the only reason I can come up with (pipe up if you have some more ideas) is if you don't have a tape drive on that system and you are short on DASD space. Probably the #1 reason it was developed: Speed, speed, speed. OK, I was looking at it from the SMF side. If you want to do other things with it then that is a different creature. I suppose you could route transactions with it as well but it would have to be written to DASD first and then read again then processed then written to DASD then read. It would seem to me a CTC (or similar facility) would be faster, no? The SPEED I was referring to was the speed of getting SMF data written out of applications to SMF and out of SMF to be offloaded. Not the transfer speed of dumping / copying a data set (like MANx today) to DASD or tape. Even with the speed of modern DASD, tape and channels, some of IBMs largest customers just can't keep up or have trouble doing so. Like many legacy components of the OS, an overhaul was needed. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any way to duplex SMF data?
Tom, After all the great ideas, what is your solution to the problem with losing the SMF data with your client? I really liked the Raid 1 solution for the packs that actually collect the SMF data, but I imagine that if a batch job screwed up and deleted the original MANx datasets before the data was saved elsewhere, it would do so on both the primary and the secondary volumes. I know when I was at PH Mining, I occasionally had problems. I think when SAP R2 started writing SMF records, the volume of the records more than doubled. I used to keep everything together in one file, but after a while of having problems, I wrote all the CICS records to 1 set of daily, weekly, and monthly files, and then wrote everything else to another set. We lost SMF data once or twice, but we used it for so few things back then it didn't really matter. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 -- 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: Any way to duplex SMF data?
I'd agree with THAT flavour of the speed point - though I've yet to see actual benchmark data. (I have faith the numbers will look good.) On top of that IFASMFDL has additional usability (compared to IFASMFDP) - and MXG-L veterans (and victims of my presentations on the matter) know that I think the dumping process could have done with extra usability. (Candidly I think, reading the IFASMFDL section in the SMF manual, there are still improvements that can be made - but I'm pursuing my ideas on that in an entirely CONSTRUCTIVE manner.) :-) Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: Any way to duplex SMF data?
On Oct 12, 2007, at 8:53 AM, Mark Zelden wrote: On Thu, 11 Oct 2007 15:43:19 -0500, Ed Gould [EMAIL PROTECTED] wrote: About the only reason I can come up with (pipe up if you have some more ideas) is if you don't have a tape drive on that system and you are short on DASD space. Probably the #1 reason it was developed: Speed, speed, speed. OK, I was looking at it from the SMF side. If you want to do other things with it then that is a different creature. I suppose you could route transactions with it as well but it would have to be written to DASD first and then read again then processed then written to DASD then read. It would seem to me a CTC (or similar facility) would be faster, no? Ed -- 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: Any way to duplex SMF data?
On Thu, 11 Oct 2007 15:43:19 -0500, Ed Gould [EMAIL PROTECTED] wrote: About the only reason I can come up with (pipe up if you have some more ideas) is if you don't have a tape drive on that system and you are short on DASD space. Probably the #1 reason it was developed: Speed, speed, speed. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any way to duplex SMF data?
On Fri, 12 Oct 2007 17:26:04 +0100, Martin Packer [EMAIL PROTECTED] wrote: I'd agree with THAT flavour of the speed point - though I've yet to see actual benchmark data. (I have faith the numbers will look good.) On top of that IFASMFDL has additional usability (compared to IFASMFDP) - and MXG-L veterans (and victims of my presentations on the matter) know that I think the dumping process could have done with extra usability. (Candidly I think, reading the IFASMFDL section in the SMF manual, there are still improvements that can be made - but I'm pursuing my ideas on that in an entirely CONSTRUCTIVE manner.) :-) I assume you are referring to my last post (it helps if you include something from the post you are appending to). Some nice benchmark data from this SHARE presentation http://shareew.prod.web.sba.com/client_files/callpapers/attach/SHARE_in_San_Diego/S2853SJ125141.pdf I won't cut/paste the chart because it doesn't do that easily from the PDF. Basically... CPU numbers are about the same. DASD I/O rate a little lower so that part is a little better than writing to MANx. The big bang for your buck comes in the (potential) parallelism of using multiple logstreams. The best part seems to be that even if you duplicate the same records across multiple logstreams, the CPU usage about the same even though the SMF logging rate is higher. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any way to duplex SMF data?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Friday, October 12, 2007 3:41 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? snip I would think basic changes in the catalog structure and or the ability to create tape files of more 255 volumes would be of higher priority. I know there is still a small shakeout snip Ed I don't foresee IBM doing this. The current idea is to make individual tapes larger, instead of increasing the limit of volumes to be greater than 255. The same applies to DASD. If 59 3390-3s are not enough space, then use 3390-9s or 3390-27s or 3390-54s. z/OS is basically letting the hardware expand rather than making some types of fundamental software changes. That why, IMO, z/OS will NEVER support SCSI DASD (or even FBA) the way that z/Linux does. No, they will have FBA disk emulate ECKD and then the access method will emulate FBA on top of the emulated ECKD (eg: VSAM linear datasets, HFS, PDS/E, etc). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Any way to duplex SMF data?
On Oct 12, 2007, at 10:11 AM, Mark Zelden wrote: On Fri, 12 Oct 2007 09:19:52 -0500, Ed Gould [EMAIL PROTECTED] wrote: On Oct 12, 2007, at 8:53 AM, Mark Zelden wrote: The SPEED I was referring to was the speed of getting SMF data written out of applications to SMF and out of SMF to be offloaded. Not the transfer speed of dumping / copying a data set (like MANx today) to DASD or tape. Even with the speed of modern DASD, tape and channels, some of IBMs largest customers just can't keep up or have trouble doing so. Like many legacy components of the OS, an overhaul was needed. While a overhaul is needed in some areas SMF processing of writing to its own data sets has never been a major issue (that I have seen). There have been one or two instances in the past where a program loop would cause SMF processing to be delayed in writing of the data, I have never heard of it as a hot issue (I don't recall of a GUIDE/ SHARE requirement). I would think basic changes in the catalog structure and or the ability to create tape files of more 255 volumes would be of higher priority. I know there is still a small shakeout of issues with the console rewrite but overall no big buyback (I have seen). I am sure there are other hotspots that could be addressed that everybody would see an immediate benefit. While the improved SMF processing is nice (don't get me wrong) I am just wondering if its that big of a payback. Speaking of revamping SMF records could be user of bigger buyback than faster writing, IMHO. This new facility is nice (don't get me wrong) and its reasonably internal code only and probably won't make any difference to the users I just think there could have been something given to help the sell Z/os a little more to the pointy headed types. Ed Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ 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 [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: Any way to duplex SMF data?
McKown, John wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Friday, October 12, 2007 3:41 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? snip I would think basic changes in the catalog structure and or the ability to create tape files of more 255 volumes would be of higher priority. I know there is still a small shakeout snip Ed I don't foresee IBM doing this. The current idea is to make individual tapes larger, instead of increasing the limit of volumes to be greater than 255. The same applies to DASD. If 59 3390-3s are not enough space, then use 3390-9s or 3390-27s or 3390-54s. z/OS is basically letting the hardware expand rather than making some types of fundamental software changes. That why, IMO, z/OS will NEVER support SCSI DASD (or even FBA) the way that z/Linux does. No, they will have FBA disk emulate ECKD and then the access method will emulate FBA on top of the emulated ECKD (eg: VSAM linear datasets, HFS, PDS/E, etc). Never say never g I believe, IBM will perform revolution in DASD storage. mod-54 reached some limit. Storage needs rapidly grow, reliefs like mod-27 to mod-54, or moving aliases out of 64k set are short-term. Today limit is approx. 3.5 PB (64k mod-54). Only 3.5 PB. What kind of revolution can we expect ? I have no idea. Geometry change (bigger volumes) or FBA support come to mind, but not exhaust possibilities. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: Any way to duplex SMF data?
On Oct 12, 2007, at 3:49 PM, McKown, John wrote: --SNIP- I don't foresee IBM doing this. The current idea is to make individual tapes larger, instead of increasing the limit of volumes to be greater than 255. The same applies to DASD. If 59 3390-3s are not enough space, then use 3390-9s or 3390-27s or 3390-54s. z/OS is basically letting the hardware expand rather than making some types of fundamental software changes. That why, IMO, z/OS will NEVER support SCSI DASD (or even FBA) the way that z/Linux does. No, they will have FBA disk emulate ECKD and then the access method will emulate FBA on top of the emulated ECKD (eg: VSAM linear datasets, HFS, PDS/E, etc). John, The list was not meant to be an all inclusive (or even a subset) it was just items off the top of my memory of items that have been a thorn in peoples side for YEARS. I hear what you say about how IBM is addressing them but to have any restrictions is just plain out and out pre 70's. The FBA concept would entail MANY changes and I agree with you that it is unlikely IBM would ever consider doing it on MVS. My head would be spinning if they managed it. I remember in the 70's-80's timeframe where we had to implement a DB that was rather large for those times and were screwed because of the VSAM restrictions, so we had to do it with a modified BDAM. All in all we would have rather done it in VSAM but because of the restrictions we could not. While I know that a lot of the restriction are somewhat lifted (not entirely) I think the task still couldn't be done. Ed -- 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: Any way to duplex SMF data?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Friday, October 12, 2007 4:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? snip Never say never g I believe, IBM will perform revolution in DASD storage. mod-54 reached some limit. Storage needs rapidly grow, reliefs like mod-27 to mod-54, or moving aliases out of 64k set are short-term. Today limit is approx. 3.5 PB (64k mod-54). Only 3.5 PB. What kind of revolution can we expect ? I have no idea. Geometry change (bigger volumes) or FBA support come to mind, but not exhaust possibilities. -- Radoslaw Skorupka Perhaps. But if IBM does do this, I'll almost bet that the current method of using SSH and CCWs will be replaced with the SIGA (Signal Adapter) and a totally new, closed and undocumented, method of I/O communications (similar to OSAs). This will keep us, the unwashed masses, from being able to write low level code. I somewhat understand IBM's position on keeping people ignorant. It makes it simplier for IBM to change things. But I don't like it. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Any way to duplex SMF data?
Based on these comments, and the fact that you have been (semi-?)retired for the past few years, I think it is likely that you haven't been at many shops with large sysplexes of z9 EC machines with 16+ processors. These installations have been getting beat up due to the delay in SMF processing. They also are the shops to have issues with console flooding as well as running up against the limitations of the original MCS console support. In addition, these customers are the ones that pay HUGE sums of money to IBM, so IBM will listen to their needs. Personally, I have never seen issues with SMF delay at my shops, but I have spent the past 15 years in development shops, where SMF records are a nice to have, not a necessity, but that doesn't mean I can't see why this was needed. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. snip While a overhaul is needed in some areas SMF processing of writing to its own data sets has never been a major issue (that I have seen). There have been one or two instances in the past where a program loop would cause SMF processing to be delayed in writing of the data, I have never heard of it as a hot issue (I don't recall of a GUIDE/ SHARE requirement). snip I know there is still a small shakeout of issues with the console rewrite but overall no big buyback (I have seen). /snip -- 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: Any way to duplex SMF data?
Ed Gould wrote: While a overhaul is needed in some areas SMF processing of writing to its own data sets has never been a major issue (that I have seen). If this wasn't a real problem, Ed, we wouldn't have spent the money to solve it. We have other things to work on, too. Perhaps you have lost touch with this particular issue. There have been one or two instances in the past where a program loop would cause SMF processing to be delayed in writing of the data, I have never heard of it as a hot issue (I don't recall of a GUIDE/SHARE requirement). I'm not sure it was ever a SHARE requirement. The problem is likely too new to ever have been a GUIDE requirement. At some point, you can overrun a recording technology and need to fix or replace it. Up until that point, it works fine. We passed that point with SMF data volumes on large busy systems, and had to do something about it. I would think basic changes in the catalog structure and or the ability to create tape files of more 255 volumes would be of higher priority. What catalog changes are you talking about? So far as support for more than 255 tape volumes per data set goes, the current JB/JX media support 700GB/tape. What data sets larger than 178.5 TB do you believe people need to create? (Just think of the time it would take to create such a file at currently sustainable data rates!) I know there is still a small shakeout of issues with the console rewrite but overall no big buyback (I have seen). Yeah, but watch this space. I am sure there are other hotspots that could be addressed that everybody would see an immediate benefit. While the improved SMF processing is nice (don't get me wrong) I am just wondering if its that big of a payback. Speaking of revamping SMF records could be user of bigger buyback than faster writing, IMHO. If we revamped the SMF record formats we would break an awful lot of vendor-, customer-, and IBM-written code. What value do you foresee that would justify the mayhem we would cause by doing that? This new facility is nice (don't get me wrong) and its reasonably internal code only and probably won't make any difference to the users I just think there could have been something given to help the sell Z/os a little more to the pointy headed types. On the contrary, I think this will make a significant difference to those who need it. To those whose SMF data write rates remain comfortably within the capacity of the ICIP recording technique used for SYS1.MAN data sets, though, I agree it will make little difference in the short term. snip -- John Eells z/OS Technical Marketing IBM Poughkeepsie -- 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: Any way to duplex SMF data?
While a overhaul is needed in some areas SMF processing of writing to its own data sets has never been a major issue (that I have seen). You have been retired. You do not see what has happened with large systems these days. SMF recording (especially CICS DB2) is a major bottleneck. I have worked with systems where the offload takes just as long (if not longer) than the recording. So, sit in your ivory tower. Things have changed. - Too busy driving to stop for gas! -- 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: Any way to duplex SMF data?
On Oct 12, 2007, at 4:47 PM, Wayne Driscoll wrote: Based on these comments, and the fact that you have been (semi-?) retired for the past few years, I think it is likely that you haven't been at many shops with large sysplexes of z9 EC machines with 16+ processors. These installations have been getting beat up due to the delay in SMF processing. They also are the shops to have issues with console flooding as well as running up against the limitations of the original MCS console support. In addition, these customers are the ones that pay HUGE sums of money to IBM, so IBM will listen to their needs. Personally, I have never seen issues with SMF delay at my shops, but I have spent the past 15 years in development shops, where SMF records are a nice to have, not a necessity, but that doesn't mean I can't see why this was needed. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. SNIP Wayne, When I retired I still keep contact with friends in the field from small to large installations and yes we go out drinking together and I do hear some war stories about various vendors and yes some good things about vendors as well (although a small number). Again I just picked a few items that seem to be hotspots. Again it was not meant to be an all inclusive list, just a random list, I am sure there are other big hitters that I did not mention. I think that if we did a poll here of things that IBM could do to make z/OS better we would get a differing opinion. The SMF addition to the logger was nice (again don't get me wrong). When I am out with friends we talk shop and I hear a lot of issues about many things and I am sure that the companies I hear from have different priorities (or issues) about different items. It might be interesting to (probably as a SHARE mini project) get a top 20(?) list of hot spots by installation size. IBM I would think would be extremely interested in such a list to prioritize IBM projects. Ed -- 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: Any way to duplex SMF data?
On Wed, 10 Oct 2007 23:19:57 -0500, Scott Fagen wrote: You don't even have to go that far with SMF writing to System Logger. One can define logstreams to be duplexed in a number of ways, even using duplexed CF structures or a CF structure and staging datasets. If the offload is to datasets that are mirrored (either synch or asynch) it would seem like you have your belt and suspenders... Not if you have a monthly process that erroneously deletes the offload data sets without producing a good monthly tape. That was the OP's problem. -- Tom Marchant -- 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: Any way to duplex SMF data?
Thanks, Tom. I was unaware of SMFUTIL. It looks very suitable for what I described. Hope they offer it inexpensively. :-) Bob Richards -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kelman, Tom Sent: Thursday, October 11, 2007 9:00 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? I am not sure there is a competitor to SMF Director on the market. snippage by OP I don't have a vested interest in this either, and I'm not familiar with SMF Director. However, considering what's being discussed what about SMFUTIL by ASPG? I just went to the ASPG web site and it appears that is still around. Tom Kelman LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- 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: Any way to duplex SMF data?
How about just using IFASMFDP to write two output files when dumping? //SYSIN DD * INDD(INDD1,OPTIONS(ALL)) OUTDD(OUTDD1,TYPE(0:255)) OUTDD(OUTDD2,TYPE(0:255)) HTH Dana -- 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: Any way to duplex SMF data?
Sent: Wednesday, October 10, 2007 2:03 PM by Bob Richards Reg, I am not sure there is a competitor to SMF Director on the market. And I know you have no vested interest in enlightening me on that front! grin Thanks for forwarding my comments to the product manager. As for taking the conversation off list, I agree if it is CA product-specific but disagree if anyone wants to discuss the relative merits of one SMF handling process over another. Tom C.'s losing SMF data was process-driven. Tom K. provided a workable solution. Has anyone else developed a RYO process that indexes the record types, date/time they were dumped, where/what media they were written on and provided simple EXTRACT statements to retrieve them? Oh, and is willing to offer it cheaply? smile Bob Richards VP, Enterprise Technologist I don't have a vested interest in this either, and I'm not familiar with SMF Director. However, considering what's being discussed what about SMFUTIL by ASPG? I just went to the ASPG web site and it appears that is still around. Tom Kelman * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: Any way to duplex SMF data?
On Wed, 10 Oct 2007 08:08:02 -0400, Pinnacle [EMAIL PROTECTED] wrote: Due to a fairly bizarre series of circumstances, my client has lost SMF data twice in the last 4 months. I'm being asked if SMF data can be duplexed. I've never heard of it, but has anyone else? They're looking for real-time duplexing if possible. Greetings Tom, With the current focus on SMF as the z/OS audit trail for all of the regulatory initiatives, your client has a valid concern. Has there been a complete examination of the entire SMF processing? A quicker and less costly alternative to duplexing is to modify the existing SMF processing so that it is iron clad. I would think that correcting the existing SMF processing is needed regardless of what long term solution is chosen. After the existing SMF processing is corrected, I guess you can identify all of the possible ways to duplex the data, laying out their associated costs and probability of data loss. To be fair, I would think most forms of duplexing will also have some risk of data loss because of fairly bizarre series of circumstances. These could include hardware failure, software failure, implementation design flaws, human error (sysprog deletes the data, operator drops a tape, tape gets lost, tape management scratches tape early, etc...). Cheers... Michael -- 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: Any way to duplex SMF data?
On Thu, 11 Oct 2007 07:02:20 -0500, Tom Marchant [EMAIL PROTECTED] wrote: On Wed, 10 Oct 2007 23:19:57 -0500, Scott Fagen wrote: You don't even have to go that far with SMF writing to System Logger. One can define logstreams to be duplexed in a number of ways, even using duplexed CF structures or a CF structure and staging datasets. If the offload is to datasets that are mirrored (either synch or asynch) it would seem like you have your belt and suspenders... Not if you have a monthly process that erroneously deletes the offload data sets without producing a good monthly tape. That was the OP's problem. Which offload datasets? The ones from system logger or the ones written by IFASMFDL? Tom Conley wrote: The problem was with the DASD offload files. Problems with the merge jobs caused them to be deleted before they could be merged into the monthly tape. This says to me that using System Logger would solve the issue If they lose the data pulled from the logstream via IFASMFDL, they can always go back to the logstream and pull it again. Unlike using MAN datasets, the logstream doesn't get emptied with each offload of SMF data (unless, of course, the installation chooses to). Scott Fagen Enterprise Systems Management -- 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: Any way to duplex SMF data?
On Thu, 11 Oct 2007 12:57:33 -0500, Scott Fagen [EMAIL PROTECTED] wrote: This says to me that using System Logger would solve the issue If they lose the data pulled from the logstream via IFASMFDL, they can always go back to the logstream and pull it again. Unlike using MAN datasets, the logstream doesn't get emptied with each offload of SMF data (unless, of course, the installation chooses to). I envision many shops deleting it on offload on a daily basis - at least initially. If not thing else, it might make the transition from their current procedures easier. That is the way we currently handle LOGREC and OPERLOG (other than some test / sandbox sysplexes where it controlled only by RETPD). The question of how much to keep in the logstream is more of an issue for SMF data because of the sheer volume. I suppose we could put aside enough DASD space to keep 2 or 3 days and select the current day minus one (once you can select by relative day). That would give us a day or two fix some mistake in processing. But considering how many times a day (an hour?) we dump MANx data sets on all our LPARs, that sounds like an awful lot of DASD... even with DASD being cheap. But then again, you can split out the logstreams by record type and just keep several days of type 70s for example. But we never lose SMF data now, so I don't think that would be the primary reason for keeping multiple days in a logstream. The reason would probably be for multiple processes to access the data and not be single threaded like they are accessing SMF data on tape - which is also not done often here since most of what everyone needs is stored in a SAS / MXG database and it gets the first crack at the data. BTW... we have a mixture of first dump processing. Some systems go to DASD, then copy to virtual tape. Some get dumped directly to virtual tape. Even prior to BUFSIZMAX(_) in SMFPRMxx I can't recall a time losing SMF data. But that parm probably did save us from losing some on one LPAR about a year ago when some looping MQ/CICS thingy starting writing SMF data faster than we could dump it ... or close to it. I was manually moving SMFDUMP STCs from its STCHI service class to SYSSTC and once I figured out which CICS region was involved, I moved its service class to discretionary (this was all on a development LPAR) which allowed it to keep running until the MQ support person figured out the problem. Ok... I'll stop rambling now. :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any way to duplex SMF data?
Continue rambling! :-) I'm getting some new ideas on ways this new logstream option may be more useful than I originally thought! smile Bob Richards -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Thursday, October 11, 2007 2:53 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? On Thu, 11 Oct 2007 12:57:33 -0500, Scott Fagen [EMAIL PROTECTED] wrote: This says to me that using System Logger would solve the issue. If they lose the data pulled from the logstream via IFASMFDL, they can always go back to the logstream and pull it again. Unlike using MAN datasets, the logstream doesn't get emptied with each offload of SMF data (unless, of course, the installation chooses to). I envision many shops deleting it on offload on a daily basis - at least initially. If not thing else, it might make the transition from their current procedures easier. That is the way we currently handle LOGREC and OPERLOG (other than some test / sandbox sysplexes where it controlled only by RETPD). The question of how much to keep in the logstream is more of an issue for SMF data because of the sheer volume. I suppose we could put aside enough DASD space to keep 2 or 3 days and select the current day minus one (once you can select by relative day). That would give us a day or two fix some mistake in processing. But considering how many times a day (an hour?) we dump MANx data sets on all our LPARs, that sounds like an awful lot of DASD... even with DASD being cheap. But then again, you can split out the logstreams by record type and just keep several days of type 70s for example. But we never lose SMF data now, so I don't think that would be the primary reason for keeping multiple days in a logstream. The reason would probably be for multiple processes to access the data and not be single threaded like they are accessing SMF data on tape - which is also not done often here since most of what everyone needs is stored in a SAS / MXG database and it gets the first crack at the data. some snippage Ok... I'll stop rambling now. :-) Mark LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- 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: Any way to duplex SMF data?
On Oct 11, 2007, at 3:16 PM, Richards.Bob wrote: Continue rambling! :-) I'm getting some new ideas on ways this new logstream option may be more useful than I originally thought! smile Bob Richards Bob, There are perhaps maybe 1 or two small uses for the log stream option for SMF, personally I can't see it of much use at all, not that is bad or anything just doesn't fit in most circumstances, IMO. I don't see why they just don't write the dumped SMF to a shared DASD volume and scrape it off from another system. About the only reason I can come up with (pipe up if you have some more ideas) is if you don't have a tape drive on that system and you are short on DASD space. If the DASD isn't shared (but it would have to be using a logstream wouldn't it?) then maybe but still, IMO a very small percent of the shops out there, no? Just curious. Ed -- 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: Any way to duplex SMF data?
Why not mirror the DASD? At 11:06 AM 10/11/2007, you wrote: On Wed, 10 Oct 2007 08:08:02 -0400, Pinnacle [EMAIL PROTECTED] wrote: Due to a fairly bizarre series of circumstances, my client has lost SMF data twice in the last 4 months. I'm being asked if SMF data can be duplexed. I've never heard of it, but has anyone else? They're looking for real-time duplexing if possible. snip Doug Fuerst Consultant BK Associates Brooklyn, NY (718) 921-2620 (Office) (718) 921-0952 (Fax) (917) 572-7364 (Cell) [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
Re: Any way to duplex SMF data?
Pinnacle wrote: Due to a fairly bizarre series of circumstances, my client has lost SMF data twice in the last 4 months. I'm being asked if SMF data can be duplexed. I've never heard of it, but has anyone else? They're looking for real-time duplexing if possible. RAID1 ? vbg But seriously: what happened ? SYS1.MANx was corrupted/deleted ? SMF archives on tape ? SMF record were lost because SYS1.MANx was ful ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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
Any way to duplex SMF data?
Due to a fairly bizarre series of circumstances, my client has lost SMF data twice in the last 4 months. I'm being asked if SMF data can be duplexed. I've never heard of it, but has anyone else? They're looking for real-time duplexing if possible. Regards, Tom Conley -- 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: Any way to duplex SMF data?
Tom, It depends on how and what. And how much money you want to spend and what kind of hardware you have available. I am currently working with EMC DMX dasd array. We can have replication of a pack going on in the background all day long. That way if we loose the primary volume (source) we can get to the secondary volume (target). Or I think it can also Mirror the data internally for recovery but I am not that strong of an stg admin yet to know how that works. If you have IBM or Hitachi there should be a similar process. Otherwise you could always dump the SMF files more frequently and backup up to multiple tape volumes after it is dumped. Or do DFDSS dumps of the man files hourly. Just some thoughts. Lizette Due to a fairly bizarre series of circumstances, my client has lost SMF data twice in the last 4 months. I'm being asked if SMF data can be duplexed. I've never heard of it, but has anyone else? They're looking for real- time duplexing if possible. -- 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: Any way to duplex SMF data?
On Wed, 10 Oct 2007 08:08:02 -0400 Pinnacle [EMAIL PROTECTED] wrote: :Due to a fairly bizarre series of circumstances, my client has lost SMF data :twice in the last 4 months. I'm being asked if SMF data can be duplexed. :I've never heard of it, but has anyone else? They're looking for real-time :duplexing if possible. Write it somewhere else in U83/84/85? But are they losing the actual SYS1.MANx files, or the tape copies? The latter is easier to duplex. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Any way to duplex SMF data?
- Original Message - From: Binyamin Dissen [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, October 10, 2007 8:21 AM Subject: Re: Any way to duplex SMF data? On Wed, 10 Oct 2007 08:08:02 -0400 Pinnacle wrote: :Due to a fairly bizarre series of circumstances, my client has lost SMF data :twice in the last 4 months. I'm being asked if SMF data can be duplexed. :I've never heard of it, but has anyone else? They're looking for real-time :duplexing if possible. Write it somewhere else in U83/84/85? But are they losing the actual SYS1.MANx files, or the tape copies? The latter is easier to duplex. The problem was with the DASD offload files. Problems with the merge jobs caused them to be deleted before they could be merged into the monthly tape. Regards, Tom Conley -- 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: Any way to duplex SMF data?
On Wed, 10 Oct 2007 08:46:14 -0400 Pinnacle [EMAIL PROTECTED] wrote: :- Original Message - :From: Binyamin Dissen [EMAIL PROTECTED] :Newsgroups: bit.listserv.ibm-main :Sent: Wednesday, October 10, 2007 8:21 AM :Subject: Re: Any way to duplex SMF data? : On Wed, 10 Oct 2007 08:08:02 -0400 Pinnacle wrote: : :Due to a fairly bizarre series of circumstances, my client has lost SMF : data : :twice in the last 4 months. I'm being asked if SMF data can be : duplexed. : :I've never heard of it, but has anyone else? They're looking for : real-time : :duplexing if possible. : Write it somewhere else in U83/84/85? : But are they losing the actual SYS1.MANx files, or the tape copies? The : latter : is easier to duplex. :The problem was with the DASD offload files. Problems with the merge jobs :caused them to be deleted before they could be merged into the monthly tape. That is procedural. Offload them to tape as well. Takes a lot more work to scratch a tape file. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Any way to duplex SMF data?
On Oct 10, 2007, at 8:04 AM, Binyamin Dissen wrote: -- SNIP--- That is procedural. Offload them to tape as well. Takes a lot more work to scratch a tape file. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Agreed (if we hearing all of the story). Going to tape does take a fair amount of work to accidentally loose data. As a semi back up use retpd of a week (if you run a weekly merge). Also, if there is some sloppiness involved create a duplex tape each time and put an appropriate retpd on it. If you are letting production control take care of it consider taking control back. Ed -- 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: Any way to duplex SMF data?
I don't think there is any way to do real time duplexing of the SMF (SYS1.MANx files) as they are written. However, we offload our SMF data hourly during the day, and send the output to two separate output files appending the data to the end of the files. Then we pull the data on a daily basis to a dataset with the date included in the name, and HSM then backs up that file. There are probably holes in this process, and I'm sure the potential is there to lose data, but we have not lost any SMF data in years with this setup. It sounds to me like you are having procedural issues if you are losing data, because with the DASD out there today, it's almost impossible to lose data due to a disk failure. Please send back more details of the actual type of data loss you had. Thanks C. Todd Burrell Senior z/OS Systems Programmer ITSO (404) 498-3299 (404) 723-2017 (cell) Please visit the ITSO Customer Satisfaction Survey and tell us about your recent experiences with ITSO. This survey is for internal CDC use only and the results will be used to improve business services. Anyone working for CDC in any capacity is invited to participate in our survey. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pinnacle Sent: Wednesday, October 10, 2007 8:08 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Any way to duplex SMF data? Due to a fairly bizarre series of circumstances, my client has lost SMF data twice in the last 4 months. I'm being asked if SMF data can be duplexed. I've never heard of it, but has anyone else? They're looking for real-time duplexing if possible. Regards, Tom Conley -- 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: Any way to duplex SMF data?
: On Wed, 10 Oct 2007 08:08:02 -0400 Pinnacle wrote: : :Due to a fairly bizarre series of circumstances, my client has lost SMF : data : :twice in the last 4 months. I'm being asked if SMF data can be : duplexed. : :I've never heard of it, but has anyone else? They're looking for : real-time : :duplexing if possible. : Write it somewhere else in U83/84/85? : But are they losing the actual SYS1.MANx files, or the tape copies? The : latter : is easier to duplex. :The problem was with the DASD offload files. Problems with the merge jobs :caused them to be deleted before they could be merged into the monthly tape. On Wed, 10 Oct 2007 8:21 Binyamin Dissen wrote: That is procedural. Offload them to tape as well. Takes a lot more work to scratch a tape file. -- Binyamin Dissen [EMAIL PROTECTED] Or if you're using IFASMFDP you can just create two copies of the data when you dump it using two output DD statements (SMFOUT1 and SMFOUT2) and the following control cards. INDD(SMFIN,OPTIONS(DUMP)) OUTDD(SMFOUT1,TYPE(0:255)) OUTDD(SMFOUT2,TYPE(0:255)) * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: Any way to duplex SMF data?
Ed Gould wrote: [...] Agreed (if we hearing all of the story). Going to tape does take a fair amount of work to accidentally loose data. As a semi back up use retpd of a week (if you run a weekly merge). Using SMS/HSM gives you duplexing on tape (easily), fast access, retpd. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: Any way to duplex SMF data?
On Wed, 10 Oct 2007 09:36:05 -0500, Kelman, Tom wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant You could always dump your MANx data sets twice, the first with OPTIONS(DUMP) and the second with OPTIONS(ALL). Do them both in the same job to ensure that the MANx data set does not change in between. Tom, why not dump them to two output files in the same step. You can allocate two output DD statements and duplex the data in one process. It would save time over dumping twice. INDD(SMFIN,OPTIONS(ALL)) OUTDD(SMFOUT1,TYPE(0:255)) OUTDD(SMFOUT2,TYPE(0:255)) Duh. Of course. Thanks. -- Tom Marchant -- 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: Any way to duplex SMF data?
On Wed, 10 Oct 2007 08:46:14 -0400, Pinnacle wrote: - Original Message - From: Binyamin Dissen [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, October 10, 2007 8:21 AM Subject: Re: Any way to duplex SMF data? On Wed, 10 Oct 2007 08:08:02 -0400 Pinnacle wrote: Due to a fairly bizarre series of circumstances, my client has lost SMF data twice in the last 4 months. I'm being asked if SMF data can be duplexed. I've never heard of it, but has anyone else? They're looking for real-time duplexing if possible. The problem was with the DASD offload files. Problems with the merge jobs caused them to be deleted before they could be merged into the monthly tape. Bulletproof shoes? Of course, you can mirror your MANx data sets, but when you empty them, the mirrors are emptied too. The same applies to the dumped SMF data. You could always dump your MANx data sets twice, the first with OPTIONS(DUMP) and the second with OPTIONS(ALL). Do them both in the same job to ensure that the MANx data set does not change in between. If your process is to create a new data set every time you dump (e.g. generation data sets) you could then copy that data set to another dats set. In that case, you need to figure out when to delete the copies. You need to fix the way the original dump data sets are kept. They should be kept for a long enough time after they are added to your monthly tapes that you are sure that they were accumulated correctly. -- Tom Marchant -- 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: Any way to duplex SMF data?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant Sent: Wednesday, October 10, 2007 9:23 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? Bulletproof shoes? Of course, you can mirror your MANx data sets, but when you empty them, the mirrors are emptied too. The same applies to the dumped SMF data. You could always dump your MANx data sets twice, the first with OPTIONS(DUMP) and the second with OPTIONS(ALL). Do them both in the same job to ensure that the MANx data set does not change in between. If your process is to create a new data set every time you dump (e.g. generation data sets) you could then copy that data set to another dats set. In that case, you need to figure out when to delete the copies. You need to fix the way the original dump data sets are kept. They should be kept for a long enough time after they are added to your monthly tapes that you are sure that they were accumulated correctly. -- Tom Marchant Tom, why not dump them to two output files in the same step. You can allocate two output DD statements and duplex the data in one process. It would save time over dumping twice. INDD(SMFIN,OPTIONS(ALL)) OUTDD(SMFOUT1,TYPE(0:255)) OUTDD(SMFOUT2,TYPE(0:255)) Tom Kelman * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: Any way to duplex SMF data?
In a message dated 10/10/2007 9:45:50 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Duh. Of course. Thanks. Heck, with SMS can do auto archive/auto backup, compress and stripe??? Still dependant on sentient life forms processing the data. DISP=(MOD,DELETE,DELETE) maybe??? ** See what's new at http://www.aol.com -- 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: Any way to duplex SMF data?
snip Heck, with SMS can do auto archive/auto backup, compress and stripe??? Still dependant on sentient life forms processing the data. DISP=(MOD,DELETE,DELETE) maybe??? /snip That's carbon units to you, Ed G -- 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: Any way to duplex SMF data?
Pinnacle wrote: Due to a fairly bizarre series of circumstances, my client has lost SMF data twice in the last 4 months. I'm being asked if SMF data can be duplexed. I've never heard of it, but has anyone else? They're looking for real-time duplexing if possible. snip On z/OS R9 using SMF's new Logger support, one could send all the records to two log streams, which would effectively duplex it. I'm not at all sure we would recommend such a thing, though. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [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
Re: Any way to duplex SMF data?
In a message dated 10/10/2007 10:07:29 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: That's carbon units to you, Ed G Probably can't tell the old joke about the Foo bird in a public forum, but am sorely tempted. ** See what's new at http://www.aol.com -- 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: Any way to duplex SMF data?
Subject: Any way to duplex SMF data? Um... why? It is mostly useless tourist information. -- 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: Any way to duplex SMF data?
Tom: If this is really critical for you, the first thing you should do is freeze the tapes the data was on even if they were re-used. Contact me offline if you can't find some easy way of getting it back. Bill From: Pinnacle [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? Date: Wed, 10 Oct 2007 08:46:14 -0400 - Original Message - From: Binyamin Dissen [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, October 10, 2007 8:21 AM Subject: Re: Any way to duplex SMF data? On Wed, 10 Oct 2007 08:08:02 -0400 Pinnacle wrote: :Due to a fairly bizarre series of circumstances, my client has lost SMF data :twice in the last 4 months. I'm being asked if SMF data can be duplexed. :I've never heard of it, but has anyone else? They're looking for real-time :duplexing if possible. Write it somewhere else in U83/84/85? But are they losing the actual SYS1.MANx files, or the tape copies? The latter is easier to duplex. The problem was with the DASD offload files. Problems with the merge jobs caused them to be deleted before they could be merged into the monthly tape. Regards, Tom Conley -- 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 _ i'm making a difference. Make every IM count for the cause of your choice. Join Now. http://im.live.com/messenger/im/home/?source=TAGHM -- 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: Any way to duplex SMF data?
I just checked with one of our CA SMF experts, and got the following answer which may be of value: Yes, done at dump time. CA SMF Director Automatic Duplexing and Multiplexing of SMF Records CA SMF Director can automatically create a duplicate copy of a history file during the dump/unload process. In addition to duplexing, CA SMF Director can also be directed to write all or a portion of the SMF records being dumped to other output files. These records can then be processed immediately, without an intervening step to extract them from the history files that were just created. Data management information is also provided for the additional output files, called split files, in the form of an index, called the split file index. The index itself is managed and used by CA SMF Director, but a copy of it can be produced by CA SMF Director for use by other applications, if needed. Reg Harbeck ca Product Management Director for Mainframe Strategy tel: +1-403-605-7986 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pinnacle Sent: Wednesday, October 10, 2007 6:08 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Any way to duplex SMF data? Due to a fairly bizarre series of circumstances, my client has lost SMF data twice in the last 4 months. I'm being asked if SMF data can be duplexed. I've never heard of it, but has anyone else? They're looking for real-time duplexing if possible. Regards, Tom Conley -- 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: Any way to duplex SMF data?
- Original Message - From: Craddock, Chris [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, October 10, 2007 12:29 PM Subject: RE: Any way to duplex SMF data? Subject: Any way to duplex SMF data? Um... why? It is mostly useless tourist information. Ha Ha, that Aussie humor. Ever hear of PCI, SOX, etc? -- 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: Any way to duplex SMF data?
Reg, Great product when it was ManageSMF. Then someone had the bright idea to imbed it with JARS and stop offering it as a separate product. Price rose dramatically, time passes (15+ years or so), someone at CA decides to offer it as a separate product again. Great idea...unfortunately the price has never dropped back down to a reasonable level. The fact is that most shops did not buy into JARS (or IBM's product for that matter - PRS? I forget) and were forced into developing their own SMF dump processes when ManageSMF disappeared. Offer it to me for less than $25,000 OTC for a perpetual Enterprise license with a 15% maintenance fee and maybe, just maybe, I can talk someone into getting it again. Bob Richards -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Harbeck, Reg Sent: Wednesday, October 10, 2007 12:48 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? I just checked with one of our CA SMF experts, and got the following answer which may be of value: Yes, done at dump time. CA SMF Director Automatic Duplexing and Multiplexing of SMF Records CA SMF Director can automatically create a duplicate copy of a history file during the dump/unload process. In addition to duplexing, CA SMF Director can also be directed to write all or a portion of the SMF records being dumped to other output files. These records can then be processed immediately, without an intervening step to extract them from the history files that were just created. Data management information is also provided for the additional output files, called split files, in the form of an index, called the split file index. The index itself is managed and used by CA SMF Director, but a copy of it can be produced by CA SMF Director for use by other applications, if needed. Reg Harbeck ca Product Management Director for Mainframe Strategy tel: +1-403-605-7986 LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- 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: Any way to duplex SMF data?
Bob, thanks for your thoughts on this. I want to be careful not to seem to be advertising software on this list, as distinct from offering suggested solutions, so I'll refrain from discussing prices in this context. However, I've forwarded your thoughts to our product manager for CA SMF Director, and I'd be willing to further this aspect of the conversation offline if you or anyone else would like. It might just come down to the value of lost SMF data. As far as the problem in question, we could look into what did and did not happen to see how it could be handled by CA SMF Director (which is a product that has evolved over time and can fulfill duplexing requirements plus a lot more). Reg Harbeck ca Product Management Director for Mainframe Strategy tel: +1-403-605-7986 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Richards.Bob Sent: Wednesday, October 10, 2007 12:01 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? Reg, Great product when it was ManageSMF. Then someone had the bright idea to imbed it with JARS and stop offering it as a separate product. Price rose dramatically, time passes (15+ years or so), someone at CA decides to offer it as a separate product again. Great idea...unfortunately the price has never dropped back down to a reasonable level. The fact is that most shops did not buy into JARS (or IBM's product for that matter - PRS? I forget) and were forced into developing their own SMF dump processes when ManageSMF disappeared. Offer it to me for less than $25,000 OTC for a perpetual Enterprise license with a 15% maintenance fee and maybe, just maybe, I can talk someone into getting it again. Bob Richards -- 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: Any way to duplex SMF data?
Reg, I am not sure there is a competitor to SMF Director on the market. And I know you have no vested interest in enlightening me on that front! grin Thanks for forwarding my comments to the product manager. As for taking the conversation off list, I agree if it is CA product-specific but disagree if anyone wants to discuss the relative merits of one SMF handling process over another. Tom C.'s losing SMF data was process-driven. Tom K. provided a workable solution. Has anyone else developed a RYO process that indexes the record types, date/time they were dumped, where/what media they were written on and provided simple EXTRACT statements to retrieve them? Oh, and is willing to offer it cheaply? smile Bob Richards VP, Enterprise Technologist - - Enterprise Technology Infrastructure- - Mainframe Services Capacity Performance Mgmt - - Office: 404-575-2798Mobile: 610-246-2943 - - email: [EMAIL PROTECTED] - Seeing Beyond Money (sm) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Harbeck, Reg Sent: Wednesday, October 10, 2007 2:37 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? Bob, thanks for your thoughts on this. I want to be careful not to seem to be advertising software on this list, as distinct from offering suggested solutions, so I'll refrain from discussing prices in this context. However, I've forwarded your thoughts to our product manager for CA SMF Director, and I'd be willing to further this aspect of the conversation offline if you or anyone else would like. It might just come down to the value of lost SMF data. As far as the problem in question, we could look into what did and did not happen to see how it could be handled by CA SMF Director (which is a product that has evolved over time and can fulfill duplexing requirements plus a lot more). Reg Harbeck ca Product Management Director for Mainframe Strategy tel: +1-403-605-7986 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Richards.Bob Sent: Wednesday, October 10, 2007 12:01 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? Reg, Great product when it was ManageSMF. Then someone had the bright idea to imbed it with JARS and stop offering it as a separate product. Price rose dramatically, time passes (15+ years or so), someone at CA decides to offer it as a separate product again. Great idea...unfortunately the price has never dropped back down to a reasonable level. The fact is that most shops did not buy into JARS (or IBM's product for that matter - PRS? I forget) and were forced into developing their own SMF dump processes when ManageSMF disappeared. Offer it to me for less than $25,000 OTC for a perpetual Enterprise license with a 15% maintenance fee and maybe, just maybe, I can talk someone into getting it again. Bob Richards LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- 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: Any way to duplex SMF data?
In a message dated 10/10/2007 12:59:24 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Ever hear of PCI, SOX, etc? HIPPA. The FBI shows up with your files and wants to know who to handcuff for letting them loose. If you can't prove otherwise, they just take the security admin ** See what's new at http://www.aol.com -- 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: Any way to duplex SMF data?
In a message dated 10/10/2007 2:04:00 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Has anyone else developed a RYO process that indexes the record types, date/time they were dumped, where/what media they were written on and provided simple EXTRACT statements to retrieve them? Oh, and is willing to offer it cheaply? smile BUILDPDB? ** See what's new at http://www.aol.com -- 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: Any way to duplex SMF data?
Ed, Care to elaborate? Bob Richards -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Finnell Sent: Wednesday, October 10, 2007 5:11 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Any way to duplex SMF data? In a message dated 10/10/2007 2:04:00 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Has anyone else developed a RYO process that indexes the record types, date/time they were dumped, where/what media they were written on and provided simple EXTRACT statements to retrieve them? Oh, and is willing to offer it cheaply? smile BUILDPDB? LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- 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: Any way to duplex SMF data?
In a message dated 10/10/2007 4:20:25 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Care to elaborate? Not really, MXG been doing this stuff for a long time. ** See what's new at http://www.aol.com -- 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: Any way to duplex SMF data?
On Oct 10, 2007, at 8:56 AM, R.S. wrote: Ed Gould wrote: [...] Agreed (if we hearing all of the story). Going to tape does take a fair amount of work to accidentally loose data. As a semi back up use retpd of a week (if you run a weekly merge). Using SMS/HSM gives you duplexing on tape (easily), fast access, retpd. -- Radoslaw Skorupka Lodz, Poland Yes that is an option in a DASD rich environment, but you must be DASD rich, IMO to do it. Of course if they are a smallish shop that might not be true at all. The SMF data *USUALLY* is only referenced infrequently. At a reasonably middle of the road place I worked for two systems created 15 reels of tape in a month. IIRC this was a cartridge and blocked 32K. IIRC a weeks worth was about 4 reels . We had a robot mounting tapes so it didn't particularly hurt any operator, except it tied up the initiator for about 25 minutes spinning through the tapes. We were DASD poor and anything that stayed on DASD for more than a day had to be signed off on (if it was larger than a cylinder), so TAPE was really the only answer for *US*. Ed -- 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: Any way to duplex SMF data?
On Wed, 10 Oct 2007 10:59:59 -0400, John Eells [EMAIL PROTECTED] wrote: Pinnacle wrote: Due to a fairly bizarre series of circumstances, my client has lost SMF data twice in the last 4 months. I'm being asked if SMF data can be duplexed. I've never heard of it, but has anyone else? They're looking for real-time duplexing if possible. snip On z/OS R9 using SMF's new Logger support, one could send all the records to two log streams, which would effectively duplex it. I'm not at all sure we would recommend such a thing, though. You don't even have to go that far with SMF writing to System Logger. One can define logstreams to be duplexed in a number of ways, even using duplexed CF structures or a CF structure and staging datasets. If the offload is to datasets that are mirrored (either synch or asynch) it would seem like you have your belt and suspenders... Scott Fagen Enterprise Systems Management -- 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
