FTPing of DFDSS Dump Files

2007-12-07 Thread Ed Long
So, since I transfer 4 DFDSS dumps a day via TERSE and FTP, I thought I'd put 
together a test restore to see what happened. I used the following FTP command 
stream; which is identical, except for replacing the put with a get, to the 
outbound.  It worked fine; a DFDSS TYPRUN=NORUN restore read the entire dataset 
and would have restored the known universe.
   
  The site rdw command gets a command not understood, since the Windows FTP 
server doesn't do Record Descriptor Words.
   
  Here are the FTP commands. note the clever use of the DDNAME option.
   
  nottherealserver
  nottherealuid
  nottherealpswd
  binary
  site rdw
  cd \ftp\blue2\backup
  lcd 'TEMP.FULLSYS.DFDSS.SHIFTBK.BACKUPR'
  status
  ls
  lpwd
  pwd
  get shift.trs //DD:SYSUT1
  quit
  

 


Edward Long

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FTPing of DFDSS Dump Files

2007-12-06 Thread Gary DiPillo

Doug,

When you FTP'd the data set from the Windows machine to the z/OS 
machine, did you either preallocate the target data set or specify the 
data set attributes (LRECL, RECFM) with the QUOTE SITE command?  The 
z/OS FTP server defaults might not be right for the TERSED files.


A few months ago I did what you are doing without a problem.

Regards,
Gary DiPillo

Doug Evans wrote:
I need to move on zOS system to another. My simply plan was to dump 
datasets using DFDSS DUMP and then transferring the DUMP file to the other 
system using FTP. For the most part it worked out ok- in fact we'd TERSE the 
DUMP file before FTPing and DETERSE after saving lots of bandwidth.


But I've falling into a situation where I have a problem. If I FTP the DUMP file 
to a Windows server using BINARY mode, and then FTP it back to a zOS 
system in BINARY mode- DFDSS cannot read the thing. My rear is still sore 
over this one.


Does anyone know of a way to FTP the DUMP file back to a zOS system so it 
is readable?


Now I've noticed in some searching of the web the that EBCDIC parameter 
being mention during the FTP transfer, would that help? BTW- I cannot go 
back and recreate the DUMP files- all I have to work with is the transferred 
copies on the Windows Server... :-(


Thanks for any help rendered...
Doug Evans

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


  


--
Axios Products, Inc. [EMAIL PROTECTED] 631-864-3666 x133

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FTPing of DFDSS Dump Files

2007-12-06 Thread Paul Gilmartin
On Thu, 6 Dec 2007 13:30:33 +0800, Johnny Luo wrote:

BINARY mode itself is not enough.

'quote stru r' is what you need.

Not necessary for TERSEd files.  And of no help to the OP,
who now has the data only on the Windows server.

On Dec 6, 2007 11:33 AM, Doug Evans wrote:

 system using FTP. For the most part it worked out ok- in fact we'd TERSE the
 DUMP file before FTPing and DETERSE after saving lots of bandwidth.

 being mention during the FTP transfer, would that help? BTW- I cannot go
 back and recreate the DUMP files- all I have to work with is the transferred
 copies on the Windows Server... :-(

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FTPing of DFDSS Dump Files

2007-12-06 Thread Zaromil Tisler
 Does anyone know of a way to FTP the DUMP file back to a zOS system so it 
 is readable?

Using Windows as a client and z/OS as a server the following works for me for 
tersed datasets (binary ftping in both directions):

ftp quote site lrecl=1024 recfm=fb blksize=6144
200 SITE command was accepted


to check allocation parameters:

ftp quote stat
.
.
.
211-Record format FB, Lrecl: 1024, Blocksize: 6144


After that I just (binary) put the tersed dataset.

-- 
Zaromil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FTPing of DFDSS Dump Files

2007-12-06 Thread Lizette Koehler
When I use DFDSS to download a volume or dataset(s) to be transferred to 
another host, I always include BLKSIZE=32760 on the output file in DFDSS.  Even 
though DFDSS does not care, it does help my transfer process whether that is 
NDM, XCOM, FTP.

If you terse the file you need to make sure you upload it with the same 
attributes that the terse files has.

That will also be the case for a TSO XMITTed file. Your BIN transfer is okay, 
so long as you keep the file attributes the same on the host.

Lizette





I need to move on zOS system to another. My simply plan was to dump
 datasets using DFDSS DUMP and then transferring the DUMP file to the other
 system using FTP. For the most part it worked out ok- in fact we'd TERSE 
 the
 DUMP file before FTPing and DETERSE after saving lots of bandwidth.

 But I've falling into a situation where I have a problem. If I FTP the 
 DUMP file
 to a Windows server using BINARY mode, and then FTP it back to a zOS
 system in BINARY mode- DFDSS cannot read the thing. My rear is still sore
 over this one.

 Does anyone know of a way to FTP the DUMP file back to a zOS system so it
 is readable?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FTPing of DFDSS Dump Files

2007-12-06 Thread Pinnacle
- Original Message - 
From: Doug Evans [EMAIL PROTECTED]

Newsgroups: bit.listserv.ibm-main
Sent: Wednesday, December 05, 2007 10:34 PM
Subject: FTPing of DFDSS Dump Files



I need to move on zOS system to another. My simply plan was to dump
datasets using DFDSS DUMP and then transferring the DUMP file to the other
system using FTP. For the most part it worked out ok- in fact we'd TERSE 
the

DUMP file before FTPing and DETERSE after saving lots of bandwidth.

But I've falling into a situation where I have a problem. If I FTP the 
DUMP file

to a Windows server using BINARY mode, and then FTP it back to a zOS
system in BINARY mode- DFDSS cannot read the thing. My rear is still sore
over this one.

Does anyone know of a way to FTP the DUMP file back to a zOS system so it
is readable?



If you downloaded the TERSEd files to your PC as BINARY, then you can still 
recover, just upload them BINARY to an FB1024 file and DETERSE, then DFDSS 
RESTORE.  If you downloaded the DFDSS DUMP files directly to the PC, even as 
binary, you are hosed.  You play with the QUOTE and SITE commands at your 
own risk.  It's ALWAYS safer to use BINARY transfer of TERSEd or XMIT'ed 
files.  The shortcuts are great when they work, but I can't take that 
chance.


Regards,
Tom Conley 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FTPing of DFDSS Dump Files

2007-12-06 Thread Doug Evans
Thanks Gary (and others),

I think I forgot to mention though is that in this case, the DUMP data set was 
not TERSED first- thus the problem

Thanks,
Doug.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FTPing of DFDSS Dump Files

2007-12-06 Thread Ed Gould

On Dec 6, 2007, at 8:03 AM, Paul Gilmartin wrote:


On Thu, 6 Dec 2007 13:30:33 +0800, Johnny Luo wrote:


BINARY mode itself is not enough.

'quote stru r' is what you need.


Not necessary for TERSEd files.  And of no help to the OP,
who now has the data only on the Windows server.


On Dec 6, 2007 11:33 AM, Doug Evans wrote:

system using FTP. For the most part it worked out ok- in fact  
we'd TERSE the

DUMP file before FTPing and DETERSE after saving lots of bandwidth.

being mention during the FTP transfer, would that help? BTW- I  
cannot go
back and recreate the DUMP files- all I have to work with is the  
transferred

copies on the Windows Server... :-(





I will throw my two cents into this as (unless something has been  
fixed or changed) ...
Long time ago and far far away the only way to get a DFDSS dump to  
ftp was to specify on the output statement (at creation time) was to  
put DCB=BLKSIZE=32760 that told DFDSS *not* to create large  
blocksize  (gt 32K) tapes.


32K is the largest FTP can handle (last I heard).

If this has changed will someonbe correct me and let me know what  
apar fixed this.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


FTPing of DFDSS Dump Files

2007-12-05 Thread Doug Evans
I need to move on zOS system to another. My simply plan was to dump 
datasets using DFDSS DUMP and then transferring the DUMP file to the other 
system using FTP. For the most part it worked out ok- in fact we'd TERSE the 
DUMP file before FTPing and DETERSE after saving lots of bandwidth.

But I've falling into a situation where I have a problem. If I FTP the DUMP 
file 
to a Windows server using BINARY mode, and then FTP it back to a zOS 
system in BINARY mode- DFDSS cannot read the thing. My rear is still sore 
over this one.

Does anyone know of a way to FTP the DUMP file back to a zOS system so it 
is readable?

Now I've noticed in some searching of the web the that EBCDIC parameter 
being mention during the FTP transfer, would that help? BTW- I cannot go 
back and recreate the DUMP files- all I have to work with is the transferred 
copies on the Windows Server... :-(

Thanks for any help rendered...
Doug Evans

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FTPing of DFDSS Dump Files

2007-12-05 Thread Johnny Luo
BINARY mode itself is not enough.

'quote stru r' is what you need.




On Dec 6, 2007 11:33 AM, Doug Evans [EMAIL PROTECTED] wrote:

 I need to move on zOS system to another. My simply plan was to dump
 datasets using DFDSS DUMP and then transferring the DUMP file to the other
 system using FTP. For the most part it worked out ok- in fact we'd TERSE
 the
 DUMP file before FTPing and DETERSE after saving lots of bandwidth.

 But I've falling into a situation where I have a problem. If I FTP the
 DUMP file
 to a Windows server using BINARY mode, and then FTP it back to a zOS
 system in BINARY mode- DFDSS cannot read the thing. My rear is still sore
 over this one.

 Does anyone know of a way to FTP the DUMP file back to a zOS system so it
 is readable?

 Now I've noticed in some searching of the web the that EBCDIC parameter
 being mention during the FTP transfer, would that help? BTW- I cannot go
 back and recreate the DUMP files- all I have to work with is the
 transferred
 copies on the Windows Server... :-(

 Thanks for any help rendered...
 Doug Evans

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html




-- 
Best Regards,
Johnny Luo

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FTPing of DFDSS Dump Files

2007-12-05 Thread shai hess
It is so easy to do it with MFNetDisk!!


Moving system from one site to another can be done by using PC Device with
source mirror as the MVS source disk and target mirror as the target MVS
disk.

You can do it without need to stop the source disk and without have
degradation in the performance using the ASync mode.

So in general the PC will take care that the source disk will be copy to the
target disk and all the update to the source disk will update also the
target disk.

 If you need more information please email me your questions.


Thanks,
Shai
On 12/5/07, Johnny Luo [EMAIL PROTECTED] wrote:

 BINARY mode itself is not enough.

 'quote stru r' is what you need.




 On Dec 6, 2007 11:33 AM, Doug Evans [EMAIL PROTECTED] wrote:

  I need to move on zOS system to another. My simply plan was to dump
  datasets using DFDSS DUMP and then transferring the DUMP file to the
 other
  system using FTP. For the most part it worked out ok- in fact we'd TERSE
  the
  DUMP file before FTPing and DETERSE after saving lots of bandwidth.
 
  But I've falling into a situation where I have a problem. If I FTP the
  DUMP file
  to a Windows server using BINARY mode, and then FTP it back to a zOS
  system in BINARY mode- DFDSS cannot read the thing. My rear is still
 sore
  over this one.
 
  Does anyone know of a way to FTP the DUMP file back to a zOS system so
 it
  is readable?
 
  Now I've noticed in some searching of the web the that EBCDIC parameter
  being mention during the FTP transfer, would that help? BTW- I cannot go
  back and recreate the DUMP files- all I have to work with is the
  transferred
  copies on the Windows Server... :-(
 
  Thanks for any help rendered...
  Doug Evans
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions,
  send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
  Search the archives at http://bama.ua.edu/archives/ibm-main.html
 



 --
 Best Regards,
 Johnny Luo

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html