Minus 1 (-1,0xffff) at end of sequential file

[GuentherF]

I was asked why there is a -1 at the end of a sequential file and why it disappears afte a COPY or BACKUP copy of that file.

Here's an example:

00000000 00000000 FFFF0063 62610003 ..abc........... 000000

00000000 00000000 00000000 00000000 ................ 000010

Notice the FFFF after EOF:

    VAX-11 RMS attributes

        Record type:                      Variable

        File organization:              Sequential

        Record attributes:             Implied carriage control

        Record size:                      3

        Highest block:                   1

        End of file block:               1

        End of file byte:                  6

After a VMS COPY the file looks like this:

00000000 00000000 00000063 62610003 ..abc........... 000000

00000000 00000000 00000000 00000000 ................ 000010

I looked up RMS sources but didn't find any hint. But I remember there was "something" about that trailing 0xffff.

Anyone remembers? Hein?

Thanks,

Guenther

[Hein van den Heuvel]

once upon a time, in a country far away...

The -1 is a special case record length word, telling rms-11 to skip to the begining of the next block for a next record.... if any.

Thus RMS does not need the FFB byte to know there is no more data in the block.

Best I know it is not used as such, as we have the EBK+FFB.

Yo will see that word in actual use for non-block-span records to signify the last record in a block.

And it is also actively used in ... drumroll... RU-Journalling.

This is how RMS can 'delete' records in a sequential file if a transaction gets rolled back.

Unfortunately (imho) they 'wasted' all the other values from 0x8000 - 0xFFFFE.

Only -1 is used to skip to the end of the block.

Therefore RU-J marked seq files have to be non-span with no mor e than 1 record/block and for a record longer than 1 block, each block has to start with a -1 to indicate a delete/rollback.

Hein

[James Amend]

Thanks both very much for your replys.  I can see now where the FFFF is used with a non-span fixed length record.  The FFFF at the end of the file must not have any significance as was pointed out because the VMS COPY command does not copy it.

Guenther Posted this for me because I didn't know about it.

Jim Amend