We just installed NetResults/z and I'm dabbling with your JES repository feature. We use JES2 and usually have anywhere from 12-16 hours of SYSLOG, on spool, at any given time of the day.
Shooting problems from the online SYSLOG, which we now do using the VS function of NetResults/z, are easy. The filtering and zoom/unzoom features have saved us much time.
We also look at the offline SYSLOG quite a bit; probably even more so than the online SYSLOG. The offline SYSLOGs are GDGs and we usually have 2-3 days worth available on DASD. We browse the offline SYSLOGs using ISPF browse. It's slow and tedious, but we've been doing it that way for a long time.
Also, there are many times when we need to look at "both" the online AND offline SYSLOG data sets to shoot a problem. These types of problems are tough and even more tedious. That's why I'm so interested in the repository.
Initially, I just want to put the most recently spunoff SYSLOG into the repository. Later I'll probably put more. Doing just the most recently spunoff SYSLOG, should at least double the amount of "online" SYSLOG ( up to around 24-36 hours). I think with that much SYSLOG data, online, we would virtually eliminate the tedium involved in dealing with "offline" SYSLOG data.
So, my question is this; How can I keep, just, the most-recently spunoff SYSLOG in the repository ?
Response to #1:wer:
To keep, only the most-recently spunoff SYSLOG in the repository, and seamlessly concatenate it with the online SYSLOG, is easy.
First of all, the "JESR" function in NetResults/z is responsible for maintaining the JES Repository. To keep just the most-recently spunoff SYSLOG in the Repository, each time you spinoff a SYSLOG, just issue the following JESR commands:
JESR ADD=dsn of most recent GDG
JESR DEL=dsn of previous GDG
The above commands can be done, either manually, through the NetResults/z command line; Or, automatically, by adding two JOB Steps to the XWTR job that produces your offline SYSLOG GDGs.
You might feel more confortable doing it manually, at first. At least until everyone involved experiences how simple it is.
Later, however, you can "automate" the process by adding the following two NTRMSG (utility supplied by NetResults/z) program STEPs, to the end of your External Writer (usually named XWTR) Proc;
//GENADD EXEC PGM=NTRMSG,PARM='ADD=$DD1'
//$DD1 DD DSN=XWTR.OUTPUT(+1),DISP=SHR
//GENDEL EXEC PGM=NTRMSG,PARM='DEL=$DD1''
//$DD1 DD DSN=XWTR.OUTPUT(0),DISP=SHR
The two above JOB STEPs will produce the following WTO's, which should then be automated to invoke the NetResults/z JESR function under a NetView AUTOTASK of your choice.
NTR900I JESR ADD=XWTR.OUTPUT.Gnnn1V00
NTR900I JESR DEL=XWTR.OUTPUT.Gnnn0V00
Incidentally, the "JESR DEL=dsn" command can be issued even though you might not have a previous SYSLOG in the Repository; as would happen the "first" time through. In that case, the JESR function will just issue a non-zero return code and put a message on the log. Nothing consequential.
Later, if you decide to increase the amount of spunoff SYSLOG data in the repository, just remove the "DEL=dsn" step. NetResults/z will automatically "pop" off the oldest SYSLOG data set whenever the total number of slots you've specified in the repository, are exceeded. Very similar to how GDG indexes manage themselves.