Re: SYSLOG and LOGR query
Skip, I know that. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jesse 1 Robinson > Sent: 19 July, 2018 17:56 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SYSLOG and LOGR query > > You get OPERLOG recording not just 'if' JES2 is down. OPERLOG starts > recording very early in an IPL--before JES starts--and continues until V > XCF,OFF--after JES has shut down. SYSLOG can eventually write out very > early IPL-time messages stored by MVS before JES starts but quits as > soon as JES terminates. That alone should make the effort worthwhile. > > . > . > J.O.Skip Robinson For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF DATASET protection WHEN(SYSID)
>So how do people protect the same dataset differently on various LPAR's, or is >it just not possible? We had to make sure that the compilers do not run on a system that doesn't have licence=z/OS. We used when(sysid) in class PROGRAM, for the names of the compilers as the program name to be protected. The downside is that the data set name must be specified (that the program is loaded from), and every data set name must be mentioned in the rule in PROGRAM. So if anyone copies the full compiler data set to their own HLQ and calls it from there, it would work on *any* system in the sysplex. The upside is that most of those calling the compiler would not have a clue how to do that. We have an additional safeguard: The jobclass canned compile jobs run in only exists on one system. How IBM expects a customer to make sure the compilers are only called on a licence=z/OS system is beyond me - RACF certainly doesn't have the appropriate instrumentation for it that I can see. As for having prod and test in the same sysplex - we are still a MIM shop, and we have a devil of a time stopping that type of data set sharing between prod and test. I think that you would have to duplicate your RACF data base and use different data set rules on the prod system(s) than on the test system(s). Which would not be easy to implement. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF DATASET protection WHEN(SYSID)
I've never tried what you're looking to do. We don't share data across sysplex boundaries. It might annoy your users, but you might try giving them a different userid on each system. Each userid would have its own unique access rights even though it represents the same person. Now that I write it down, sounds pretty lame. ;-( . . 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 Brian Westerman Sent: Thursday, July 19, 2018 6:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):RACF DATASET protection WHEN(SYSID) Hi, I was hit with a question that I don't know the answer to. Previously (until today) I had thought, but never tried, that you could have a shared RACF database between two LPARs and that you could protect datasets differently based on the DATASET class rule such that if you had a dataset "TESTCASE.MY.DATASET" specified as UAC of NONE, the you could set up two dataset permits as follows: PERMIT 'TESTCASE.**' ACCESS(READ) ID(userid) WHEN(SYSID(SYSP)) and PERMIT 'TESTCASE.**' ACCESS(ALTER) ID(userid) WHEN(SYSID(SYST)) And that it would make it so that if the user were to log onto the test LPAR (SYST), they could update the TESTCASE.MY.DATASET all they wanted, but if they logged onto the production LPAR (SYSP) that they were limited to only READ access. Well, apparently the SYSID subparameter of WHEN is not valid for DATASET rules. So how do people protect the same dataset differently on various LPAR's, or is it just not possible? Any help or pointers would be appreciated. What I would like is just a simple way to make it so that people in the production LPAR can see and look at the TEST datasets, but if they actually want to change them, they have to actually log onto that LPAR to do it. I know that seems like a silly way to operate, but in this case there is actually a good reason for it. I just can't think of how to do it without the WHEN(SYSID) parm. Does anyone have any ideas? Thanks, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
On 20/07/2018 12:38 AM, Thomas David Rivers wrote: David Crayford wrote: It's always best to get storage on the stack and avoid the heap if you can. z/OS C/C++ supports the GCC extensions that allow you to align storage using variable attributes. char buffer[1408] __attribute__((__aligned__(16))) ; // only works in 64-bit Unless the stack is above-the-bar and you need below-the-bar memory... I mention this because the OP wrote that he is using __malloc31(). Good point! Although it's curious why the OP is using __malloc31() when calling CSRC4RG1 which is a 64-bit service. But for z/OS it would be probably be useful to have a aligned_malloc31() for such a requirement. Does Dignus C have something like aligned_malloc()? I don't think LE allows the stack to be above-the-bar, but in a 64-bit Dignus program it can certainly be there (and, by default, is...) It sure does. Check out the STACK64 LE runtime option. - Dave R. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF DATASET protection WHEN(SYSID)
Good point, I'll do that. It should have occurred to me that it was more appropriate there. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF DATASET protection WHEN(SYSID)
You may get an answer on this listserv, but might also have better luck with the RACF listserv... https://listserv.uga.edu/cgi-bin/wa?A0=RACF-L HTH, Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Westerman Sent: Thursday, July 19, 2018 9:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RACF DATASET protection WHEN(SYSID) Hi, I was hit with a question that I don't know the answer to. Previously (until today) I had thought, but never tried, that you could have a shared RACF database between two LPARs and that you could protect datasets differently based on the DATASET class rule such that if you had a dataset "TESTCASE.MY.DATASET" specified as UAC of NONE, the you could set up two dataset permits as follows: PERMIT 'TESTCASE.**' ACCESS(READ) ID(userid) WHEN(SYSID(SYSP)) and PERMIT 'TESTCASE.**' ACCESS(ALTER) ID(userid) WHEN(SYSID(SYST)) And that it would make it so that if the user were to log onto the test LPAR (SYST), they could update the TESTCASE.MY.DATASET all they wanted, but if they logged onto the production LPAR (SYSP) that they were limited to only READ access. Well, apparently the SYSID subparameter of WHEN is not valid for DATASET rules. So how do people protect the same dataset differently on various LPAR's, or is it just not possible? Any help or pointers would be appreciated. What I would like is just a simple way to make it so that people in the production LPAR can see and look at the TEST datasets, but if they actually want to change them, they have to actually log onto that LPAR to do it. I know that seems like a silly way to operate, but in this case there is actually a good reason for it. I just can't think of how to do it without the WHEN(SYSID) parm. Does anyone have any ideas? Thanks, Brian -- 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
RACF DATASET protection WHEN(SYSID)
Hi, I was hit with a question that I don't know the answer to. Previously (until today) I had thought, but never tried, that you could have a shared RACF database between two LPARs and that you could protect datasets differently based on the DATASET class rule such that if you had a dataset "TESTCASE.MY.DATASET" specified as UAC of NONE, the you could set up two dataset permits as follows: PERMIT 'TESTCASE.**' ACCESS(READ) ID(userid) WHEN(SYSID(SYSP)) and PERMIT 'TESTCASE.**' ACCESS(ALTER) ID(userid) WHEN(SYSID(SYST)) And that it would make it so that if the user were to log onto the test LPAR (SYST), they could update the TESTCASE.MY.DATASET all they wanted, but if they logged onto the production LPAR (SYSP) that they were limited to only READ access. Well, apparently the SYSID subparameter of WHEN is not valid for DATASET rules. So how do people protect the same dataset differently on various LPAR's, or is it just not possible? Any help or pointers would be appreciated. What I would like is just a simple way to make it so that people in the production LPAR can see and look at the TEST datasets, but if they actually want to change them, they have to actually log onto that LPAR to do it. I know that seems like a silly way to operate, but in this case there is actually a good reason for it. I just can't think of how to do it without the WHEN(SYSID) parm. Does anyone have any ideas? Thanks, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM Toolkit for Swift on z/OS
I've not seen any official mention of this, so I figured I'd make an unofficial mention of it. The IBM Toolkit for Swift on z/OS Community Edition has been released by IBM. It's a free download (don't know if that will change). More information can be found here: https://developer.ibm.com/mainframe/products/ibm-toolkit-swift-z-os/ I've been working with the beta releases for the last year or so and I really like it. Don't know that we'd ever have cause to actually use it for "real production work", but others might. Give it a shot? Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
On Thu, 19 Jul 2018 12:38:06 -0400, Thomas David Rivers David Crayford wrote: > >I don't think LE allows the stack to be above-the-bar XPLINK-64 allocates the stack above the bar. I don't know if that can be overridden. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Tell IBM about your experience managing z/OS, z/OSMF & more!
If you haven't had a chance to share your thoughts with us, we'd love to hear from you! We'd appreciate your response by July 20, 2018. Thanks to everyone who has taken our survey to date. Please take our survey to help us understand any time consuming or complex tasks that you experience with managing your z/OS environment. We'd also like to know if you are using z/OSMF and hear your thoughts on mainframe operations, DevOps and cloud. Here's the link to the survey: https://www.surveygizmo.com/s3/4403313/IBM-z-OS-Survey-2018 Thanks in advance for your participation! Regards, Iris M. Rivera Design Researcher, z System Software iriv...@us.ibm.com @zsurveygirl -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
David Crayford wrote: It's always best to get storage on the stack and avoid the heap if you can. z/OS C/C++ supports the GCC extensions that allow you to align storage using variable attributes. char buffer[1408] __attribute__((__aligned__(16))) ; // only works in 64-bit Unless the stack is above-the-bar and you need below-the-bar memory... I mention this because the OP wrote that he is using __malloc31(). I don't think LE allows the stack to be above-the-bar, but in a 64-bit Dignus program it can certainly be there (and, by default, is...) - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
Done, although he's too nice of a person to have to keep explaining the inexplicable. :-) sas On Thu, Jul 19, 2018 at 11:23 AM, Charles Mills wrote: > So NILF takes -16 but NILL won't take -4? > > You should post that on the HLASM list. Jonathon Scott of HLASM > development is very responsive there. > > Charles > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSLOG and LOGR query
You get OPERLOG recording not just 'if' JES2 is down. OPERLOG starts recording very early in an IPL--before JES starts--and continues until V XCF,OFF--after JES has shut down. SYSLOG can eventually write out very early IPL-time messages stored by MVS before JES starts but quits as soon as JES terminates. That alone should make the effort worthwhile. . . 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 Sean Gleann Sent: Thursday, July 19, 2018 6:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: SYSLOG and LOGR query OK, I understand Allan's point about there being no benefit in using CFs with DASDONLY, but I'd put that consideration to one side since - as I say - I'm working with a MONOPLEX and so I don't expect to be sharing anything. I just want to make use of the facility. I've already put a fair amount of work in to gathering SMF data in a logstream and the result works fine - & is far easier to work with that the old-style MANx files IMHO. With regard to the OPERLOG, that is all the SYSLOGs that are being collected all in one place, right? Well, in my situation, I can't see any difference between the SDSF OPERLOG and the SDSF SYSLOG displays. Which makes sense to me. I've only got one source. Kees is right - I want to be able capitalise on the "...easier to process, search, keep for a longer period..." bits. I want to fully automate the collection of my SYSLOG in daily files. I've currently got a horrible kludgy set-up of REXX execs and ICEMAN stuff and manual interventions to do this. Having seen how much easier things were with the SMF data, I moved on to handling the SYSLOG in a similar manner. But I appear to have fallen in to a hole... Sean On 19 July 2018 at 14:22, John McKown wrote: > On Thu, Jul 19, 2018 at 8:20 AM Vernooij, Kees (ITOPT1) - KLM < > kees.verno...@klm.com> wrote: > > > He says he has a monoplex. > > The advantage is, that you het syslog data in the operlog logstream, > > i.s.o. Jes2 Sysout files. That can be easier to process, search, > > keep > for a > > longer period etc. > > > > I haven't done it, but would it also mean that you'd get the "syslog" > data recorded even if JES2 is down. I.e. when you are shutting down to > IPL, you have a more complete record. > > > > > > > Kees. > > > > -- > There is no such thing as the Cloud. It is just somebody else’s computer. > > Maranatha! <>< > John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RES: SYSLOG and LOGR query
Glen, Do you have a CFRM CDS defined to a monoplex environment, what for ? When you list LOGR definitons, are they ok ? (DATA TYPE(LOGR) REPORT(YES) ) Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto BANCO BRADESCO S.A. 4250 / DITI Engenharia de Software Sistemas Operacionais Mainframes Tel: +55 11 3684-9602 R: 49602 3-1404 Fax: +55 11 3684-4427 -Mensagem original- De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de Sean Gleann Enviada em: quinta-feira, 19 de julho de 2018 10:04 Para: IBM-MAIN@LISTSERV.UA.EDU Assunto: SYSLOG and LOGR query I'm trying to use a LOGR logstream to gather the SYSLOG data, but I don't appear to be able to make it work... I believe I've correctly followed all the instructions detailed in the relevant section of the "z/OS System Logger" redbook. Modifying the CFRM policy to add the OPERLOG structure, and then defining the associated logstream all appears to have gone OK. For what it's worth, I'm working with a system in MONOPLEX mode, so the logstream is defined with DASDONLY(YES) specified. My CONSOLxx member includes "HARDCOPY DEVNUM(OPERLOG) ROUTCODE(ALL) CMDLEVEL(CMDS) HCFORMAT(CENTURY)", which I *think* is right but I'm not absolutely certain. Then to 'activate' the facility, I used the V OPERLOG,HARDCPY command - which again I'm not absolutely certain of. Whenever I try to use the IEAMDBLG program, it either abends with a U0001 or ends with message "MLG003I NORECORDS IN RANGE", depending on the PARM that I use. Can anyone see anything wrong with my work here, please? I can't be the only one trying to do this, so if any one out there can help at all, I'd appreciate it mightily. Sean -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. LEGAL ADVICE...This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
So NILF takes -16 but NILL won't take -4? You should post that on the HLASM list. Jonathon Scott of HLASM development is very responsive there. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Thursday, July 19, 2018 7:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C6 in CSRC4RG1 Thank-you Mr. Relson! Oddly enough, in rerunning my test, it seems that it fails considerably less than half the time. That is, it usually aligns on a 16-byte boundary. This test version is configured to allocate the cpool anchor and extent, plus four 160-byte buffers. This is to stress-test buffer exhaustion logic. The production version uses 4091* buffers, making the total space just under 640KB (which as we all know, should be enough for anybody). That has never failed to align correctly. * The idea is to *avoid* buffer exhaustion, and presently, this seems to be enough. Re specification of rounding mask: I do think -16, -8, etc. are an elegant way to specify these, particularly as they correlate to 16-byte, 8-byte, etc. boundaries. I sure wish they were usable with NILL and NILF. Well, I decided to check before complaining... and (surprise!): 028C 481 NILL R15,-4 ** ASMA031E Invalid immediate or mask field 0290 C0FB FFF0 482 NILF R15,-16 483 * Sigh. sas On Thu, Jul 19, 2018 at 8:01 AM, Peter Relson wrote: > > Problems: > > 1. Undocumented requirement to quad-word align CPOOL anchor and/or > extent > > in 64-bit mode (and actually undocumented alignment requirements for > all). > > 2. Unable to guarantee quad-word alignment with malloc. > > I will get the first taken care of. The anchor does not need to be > quad-word aligned. > > For the second, as has been pointed out in C syntax but I think not in > words, you would do what everyone used to do prior to STARTBDY keyword of > GETMAIN / STORAGE OBTAIN -- round the start address up to the necessary > boundary, having gotten an additional 8 if you need the length to be some > specific value (or 15 if you do are not guaranteed that the area will at > least be on a doubleword boundary). > > The rounding is typically "Add 15, AND with -16". > > Peter Relson > z/OS Core Technology Design -- 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: S0C6 in CSRC4RG1
Thank-you Mr. Relson! Oddly enough, in rerunning my test, it seems that it fails considerably less than half the time. That is, it usually aligns on a 16-byte boundary. This test version is configured to allocate the cpool anchor and extent, plus four 160-byte buffers. This is to stress-test buffer exhaustion logic. The production version uses 4091* buffers, making the total space just under 640KB (which as we all know, should be enough for anybody). That has never failed to align correctly. * The idea is to *avoid* buffer exhaustion, and presently, this seems to be enough. Re specification of rounding mask: I do think -16, -8, etc. are an elegant way to specify these, particularly as they correlate to 16-byte, 8-byte, etc. boundaries. I sure wish they were usable with NILL and NILF. Well, I decided to check before complaining... and (surprise!): 028C 481 NILL R15,-4 ** ASMA031E Invalid immediate or mask field 0290 C0FB FFF0 482 NILF R15,-16 483 * Sigh. sas On Thu, Jul 19, 2018 at 8:01 AM, Peter Relson wrote: > > Problems: > > 1. Undocumented requirement to quad-word align CPOOL anchor and/or > extent > > in 64-bit mode (and actually undocumented alignment requirements for > all). > > 2. Unable to guarantee quad-word alignment with malloc. > > I will get the first taken care of. The anchor does not need to be > quad-word aligned. > > For the second, as has been pointed out in C syntax but I think not in > words, you would do what everyone used to do prior to STARTBDY keyword of > GETMAIN / STORAGE OBTAIN -- round the start address up to the necessary > boundary, having gotten an additional 8 if you need the length to be some > specific value (or 15 if you do are not guaranteed that the area will at > least be on a doubleword boundary). > > The rounding is typically "Add 15, AND with -16". > > Peter Relson > z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSLOG and LOGR query
"that is all the SYSLOGs that are being collected all in one place, right?" If you mean: "all SYSLOGs within the Sysplex" you are right. Logstreams don't cross sysplexes. Unfortunately, we don't use IEAMDBLG, so I can't help you there. We still use the jes2 syslog for daily archiving, no time/need yet to change this. But the long online availability and SDSF's Operlog feature alone are worthwhile the effort. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Sean Gleann > Sent: 19 July, 2018 15:35 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SYSLOG and LOGR query > > OK, I understand Allan's point about there being no benefit in using CFs > with DASDONLY, but I'd put that consideration to one side since - as I > say > - I'm working with a MONOPLEX and so I don't expect to be sharing > anything. > I just want to make use of the facility. > > I've already put a fair amount of work in to gathering SMF data in a > logstream and the result works fine - & is far easier to work with that > the > old-style MANx files IMHO. > > With regard to the OPERLOG, that is all the SYSLOGs that are being > collected all in one place, right? > Well, in my situation, I can't see any difference between the SDSF > OPERLOG > and the SDSF SYSLOG displays. Which makes sense to me. I've only got one > source. > > Kees is right - I want to be able capitalise on the "...easier to > process, > search, keep for a longer period..." bits. I want to fully automate the > collection of my SYSLOG in daily files. I've currently got a horrible > kludgy set-up of REXX execs and ICEMAN stuff and manual interventions to > do > this. Having seen how much easier things were with the SMF data, I moved > on > to handling the SYSLOG in a similar manner. > But I appear to have fallen in to a hole... > > Sean > > On 19 July 2018 at 14:22, John McKown > wrote: > > > On Thu, Jul 19, 2018 at 8:20 AM Vernooij, Kees (ITOPT1) - KLM < > > kees.verno...@klm.com> wrote: > > > > > He says he has a monoplex. > > > The advantage is, that you het syslog data in the operlog logstream, > > > i.s.o. Jes2 Sysout files. That can be easier to process, search, > keep > > for a > > > longer period etc. > > > > > > > I haven't done it, but would it also mean that you'd get the "syslog" > data > > recorded even if JES2 is down. I.e. when you are shutting down to IPL, > you > > have a more complete record. > > > > > > > > > > > > Kees. > > > > > > > -- > > There is no such thing as the Cloud. It is just somebody else’s > computer. > > > > Maranatha! <>< > > John McKown > > > > -- > > 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSLOG and LOGR query
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: 19 July, 2018 15:22 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SYSLOG and LOGR query > > On Thu, Jul 19, 2018 at 8:20 AM Vernooij, Kees (ITOPT1) - KLM < > kees.verno...@klm.com> wrote: > > > He says he has a monoplex. > > The advantage is, that you het syslog data in the operlog logstream, > > i.s.o. Jes2 Sysout files. That can be easier to process, search, keep > for a > > longer period etc. > > > > I haven't done it, but would it also mean that you'd get the "syslog" > data > recorded even if JES2 is down. I.e. when you are shutting down to IPL, > you > have a more complete record. > > > Correct. Plus: you have SDSF's Operlog features, like filter etc. etc. A nice set of enhancements over SYLOG. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSLOG and LOGR query
OK, I understand Allan's point about there being no benefit in using CFs with DASDONLY, but I'd put that consideration to one side since - as I say - I'm working with a MONOPLEX and so I don't expect to be sharing anything. I just want to make use of the facility. I've already put a fair amount of work in to gathering SMF data in a logstream and the result works fine - & is far easier to work with that the old-style MANx files IMHO. With regard to the OPERLOG, that is all the SYSLOGs that are being collected all in one place, right? Well, in my situation, I can't see any difference between the SDSF OPERLOG and the SDSF SYSLOG displays. Which makes sense to me. I've only got one source. Kees is right - I want to be able capitalise on the "...easier to process, search, keep for a longer period..." bits. I want to fully automate the collection of my SYSLOG in daily files. I've currently got a horrible kludgy set-up of REXX execs and ICEMAN stuff and manual interventions to do this. Having seen how much easier things were with the SMF data, I moved on to handling the SYSLOG in a similar manner. But I appear to have fallen in to a hole... Sean On 19 July 2018 at 14:22, John McKown wrote: > On Thu, Jul 19, 2018 at 8:20 AM Vernooij, Kees (ITOPT1) - KLM < > kees.verno...@klm.com> wrote: > > > He says he has a monoplex. > > The advantage is, that you het syslog data in the operlog logstream, > > i.s.o. Jes2 Sysout files. That can be easier to process, search, keep > for a > > longer period etc. > > > > I haven't done it, but would it also mean that you'd get the "syslog" data > recorded even if JES2 is down. I.e. when you are shutting down to IPL, you > have a more complete record. > > > > > > > Kees. > > > > -- > There is no such thing as the Cloud. It is just somebody else’s computer. > > Maranatha! <>< > John McKown > > -- > 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: SYSLOG and LOGR query
On Thu, Jul 19, 2018 at 8:20 AM Vernooij, Kees (ITOPT1) - KLM < kees.verno...@klm.com> wrote: > He says he has a monoplex. > The advantage is, that you het syslog data in the operlog logstream, > i.s.o. Jes2 Sysout files. That can be easier to process, search, keep for a > longer period etc. > I haven't done it, but would it also mean that you'd get the "syslog" data recorded even if JES2 is down. I.e. when you are shutting down to IPL, you have a more complete record. > > Kees. > -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSLOG and LOGR query
He says he has a monoplex. The advantage is, that you het syslog data in the operlog logstream, i.s.o. Jes2 Sysout files. That can be easier to process, search, keep for a longer period etc. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Allan Staller > Sent: 19 July, 2018 15:10 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SYSLOG and LOGR query > > DASD only logstreams cannot be shared. Architectural limitation. > > You can get operlog to work w/DASDONLY, but only for a single system. > There is no benefit to LOGR unless you have a CF. > > To save you the work, don't bother w/SMF or LOGREC logstreams either. > > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Sean Gleann > Sent: Thursday, July 19, 2018 8:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SYSLOG and LOGR query > > I'm trying to use a LOGR logstream to gather the SYSLOG data, but I > don't appear to be able to make it work... > I believe I've correctly followed all the instructions detailed in the > relevant section of the "z/OS System Logger" redbook. > Modifying the CFRM policy to add the OPERLOG structure, and then > defining the associated logstream all appears to have gone OK. For what > it's worth, I'm working with a system in MONOPLEX mode, so the logstream > is defined with DASDONLY(YES) specified. > My CONSOLxx member includes "HARDCOPY DEVNUM(OPERLOG) ROUTCODE(ALL) > CMDLEVEL(CMDS) HCFORMAT(CENTURY)", which I *think* is right but I'm not > absolutely certain. > Then to 'activate' the facility, I used the V OPERLOG,HARDCPY command - > which again I'm not absolutely certain of. > > Whenever I try to use the IEAMDBLG program, it either abends with a > U0001 or ends with message "MLG003I NORECORDS IN RANGE", depending on > the PARM that I use. > > Can anyone see anything wrong with my work here, please? > I can't be the only one trying to do this, so if any one out there can > help at all, I'd appreciate it mightily. > > Sean > > -- > 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 immediately. Before opening any email and/or > attachments, please check them for viruses and other defects. > > > > -- > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receip
Re: SYSLOG and LOGR query
" dasd only logstreams don't need a CF structure" - Agreed. However the logstream cannot be shared. If OPERLOG is established on 2 separate systems they cannot operate concurrently and use the same logstream, so what is the benefit? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Thursday, July 19, 2018 8:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSLOG and LOGR query 2 things that may help: - dasd only logstreams don't need a CF structure - you can browse the operlog via SDSF and the LOG O command. This way you can verify that Operlog works and you can concentrate on retrieving it. Grtn, Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Sean Gleann > Sent: 19 July, 2018 15:04 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SYSLOG and LOGR query > > I'm trying to use a LOGR logstream to gather the SYSLOG data, but I > don't appear to be able to make it work... > I believe I've correctly followed all the instructions detailed in the > relevant section of the "z/OS System Logger" redbook. > Modifying the CFRM policy to add the OPERLOG structure, and then > defining the associated logstream all appears to have gone OK. For > what it's worth, I'm working with a system in MONOPLEX mode, so the > logstream is defined with DASDONLY(YES) specified. > My CONSOLxx member includes "HARDCOPY DEVNUM(OPERLOG) ROUTCODE(ALL) > CMDLEVEL(CMDS) HCFORMAT(CENTURY)", which I *think* is right but I'm > not absolutely certain. > Then to 'activate' the facility, I used the V OPERLOG,HARDCPY command > - which again I'm not absolutely certain of. > > Whenever I try to use the IEAMDBLG program, it either abends with a > U0001 > or ends with message "MLG003I NORECORDS IN RANGE", depending on the > PARM that I use. > > Can anyone see anything wrong with my work here, please? > I can't be the only one trying to do this, so if any one out there can > help at all, I'd appreciate it mightily. > > Sean > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.com&data=02%7C01%7Callan.staller%40HCL.COM%7Ccb0b6feec2b94b41860008d5ed79540a%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636676027751948374&sdata=TVcpSz0coII7xiRjWb5u1WK3RTVIfktKdIjPGMiXKf0%3D&reserved=0. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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
Re: SYSLOG and LOGR query
2 things that may help: - dasd only logstreams don't need a CF structure - you can browse the operlog via SDSF and the LOG O command. This way you can verify that Operlog works and you can concentrate on retrieving it. Grtn, Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Sean Gleann > Sent: 19 July, 2018 15:04 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SYSLOG and LOGR query > > I'm trying to use a LOGR logstream to gather the SYSLOG data, but I > don't > appear to be able to make it work... > I believe I've correctly followed all the instructions detailed in the > relevant section of the "z/OS System Logger" redbook. > Modifying the CFRM policy to add the OPERLOG structure, and then > defining > the associated logstream all appears to have gone OK. For what it's > worth, > I'm working with a system in MONOPLEX mode, so the logstream is defined > with DASDONLY(YES) specified. > My CONSOLxx member includes "HARDCOPY DEVNUM(OPERLOG) ROUTCODE(ALL) > CMDLEVEL(CMDS) HCFORMAT(CENTURY)", which I *think* is right but I'm not > absolutely certain. > Then to 'activate' the facility, I used the V OPERLOG,HARDCPY command - > which again I'm not absolutely certain of. > > Whenever I try to use the IEAMDBLG program, it either abends with a > U0001 > or ends with message "MLG003I NORECORDS IN RANGE", depending on the PARM > that I use. > > Can anyone see anything wrong with my work here, please? > I can't be the only one trying to do this, so if any one out there can > help > at all, I'd appreciate it mightily. > > Sean > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSLOG and LOGR query
DASD only logstreams cannot be shared. Architectural limitation. You can get operlog to work w/DASDONLY, but only for a single system. There is no benefit to LOGR unless you have a CF. To save you the work, don't bother w/SMF or LOGREC logstreams either. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sean Gleann Sent: Thursday, July 19, 2018 8:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SYSLOG and LOGR query I'm trying to use a LOGR logstream to gather the SYSLOG data, but I don't appear to be able to make it work... I believe I've correctly followed all the instructions detailed in the relevant section of the "z/OS System Logger" redbook. Modifying the CFRM policy to add the OPERLOG structure, and then defining the associated logstream all appears to have gone OK. For what it's worth, I'm working with a system in MONOPLEX mode, so the logstream is defined with DASDONLY(YES) specified. My CONSOLxx member includes "HARDCOPY DEVNUM(OPERLOG) ROUTCODE(ALL) CMDLEVEL(CMDS) HCFORMAT(CENTURY)", which I *think* is right but I'm not absolutely certain. Then to 'activate' the facility, I used the V OPERLOG,HARDCPY command - which again I'm not absolutely certain of. Whenever I try to use the IEAMDBLG program, it either abends with a U0001 or ends with message "MLG003I NORECORDS IN RANGE", depending on the PARM that I use. Can anyone see anything wrong with my work here, please? I can't be the only one trying to do this, so if any one out there can help at all, I'd appreciate it mightily. Sean -- 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 immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SYSLOG and LOGR query
I'm trying to use a LOGR logstream to gather the SYSLOG data, but I don't appear to be able to make it work... I believe I've correctly followed all the instructions detailed in the relevant section of the "z/OS System Logger" redbook. Modifying the CFRM policy to add the OPERLOG structure, and then defining the associated logstream all appears to have gone OK. For what it's worth, I'm working with a system in MONOPLEX mode, so the logstream is defined with DASDONLY(YES) specified. My CONSOLxx member includes "HARDCOPY DEVNUM(OPERLOG) ROUTCODE(ALL) CMDLEVEL(CMDS) HCFORMAT(CENTURY)", which I *think* is right but I'm not absolutely certain. Then to 'activate' the facility, I used the V OPERLOG,HARDCPY command - which again I'm not absolutely certain of. Whenever I try to use the IEAMDBLG program, it either abends with a U0001 or ends with message "MLG003I NORECORDS IN RANGE", depending on the PARM that I use. Can anyone see anything wrong with my work here, please? I can't be the only one trying to do this, so if any one out there can help at all, I'd appreciate it mightily. Sean -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
> Problems: > 1. Undocumented requirement to quad-word align CPOOL anchor and/or extent > in 64-bit mode (and actually undocumented alignment requirements for all). > 2. Unable to guarantee quad-word alignment with malloc. I will get the first taken care of. The anchor does not need to be quad-word aligned. For the second, as has been pointed out in C syntax but I think not in words, you would do what everyone used to do prior to STARTBDY keyword of GETMAIN / STORAGE OBTAIN -- round the start address up to the necessary boundary, having gotten an additional 8 if you need the length to be some specific value (or 15 if you do are not guaranteed that the area will at least be on a doubleword boundary). The rounding is typically "Add 15, AND with -16". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Migration from DB2 V10 to V11
I'm pretty sure I hit the same problem. Silly question, but you do have the coexistence SPE on your system? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
