RMS indexed file with no record layout available

[igal vaskain]

I have a set of indexed files from an old software package that we use. The record layout maps are missing and unavailable. I got key info using various VMS utilites, but the data portion could not. So, the question is:
Is there a way to determine the position and a length of a field in the record of an RMS indexed file without having the record map?

[Robert Gezelter]

igal,

Welcome to the ITRC OpenVMS Forum!

Strictly speaking, there is no record layout meta data stored about RMS files with the file itself, other than the layouts of the keys (and the keys can be partial or composites of different fields).

Other than the actual data structure maps used with a file, about the only options are to use DUMP to look at the contents, or to disassemble the code.

Admittedly, neither is a particularly attractive option. Reverse engineering record structures is a bit of a black art (having done it some times).

That said, reports generated from the data are extremely useful.

- Bob Gezelter, http://www.rlgsc.com

[igal vaskain]

Robert,
Thanks for such a quick reply. The dump does not show much, all binary. You have mention a disassembler. Do you know of any. Will it work on *.exe files ? I do not even have the *.obj files.

[Hoff]

It might help to identify the old software package, and work from there with the vendor or whomever might still know about the package.

Failing that, I'd start with DUMP and looking at what's in the file. You'll be looking for date values, floating point values or whatever it is that you think is stored in the file. As you've found, the key definitions can help.

If you're willing to disassemble the associated VAX or Alpha executable code and assuming that disassembly and reverse-engineering is permissible within your environment (check with the corporate legal folks, etc), the old VAX disassembler is DISM32, and it's been available around the network. (It was at the SAIC archives, but they went offline a month or two back.) With Alpha, the srm_check tool is a potential option here.

And if you think the dump shows binary, a disassembler provides you with assembler code. No comments. No structure. Probably also an instruction sequence that has been through an optimizer after having been compiled from the original source code. (Unless the source code was originally VAX Macro32 Assembler and you're working with VAX code, but that's fairly rare.)

I've done file-level reverse engineering in the past. It can take weeks to fully figure out what you're looking at in a moderately complex file. And that's presuming the original programmers didn't do something weird.

If you're moving forward from OpenVMS VAX to Alpha or from OpenVMS Alpha to OpenVMS I64 on Integrity, then you might be able to run the executable through one of the image translation tools. That (usually) avoids having to reverse-engineer the data files.

[Wim Van den Wyngaert]

I would first start a search on all disks.

May be someone saved the sources/libraries. In a save set. Or zip file. Or .tlb. Or even compilation listings (.lis).

Or may be in the datatrieve setup (sorry but my head is empty on the subject, it's 20 been years that I used DTR).

fwiw

Wim

[Hein van den Heuvel]

>> The dump does not show much, all binary.
No luck huh? Ascii columns are often easy to line up, binary data much less so.

Just to be sure... By default DUMP does a BLOCK dump, which for an indexed file starts with a few block of binary looking data more often than not with data bucket following at block 3 or 4. But that data has binary bucket headers and record headers and possibly compression.
So you must request a record dump. For example:
$ DUMP/RECORD=COUNT=5

You may also try an editor to look at the data. Sometimes it helps to first extract the
record to a width restricted, padded sequential file:
$CONVERTPAD/TRUN/FDL=SYS$INPPUT tmp.idx tmp.seq
RECORD; FORM FIXED; SIZE 64

Good luck!
Hein.