Re: Q: The Kongsberg file format

I wouldn't be surprised if 'kongsberg' is scandinavian. Searches of
the internet using an argument that uses simple Latin 'o' in spelling
konsberg with relevant combination words produces no results. If there
is any current info at sites published in the native language you will
need to conjure up the encoding for that vowel for your search
arguements. That may require encoding the cipher as an escape
sequence, and a friendly search engine.


Meanwhile, looking at your posted hex dump, there is a chance you have
not yet revealed any clues (See notes below). I think you have only
dumped file header data. I am guessing, but I think you only accessed
the label of the file, not the file itself.


The material you dumped looks like information about FILE and DIRECTORY.


Maybe give us a hint as to what environ it came from. The dates
reflect fairly current runs. What kind of system is this for, and
approximately what does the object image represent. You might be able
to get more help just from your operating context then the encoding,
although it is fascinating to look at.


The dumped material appears to be in ASCII format. It appears to have 40
records (that is the label has forty records).


Here's a partial interpretation


*$TCSIO
*$TCHIO =>Mount Cartridge and Write 1SIO
*$TCH EMUIOT1 Date: 99-09-20 Time: 14:56:41
*$TC+-CPOSW/00>
*$TC+S2COUT/00 EMUIOT1 Date: 99-09-20 Time: 14:56:41
*$TC+-S2CHEX/0064
                0 0 0 0 0 0 A X L O
7F7F7F7F30202030303030304158202020202020202020204C4F


                                                V O L U M
                                                564F4C554D202020202020202020




0 0 0 0 0 0 0 0 0 0 9 9 0 9 2 0 1 0 0 0 9 2 0
30303030303030303030 393930393230 313030303932302020


000000000000000000000000000000


*$TC+-CEOF
*$TC+-S2CHEX/0064


                4 0 0 0 0 0 0 L O F I L E L A
7F7F7F7F34302030303030304C4F46494C452020202020204C41


                                                D I R E C T O R Y
                                                4449524543544F52592020202020


                    0 0 0 0 1 9 9 0 9 2 0 1 0 0 0 9 2 0
20202020203030303031 393930393230 313030303932302020


000000000000000000000000000000
...


The interpreted date stamps match your display of " Date: 99-09-20"


I think that all means that the volume information is 0000 and the
directory information is 0001. The LAs and LOs may or may not be
length/address designations: LOF being a common enough abbrebreviation
for Length Of File. It all looks like directory or file management
data needed by tape utility or archiving utility.


If there is an object file on this medium it may be the next thing on
there. Let me explain that, you may know this already, but if you are
not into this part of the technology this small hint could help.
Tapes, for example, have a file on the front which is really just a
label that explains every thing that follows. Sometimes a tape copy
of just one file has two files, first the label, and then the thing
you think you put on there.


There are different strategies for putting multiple files onto a
tape. Some times a single label 'file' up front can control all the
rest of the potentially multiple files that follow. This label can be
compared to a disk packs Volume Table Of Contents ( a VTOC). Other
strategies might be interspersing between each additional file with an
additional 'label' file.


(some methods even put a trailer onto a tape that can appear as yet
one more file). So in simple situations a single file on a tape may
have as many as three files: the label header, the file itself, and
then the trailer. If an error is made: you can get either just the
header 'label' file, and nothing else or the header and the trailer
and nothing in between.


If you are dealing witha situation like that you either need to
instruct your dump utility to skip the firts 'file' which is possibly
just the label, or you need to get the oparing system to hide the
label from the utility (That is, your operating system may think the
medium is unlabeled! so it reads the first 'file' for the utility, not
the real file which is the second file (in some cases)).


If you know all that, except my apology for spoon feeding you. But the
displayed data does nor look like object image. If does have some hex
7f7f7f7f at the lead of each dumbed block, and there are binary zeroes
in there; so it is not exactly a pretty text file. But object files
are less easily interpretable than this: it all looks like ascii.


It is not clear from the post why there would be DIRECTORY information
in this image, so you may be dealing with a smoke-screen from the
backup or recovery utility that made the image.


You probably know a lot about the tape. I am guessing that the
designation EMUIOT1 means something clear to you, and I am not asking
for clarity from you: just want to point out that if EMU means
something like Emergency Medical Unit then you can research image scan
file formats in a medical context; if EMU happens to be an
abbreviation for a university, then perhaps that can be a access point
for your research.


Let me know how it goes.


Best Wishes




Robert Rayhawk
RKRayhawk@aol.com

Return to the comp.compilers page.
Search the comp.compilers archives again.