FTP variable block dataset from z/OS to Windows and back

[Gilbert Cardenas]

Does anyone know if the following limitation still applies?
http://www-01.ibm.com/support/docview.wss?uid=swg21188301

I have a request to ftp a z/OS variable blocked dataset to a windows server and then be able to ftp that dataset back to a z/OS system. I am not privy to all the details about why they want to do this, just been asked if it is possible to do? I'm guessing they want to make some minor tweaks to the dataset and re-upload.

Anyhow, can this be done and if so, can you share any samples?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[John P Kalinich]

Gilbert,

If there is no binary data in the file it should work.

Regards,
John K

[John McKown]

Have you looked at the

LOCSITE RDW

ftp command? It works for binary transfers. It actually sends (or
receives) the 4 byte RDW

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b990/5.36

<quote>
RDW
Specifies that variable record descriptor words (RDWs) are treated as
if they were part of the record and are not discarded during FTP
transmission of variable format data sets. This applies to transfers
in stream mode only.
Note: RDW information is stored in binary format. Transfer files in
binary mode to avoid the translation problems that can occur if you
transfer this binary field in EBCDIC or ASCII mode.
</quote>

--
Maranatha! <><
John McKown

[Elardus Engelbrecht]

Gilbert Cardenas wrote:
>> I have a request to ftp a z/OS variable blocked dataset to a windows server and then be able to ftp that dataset back to a z/OS system.

Why this route z/OS -> win -> z/OS?

Try this (this is what I use to FTP my SMF data everyday from z/OS to z/OS (excluding windoze of course) ):

LOCSITE RDW <--- most important! (See John McKown reply)
LOCSITE RECFM=VBS
LOCSITE LRECL=??

You may need SITE RDW, SITE RECFM=VBS, etc.

Since you did not mentioned any translation, I would suggest you look at these two commands:
MODE B
EBCDIC

HTH!

Groete / Greetings
Elardus Engelbrecht

[Paul Gilmartin]

On Thu, 10 Jan 2013 08:31:11 -0600, John McKown wrote:

>Have you looked at the
>
>LOCSITE RDW
>
>ftp command? It works for binary transfers. It actually sends (or
>receives) the 4 byte RDW
>
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b990/5.36
>
><quote>
>RDW
>Specifies that variable record descriptor words (RDWs) are treated as
>if they were part of the record and are not discarded during FTP

>transmission of variable format data sets. ...
></quote>
>
It should, but, NO! The last time I tried this, it correctly placed the
RDWs in the stream going from z to Open, but coming back from
Open to Z, the "(RDWs) are treated as if they were part of the
record" and become part of the data, not RDWs in the reloaded
data set.

Evidently some coder took the spec excessively literally, and made
RDWs part of the data in both transfer directions.

Perhaps it has been fixed. You can try a PMR. Likely they'll say
WAD, quote the manual text, and plead compatibility impacts.

Manifestly they never validated the implementation against the
objective. Morons.

TERSE; upload. Download; deTERSE. A PITA for your user.

-- gil

[Gilbert Cardenas]

Sorry, z/os to z/os is not an option. Apparently these are AFP datasets. I tried using the
BIN
LOCSITE RDW on the FTP download to windows and then the LOCSITE RECFM=VB on the get from the mainframe but the new dataset appears to be one long record and the record layout is lost. It also appears that the RDW info is appended to the front of the new dataset.

[Paul Gilmartin]

On Thu, 10 Jan 2013 09:19:01 -0600, Gilbert Cardenas wrote:

>Sorry, z/os to z/os is not an option. Apparently these are AFP datasets. I tried using the
>BIN
>LOCSITE RDW on the FTP download to windows and then the LOCSITE RECFM=VB on the get from the mainframe but the new dataset appears to be one long record and the record layout is lost. It also appears that the RDW info is appended to the front of the new dataset.
>

Did you use LOCSITE RDW in both directions? In my experience, even that
fails, although I'd expect it to work. It's a BUG!

I know ways to cheat it if I have a z/OS server and OS X/Linux/DOS client
for both transfers, but that's likely not what your customer needs.

-- gil

[Barry Merrill]

You can't pass a V/VB/VBS file in and out of windows
or unix unless it is tersed or XMIT Manager'd at both
ends, or unless you write a program to reconstruct the
raw records after uploaded to the second z/OS.

Windows/Unix/Linux etc. have no knowledge of records and
will store the file as a serial stream of bytes,
(AND ONLY IF THE FILE IS RECFM=U will the BDW and RDW
be included in that serial stream of bytes - ftp will
show you how smart it is by stripping the BDW and RDW
and only downloading the data portion of V/VB/VBS records).

While you can then upload them into a z/OS file, there
is no intelligence to create records going back to z/OS.

MXG sites can use SAS and MXG's UDEBLOCK on z/OS,
or the ASM program ASMDBLKU if you don't have z/OS SAS,
to rebuild the BDW/RDWs in the serial file that was
uploaded into a RECFM=U file. Those programs exist
for users who execute MXG on ascii, using the SAS ftp
access method to directly read the z/OS file, who
also store a backup of that SMF file on ascii, in
case IBM needs to see that original SMF file.

Barry


Herbert W. Barry Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas TX 75229
214 351 1966 tel
214 350 3695 fax
www.mxg.com

[Gilbert Cardenas]

Hi Gil, yes I did try using RDW both ways and it still fails. The output is one long line with no crlfs to separate the records.

I think that's what IBM was alluding to in ftp'ing the dataset to the HFS and then back to the mainframe, but as you stated, that is not an option for the customer.

[Gilbert Cardenas]

Barry said:
"You can't pass a V/VB/VBS file in and out of windows or unix unless it is tersed or XMIT Manager'd at both
ends, or unless you write a program to reconstruct the raw records after uploaded to the second z/OS."

Sorry Barry, can you please elaborate, are you saying that if I terse the VB dataset on the mainframe before ftp'ing it to the windows server, I should be able to re-upload to the mainframe correctly or did I missing something?

[Lizette Koehler]

A process I use is to either do one of the following to the file on z/OS before FTP

TSO XMIT
DFDSS
TRSMAIN

Then download to the pc with BIN

Then upload the z/OS with Bin

Then reverse the process used to format the file with TSO XMIT, DFDSS, TRSMAIN

This usually works for most file types.

Lizette

[Barry Merrill]

Yes, that is correct, you must TERSE first on the sending
z/OS then ftp to windows then ftp up to the second z/OS
and then UNTERSE.

This works because TERSED output file is FB, and ftp can't
muck up the BDW and RDW since there aren't any in the FB
file (and Unterse knows about BDWs and RDWs).

Barry

[Gilbert Cardenas]

Thanks Barry/Liz, et.al, I'll give this a try.

[Miklos Szigetvari]

Hi

If you not insists to FTP, the old IND$FILE can do this with binary mode
and CR/LF . During UPLOAD the
CR/LF data in the datastream can cause extra breaks, but the IBM has an
AFPREBLK REXX exec to correct this (not sure now if AFPREBLK or AFRREBLK
) from the AFP Workbench.
I can send you off-list if you need .
(I don't remember, if the AFPREBLK can cope with binary FTP stream)

[retired mainframer]

You have received a couple of ideas to solve the transfer problem. It's
your last sentence I'm concerned about. If the minor tweaks are strictly
limited to a character by character substitution (one for one) it may be OK
(obviously not if the dataset contains a checksum). But if any substitution
changes the number of characters in a "record", it will mess up
XMIT/RECEIVE, TERSE, and/or the BDW/RDW to render the data unreadable by
normal z/OS I/O.

And then there is my paranoid concern regarding why someone is altering a
mainframe dataset to make it look like the mainframe has the wrong data.
Data received from a Windows system should be easily identified as such so
problems with the data can be addressed on the system that created it.

:>: -----Original Message-----

:>: From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
:>: Behalf Of Gilbert Cardenas

:>: Sent: Thursday, January 10, 2013 6:11 AM
:>: To: IBM-...@LISTSERV.UA.EDU
:>: Subject: FTP variable block dataset from z/OS to Windows and back
:>:
:>: Does anyone know if the following limitation still applies?

[Paul Gilmartin]

On Thu, 10 Jan 2013 09:24:13 -0600, Paul Gilmartin wrote:
>
>I know ways to cheat it if I have a z/OS server and OS X/Linux/DOS client
>for both transfers, but that's likely not what your customer needs.
>

Someone asked me a question about this privately, so I'm replying
to myself. I tried (schematically):

ftp MVS
...
binary

quote type E
quote mode B

cd OLD.VBPDS
get MEMBER

cd NEW.VBPDS
put MEMBER

Drat! It almost worked, but not quite. Empty lines in the
OLD were converted to blanks in the NEW. I consider
this an integrity flaw. Why, why, why can't IBM refrain from
its compulsion to munge users' data!

(Is there a setting to control this? And if there is, the default
is wrong.)

-- gil

[Roger Bolan]

Gilbert,
I move AFP files all the time. Of the 3 methods mentioned in your
reference,
http://www-01.ibm.com/support/docview.wss?uid=swg21188301 ,
I use Method 3, tersing, the most. It seems the easiest and most
foolproof to me. You just terse the original file, then make sure all
transfers are done in binary mode, not text, and unterse the file on the
new z/OS system. For the final FTP upload, I specify something like
SITE RECFM=FB LRECL=1024 BLKSIZE=0 CYLINDERS PRIMARY=10 SECONDARY=10
where you adjust the size to fit your requirements. Then I do my binary
FTP upload to z/OS. Untersing the data set restores the original DCB
attributes.

AFRREBLK is for fixing untersed binary AFP files that have been uploaded
from a non-MVS system. If you have PSF, you should find
SYS1.SAPSEXEC(AFRREBLK) and the sample profile SYS1.SAMPLIB(AFRREBLK).
Read the comments inside the exec for usage details.

Text files are a little more forgiving, but I occasionally get one somebody
has sent to me that is all one long wrapped file. Chances are it has CRLF
type characters in it. One way to fix some of those files is to use the
OMVS system to split it. I have a little exec like this:
BROWSE BOLAN.MY.CLIST(SPLIT) - 01.02 Line 00000000 Col 0
Command ===> Scroll ===
********************************* Top of Data ***************************
/* REXX COMMAND TO FIX UNSPLIT HFS FILES */
/* Roger Bolan May 18, 2010 */
Trace C
ADDRESS tso
PARSE ARG olddsn
if olddsn = '?' then call explain
stripdsn = Strip(olddsn,'B',"'")
"OPUT '"||stripdsn||"' '/tmp/"||stripdsn||"'"
"OGET '/tmp/"||stripdsn||"' '"||stripdsn||"'" "TEXT"
"OSHELL rm /tmp/"||stripdsn
return RC
explain:
say 'Use from ISPF 3.4'
say 'Example format: %split / '
say 'use / to enter the quoted fully qualified name from ISPF 3.4'
exit 0

Sometimes text files have only a x'15' or x'25' byte dividing the original
records. I have a VM system too, so I use pipe commands, like the
following excerpts, sometimes.

/* splits on 0x15 */
'PIPE <' fn ft fm '| DEBLOCK LINEEND | >' fn ft 'A'

/* splits on x'25'*/
'PIPE <' fn ft fm '| DEBLOCK C | >' fn 'SPLIT A'

Regards,
--Roger

[Gilbert Cardenas]

You are correct Roger, the terse/ftp/ftp/unterse did work. It does add an extra layer of complexity to the process though and is not as straightforward as an FTP to pc and then back to MF.

I'm am not privy to all of the information around why they want to do this but apparently, the OP has already found another possible solution and that is to use the STRucture RECORD type.

Apparently the RECORD type adds a End-of-Record (x'FF01') but they think they can work around this.

I was just trying to help a friend with this delimna but they seemed to possibly have found a work around using STRucture RECORD.

[Roger Bolan]

I'm curious about how they used RECORD or STRUC R to do what they wanted.
I haven't played with it, but my initial impression was that STRUCTURE
RECORD might work if you were going from z/OS FTP to another z/OS FTP, but
that the structure information might be lost if there were other non-MVS
systems in the path. I could be wrong about that. I'd like to know.
Regards,
--Roger

[Gibney, Dave]

For a VB(S) file, ftp from z to Windows or *nix, plus change the data on Windows/*nix and return to z via ftp (or ind$file) is going to require specific programming to adjust and possibly restore the BDW/RDW structure of the final file. It's really not that hard a program to write :)

Dave Gibney
Information Technology Services
Washington State University

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of Gilbert Cardenas

> Sent: Thursday, January 10, 2013 10:16 AM
> To: IBM-...@LISTSERV.UA.EDU

[Paul Gilmartin]

On Thu, 10 Jan 2013 11:50:15 -0700, Roger Bolan wrote:

>I'm curious about how they used RECORD or STRUC R to do what they wanted.
>I haven't played with it, but my initial impression was that STRUCTURE
>RECORD might work if you were going from z/OS FTP to another z/OS FTP, but
>that the structure information might be lost if there were other non-MVS
>systems in the path. I could be wrong about that. I'd like to know.
>

The ugly truth:

Command:
quote syst
>>> syst
215 UNIX Type: L8 Version: SUNOS
Command:
record
>>> STRU R
504 Unimplemented STRU type.
Command:

... notwithstanding that it's specified in RFC 959.

-- gil

[John McKown]

Same happens with the Linux ftp client and the vsftpd server. Neither
understands RECORD structure and rejects the command.

--
Maranatha! <><
John McKown

[Ed Gould]

John:

But in VB type datasets there is always binary data in the RR portion
of the record.

Ed

[John P Kalinich]

Ed,

The BDW/RDW data does not get transferred.

Regards,
John K

[Gilbert Cardenas]

I don't know if this is how the OP did it but this was the procedure I used...
From a windows server:

1. Open FTP session to the mainframe and issue
BINary
QUOTE STRU R
GET 'MAINFRAME.DATASET' PC.DATASET.NAME
QUIT

2. To upload file back to mainframe, open FTP session to mainframe and issue
BINary
quote STRU R
quote site RECFM=VB
quote site LRECL=??? (932 in my case)
quote site BLOCKSIZE=????? (27998 in my case)
quote site FILEtype=SEQ
PUT PC.DATASET.NAME 'MAINFRAME.DATASET.NAME'
QUIT

Did a ISRSUPC compare and there were no differences.

[Paul Gilmartin]

Didn't work for me.

On Thu, 10 Jan 2013 14:32:56 -0600, Gilbert Cardenas wrote:

>I don't know if this is how the OP did it but this was the procedure I used...
>From a windows server:
>
>1. Open FTP session to the mainframe and issue
>BINary
>QUOTE STRU R
>GET 'MAINFRAME.DATASET' PC.DATASET.NAME
>QUIT
>
>2. To upload file back to mainframe, open FTP session to mainframe and issue
>BINary
>quote STRU R
>quote site RECFM=VB
>quote site LRECL=??? (932 in my case)
>quote site BLOCKSIZE=????? (27998 in my case)
>quote site FILEtype=SEQ
>PUT PC.DATASET.NAME 'MAINFRAME.DATASET.NAME'
>QUIT
>
>Did a ISRSUPC compare and there were no differences.
>

Didn't work for me. Once again, empty lines were changed to blanks.

Perhaps your test case contains no empty lines. Have you checked?

And ISRSUPC is broken.

-- gil

[Gilbert Cardenas]

Granted, I did not do extensive testing. I simply used a DCOLLECT dataset which is variable blocked and probably does not contain any blank lines.

If I have time, I'll try to hunt down one that has blank lines in it and see what results I get.

[Steven St.Jean]

Gil,

> The ugly truth:

> >>> STRU R
> 504 Unimplemented STRU type.

Depending on what the OP wants to do with the file on the Windows system, it may not matter that it does not support STRU R. The important thing is that z/OS does. If the primary goal is what we used to call "invertibility" -- getting the file back exactly as it started out -- STRU R with binary should work. You just have to make sure you tell it to the z/OS side on both transfers.

Consider the following example. At the end of this exercise, IP.PKTTRACE and IP.PKTTRACE.COPY are identical data sets:

ftp> dir ip.pkttrace.*
200 Port request OK.
125 List started OK
Volume Unit Referred Ext Used Recfm Lrecl BlkSz Dsorg Dsname
SDSMVO 3390 2013/01/10 1 2 VB 27994 27998 PS IP.PKTTRACE
250 List completed successfully.
ftp: 137 bytes received in 0.00Seconds 137.00Kbytes/sec.
ftp> quote site lrecl=27994 blks=27998 recfm=vb
200 SITE command was accepted
ftp> binary
200 Representation type is Image
ftp> quote stru r
250 Data structure is Record
ftp> get ip.pkttrace
200 Port request OK.
125 Sending data set BSSJ1.IP.PKTTRACE
250 Transfer completed successfully.
ftp: 77311 bytes received in 0.28Seconds 275.13Kbytes/sec.

ftp> quote site lrecl=27994 blks=27998 recfm=vb
200 SITE command was accepted
ftp> binary
200 Representation type is Image
ftp> quote stru r
250 Data structure is Record
ftp> put ip.pkttrace ip.pkttrace.copy
200 Port request OK.
125 Storing data set BSSJ1.IP.PKTTRACE.COPY
250 Transfer completed successfully.
ftp: 77311 bytes sent in 0.37Seconds 206.71Kbytes/sec.
ftp> dir ip.pkttrace.*
200 Port request OK.
125 List started OK
Volume Unit Referred Ext Used Recfm Lrecl BlkSz Dsorg Dsname
SDSMVO 3390 2013/01/10 1 2 VB 27994 27998 PS IP.PKTTRACE
SDSMVN 3390 2013/01/10 2 2 VB 27994 27998 PS IP.PKTTRACE.COPY
250 List completed successfully.
ftp: 214 bytes received in 0.00Seconds 53.50Kbytes/sec.

Best,
Steven St.Jean

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On

> Behalf Of Paul Gilmartin
> Sent: Thursday, January 10, 2013 2:55 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: FTP variable block dataset from z/OS to Windows and back
>

[Ed Gould]

John,

That is contrary to what I have experienced.

Ed

[Paul Gilmartin]

On Thu, 10 Jan 2013 22:13:51 -0600, Ed Gould wrote:
>
>That is contrary to what I have experienced.
>

What options? Certainly if you specify RDW. Otherwise, give
an example, with hex dump.

Of course, if you transfer z/OS to Z/OS with TYPE ASII, the
RDWs are not transmitted, but reconstructed at the receiving
end.

On Thu, 10 Jan 2013 20:28:26 -0500, Steven St.Jean wrote:
>Gil,
>
>> The ugly truth:
>
>> >>> STRU R
>> 504 Unimplemented STRU type.
>
>Depending on what the OP wants to do with the file on the Windows system, it may not matter that it does not support STRU R. The important thing is that z/OS does. If the primary goal is what we used to call "invertibility" -- getting the file back exactly as it started out -- STRU R with binary should work. You just have to make sure you tell it to the z/OS side on both transfers.
>

It would seem so, but as I reported earlier in this thread, it doesn't work.
Empty records are corrupted; I don't get "the file back exactly as it started
out". I suspect this is purely a z/OS flaw, and it might occur even
transferring directly z/OS to z/OS with STRU R.

BTW, I understand how this process works with Windows client and z/OS
server. Can it be done likewise with z/OS client and Windows server
(which seemed to be the OP's requirement)? IOW, is there a LOCSTRU
or LOCSITE STRU R type command to allow the Windows server to
operate in BINARY mode and the z/OS client in RECORD?

An immodest proposal: Does anyone want to write the requirement for:

SITE AMATERSE and LOCSITE AMATERSE, and/or
SITE TSOXMIT and LOCSITE TSOXMIT?

-- gil

[John P Kalinich]

It may get transferred on a BINARY FTP but not on ASCII.

Regards,
John K

-----IBM Mainframe Discussion List <IBM-...@listserv.ua.edu> wrote: -----
To: IBM-...@listserv.ua.edu
From: Ed Gould

Sent by: IBM Mainframe Discussion List

Date: 01/10/2013 10:14PM

Subject: Re: FTP variable block dataset from z/OS to Windows and back

John,

That is contrary to what I have experienced.

Ed

On Jan 10, 2013, at 2:13 PM, John P Kalinich wrote:

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

[Shmuel Metz , Seymour J.]

In <2099607434784895.WA...@listserv.ua.edu>, on
01/10/2013

at 01:55 PM, Paul Gilmartin <PaulGB...@AIM.COM> said:

>... notwithstanding that it's specified in RFC 959.

RFC 959 allows 504 for STRU.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

[Steven St.Jean]

Gil,

> It would seem so, but as I reported earlier in this thread, it doesn't
> work.
> Empty records are corrupted; I don't get "the file back exactly as it
> started out".

Sorry, I missed that.

> I suspect this is purely a z/OS flaw,

I agree. If it does indeed work (or fail to work) as you describe, I would open a PMR with z/OS Comm Server.

Best,
Steven St.Jean


> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin

> Sent: Friday, January 11, 2013 12:58 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: FTP variable block dataset from z/OS to Windows and back
>

[Paul Gilmartin]

On Fri, 11 Jan 2013 08:18:37 -0500, Steven St.Jean wrote:

>Gil,
>

>> It would seem so, but as I reported earlier in this thread, it doesn't
>> work.
>> Empty records are corrupted; I don't get "the file back exactly as it
>> started out".
>
>Sorry, I missed that.
>
>> I suspect this is purely a z/OS flaw,
>
>I agree. If it does indeed work (or fail to work) as you describe, I would open a PMR with z/OS Comm Server.
>

WAD is highly likey for this. It's easy to suspect that there's
a common subroutine to add record to target file, called for
all transfer modes, that converts empty records to spaces.
And that behavior may have been inherited from VM/CMS
where empty records are strictly prohibited by the file system.

And they might consider it an incompatible behavior. It might
break end user code that does LH; BCTR; EX; MVC to copy
variable length records. Same reason that ISPF/PDF changes
empty records even with SET PRESERVE ON.

[Kirk Wolf]

I'm not sure if it is related, but the IBM C library has a wierd feature
(bug) - search the IBM C/C++ Programmers Guide for "_EDC_ZERO_RECLEN".
Warning: the documentation is pretty confusing.

[Paul Gilmartin]

On Fri, 11 Jan 2013 10:27:38 -0600, Kirk Wolf wrote:

>I'm not sure if it is related, but the IBM C library has a wierd feature
>(bug) - search the IBM C/C++ Programmers Guide for "_EDC_ZERO_RECLEN".
>Warning: the documentation is pretty confusing.
>

Yah. This is an environment variable documented as affecting the
z/OS UNIX commands CP and MV. What's truly dreadful is that the
default is the less UNIX-like behavior. So FTP might be making an
accommodation for this.

How does this affect Co:Z?

But, yes, "bug". Although ANSI C waffles in order to accommodate
RECFM=F and filesystems such as VM/CMS MDFS which tolerates
neither empty files nor empty lines.

[Steven St.Jean]

> WAD is highly likey for this. It's easy to suspect that there's a common
> subroutine to add record to target file, called for all transfer modes,
> that converts empty records to spaces.

This might make sense for FB files, but not for VB, especially in binary mode. The FTP server has no grounds to decide that a space represents "emptiness".

An FTP server has no business using a common subroutine for all transfer modes. Data transformation is half the job. (I know; I used to be responsible for one.)

> And they might consider it an incompatible behavior. It might break end

> user code...

If end-user code cannot handle empty VB records, the code would obviously have the same problem with original file.

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, January 11, 2013 11:02 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: FTP variable block dataset from z/OS to Windows and back
>

[Paul Gilmartin]

On Fri, 11 Jan 2013 11:53:02 -0500, Steven St.Jean wrote:
>
>An FTP server has no business using a common subroutine for all transfer modes. Data transformation is half the job. (I know; I used to be responsible for one.)
>

Granted, but:

>> And they might consider it an incompatible behavior. It might break end
>> user code...
>
>If end-user code cannot handle empty VB records, the code would obviously have the same problem with original file.
>

If the file originated on a non-IBM platform the rules might have been
different there. Surely no BCTR; EX; MVC problems.

[Steven St.Jean]

> If the file originated on a non-IBM platform the rules might have been
> different there.

Not to be a last word freak, but we're discussing the behavior of z/OS Comm Server when storing data in its own file system. The rules for processing data on non-IBM platforms don’t enter into it.

Maybe I should open that PMR myself.

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, January 11, 2013 12:47 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: FTP variable block dataset from z/OS to Windows and back
>