Hi Tom,
I believe the file to look at is File 790, SRS - Sysout Retrieval Service.
It uses the SAPI interface to pull data off of spool.
DanD
-----Original Message-----
From: Thomas Berg
Sent: Friday, October 10, 2014 8:29 AM Newsgroups: bit.listserv.ibm-main
Subject: Re: Alternative to TSO RECEIVE
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Elardus Engelbrecht
Sent: Friday, October 10, 2014 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Alternative to TSO RECEIVE
Thomas Berg wrote:
>I'm using TSO RECEIVE to read outputs from JES SPOOL.
On what z/OS level are you?
1.13
>The outputs is created by allocating and writing as:
>Rc = BPXWDYN('ALLOC LOGROUTT SYSOUT(8) SPIN(UNALLOC)
DEST(systarget.userid) RECFM(V,B) LRECL(varies) BLKSIZE(32756) REUSE')
>'EXECIO' s.0 'DISKW LOGROUTT (STEM S. FINIS'
>The problem is the performance. There is many files with mostly one
>record.
Receive takes from 1/10 to 1 second elapsed time to get one file.
Ouch. And you probably have gazillions of them?
You could say so...
>I have tried the REXX/ISFACT interface to SDSF but it was only a minor,
>if any,
improvement.
Plus - I remember now - that I can't (sometime?) purge the files after the
read due to some racfrule. RECEIVE obviously isn't affected by those.
I would also go that route. But in the first place I would like the
jobowner to
write the outputs in the first place to datasets. Say for example changing
that
ALLOC statements somehow.
Well, this application is a sort of a primitive log function made by me.
The benefit of this solution is 1: It's independent of the environment
(MVS batch, TSO etc.) 2: It's relative fast (no alloc of a dataset etc.)
3: There is no enque problem or racf dependency regarding DSName.
Possible alternatives which I have NOT tested out for your scenario:
Offloader?
External writer, probably RYO one?
I think there are Assembler (better performance) examples on the CBTTAPE.
Anyone out there who can remember in what file(s) it was?
This would be interesting. I have browsed the cbt descriptions but not
found any that seems relevant.
We have a commercial spool offloader we use to extract the job outputs and
place it in datasets which can be browsed in an ISPF screen. That
offloader frees
up our spool space by extracting job outputs 24 hours per day and keep it
for x
days as required by our users.
>Any suggestion for a better performance?
Not much. There is a lot of overhead for just one record as found PER job.
JES2
and your interface to open it from both sides. Then the actual transfer of
that
line and then close on both sides. Then JES2 has to update its checkpoints
and do
some spooloverhead. Then your interface has to unalloc it and catalog it.
And all of this - if your JES2 is really busy, you will have to wait your
turn.
Perhaps little WLM tuning can help?
Groete / Greetings
Elardus Engelbrecht
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Best Regards,
Thomas Berg
___________________________________________________________________
Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
