Reading CA-VIEW (aka SAR) files

[Duffy, Peter]

Hi, all,

Delurking here for my first question. So far, most of what I've needed to
do can be mined from the archives or on someone's site. I love what has
been shared in the archives and on so many user sites. I so appreciate the
REXX community!

A question came up here on how use REXX to read output in CA-VIEW, which
used to be called SAR or CA-SAR. Is anyone doing this and if so would you
have any examples you would be willing to share?

The product archives output out of the spool to its own files (DSORG of DA)
based on various criteria. We want to read through various job outputs for
info, consolidate this and that, produce reports, yada, yada, yada.

Thanks in advance,
Peter Duffy
AARP
pdu...@aarp.org
562-496-5215

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Lionel Dyck]

I've got something I call CAVXTRT and you can find it on my web site at
http://www.lbdsoftware.com

It is effectively a easier to use, more functional, replacement for the CA
provided ISPF interface to CA-View and you can look at it to see how it
extracts the CA-View files.

hope this helps
--------------------------------------------------------------------
Lionel B. Dyck, Systems Software Lead
Kaiser Permanente Information Technology
25 N. Via Monte Ave
Walnut Creek, Ca 94598

Phone: (925) 926-5332 (tie line 8/473-5332)
E-Mail: Lionel...@kp.org
Sametime: (use Lotus Notes address)
AIM: lbdyck

"Duffy, Peter" <PDu...@AARP.ORG>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
11/27/2002 10:44 AM
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>

To
TSO-...@VM.MARIST.EDU
cc

Subject
[TSO-REXX] Reading CA-VIEW (aka SAR) files

[Robert Zenuk]

I haven't had the need to wrap SAR in REXX yet, but the approach I would take
would depend on the requirements. To second guess the requirements a little,
I will go through a couple scenarios.

If this is a completely static batch solution, I would run a SARBCH step to
"/PRINT" all the required reports to sequential files.

//********************************************************************
//* PRINT SAR REPORTS TO A FILE *
//********************************************************************
//SARBATCH EXEC PGM=SARBCH,PARM='SAR.DB'
//SYSPRINT DD SYSOUT=*
//REPORT DD SYSOUT=*
//OUTPUT1 DD DSN=RZENUK.SAR.OUTPUT1,DISP=(,CATLG),UNIT=SYSDA,
// SPACE=(CYL,(10,10),RLSE)
//OUTPUT2 DD DSN=RZENUK.SAR.OUTPUT2,DISP=(,CATLG),UNIT=SYSDA,
// SPACE=(CYL,(10,10),RLSE)
//OUTPUT3 DD DSN=RZENUK.SAR.OUTPUT3,DISP=(,CATLG),UNIT=SYSDA,
// SPACE=(CYL,(10,10),RLSE)
//SYSIN DD *
/PRINT ID=REPORT1 DDNAME=OUTPUT1
/PRINT ID=REPORT2 DDNAME=OUTPUT2
/PRINT ID=REPORT3 DDNAME=OUTPUT3
/*

Then I would write a REXX parser to run as a second step that would
ALLOC/EXECIO the 3 OUTPUTx DSN's and do the consolidation... Obviously the
parser would have unique code for each report. Without knowing the actual
reports, their relationships to each other and the summarization rules, I
would tend to settle on a separate internal subroutine for each report and
keep the targeted data in stem variables for summarization after all the
files are read.

If this is to be used foreground or you are looking for a single step
self-contained solution, I would wrap the SARBCH program in an EXEC using the
following techniques:

"ALLOC F(SYSPRINT)...." /* or include the DD in the JCL */
"ALLOC F(REPORT)......" /* or include the DD in the JCL */
"ALLOC F(OUTPUT1)....." /* or include the DD in the JCL */
"ALLOC F(OUTPUT2)....." /* or include the DD in the JCL */
"ALLOC F(OUTPUT3)....." /* or include the DD in the JCL */

I would then generate the SAR /PRINT statements in a stem and EXECIO them
into a VIO SYSIN and do everything under the covers.

sysin.1 = '/PRINT ID=REPORT1 DDNAME=OUTPUT1'
sysin.2 = '/PRINT ID=REPORT2 DDNAME=OUTPUT2'
sysin.3 = '/PRINT ID=REPORT3 DDNAME=OUTPUT3'
"ALLOC F(SYSIN) UNIT(VIO) LRECL(80) BLKSIZE(0) SPACE(1) TRACKS"
"EXECIO * DISKW SYSIN (STEM SYSIN. FINIS"

Finally, call SARBCH. I like ATTCHMVS if SARBCH is in the LINKLST or you use
JCL and can but the SAR.LOADLIB in the STEPLIB. If not, use a TSO "CALL
'SAR.LOADLIB(SARBCH)' '"sarparms"'"

sarparms = 'SAR.DB'
address ATTCHMVS "SARBCH" "SARPARMS"

In all cases, running a SAR index to first identify the reports may be
necessary if you are trying to retrieve prior versions of a report. The SAR
/PRINT statement defaults to the most recent copy of a report.

If the data in one report is supposed to be cross referenced with data on
another report (and a product like Monarch or some other SYSOUT miner is not
available), you might consider creating some temporary files or tables (if
DB2 is available) to create an easier working environment.

Now the disclaimer, I have found most of these report scrapers to be
problematic because the original reports can change (like the old HLLAPI
screen scrapers). The best solution is always to go back to the application
with new requirements for new programs/reports than building backend
processes over the top of obsolete reports. I also tend to look upstream to
see if the reports are already generated off existing extracts. This allows
you to go directly to the source and avoid the report parsing issue. If the
reports are not generated off flat extract files to begin with, another
approach is to have the existing reporting program write an extract file so
the post processing is easier. I realize that much of this is not possible
if this is a vendor package, but I always like to suggest going back to the
application to avoid creating processes the application is unaware of. Many
application upgrades and overhauls tend to destroy these one off solutions.
Even though I always make this recommendation, I have still been contracted
to create these types of reports, hence the awareness to the technique...

Hope this Helps,
Robert Zenuk
robz...@aol.com

[Jeremy C B Nicoll]

In article <6F7CED372921C749B48...@mbs02lw.na.aarp.int>,
"Duffy, Peter" <PDu...@AARP.ORG> wrote:

> A question came up here on how use REXX to read output in CA-VIEW,
> which used to be called SAR or CA-SAR. Is anyone doing this and if so
> would you have any examples you would be willing to share?

There's code - normally used by batch jobs - to look up the index of a
sar database, and then to extract (to a sequential file) a particular
report.

It's quite easy to run the first part to create a listing of the index in
a file, and then read that with rexx and create the sysin for the second
part. I used to do this to grab the "most recent instance" or "the "last
report generated on a particular date" etc..

Once you've got it working in batch changing it to foreground is not
difficult, but there's a drawback which is that SAR may have to mount an
archive tape to recover the report(s) you want. It's not sensible to
have stuff like that hold up a foreground user.

I got the basic jcl for the index & retrieval parts of this from the
people who looked after set-up & housekeeping of our sar databases.

I can't readily get you examples because I'm off sick (and can't remember
what typical jobs that did this were called).

--
Jeremy C B Nicoll - my opinions are my own.