REXX and Logstreams

[Mark Jacobs]

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=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

[Michael Oujesky]

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

[Radoslaw Skorupka]

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

[Michael Oujesky]

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

[Steve Beaver]

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

[Carmen Vitullo]

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

[Carmen Vitullo]

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

[Steve Beaver]

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

[Charles Mills]

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

[Steve Beaver]

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

[Scott Barry]

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.)
>
>   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

[Steve Beaver]

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.)   

   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

[Art Gutowski]

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

[Michael Oujesky]

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

[Scott Barry]

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

[Steve Beaver]

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

[Steve Beaver]

Logstreams are a bit befuddling 

 

Trouble will start below

 

 DATA TYPE(LOGR) REPORT(YES)

  

DEFINE LOGSTREAM NAME(IFASMF.)

   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.,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

[Bonnie Ordonez]

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

[Mark Jacobs]

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=j==s=web==rja=8=2ahUKEwiMopLk6N_uAhXVK80KHQvvAGoQFjAAegQIAhAC=http%3A%2F%2Fwww.redbooks.ibm.com%2Fredbooks%2Fpdfs%2Fsg248259.pdf=AOvVaw1N6FizLuyEIN-uSXF650n9

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=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

[Horne, Jim]

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

[Mark Jacobs]

If you've already setup zEDC compression on the LPAR, it's as easy as this;

DEFAULTLSNAME(IFASMF.,COMPRESS)

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=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

[Pierre Fichaud]

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

[Horne, Jim]

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

[Mark Jacobs]

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=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

[Colin Paice]

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

[Ron Burg]

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

[Horne, Jim]

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

[Gadi Ben-Avi]

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

[Ron Burg]

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

[Cameron Conacher]

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

[Cameron Conacher]

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

[Timothy Sipples]

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

[Gadi Ben-Avi]

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

[David Spiegel]

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

[Gadi Ben-Avi]

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

[Mike Shorkend]

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

[Gadi Ben-Avi]

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

[Michael Babcock]

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

[Kenneth J. Kripke]

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

[Scott Barry]

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. 
<robert.richa...@opm.gov> 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. 
><robert.richa...@opm.gov> 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 importan

Re: SMF advice on additional logstreams

[Richards, Robert B.]

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. 
<robert.richa...@opm.gov> 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

Re: SMF advice on additional logstreams

[Scott Barry]

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. 
<robert.richa...@opm.gov> 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've seen these bei

Re: SMF advice on additional logstreams

[Pew, Curtis G]

On Feb 9, 2018, at 7:16 AM, Richards, Robert B. <robert.richa...@opm.gov> 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

[Richards, Robert B.]

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 <allan.stal...@hcl.com> 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

[Scott Chapman]

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

[Richards, Robert B.]

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=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=lUU8KyIIZ5UpJX6ypDL%2FvS6%2Fd21%2BHuYJaq8FhqZD%2Bf8%3D=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=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=XXMltfkhIrQuNXdspClQAO4JClJMSbbTSDYMCitv7ZA%3D=0
Privacy Policy - 
https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=yOfhey0%2BRjTNYEaeidsV%2BoT6WS3XCJXjDy6UHsZt0z0%3D=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 H

Re: SMF advice on additional logstreams

[Richards, Robert B.]

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

[Allan Staller]

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=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=lUU8KyIIZ5UpJX6ypDL%2FvS6%2Fd21%2BHuYJaq8FhqZD%2Bf8%3D=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=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=XXMltfkhIrQuNXdspClQAO4JClJMSbbTSDYMCitv7ZA%3D=0
Privacy Policy - 
https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy=02%7C01%7Callan.staller%40HCL.COM%7C0e87c30fbbdb4b18c08b08d56f0dbd24%7Cdd85efd06a9c4fee843ed525fa4be3ca%7C0%7C0%7C636537027178034845=yOfhey0%2BRjTNYEaeidsV%2BoT6WS3XCJXjDy6UHsZt0z0%3D=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 is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 

Re: SMF advice on additional logstreams

[Rob Scott]

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

[Richards, Robert B.]

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

[scott Ford]

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 <stars...@mindspring.com>
> 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

[Mohamed Gomaa]

I think you mean use your favorite not user 

Thanks 

Sent from my iPhone

> On Jul 16, 2017, at 8:03 PM, Lizette Koehler <stars...@mindspring.com> 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

[Lizette Koehler]

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

[Mohamed Gomaa]

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

[Jim Mulder]

 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 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

[John Eells]

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 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

[Jesse 1 Robinson]

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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Jesse 1 Robinson <jesse1.robin...@sce.com>
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 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 <IBM-MAIN@LISTSERV.UA.EDU> on 
> behalf of Lizette Koehler <stars...@mindspring.com>
> 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

[Jesse 1 Robinson]

I do have the dimmest memory of IPLing a new LPAR that did not yet have a 
SYS 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 <IBM-MAIN@LISTSERV.UA.EDU> on 
> behalf of Jesse 1 Robinson <jesse1.robin...@sce.com>
> 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 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 <IBM-MAIN@LISTSERV.UA.EDU> on 
> > behalf of Lizette Koehler <stars...@mindspring.com>
> > 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 Mess

Re: Logstreams

[Gibney, Dave]

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 <IBM-MAIN@LISTSERV.UA.EDU> on
> behalf of Jesse 1 Robinson <jesse1.robin...@sce.com>
> 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 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 <IBM-MAIN@LISTSERV.UA.EDU> on
> > behalf of Lizette Koehler <stars...@mindspring.com>
> > 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

[Bill Wilkie]

Thanks, that's nice to KnowBill



From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Skeldum, William <william.skel...@efirstbank.com>
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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Jesse 1 Robinson <jesse1.robin...@sce.com>
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 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 <IBM-MAIN@LISTSERV.UA.EDU> on
> behalf of Lizette Koehler <stars...@mindspring.com>
> 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 re

Re: Logstreams

[Skeldum, William]

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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Jesse 1 Robinson <jesse1.robin...@sce.com>
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 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 <IBM-MAIN@LISTSERV.UA.EDU> on
> behalf of Lizette Koehler <stars...@mindspring.com>
> 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-m

Re: Logstreams

[Rob Schramm]

Mvs logger - Speed, Sysplex available, transaction loggers

Rob Schramm

On Thu, Jun 29, 2017, 12:21 PM Bill Wilkie <billwil...@hotmail.com> 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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf
> of Lizette Koehler <stars...@mindspring.com>
> 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 <IBM-MAIN@LISTSERV.UA.EDU> on
> behalf of
> > Lizette Koehler <stars...@mindspring.com>
> > 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

[Bill Wilkie]

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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Lizette Koehler <stars...@mindspring.com>
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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
> Lizette Koehler <stars...@mindspring.com>
> 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

[Bill Wilkie]

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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Jesse 1 Robinson <jesse1.robin...@sce.com>
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 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 <IBM-MAIN@LISTSERV.UA.EDU> on
> behalf of Lizette Koehler <stars...@mindspring.com>
> 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

[Jesse 1 Robinson]

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 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 <IBM-MAIN@LISTSERV.UA.EDU> on 
> behalf of Lizette Koehler <stars...@mindspring.com>
> 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 Koehler]

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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
> Lizette Koehler <stars...@mindspring.com>
> 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

[Bill Wilkie]

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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Lizette Koehler <stars...@mindspring.com>
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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
> Jesse 1 Robinson <jesse1.robin...@sce.com>
> 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 <billwil...@hotmail.com> 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

[Carmen Vitullo]

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" <jesse1.robin...@sce.com> 
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 <billwil...@hotmail.com> 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

[Lizette Koehler]

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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
> Jesse 1 Robinson <jesse1.robin...@sce.com>
> 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 <billwil...@hotmail.com> 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

[Bill Wilkie]

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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Jesse 1 Robinson <jesse1.robin...@sce.com>
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 <billwil...@hotmail.com> 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

[Anthony Thompson]

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 <billwil...@hotmail.com> 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

[Jesse 1 Robinson]

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 <billwil...@hotmail.com> 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

[Pew, Curtis G]

On Jun 28, 2017, at 2:07 PM, Bill Wilkie <billwil...@hotmail.com> 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

[Carmen Vitullo]

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" <billwil...@hotmail.com> 
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

[Bill Wilkie]

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

[Greg Shirey]

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

SMF Logstreams

[Jonathan Miller]

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

Re: SMF Logstreams

[Jonathan Miller]

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