Conference lassie::ucx

    The problem is that when copying files from UCX to UCX, a special mode
    is used where the file's FDL is sent before the file's binary contents.
    
    The LRL (longest record length) field is maintained by RMS as records
    are inserted into the file.  It is a value that is generated from its
    experience in loading the file.
    
    When the file is written into as binary blocks (such is the case here),
    the LRL attribute is not determinable.  Note that this is an ATTRIBUTE
    on the file; it does not occupy space within the file's body.
    
    As a result, RMS writes it as zero (as it would for any block I/O
    written file).  While this causes file attribute mismatches when files
    are copied, there should be no problem accessing the file.  In
    addition, any appends which occur on the file will cause LRL to be
    updated.  In normal programming, I make accomodations for LRL, LRL=0,
    and possibly larger-than-LRL records in the file.
    
    Have you experienced any problems reading data from these files?

    hello,
    
    
    you mention VFC right?
    I do not think that FTP can handle such files!
    A file with this format (VFC) has two distinct records:
    The first one describes the print format of the file which
    is handle by VMS utilities such as print and type but
    not CONVERT or editors! and the second one is the record 
    format of the plain data. 
    So , if you use convert on this file or edit it , the first
    record is gone forever!
    To handle correctly this file format you need a program 
    doing multistreamming (one FAB and two or more RABs).
    
    regards
    Phyl(actis)

    
    First of all, when copying from UCX-to-UCX in VMS-Plus mode, the entire
    body of the file is copied.  The problem here is that the LRL attribute
    is stored in the file header, not in the body of the file.  Also, RMS
    is the one responsible for maintaining it (or anyone else who pretends
    to be RMS) and, when performing block I/O (which is what we are doing),
    RMS doesn't apply the notion of a record to the data at all.  Hence,
    LRL is not maintained (only in record mode).
    
    Secondly, as far as the VFC formatting goes, the VFC header is part of the
    record; it does not exist in a `different' record at all.  When RMS
    reads the record, it places the variable data into the buffer which you
    describe in rab$l_ubf and rab$w_usz, and the header (which is always
    fab$w_fsz bytes in size) into the buffer pointed to by rab$l_rhb.
    If fab$l_rhb is not filled in, then RMS won't return the header. That's
    why most people don't "see it"; they don't recognize the header and
    account for it.
    
    When a file is `print file format', then rab$b_rat has FAB$M_PRN set in
    it, fab$b_rsz is two, and each of the bytes in the fixed header
    describes what to place before and after each record.  Usually, you see
    a 0x01 0x8d in there, which is "insert one line feed before the record"
    (0x01), and a "carriage-return afterwards" (0x80 | 0x0d=cr).  It looks
    like the latin form of a fortran record on VMS.
    
    By the way, I don't like print file format at all.  I've had to make it
    work properly for several of the UCX components and it doesn't fit
    perfectly into the Unix concept of a stream[_LF] file.  Why this
    became the standard format of log files is beyond me.
    
    No, a file of this type has one distinct record.
    
    The FHZ (fixed header size) is an area which actually exists in the
    beginning of the record and, to read it, you must point 

    By the way, CONVERT does handle VFC files.
    
    See the /FIXED_CONTROL qualifier.
    
    (I know this because I wrote RMSCNV, the PDP-11 version of the
    utility.  Gosh, I was in my early 20s without even a hint of
    a bald spot!)

    Hi,
    
    Thankyou for your replies.
    
    Re .1 Yes, we are having problems accessing these files. A command
    procedure tries to sort the copied file(s) and gets the following
    errors:
    
    %SORT-E-BAD_LRL, record length (722) greater that specified longest
    length record
    -SORT-E-READERR, error reading 'filename'
    
    The SORT command is:
    
    $ SORT/KEY=(POSITION:1,SIZE:2,DESCENDING) 'inputfile 'outputfile
    
    I do not know if they can open the files from their COBOL programs
    since the sort fails.
    
    Is there any way around this problem without having to modify the
    customer's code ?
                     
    Thanks in advance,
    
    Mary.

    Hi,
    
    I have managed to copy the file and have the LRL value set by turning
    off VMS-Plus mode in ftp.
    
    FTP> OPEN remote_host
    FTP> DISABLE vms_plus
    FTP> PUT filename
                                   
    The remote file had LRL correctly set and I could sort it.
                        
    It will not be possible to interactively disable VMS-plus mode as I did
    above.  The customer does not use ftp directly. They use FTSO on the
    local side in 'ftpmode' which causes it to use UCX's ftp on the remote
    side.
    
    Is there a way to permanently disable VMS-Plus mode on a process-wide
    basis  ?
    
    We will still need to be able to copy binary files therefore we will
    need to be able to use VMS-plus mode for some copies.
    
    What is the effect of disabling VMS-plus mode ?
    	i.e. Will it affect performance ?
    	     How will it prevent copying of binary files ?
    
    
    Thanks in advance,
    
    Mary.
    

	re .5
        
>    %SORT-E-BAD_LRL, record length (722) greater that specified longest
>    length record
>    -SORT-E-READERR, error reading 'filename'
        
        I think that if the LRL is stored as 0 in the file header then
        SORT has to guess, and will complain if a record greater than
        the guess is discovered.
        
        You should be able to specify the input file qualifier as
        something like /FORMAT=(RECORD_SIZE:nnn) once you know an
        upper bound nnnn (here, at least 722) on the true record
        length.
        
        Likewise you can set the file header with
        
        	$ SET FILE/ATTRIBUTE=(LRL:nnnn) filename
        
        Dan

    Two possibilities:
    
    	(1) Convert the file before running your sort
    
    	(2) Disable VMS+ mode by placing the command:
    
    		DISABLE VMS_PLUS
    
    	    in SYS$LOGIN:FTPINIT.INI
    

    Hi,
    
    Disabling VMS_PLUS in FTP$INIT.INI works for copying files using just
    ftp (i.e. the LRL is set). However when I copy the file using FTSO the LRL
    is not set. I think this is because FTSO enables VMS_PLUS mode itself.
    
    $ SORT input/FORMAT=RECORD:nn output
    Works - ie it sorts it and set the LRL.
    The problem with this is that the customer will not always know what
    the LRL should be and there are several procedures within a large
    application doing various sorts.
    
    $ CONVERT before sorting the file also works, but again this means
    changing several command procedures
    
    Will ftp be able to copy binary files correctly if VMS_PLUS mode is
    disabled ?
    
    Is there any way to get RMS to write the file on the remote side so
    that LRL is set (eg setting something on the remote system).
    
    I'll cross post this in the FTSO conference.
    
    Any other suggestions VERY welcome.
    
    Thanks in advance,
    
    Mary.
    
      

    The `binary' files will come across the connection as FIXED=512
    sequential files.  A future release of UCX will go out of its way to
    preserve LRL.

    Hi,
    
    Is the disabling of VMS_PLUS mode a supported way of getting UCX to
    copy a variable length record file ? If it is possible to modify FTSO
    to interrogate this setting somehow can we be guaranteed that this
    facility won't go away in the future.
    
    Thanks,
    
    Mary.
    

    It will copy the file as a stream_lf file, I believe.  By default it
    should place the connection into ASCII mode, converting record
    terminators in NVT newlines.
    
    This mode will always be there, and should be there for all FTPs.