Copy Link
Add to Bookmark
Report
NULL mag Issue 06 23 the jam format
as you read in the news section a member of the JAM format team has
deceased. so in honoring him and the rest of the team, i would like
to write this "analysis" of the format, from my point of view. JAM is
a format that we still use, even after all those years and it seems
that we will be using it for a long time more.
if you want to learn more about the format take a look here:
https://defsol.com/news/jammbp-the-joaquim-andrew-mats-message-base-proposal/
so... a "jam base" is actually 4+ files! not just one. each file has
a different format and its been created for specific reasons.
remember that the jam format created in 1993. at that time the hard
disk space and speed was way lower than today, we still used floppies
and similar stuff. also there wasn't any database like sqlite exists
today. if i remember correct dbase existed then, but perhaps the
creators of jam, didn't want to use it or some other reason. i don't
know.
a jam base needs 4 files to be fully working and valid. if one of
those files is missing it means that either the base was just been
created or corrupted or the program made that base, didn't implement
the format as it should.
the main file is the header file (.jdh). it contains info for the
base it self and also a header for each message that is written in
it. if the bbs program needs info for a message, it needs to access
this file.
but we are back in 1993... remember? we can't keep a file all the
time opened by just one app. and for doing some things, was better to
create a another file for the format, than opening the main header
file and reading it again and again. also, the info that the format
had to keep, couldn't be possible to be just in one file. so except
the .jdh file, we also have the .jdx, jdt, jlr and more. each one for
a specific job.
the .jdt file contains only the text of the messages and its the
biggest file in the base. check your bbs and you will see it your
self. and because it's the biggest and needed to transfer a lot more
data, than with the other files of the format, it has been created
separately and it's being accessed only when a message is going to
be read from the user.
there is also the .jdx file, which i think it's the "clever" one ;)
it stores records in a pair of user crc + header offset. the offset
refers to the .jdh file. its record refer to one message in the way
it was written in the base and so in the .jdh file. so if we accessed
the 100th record in the .jdx file, we get the offset for the 100th
message header in the .jdh file. this way we can access the
information of the 100th message in the header file, way faster by
opening the .jdh file and accessing it in a linear way.
if we devide the file size of the .jdx file by 8, we get the number
of messages in the base ;) also a quick way to get this number.
because the message header, also contains info for the sub fields,
the sum of the message + sub field headers is not the same, for each
message. so reading the .jdh file in a linear way to get the info for
the 100th message, needs more calculations, than just opening the
.jdx file going straight to the 100th record and get the offset for
the header of the specific message in the .jdh file.
the jam format, also used another "trick" or "way of thinking"
better. lets say that a user deleted a message, which is something
that the format supports and it should, as everyone understand...
so... instead of actually deleting the message info (header, text,
index etc.) the jam format... simply marks it as deleted! it doesn't
actually delete the info/text. before saying "how unsafe or tricky"
this was, let me explain.
when accessing a part of a file in a disk... you can't actually
delete parts of it. erasing parts of a file, doesn't work as cutting
text from a line, by just removing a part of it. in files you can
only overwrite things! not erase! so in a jam base, if we actually
wanted to delete a message we should do the following:
1. create temp files, for each one of the format it needs.
2. copy the header/text of all previous messages up to the one we
want to delete, to the temp file.
3. skip the header/text of the file that is being deleted.
4. continue copying all other data in the files
5. delete the actually jam base files... all of them!
6. rename the temp. files to original file names.
...and all this work had to be done the same time, the user was
accessing the bbs and the message base. can you imagine the delay and
the risk of corrupting the base, if two or more users were accessing
the jam base?
and that's why we have "base packing"! instead of doing all the above
work to erase just one message, we do it at a specific time, for many
messages at the same time. that's why you have to pack your bases at
a time that your bbs should be down and relative often, to fix any
broken links and delete the old messages...
... whoops... i forgot that! as i said, disk space back in 1993 and
even earlier, was restricted. also the files, couldn't have bigger
size than a specific limit. today we can have files up to 4GB and
even more, but back then, you couldn't and you shouldn't. so by
packing the bases, the format also achieved another function... to
keep the file size down to a reasonable size.
back then you couldn't just keep all messages! that's why your bbs
software asks you how many days to keep the messages and how many of
them. the older messages get deleted automatically during packing, to
keep size small and the base would be accessed faster this way.
the jam format is another example of "old thinking" and i don't mean
"not modern", but "more logical", not wasting computer resources as
we do today. back then we had some thousand kilobytes to use and
every byte, was important. also some bbses were hosted on just floppy
disks! can you imagine that today? so jam format did its job good and
as quick as possible... perhaps that's the reason it's being used
even today and it hasn't been replaced by another format. who
knows...
so the JAM format will be around for a long time and its creators
deserve to be remembered by the bbs scene.
[ J ] oaquim Homrighausen (1)
[ A ] ndrew Milner (2)
[ M ] ats Birch
[ M ] ats Wallin
(1) https://www.joho.se/
(2) http://www.edu.aboutnow.com/bbsdays/people/andrew_milner/
