How were business apps done in BASIC?

[whartung]

UCSD Pascal was a major player in the later 70s and early 80s.

It was, but it was also problematic, particularly the early ones, that it took over the system, rather than running on top of it. Later, with the DOS versions, they shifted from that a bit. But early on, it was the whole enchilada.

No HL language was as efficient on resource-constrained systems as Forth was (and still is). Add to that OOP that Forth (almost) always had (CREATE..DOES) — even, when the term itself wasn't even coined, and its „virtual memory” ability thank to Forth's „block system”.

Early Forth suffered this similarly (among other things). And while all of those features were indeed useful features of the Forth system, they weren't enough to let the system break out into the mainstream. dBase sold a lot more copies, and shipped more applications into more verticals than any Forth system ever did.

 

[alfons]

This is great information. I have been wondering the same thing. I would like to find some software for vintage hardware (Z80 CP/M or X86 DOS) that does accounting and inventory. It has perplexed me on how database and data storage was done. I am too young (37 currently) to have dealt with anything that doesn't have SQL type connections. I used Foxpro and Dbase a tiny bit, but it was to salvage data and import into SQL databases.

If I were to write software for older hardware with some type of database and with current technology, what is the best way to do that? Is there a way to integrate a MySQL connection into a basic or pascal program? maybe a way to use SQL through a serial port?
I don't mean to hijack the thread but this is very interesting and would love to hear more about how databases in the late 70's to early 80's functioned and a reliable way to reproduce the effect. By the way, if you're curious about the latest trends in blockchain and gaming, you might want to check out https://icoholder.com/en/games for some insightful information.

Choose a language that was popular during the vintage era, such as Pascal or BASIC. These languages have a simple syntax and are well-suited for the limitations of early hardware.

 

[Roger Wilco]

If you mean that BASIC/Pascal like languages, then the better idea may be to get the more „modern” versions of them, like Power BASIC 3.50 (the last version for DOS), or Unicomal 3.11.
But I still recommend Forth — modern Forth for DOS, like DX Forth, for example.

 

[Endersending]

This is great information. Thank you so much.

 

[whartung]

I'm privileged to say that I was the author of a business BASIC (manual is on archive.org). None of this B+ tree stuff--just an integrated ISAM. Decimal arithmetic. I have sample code if you're curious.

So, I was noodling about with this. Trying to better understand ISAM and how it works.

Fundamentally, perhaps simplistically, it's a static tree with the leaf pages pointing to the records.

When a new entry is added, the tree is walked to find the leaf page that "handles" the range of data the new record would belong. If there's room in the page for the new entry, the entry (i.e. the key/record id pair) is inserted into the page, and the page is resorted. If there is no room, then an overflow page is added and the new entry is stored there.

It's not clear to me if the new page is sorted as well. It seems that the key point here is that, as I understand it, keys are not "shoved out" into overflow pages. Rather, overflow pages are simply created and populated as a bag of unsorted keys. That part is muddy.

When the ISAM index is created, it could be good practice to create the new index with space for new entries, in order to reduce the number of overflow pages, but at the cost of disk space that sits idle. And that makes sense for indexes that are receiving "random" updates (i.e. last name, or something else).

However, if you're inserting rows into, say, a Customer Master, where each row get an incrementing Customer ID, then creating an index with space doesn't make much sense. The IDs are unique, assigned once, and never increasing. So, there won't be a case where you may insert IDs 101, then 201, then 301, and then, back, to 105 or 256. But it does suggest when creating a new index, that you would pre-allocate space for the new IDs. That is, if you already have 1000 customers (numbered 1-1000), when you reorganize the index, you may create an index for 1-1500. That makes adding new IDs a simple update of the appropriate leaf node, but not commit the actual records themselves. At least, that's my intuition.

Is that your experience?

As an aside, I was playing with doing some sorting in BASIC. A simple shell sort.

I ran it on a cycle accurate 4.77 PC simulator. And it took over 18s to sort 100 random integers.

It just reminds us how much we've gained and amazed that we were able to get anything accomplished back in the day.

 

[Chuck(G)]

Two files--one of data (with keys) and an index of nothing but keys and pointer to records in the data file. The data can be read sequentially--and ISTR that I included an "Active" flag with each data record. You can (obviously) access the data file records by referring to them by index value. Pretty simple, actually. Maintenance of the index list is done in this case with an ordered linked list (the stuff was written nearly 50 years ago, so my memory may be faulty). Since the data file also contains the index key values, it can be used to rebuild a corrupted or lost index file. There's also stuff in there about record locking, which should be obvious. All done in 8080 assembly code.

The thing about the old way of thinking is that floppy disks are more prone to errors than hard disks, so "you can't get there from here" situations had to be avoided.