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
