NFS problem with CRLF - NFS

This is a discussion on NFS problem with CRLF - NFS ; I have a file on the Mainframe that I NFS it down to the PC. It's a 300 byte file. When I look at it on the PC with a HEX Editor I notice that it puts a LineFeed Character ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: NFS problem with CRLF

  1. NFS problem with CRLF

    I have a file on the Mainframe that I NFS it down to the PC. It's a
    300 byte file. When I look at it on the PC with a HEX Editor I notice
    that it puts a LineFeed Character (0A in Hex) at the end of the
    record. What I need it to put is CR AND LF (0D and 0A). How do I go
    about doing this without increasing the file size? With FTP i didn't
    have this problem since it always put a CRLF at the end.

    Can anyone please shed some light on this?

    Thanks
    Andy.

  2. Re: NFS problem with CRLF

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Andy wrote:
    > I have a file on the Mainframe that I NFS it down to the PC. It's a
    > 300 byte file. When I look at it on the PC with a HEX Editor I notice
    > that it puts a LineFeed Character (0A in Hex) at the end of the
    > record. What I need it to put is CR AND LF (0D and 0A). How do I go
    > about doing this without increasing the file size? With FTP i didn't
    > have this problem since it always put a CRLF at the end.


    You can't go about adding carriage return characters without affecting the
    file size.


    > Can anyone please shed some light on this?


    It's simple really.

    With FTP, the ftp client makes a copy of the file that's on the other system,
    and adjusts this copy to include carriage return and linefeed characters. The
    copy is written to your PC, and the original is left alone.

    With NFS, the NFS client is giving you direct access to the original file. No
    copies, no alterations, just the original file. If you want the original file
    to contain carriage return and linefeed characters, you're going to have to
    put them in yourself, either when you create the file on the mainframe, or
    with editing from your PC. In either case, the file on the mainframe will no
    longer have just linefeed characters in it, so this will impact any other
    program or user who reads the file.

    The best you can do is /copy/ the file, and make your changes to the /copy/,
    much like FTP copied the file, and made changes to the copy.

    - --
    Lew Pitcher

    Master Codewright & JOAT-in-training | GPG public key available on request
    Registered Linux User #112576 (http://counter.li.org/)
    Slackware - Because I know what I'm doing.
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.4 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

    iD8DBQFBnT/ZagVFX4UWr64RApGwAKCC4RDU1GxEXKd6kn5YCFJKqbIMOACeJ wA2
    Z65e9lWZ1uDtSIN3bXQzWsU=
    =l49M
    -----END PGP SIGNATURE-----

  3. Re: NFS problem with CRLF

    Lew Pitcher wrote:

    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Andy wrote:
    > > I have a file on the Mainframe that I NFS it down to the PC. It's a
    > > 300 byte file. When I look at it on the PC with a HEX Editor I
    > > notice that it puts a LineFeed Character (0A in Hex) at the end of
    > > the record. What I need it to put is CR AND LF (0D and 0A). How do
    > > I go about doing this without increasing the file size? With FTP i
    > > didn't have this problem since it always put a CRLF at the end.

    >
    > You can't go about adding carriage return characters without
    > affecting the file size.
    >
    >
    > > Can anyone please shed some light on this?

    >
    > It's simple really.
    >
    > With FTP, the ftp client makes a copy of the file that's on the other
    > system, and adjusts this copy to include carriage return and linefeed
    > characters. The copy is written to your PC, and the original is left
    > alone.
    >
    > With NFS, the NFS client is giving you direct access to the original
    > file. No copies, no alterations, just the original file. If you want
    > the original file to contain carriage return and linefeed characters,
    > you're going to have to put them in yourself, either when you create
    > the file on the mainframe, or with editing from your PC. In either
    > case, the file on the mainframe will no longer have just linefeed
    > characters in it, so this will impact any other program or user who
    > reads the file.
    >
    > The best you can do is copy the file, and make your changes to the
    > copy, much like FTP copied the file, and made changes to the copy.
    >
    > - --
    > Lew Pitcher
    >
    > Master Codewright & JOAT-in-training | GPG public key available on
    > request Registered Linux User #112576 (http://counter.li.org/)
    > Slackware - Because I know what I'm doing.
    > -----BEGIN PGP SIGNATURE-----
    > Version: GnuPG v1.2.4 (GNU/Linux)
    > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
    >
    > iD8DBQFBnT/ZagVFX4UWr64RApGwAKCC4RDU1GxEXKd6kn5YCFJKqbIMOACeJ wA2
    > Z65e9lWZ1uDtSIN3bXQzWsU=
    > =l49M
    > -----END PGP SIGNATURE-----


    This is a problem that has always been around. Many programmers have
    had to write programs that would read in a file and write it back out
    with desired carriage control. Typically the files came from
    mainframes or Vaxes and were needed on a PC. ftp also can give you
    undesired results. Like was said before the ftp copy would convert the
    carriage control for you, but if you put ftp in image mode with the
    binary command the carriage control would normally not be converted.

    We recently had a problem where a postscript file was needed by
    multiple apps. It needed to be printed and ftp'ed to our IIS web/ftp
    server. Ghostscript was used to open the files and they printed fine
    on a DEC Laser 3500. When the old laser printer died we went to an HP
    2200dn. This printer would not recognize the Adobe Postscript marker
    to auto switch into postscript mode so we modified it. Now ghostscript
    no longer will open the .ps files from within the IE Browser. The work
    around was we create two files. One that is sent to the printer and
    one that is sent to our IIS server.

+ Reply to Thread