RMS record much longer that format attribute proclaims. - VMS

This is a discussion on RMS record much longer that format attribute proclaims. - VMS ; This shows and output file with Record format: Stream_LF, maximum 255 bytes, longest 255 bytes but the DUMP/RECORD below shows Record number 120 (00000078), 7626 (1DCA) bytes, RFA(0008,0000,01FB) a record much longer than that. Comments? $DIRE/FULL TEST.LOG; Directory DISK$TEST:[DEVL] TEST.LOG;11 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: RMS record much longer that format attribute proclaims.

  1. RMS record much longer that format attribute proclaims.

    This shows and output file with

    Record format: Stream_LF, maximum 255 bytes, longest 255 bytes

    but the DUMP/RECORD below shows

    Record number 120 (00000078), 7626 (1DCA) bytes, RFA(0008,0000,01FB)

    a record much longer than that.

    Comments?


    $DIRE/FULL TEST.LOG;

    Directory DISK$TEST:[DEVL]

    TEST.LOG;11 File ID: (190302,83,0)
    Size: 86/90 Owner: [MIS,TEST]
    Created: 30-APR-2008 08:26:59.01
    Revised: 30-APR-2008 08:27:01.22 (1)
    Expires:
    Backup:
    Effective:
    Recording:
    Accessed:
    Attributes:
    Modified:
    Linkcount: 1
    File organization: Sequential
    Shelved state: Online
    Caching attribute: Writethrough
    File attributes: Allocation: 90, Extend: 0, Global buffer count: 0
    No version limit
    Record format: Stream_LF, maximum 255 bytes, longest 255 bytes
    Record attributes: Carriage return carriage control
    RMS attributes: None
    Journaling enabled: None
    File protection: System:RWED, Owner:RWED, Group:RE, World:
    Access Cntrl List: None
    Client attributes: None

    Total of 1 file, 86/90 blocks.

    ===
    [SNIP]
    Record number 119 (00000077), 9 (0009) bytes, RFA(0008,0000,01F1)
    Record number 120 (00000078), 7626 (1DCA) bytes, RFA(0008,0000,01FB)
    Record number 121 (00000079), 18 (0012) bytes, RFA(0017,0000,01C6)
    [SNIP]

  2. Re: RMS record much longer that format attribute proclaims.

    On Apr 30, 8:35*am, norm.raph...@metso.com wrote:
    > This shows and output file with
    >
    > Record format: * * *Stream_LF, maximum 255 bytes, longest 255 bytes
    >
    > but the DUMP/RECORD below shows
    >
    > Record number 120 (00000078), 7626 (1DCA) bytes, RFA(0008,0000,01FB)
    >
    > a record much longer than that.
    >
    > Comments?


    Only the obvious... the actual records do not match the file
    attributes. So ?

    And that 255 is sort of a nice-number: max value for an unsigned byte.

    RMS itself would not do that, short of a system crash stopping the
    atributes from being flushed out.
    Who / What wrote the file? The C-RTL easily could, as it does block
    IO, not (RMS) record IO of simple unshared sequential files.
    It could have picked up attributes from an earlier version of the
    file, if C rtl was used to create it.
    And check out the logical name "decc$default_lrl".
    That would not happen to be set to 255 would it now?

    It the record a 'good one' as far as the application is concerned, or
    is it broken ?

    I'm sure you know how to 'fix' it, but since you did not indicate
    so...:
    $ SET FILE/ATTR=(MRS=0,LRL=7627) TEST.LOG

    Cheers,
    Hein. (taking a quick peek online whilest on family vacation)

  3. Re: RMS record much longer that format attribute proclaims.

    norm.raphael@metso.com wrote:
    >
    > This shows and output file with
    >
    > Record format: Stream_LF, maximum 255 bytes, longest 255 bytes
    >
    > but the DUMP/RECORD below shows
    >
    > Record number 120 (00000078), 7626 (1DCA) bytes, RFA(0008,0000,01FB)
    >
    > a record much longer than that.
    >
    > Comments?


    As I understand it (probably inaccurate/incomplete), these values are
    really just advisory in nature. They provode some clue as to what is
    reasonably expectable, even if that expectation does not reflect the
    reality of the data.

    I read once that some programs use the LRL value at file ((SYS)$)OPEN
    time to initially allocate buffer space.

    D.J.D.

+ Reply to Thread