Many years ago, I captured the TSO HELP for XMIT and RECEIVE and converted it to a more CMS-like HELP on VM. We had several MVS programmers whose only reason for logging on to VM was to view those HELP files.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] > Behalf Of Mike Walter > Sent: Wednesday, September 27, 2006 7:17 AM > To: [email protected] > Subject: Re: SENDFILE to MVS > > > Shimon, > > There is full help for the RECEIVE (and XMIT, aka TRANSMIT) > command on > TSO, on our systems I can see the help by entering: H RECEIVE > It's not *good* help like we are used to on VM mind you, but it does > explain the command syntax. > > > I still have not seen how to receive as > > a member to an existing library. > > I *think* you may want: > > receive > <when prompted> > DSN(your.pdsname(repmbr)) > > If the dsn is not prefixed by your TSO userid, then you'll > need to quote > it, as in: > DSN('your.pdsname(repmbr)') > > Personally, I just RECEIVE the file as a flat file and then > use ISPF to > copy the member to the PDS. > It is all-to-easy to forget to include the PDS member name, > in which case > you destroy the PDS - replacing it with the flat file. > Your gun, your foot. :-) > > Earlier in the thread, SENDFILE and TRANSMIT/XMIT modify the > file sent by > packing it into "NETDATA format", and then unpack it at the > receiving end. > Regardless of the actual maximum LRECL, the file will be > broken down into > 80 byte records for its journey. Of the 80 bytes, there are > prefixes on > at least some, perhaps all (been a while since I looked at > Netdata format) > records. There can be "significant overhead " doing that for > large files > -- on both sides of the transmission (whether they are both > VM, TSO, or a > mix). Consider whether FTP might be a better alternative > (especially if > using the scripting VMFTP package). > > Mike Walter > Hewitt Associates > Any opinions expressed herein are mine alone and do not necessarily > represent the opinions or policies of Hewitt Associates. > > > > > > > "Shimon Lebowitz" <[EMAIL PROTECTED]> > > Sent by: "The IBM z/VM Operating System" <[email protected]> > 09/27/2006 08:50 AM > Please respond to > "The IBM z/VM Operating System" <[email protected]> > > > > To > [email protected] > cc > > Subject > Re: SENDFILE to MVS > > > > > > > You got me on track. > After SENDFILE from CMS, SDSF shows > an MVS spool file named RSCSnnnn with > DEST of the target TSO userid. > > In TSO type TSO RECEIVE > > In response to the prompt, type DA(some.mvs.dsn) > > I still have not seen how to receive as > a member to an existing library. > > Thanks! > Shimon > > > On 27 Sep 2006 at 8:01, Nick Laflamme wrote: > > > It's been more than a decade since I last used TSO > (Hurray!), but, yes, > > TSO users can do something similar to a receive to receive > datasets from > > > spool space. TSO's counterpart to SENDFILE is XMIT, as I recall. > > > > Nick > > > > Shimon Lebowitz wrote: > > > Hi, > > > I seem to remember hearing once upon a time, that > > > TSO somehow supports SENDFILE. > > > > > > Is this true? What I mostly am interested in is using > > > SENDFILE on CMS to send files to a TSO user, > > > via an RSCS TCPNJE link which we have between > > > the two systems. (We actually also have SNANJE, > > > if that matters). > > > > > > And can TSO send files back to CMS? > > > > > > Thanks, > > > Shimon > > > > > -- > ************************************************************** > ********** > Shimon Lebowitz mailto:[EMAIL PROTECTED] > VM System Programmer . > Israel Police National HQ. http://www.poboxes.com/shimonpgp > Jerusalem, Israel phone: +972 2 530-9877 fax: 530-9308 > ************************************************************** > ********** > > > > > > The information contained in this e-mail and any accompanying > documents may contain information that is confidential or > otherwise protected from disclosure. If you are not the > intended recipient of this message, or if this message has > been addressed to you in error, please immediately alert the > sender by reply e-mail and then delete this message, > including any attachments. Any dissemination, distribution or > other use of the contents of this message by anyone other > than the intended recipient > is strictly prohibited. >
