Along came the 3^rd party vendors who were preparing to revolutionize the industry. Even IBM was going to get involved. First, companies planned to eliminate "sysout" listings (i.e. JCL and JES logs) by archiving them to disk. Who really needed to print them anyway? Besides, this way the distribution clerk wouldn’t have to separate the JCL from the report before delivering it to the end user. Next was the issue of viewing the sysout. Ah, but how to provide access? Would TSO suffice? What about Roscoe users? Would CICS or IMS viewing also be needed? How long should the listing be stored?

Now that 25% of the paper was eliminated, where do you go from here? Suddenly, vendors realized that the poor sole responsible for delivering the actual report really had few clues about where it really needed to go. Think about it, all we have is a JES banner page which typically identified the jobname that this pile of paper came from, big deal. The next obvious solution would be to create special banner pages identifying the individual (with physical address) who would be desperately awaiting the arrival of this valuable information. Since many companies now had a scheduling system, a lot of information about the end user became available but it was still necessary to input this into the report distribution system. Much like early scheduling systems, report distribution products became a manual, tedious process to implement.

Along with customized banner pages, some vendors promoted the capability of letting the computer breakdown a report into sections so that the accounting department got just the part of the report that they needed. Same for sales, operations and anyone else. Why print multiple copies when you could just tear the report into pieces and deliver the pieces. Farewell, multicopy forms (in some cases)!

Wait! If we promote the viewing of JCL listings, why not view reports in the same fashion? Put those users ONLINE! Allow them to view multiple versions of the report so they can compare this month to last month! Why not this year to last year? Roll in some more DASD please!

Ah, now that these ever so wise vendors have solved the problem of physical report distribution the only thing left to solve would be the last remaining clerical task of "balancing" a report. Check those totals. If they aren’t within an expected range, if things don’t "add up", someone needs to be notified! Thus a tie from the report distribution process to the scheduling system.

But wait, here comes client/server technology. How can we keep our users happy with these latest technologies? Confusion expands with the age of web-based report distribution. Same issues and concepts but on different platforms. Will the mainframe reports be forced to reside on NT or Unix rather than the trusted mainframe? Will the information be secure? What functionality will be gained? Hey wait, if you can do this with mainframe reports, why not do the same with ERP, client/server or any other report? Why not route everything to through the mainframe distribution system? The battle between the mainframe and client/server continues. Is there a "right" answer?

Alas, the users continue to demand service. Now they expect to view these reports via a web browser. Can we tie the mainframe security and storage capabilities with PC viewing? Maybe it’s time for a fresh approach to an old problem. What does that mean for all of the hard work and time put into the original report distribution system?

Remember how tedious it was to define those report distribution criteria to the original mainframe products? Well, bad news. You will be faced with the same tedious task on the new platform. The platform may be NT or Unix but the task is still the same, perhaps prettier with the GUI but still tedious. What about a way to programmatically extract both reports and report definitions from your old system and feed it directly into your newly chosen solution? That is how Essential Systems Technical Consulting approached this problem as more and more companies change from one report distribution system to another. Whether it is for feature reasons, vendor preferences, or simply to satisfy those pesky end users, don’t throw away your investment of all of those hours defining how to break down reports. And, don’t forget that you might need to migrate the archived reports themselves to the new system unless you’re prepared to pay for two licenses of the same type of software.

With over 20 years of report distribution and automated operations experience, ESTC knows how to tame these beasts of information. The answer is more than just technology, it’s a matter of review and consolidation of reports and retention periods. While you’re upgrading the software, you might as well clean house and get rid of unneeded reports thus freeing up more disk space, which will quickly be gobbled up by other more desirous entities. This is the time to review retention, distribution and general reporting policies. But how do you get this information out of one system and into the next? This is not a simple read it and write it process. ESTC, because of its experience with various report distribution systems took a generalized approach called Path2tm Technology. This affords the user the flexibility of moving from any system to any other system in a programmatic, automated method.

Data and reports on the mainframe are commonly referred to as LEGACY Data and LEGACY Reports. In an effort to mainstream the report distribution process, many companies have chosen to move to a client based report distribution system. The whys are not totally clear but companies are moving for a variety of reasons, maintenance costs, old technology, vendor relationship and more. When a company begins a task of changing software products either on the same platform or moving to another platform, the first question is Can I retain my information and archival reports ?. The answer is yes. What many clients need to realize is there are methods of maintaining your original investment data and still allow the datacenter to support only one report distribution product. By using a proven methodology in a conversion project, all legacy reports will remain in tact in the new environment. The process of conversion is different for each report distribution product but the bottom line remains the same.

Several considerations should be made when converting from one product to another. First is to be sure your staff does a proper due diligence on the product you are moving to. Don’t be swayed by a salesperson telling you that their product is better and comparable to your existing product. No two report distribution systems are the same. Many look and feel alike but the underlying technology may be drastically different. Asking an independent consulting company may be worth the small fee for advice on report distribution. Secondly, you should identify the critical reports and remove any trash from your existing system. A clean data plate is much easier to convert than one that has a lot of left overs on it. Thirdly, be sure that the space requirements are comparable, make the vendor display the compression algorithms to you and compare them to your existing system. Remember you will reuse the space you occupy now for report distribution. Lastly, you should identify any changes or customization you wish to have in the new system. Conversion routines can be customized for the clients need.

The first task in a report distribution product conversion is to determine if the definitions must be converted. In a case where you are jumping platforms (i.e.: MVS to UNIX), the application programs will generate different reports and jobs. The critical task in this case is to get the report archives over to the new system so users can reference the legacy data. If you are to remain under one operating system and are simply switching products, most likely you will want to keep the existing naming and processing conventions.

The problem that arises when trying to keep existing standards are the database fields are different lengths. For example, a customer wishes to convert CA-Deliver to OnDemand. The Report Id field in CA-Deliver is 12 bytes and in OnDemand the Report Id is only 8 bytes. In a CA-Dispatch to CA-Deliver conversion, the Recipient (aka Distribution Id) field in CA-Dispatch is 16 bytes where as in CA-Deliver the Distribution ID field is only eight bytes. There are other field inconsistencies between all of the major report distribution systems. When converting to another platform the flexibility of UNIX and NT based report distribution products allows for an easier less restrictive environment.

Now that we have accepted the role of the PC for providing access to these wonderful mainframe reports, you know, the ones we all spent days, weeks and sometimes months designing, where do we go from here? The users continue to complain about time to receive information. Wasn’t that what these new report distribution systems were supposed to fix? Why can’t those users ever be satisfied? Perhaps it’s time to consider the next level of reporting. Is it possible to provide the data to the user and let them generate their own reports? That way, our programming backlog will be reduced instead of having to satisfy the user who continually wants to add just one more field or to re-sort the information in just one other way. To keep the data under control but let the user LOOK at it the way they each want to (individually), now THAT would be customer service.

This next level of reporting has also become known as Business Intelligence; Decision Support Software and sometimes simply adhoc reporting. The key is keeping the data under control. That is where products such as Brio Technology, Cognos, and other companies found success. Their tools provide the user the ability to generate reports in a multitude of ways.

Next article:  "Web-Based Reporting, Letting Go of the Data (Beyond Report Dist)".