An XMITted file sits in the JES output queue in a designated class (usually B) 
with the recipient's userid as DEST. When that user issues RECEIVE, all pending 
XMIT files are presented one by one. For each file, the user can store it, 
delete it, or issue END. END terminates the RECEIVE command without processing 
the current file. You could issue RECEIVE again and get the same files (I'm 
pretty sure) in the same sequence. So on each pass, you could store the next 
file with attributes gleaned from the previous pass and then END. Repeat until 
no more files are presented. 

Pretty kludgy, but it would probably work. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[email protected]

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, November 17, 2015 12:18 PM
To: [email protected]
Subject: (External):Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

On 2015-11-17 12:00, J O Skip Robinson wrote:
> Unlike CLIST, REXX is tricky for handling subcommands and prompt responses, 
> which need to be QUEUEd (or PUSHed) onto the stack before the main command is 
> issued. This can be problematic when the response cannot be known in advance 
> of issuing the command. For example, the data set name to use for RECEIVE may 
> depend on the data set XMITted. One solution might be to issue RECEIVE, trap 
> the output that contains the data set name, and END without actually 
> receiving the data set. Then construct a prompt response based the known data 
> set name, QUEUE the appropriate response, and issue RECEIVE again. Might be 
> undoable if more than one data set is waiting for RECEIVE.
> 
Terrible design, indeed.  Perhaps it was motivated by a desire to match and 
surpass the worst features of the TSO OUTPUT command.

RECEIVE ought to have options:
o JOBID(JOBnnnnn)
o REPLY('string')
o QUERY (your RECEIVE; trap; END)  (like CMS NETDATA QUERY)

And it should be a prefix command in SDSF

How does RECEIVE select which spool entries to process?

But this seems to work for me:


user@OS/390.24.00: rexx "address TSO 'listcat level(...)'" |
    sed -n 's/NONVSAM -.\{24\}//p' | sort
G0628V00
G0629V00
G0630V00
G0631V00
G0632V00
G0633V00
G0634V00
G0635V00
G0636V00
G0637V00
G0638V00
G0639V00
G0640V00
G0641V00
G0642V00

"sort" may be superfluous; LISTCAT seems to alphabetize its output.

On Tue, 17 Nov 2015 07:50:44 -0600, Walt Farrell wrote:
>
>CSI is a better approach than reading the output of LISTC, in my opinion, as 
>the LISTC output is not a programming interface.
>
Grrr...  IOW, you believe the output format of LISTCAT is subject to change.

Lizette seems determined to optimize a gnat with a sledgehammer.
-- gil


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to