> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]]
> On Behalf Of Elardus Engelbrecht
> Sent: Friday, October 10, 2014 1:59 PM
> To: [email protected]
> 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN
