On Mon, Dec 15, 2014 at 10:04 PM, Paul Edwards <mutazi...@gmail.com> wrote:
> >> I wish to distribute VB files (developed on MVS/380) via PC, > >> with z/OS as a target. I don't want BDW, just the RDW format > >> that ftp produces. I'm very happy with the RDW format that > >> IBM's ftp produces, I just want it to be reversible. > > > STRU R is reversible; RDW isn't. For your objective, the remaining > > chore would be to synthesize STRU R on OS 380. > > I now have the test results from STRU R, and here is > what it looks like: > > 000000 C8859393 9640A388 859985FF 01C69693 Hello there..Fol > 000010 92A2FF01 FF02 ks.... > > That is not even close to the RDW format that IBM > provides. I have based PDPCLIB around IBM's RDW > format. > > That STRU R format also doesn't allow data with x'ff' > in it. The RDW format does. > STRU R is_can_ transmit a x'FF'. x'FF' is to STRU R what \ is to a C compiler. It is an "escape" byte which says to treat the _next_ byte specially. In particular, a x'FF' followed by a second x'FF' represents a single x'FF'. A x'FF' followed by a x'01' specifies "end of logical record", followed by a x'02' specifies "end of file", and by a x'03' specified "end of record & file". I guess that anything else (x'04'..x'FE') after an x'FF' is a protocol error. ref: https://www.ietf.org/rfc/rfc959.txt on page 21 (this is a single web page, but formatted with page headers and footers for printing) <quote> In a record structured file EOR and EOF will each be indicated by a two-byte control code. The first byte of the control code will be all ones, the escape character. The second byte will have the low order bit on and zeros elsewhere for EOR and the second low order bit on for EOF; that is, the byte will have value 1 for EOR and value 2 for EOF. EOR and EOF may be indicated together on the last byte transmitted by turning both low order bits on (i.e., the value 3). If a byte of all one was intended to be sent as data, it should be repeated in the second byte of the control code. </quote> <snip> > > I am not interested in BDWs etc. I consider that IBM's > RDW option is an excellent choice for variable-lengthed > binary records. It produces a V-format file that can be > processed by a C program. The C program is expected > to understand what an RDW is (but not BDW etc). I > consider this to be logical and neat, and all I am after > is for the RDW option to be reversible so that F, V and > U files can all be transferred simply from mainframe > to PC and back. > > BFN. Paul. > > -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
