DSTEVENS@VAXC.STEVENS-TECH.EDU (David L. Stevens) (02/08/88)
To open a file up and be at end of file look in the RMS manual at the ROP (record options) field of the RAB. I believe that the option is RAB$_EOF. Dave Stevens Senior Systems Programmer Stevens Institute of Technology Bitnet: DSTEVENS@SITVXB Internet: DSTEVENS@VAXC.STEVENS-TECH.EDU ------------
rrk@byuvax.bitnet (02/11/88)
With no duplicate keys allowed, you can declare a reverse key for the same
part of the record/data type that your regular key is.
Other than that, it's a big deficiency of VMS.
Ray WhitmerESC1332@ESOC.BITNET ("K.Keyte") (02/11/88)
Does anyone know of a way of reading the LAST record in an ISAM file without having to read sequentially up to EOF? Unfortunately it isn't possible to read backwards 1 record, and adding a new record with a very high key and then deleting it leaves you at EOF, not the record before! It seems quite a deficiency - there MUST be away. Any of you VAX wizards know it??? Help appreciated. Please answer to Karl (ESC1332@ESOC.BITNET). Thank-you. Have a nice February. Karl ' K.Keyte Info-VAX list 2/01/88 Reading last record in ISAM f -------
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (02/11/88)
Does anyone know of a way of reading the LAST record in an ISAM file without having to read sequentially up to EOF? Unfortunately it isn't possible to read backwards 1 record, and adding a new record with a very high key and then deleting it leaves you at EOF, not the record before! First of all, there is no such thing as the "last" record in a file with multiple keys; you have to decide which key you are interested in. Given that, add one more key, using the same data as the key relative to which you want the "last" record, but make it a DESCENDING key. Then the FIRST record with respect to the descending key is the LAST record with respect to the original ascending key, and vice versa. If you are unwilling to add an extra key, about the best you can do is search backwards from very large key values, looking for the keys greater than or equal to your "best guess so far". You can do a binary search and find the last record fairly quickly this way. It seems quite a deficiency - there MUST be away. Why? There is nothing in the structure of an efficient indexed file imple- mentation that makes this information easily available. Sure, RMS could keep track of the largest record every written - for each key, of course! - but that record could be deleted, at which point RMS would need some sort of back- pointer to find the previous record. But it has no need for such a back- pointer for anything else, and keeping such pointers correct is complex and consumes time and disk space. Little gain, large cost - and a workaround for users who really NEED this exists (descending keys). BTW, in my experience most designs that appear to need to find the last record in an indexed file can be re-done fairly easily to NOT need it - or they can maintain such a pointer themselves quite easily because they have special information about the particular application that RMS doesn't have. -- Jerry