Micro Focus Enterprise Analyzer

The Micro Focus Enterprise Analyzer (EA) is a tool that allows you to track your configuration items (CI’s) on the mainframe. We use it to provide an inventory of all CI’s we use so we can use the information for one of our projects.

Our Requirements

1. Keep an inventory of all configuration items (ie JCL, PROC, Programs, Copybooks, data cards, IMS and CICS transactions, DB2 databases and tables, etc) used on the mainframe.
2. Provide reports that show how each of these components are related (ie. what PROCs, Programs, files are used by a Job or what INCLUDE members are used by PL/1 programs or what programs use a specific COPYBOOK, etc).
3. Show the job flow diagram of an ESP schedule.
4. Identify any CI’s that have not been included in the repository.

How Enterprise Analyzer Addressed our Requirements

1. Once the CI’s are loaded to the repository, EA allows us to search for specific CI’s we need to find.
2. EA also provides reports that show how each CI is related to another CI. We can display for example, all programs and PROCs used within a job. We can also show what INCLUDE members are used by a PL/1 program. This can be seen immediately from the navigation panel. You can also produce reports for CI’s used by multiple jobs.
3. With regards to the job flow diagram from an ESP schedule, this is a special add-on that allows us to map how each jobs are executed on a schedule. This is quite helpful for new members of the team or to get an idea of predecessor or successor jobs.
4. In doing an inventory, it is important to make sure all CI’s are included in the repository. This is where the tool shines. You can produce a report that shows what CI’s are still not in the repository. From this report, you can then look for the CI on the mainframe. This feature has shown us several CI’s that we did not know even existed.THIS ARTICLE IS COPYRIGHTED. IF YOU CAN SEE THIS, THE ONE WHO POSTED THIS STOLE MY WORK

Things to Consider in Initial Setup

Much as the product meets our requirements, there are some things to consider in setting up the tool. Some of these are not specific to the tool but with the process in general. As in any product, the set up was the most difficult.

1. Searching for ALL CI’s on the mainframe was quite tedious because it requires displaying and going through the mainframe data sets and identifying which ones are relevant. This is not the fault of the tool, but is something that will happen whatever tool is used.
2. The CI’s need to have the right extensions to identify what they are. The consultant we hired had tools to do this but I would imagine it being a nightmare if we were to do this manually. To think that if a PDS has members of different file types (ie one PDS that contains COBOL and PL/1 programs), this will require a tool to scan through the files and guess what type of files they are.
3. Structuring the folders within the repository is also tricky. We had the benefit of a consultant who guided us through the process and this helped us save a lot of trial and error in defining the folders.
4. System programs and PROCs need to be defined in the repository so it will know that it should not search for the source code.
5. Verifying the codes was quite tedious. This is again, not a problem with the tool, but is part of the set up. Once we had loaded the repository, we verified the CI’s and of course, found some missing CI’s. We had to search for these and load them to the repository. In the process, we have found some CI’s that we thought were not being used or existed.
6. Setting up the Search Path for each project can be quite tricky. One thing we discovered is when a user changes the path of the Project, this change is not reflected as an option for the other users.