Tom's E-SRF Event Reporting Release 2.1 Sample Reports

Home Page - Click on your desired topic link

E-SRF Event Reporting is part of the EKC E-SRF Security Reporting Facility system product.
For information on obtaining this product, please click on EKC's link (below):

Link to: EKC, Inc. WEB Site
Link to: IBM Global Solutions Website

E-SRF consists of two components: Event and Access Analysis reporting.

  • Access Analysis focuses on "what could happen."
  • Event focuses on "what actually happened".

    There is information contained on this site about Access Analysis, but its main focus is on Event Reporting.

    Information contained on this site reflects my personal experiences with this product.
    EKC, Inc. is the only authorized authority on this product.

    E-SRF Event Reporting is available as Release 2.1.
    (Build: LE00450) at maintenance level: LE21029 (April 2006 rollup)

    Website Contents:

    Event Reporting Information and Sample Reports

  • Issues relating to MC, RM and UM objects
  • COLD and UPDATE Job sample SYSPRINT output
  • How our sample event reports were produced
  • Specific Report Overlays (canned)
  • ESRFLIST Reports (Utility Report Overlay)
  • Control Reports (used to administer Event Reporting)
  • Reports that will help you set up your grouping structure
  • Event Report Distribution

    Access Analysis Reporting Information

  • Sample Access Analysis JCL and Output from a very small test RACF system

    EKC's E-SRF Security Reporting Facility Release 2.1 distribution documentation

  • EVENT Reporting Release 2.1 product documentation
  • Access Analysis Reporting Release 2.1 product documentation

    Event Reporting Information and Sample Reports

    D-I-S-C-L-A-I-M-E-R !!!

    • Our purpose was to sample what the E-SRF Event Reports look like and what they can contain.
    • The systems used for our samples are development test systems that do not host any type of production processing.
    • RACF and ACF2 system extensions are developed on these systems that may modify their security databases.
    • Because they are ACF2/RACF development test systems, it is possible and probable that errors may be contaned on their security databases.
    • The data also reflects what a bunch of developers would have in their sandbox test system... very little useful data for reporting.
    • It appears nobody is willing to allow their production (or even test) security journals to be displayed as samples like this.
    • If you are willing, please email me.
    • Thank you for your patience and understanding in this matter.

    Starting in Release 2.1, you have the ability to write reports to a Variable Length (RECFM=VB) dataset in the following formats:

    • Standard printing (as in previous releases).
    • HTML format using the CTLCHAR(HTML) RUN parameter.
    • ASCII format (complete with ASCII print control characters) using the CTLCHAR(ASCII) RUN parameter.

    We ran some selected reports with Release 2.1 GA (General Availability), using the CTLCHAR(HTML) RUN parameter.
    The output was in 'EBCDIC' format (which enables its use on the mainframe computer).

    The reports were downloaded from the mainframe computer in ASCII format and ported directly to our WEB site.
    (Using IND$FILE with "CR+LF" attributes) from a TSO 3270 emulation session.
    The WEB site is x686 based and runs Apache 2.0.

    They are now sitting on the WEB site unaltered from their downloads.
    We tested the results using Microsoft IE 6.0 (running on Windows/2000 SP4).

    Some things to consider:

    1. E-SRF Event Reports can be quite large.
    2. The Masterfile used to produce these samples was established for test purposes.
      It is quite small compared to what a production facility would have.
    3. The security data used to update the Masterfile are real loggings from ACF2,
      but is test data from the product development facility.
      We cannot use "real" security data on a WEB site like this.
    4. If you run RACF, the reports would look 99.9 percent identical.
      In fact, you can mix RACF and ACF2 images on the same Masterfile and reports.
    5. The raw data used for the Update Function consisted of random "pickings" of SMF data across four years.
    6. The Update Function runs much faster in 2.1 than in previous releases.
    7. There is quite a bit of parameterization that may be applied to E-SRF Event reports.
      (For our samples, we ran with the most basic options).
    8. Additionally, we did not do any date scoping... you would normally not run this way.
      You would scope your reports for a certain date/time period.
    9. The current "shelf" release of E-SRF Event Reporting is: 2.1 (at level LE00450).
      Release 2.1 is now Generally Available (GA).
    10. With rare exception, these reports look the same as they did in Release 1.6.
    11. If you have long resource names, they will be displayed. If they do not fit on the report,
      they are right truncated with footnotes to the fully formatted name at the end of the report.

    Issues relating to the Resource Maintenance (RM) and User maintenance (UM) Objects:

    Starting in Release 2.1, these two objects are mapped identically.

    This means the object field structure is the same.

    The data contained in the fields is still limited to what is available from the RSS producing the loggings.

    This should not present a problem to most of us.

    Issues relating to the Maintenance Chronologoical (MC) Object:

    Starting in Release 2.1, the MC object no longer exists physically on the Masterfile.

    Not to worry, the object still exists as a "Virtual Object.

    The MC object has a new formal which looks exactly like the RM/UM objects.
    (This is because the data is actually made up of the RM and UM objects).

    This was done to address Masterfile performance, space issues and to allow you to produce full maintenance reports using the MC object identifier.

    In releases prior to 2.1, userid maintenance reported on the MC object had some extra event postings that were written out in error.

    These records never hurt anyone, but made the report hard to understand.
    In release 2.1, these "rogue" events are no longer posted.
    This means your MC reporting for userids may be smaller than what you had in prior releases.

    If you want a report using the MC object that looks like a previous release,
    add the following criteria to your RUN command:

              WHEN(MC.DATANAME LE ' ')      -
                OR(MC.DATANAME EQ RULE)     -
                OR(MC.DATANAME EQ PROFILE)  -
                OR(MC.DATANAME EQ SYSTEM)   -
                OR(MC.DATANAME MATCH +-)    -
                OR(MC.DATANAME EQ ACCESS)   -
                OR(MC.DATANAME EQ ID)       -

    If you want to report on RESOURCES only, you should use the RM object instead of the MC object.

    If you want to report on USERIDS only, you should use the UM object instead of the MC object.

    If you use MC, all Maintenance Objects are processed, this means RM and UM objects.
    This would require processing just about the entire Masterfile.
    This will give you what you want, but result in a waste of resources when only Resource or Userid Maintenance is required in a report.

    Remember, this is where the data comes from. You reports will run faster this way.
    The only real reason to use the MC object in release 2.1 is to run maintenance reports that include both RESOURCES and USERIDS.

    Ability to "relate" to the "changer's" userid:

    Starting in Release 2.1 (with LE21026 applied), when using the MC/RM/UM objects you can relate to the changer's userid.
    You simply specify a C. in front of the field you want to relate.
    For example you want to report the changer's name on the report, specify: C.NAME instead of just NAME.
    If you want to report on a changer's particular RSS field, place the C. in front ot the full field name: C.ACF2.NON-CNCL
    This works for any field in the User Header that you want to relate to.
    This applies to anywhere a dictionary field would be used with these objects.

    COLD and UPDATE Job sample SYSPRINT output

    To get reports out of ESRF, you need a Masterfile:
  • The Masterfile is a special VSAM cluster that is used to store your logged security data.
  • You must define your Cluster as per the instructions in the Dictionary and Masterfile Reference.
  • You then run a COLD job it provision the Cluster so it may be used as an ESRF Event Reporting Masterfile.
  • Now you run updates with the SMF (MVS system Journal file) data that your security system provided.

    The following links are sample SYSPRINT outputs from the COLD and an UPDATE run:

    JCL to run a Masterfile Update for a small ACF2 system

  • SYSPRINT (Update Control Report)

    JCL to COLD Start an E-SRF Event Reporting Masterfile using a small ACF2 system

  • SYSPRINT (Update Control Report)

    How our sample event reports were produced

    Reports were produced in a single run with the 'IEBUPDTE' option set using CTLCHAR(HTML).
    The rendered file was downloaded to a PC Workstation using IND$FILE (with ASCII CR/LF) set.
    The file was post processed on the workstation using a program that create individuel files based on 'IEBUPDTE' tags.
    The collection of individual files were transferred to the Web server so you can see them on thisd site.

    JCL to run our sample reports

    Specific Report Overlays (canned)

    Canned Report Overlays were designed and formatted for very specific purposes.
    You do have the ability to select the data you wish to report on, and in some cases add additional fields.
    However, you cannot alter their format.

  • ESRFRDRE (Ranked Daily Resource Events)
  • ESRFRDUE (Ranked Daily User Events)
  • ESRFRDRV (Ranked Daily Resource Violations)
  • ESRFRDUV (Ranked Daily User Violations)
  • ESRFRLR (Ranked Security Loggings by Resource)
  • ESRFRLU (Ranked Security Loggings by User)
  • ESRFRVR (Ranked Security Violations by Resource)
  • ESRFRVU (Ranked Security Violations by User)
  • ESRFUVLR (Userid Violations/Loggings Summary by Resource)
  • ESRFRUSE (Ranked User Signon Errors)
  • ESRFVLCS (Count of Violations/Loggings Summary by Class)
  • ESRFUVLC (Count of Violations/loggings by Userid)

  • ESRFRSSE (Ranked Source Signon Errors)

    • ESRFLIST Reports (Utility Report Overlay)

    There is almost no limit to the number of different reports you can create with ESRFLIST.
    Below is what we have, we will create and add additional samples soon... Stay Tuned!

  • Maintenance Chronological Detail Listing (new)
  • User Header Sample Listing
  • Maintenance Chronological (emulated to look like 1.6)
  • User Security Administrator's Activity Summary
  • User Signon Chronological Listing
  • Resource Chronological Detail Listing
  • User Chronological Detail Listing
  • Resource Maintenance Detail Listing
  • User Maintenance Detail Listing
  • Resource Recap Summary Report
  • User Recap Summary Report
  • Resource Statistical Summary Report
  • User Statistical Summary Report

    • Control Reports (used to administer Event Reporting)

    These reports are privided to help you configure administer the Event Reporting System.
    Normally, end users would not have any use for them.

  • ESRFDICT (Display Masterfile Data Dictionary)
  • ESRFKEYS (RESOURCE Segment KEY Listing)
  • ESRFSHOW (Show Current System Options)
  • ESRFKEYS (SOURCE Segment KEY Listing)
  • ESRFSTAT (Current Masterfile Object Statistics)
  • ESRFKEYS (USER Segment KEY Listing)

    • Reports that will help you set up your grouping structure

    Before looking at these reports, please review the points below:
    1. The Grouping Structure on our test system is primitive.
    2. It will however support a full distributed reporting system.
    3. There are two ways to group datasets in Event Reporting.
    4. We could have used dataset grouping rules (this is the default).
    5. We also could have considered datasets to be "resources" and set them up as a single RESOURCE CLASS.
    6. For simplicity in writing our grouping rules, we chose the latter option.
    7. We set the following option: SET DATASET(DATASET) and used Resource Grouping Rules.

  • ESRFGRPS (Group Control Structures Report)
  • ESRFGRPT (Group Selection Template)
  • ESRFGRPV (Grouping Structures Verification Report)
  • ESRFGRPX (Display External Grouping Scheme)>
  • ESRFOWNX (Owner/Group Reference Listing)

    ESRFGRPT is very useful to test report production involving Group and Owner selections.
    Our example had no selections that rendered a full list of all grouped entities on the Masterfile.

    Event Report Distribution

    E-SRF Event Reporting contains a very comprehensive Report Distribution Facility that OPTIONALLY may be used.
    Report distribution is the "Jewel" of this product and is what sets it apart from other reporting tools.

    The above reports were all run as Undistributed Reports.
    If we were to add the DIST(OWNER) RUN parameter to our report execution:

  • The exact same reports would have been produced, except:
  • We would create individual reports for EACH OWNER containing only their data.

    Each Owner would only see data related to the "GROUPS" that the OWNER either "owns" or is an Interested Party to.

    Access Analysis Reporting Information

    Access Analysis reporting provides you with reports showing who COULD access your resources.
  • The question "who can get to my resources?" is answered.
  • The question "what resources are my users able to access? is also answered.

    In contrast to Event Reporting, there is a separate product for ACF2 and RACF.
    There is no "Masterfile" involved.
    Access Analysis is a "point" product, run on demand to answer audit questions.

    Be careful how you run these reports.
    The entire security configuration is examined for every resource (and the set of users) you query on.
    These reports have the potential to require great amounts of CPU resources to produce.
    No stone is left unturned.

    The larger the set of target resources and set of users queried, the more resources are consumed.

    Event Reporting had some of these issues in the past and most were addressed by EKC development.
    Development effort has now shifted back to Access Analysis to make that an even better product.

    Sample Access Analysis JCL and Output from a very small test RACF system:

    D-I-S-C-L-A-I-M-E-R !!!

    • Our purpose was to sample what the E-SRF Event Reports look like and what they can contain.
    • The systems used for our samples are development test systems that do not host any type of production processing.
    • RACF and ACF2 system extensions are developed on these systems that may modify their security databases.
    • Because they are ACF2/RACF development test systems, it is possible and probable that errors may be contaned on their security databases.
    • The data also reflects what a bunch of developers would have in their sandbox test system... very little useful data for reporting.
    • It appears nobody is willing to allow their production (or even test) security journals to be displayed as samples like this.
    • If you are willing, please email me.
    • Thank you for your patience and understanding in this matter.

    We ran some Access Analysis reports using the ESRFHTML utility to create HTML output so they can be available on this site.
    The sample JCL is exactly what was run, including the step to create the HTML output.

    Preparation Samples:

    JCL to run EKCRXCAT -- Acquire dataset names from the System Catalog

  • SYSPRINT (control report)
  • CATALOGS (DASD option set)
  • DSNAMES (list of Dataset Names)

    JCL to run EKCRRCDB -- Build RACF Access Analysis VSAM Cluster

  • SYSPRINT (control report)

    JCL to run EKCRRPSD -- Run Pseudo Dataset/Resource Name Generator

  • SYSPRINT (control report)
  • DSNAMES (list of Pseudo Dataset Names)
  • RSNAMES (list of Pseudo Resource Class/Names)

    DataOwner Report samples:

    JCL to run EKCRRDDS -- Run DataOwner DATASET Report using RXCAT input

  • SYSPRINT (analysis report)

    JCL to run EKCRRDDS -- Run DataOwner DATASET Report using Pseudo Dataset Names

  • SYSPRINT (analysis report)

    JCL to run EKCRRDRS -- Run DataOwner RESOURCE Report using Pseudo Dataset Names

  • SYSPRINT (analysis report)

    UseridOwner Report samples:

    JCL to run EKCRRUDS -- Run UseridOwner DATASET Report using RXCAT input

  • SYSPRINT (DETAIL analysis report)
  • SYSPRINT (SUMMARY analysis report)

    JCL to run EKCRRUDS -- Run UseridOwner DATASET Report using Pseudo Dataset Names

  • SYSPRINT (analysis report)

    JCL to run EKCRUDRS -- Run UseridOwner RESOURCE Report using Pseudo Dataset Names

  • SYSPRINT (analysis report)

    E-SRF Product Documentation

    EKC's E-SRF Security Reporting Facility Release 2.1 distribution documentation

    Cover Letter
    EKC Doc Upgrade Notice for GA LE00450
    EKC Grouping Facility
    EKC ESRF Installation Guide

    EVENT Reporting Release 2.1 product documentation

    Change Summary
    Command Reference
    Masterfile and Data Dictionary Reference
    Messages and Codes
    Report Overlays Guide
    User Guide

    Access Analysis Reporting Release 2.1 product documentation

    Introduction to Access Analysis
    Access Analysis for ACF2
    Access Analysis for RACF

    Last Update: Friday, May 25, 2006
    Copyright © 2004-2006 www.event.tec.dyndns.org
    Site Email Contact: