REXX and Logstreams
I did a quick search and didn't see anything, so I thought i'd ask here. Can a rexx program being executed in Netview write data to a logstream? Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
Long ago (2005) we had one of the largest generators of SMF data on record and continued to use MAN datasets using a couple of techniques to carry the load. Environment: four CECS, all in the same SYSPLEX. four on UK time, ten on US time. Extensive use of CICSPLEX and transaction routine with DB2 data sharing. Techniques: * multiple MAN data sets for each system all in shared user catalogs after system initialization. IPLed on master cataloged MAN files, then switched over to the user cataloged ones late in the start up process.) * dump/clear routines designed so that multiple instances could run on a system at the same time. GDGs were not used to avoid base contention. Dataset names generated by dynamic system variables. * Dump phases were scheduled on small utility LPARS, with clear phases run on the originating image. * offloaded data was SMS tailored compressed (today would use zEDC) getting close to 90% compression/ * Did not use internal compression for CICS or DB2 data to lower processor utilization in those address spaces. (these use CSRCESRV which uses the generic compression algorithms getting 40-50% compression and ran on GP engines). SMS compression also super-blocks (full track read/writes) for better disk utilization. Multi-stripping also used to speed up and overlap phisical I/O to the files. Michael At 02:45 PM 8/2/2022, Radoslaw Skorupka wrote: Content-Transfer-Encoding: 8bit W dniu 02.08.2022 o 19:41, Steve Beaver pisze: Has anyone ever created a LOGSTREAM on an M54 of 65000 cylinders. I have a very, very busy CICS and DB2 on the same LPAR No, never, even close to such huge size. I'm talking about very busy and overloaded CICS region with DB2 on same LPAR (200M trn/day, up to 4000 trn/s). -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
W dniu 02.08.2022 o 19:41, Steve Beaver pisze: Has anyone ever created a LOGSTREAM on an M54 of 65000 cylinders. I have a very, very busy CICS and DB2 on the same LPAR No, never, even close to such huge size. I'm talking about very busy and overloaded CICS region with DB2 on same LPAR (200M trn/day, up to 4000 trn/s). -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
You might consider splitting the data into multiple logstreams. Michael At 12:41 PM 8/2/2022, Steve Beaver wrote: Has anyone ever created a LOGSTREAM on an M54 of 65000 cylinders. I have a very, very busy CICS and DB2 on the same LPAR Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Logstreams
Has anyone ever created a LOGSTREAM on an M54 of 65000 cylinders. I have a very, very busy CICS and DB2 on the same LPAR Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
well. I found anther SMF logstream which is a PLEX wide complete SMF logstream, totaling 22,223 CYLS Carmen = On 7/15/2022 9:12 AM, Steve Beaver wrote: For those using Logstreams. What is your largest Logstream in cylinders? And are you using SMS EF? TIA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
the largest LS we have defined is for SMF, allocated in tracks, but I calculated to 5,098 CYLS Carmen On 7/15/2022 9:12 AM, Steve Beaver wrote: For those using Logstreams. What is your largest Logstream in cylinders? And are you using SMS EF? TIA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Logstreams
For those using Logstreams. What is your largest Logstream in cylinders? And are you using SMS EF? TIA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
Does "56+ kbytes per track" help? What are those numbers? Kilobytes? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Beaver Sent: Friday, June 3, 2022 12:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Logstreams Has anyone figured out how to compute the number of cylinders for STG_SIZE(119880) LS_SIZE(119880) Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Logstreams
Has anyone figured out how to compute the number of cylinders for STG_SIZE(119880) LS_SIZE(119880) Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOGSTREAMS
On Thu, 26 May 2022 10:10:24 -0500, Steve Beaver wrote: >I have a friend whose systems produces BILLIONS of SMF records per month and > >He is basically using the following DEFINE for his DEFAULT LOGSTREAM. > > > >I will tell you simply that I have no IDEA if the NUMBERS for STG_SIZE and >LS_SIZE > >Are crazy or inline. I know those numbers can be revised on the fly > > > > DEFINE LOGSTREAM NAME(IFASMF.&SYSNAME..SMFDFLT) > > DASDONLY(YES) > > STG_SIZE(119880)/* IN 4K BLOCKS */ > > STG_DATACLAS(MVSLOGR) > > LS_DATACLAS(MVSLOGR) > > LS_SIZE(119880) /* IN 4K BLOCKS */ > > HIGHOFFLOAD(85) > > AUTODELETE(YES) > > RETPD(90) > Suggest analyzing SMF type 23 data for SMF recording activity - this information will help determine minimum sizing based on anticipated max SMF LS offloading needed - this information will help contribute to your LOGR attribute sizing interests. And along the way, analyze your SMF 88 activity to monitor LOGR with SMF LS data-handling. Scott Barry SBBTech LLC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
LOGSTREAMS
I have a friend whose systems produces BILLIONS of SMF records per month and He is basically using the following DEFINE for his DEFAULT LOGSTREAM. I will tell you simply that I have no IDEA if the NUMBERS for STG_SIZE and LS_SIZE Are crazy or inline. I know those numbers can be revised on the fly DEFINE LOGSTREAM NAME(IFASMF.&SYSNAME..SMFDFLT) DASDONLY(YES) STG_SIZE(119880)/* IN 4K BLOCKS */ STG_DATACLAS(MVSLOGR) LS_DATACLAS(MVSLOGR) LS_SIZE(119880) /* IN 4K BLOCKS */ HIGHOFFLOAD(85) AUTODELETE(YES) RETPD(90) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: System Logstreams
On Wed, 25 May 2022 15:12:34 -0500, Scott Barry wrote: >For SMF Logstreams, there is no "I SMF" -- instead, only option is IFASMFDL >(batch) invocation to offload any given / named SMF LOGSTREAM. And consider >staggering the individual START command invocations, that is >if you are using zEDC and are not yet at z15, where/when PCIe card use is >eliminated. I SMF still "works" with Logstreams, just differently. It does not "switch" datasets, but it still flushes the in-storage SMF buffers to the logstream staging/offload datasets (which Z EOD also does, among other functions), and then passes control to IEFU29L, if it's active. Art Gutowski Huntington National Bank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: System Logstreams
Food for thought: * when splitting out CICS 110, consider splitting out 110.1.3 (transaction detail) and all other. Depending on how you process the transaction detail, you might also want to separate out the 110.1.1 dictionary records. * Also consider splitting out TYPE74 from the rest of the 7x's * For Db2, the same would apply for TYPE101's * should you have zEDC available, and are retaining ten years of data (hopefully not including data that has a short-lived value like device interval activity), you might consider using IFASMFDl to extract data into zEDC compressed data sets, then allow DFHSM to archive and manage then. Thought ought to reduce your archival storage needs. Michael At 02:46 PM 5/25/2022, Steve Beaver wrote: I have learned more about SYSTEM Logstreams that I ever wanted to know. I have friend that produces BILLIONS of SMF/Logstream records per month, And has RETPD of 120 (ten years' worth). And each STAGE file is migrated Of within 24 hours. I am going to split this mess into DB2(100,101,102), SECURITY(80), CICS(110), RMF(70-79), and BILLING. There are 2 questions I have not been able to figure out. (1) How does logger determine when a LOGGER STAGE file need to be Expired? (2) All if us at 00.01 force at "I SMF" a switch. I have not been able how To force a LOGGER Switch? Does anyone have ANY idea ideas? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: System Logstreams
On Wed, 25 May 2022 14:46:20 -0500, Steve Beaver wrote: >I have learned more about SYSTEM Logstreams that I ever wanted to know. > > > >I have friend that produces BILLIONS of SMF/Logstream records per month, > >And has RETPD of 120 (ten years' worth). And each STAGE file is migrated > >Of within 24 hours. > > > >I am going to split this mess into DB2(100,101,102), SECURITY(80),CICS(110), > >RMF(70-79), and BILLING. > > > >There are 2 questions I have not been able to figure out. > > > >(1) How does logger determine when a LOGGER STAGE file need to be > >Expired? > >(2) All if us at 00.01 force at "I SMF" a switch. I have not been able >how > >To force a LOGGER Switch? > > > >Does anyone have ANY idea ideas? > For SMF Logstreams, there is no "I SMF" -- instead, only option is IFASMFDL (batch) invocation to offload any given / named SMF LOGSTREAM. And consider staggering the individual START command invocations, that is if you are using zEDC and are not yet at z15, where/when PCIe card use is eliminated. And as for "...need to be Expired?" - you can either exploit IFASMFDL ARCHIVE feature or otherwise using RETPD/AUTODELETE function. And my recommendation is to separate DB2 SMF 101 and 102, mostly due to anticipated data-volume. Also, some sites take action to capture/maintain an SCRT SMF LOGSTREAM as well mostly for convenience with using SMS MGMTCLAS retention / management when using DFHSM. Similarly if using MQ, consider splitting MQ 116 from MQ 115, again due to data-volume. Scott Barry SBBTech LLC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
System Logstreams
I have learned more about SYSTEM Logstreams that I ever wanted to know. I have friend that produces BILLIONS of SMF/Logstream records per month, And has RETPD of 120 (ten years' worth). And each STAGE file is migrated Of within 24 hours. I am going to split this mess into DB2(100,101,102), SECURITY(80),CICS(110), RMF(70-79), and BILLING. There are 2 questions I have not been able to figure out. (1) How does logger determine when a LOGGER STAGE file need to be Expired? (2) All if us at 00.01 force at "I SMF" a switch. I have not been able how To force a LOGGER Switch? Does anyone have ANY idea ideas? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Logstreams are a bit befuddling
Logstreams are a bit befuddling Trouble will start below DATA TYPE(LOGR) REPORT(YES) DEFINE LOGSTREAM NAME(IFASMF.&SYSNAME..SYSTEM) DASDONLY(YES) STG_SIZE(50) STG_DATACLAS(MVSLOGR) LS_DATACLAS(MVSLOGR) LS_SIZE(50) HLQ(LOGGER) HIGHOFFLOAD(85) LOWOFFLOAD(0) AUTODELETE(YES) RETPD(2) SMFPRMxx LSNAME(IFASMF.&SYSNAME..SYSTEM,TYPE(0:255)) RECORDING(LOGSTREAM) The BOOK, ??, illustrates STG_SIZE(50), LS_SIZE(50), and RETPD(2). I'm having Storage Pool, that SMS will drive HLQ(LOGGER) to it, I am having the Pool initially populated with three (3) MOD27's I am well aware that I can have the Logstreams to a lot of separations. Now at this point I am totally befuddled as how to proceed other than to Get the counts of SMF records we produce on 10 LPARS, since none of them, Are the same -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Collecting SMF data with Logstreams
Decisions around how long to keep SMF data in the log streams are unique per customer installation. IBM does not make recommendations for that. For your IFASMFDL return code concerns, implementing a post processing job log 'scraper' world be useful to take specific actions based on the messages in the job log that are returned by IFASMFDL. Bonnie Ordonez, IBM, SMF Level 3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Collecting SMF data with Logstreams
Here's a RedBook that might help you set it up. It's a little easier on a z15 (might also be true on a z14 too), since the hardware is incorporated on the processor itself and not as a separate PCIe processor card. It still is a price z/OS feature though. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiMopLk6N_uAhXVK80KHQvvAGoQFjAAegQIAhAC&url=http%3A%2F%2Fwww.redbooks.ibm.com%2Fredbooks%2Fpdfs%2Fsg248259.pdf&usg=AOvVaw1N6FizLuyEIN-uSXF650n9 Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, February 10th, 2021 at 12:10 PM, Horne, Jim wrote: > Thanks for that. And if you have not yet set up zEDC compression, where is a > good place to start? > > Jim Horne > > NOTICE: All information in and attached to the e-mails below may be > proprietary, confidential, privileged and otherwise protected from improper > or erroneous disclosure. If you are not the sender's intended recipient, you > are not authorized to intercept, read, print, retain, copy, forward, or > disseminate this message. If you have erroneously received this > communication, please notify the sender immediately by phone (704-758-1000) > or by e-mail and destroy all copies of this message electronic, paper, or > otherwise. By transmitting documents via this email: Users, Customers, > Suppliers and Vendors collectively acknowledge and agree the transmittal of > information via email is voluntary, is offered as a convenience, and is not a > secured method of communication; Not to transmit any payment information E.G. > credit card, debit card, checking account, wire transfer information, > passwords, or sensitive and personal information E.G. Driver's license, DOB, > social security, or any other information the user wishes to remain > confidential; To transmit only non-confidential information such as plans, > pictures and drawings and to assume all risk and liability for and indemnify > Lowe's from any claims, losses or damages that may arise from the transmittal > of documents or including non-confidential information in the body of an > email transmittal. Thank you. > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Collecting SMF data with Logstreams
Thanks for that. And if you have not yet set up zEDC compression, where is a good place to start? Jim Horne NOTICE: All information in and attached to the e-mails below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message electronic, paper, or otherwise. By transmitting documents via this email: Users, Customers, Suppliers and Vendors collectively acknowledge and agree the transmittal of information via email is voluntary, is offered as a convenience, and is not a secured method of communication; Not to transmit any payment information E.G. credit card, debit card, checking account, wire transfer information, passwords, or sensitive and personal information E.G. Driver's license, DOB, social security, or any other information the user wishes to remain confidential; To transmit only non-confidential information such as plans, pictures and drawings and to assume all risk and liability for and indemnify Lowe's from any claims, losses or damages that may arise from the transmittal of documents or including non-confidential information in the body of an email transmittal. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Collecting SMF data with Logstreams
If you've already setup zEDC compression on the LPAR, it's as easy as this; DEFAULTLSNAME(IFASMF.&SYSPLEX..DEFAULT,COMPRESS) Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, February 10th, 2021 at 11:12 AM, Horne, Jim wrote: > Can you point to documentation on how to set up zEDC compression, especially > for SMF logstreams? > > Jim Horne > > NOTICE: All information in and attached to the e-mails below may be > proprietary, confidential, privileged and otherwise protected from improper > or erroneous disclosure. If you are not the sender's intended recipient, you > are not authorized to intercept, read, print, retain, copy, forward, or > disseminate this message. If you have erroneously received this > communication, please notify the sender immediately by phone (704-758-1000) > or by e-mail and destroy all copies of this message electronic, paper, or > otherwise. By transmitting documents via this email: Users, Customers, > Suppliers and Vendors collectively acknowledge and agree the transmittal of > information via email is voluntary, is offered as a convenience, and is not a > secured method of communication; Not to transmit any payment information E.G. > credit card, debit card, checking account, wire transfer information, > passwords, or sensitive and personal information E.G. Driver's license, DOB, > social security, or any other information the user wishes to remain > confidential; To transmit only non-confidential information such as plans, > pictures and drawings and to assume all risk and liability for and indemnify > Lowe's from any claims, losses or damages that may arise from the transmittal > of documents or including non-confidential information in the body of an > email transmittal. Thank you. > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Collecting SMF data with Logstreams
L r01,psaaold-psa L r01,ascbassb-assb(,r01) L r01,assbjsab-iazjsab(,r01) Regards, Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Collecting SMF data with Logstreams
Can you point to documentation on how to set up zEDC compression, especially for SMF logstreams? Jim Horne NOTICE: All information in and attached to the e-mails below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message electronic, paper, or otherwise. By transmitting documents via this email: Users, Customers, Suppliers and Vendors collectively acknowledge and agree the transmittal of information via email is voluntary, is offered as a convenience, and is not a secured method of communication; Not to transmit any payment information E.G. credit card, debit card, checking account, wire transfer information, passwords, or sensitive and personal information E.G. Driver's license, DOB, social security, or any other information the user wishes to remain confidential; To transmit only non-confidential information such as plans, pictures and drawings and to assume all risk and liability for and indemnify Lowe's from any claims, losses or damages that may arise from the transmittal of documents or including non-confidential information in the body of an email transmittal. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Collecting SMF data with Logstreams
If you have zEDC compression available it's very worthwhile to compress the SMF data before writing it to the logstream/staging datasets. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, February 10th, 2021 at 5:33 AM, Ron Burg wrote: > Hello, > > I'm trying to figure out the best-practice for collecting SMF data > > with Logstream instead of MAN datasets. There are few points I seem to > > miss and I hope to get some advice from those who used it for a while. > > I can see the benefits in storing the SMF on logstream only, for > > example I can use IFASMFDL to set range of dates and not have to worry > > about the location of each week/month in a different GDG generation. > > Also, the ability of logger to use the timestamp to read only relevant > > period can save time and CPU while offloading data in comparison to > > sequential read. > > Those benefit however are minified if I use the logstream only as a > > short-term storage before migrating the data to the regular GDG > > datasets. > > Here are some open questions I have: > > 1. The ideal situation for me would be to have all SMF data on > > logstream, for example for a period of two years, but there is a limit > > of 168 offload datasets before starting to use DSEXTENTs and each > > dataset can be up to about 2GB in size, this makes me wonder if I > > misunderstood the Logstream usage as a long term storage of smf data. > > Does it make sense to hold SMF data for few years on logstream? > 2. Using the IFASMFDL utility is very tricky as I can get RC 4 for > > both "RELATIVEDATE RANGE EXTENDS INTO FUTURE" and for a case where I > > ran the job on a different system (DASD-only logstream) and it failed > > to find the logstream. > > Worse than that, if I try to dump data from few offload datasets (a week > for > > example) and one of the "middle" datasets is missing I can get a > > return code of 0 while the data returned will be only what Logger was > > able to find. > > How can I be sure that the dumped data from IFASMFDL is complete? > > By the way, I used the "SMF Logstream Mode" redbook which was very > > useful but it left me with those unanswered questions. > > Many thanks for helping, > > Ron Burg > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Collecting SMF data with Logstreams
An advantage of log streams is that you can set up a log stream so type1 goes to one log stream and type2 goes to another log stream. If type1 produces too much data type2 is not affected. If you log to disk you process the data set to extract/process the type1 and type2 records. If type1 produces too many records so the SMF buffer fills up you can lose type 2 records. Colin On Wed, 10 Feb 2021 at 15:03, Ron Burg wrote: > Thank you Gadi and Jim, > > For us, using DASD-only logstream is the preferred way and I already set > it up on a test system and played with it a little bit. > I set up a RETPD of 10 days. this works fine and I understand that this is > the prefered way and not period of years, I just wanted to check the > possibilty of longer-period on a logsream as this extands the benefits (for > example maybe I can migrate the offload datasets of the Logstream itself to > tapes). > > The other thing that bothers me more is the IFASMFDL which gives me a > return code of 04 for critical errors. > for example, I tried to dump (not archive) data from logstream to a > sequential dataset, but I gave a wrong LS name, this resulted in the > following message: > IFA815I INSTALLATION ERROR FOR LOGSTREAM IFASMF.BLABLA.DFLT > LOGSTREAM IS UNAVAILABLE CAUSED BY RC=08-080B > IFA825I LOG STREAM NAME HAS NOT BEEN DEFINED IN LOGR POLICY. > > and although I can see in the message RC=08-080B, the job itself ends with > RC 4. > How can I catch those type of errors? the only solution I thought on is > running another step of REXX to parse the IFASMFDL output and search for > common error messages and then set a return code accordingly. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Collecting SMF data with Logstreams
Thank you Gadi and Jim, For us, using DASD-only logstream is the preferred way and I already set it up on a test system and played with it a little bit. I set up a RETPD of 10 days. this works fine and I understand that this is the prefered way and not period of years, I just wanted to check the possibilty of longer-period on a logsream as this extands the benefits (for example maybe I can migrate the offload datasets of the Logstream itself to tapes). The other thing that bothers me more is the IFASMFDL which gives me a return code of 04 for critical errors. for example, I tried to dump (not archive) data from logstream to a sequential dataset, but I gave a wrong LS name, this resulted in the following message: IFA815I INSTALLATION ERROR FOR LOGSTREAM IFASMF.BLABLA.DFLT LOGSTREAM IS UNAVAILABLE CAUSED BY RC=08-080B IFA825I LOG STREAM NAME HAS NOT BEEN DEFINED IN LOGR POLICY. and although I can see in the message RC=08-080B, the job itself ends with RC 4. How can I catch those type of errors? the only solution I thought on is running another step of REXX to parse the IFASMFDL output and search for common error messages and then set a return code accordingly. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Collecting SMF data with Logstreams
Ron, You definitely want to go to logstreams. We went to CF logstreams 10 years ago and have never regretted it. And that is the first question you need to answer: coupling facility, which is sysplex-wide, or DASD-only? That will affect all your other decisions. The next thing you need to do is see how much data you dump per day and in what records. That will help you determine what logstreams you want to use. Sadly, the picture IBM paints of keeping data in the logstream is not practical shops. Collecting over 100 gigabytes of data per day is not unusual; that does not lend itself to practical long term storage. You also need to determine how much disk space you are willing to give to offload datasets. While this is less of a concern for most shops than it was 10 years ago, it is still something you want to factor in. When we did our original calculations, we were comfortable keeping far less than a single day on disk. We period archive - archive, not dump - to tape, and consolidate at daily and weekly levels. You should save room for more offload datasets than you expect to handle the times the archive process breaks. On your question of return code 4 on the logstream dump, our archive jobs accept 4 as okay because of the message you cite. The archive process will fail, not merely RC=4, if it doesn't work. Again, test this for yourself; it will make you feel better and give you more confidence in your process. Best of luck! Jim Horne -Original Message- I'm trying to figure out the best-practice for collecting SMF data with Logstream instead of MAN datasets. There are few points I seem to miss and I hope to get some advice from those who used it for a while. I can see the benefits in storing the SMF on logstream only, for example I can use IFASMFDL to set range of dates and not have to worry about the location of each week/month in a different GDG generation. Also, the ability of logger to use the timestamp to read only relevant period can save time and CPU while offloading data in comparison to sequential read. Those benefit however are minified if I use the logstream only as a short-term storage before migrating the data to the regular GDG datasets. Here are some open questions I have: 1. The ideal situation for me would be to have all SMF data on logstream, for example for a period of two years, but there is a limit of 168 offload datasets before starting to use DSEXTENTs and each dataset can be up to about 2GB in size, this makes me wonder if I misunderstood the Logstream usage as a long term storage of smf data. Does it make sense to hold SMF data for few years on logstream? 2. Using the IFASMFDL utility is very tricky as I can get RC 4 for both "RELATIVEDATE RANGE EXTENDS INTO FUTURE" and for a case where I ran the job on a different system (DASD-only logstream) and it failed to find the logstream. Worse than that, if I try to dump data from few offload datasets (a week for example) and one of the "middle" datasets is missing I can get a return code of 0 while the data returned will be only what Logger was able to find. How can I be sure that the dumped data from IFASMFDL is complete? NOTICE: All information in and attached to the e-mails below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message electronic, paper, or otherwise. By transmitting documents via this email: Users, Customers, Suppliers and Vendors collectively acknowledge and agree the transmittal of information via email is voluntary, is offered as a convenience, and is not a secured method of communication; Not to transmit any payment information E.G. credit card, debit card, checking account, wire transfer information, passwords, or sensitive and personal information E.G. Driver's license, DOB, social security, or any other information the user wishes to remain confidential; To transmit only non-confidential information such as plans, pictures and drawings and to assume all risk and liability for and indemnify Lowe's from any claims, losses or damages that may arise from the transmittal of documents or including non-confidential information in the body of an email transmittal. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Collecting SMF data with Logstreams
Hi, We write SMF to logstreams. Every day at midnight we copy the data for the previous day to dasd. Every week we create a weekly smf dataset from the previous weeks daily datasets. Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ron Burg Sent: Wednesday, February 10, 2021 12:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Collecting SMF data with Logstreams Hello, I'm trying to figure out the best-practice for collecting SMF data with Logstream instead of MAN datasets. There are few points I seem to miss and I hope to get some advice from those who used it for a while. I can see the benefits in storing the SMF on logstream only, for example I can use IFASMFDL to set range of dates and not have to worry about the location of each week/month in a different GDG generation. Also, the ability of logger to use the timestamp to read only relevant period can save time and CPU while offloading data in comparison to sequential read. Those benefit however are minified if I use the logstream only as a short-term storage before migrating the data to the regular GDG datasets. Here are some open questions I have: 1. The ideal situation for me would be to have all SMF data on logstream, for example for a period of two years, but there is a limit of 168 offload datasets before starting to use DSEXTENTs and each dataset can be up to about 2GB in size, this makes me wonder if I misunderstood the Logstream usage as a long term storage of smf data. Does it make sense to hold SMF data for few years on logstream? 2. Using the IFASMFDL utility is very tricky as I can get RC 4 for both "RELATIVEDATE RANGE EXTENDS INTO FUTURE" and for a case where I ran the job on a different system (DASD-only logstream) and it failed to find the logstream. Worse than that, if I try to dump data from few offload datasets (a week for example) and one of the "middle" datasets is missing I can get a return code of 0 while the data returned will be only what Logger was able to find. How can I be sure that the dumped data from IFASMFDL is complete? By the way, I used the "SMF Logstream Mode" redbook which was very useful but it left me with those unanswered questions. Many thanks for helping, Ron Burg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Email secured by Check Point -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Collecting SMF data with Logstreams
Hello, I'm trying to figure out the best-practice for collecting SMF data with Logstream instead of MAN datasets. There are few points I seem to miss and I hope to get some advice from those who used it for a while. I can see the benefits in storing the SMF on logstream only, for example I can use IFASMFDL to set range of dates and not have to worry about the location of each week/month in a different GDG generation. Also, the ability of logger to use the timestamp to read only relevant period can save time and CPU while offloading data in comparison to sequential read. Those benefit however are minified if I use the logstream only as a short-term storage before migrating the data to the regular GDG datasets. Here are some open questions I have: 1. The ideal situation for me would be to have all SMF data on logstream, for example for a period of two years, but there is a limit of 168 offload datasets before starting to use DSEXTENTs and each dataset can be up to about 2GB in size, this makes me wonder if I misunderstood the Logstream usage as a long term storage of smf data. Does it make sense to hold SMF data for few years on logstream? 2. Using the IFASMFDL utility is very tricky as I can get RC 4 for both "RELATIVEDATE RANGE EXTENDS INTO FUTURE" and for a case where I ran the job on a different system (DASD-only logstream) and it failed to find the logstream. Worse than that, if I try to dump data from few offload datasets (a week for example) and one of the "middle" datasets is missing I can get a return code of 0 while the data returned will be only what Logger was able to find. How can I be sure that the dumped data from IFASMFDL is complete? By the way, I used the "SMF Logstream Mode" redbook which was very useful but it left me with those unanswered questions. Many thanks for helping, Ron Burg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Coupling Facility LOGSTREAMs
Hello everyone, I received some information back from IBM. *If data loss cannot be tolerated at the DR site, STG_DUPLEX in the LOGSTREAM definition must be set as YES.* *CICS cannot tolerate LOGSTREAM data loss.* Just sharing information here, in case someone runs into a similar situation in the future. On Wed, Aug 28, 2019 at 7:34 PM Cameron Conacher wrote: > Hello folks, > I have a question and precious little information. > We use CDC IIDR to support replicating VSAM file updates downstream from > our CIC applications. > > We have a LOGSTREAM defined in the Coupling Facility of our SYSPLEX. > Apparently, there is a VSAM file that is defined behind the CF LOGSTREAM. > I know very little about this. We simply requested the LOGSTREAM to be > made available to our CICS Regions, and our IBM resources waved their magic > wands and it was there. > > Anyway, I pro-actively defined all LOGSTREAMs that we would be requiring > for production, well ahead of when we would actually require them. > > Sometime later but before we installed out application change we ran a > Disaster Recovery test event. > When the DR event ran, there was a hiccup with our LOGSTREAM. > Sadly no diagnostic information was collected and saved. > I had our IBM folks redefine the LOGSTREAM and we were back in business. > > So, I now have a couple of questions for anyone that can help me > understand things. > > At the time CF structures are defined, is the VSAM file also automatically > defined? > Are these two separate/distinct steps? > > When Coupling Facility structures are defined, would this definition be > part a "normal" mirroring process that manages DR? > Is the LOGSTREAM something special I should call out to IBM to indicate it > requires DR attention? > Assuming that file systems are mirrored even for the CF, would data in the > LOGSTREAM VSAM file be mirrored to the DR site? > Would it make any difference if the VSAM file were never used, and > therefore present as an unloaded (never used) VSAM file? > I assume that a never used VSAM file would have nothing mirrored to the DR > site. > Would that present any difficulties to starting the DR site? > Maybe the VSAM file is automatically defined for the LOGSTREAM at SYSPLEX > startup time, if none is available from the catalog? > But if one is available in the catalog, maybe it cannot be in an unloaded > state at SYSPLEX startup time? > > Anyway I would appreciate any information anyone might share. I am just > curious about this at the moment. > I do not have a burning problem. I would simply like to understand a bit > better. > > Thanks > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Coupling Facility LOGSTREAMs
Hello folks, I have a question and precious little information. We use CDC IIDR to support replicating VSAM file updates downstream from our CIC applications. We have a LOGSTREAM defined in the Coupling Facility of our SYSPLEX. Apparently, there is a VSAM file that is defined behind the CF LOGSTREAM. I know very little about this. We simply requested the LOGSTREAM to be made available to our CICS Regions, and our IBM resources waved their magic wands and it was there. Anyway, I pro-actively defined all LOGSTREAMs that we would be requiring for production, well ahead of when we would actually require them. Sometime later but before we installed out application change we ran a Disaster Recovery test event. When the DR event ran, there was a hiccup with our LOGSTREAM. Sadly no diagnostic information was collected and saved. I had our IBM folks redefine the LOGSTREAM and we were back in business. So, I now have a couple of questions for anyone that can help me understand things. At the time CF structures are defined, is the VSAM file also automatically defined? Are these two separate/distinct steps? When Coupling Facility structures are defined, would this definition be part a "normal" mirroring process that manages DR? Is the LOGSTREAM something special I should call out to IBM to indicate it requires DR attention? Assuming that file systems are mirrored even for the CF, would data in the LOGSTREAM VSAM file be mirrored to the DR site? Would it make any difference if the VSAM file were never used, and therefore present as an unloaded (never used) VSAM file? I assume that a never used VSAM file would have nothing mirrored to the DR site. Would that present any difficulties to starting the DR site? Maybe the VSAM file is automatically defined for the LOGSTREAM at SYSPLEX startup time, if none is available from the catalog? But if one is available in the catalog, maybe it cannot be in an unloaded state at SYSPLEX startup time? Anyway I would appreciate any information anyone might share. I am just curious about this at the moment. I do not have a burning problem. I would simply like to understand a bit better. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Access to SMF logstreams
Gadi Ben-Avi wrote: >I would like to prevent a user from accessing the SMF log >streams >Is there anything else that I need to define? To add to earlier replies, it's prudent to encrypt your log stream data sets so that you're fully blocking unauthorized user access, even from storage administrators for example. You can enable log stream data set encryption in z/OS 2.2 (with the z/OS Data Set Encryption PTFs) or higher on IBM z114/z196 machines or higher. (z/OS 2.1 with PTFs has some awareness of encrypted log stream data sets but cannot create them.) There are some potential performance implications to consider on machines prior to the z14 models, but you shouldn't treat such implications as a veto even if they exist. Security is also quite important and keeps getting more important. For more information, try this link (z/OS 2.3 documentation): https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaf100/enclogstrds.htm Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Access to SMF logstreams
Probably -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Monday, April 29, 2019 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Access to SMF logstreams Hi Gadi, I think that you meant "discrete" instead of "discreet". Shalom, David On 2019-04-29 01:34, Gadi Ben-Avi wrote: > Hi, > I would like to prevent a user from accessing the SMF log streams. > Class is active and there are discreet profiles for each of the SMF > logstreams. > The user in question does not have access to the profiles. > > Is there anything else that I need to define? > > Thanks > > Gadi > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Access to SMF logstreams
Hi Gadi, I think that you meant "discrete" instead of "discreet". Shalom, David On 2019-04-29 01:34, Gadi Ben-Avi wrote: > Hi, > I would like to prevent a user from accessing the SMF log streams. > Class is active and there are discreet profiles for each of the SMF > logstreams. > The user in question does not have access to the profiles. > > Is there anything else that I need to define? > > Thanks > > Gadi > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Access to SMF logstreams
Thanks I found the problem The profile were protecting generic log stream names, but I defined the log streams using the LPAR name. Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Shorkend Sent: Monday, April 29, 2019 9:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Access to SMF logstreams Gadi You should be good. Remember to grant the user associated with the SMF address space UPDATE access to the profiles. If you haven't already done so, take a look at this redbook: SMF Logstream Mode <http://www.redbooks.ibm.com/redbooks/pdfs/sg247919.pdf> Chapter 5.1.5 covers RACF Mike On Mon, 29 Apr 2019 at 08:34, Gadi Ben-Avi wrote: > Hi, > I would like to prevent a user from accessing the SMF log streams. > Class is active and there are discreet profiles for each of the SMF > logstreams. > The user in question does not have access to the profiles. > > Is there anything else that I need to define? > > Thanks > > Gadi > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Mike Shorkend m...@shorkend.com www.shorkend.com Tel: +972524208743 Fax: +97239772196 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Access to SMF logstreams
Gadi You should be good. Remember to grant the user associated with the SMF address space UPDATE access to the profiles. If you haven't already done so, take a look at this redbook: SMF Logstream Mode <http://www.redbooks.ibm.com/redbooks/pdfs/sg247919.pdf> Chapter 5.1.5 covers RACF Mike On Mon, 29 Apr 2019 at 08:34, Gadi Ben-Avi wrote: > Hi, > I would like to prevent a user from accessing the SMF log streams. > Class is active and there are discreet profiles for each of the SMF > logstreams. > The user in question does not have access to the profiles. > > Is there anything else that I need to define? > > Thanks > > Gadi > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Mike Shorkend m...@shorkend.com www.shorkend.com Tel: +972524208743 Fax: +97239772196 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Access to SMF logstreams
Hi, I would like to prevent a user from accessing the SMF log streams. Class is active and there are discreet profiles for each of the SMF logstreams. The user in question does not have access to the profiles. Is there anything else that I need to define? Thanks Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best Practices, SMF LOGSTREAMS
It sounds as though you only have one CF? At least two is the recommended config. In that case you move the structures from one CF to the other then work on the “empty” one. You can always revert to using SMF datasets while working on the CF. On Thu, May 17, 2018 at 4:40 PM Kenneth J. Kripke wrote: > Hello; > > I wish to get some input on handling outages for the coupling > facilities when it comes to such activities as an IML to > > Expand the Coupling facility sizes. We had an episode where the Partition > was reconfigured for more storage which disrupted recording of > > The SMF data. The data was retrieved successfully via the using an > IEBGENER > with the SUBSYS=(LOGR,IFASEXIT) parm coded for the input of > > The log stream file. > > In instances such as this, how do other organizations insure no data loss? > I apologize beforehand, but, we are just in the process of putting > > Our SMF data to Log Streams. Any tips or suggestions in the form of best > practices would be appreciated. > > > > Kenneth J. Kripke > > > > k.kri...@comcast.net > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Best Practices, SMF LOGSTREAMS
Hello; I wish to get some input on handling outages for the coupling facilities when it comes to such activities as an IML to Expand the Coupling facility sizes. We had an episode where the Partition was reconfigured for more storage which disrupted recording of The SMF data. The data was retrieved successfully via the using an IEBGENER with the SUBSYS=(LOGR,IFASEXIT) parm coded for the input of The log stream file. In instances such as this, how do other organizations insure no data loss? I apologize beforehand, but, we are just in the process of putting Our SMF data to Log Streams. Any tips or suggestions in the form of best practices would be appreciated. Kenneth J. Kripke k.kri...@comcast.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF advice on additional logstreams
Based on my first-hand experience, the CA SMF DIRECTOR solution is nothing like any predecessor - has not been for nearly 10 years, possibly more. Any sizable z/OS site looking at SMF Logstreams should consider this solution, as an opportunity to help with easing migration and also going forward with a simplified SMF data management process. As for pricing, that's always negotiable between client/vendor, based on value, satisfaction, and longevity. Scott Barry SBBWorks, Inc. On Fri, 9 Feb 2018 18:00:49 +, Richards, Robert B. wrote: >Scott B., > >All good points. However, has CA-SMFiDirector, nee CA-JARS SMF, nee ManageSMF >come down in price? IIRC, it was less than $30K in 1985. Last I checked it was >closer to 10 times that and that was 10 years ago. And it had basically the >same functionality. For the record, I loved ManageSMF. That is until they >embedded it into JARS and screwed those of us that had ManageSMF. > >I do like the zEDC recommendation and the "frequency of reference" comments. > >Thanks for taking the time to reply. > >Bob > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Scott Barry >Sent: Friday, February 09, 2018 10:27 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMF advice on additional logstreams > >Also, for consideration, might there also be "frequency of reference", such as >security (ACF2, RACF, etc.) and/or DB2 TRACE (SMF 102 types) -- both of which >may require near real-time access directly from the SMF Logstream, as well as >after the SMF historical offload occurs? > >Maintaining separate SMF recording/offloading by SMF type provides the >opportunity for SMS-managed historical data-capture, as a retention-limit. > >For a client/site we support, SMF Logstreams are defined/managed by CA SMF >DIRECTOR using zEDC (8-to-1 compression typical) with DFHSM-managed historical >(ML0->ML2 directly) data, for up to 5 years -- again, based on SMF type, as >follows: > >- DFLT -- all types other than below mentioned, >- CICS / SMFT110 -- includes both CICS CMF and STATISTICS, >- DB2 / T101 -- DB2 ACCOUNTING, >- DB2 / T102 -- DB2 TRACE, >- ACF2 -- security logging events, >- WAS / SMFT120 -- includes WAS and WAS/ODM subtypes, >- MQ / SMFT116 -- excludes SMF Types 115 and 117 (IIB), >- IDMS / T254 > >And with CA SMF DIRECTOR software deployed, o e need not know where an SMF >type / recorded-date/time resides, only specify the EXTRACT statement with the >system (or ALL), type/subtype, date/date/time-range) and the software takes >care of finding the requested historical data (accomplished via dynamic >allocation, no JCL-DD coding). > >SMF historical data retention limits are also managedyby the software. The >software also controls awareness with BEFORE/AFTER MAN-to-Logstream migration, >again not requiring the end-user to know where to find SMF type/subtype, etc. >Very effective with simplifying and streamlining SMF data management, while >maintaining auditability and access-limit compliance -- tracking what SMF data >was recorded, offloaded, when, and who has approved access (via >program-limitation with security-rules). > > >Regards, > >Scott Barry >SBBWorks, Inc. > > >On Fri, 9 Feb 2018 :3:16:59 +, Richards, Robert B. > wrote: > >>Scott, >> >>I am the OP. >> >>I definitely appreciate your comments (and everyone else's too), but no one >>was commented on the other half of my questions. >> >>At what point or percentage (records written/space used) would it be >>advisable to split out 92s, 99s, 120s into their own logstreams? Right now >>they are all in Default. A coworker tested turning on 120s in WebSphere for >>an hour and then grew it into an estimated 2 million records that would use >>48% of the space after 8 hours. Not sure if that was one WAS server or more, >>but that certainly got his attention. >> >>I realize YMMV, but am canvassing for real world expeeiences here. >> >>Bob >> >>-Original Message- >>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >>On Behalf Of Scott Chapman >>Sent: Friday, February 09, 2018 7:31 AM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: SMF advice on additional logstreams >> >>Remember when looking at SMF volume, record counts are interesting, but the >>bigger issue is the number of bytes written. >> >>We (Peter Enrico and myself) recommend collecting at least 99 subtypes 6, 10, >>11, 12, and 14. >> >>6 is especially important as it's the summary service class period >>i
Re: SMF advice on additional logstreams
Scott B., All good points. However, has CA-SMF Director, nee CA-JARS SMF, nee ManageSMF come down in price? IIRC, it was less than $30K in 1985. Last I checked it was closer to 10 times that and that was 10 years ago. And it had basically the same functionality. For the record, I loved ManageSMF. That is until they embedded it into JARS and screwed those of us that had ManageSMF. I do like the zEDC recommendation and the "frequency of reference" comments. Thanks for taking the time to reply. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Barry Sent: Friday, February 09, 2018 10:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF advice on additional logstreams Also, for consideration, might there also be "frequency of reference", such as security (ACF2, RACF, etc.) and/or DB2 TRACE (SMF 102 types) -- both of which may require near real-time access directly from the SMF Logstream, as well as after the SMF historical offload occurs? Maintaining separate SMF recording/offloading by SMF type provides the opportunity for SMS-managed historical data-capture, as a retention-limit. For a client/site we support, SMF Logstreams are defined/managed by CA SMF DIRECTOR using zEDC (8-to-1 compression typical) with DFHSM-managed historical (ML0->ML2 directly) data, for up to 5 years -- again, based on SMF type, as follows: - DFLT -- all types other than below mentioned, - CICS / SMFT110 -- includes both CICS CMF and STATISTICS, - DB2 / T101 -- DB2 ACCOUNTING, - DB2 / T102 -- DB2 TRACE, - ACF2 -- security logging events, - WAS / SMFT120 -- includes WAS and WAS/ODM subtypes, - MQ / SMFT116 -- excludes SMF Types 115 and 117 (IIB), - IDMS / T254 And with CA SMF DIRECTOR software deployed, one need not know where an SMF type / recorded-date/time resides, only specify the EXTRACT statement with the system (or ALL), type/subtype, date/date/time-range) and the software takes care of finding the requested historical data (accomplished via dynamic allocation, no JCL-DD coding). SMF historical data retention limits are also managed by the software. The software also controls awareness with BEFORE/AFTER MAN-to-Logstream migration, again not requiring the end-user to know where to find SMF type/subtype, etc. Very effective with simplifying and streamlining SMF data management, while maintaining auditability and access-limit compliance -- tracking what SMF data was recorded, offloaded, when, and who has approved access (via program-limitation with security-rules). Regards, Scott Barry SBBWorks, Inc. On Fri, 9 Feb 2018 13:16:59 +, Richards, Robert B. wrote: >Scott, > >I am the OP. > >I definitely appreciate your comments (and everyone else's too), but no one >was commented on the other half of my questions. > >At what point or percentage (records written/space used) would it be advisable >to split out 92s, 99s, 120s into their own logstreams? Right now they are all >in Default. A coworker tested turning on 120s in WebSphere for an hour and >then grew it into an estimated 2 million records that would use 48% of the >space after 8 hours. Not sure if that was one WAS server or more, but that >certainly got his attention. > >I realize YMMV, but am canvassing for real world expeeiences here. > >Bob > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >On Behalf Of Scott Chapman >Sent: Friday, February 09, 2018 7:31 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMF advice on additional logstreams > >Remember when looking at SMF volume, record counts are interesting, but the >bigger issue is the number of bytes written. > >We (Peter Enrico and myself) recommend collecting at least 99 subtypes 6, 10, >11, 12, and 14. > >6 is especially important as it's the summary service class period >information (every 10 seconds) >10 is dynamic processor speed changes, which you hopefully don't see >11 is for Group Capacity limits, and is written every 5 minutes >12 is HiperDispatch interval (2 second) data which can show you >utilization information on a 2 second basis which can be quite >interesting >14 is HiperDispatch topology data written every 5 minutes or when a >change occurs > >The 6s and 12s are in fact high volume in terms of the number of records, but >the records themselves are relatively short. In terms of bytes, from what I've >seen the subtype 6 is somewhere between 40 and 100 MB of additional SMF data >per system per day. Subtype 12 seems to run around 40 to 50MB. I expect that's >not noticeable in most environments. Indeed, the type 30s can easily be more >data than that. Not to mention the 101s, 110s, and 120s. I actually have a >slide on this in an
Re: SMF advice on additional logstreams
Also, for consideration, might there also be "frequency of reference", such as security (ACF2, RACF, etc.) and/or DB2 TRACE (SMF 102 types) -- both of which may require near real-time access directly from the SMF Logstream, as well as after the SMF historical offload occurs? Maintaining separate SMF recording/offloading by SMF type provides the opportunity for SMS-managed historical data-capture, as a retention-limit. For a client/site we support, SMF Logstreams are defined/managed by CA SMF DIRECTOR using zEDC (8-to-1 compression typical) with DFHSM-managed historical (ML0->ML2 directly) data, for up to 5 years -- again, based on SMF type, as follows: - DFLT -- all types other than below mentioned, - CICS / SMFT110 -- includes both CICS CMF and STATISTICS, - DB2 / T101 -- DB2 ACCOUNTING, - DB2 / T102 -- DB2 TRACE, - ACF2 -- security logging events, - WAS / SMFT120 -- includes WAS and WAS/ODM subtypes, - MQ / SMFT116 -- excludes SMF Types 115 and 117 (IIB), - IDMS / T254 And with CA SMF DIRECTOR software deployed, one need not know where an SMF type / recorded-date/time resides, only specify the EXTRACT statement with the system (or ALL), type/subtype, date/date/time-range) and the software takes care of finding the requested historical data (accomplished via dynamic allocation, no JCL-DD coding). SMF historical data retention limits are also managed by the software. The software also controls awareness with BEFORE/AFTER MAN-to-Logstream migration, again not requiring the end-user to know where to find SMF type/subtype, etc. Very effective with simplifying and streamlining SMF data management, while maintaining auditability and access-limit compliance -- tracking what SMF data was recorded, offloaded, when, and who has approved access (via program-limitation with security-rules). Regards, Scott Barry SBBWorks, Inc. On Fri, 9 Feb 2018 13:16:59 +, Richards, Robert B. wrote: >Scott, > >I am the OP. > >I definitely appreciate your comments (and everyone else's too), but no one >was commented on the other half of my questions. > >At what point or percentage (records written/space used) would it be advisable >to split out 92s, 99s, 120s into their own logstreams? Right now they are all >in Default. A coworker tested turning on 120s in WebSphere for an hour and >then grew it into an estimated 2 million records that would use 48% of the >space after 8 hours. Not sure if that was one WAS server or more, but that >certainly got his attention. > >I realize YMMV, but am canvassing for real world expeeiences here. > >Bob > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Scott Chapman >Sent: Friday, February 09, 2018 7:31 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMF advice on additional logstreams > >Remember when looking at SMF volume, record counts are interesting, but the >bigger issue is the number of bytes written. > >We (Peter Enrico and myself) recommend collecting at least 99 subtypes 6, 10, >11, 12, and 14. > >6 is especially important as it's the summary service class period information >(every 10 seconds) >10 is dynamic processor speed changes, which you hopefully don't see >11 is for Group Capacity limits, and is written every 5 minutes >12 is HiperDispatch interval (2 second) data which can show you utilization >information on a 2 second basis which can be quite interesting >14 is HiperDispatch topology data written every 5 minutes or when a change >occurs > >The 6s and 12s are in fact high volume in terms of the number of records, but >the records themselves are relatively short. In terms of bytes, from what I've >seen the subtype 6 is somewhere between 40 and 100 MB of additional SMF data >per system per day. Subtype 12 seems to run around 40 to 50MB. I expect that's >not noticeable in most environments. Indeed, the type 30s can easily be more >data than that. Not to mention the 101s, 110s, and 120s. I actually have a >slide on this in an upcoming conference presentation. > >The other 99 subtypes are used less often and some can be more voluminous than >the 6 summary records. If you don't want to record those subtypes all the >time, I'm ok with that. But OTOH, if you need them to do a deep dive on WLM to >try to understand why things worked the way they did, then having them handy >is better than having to turn them on and recreate the issue. We don't >formally recommend people keep them enabled, but if it was me, I'd probably >keep at least most of them enabled. > >The 92s are file system information. The subtypes 10 and 11 are written every >time a file is opened/closed. In large Websphere Application Server >environments I
Re: SMF advice on additional logstreams
On Feb 9, 2018, at 7:16 AM, Richards, Robert B. wrote: > > At what point or percentage (records written/space used) would it be > advisable to split out 92s, 99s, 120s into their own logstreams? Right now > they are all in Default. A coworker tested turning on 120s in WebSphere for > an hour and then grew it into an estimated 2 million records that would use > 48% of the space after 8 hours. Not sure if that was one WAS server or more, > but that certainly got his attention. > > I realize YMMV, but am canvassing for real world experiences here. My philosophy in segregating SMF types into their own logstreams is to consider the consumers. So, for example, I have a logstream for all the types that we process for MXG reports, and another for the types used by CR+. (Note that the same record can be written to multiple logstreams.) -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF advice on additional logstreams
Scott, I am the OP. I definitely appreciate your comments (and everyone else's too), but no one was commented on the other half of my questions. At what point or percentage (records written/space used) would it be advisable to split out 92s, 99s, 120s into their own logstreams? Right now they are all in Default. A coworker tested turning on 120s in WebSphere for an hour and then grew it into an estimated 2 million records that would use 48% of the space after 8 hours. Not sure if that was one WAS server or more, but that certainly got his attention. I realize YMMV, but am canvassing for real world experiences here. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Chapman Sent: Friday, February 09, 2018 7:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF advice on additional logstreams Remember when looking at SMF volume, record counts are interesting, but the bigger issue is the number of bytes written. We (Peter Enrico and myself) recommend collecting at least 99 subtypes 6, 10, 11, 12, and 14. 6 is especially important as it's the summary service class period information (every 10 seconds) 10 is dynamic processor speed changes, which you hopefully don't see 11 is for Group Capacity limits, and is written every 5 minutes 12 is HiperDispatch interval (2 second) data which can show you utilization information on a 2 second basis which can be quite interesting 14 is HiperDispatch topology data written every 5 minutes or when a change occurs The 6s and 12s are in fact high volume in terms of the number of records, but the records themselves are relatively short. In terms of bytes, from what I've seen the subtype 6 is somewhere between 40 and 100 MB of additional SMF data per system per day. Subtype 12 seems to run around 40 to 50MB. I expect that's not noticeable in most environments. Indeed, the type 30s can easily be more data than that. Not to mention the 101s, 110s, and 120s. I actually have a slide on this in an upcoming conference presentation. The other 99 subtypes are used less often and some can be more voluminous than the 6 summary records. If you don't want to record those subtypes all the time, I'm ok with that. But OTOH, if you need them to do a deep dive on WLM to try to understand why things worked the way they did, then having them handy is better than having to turn them on and recreate the issue. We don't formally recommend people keep them enabled, but if it was me, I'd probably keep at least most of them enabled. The 92s are file system information. The subtypes 10 and 11 are written every time a file is opened/closed. In large Websphere Application Server environments I've seen these being very voluminous. I haven't looked at them lately, but my recollection from quite some time ago is that directory traversal (at least in the HFS file systems) triggered these records as well. I've seen the 92s in such an environment being much more voluminous than the 99s. In that environment, I did have the 92s turned off because of this. There are relatively new subtypes (at least 50-59) in the 92s, that may be why the OP is seeing more 92s. It looks like possibly useful information if you're tuning zFS performance, but I personally haven't spent any time yet investigating them. Scott Chapman On Thu, 8 Feb 2018 16:17:47 +, Allan Staller wrote: >Not sure about SMF92, but SMF99 are "WLM decision records". > >Yes they are large volume, but somewhat indispensable. > >Generally when there is a WLM problem it is extremely difficult or impossible >to reproduce. >If the SMF99's are not available "during the problem" it is virtually >impossible to debug. > >IMO, SMF99's should be recorded. I know Cheryl Watson and others may disagree. > >My US$ $0.02 worth, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF advice on additional logstreams
Remember when looking at SMF volume, record counts are interesting, but the bigger issue is the number of bytes written. We (Peter Enrico and myself) recommend collecting at least 99 subtypes 6, 10, 11, 12, and 14. 6 is especially important as it's the summary service class period information (every 10 seconds) 10 is dynamic processor speed changes, which you hopefully don't see 11 is for Group Capacity limits, and is written every 5 minutes 12 is HiperDispatch interval (2 second) data which can show you utilization information on a 2 second basis which can be quite interesting 14 is HiperDispatch topology data written every 5 minutes or when a change occurs The 6s and 12s are in fact high volume in terms of the number of records, but the records themselves are relatively short. In terms of bytes, from what I've seen the subtype 6 is somewhere between 40 and 100 MB of additional SMF data per system per day. Subtype 12 seems to run around 40 to 50MB. I expect that's not noticeable in most environments. Indeed, the type 30s can easily be more data than that. Not to mention the 101s, 110s, and 120s. I actually have a slide on this in an upcoming conference presentation. The other 99 subtypes are used less often and some can be more voluminous than the 6 summary records. If you don't want to record those subtypes all the time, I'm ok with that. But OTOH, if you need them to do a deep dive on WLM to try to understand why things worked the way they did, then having them handy is better than having to turn them on and recreate the issue. We don't formally recommend people keep them enabled, but if it was me, I'd probably keep at least most of them enabled. The 92s are file system information. The subtypes 10 and 11 are written every time a file is opened/closed. In large Websphere Application Server environments I've seen these being very voluminous. I haven't looked at them lately, but my recollection from quite some time ago is that directory traversal (at least in the HFS file systems) triggered these records as well. I've seen the 92s in such an environment being much more voluminous than the 99s. In that environment, I did have the 92s turned off because of this. There are relatively new subtypes (at least 50-59) in the 92s, that may be why the OP is seeing more 92s. It looks like possibly useful information if you're tuning zFS performance, but I personally haven't spent any time yet investigating them. Scott Chapman On Thu, 8 Feb 2018 16:17:47 +, Allan Staller wrote: >Not sure about SMF92, but SMF99 are "WLM decision records". > >Yes they are large volume, but somewhat indispensable. > >Generally when there is a WLM problem it is extremely difficult or impossible >to reproduce. >If the SMF99's are not available "during the problem" it is virtually >impossible to debug. > >IMO, SMF99's should be recorded. I know Cheryl Watson and others may disagree. > >My US$ $0.02 worth, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF advice on additional logstreams
Allan, At this time, I am not contemplating using NOTYPE on either of them. My original question was whether I should pull them out of DEFAULT or not due to the frequency in which they are created. Still...all comments appreciated. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Thursday, February 08, 2018 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF advice on additional logstreams Not sure about SMF92, but SMF99 are "WLM decision records". Yes they are large volume, but somewhat indispensable. Generally when there is a WLM problem it is extremely difficult or impossible to reproduce. If the SMF99's are not available "during the problem" it is virtually impossible to debug. IMO, SMF99's should be recorded. I know Cheryl Watson and others may disagree. My USD $0.02 worth, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Thursday, February 8, 2018 10:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF advice on additional logstreams I have always thought of SMF92 and SMF99 as data of interest primarily for monitoring products - do you have them enabled because of ISV requirements? If there is ISV software that needs to read this SMF data in real time (eg via IEFU8x) but there is no need for historical storage for these types, perhaps the vendor (or you) could create a simple IEFU8x to suppress these records from being hardened to MANx datasets or logstreams. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Thursday, February 8, 2018 3:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF advice on additional logstreams It was recently noticed that SMF TYPES 92 and 99 are creating a very high percentage of our overall SMF records. Seems to coincide with the implementation of z/OS 2.2, but that is speculative at the moment. Has anyone considered (or implemented) making one or both into their own logstream(s)? What about TYPE 120s from WebSphere? At present, I have DEFAULT, RMF, RACF and DB2 with the usual types. Thanks in advance, for your viewpoint(s). Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport&data=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845&sdata=lUU8KyIIZ5UpJX6ypDL%2FvS6%2Fd21%2BHuYJaq8FhqZD%2Bf8%3D&reserved=0 Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences&data=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845&sdata=XXMltfkhIrQuNXdspClQAO4JClJMSbbTSDYMCitv7ZA%3D&reserved=0 Privacy Policy - https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy&data=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845&sdata=yOfhey0%2BRjTNYEaeidsV%2BoT6WS3XCJXjDy6UHsZt0z0%3D&reserved=0 This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its cont
Re: SMF advice on additional logstreams
Rob, > do you have them enabled because of ISV requirements? Not intentionally, but you raise a point I need to consider. I am getting ready to install TMONMVS 4.8 which will now have their former standalone USS product integrated within it. I should probably wait until I review the installation requirements. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Thursday, February 08, 2018 11:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF advice on additional logstreams I have always thought of SMF92 and SMF99 as data of interest primarily for monitoring products - do you have them enabled because of ISV requirements? If there is ISV software that needs to read this SMF data in real time (eg via IEFU8x) but there is no need for historical storage for these types, perhaps the vendor (or you) could create a simple IEFU8x to suppress these records from being hardened to MANx datasets or logstreams. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Thursday, February 8, 2018 3:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF advice on additional logstreams It was recently noticed that SMF TYPES 92 and 99 are creating a very high percentage of our overall SMF records. Seems to coincide with the implementation of z/OS 2.2, but that is speculative at the moment. Has anyone considered (or implemented) making one or both into their own logstream(s)? What about TYPE 120s from WebSphere? At present, I have DEFAULT, RMF, RACF and DB2 with the usual types. Thanks in advance, for your viewpoint(s). Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF advice on additional logstreams
Not sure about SMF92, but SMF99 are "WLM decision records". Yes they are large volume, but somewhat indispensable. Generally when there is a WLM problem it is extremely difficult or impossible to reproduce. If the SMF99's are not available "during the problem" it is virtually impossible to debug. IMO, SMF99's should be recorded. I know Cheryl Watson and others may disagree. My USD $0.02 worth, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Thursday, February 8, 2018 10:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF advice on additional logstreams I have always thought of SMF92 and SMF99 as data of interest primarily for monitoring products - do you have them enabled because of ISV requirements? If there is ISV software that needs to read this SMF data in real time (eg via IEFU8x) but there is no need for historical storage for these types, perhaps the vendor (or you) could create a simple IEFU8x to suppress these records from being hardened to MANx datasets or logstreams. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Thursday, February 8, 2018 3:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF advice on additional logstreams It was recently noticed that SMF TYPES 92 and 99 are creating a very high percentage of our overall SMF records. Seems to coincide with the implementation of z/OS 2.2, but that is speculative at the moment. Has anyone considered (or implemented) making one or both into their own logstream(s)? What about TYPE 120s from WebSphere? At present, I have DEFAULT, RMF, RACF and DB2 with the usual types. Thanks in advance, for your viewpoint(s). Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport&data=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845&sdata=lUU8KyIIZ5UpJX6ypDL%2FvS6%2Fd21%2BHuYJaq8FhqZD%2Bf8%3D&reserved=0 Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences&data=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845&sdata=XXMltfkhIrQuNXdspClQAO4JClJMSbbTSDYMCitv7ZA%3D&reserved=0 Privacy Policy - https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy&data=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845&sdata=yOfhey0%2BRjTNYEaeidsV%2BoT6WS3XCJXjDy6UHsZt0z0%3D&reserved=0 This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL
Re: SMF advice on additional logstreams
I have always thought of SMF92 and SMF99 as data of interest primarily for monitoring products - do you have them enabled because of ISV requirements? If there is ISV software that needs to read this SMF data in real time (eg via IEFU8x) but there is no need for historical storage for these types, perhaps the vendor (or you) could create a simple IEFU8x to suppress these records from being hardened to MANx datasets or logstreams. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Thursday, February 8, 2018 3:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF advice on additional logstreams It was recently noticed that SMF TYPES 92 and 99 are creating a very high percentage of our overall SMF records. Seems to coincide with the implementation of z/OS 2.2, but that is speculative at the moment. Has anyone considered (or implemented) making one or both into their own logstream(s)? What about TYPE 120s from WebSphere? At present, I have DEFAULT, RMF, RACF and DB2 with the usual types. Thanks in advance, for your viewpoint(s). Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMF advice on additional logstreams
It was recently noticed that SMF TYPES 92 and 99 are creating a very high percentage of our overall SMF records. Seems to coincide with the implementation of z/OS 2.2, but that is speculative at the moment. Has anyone considered (or implemented) making one or both into their own logstream(s)? What about TYPE 120s from WebSphere? At present, I have DEFAULT, RMF, RACF and DB2 with the usual types. Thanks in advance, for your viewpoint(s). Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CICS Logstreams
Remember terminology for us here on the Listserv is important. Wrong words can be misleading.. On Sun, Jul 16, 2017 at 2:20 PM Mohamed Gomaa < 00cefc9a9b79-dmarc-requ...@listserv.ua.edu> wrote: > I think you mean use your favorite not user > > Thanks > > Sent from my iPhone > > > On Jul 16, 2017, at 8:03 PM, Lizette Koehler > wrote: > > > > I think you mean looking not locking > > > > User your favorite internet browser and use the phrase > > > > cics logstream define installation > > > > > > > > > > You will find what you need. > > > > Lizette > > > > > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > >> Behalf Of Mohamed Gomaa > >> Sent: Sunday, July 16, 2017 9:50 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: CICS Logstreams > >> > >> I am locking for setting CICS log stream using structure in sysplex and > for > >> recovery purpose we want to use staging dataset. > >> I am locking for policy sample to define it > >> > >> Thanks > >> Mohamed Juma > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CICS Logstreams
I think you mean use your favorite not user Thanks Sent from my iPhone > On Jul 16, 2017, at 8:03 PM, Lizette Koehler wrote: > > I think you mean looking not locking > > User your favorite internet browser and use the phrase > > cics logstream define installation > > > > > You will find what you need. > > Lizette > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Mohamed Gomaa >> Sent: Sunday, July 16, 2017 9:50 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: CICS Logstreams >> >> I am locking for setting CICS log stream using structure in sysplex and for >> recovery purpose we want to use staging dataset. >> I am locking for policy sample to define it >> >> Thanks >> Mohamed Juma > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CICS Logstreams
I think you mean looking not locking User your favorite internet browser and use the phrase cics logstream define installation You will find what you need. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mohamed Gomaa > Sent: Sunday, July 16, 2017 9:50 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: CICS Logstreams > > I am locking for setting CICS log stream using structure in sysplex and for > recovery purpose we want to use staging dataset. > I am locking for policy sample to define it > > Thanks > Mohamed Juma -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CICS Logstreams
I am locking for setting CICS log stream using structure in sysplex and for recovery purpose we want to use staging dataset. I am locking for policy sample to define it Thanks Mohamed Juma -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
LOGREC=IGNORE was introduced in MVS/ESA SP5.2.0 (around 1994) as part of the logrec to logstreams line item. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY John Eells/Poughkeepsie/IBM@IBMUS wrote on 06/30/2017 09:26:31 AM: > From: John Eells/Poughkeepsie/IBM@IBMUS > To: ibm-main@listserv.ua.edu > Date: 06/30/2017 02:03 PM > Subject: Re: Logstreams > > On z/OS V2.2, at least (I don't recall when we added this), if you: > > - Do NOT have the logrec data set named in MSTJCLxx; *and*, > - Specify LOGREC=IGNORE in IEASYSxx, > > ...the system should IPL without a LOGREC data set. You can use > SETLOGRC afterward, IIRC, to name a log stream or logrec data set. > > By all means, try this in a safe harbor (a sysprog sandbox) first to > make sure I did not miss a step above! > > Jesse 1 Robinson wrote: > > I do have the dimmest memory of IPLing a new LPAR that did not yet > have a SYS&SYSCLONE LOGREC. (Disclaimer: all my memories are dim.) > Perhaps the system prompted for a usable LOGREC data set, or at > least the volser of the named guy. But I think we've established > that you will not IPL without some LOGREC data set available. > > > > Note that this is not true for other logstream recording > mechanisms like SMF and OPERLOG. A system will limp along with no > usable MANx data set; also with no functioning OPERLOG. In fact this > happens to us every time we bring up our DR systems for the first > time--without any defined logstreams. You can create a logstream > only on the exploiting system. So we IPL, then run the log stream > creation jobs for SMF, OPERLOG, and RRS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
On z/OS V2.2, at least (I don't recall when we added this), if you: - Do NOT have the logrec data set named in MSTJCLxx; *and*, - Specify LOGREC=IGNORE in IEASYSxx, ...the system should IPL without a LOGREC data set. You can use SETLOGRC afterward, IIRC, to name a log stream or logrec data set. By all means, try this in a safe harbor (a sysprog sandbox) first to make sure I did not miss a step above! Jesse 1 Robinson wrote: I do have the dimmest memory of IPLing a new LPAR that did not yet have a SYS&SYSCLONE LOGREC. (Disclaimer: all my memories are dim.) Perhaps the system prompted for a usable LOGREC data set, or at least the volser of the named guy. But I think we've established that you will not IPL without some LOGREC data set available. Note that this is not true for other logstream recording mechanisms like SMF and OPERLOG. A system will limp along with no usable MANx data set; also with no functioning OPERLOG. In fact this happens to us every time we bring up our DR systems for the first time--without any defined logstreams. You can create a logstream only on the exploiting system. So we IPL, then run the log stream creation jobs for SMF, OPERLOG, and RRS. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
Aha. I didn't know about specifying 'LOGSTREAM' in IEASYSxx. I wonder about our DR situation though. We cannot create any logstream until the first system is up and running... . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skeldum, William Sent: Thursday, June 29, 2017 9:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Logstreams We use logstreams, including for logrec and do not have any SYS1.LOGREC datasets defined. Our IEASYSxx parmlib specifies LOGREC=LOGSTREAM. We have no issues IPLing. Early in the IPL we receive message: IFB085I LOGREC RECORDING TO LOG STREAM SYSPLEX.LOGREC.ALLRECS Bill Skeldum -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie Sent: Thursday, June 29, 2017 10:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams Thanks, and yes, It does fail without sys1.logrec. I can't believe the system can't come up without LOGREC. I would think it should issue messages but at least let you IPL. Once you're up you can allocate a new one. Maybe Z/os could even dynamically allocate one and just keep going. From what I can gather so far about Logstreams, it just holds a bunch of different logs like Operlog, LOGREC, etc. but the data is still in it's original form as if it were read directly from the original data set. Bill From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Thursday, June 29, 2017 3:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams Logstream cannot substitute for the LOGREC data set at IPL, which others suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. It is however named in IEASYSxx, where we have coded LOGREC=SYS1.LOGREC.$SYS&SYSCLONE ever since we moved to sysplex in the mid-90s. I cannot recall trying to IPL without LOGREC, but I imagine it would fail. There are good reasons for moving to logstream, but the ability to IPL is not one of them. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, June 29, 2017 7:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Logstreams So does this mean the problem you are trying to solve by asking about logstreams is Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC? Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Wilkie > Sent: Thursday, June 29, 2017 5:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > Lizette: > > > I am not using logstreams yet. I am just looking into it. > > > The SYS1.LOGREC data set got deleted on our test system so we couldn't > IPL it. We ran a job from our other system to create a new one and it IPL'd > OK. > > > Thanks > > Bill > > > > From: IBM Mainframe Discussion List on > behalf of Lizette Koehler > Sent: Thursday, June 29, 2017 12:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > When you say you deleted a logstream - which one? > > If it is for Logrec, did you have the SYS1.LOGREC dataset still > cataloged and on the system? > > What was the corrective action that allowed you to IPL > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie > > Sent: Thursday, June 29, 2017 2:32 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > We accidentally deleted Logrec on one system, and couldn't IPL. Not > > sure if logstream being available would have made a difference. > > > > > > Bill > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
I do have the dimmest memory of IPLing a new LPAR that did not yet have a SYS&SYSCLONE LOGREC. (Disclaimer: all my memories are dim.) Perhaps the system prompted for a usable LOGREC data set, or at least the volser of the named guy. But I think we've established that you will not IPL without some LOGREC data set available. Note that this is not true for other logstream recording mechanisms like SMF and OPERLOG. A system will limp along with no usable MANx data set; also with no functioning OPERLOG. In fact this happens to us every time we bring up our DR systems for the first time--without any defined logstreams. You can create a logstream only on the exploiting system. So we IPL, then run the log stream creation jobs for SMF, OPERLOG, and RRS. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Thursday, June 29, 2017 11:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Logstreams It will come up with LOGREC full :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Wilkie > Sent: Thursday, June 29, 2017 9:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > Thanks, and yes, It does fail without sys1.logrec. > > > I can't believe the system can't come up without LOGREC. I would think > it should issue messages but at least let you IPL. Once you're up you > can allocate a new one. Maybe Z/os could even dynamically allocate > one and just keep going. > > > From what I can gather so far about Logstreams, it just holds a bunch > of different logs like Operlog, LOGREC, etc. but the data is still in > it's original form as if it were read directly from the original data set. > > > Bill > > > > From: IBM Mainframe Discussion List on > behalf of Jesse 1 Robinson > Sent: Thursday, June 29, 2017 3:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > Logstream cannot substitute for the LOGREC data set at IPL, which > others suggest is required. I checked our MSTJCLxx, but LOGREC is not named > there. > It is however named in IEASYSxx, where we have coded > LOGREC=SYS1.LOGREC.$SYS&SYSCLONE ever since we moved to sysplex in the > mid-90s. I cannot recall trying to IPL without LOGREC, but I imagine > it would fail. > > There are good reasons for moving to logstream, but the ability to IPL > is not one of them. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: Thursday, June 29, 2017 7:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Logstreams > > So does this mean the problem you are trying to solve by asking about > logstreams is > > Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC? > Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone? > > Lizette > > > > > -Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie > > Sent: Thursday, June 29, 2017 5:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > Lizette: > > > > > > I am not using logstreams yet. I am just looking into it. > > > > > > The SYS1.LOGREC data set got deleted on our test system so we > > couldn't IPL it. We ran a job from our other system to create a new > > one and it IPL'd > OK. > > > > > > Thanks > > > > Bill > > > > > > > > From: IBM Mainframe Discussion List on > > behalf of Lizette Koehler > > Sent: Thursday, June 29, 2017 12:45 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > When you say you deleted a logstream - which one? > > > > If it is for Logrec, did you have the SYS1.LOGREC dataset still > > cataloged and on the system? > > > > What was the corrective action that allowed you to IPL > > > > Lizette > > > > > > > -Original Message- > > > From: IBM Mainframe Discussi
Re: Logstreams
It will come up with LOGREC full :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Wilkie > Sent: Thursday, June 29, 2017 9:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > Thanks, and yes, It does fail without sys1.logrec. > > > I can't believe the system can't come up without LOGREC. I would think it > should issue messages but at least let you IPL. Once you're up you can > allocate a new one. Maybe Z/os could even dynamically allocate one and just > keep going. > > > From what I can gather so far about Logstreams, it just holds a bunch of > different logs like Operlog, LOGREC, etc. but the data is still in it's > original > form as if it were read directly from the original data set. > > > Bill > > > > From: IBM Mainframe Discussion List on > behalf of Jesse 1 Robinson > Sent: Thursday, June 29, 2017 3:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > Logstream cannot substitute for the LOGREC data set at IPL, which others > suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. > It is however named in IEASYSxx, where we have coded > LOGREC=SYS1.LOGREC.$SYS&SYSCLONE ever since we moved to sysplex in > the mid-90s. I cannot recall trying to IPL without LOGREC, but I imagine it > would fail. > > There are good reasons for moving to logstream, but the ability to IPL is not > one of them. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: Thursday, June 29, 2017 7:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Logstreams > > So does this mean the problem you are trying to solve by asking about > logstreams is > > Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC? > Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone? > > Lizette > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Bill Wilkie > > Sent: Thursday, June 29, 2017 5:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > Lizette: > > > > > > I am not using logstreams yet. I am just looking into it. > > > > > > The SYS1.LOGREC data set got deleted on our test system so we couldn't > > IPL it. We ran a job from our other system to create a new one and it IPL'd > OK. > > > > > > Thanks > > > > Bill > > > > > > > > From: IBM Mainframe Discussion List on > > behalf of Lizette Koehler > > Sent: Thursday, June 29, 2017 12:45 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > When you say you deleted a logstream - which one? > > > > If it is for Logrec, did you have the SYS1.LOGREC dataset still > > cataloged and on the system? > > > > What was the corrective action that allowed you to IPL > > > > Lizette > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie > > > Sent: Thursday, June 29, 2017 2:32 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Logstreams > > > > > > We accidentally deleted Logrec on one system, and couldn't IPL. Not > > > sure if logstream being available would have made a difference. > > > > > > > > > Bill > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
Thanks, that's nice to KnowBill From: IBM Mainframe Discussion List on behalf of Skeldum, William Sent: Thursday, June 29, 2017 4:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams We use logstreams, including for logrec and do not have any SYS1.LOGREC datasets defined. Our IEASYSxx parmlib specifies LOGREC=LOGSTREAM. We have no issues IPLing. Early in the IPL we receive message: IFB085I LOGREC RECORDING TO LOG STREAM SYSPLEX.LOGREC.ALLRECS Bill Skeldum -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie Sent: Thursday, June 29, 2017 10:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams Thanks, and yes, It does fail without sys1.logrec. I can't believe the system can't come up without LOGREC. I would think it should issue messages but at least let you IPL. Once you're up you can allocate a new one. Maybe Z/os could even dynamically allocate one and just keep going. From what I can gather so far about Logstreams, it just holds a bunch of different logs like Operlog, LOGREC, etc. but the data is still in it's original form as if it were read directly from the original data set. Bill From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Thursday, June 29, 2017 3:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams Logstream cannot substitute for the LOGREC data set at IPL, which others suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. It is however named in IEASYSxx, where we have coded LOGREC=SYS1.LOGREC.$SYS&SYSCLONE ever since we moved to sysplex in the mid-90s. I cannot recall trying to IPL without LOGREC, but I imagine it would fail. There are good reasons for moving to logstream, but the ability to IPL is not one of them. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, June 29, 2017 7:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Logstreams So does this mean the problem you are trying to solve by asking about logstreams is Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC? Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Wilkie > Sent: Thursday, June 29, 2017 5:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > Lizette: > > > I am not using logstreams yet. I am just looking into it. > > > The SYS1.LOGREC data set got deleted on our test system so we couldn't > IPL it. We ran a job from our other system to create a new one and it IPL'd > OK. > > > Thanks > > Bill > > > > From: IBM Mainframe Discussion List on > behalf of Lizette Koehler > Sent: Thursday, June 29, 2017 12:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > When you say you deleted a logstream - which one? > > If it is for Logrec, did you have the SYS1.LOGREC dataset still > cataloged and on the system? > > What was the corrective action that allowed you to IPL > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie > > Sent: Thursday, June 29, 2017 2:32 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > We accidentally deleted Logrec on one system, and couldn't IPL. Not > > sure if logstream being available would have made a difference. > > > > > > Bill > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, disse
Re: Logstreams
We use logstreams, including for logrec and do not have any SYS1.LOGREC datasets defined. Our IEASYSxx parmlib specifies LOGREC=LOGSTREAM. We have no issues IPLing. Early in the IPL we receive message: IFB085I LOGREC RECORDING TO LOG STREAM SYSPLEX.LOGREC.ALLRECS Bill Skeldum -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie Sent: Thursday, June 29, 2017 10:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams Thanks, and yes, It does fail without sys1.logrec. I can't believe the system can't come up without LOGREC. I would think it should issue messages but at least let you IPL. Once you're up you can allocate a new one. Maybe Z/os could even dynamically allocate one and just keep going. From what I can gather so far about Logstreams, it just holds a bunch of different logs like Operlog, LOGREC, etc. but the data is still in it's original form as if it were read directly from the original data set. Bill From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Thursday, June 29, 2017 3:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams Logstream cannot substitute for the LOGREC data set at IPL, which others suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. It is however named in IEASYSxx, where we have coded LOGREC=SYS1.LOGREC.$SYS&SYSCLONE ever since we moved to sysplex in the mid-90s. I cannot recall trying to IPL without LOGREC, but I imagine it would fail. There are good reasons for moving to logstream, but the ability to IPL is not one of them. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, June 29, 2017 7:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Logstreams So does this mean the problem you are trying to solve by asking about logstreams is Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC? Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Wilkie > Sent: Thursday, June 29, 2017 5:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > Lizette: > > > I am not using logstreams yet. I am just looking into it. > > > The SYS1.LOGREC data set got deleted on our test system so we couldn't > IPL it. We ran a job from our other system to create a new one and it IPL'd > OK. > > > Thanks > > Bill > > > > From: IBM Mainframe Discussion List on > behalf of Lizette Koehler > Sent: Thursday, June 29, 2017 12:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > When you say you deleted a logstream - which one? > > If it is for Logrec, did you have the SYS1.LOGREC dataset still > cataloged and on the system? > > What was the corrective action that allowed you to IPL > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie > > Sent: Thursday, June 29, 2017 2:32 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > We accidentally deleted Logrec on one system, and couldn't IPL. Not > > sure if logstream being available would have made a difference. > > > > > > Bill > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
Mvs logger - Speed, Sysplex available, transaction loggers Rob Schramm On Thu, Jun 29, 2017, 12:21 PM Bill Wilkie wrote: > Lizette: > > > I am trying to understand the purpose of the logstream vs Logrec. I am > just finishing the Logrec manuals and about to read the Logstream Redbook. > > > I was just trying to figure out who was using logstreams and why. > > > Thanks > > Bill > > > > From: IBM Mainframe Discussion List on behalf > of Lizette Koehler > Sent: Thursday, June 29, 2017 2:50 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > So does this mean the problem you are trying to solve by asking about > logstreams is > > Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC? > Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone? > > Lizette > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Bill Wilkie > > Sent: Thursday, June 29, 2017 5:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > Lizette: > > > > > > I am not using logstreams yet. I am just looking into it. > > > > > > The SYS1.LOGREC data set got deleted on our test system so we couldn't > IPL > > it. We ran a job from our other system to create a new one and it IPL'd > OK. > > > > > > Thanks > > > > Bill > > > > > > > > From: IBM Mainframe Discussion List on > behalf of > > Lizette Koehler > > Sent: Thursday, June 29, 2017 12:45 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > When you say you deleted a logstream - which one? > > > > If it is for Logrec, did you have the SYS1.LOGREC dataset still > cataloged and > > on the system? > > > > What was the corrective action that allowed you to IPL > > > > Lizette > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > > On Behalf Of Bill Wilkie > > > Sent: Thursday, June 29, 2017 2:32 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Logstreams > > > > > > We accidentally deleted Logrec on one system, and couldn't IPL. Not > > > sure if logstream being available would have made a difference. > > > > > > > > > Bill > > > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
Lizette: I am trying to understand the purpose of the logstream vs Logrec. I am just finishing the Logrec manuals and about to read the Logstream Redbook. I was just trying to figure out who was using logstreams and why. Thanks Bill From: IBM Mainframe Discussion List on behalf of Lizette Koehler Sent: Thursday, June 29, 2017 2:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams So does this mean the problem you are trying to solve by asking about logstreams is Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC? Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Wilkie > Sent: Thursday, June 29, 2017 5:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > Lizette: > > > I am not using logstreams yet. I am just looking into it. > > > The SYS1.LOGREC data set got deleted on our test system so we couldn't IPL > it. We ran a job from our other system to create a new one and it IPL'd OK. > > > Thanks > > Bill > > > > From: IBM Mainframe Discussion List on behalf of > Lizette Koehler > Sent: Thursday, June 29, 2017 12:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > When you say you deleted a logstream - which one? > > If it is for Logrec, did you have the SYS1.LOGREC dataset still cataloged and > on the system? > > What was the corrective action that allowed you to IPL > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Bill Wilkie > > Sent: Thursday, June 29, 2017 2:32 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > We accidentally deleted Logrec on one system, and couldn't IPL. Not > > sure if logstream being available would have made a difference. > > > > > > Bill > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
Thanks, and yes, It does fail without sys1.logrec. I can't believe the system can't come up without LOGREC. I would think it should issue messages but at least let you IPL. Once you're up you can allocate a new one. Maybe Z/os could even dynamically allocate one and just keep going. From what I can gather so far about Logstreams, it just holds a bunch of different logs like Operlog, LOGREC, etc. but the data is still in it's original form as if it were read directly from the original data set. Bill From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Thursday, June 29, 2017 3:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams Logstream cannot substitute for the LOGREC data set at IPL, which others suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. It is however named in IEASYSxx, where we have coded LOGREC=SYS1.LOGREC.$SYS&SYSCLONE ever since we moved to sysplex in the mid-90s. I cannot recall trying to IPL without LOGREC, but I imagine it would fail. There are good reasons for moving to logstream, but the ability to IPL is not one of them. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, June 29, 2017 7:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Logstreams So does this mean the problem you are trying to solve by asking about logstreams is Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC? Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Wilkie > Sent: Thursday, June 29, 2017 5:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > Lizette: > > > I am not using logstreams yet. I am just looking into it. > > > The SYS1.LOGREC data set got deleted on our test system so we couldn't > IPL it. We ran a job from our other system to create a new one and it IPL'd > OK. > > > Thanks > > Bill > > > > From: IBM Mainframe Discussion List on > behalf of Lizette Koehler > Sent: Thursday, June 29, 2017 12:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > When you say you deleted a logstream - which one? > > If it is for Logrec, did you have the SYS1.LOGREC dataset still > cataloged and on the system? > > What was the corrective action that allowed you to IPL > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie > > Sent: Thursday, June 29, 2017 2:32 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > We accidentally deleted Logrec on one system, and couldn't IPL. Not > > sure if logstream being available would have made a difference. > > > > > > Bill > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
Logstream cannot substitute for the LOGREC data set at IPL, which others suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. It is however named in IEASYSxx, where we have coded LOGREC=SYS1.LOGREC.$SYS&SYSCLONE ever since we moved to sysplex in the mid-90s. I cannot recall trying to IPL without LOGREC, but I imagine it would fail. There are good reasons for moving to logstream, but the ability to IPL is not one of them. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, June 29, 2017 7:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Logstreams So does this mean the problem you are trying to solve by asking about logstreams is Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC? Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Bill Wilkie > Sent: Thursday, June 29, 2017 5:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > Lizette: > > > I am not using logstreams yet. I am just looking into it. > > > The SYS1.LOGREC data set got deleted on our test system so we couldn't > IPL it. We ran a job from our other system to create a new one and it IPL'd > OK. > > > Thanks > > Bill > > > > From: IBM Mainframe Discussion List on > behalf of Lizette Koehler > Sent: Thursday, June 29, 2017 12:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > When you say you deleted a logstream - which one? > > If it is for Logrec, did you have the SYS1.LOGREC dataset still > cataloged and on the system? > > What was the corrective action that allowed you to IPL > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie > > Sent: Thursday, June 29, 2017 2:32 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > We accidentally deleted Logrec on one system, and couldn't IPL. Not > > sure if logstream being available would have made a difference. > > > > > > Bill > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
So does this mean the problem you are trying to solve by asking about logstreams is Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC? Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Wilkie > Sent: Thursday, June 29, 2017 5:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > Lizette: > > > I am not using logstreams yet. I am just looking into it. > > > The SYS1.LOGREC data set got deleted on our test system so we couldn't IPL > it. We ran a job from our other system to create a new one and it IPL'd OK. > > > Thanks > > Bill > > > > From: IBM Mainframe Discussion List on behalf of > Lizette Koehler > Sent: Thursday, June 29, 2017 12:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > When you say you deleted a logstream - which one? > > If it is for Logrec, did you have the SYS1.LOGREC dataset still cataloged and > on the system? > > What was the corrective action that allowed you to IPL > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Bill Wilkie > > Sent: Thursday, June 29, 2017 2:32 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Logstreams > > > > We accidentally deleted Logrec on one system, and couldn't IPL. Not > > sure if logstream being available would have made a difference. > > > > > > Bill > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
Lizette: I am not using logstreams yet. I am just looking into it. The SYS1.LOGREC data set got deleted on our test system so we couldn't IPL it. We ran a job from our other system to create a new one and it IPL'd OK. Thanks Bill From: IBM Mainframe Discussion List on behalf of Lizette Koehler Sent: Thursday, June 29, 2017 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams When you say you deleted a logstream - which one? If it is for Logrec, did you have the SYS1.LOGREC dataset still cataloged and on the system? What was the corrective action that allowed you to IPL Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Wilkie > Sent: Thursday, June 29, 2017 2:32 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > We accidentally deleted Logrec on one system, and couldn't IPL. Not sure if > logstream being available would have made a difference. > > > Bill > > > > From: IBM Mainframe Discussion List on behalf of > Jesse 1 Robinson > Sent: Wednesday, June 28, 2017 8:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > We don't run regularly with logrec logstream, but I believe that you still > need to maintain SYS1.LOGREC in order to capture IPL time records that are > cut before logger gets running. If that's still true... > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Pew, Curtis G > Sent: Wednesday, June 28, 2017 12:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Logstreams > > On Jun 28, 2017, at 2:07 PM, Bill Wilkie wrote: > > > > Is anyone running from logstreams instead just running logrec? Using > logstreams for other reports? How used? Problems? > > I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all > went smoothly and without issues. > > -- > Pew, Curtis G > curtis@austin.utexas.edu > ITS Systems/Core/Administrative Services > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
I believe you are correct, we added SETLOGRC LOGSTREAM to COMMNDxx member, SYS1.LOGREC is still maintained on my systems Carmen - Original Message - From: "Jesse 1 Robinson" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, June 28, 2017 3:23:03 PM Subject: Re: Logstreams We don't run regularly with logrec logstream, but I believe that you still need to maintain SYS1.LOGREC in order to capture IPL time records that are cut before logger gets running. If that's still true... . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Wednesday, June 28, 2017 12:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Logstreams On Jun 28, 2017, at 2:07 PM, Bill Wilkie wrote: > > Is anyone running from logstreams instead just running logrec? Using > logstreams for other reports? How used? Problems? I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all went smoothly and without issues. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
When you say you deleted a logstream - which one? If it is for Logrec, did you have the SYS1.LOGREC dataset still cataloged and on the system? What was the corrective action that allowed you to IPL Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Wilkie > Sent: Thursday, June 29, 2017 2:32 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > We accidentally deleted Logrec on one system, and couldn't IPL. Not sure if > logstream being available would have made a difference. > > > Bill > > > > From: IBM Mainframe Discussion List on behalf of > Jesse 1 Robinson > Sent: Wednesday, June 28, 2017 8:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Logstreams > > We don't run regularly with logrec logstream, but I believe that you still > need to maintain SYS1.LOGREC in order to capture IPL time records that are > cut before logger gets running. If that's still true... > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Pew, Curtis G > Sent: Wednesday, June 28, 2017 12:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Logstreams > > On Jun 28, 2017, at 2:07 PM, Bill Wilkie wrote: > > > > Is anyone running from logstreams instead just running logrec? Using > logstreams for other reports? How used? Problems? > > I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all > went smoothly and without issues. > > -- > Pew, Curtis G > curtis@austin.utexas.edu > ITS Systems/Core/Administrative Services > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
We accidentally deleted Logrec on one system, and couldn't IPL. Not sure if logstream being available would have made a difference. Bill From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Wednesday, June 28, 2017 8:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams We don't run regularly with logrec logstream, but I believe that you still need to maintain SYS1.LOGREC in order to capture IPL time records that are cut before logger gets running. If that's still true... . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Wednesday, June 28, 2017 12:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Logstreams On Jun 28, 2017, at 2:07 PM, Bill Wilkie wrote: > > Is anyone running from logstreams instead just running logrec? Using > logstreams for other reports? How used? Problems? I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all went smoothly and without issues. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
Just so. We start up our systems on SYS1.LOGREC and convert to logstream once logger services are available (SETLOGRC command issued via automation). I converted both SMF and SYSLOG to logstreams with no dramas. This site had syslogs stored by system-id, so I modified SAMPLIB(IEAMDBLG) to filter/save OPERLOG by sys-id to maintain the saved syslog GDG's that were inspected by other processes. Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Thursday, 29 June 2017 5:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Logstreams We don't run regularly with logrec logstream, but I believe that you still need to maintain SYS1.LOGREC in order to capture IPL time records that are cut before logger gets running. If that's still true... . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Wednesday, June 28, 2017 12:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Logstreams On Jun 28, 2017, at 2:07 PM, Bill Wilkie wrote: > > Is anyone running from logstreams instead just running logrec? Using > logstreams for other reports? How used? Problems? I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all went smoothly and without issues. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
We don't run regularly with logrec logstream, but I believe that you still need to maintain SYS1.LOGREC in order to capture IPL time records that are cut before logger gets running. If that's still true... . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Wednesday, June 28, 2017 12:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Logstreams On Jun 28, 2017, at 2:07 PM, Bill Wilkie wrote: > > Is anyone running from logstreams instead just running logrec? Using > logstreams for other reports? How used? Problems? I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all went smoothly and without issues. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
On Jun 28, 2017, at 2:07 PM, Bill Wilkie wrote: > > Is anyone running from logstreams instead just running logrec? Using > logstreams for other reports? How used? Problems? I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all went smoothly and without issues. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logstreams
Since I think 2001 the first company that wanted SYSPLEX savings started using LOGR LOGREC logstream, at the time it was the easiest was to exploit SYSPLEX savings. I'm using it now and offloading logstream data daily to a logrec history file, and running any EREP reports I need to just as it if I was using SYS1.LOGREC Carmen - Original Message - From: "Bill Wilkie" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, June 28, 2017 2:07:02 PM Subject: Logstreams Is anyone running from logstreams instead just running logrec? Using logstreams for other reports? How used? Problems? Thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Logstreams
Is anyone running from logstreams instead just running logrec? Using logstreams for other reports? How used? Problems? Thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Logstreams
What was the solution? Thanks, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jonathan Miller Sent: Tuesday, May 20, 2014 9:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF Logstreams I found the solution to this problem so no need repsond. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Logstreams
I found the solution to this problem so no need repsond. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMF Logstreams
How do i extract smf data that has already been marked for delete from a logstream? We use the archive feature and had a problem and one of the archived tapes was delete. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN