On Wed, 17 Sep 2014 04:13:46 -0700, Charles Mills wrote:
>Take a look at the FTP subcommand SENDSITE.
>
Why?
>On Tue, 16 Sep 2014 13:29:57 -0700, Charles Mills wrote:
>
>>Yup. Over-engineering. Over-validation. Like examining a filename to see if
>>it is syntactically valid rather than just passing it to the OS's open
>>function and seeing if it works for the OS.
>>
Bizarre. Wait, while I put on my Black Team costume ... there.
(Twirling mustache) The job step JCL:
//FTPCAT EXEC PGM=FTP,PARM='&UNXSRV' ,COND=(0,LE)
//NOTES DD *
In:
http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.halu001/dd_name_support.htm
ddname support with FTP
z/OS Communications Server: IP User's Guide and Commands
SC27-3662-00 )
Restrictions:
...
To prevent transferring data from an empty file, FTP checks whether
the first file in a concatenation series is empty and allocates an
empty data set. No data is transferred.
... but the restriction appears not to apply to empty instream data
sets; it does apply to empty UNIX files.
>
//NETRC DD PATHOPTS=ORDONLY,FILEDATA=TEXT,RECFM=VB,
// LRECL=999,BLKSIZE=9999,PATH='/tmp/&SYSUID/HOME/.netrc'
//OUTPUT DD SYSOUT=(,)
//*
//SYSPRINT DD SYSOUT=(,)
//SYSIN DD DUMMY
//SYSUT2 DD SYSOUT=(,)
//SYSUT1 DD * 2....+....3
// DD *
This is the first catenand, and has a long record!
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9..
// DD PATHOPTS=ORDONLY,PATH='/tmp/&SYSUID/empty',
// RECFM=FB,LRECL=80,BLKSIZE=32720
// DD *
This is the last catenand.
//INPUT DD *
user
whatever
verbose
ascii
delete TEMP.FTPCAT
put //DD:SYSUT1 TEMP.FTPCAT
quit
//
Submitted from a Solaris system via FTP:
:w ! JESRECFM=V JESLRECL=254 submit $MVS_HOST
Shows the following (excerpted) in FTP OUTPUT:
EZA1736I delete TEMP.FTPCAT
EZA1701I >>> DELE TEMP.FTPCAT
250 DELE command successful.
EZA1460I Command:
EZA1736I put //DD:SYSUT1 TEMP.FTPCAT
EZA1701I >>> SITE FIXrecfm 30 LRECL=30 RECFM=FB BLKSIZE=30
500 'SITE FIXRECFM 30 LRECL=30 RECFM=FB BLKSIZE=30': command not understood.
EZA1701I >>> PORT 10,80,63,53,15,236
200 PORT command successful.
EZA1701I >>> STOR TEMP.FTPCAT
150 Opening ASCII mode data connection for TEMP.FTPCAT.
226 Transfer complete.
EZA1617I 224 bytes transferred in 0.030 seconds. Transfer rate 7.47
Kbytes/sec.
EZA1460I Command:
EZA1736I quit
EZA1701I >>> QUIT
221-You have transferred 224 bytes in 1 files.
Where does the "LRECL=30" come from? (I have an RCF in on this.
Waiting with bated breath.)
And in the received file -- clearly some data were truncated, but no
error messages were issued:
user@HOST: ( cd && cat TEMP.FTPCAT )
This is the first cat
?-....+....1....+....2.
This is the last catenand.?
-....+....1....+....2.?
-....+....1....+....2.?
-....+This is the last ca
tenand.?
Ugh! I bet it's all WAD. I imagine the response: "It's not our fault;
you're not supposed to do that."
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
