What's New in File-AID 16.03

Editor's Notes

• #6: Hypothetical Example # 1. File-AID/MVS - Progressive releases in both 2015 and 2016. Classic Release of File-AID/MVS, 10.02, released November of 2014, stays supported until end of December 2017. Cumulative Maintenance consists of bug fixes and currency only. Progressive Release 16.03 is introduced at the beginning of the third quarter, July, 2015. Since 16 is 1 above the current year, that immediately designates it as “next years” release. The 03 indicates its original “manufacturing date”: third quarter. Release 16.03 now stays at 16.03 for the rest of its life. New functionality may be delivered in 2015, while it is still a Progressive Release, but the 16.03 will never change. At the beginning of 2016, this becomes a Classic Release, and is supported for a minimum of three years. There’s no change to the support policy. In 2016, Release 17.02 gets released in the second quarter (April). Again, the 17 signifies “next years” release, and the 02 is the manufacturing date. New functionality may be introduced in subsequent quarters in 2016, and then it becomes a Classic Release on Jan. 1st, 2017. Note: Once a product is released, it’s VV.RR never changes. This would require additional work in the lab and issuance of new licenses for the customers.
• #19: We made a number of enhancements to the File-AID MVS and File-AID/RDX products, 19 of them to be exact. Due to time issues I’m going to be discussing three of them that I feel might be beneficial to a lot of File-AID users: 64-Bit Memory Edit – The removal of Windowed editing. Compare enhancements targeted to allow File-Aid customers to replace other Compare utilities. Multi-file support in option 3.6, Search/Update. Lets look>
• #20: Here’s a brief history of Windowed Browse/Edit. Many years ago customers started requesting a way to edit very large files. Technology limited us on what we could fit into memory. We came up with a solution that involved just reading the necessary amount of records into memory, and we called this Windowed Browse/Edit. This technique brought about several restrictions, one of these restrictions was the limited file types that were supported. Technology has progressed, and file sizes have grown. With 16.03 we are getting rid of Windowed editing and taking advantage of 64-Bit memory. Many of the previous restrictions are now lifted including file type access. For example we can now access very large ESDS, RRDS, and PDS type files. Let’s show you the difference….
• #21: Notice in this chart that I have three columns of file types across the top. Down the side I have some commonly used edit commands. For KSDS Large files the removal of Windowed Edit and use of 64-Bit memory removes restrictions and makes it look just like standard edit of a smaller file. For Sequential Large Files, 64-Bit memory removes all sorts of restrictions, and now allows us to perform the commands listed on the chart. For these other Large file types, we now support them where before we couldn’t edit or browse them at all.
• #22: Here’s a few other frequently used commands that now work the same regardless of the file size. Lets take a look at the product for a comparison.
• #23: We’ll start in version 10.2 which is our GA Classic release. Most of you have either 10.2, 10.1, or something earlier.
• #24: We’ll start by editing a very large sequential file without selection criteria,
• #25: In 10.2 we get this attractive Windowed Edit Specification Screen. And it asks us to make an edit method choice at the bottom of the screen. Here we choose to try and load it.
• #26: No luck with that. Lets try again.
• #27: This time we’ll choose windowing. Notice that certain commands are not available.
• #28: You can see here that we are in edit but we don’t have line numbers. I’m typing in some lables .A and .B to illustrate some commands.
• #29: Here we are doing a FIND on “obert” just within the labels.
• #30: Windowed Edit can’t handle this.
• #31: Same for Change.
• #32: Now let’s look at 16.03, our GA Progressive release.
• #33: Same file in edit.
• #34: This time our screen looks just like standard Edit. Note the 64-Bit message in the right hand corner.
• #35: Now, issuing a CHANGE command with my labels…
• #36: It works as it would in standard edit. This is just one example. By taking advantage of 64-Bit memory, we now have the ability to edit very large files in the same manner we edit smaller ones. Lets move on to Compare….
• #38: I’m going to illustrate two of the Compare enhancements we added to 16.03 to help customers replace a leading Compare tool. There were other Compare enhancements, but these two were the most impactful in allowing customers to replace another vendors tool. Compare now provides a new standard report option to reduce the number of lines in an unformatted compare. Blank lines and duplicate information have been eliminated. For an Unformatted COMPARE, fields can now be chosen for compare implicitly by "Excluding" non-compare fields. This makes COMPARE easier to use when only a few fields are non-compare fields.
• #39: The first enhancement we’ll discuss is a new “Reduced” report Format. This significantly reduces the amount of output sent to your report, and makes larger compares much faster. We’ll start by showing the existing standard report first. Here we will compare unformatted and supply one of the files to Compare.
• #40: Here’s the file we are comparing it to. It’s got some difference.
• #41: We’ll choose online processing with selection criteria.
• #42: And we’ll choose to modify the print defaults.
• #43: Here we choose our print defaults.
• #44: And we’ll choose the STANDARD report style. Notice there is a new option in the OLD/NEW Print Sequence called REDUCED that we’ll see shortly.
• #45: I’m going to perform a full record compare telling File-AID to use the 1st 5 bytes to sync the records
• #46: Standard Alternating report   Matched records Positions cut into 100 byte sections Shows the old record with a blank lines between each data line
• #47: Changed records Shows OLD then a line to underline the change, then the new and a line to underline the change Then it shows the old and new matched bytes with blank lines between
• #48: Inserted records/ Deleted NEW only if inserted with blank lines OLD only if deleted with blank lines
• #49: In this very small compare (4 records per file), we get 164 LINES IN THIS REPORT.
• #50: The enhancement request was to reduce the number of lines in the compare report. We added a new reporting option to the Standard type report. This is called a “reduced” report. Start compare again everything the same until HERE. The new report format is REDUCED and is only valid for standard report type.
• #51: Matched Records Positions cut into 100 byte sections Shows the old record with NO blank lines between each data line No need to show the matched records which would reduce the size of the report
• #52: Changed records Shows OLD and NEW records then a line to underline the change Then it shows BOTH for all the 100 byte sections that match with no blank lines
• #53: Inserted records/ Deleted NEW only if inserted without blank lines OLD only if deleted without blank lines
• #54: Point out that report is now 115 lines for the same compare (old way was 164) And that’s with only comparing 4 records. Consider the lines saved if the file had a million records or more? Now let’s talk about another enhancement. EXCLUDE processing,
• #55: The request -- In File-AID unformatted compare fields all the fields that the user wanted to include in the compare were selected using the “C” line command Lets do a Compare without using the new Exclude processing.
• #56: Here we are doing a Standard report with a Grouped Print Sequence.
• #57: In this example I know that I want to compare 2 datasets but I don’t want to include bytes 35, 210-212 or 410-412.   So currently I have to do lots of math to tell File-AID compare which fields I do want to compare. Now, if you enjoy solving dumps without Abend-AID, then this may be how you enjoy setting up COMPARE’s. Not me!
• #58: The new way of doing it also allows me to EXCLUDE if I prefer rather than have to do an INCLUSIVE COMPARE. Using the new X line command. When a X line command is used the fields that File-AID compares are everything EXCEPT for the excluded bytes. Here’s the same comparison using EXCLUDES This is my kind of math!
• #59: Here we can see that the records are considered match even though some of the bytes differ. We excluded those bytes.
• #60: Currently Option 3.6 Search/Update allows me to Search update of a dataset. Including the capability to search update across all or selected members of a PDS/E. This is great but our customers have asked us to expand the capability to multiple datasets simultaneously. Let’s look…..
• #61: Here I’m actually in File-AID release 10.1 and I’m using a wildcard in the dataset name to show me a list of datasets.
• #62: I Want a list of all the PROGRAMS THAT reference the COBOL field NAMED SIDE-A, so I start by selecting a dataset to search. Notice that I have other Source Libraries I may want to search as well, but I can only select them one at a time. 
• #63: I AM ABLE TO SEARCH THE ENTIRE PDS FOR side-a HOWEVER THEN I HAVE TO GO BACK AND DO THE SEARCH AGAIN ON ALL SOURCE AND INCLUDE DATASETS one at a time.
• #64: With File-AID 16.3, New functionality in F.3.6 allows selection of multiple datasets from the pattern dataset list. All dataset types that are currently supported in F.3.6 can be selected for processing together. This means you can search and update for example a KSDS, QSAM and PDSE at the same time. In this example I need to change area code 408 to 917 if in positions 179 or 189
• #65: Notice the use block and single command at one time.
• #66: Exclude line commands helps us trim the dataset to the ones we want. Notice the file types selected.
• #68: PDS Processing options panel is displayed for each PDS and PDSE selected allowing all members or selected members to be included in the search update.
• #70: This 1st selection criteria screen is a powerful way of limiting the update . Supplying a starting point within the file Number of records to search Number of records to select Etc For the purposes of this demo we will move forward with the defaults which will search and apply any updates to the entire dataset.
• #71: Here we enter unformatted field selection criteria for the update.
• #72: Describe the message Input datasets = the number of datasets selected from the pattern dataset list Selected datasets = the number of datasets that contained at least one hit Error datasets = If a dataset was selected that resulted in an i/o error for example. That file would be skipped and the next in the list processed Empty datasets = These are listed separately and is for informational purposes. We do not consider this an error. Records read = Total read from all selected datasets Selected = number of records that met the selection criteria Error records skipped = The records from each dataset are separated by the Opened message. If any of the datasets that contain hits are pds/E then there is an additional information record showing the member name followed by it’s records
• #73: Show the exception Report   Datasets are listed here with a legend describing the condition File-AID finds to be an exception. Some may be error conditions like I/O errors or Unsupported dataset types. Others may be for informational purposes such as shown here when one of the selected datasets was empty or for a PDS if no members were selected PERFORM the update
• #74: Perform the update.
• #75: NOW GO BACK TO THE SRCE code example
• #76: This time we are selecting multiple Source libraries to search at the same time.
• #77: Put in your Search Criteria.
• #78: Get your results.