On Sun, 22 Nov 2015 16:32:00 +0100, Leopold Strauss wrote:
>
>Obviously the misdesigned RECEIVE-command is the problem, because I do
>not understand, why this command does not accept all needed parameters
>as a lot of other TSO-commands do.
>
Yup.
>There is no meaningful sense in that design-
>
Diachronic. It appears that the command was originally intended only for use
under interactive TSO. The later extensions are incomplete.
>On 22.11.2015 16:24, Leopold Strauss wrote:
>>
>> But from time to time we get a lot of xmit-files from our customers
>>
>> I know the sdsf-rexx-features ( very great features), but I do not see
>> any benefit in that for automizinh receives uin unix-shell.
>>
>> We get the xmit files somewhere sent withFTP , thenevery xmit-file has
>> to copied to a zOS-native_dataset, then it will be received and so on.
>>
>> No idea, what SDSFdoes have to do with it.
>>
I hadn't understood. Traditional TRANSMIT without the OUTDD option and
RECEIVE without the INDD option manipulate the spool which might be accessed
with SDSF.
>>
I have a variant of this working:
Write a TSO EXEC, saved in a z/OS-native partitioned data set which does:
call BPXWDYN( 'alloc rtddn(NETDATA) path('''arg( 1 )''') ... msg(WTP)' )
call prompt( 'ON' )
push 'reply-to-receive-prompt'
adress TSO 'RECEIVE INDD('NETDATA')'
Then, from your z/OS UNIX REXX:
address TSO 'EXEC ''your-pds(receive-exec)'' ''file-received-from-ftp'''
Hope this helps. Shmel's sniping is surely no help.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
