Re: SMF to capture user login history
In SDSF, &10 or &nn does the job - KB ‐‐‐ Original Message ‐‐‐ On Monday, October 26, 2020 12:17 AM, Tom Brennan wrote: > Reminds me of a co-worker who no matter what time day or night I would > happen to see his online Outlook status, his id was marked as online and > busy. Of course he had some kind of macro or hook running on his PC. > > On 10/24/2020 11:10 PM, kekronbekron wrote: > > > I hope no one encourages this kind of snooping on the list. > > Stinks of an attempt to police working hours. > > > > - KB > > > > ‐‐‐ Original Message ‐‐‐ > > On Sunday, October 25, 2020 11:37 AM, Jake Anderson > > justmainfra...@gmail.com wrote: > > > > > Hello > > > Cross posted. > > > We have a SMF data for some years and I would like to fetch a user's logon > > > history like when he was logged with all time intervals. > > > Is there a sample JCL or process you are following without having to use > > > any third party product to process. > > > Could someone please share any sample if you have and willing to share ? > > > Jake > > > > > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Of course, I'm just raising a point of being mindful of what the purpose of this may be. Heck, I wrote one myself a few years ago; good thing it wasn't used more than once (the initial test run lol). - KB ‐‐‐ Original Message ‐‐‐ On Sunday, October 25, 2020 8:18 PM, Seymour J Metz wrote: > There are legitimate reasons for that type of report. > > > --- > > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > kekronbekron [02dee3fcae33-dmarc-requ...@listserv.ua.edu] > Sent: Sunday, October 25, 2020 2:10 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Sunday, October 25, 2020 11:37 AM, Jake Anderson > justmainfra...@gmail.com wrote: > > > > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's logon > > history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to use > > any third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
On 26/10/2020 5:13 am, Charles Mills wrote: I *think* z/OS is now shipping header files for C/C++ for many SMF records. If not, EDCDSECT does a halfway decent job. (I know -- been there, done that, got the T-shirt.) There is someone I think who offers SMF layouts in Java, perhaps at no charge. Google might be your friend. EasySMF has SMF mappings in Java, but not at no charge. There is a lot more to it than just generating the layouts. E.g. each date and time field is available as the appropriate java.time type (up to nanosecond precision) i.e. you don't have to figure out the units. There are methods provided to extract the record sections. Some sample reports to demonstrate the use are available on Github: https://github.com/BlackHillSoftware/easysmf-samples -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
We did not usually see 1.0's for CICS logons. I think there is a caller ability to suppress cutting the record, or perhaps customers don't usually audit successful logons (?) so we found CICS logons to be basically hopeless. There is some other 1.nn that gets cut a lot but it happens on every transaction (?) so customers were reluctant to turn it on due to the volume. Working from two+ year old memory here. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hayim Sokolsky Sent: Sunday, October 25, 2020 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history User logon activity depends upon a combination of which logons you are talking about -and- which OEM security you use - RACF, Top Secret, or ACF2. TSO logon, job start (batch) and Started Task events are SMF type 20 or type 30. Anything else (CICS, Distributed DB2, IMS, etc…) is an SMF type 80 (event code 1 - RACINIT) cut by the security product itself. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
User logon activity depends upon a combination of which logons you are talking about -and- which OEM security you use - RACF, Top Secret, or ACF2. TSO logon, job start (batch) and Started Task events are SMF type 20 or type 30. Anything else (CICS, Distributed DB2, IMS, etc…) is an SMF type 80 (event code 1 - RACINIT) cut by the security product itself. Hayim > On Oct 25, 2020, at 16:36, Seymour J Metz wrote: > > Ouch! > > I meant type 80, but from what you say he may be SOL if he needs more than > TSO. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Charles Mills [charl...@mcn.org] > Sent: Sunday, October 25, 2020 4:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > I lived and breathed z/OS event monitoring via real-time SMF from 2010 to > 2018. CICS and most if not all session managers are pretty much hopeless. > Ditto end-user access to WebSphere, and Db2 if it is three-tier -- i.e., the > user logs onto Linux or Windows and a process there hits Db2. CICS cuts SMF > 110 records but not for logons. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Seymour J Metz > Sent: Sunday, October 25, 2020 12:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > I don't know that TSO is all that is of interest. What about, e.g., CICS, > NVAS, TPX? > > -- > 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: SMF to capture user login history
On Sun, 25 Oct 2020 19:21:24 +, Jesse 1 Robinson wrote: >I had that problem in a shop long ago. In defense of the 'perpetrators', if a >user got caught by timeout chopper, getting back on could be long and >difficult. The real culprit was lousy tuning and inadequate resources. The >resource problem eventually got solved by an upgrade. No users were harmed in >the process. > At one time our admin installed a timeout chopper for CMS users. He was generous and naive enough to provide a "two minute warning". The first time I was away from my desk long enough to miss that warning I installed a background process to trap the warning. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Ouch! I meant type 80, but from what you say he may be SOL if he needs more than TSO. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Sunday, October 25, 2020 4:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history I lived and breathed z/OS event monitoring via real-time SMF from 2010 to 2018. CICS and most if not all session managers are pretty much hopeless. Ditto end-user access to WebSphere, and Db2 if it is three-tier -- i.e., the user logs onto Linux or Windows and a process there hits Db2. CICS cuts SMF 110 records but not for logons. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Sunday, October 25, 2020 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history I don't know that TSO is all that is of interest. What about, e.g., CICS, NVAS, TPX? -- 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 to capture user login history
I lived and breathed z/OS event monitoring via real-time SMF from 2010 to 2018. CICS and most if not all session managers are pretty much hopeless. Ditto end-user access to WebSphere, and Db2 if it is three-tier -- i.e., the user logs onto Linux or Windows and a process there hits Db2. CICS cuts SMF 110 records but not for logons. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Sunday, October 25, 2020 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history I don't know that TSO is all that is of interest. What about, e.g., CICS, NVAS, TPX? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Some free SSL/TLS/Certificates education if you are interested
In case anyone is interested I am doing a free one-hour Webinar on the "internals" of the certificate and SSL/TLS protocols this coming Tuesday. I have absolutely nothing to sell you - this is not a pitch for some certificate-management package or anything like that. It is *NOT* "how to install a certificate in RACF" or similar. That's a good topic, but it's not this topic. It's a pure look at the protocol flow and so forth. It's independent of any particular security subsystem and actually not even really mainframe-specific - it's about the protocol flow, independent of the boxes it is running on. It's equally relevant to RACF, ACF2 and TSS, and for that matter equally relevant to Linux and Windows. I've done it at SHARE twice and for NewEra once and it was well-received. Hope you can join us. I think NewEra will automatically sign you up to be notified of future webinars. That's not a bad thing but it you don't like it I am sure they will honor an unsubscribe. Scroll down near the bottom here: https://www.newera-info.com/Month.html X-Posted IBM-MAIN, RACF-L, IBMVM and IBMTCP-L. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
I don't know that TSO is all that is of interest. What about, e.g., CICS, NVAS, TPX? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Sunday, October 25, 2020 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Trust me, necessary and sufficient for user TSO logon and logoff is SMF 30. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Sunday, October 25, 2020 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a small PL/I program to process the SMF data. The records to look at depend on the types of logon you're concerned with, "Note: IBM recommends that you use record type 30 rather than record types 4, 5, 20, 34, 35, and 40." You may also need type 70 (RMF). -- 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 to capture user login history
These days a lot of things depend on Unix System Services. You would need to do something to let them be dubbed. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Sunday, October 25, 2020 11:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Sun, 25 Oct 2020 15:07:20 +, Seymour J Metz wrote: >Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a >small PL/I program to process the SMF data. The records to look at depend on >the types of logon you're concerned with, > >"Note: IBM recommends that you use record type 30 rather than record types 4, >5, 20, 34, 35, and 40." You may also need type 70 (RMF). > Are there PL/I header files mapping SMF record types? C? Rexx? For Rexx, the ideal would be a facility similar to OMVS ADDRESS SYSCALL which returns not a storage object with mapped offsets but a compound symbol with a programmer-specified stem and tail values mapped by mnemonic SYSCALL_CONSTANTS. Is there (a range of) SMF record types reserved for ISVs? Or even a single type further distinguished by ISV-assigned component prefix? Is it possible to operate z/OS with neither RACF nor a competing product? I'd suspect many SAF calls would need to be stubbed. Data set passwords, UADS, etc.? -- gil -- 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 to capture user login history
I had that problem in a shop long ago. In defense of the 'perpetrators', if a user got caught by timeout chopper, getting back on could be long and difficult. The real culprit was lousy tuning and inadequate resources. The resource problem eventually got solved by an upgrade. No users were harmed in the process. . . 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 On Behalf Of Tom Brennan Sent: Sunday, October 25, 2020 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: SMF to capture user login history CAUTION EXTERNAL EMAIL Reminds me of a co-worker who no matter what time day or night I would happen to see his online Outlook status, his id was marked as online and busy. Of course he had some kind of macro or hook running on his PC. On 10/24/2020 11:10 PM, kekronbekron wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Sunday, October 25, 2020 11:37 AM, Jake Anderson > wrote: > >> Hello >> >> Cross posted. >> >> We have a SMF data for some years and I would like to fetch a user's >> logon history like when he was logged with all time intervals. >> >> Is there a sample JCL or process you are following without having to >> use any third party product to process. >> >> Could someone please share any sample if you have and willing to share ? >> >> Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Reminds me of a co-worker who no matter what time day or night I would happen to see his online Outlook status, his id was marked as online and busy. Of course he had some kind of macro or hook running on his PC. On 10/24/2020 11:10 PM, kekronbekron wrote: I hope no one encourages this kind of snooping on the list. Stinks of an attempt to police working hours. - KB ‐‐‐ Original Message ‐‐‐ On Sunday, October 25, 2020 11:37 AM, Jake Anderson wrote: Hello Cross posted. We have a SMF data for some years and I would like to fetch a user's logon history like when he was logged with all time intervals. Is there a sample JCL or process you are following without having to use any third party product to process. Could someone please share any sample if you have and willing to share ? Jake 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: SMF to capture user login history
I *think* z/OS is now shipping header files for C/C++ for many SMF records. If not, EDCDSECT does a halfway decent job. (I know -- been there, done that, got the T-shirt.) There is someone I think who offers SMF layouts in Java, perhaps at no charge. Google might be your friend. Yes, for "old" SMF records types 128 to 255 are reserved for non-IBM use. There is no official repository of who uses what, but Cheryl Watson has the best list I know of. Google is your friend. For the "new" SMF record format with 16-bit types, yes, there is a large range reserved for non-IBM but I do not have it memorized. Yes, I think it may be possible to run z/OS with no security subsystem but I doubt that anyone does so. Yes, you would need a SAF stub that always said "yes, go ahead, you have access" or perhaps made some very simplistic determination: GILMART is allowed to do anything; anyone else only gets read access to datasets unless they have their HLQ. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, October 25, 2020 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Sun, 25 Oct 2020 15:07:20 +, Seymour J Metz wrote: >Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a >small PL/I program to process the SMF data. The records to look at depend on >the types of logon you're concerned with, > >"Note: IBM recommends that you use record type 30 rather than record types 4, >5, 20, 34, 35, and 40." You may also need type 70 (RMF). > Are there PL/I header files mapping SMF record types? C? Rexx? For Rexx, the ideal would be a facility similar to OMVS ADDRESS SYSCALL which returns not a storage object with mapped offsets but a compound symbol with a programmer-specified stem and tail values mapped by mnemonic SYSCALL_CONSTANTS. Is there (a range of) SMF record types reserved for ISVs? Or even a single type further distinguished by ISV-assigned component prefix? Is it possible to operate z/OS with neither RACF nor a competing product? I'd suspect many SAF calls would need to be stubbed. Data set passwords, UADS, etc.? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
On Sun, 25 Oct 2020 15:07:20 +, Seymour J Metz wrote: >Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a >small PL/I program to process the SMF data. The records to look at depend on >the types of logon you're concerned with, > >"Note: IBM recommends that you use record type 30 rather than record types 4, >5, 20, 34, 35, and 40." You may also need type 70 (RMF). > Are there PL/I header files mapping SMF record types? C? Rexx? For Rexx, the ideal would be a facility similar to OMVS ADDRESS SYSCALL which returns not a storage object with mapped offsets but a compound symbol with a programmer-specified stem and tail values mapped by mnemonic SYSCALL_CONSTANTS. Is there (a range of) SMF record types reserved for ISVs? Or even a single type further distinguished by ISV-assigned component prefix? Is it possible to operate z/OS with neither RACF nor a competing product? I'd suspect many SAF calls would need to be stubbed. Data set passwords, UADS, etc.? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Trust me, necessary and sufficient for user TSO logon and logoff is SMF 30. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Sunday, October 25, 2020 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a small PL/I program to process the SMF data. The records to look at depend on the types of logon you're concerned with, "Note: IBM recommends that you use record type 30 rather than record types 4, 5, 20, 34, 35, and 40." You may also need type 70 (RMF). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Also assuming you run RACF, not either of the CA security products. IRRADU00 is technical not "free," it is a part of RACF. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Sunday, October 25, 2020 7:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Yes! Does a good job, again assuming you are collecting the relevant SMF 30 data. IRRADU00 contrary to what you might expect from the name processes SMF 30 as well as RACF SMF 80 (assuming I recall correctly). It solves the "section" problem that @Lizette alludes to. Its output IIRC is a file of huge fixed-layout records. I have never used it; this is from customer discussions and documentation-reading. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Saturday, October 24, 2020 11:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history The answer is IRRADU00 report - standard (free) RACF tool. Then you can write yoour own report. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a small PL/I program to process the SMF data. The records to look at depend on the types of logon you're concerned with, "Note: IBM recommends that you use record type 30 rather than record types 4, 5, 20, 34, 35, and 40." You may also need type 70 (RMF). -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jake Anderson [justmainfra...@gmail.com] Sent: Sunday, October 25, 2020 2:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF to capture user login history Hello Cross posted. We have a SMF data for some years and I would like to fetch a user's logon history like when he was logged with all time intervals. Is there a sample JCL or process you are following without having to use any third party product to process. Could someone please share any sample if you have and willing to share ? Jake -- 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 to capture user login history
There are legitimate reasons for that type of report. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of kekronbekron [02dee3fcae33-dmarc-requ...@listserv.ua.edu] Sent: Sunday, October 25, 2020 2:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history I hope no one encourages this kind of snooping on the list. Stinks of an attempt to police working hours. - KB ‐‐‐ Original Message ‐‐‐ On Sunday, October 25, 2020 11:37 AM, Jake Anderson wrote: > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's logon > history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to use > any third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > > > 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: SMF to capture user login history
It's as Piece of cake in PL/I, although the OS PL/I "optimizing" compiler generated truly ghastly code for unaligned bit strings. (Has that been fixed in Enterprise PL/I?) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Lizette Koehler [stars...@mindspring.com] Sent: Sunday, October 25, 2020 2:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Which SMF Records are you going to use? I would say in general without a 3rd part product (like SAS) it will be a challenge to parse through MOST SMF records without something that can handle the record section offsets Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jake Anderson Sent: Saturday, October 24, 2020 11:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF to capture user login history Hello Cross posted. We have a SMF data for some years and I would like to fetch a user's logon history like when he was logged with all time intervals. Is there a sample JCL or process you are following without having to use any third party product to process. Could someone please share any sample if you have and willing to share ? Jake -- 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: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
I vaguely recall that OS/360 had some Fxx system ABEND codes that did not indicate missing SVCs. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Sunday, October 25, 2020 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down BTW2: I even experienced F37 abend in the past. It was related to huge (at the time) Jaguar J1A tapes and good compression and ...problems in RMM. AFAIK I put over 6TB (terabytes) of uncompressed data on 300GB cart. Interesting. That completion code would not have been in correct IBM code (Fxx abends have indicated the non-availability of SVC xx, for as long as the SVC FLIH has existed, as far as I know). 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: SMF to capture user login history
Yes! Does a good job, again assuming you are collecting the relevant SMF 30 data. IRRADU00 contrary to what you might expect from the name processes SMF 30 as well as RACF SMF 80 (assuming I recall correctly). It solves the "section" problem that @Lizette alludes to. Its output IIRC is a file of huge fixed-layout records. I have never used it; this is from customer discussions and documentation-reading. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Saturday, October 24, 2020 11:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history The answer is IRRADU00 report - standard (free) RACF tool. Then you can write yoour own report. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
SMF 30 is sufficient to do this, assuming you have been capturing the start and end events of TSO sessions. There may be a CBT program to report on this; have you searched? It is not impossible to do it yourself with Rexx. @Lizette mentions the problem of SMF "sections." She's right, but it's not impossible. Here is the basic technique: GetSect: Procedure Expose Recd.1 Triplet = Arg(1) If Triplet = "" Then Return "" Num = C2D(Substr(Triplet, 7, 2)) If Num = 0 Then Return "" Len = C2D(Substr(Triplet, 5, 2)) If Len = 0 Then Return "" Off = C2D(Substr(Triplet, 1, 4)) If Off = 0 Then Return "" Return Substr(Recd.1, Off-3, Len) Then you can code, for example Section = GetSect(Substr(Recd.1, 29, 8)) SMF30JBN = Substr(Section, 1,8) Yes, as @KB more or less alluded to, what you propose may be frowned upon in some circles. This kind of reporting is forbidden (by law? by typical union contract?) in Germany (and perhaps elsewhere in the EU and other places?). It is prohibited to routinely process data that could be used to infer working hours. You can collect it, and process it in a specific investigation, but not routinely. (I am not a lawyer, much less a German labor law lawyer, so take what I write as a general hint, not exact legal advice.) This is all right in my wheelhouse because the program I wrote for CorreLog, zDefender, and which was acquired by BMC as AMI Defender, may be and is often used to do exactly what you describe. You use it in conjunction with a collection and reporting tool running on a "small system": either Splunk, or a "SIEM" such as IBM QRadar. I know you said "no third party" but this was a fairly mature market: nearly every shop has either Defender, or one of the two main competitors, IBM zSecure Audit or Syncsort Ironstream (and nearly every company in the world seems to be running Splunk). You might want to check whether your shop already has one of the three mainframe products I mention, and Splunk or a SIEM in your Security Operations Center. If you have one of the mainframe products already, but your organization does not give you access to Splunk, you can download it and run it "full-function" for free, provided only that you keep your data to under 500MB/day. Splunk is really powerful and really easy to use. (That's why everyone it seems runs it.) Yes, this assumes by "logged on" you refer to TSO. CICS does not generate SMF data equivalent to this, nor does IMS, nor do the session manager products AFAIK. If you have not been collecting SMF 30 TSO start and end events, then you may be able to get the logons from SMF 80, but not the log offs. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson Sent: Saturday, October 24, 2020 11:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF to capture user login history Hello Cross posted. We have a SMF data for some years and I would like to fetch a user's logon history like when he was logged with all time intervals. Is there a sample JCL or process you are following without having to use any third party product to process. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
> two sets of IDs Multiple ids can be very usefull. If you have a lot of privileges and write code that is supposed to work without those privileges, it's useful to have a bare bones userid. If you have work that requires privileges that you consider too dangerous for normal work, it's nice to have a more privileged userid and proxy permission. BTDT, GTTS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Horein [steve.hor...@gmail.com] Sent: Sunday, October 25, 2020 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > Meh. The first shop I worked in implemented something like that to track the use of privileged IDs that had elevated permissions to update production resources. At the time, the scope had been TSO, so I wrote some automation that would send an email to the "security operations center" if RACF IDs matching specific patterns generated an IEF125I, IEF126I, or an IEF45* message. The time frames from logon to logoff/abend needed to be justified with a change request or incident, otherwise it would be considered suspicious activity. Yes, it meant having to maintain two sets of IDs - a BAU ID for day to day work, and the privileged ID for changes or recovery support, but it satisfied someone's requirement. -- 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: emptying a PDS: was RE: [IBM-MAIN] getting XCFAS down
BTW2: I even experienced F37 abend in the past. It was related to huge (at the time) Jaguar J1A tapes and good compression and ...problems in RMM. AFAIK I put over 6TB (terabytes) of uncompressed data on 300GB cart. Interesting. That completion code would not have been in correct IBM code (Fxx abends have indicated the non-availability of SVC xx, for as long as the SVC FLIH has existed, as far as I know). 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: How can you change TCAS defaults using the TSOKEYxx PARMLIB member?
Yeah ... just start at /asm then scroll down in the list to TSO VTAM (IKT) and then to IKTCAS54. Joe On Sun, Oct 25, 2020 at 8:31 AM David Spiegel wrote: > Hi Joe, > I got 404 when I tried to click on the last 2 Links. > > Regards, > David > > On 2020-10-25 09:04, Joe Monk wrote: > > Hi Sam, > > > > Just a bit of background... > > > > If you go here : > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.stben.net%2Ffiles%2FMVS_3.8%2Fasm%2F&data=04%7C01%7C%7Cd3dac48eaa1d4215267b08d878e699c2%7C84df9e7fe9f640afb435%7C1%7C0%7C637392279102656730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v4lwbphN9UTToLQ7wK1xLpUcnmcl1LoWg2xzBCj%2F55s%3D&reserved=0 > you can find a > > mostly complete set of routines for MVS 3.8J. > > > > In there you will find: > > > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.stben.net%2Ffiles%2FMVS_3.8%2Fasm%2FTSO%2520VTAM%2520&data=04%7C01%7C%7Cd3dac48eaa1d4215267b08d878e699c2%7C84df9e7fe9f640afb435%7C1%7C0%7C637392279102656730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m7M0E033aXQvzIIC2HpbsFdSSA%2BW8Cf9R5wJC8pmjjE%3D&reserved=0(IKT)/ > which is the > > source code for TCAS... > > > > And in there you will find > > > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.stben.net%2Ffiles%2FMVS_3.8%2Fasm%2FTSO%2520VTAM%2520&data=04%7C01%7C%7Cd3dac48eaa1d4215267b08d878e699c2%7C84df9e7fe9f640afb435%7C1%7C0%7C637392279102656730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m7M0E033aXQvzIIC2HpbsFdSSA%2BW8Cf9R5wJC8pmjjE%3D&reserved=0(IKT)/IKTCAS54 > which is > > the TCAS parm processor. > > > > If you check the logic you will see that it checks for a ',' to know how > to > > continue or to stop processing keywords. This is why all the keywords > have > > to come first in the member :) > > > > Anyway, a little bit of trivia for you :) > > > > Joe > > > > On Sun, Oct 25, 2020 at 1:10 AM Sam Golob wrote: > > > >> Dear Folks, > >> > >> Thanks to Joe Monk for getting me the correct information. First > >> of all, the parameters, which have to be in "=" format, and not TSO > >> format with parentheses, must PRECEDE the comments, and all of them, > >> except the last one, have to be followed by a comma. For example: > >> > >> USERMAX=39, > >> > >> RECONLIM=1 > >> > >> which is written BEFORE the comments. > >> > >> ALSO, I bounced the TSO address space. > >> > >> The resulting SHOWTCAS display is: (CBT File 731 - > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cbttape.org%2F&data=04%7C01%7C%7Cd3dac48eaa1d4215267b08d878e699c2%7C84df9e7fe9f640afb435%7C1%7C0%7C637392279102656730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Wu5oJl7x%2BwzrijrM9%2BNzMDNJugmLYPnQIc93qHKcuw4%3D&reserved=0 > - > >> Updates page) > >> > >> SHOWTCAS - TERMINAL CONTROL ADDRESS SPACE - FIELDS > >> --- --- - -- > >> Display of Settings and Addresses having > >> to do with the TSOKEYxx PARMLIB member > >> at the beginning of the IKTTCAST macro > >>8-CHARACTER USERID SUPPORT IS: ON > >> TCAS ADDRESS: 00C2EDC8 > >> > >> addr fieldvalue explanation > >> -- --- > >> +0 TCASID TCAS Control block identifier > >> +4 TCASUSEC 0001 Number of active users - HEX > >> 1Number of active users - DEC > >> +6 TCASUMAX 0027 TSO Maxusers number - HEX > >> 39TSO Maxusers number - DEC > >> +8 TCASACBP ACB Password > >>+10 TCASRCON 0001 Reconnect time in minutes - HEX > >> 1Reconnect time in minutes - DEC > >>+12 TCASCLSZ 0084 Buffer Size - HEX > >>132Buffer Size - DEC > >>+14 TCASHBUF BB80 High Buffer Threshold - HEX > >> 48000High Buffer Threshold - DEC > >>+18 TCASLBUF 5DC0 Low Buffer Threshold - HEX > >> 24000Low Buffer Threshold - DEC > >>+1C TCASCRSZ 01E0 Screen Size - HEX > >>480Screen Size - DEC > >>+1E TCASCHNL 04 Maximum Chain Length - HEX > >> 4Maximum Chain Length - DEC > >>+1F TCASENGT 00 ENGTRANS Value 0-Base,1-Ext,2-None > >> > >>Thanks very much to all of you for your interest, and thanks, Joe > >> Monk, for the correct reply. > >> > >>All the best of everything to all
Re: How can you change TCAS defaults using the TSOKEYxx PARMLIB member?
Hi Joe,
I got 404 when I tried to click on the last 2 Links.
Regards,
David
On 2020-10-25 09:04, Joe Monk wrote:
Hi Sam,
Just a bit of background...
If you go here :
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.stben.net%2Ffiles%2FMVS_3.8%2Fasm%2F&data=04%7C01%7C%7Cd3dac48eaa1d4215267b08d878e699c2%7C84df9e7fe9f640afb435%7C1%7C0%7C637392279102656730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v4lwbphN9UTToLQ7wK1xLpUcnmcl1LoWg2xzBCj%2F55s%3D&reserved=0
you can find a
mostly complete set of routines for MVS 3.8J.
In there you will find:
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.stben.net%2Ffiles%2FMVS_3.8%2Fasm%2FTSO%2520VTAM%2520&data=04%7C01%7C%7Cd3dac48eaa1d4215267b08d878e699c2%7C84df9e7fe9f640afb435%7C1%7C0%7C637392279102656730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m7M0E033aXQvzIIC2HpbsFdSSA%2BW8Cf9R5wJC8pmjjE%3D&reserved=0(IKT)/
which is the
source code for TCAS...
And in there you will find
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.stben.net%2Ffiles%2FMVS_3.8%2Fasm%2FTSO%2520VTAM%2520&data=04%7C01%7C%7Cd3dac48eaa1d4215267b08d878e699c2%7C84df9e7fe9f640afb435%7C1%7C0%7C637392279102656730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m7M0E033aXQvzIIC2HpbsFdSSA%2BW8Cf9R5wJC8pmjjE%3D&reserved=0(IKT)/IKTCAS54
which is
the TCAS parm processor.
If you check the logic you will see that it checks for a ',' to know how to
continue or to stop processing keywords. This is why all the keywords have
to come first in the member :)
Anyway, a little bit of trivia for you :)
Joe
On Sun, Oct 25, 2020 at 1:10 AM Sam Golob wrote:
Dear Folks,
Thanks to Joe Monk for getting me the correct information. First
of all, the parameters, which have to be in "=" format, and not TSO
format with parentheses, must PRECEDE the comments, and all of them,
except the last one, have to be followed by a comma. For example:
USERMAX=39,
RECONLIM=1
which is written BEFORE the comments.
ALSO, I bounced the TSO address space.
The resulting SHOWTCAS display is: (CBT File 731 -
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cbttape.org%2F&data=04%7C01%7C%7Cd3dac48eaa1d4215267b08d878e699c2%7C84df9e7fe9f640afb435%7C1%7C0%7C637392279102656730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Wu5oJl7x%2BwzrijrM9%2BNzMDNJugmLYPnQIc93qHKcuw4%3D&reserved=0
-
Updates page)
SHOWTCAS - TERMINAL CONTROL ADDRESS SPACE - FIELDS
--- --- - --
Display of Settings and Addresses having
to do with the TSOKEYxx PARMLIB member
at the beginning of the IKTTCAST macro
8-CHARACTER USERID SUPPORT IS: ON
TCAS ADDRESS: 00C2EDC8
addr fieldvalue explanation
-- ---
+0 TCASID TCAS Control block identifier
+4 TCASUSEC 0001 Number of active users - HEX
1Number of active users - DEC
+6 TCASUMAX 0027 TSO Maxusers number - HEX
39TSO Maxusers number - DEC
+8 TCASACBP ACB Password
+10 TCASRCON 0001 Reconnect time in minutes - HEX
1Reconnect time in minutes - DEC
+12 TCASCLSZ 0084 Buffer Size - HEX
132Buffer Size - DEC
+14 TCASHBUF BB80 High Buffer Threshold - HEX
48000High Buffer Threshold - DEC
+18 TCASLBUF 5DC0 Low Buffer Threshold - HEX
24000Low Buffer Threshold - DEC
+1C TCASCRSZ 01E0 Screen Size - HEX
480Screen Size - DEC
+1E TCASCHNL 04 Maximum Chain Length - HEX
4Maximum Chain Length - DEC
+1F TCASENGT 00 ENGTRANS Value 0-Base,1-Ext,2-None
Thanks very much to all of you for your interest, and thanks, Joe
Monk, for the correct reply.
All the best of everything to all of you.
Sincerely, Sam
P.S. The SHOWTCAS command has an ALL parameter, which will display the
entire real contents (mostly addresses) in the IKTTCAST macro, with all
the correct values for your LPAR, below the settings which are displayed
here. I figured that most people don't want to see the whole thing.
They are just interested in the current settings. So ALL is not the
default.
--
For IBM-MAIN subscribe / signoff / archive access instr
Re: SMF to capture user login history
Nah. This is standard stuff required by auditors to provide artifacts for an audit. Not suspicious at all. Joe On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Sunday, October 25, 2020 11:37 AM, Jake Anderson < > justmainfra...@gmail.com> wrote: > > > Hello > > > > Cross posted. > > > > We have a SMF data for some years and I would like to fetch a user's > logon > > history like when he was logged with all time intervals. > > > > Is there a sample JCL or process you are following without having to use > > any third party product to process. > > > > Could someone please share any sample if you have and willing to share ? > > > > Jake > > > > > > > > > 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: How can you change TCAS defaults using the TSOKEYxx PARMLIB member?
Hi Sam, Just a bit of background... If you go here : http://www.stben.net/files/MVS_3.8/asm/ you can find a mostly complete set of routines for MVS 3.8J. In there you will find: http://www.stben.net/files/MVS_3.8/asm/TSO%20VTAM%20(IKT)/ which is the source code for TCAS... And in there you will find http://www.stben.net/files/MVS_3.8/asm/TSO%20VTAM%20(IKT)/IKTCAS54 which is the TCAS parm processor. If you check the logic you will see that it checks for a ',' to know how to continue or to stop processing keywords. This is why all the keywords have to come first in the member :) Anyway, a little bit of trivia for you :) Joe On Sun, Oct 25, 2020 at 1:10 AM Sam Golob wrote: > Dear Folks, > > Thanks to Joe Monk for getting me the correct information. First > of all, the parameters, which have to be in "=" format, and not TSO > format with parentheses, must PRECEDE the comments, and all of them, > except the last one, have to be followed by a comma. For example: > > USERMAX=39, > > RECONLIM=1 > > which is written BEFORE the comments. > > ALSO, I bounced the TSO address space. > > The resulting SHOWTCAS display is: (CBT File 731 - www.cbttape.org - > Updates page) > >SHOWTCAS - TERMINAL CONTROL ADDRESS SPACE - FIELDS > --- --- - -- >Display of Settings and Addresses having > to do with the TSOKEYxx PARMLIB member > at the beginning of the IKTTCAST macro > 8-CHARACTER USERID SUPPORT IS: ON > TCAS ADDRESS: 00C2EDC8 > > addr fieldvalue explanation > -- --- >+0 TCASID TCAS Control block identifier >+4 TCASUSEC 0001 Number of active users - HEX > 1Number of active users - DEC >+6 TCASUMAX 0027 TSO Maxusers number - HEX >39TSO Maxusers number - DEC >+8 TCASACBP ACB Password > +10 TCASRCON 0001 Reconnect time in minutes - HEX > 1Reconnect time in minutes - DEC > +12 TCASCLSZ 0084 Buffer Size - HEX > 132Buffer Size - DEC > +14 TCASHBUF BB80 High Buffer Threshold - HEX > 48000High Buffer Threshold - DEC > +18 TCASLBUF 5DC0 Low Buffer Threshold - HEX > 24000Low Buffer Threshold - DEC > +1C TCASCRSZ 01E0 Screen Size - HEX > 480Screen Size - DEC > +1E TCASCHNL 04 Maximum Chain Length - HEX > 4Maximum Chain Length - DEC > +1F TCASENGT 00 ENGTRANS Value 0-Base,1-Ext,2-None > > Thanks very much to all of you for your interest, and thanks, Joe > Monk, for the correct reply. > > All the best of everything to all of you. > > Sincerely, Sam > > P.S. The SHOWTCAS command has an ALL parameter, which will display the > entire real contents (mostly addresses) in the IKTTCAST macro, with all > the correct values for your LPAR, below the settings which are displayed > here. I figured that most people don't want to see the whole thing. > They are just interested in the current settings. So ALL is not the > default. > > > > -- > 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 to capture user login history
On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > Meh. The first shop I worked in implemented something like that to track the use of privileged IDs that had elevated permissions to update production resources. At the time, the scope had been TSO, so I wrote some automation that would send an email to the "security operations center" if RACF IDs matching specific patterns generated an IEF125I, IEF126I, or an IEF45* message. The time frames from logon to logoff/abend needed to be justified with a change request or incident, otherwise it would be considered suspicious activity. Yes, it meant having to maintain two sets of IDs - a BAU ID for day to day work, and the privileged ID for changes or recovery support, but it satisfied someone's requirement. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Logon to what? Just TSO, or a session manager like TPX? Logon to CICS, IMS, Websphere, MQ, etc. ? And what about logoff -- are you looking for logon duration, or whether a particular user could have initiated some system or application action at a certain time? There are literally dozens of different data sources for these metrics, so how to do it depends upon whether close counts? A very imprecise answer is from an ESM report like IRRADU00 , while a 100% correct answer becomes very difficult to achieve and may require more than SMF data. On Sun, Oct 25, 2020 at 5:08 PM Jake Anderson wrote: > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's logon > history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to use > any third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > -- > 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
