On Mon, Apr 10, 2017 at 9:37 AM, Lizette Koehler <[email protected]> wrote:
> There are products out there > > Systemware XPTR (not sure of today's name) > > CA View (Old Mobius product I think) > > $AVERS > > And more > > It will depend on $$ to spend and what features you need. > One thing that is (now) of greater importance to me is "Where is the data stored?". There there seems to be two choices in today's world: individual sequential(?) data sets for each job or in a single "data store" data set which contains a "directory" and comes with "management software" to do things such as request a reprint or archive old output. I rather liked the "one PS data set per job/report" philosophy because it was easy to read reports via ISPF 3.4. Even better, IMO, would be "one UNIX file per report". Why UNIX you ask? Because it is _easy_ to use something like "grep" to find complicated search strings. Well, it is easy so long as you know regular expressions; which I do. Also, depending on your company's technical expertise, it would be "easy" to transfer the reports to a distributed system and index it similar to a "web search" engine so that your user could do a Google (or Bing) like search. We actually use a product which is PC resident (Report 2 Web). The z/OS system uses JQP from MacKinney Software to send reports to a "LAN printer", which is actually a "service" on a Windows machine. This service looks at the data in the report (which includes a job separator which we use to communicate with the service) to classify it. It can then do a number of things with the data (including creating a subset from an embedded "table" which is stored in an Excel spreadsheet), but we manly just store it in a reformatted file on a LAN disk. The "index" to this is kept in an Oracle data base (but, IIRC, it could use any ODBC compliant data base). Users are defined to the software for access to specific reports. The users access the reports to which they are authorized via their browser (thus to "2 Web" part of the name). The file format on disk is undocumented, but fairly simple to figure out. > > Searching the internet should be able to start your review process. > > Not only look at the features, but how the conversion from RMDS to new > product will be handled. > We converted from Mobius Infopack. We had help from a consulting firm which basically wrote some programs to parse the output from an Infopack report on available reports, and create "print" jobs which sent the "print" out to the "LAN printer". Basically, it was a programmed operator to request a reprint of every report in Infopack. Mobius was not well pleased about the "automation", as I recall. > > Lizette > -- "Irrigation of the land with seawater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
