- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Minus 1 (-1,0xffff) at end of sequential file
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2012 01:39 PM
06-22-2012 01:39 PM
Minus 1 (-1,0xffff) at end of sequential file
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2012 06:32 PM
06-22-2012 06:32 PM
Re: Minus 1 (-1,0xffff) at end of sequential file
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2012 09:52 PM
06-22-2012 09:52 PM
Re: Minus 1 (-1,0xffff) at end of sequential file
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-25-2012 09:17 PM
06-25-2012 09:17 PM
Re: Minus 1 (-1,0xffff) at end of sequential file
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