Re: REFM=VB Binary upload problem
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Greg Saccomanno Sent: Monday, November 19, 2007 6:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: REFM=VB Binary upload problem snip I tried pulling the file down and pushing the file back up using a command window from M$ Windows and it worked as indicated (the file matched once re-uploaded). I tried various incarnations from an MVS batch job and have had no luck at all. Is there a way to do this from an MVS batch job or TSO FTP ( where I guess MVS is the client instead of the server)? If not I guess I will have to continue using XMIT and/or TERSE were applicable but for smaller files it would be nice to eliminate the extra step and be able to submit batch jobs from our MVS scheduling package. Thank you, Greg No. The STRU R command only works when z/OS is the SERVER. If you are trying to push from z/OS to Windows, then z/OS is the CLIENT and Windows is the SERVER. I've never gotten that to work. Well, except to ftp from z/OS to itself using the STRU R to another dataset, then ftp'ing that dataset to Windows. It appears that few (maybe no) other ftp servers implement the STRU R command. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: REFM=VB Binary upload problem
I don't remember all the details but you might try using STRU R setting in the ftp for the binary VB file and see if you can get better results. I believe we used this for binary VB files exchanged between MVS and open-system. However, you still have the interpretation translation problem - what do the bits mean on the platform where they reside? Sorry to be so sketchy but hth somewhat. Regards, Joe Joe Peresich Northwest Regional Data Center 2048 East Paul Dirac Drive Tallahassee, FL 32310 850-245-3527 Sun:205-3527 www.nwrdc.fsu.edu -- Date:Sun, 18 Nov 2007 01:43:07 +0800 From:Tommy Tsui [EMAIL PROTECTED] Subject: Re: REFM=VB Binary upload problem why the FTP command does not works.QUOTE SITE RDW RECFM=VB LRECL=1024 anyone know why -- 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: REFM=VB Binary upload problem
If you want to transfer a binary file from z/OS to z/OS with non-z/OS intermediate nodes, then I'd strongly suggest that you use QUOTE SITE STRU R to use record structure. This encodes the file so that record boundries are kept. I've done this to transfer files in the past from z/OS to Windows, back to z/OS. The binary file is not readily usable on the intermediate nodes due to the encoding. -- I tried pulling the file down and pushing the file back up using a command window from M$ Windows and it worked as indicated (the file matched once re-uploaded). I tried various incarnations from an MVS batch job and have had no luck at all. Is there a way to do this from an MVS batch job or TSO FTP ( where I guess MVS is the client instead of the server)? If not I guess I will have to continue using XMIT and/or TERSE were applicable but for smaller files it would be nice to eliminate the extra step and be able to submit batch jobs from our MVS scheduling package. Thank you, Greg -- 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: REFM=VB Binary upload problem
Not sure, but may want to try putting the following before the GET or Put statements. It's what I use when transferring from Z/Os to another Z/Os directly. structure record ebcdic Here is a sample from a job I used to transfer command tables from one zOS box to the one the job is running on. //STEP1B EXEC PGM=FTP //SYSPRINT DD SYSOUT=* //OUTPUT DD SYSOUT=* //INPUTDD * *sitename* (exit *userid* *password* lcd 'SDEV.ISPF.ISPTLIB' cd 'SDEV.ISPF.ISPTLIB' structure record ebcdic get PANVCMDS (REPLACE get USRCMDS (REPLACE quit /* -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Greg Saccomanno Sent: Monday, November 19, 2007 4:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: REFM=VB Binary upload problem If you want to transfer a binary file from z/OS to z/OS with non-z/OS intermediate nodes, then I'd strongly suggest that you use QUOTE SITE STRU R to use record structure. This encodes the file so that record boundries are kept. I've done this to transfer files in the past from z/OS to Windows, back to z/OS. The binary file is not readily usable on the intermediate nodes due to the encoding. -- I tried pulling the file down and pushing the file back up using a command window from M$ Windows and it worked as indicated (the file matched once re-uploaded). I tried various incarnations from an MVS batch job and have had no luck at all. Is there a way to do this from an MVS batch job or TSO FTP ( where I guess MVS is the client instead of the server)? If not I guess I will have to continue using XMIT and/or TERSE were applicable but for smaller files it would be nice to eliminate the extra step and be able to submit batch jobs from our MVS scheduling package. Thank you, Greg -- 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
Re: REFM=VB Binary upload problem
On Mon, 19 Nov 2007 18:10:09 -0600, Greg Saccomanno wrote: QUOTE SITE STRU R I tried pulling the file down and pushing the file back up using a command window from M$ Windows and it worked as indicated (the file matched once re-uploaded). I tried various incarnations from an MVS batch job and have had no luck at all. Is there a way to do this from an MVS batch job or TSO FTP ( where I guess MVS is the client instead of the server)? If not I guess I will have to continue using XMIT and/or TERSE were applicable but for smaller files it would be nice to eliminate the extra step and be able to submit batch jobs from our MVS scheduling package. I would expect you can submit multiple step jobs from the scheduling package. Otherwise, you still need multiple copies, but you can do it all within MVS FTP by using an MVS server (untested): //PUT EXEC PGM=FTP,PARM='127.0.0.1 (EXIT' //TEMPFILE DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //INPUT DD * ebcdic quote site stru R get INPUT.DATA.SET.NAME //DD:TEMPFILE close open open.system binary put //DD:TEMPFILE remote.file.name Reload by reversing the process: //GET EXEC PGM=FTP,PARM='OPEN.SYSTEM (EXIT' //TEMPFILE DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //INPUT DD * binary quote site stru R get remote.file.name //DD:TEMPFILE close open 127.0.0.1 ebcdic quote site stru R put //DD:TEMPFILE OUTPUT.DATA.SET.NAME -- 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: REFM=VB Binary upload problem
why the FTP command does not works.QUOTE SITE RDW RECFM=VB LRECL=1024 anyone know why On 11/16/07, McKown, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Magee Sent: Friday, November 16, 2007 9:36 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: REFM=VB Binary upload problem Another method would be to use DSS to create an archive and then terse it with TRSMAIN. Reverse the process once the tersed file reaches its destination z/OS system. Good point! And the plus is that the tersed file can be quite a bit smaller, which reduces the transmission time. Of course, it takes CPU to terse/unterse the file. There's always a trade-off. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: REFM=VB Binary upload problem
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Magee Sent: Friday, November 16, 2007 9:36 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: REFM=VB Binary upload problem Another method would be to use DSS to create an archive and then terse it with TRSMAIN. Reverse the process once the tersed file reaches its destination z/OS system. Good point! And the plus is that the tersed file can be quite a bit smaller, which reduces the transmission time. Of course, it takes CPU to terse/unterse the file. There's always a trade-off. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: REFM=VB Binary upload problem
Another method would be to use DSS to create an archive and then terse it with TRSMAIN. Reverse the process once the tersed file reaches its destination z/OS system. -- 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: REFM=VB Binary upload problem
On Thu, 15 Nov 2007 14:05:06 +0800, Tommy Tsui wrote: Actually, I have problem when I re-uploading the same file to HOST, The record format is VB and is not one by one after uploaded. OK. Let's start with the details. What tool(s) did you use for the download and upload? (I didn't ask; you didn't tell.) Did the data appear one by one on the OPEN system after downloading? On Thu, 15 Nov 2007 12:02:52 +0800, Tommy Tsui wrote: When I try to download the file with VB format from HOST to OPEN system (binary mode) , it's ok and I found a problem when I try to upload the same file to HOST with binary format. The file are not in sequence and it seems the 4 byte RDW are missing. Is there any other way? -- 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: REFM=VB Binary upload problem
Also, be sure that the site default is RDW or issue QUOTE SITE RDW so the HOST side preserves the RDW. Paul Gilmartin wrote: On Thu, 15 Nov 2007 14:05:06 +0800, Tommy Tsui wrote: Actually, I have problem when I re-uploading the same file to HOST, The record format is VB and is not one by one after uploaded. OK. Let's start with the details. What tool(s) did you use for the download and upload? (I didn't ask; you didn't tell.) Did the data appear one by one on the OPEN system after downloading? On Thu, 15 Nov 2007 12:02:52 +0800, Tommy Tsui wrote: When I try to download the file with VB format from HOST to OPEN system (binary mode) , it's ok and I found a problem when I try to upload the same file to HOST with binary format. The file are not in sequence and it seems the 4 byte RDW are missing. Is there any other way? -- 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 -- 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: REFM=VB Binary upload problem
-Original Message- From: Tommy Tsui [mailto:[EMAIL PROTECTED] Sent: Thursday, November 15, 2007 1:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: REFM=VB Binary upload problem Actually, I have problem when I re-uploading the same file to HOST, The record format is VB and is not one by one after uploaded. The only way I know of to guarantee you get the same file back with the same characteristics when there are non-IBM systems in between is to: 1. use XMIT to convert the VB file to a sequential XMIT-format file (RECFM=FB, LRECL=80, BLKSIZE=3120) 2. transfer the XMIT file (RECFM=FB, LRECL=80, BLKSIZE=3120) in binary mode to your open system 3. transfer the XMIT file from the open system to your (other?) host system (RECFM=FB, LRECL=80, BLKSIZE=3120) 4. use RECEIVE on the host to convert the XMIT file back to VB There are minor gotchas and watchfors, but that's the major outline. HTH Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: REFM=VB Binary upload problem
If you download a VB dataset with: bin quote site rdw then you will get binary data with IBM RDWs inlined. then to upload: bin quote site rdw quote site recfm=vb On Nov 15, 2007 9:10 AM, Farley, Peter x23353 [EMAIL PROTECTED] wrote: -Original Message- From: Tommy Tsui [mailto:[EMAIL PROTECTED] Sent: Thursday, November 15, 2007 1:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: REFM=VB Binary upload problem Actually, I have problem when I re-uploading the same file to HOST, The record format is VB and is not one by one after uploaded. The only way I know of to guarantee you get the same file back with the same characteristics when there are non-IBM systems in between is to: 1. use XMIT to convert the VB file to a sequential XMIT-format file (RECFM=FB, LRECL=80, BLKSIZE=3120) 2. transfer the XMIT file (RECFM=FB, LRECL=80, BLKSIZE=3120) in binary mode to your open system 3. transfer the XMIT file from the open system to your (other?) host system (RECFM=FB, LRECL=80, BLKSIZE=3120) 4. use RECEIVE on the host to convert the XMIT file back to VB There are minor gotchas and watchfors, but that's the major outline. HTH Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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
Re: REFM=VB Binary upload problem
On 15 Nov 2007 08:46:54 -0800, [EMAIL PROTECTED] (Kirk Wolf) wrote: If you download a VB dataset with: bin quote site rdw then you will get binary data with IBM RDWs inlined. then to upload: bin quote site rdw quote site recfm=vb I just tried your suggestion, but my results weren't quite what we might have expected. My test involved downloading a member of a PDSE having the attributes DSORG=PO,RECFM=VB,LRECL=255,BLKSIZE=32760. When I uploaded my test data back to the mainframe, the RDWs were included as part of the data and the original record boundaries were lost. Here's my FTP session: 230 ERIC1 is logged on. Working directory is ERIC1.. ftp cd misc.text 250 The working directory ERIC1.MISC.TEXT is a partitioned data set ftp bin 200 Representation type is Image ftp quote site rdw 200 SITE command was accepted ftp get create 200 Port request OK. 125 Sending data set ERIC1.MISC.TEXT(CREATE) 250 Transfer completed successfully. ftp: 469 bytes received in 0.01Seconds 31.27Kbytes/sec. ftp quote site recfm=vb 200 SITE command was accepted ftp put create temp 200 Port request OK. 125 Storing data set ERIC1.MISC.TEXT(TEMP) 250 Transfer completed successfully. ftp: 469 bytes sent in 0.00Seconds 469000.00Kbytes/sec. Eric -- Eric Chevalier E-mail: [EMAIL PROTECTED] Web: www.tulsagrammer.com Is that call really worth your child's life? HANG UP AND DRIVE! -- 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: REFM=VB Binary upload problem
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Eric Chevalier Sent: Thursday, November 15, 2007 11:51 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: REFM=VB Binary upload problem On 15 Nov 2007 08:46:54 -0800, [EMAIL PROTECTED] (Kirk Wolf) wrote: If you download a VB dataset with: bin quote site rdw then you will get binary data with IBM RDWs inlined. then to upload: bin quote site rdw quote site recfm=vb I just tried your suggestion, but my results weren't quite what we might have expected. My test involved downloading a member of a PDSE having the attributes DSORG=PO,RECFM=VB,LRECL=255,BLKSIZE=32760. When I uploaded my test data back to the mainframe, the RDWs were included as part of the data and the original record boundaries were lost. Here's my FTP session: 230 ERIC1 is logged on. Working directory is ERIC1.. ftp cd misc.text 250 The working directory ERIC1.MISC.TEXT is a partitioned data set ftp bin 200 Representation type is Image ftp quote site rdw 200 SITE command was accepted ftp get create 200 Port request OK. 125 Sending data set ERIC1.MISC.TEXT(CREATE) 250 Transfer completed successfully. ftp: 469 bytes received in 0.01Seconds 31.27Kbytes/sec. ftp quote site recfm=vb 200 SITE command was accepted ftp put create temp 200 Port request OK. 125 Storing data set ERIC1.MISC.TEXT(TEMP) 250 Transfer completed successfully. ftp: 469 bytes sent in 0.00Seconds 469000.00Kbytes/sec. Eric -- Eric Chevalier E-mail: [EMAIL PROTECTED] If you want to transfer a binary file from z/OS to z/OS with non-z/OS intermediate nodes, then I'd strongly suggest that you use QUOTE SITE STRU R to use record structure. This encodes the file so that record boundries are kept. I've done this to transfer files in the past from z/OS to Windows, back to z/OS. The binary file is not readily usable on the intermediate nodes due to the encoding. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: REFM=VB Binary upload problem
On Thu, 15 Nov 2007 12:02:52 +0800, Tommy Tsui wrote: When I try to download the file with VB format from HOST to OPEN system (binary mode) , it's ok and I found a problem when I try to upload the same file to HOST with binary format. The file are not in sequence and it seems the 4 byte RDW are missing. Is there any other way? You need to issue the command, quote site recfm=vb ... did you do that? Even so, this sequence of operations will likely lose the original positions of the logical record boundaries. However, if it's ok as you say after download to the OPEN system which has no logical record structure, the logical record boundaries must be inconsequential, and it shouldn't matter where they are after re-uploading to the HOST. -- 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
