• Please review our updated Terms and Rules here

How were business apps done in BASIC?

There were a number of SQL style interfaces for MS-DOS. I worked at a Novell shop so I have a slight familiarity with the XQL to Btrieve for DOS interfaces. Other ones did exist but it was proprietary code that only hooked into one database. Generally very complex and poorly documented. ODBC, for all its faults, at least gave a standard interface to most of the database backends. Lots of work but only once.

For most DIY databases, SQL is overkill. A simple ISAM design should handle thousands of items with minimal lost performance.

Courses must have changed since I was in school. I remember having to write a rudimentary database engine as a project.
 
Endersending said:
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?
Click to expand...
This would be possible, and it may well be effective. Much of the burden of the work would be on the server, leaving your client to having to do little more than block moves in memory.

Fundamentally, DB records were represented as blocks of memory with fields mapped on top of them. The memory itself had no meta information, it's what just a buffer. Much like populating a C struct and just reading and writing it to a file.

For Pascal, this wouldn't be difficult as you can just make a record definition, put in some int, floats, and character arrays, and point a pointer to a data buffer.

In BASIC, it's a little harder because while all of those buffer machinations exist (through the FIELD statement), the actual memory buffers used are a mystery (you may well be able to just use a VARPTR on one of the first fields in the mapping, and it may just work). It's possible, it would just require some internal BASIC implementation knowledge to pull it off.

On the server, it's job is to take a SQL result set, and convert the rows into these continuous memory blocks. Most SQL drivers just work on string data. Send a string up as a query, get a collection of strings back as a result, and the local driver does the conversions, like "1234" to the actual binary for 1234 on the local system. Converting strings to ints are straightforward, to compatible floats may not be (do you know the floating point format for Turbo Pascal? I don't.)

On legacy hardware, you simply can't afford to do that. It would just take forever. So, delegate all of that to the server. All the client sends is binary blobs to the server, the server maps them into things like INSERT and UPDATE statements. And the server sends back binary blobs. All of this coincidentally matching the mappings you have hard coded on your local machine.

The dark side of this is since the mapping is mostly static, you don't get the granularity you would normally get from SQL. No most just "SELECT CUST_ID, CUST_NAME FROM CUSTOMER". You'd probably have to map the entire record, even if you were just interested in the name. Obviously, you can do what you want, but with the static mappings, it just not very nimble.

Now, in Pascal, you could return a linked list of "fields" to give you that kind of flexibility. It would certainly slow things down, static buffers are as fast as you can get. So you may just mix using hard mapped records and these flex lists. In BASIC, you wouldn't (as easily) be able to do that. You could dig into the implementations and populate a string array for a "flex" result.

A serial interface is fast enough for this. 19,200 is almost 2K per second, faster than many contemporary floppy drives, but certainly not hard drives. Obviously, the faster you can push the interface the better. 115K baud actually pushes into the hard drive space. And with the server doing most of the work, you'll lose a lot of the seeking latency of older hardware as well. Legacy hardware reaching 115K is unlikely. But a lot of modern Z80 kits can do that.

A parallel interface would be faster, but you'd need to write a driver like on both ends, certainly not as plug and play as a serial interface.
 
I am getting a better picture of how this stuff works. I am imagining an office with a minicomputer and some terminals and maybe like a tape backup. The mini would act as 2 servers: A Terminal/application server. You would turn on your terminal, probably have to log in with credentials and from there you can run the terminal application (sales orders, inventory). the mini would also be the database/storage/backup: handling batch processes, databases.

The software would be either the vendor supplied or whatever small company was making the next big sales program.
I live in a rural area where It makes sense that it took awhile for that technology to find its way here. You needed door to door software salesmen, or computer stores. You couldn't go on youtube and search 'how to fix my VAX'. It seems like there was a whole ecosystem to just keeping the computers running and everything was changing almost daily.

What kind of Minicomputers (if that is the correct type) did they use for an office of 10 people? would the company rent the hardware? Who would train the secretaries to use the latest Pascal application? Who would you call if you tape drive stops working or a terminal stops working?

Does anyone have stories of how you would 'run the gaunlet' at payroll time or what a year end inventory backup would require?
How much coding was done in house? Did the secretary have to do any programming?
How much coffee did it take to write a batch process?
 
"What kind of Minicomputers (if that is the correct type) did they use for an office of 10 people?"

There was a whole class of computers called "Small Business Computers" that really doesn't exist any more, along with most of the players in that market.
IBM sold systems like the System/3, 34, 36, 38 and still today as the AS/400. The displays were forms based.
Burroughs had similar products like the B80/800/90/900

and lots of smaller guys like BASIC/4, et. al.

These sorts of systems weren't really written in BASIC, though.
There were specialized Business BASICs though, that companies like Data General sold that were tailored towards writing applications for that market.

The Pick software system was also popular across several computer architectures.
 
A small business, such as an insurance agency, might use a Microdata Reality system:
Also, do not discount the importance that many small companies outsourced their data processing needs to service bureaus.
There really was no "universal" solution in small business, even in the early microcomputer era. For instance, auto parts dealers often used Trident (IIRC) software and systems.

Before that, a small business <100 employees might have a bunch of unit-record equipment (sorters, collators, punches, accounting machines) to handle things and no computer at all.
 
more than you ever wanted to know:

example:

after several generations, the whole process of how businesses ran, going back to paper records, is disappearing into the mists of time
along with how the computerized versions of those processes were implemented

buisiness data processing is a field that has never held much interest to classic computer hobbyists
 
I ran a business started in 1975 that is still going today in the 1980s i ran XTs with basic programs i wrote in combination with lotus 123, dbase III and wordstar 4.0

i had a bunch of inventory programs that ran in basic. mail merge and label makers and an accounting program with tax tables.

i never compiled anything back then i just had a patched version of basic for the office that removed control C so you couldn't just exit to the editor and mess around easily. it was just a quick safety for the office staff but back then you could trust easier.

there was a TON! of free and pay basic business programs some you can still find today.
even microsoft in the basic manual gave you a demo inventory and payroll program you could modify how you needed.

there was integrated word processors in some programs as well.

here is one

TRS-80 Color Computer Archive

TRS-80 Color Computer Archive
colorcomputerarchive.com colorcomputerarchive.com

i also had multiple little programs for inter office memos and printing checks i linked everything back to a central menu system so an employee could choose what they needed.
there was a menu system for DOS that ran apps and then a Basic menu system i wrote that would run programs.
it was a little separated due to printer configurations so really one machine was running basic and the others could but didn't need to.

this setup lasted and was improved on by NETWARE software with a 10-base-T network. around 1990 it was replaced with a windows 3.0 system that went into 3.1 and 3.11
my original software even made it into windows 2000. i think i last had some of it working under windows XP as you could copy special icons from previous desktops and it would honor the dos settings.

by the mid 2000s everything had to be changed for new applications. the original Dbase III database was ported to office 2000 access along with a interface that matched the dbase III overlay.
i still have a few pcs from the early 2000s that have the same setup as from the 1980s that ran and still run my buinsess.

BASIC had a big hand in it.
 
you know what really drove computers. hee hee

Code: 
                                 ,cccc,,,
                              ,P"`.`."`.ch$.
                             .P`.`.`.`.`.`;`h
                            j'.`.`.`.`.`.`.?3?
                            $`.`.`.`.`.`.`.`?$.
                          ,P`.`.`.`.`.`.,$$,.3$h.
                        ,P`.`.`.`.`.`.,$$$$$i.`$$h
                      ,P".`.`.`.`.`.,$$$$$$$$$hJ$$$.
                    c"`.`.`.`.`.,$$$$$$$$$$$$$$$$$$$
                  J"`.`.`.`.`.;J$$$$$$$$$$$$$$$$$$$$h
                J"`.`.`.`.`.,;$$$$$$$$$?????iiJJJJJJ$$$$$cc,
              J"`.`.`.`.`.`;???????iiJJJJ$$$$$$$$$$$$$$$$$$$$h
            ,?`.`.`.`.`.`;;J$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$c
          ,P`.`.`.`.`.`.;;P"$F?$$$$$$$$$?$$"?$I"?C?$$$$$$$$$$$$$h
         J".`.`.`.`.`.,;;$ j"J$?"""?$C`.??";;J?$'?L$$$$$$$$$$$$$$>
       ,P.`.`.`.`.`.`,;;$'J3F'J$??$3c$`.`?h$9hP"`.$<?$$$$$$$$$$$$'
      J"`.`.`.`.`.`.,;9'$ P3`.`.""`.`3`.`.`.`.`.`.3?$ $?$$$$$$$$P
     J'.`.`.`.`.`.`;;J$,/j'$`.`.`.`.`$`.`.`.`.`.`.3F<? "',_?$$$$    _,,="
    P.`.`.`.`.`.`.;;J'$$ $ ?`.`.`.`.$"`.`.`.`.`.`.3h ?     `"?$C,c$P"
   P`.`.`.`.`.`.,;;9' $$ F  h.`.`.`."?".".`.`.`.`.$$  h=-,_     `?c
 ,$.`.`.`.`.`.`;;;J' ,'$j' <$.`.`.`.`.`.`.`.`.`.`.$j   ?c  ".     `$"??hcc?
;C;.`.`.`.`.`;;;;J'$$h;$J  `Ph`.`.`,JllllCCc`.`.`.PjL    "=c,`=c,   "h.
$;;.`.`.`.`,;;;;P   Jh?$J   L$`.`.`?hiiii?".`.`.`.Fj''       ??  ?.   ?c
C;;,`.`.`.;;;;9"   $"  $J   $'h.`.`.`.`.`.`.`.`.`JFJ  $C      $   ,>h, `?c,_
C;;;;;;;;;;;;$    <Lc,jP$   $ ?h`.`.`.`.`.`.`.`J$$ $  $ ?cc,  ?.,P""=c,c=""
C;;;;;;;;;;;?$    <C,'j'$   $  $?h,.`.`.`.`,J??;$F $  $    $ ""$ . ,=-cc"""
$;;;;;;;;;;;;?h.  <$F $ $   $  $;;;;?TTTT??;;;;;P  F  $  > $  .`h "c`h.
$;;;;;;;;;;;;;9h?$C$ J',P   F  $h;;;;;;;;;;;;;;9> j'c $  > ?  `h`h `"c`h.
$;;;;;;;;;;;;;;h;;;$ $ $ \  F  $$;;;;;;;;;;;;;;9' 3 $ $  h `h  $ ?c"h.3?=,_
`h;;;;;;;;;;;;;$;;;$j'<$ `h.F  F<C;;;;;;;;;;;;;J> $ $ $  $ `h   $ $Pc,`"?$h.
 $;;;;;;;;;;;;;??;;P$ $F  h,F  F,c;;;;;;;;;;;;;$> $ $ $  $  C    ?c?c  "???"
 `h;;;;;;;;;;;;;;;9FF<$   h,F j'J;;;;;;;;;;;;;$ h $ $ ?. $  $   `h`?`h
  ?;;;;;;;;;;;;;;;$<F$$   F,F $,c;;;;;;;;;`;;J'J3 $ $ `h ?  $h   `h`h.`.
   $;;;;;;;;;;;;;;FJj'$  .F  Jl$;;;;;;;;;;;;$.P.`,? ?  h `h <$?   ?h `$C3hc
    $;;;;;;;;;;;;J $$ $  J'  $ $;;;;;;;;;'J"3" $,'? ?. $  $  $'L   $"',"","
     "i;;;;;;;;;;$j'$ $  $  J',C;;`;;;ii?3$'J $ $ `L`h `h ?. `h'L  .?,_
      `i;;;;;;;;;$$$L ?',F .P $.`.`.j??$cc,' J' F  $ $  $  ?   $ ?c`-,,h.
       ?;;;;;;;;;;;$$?c$F  P J'.`.`.`.`.`P" ,F `F  ? `h `h  h   $  ???
       `C;;;;;;;;;;;$>    / J'`.`.`.`.`.??3FJF  $   L $  `h `h  c$$.
        $;;;;;;;;;;;$,?,-<c$`.`.`.`.`.`.`.`$F$c `h  `h_$  `L  $???"`$
        $;;;;;;;;;;;'"$ $?$.`.`.`.`.`.`.`.`?`.`?$$.    `?c,$$,`L`.`.`h
        $;;;;;;;;;;`.?LP'`?.`.`.`.`.`.`.`.`.`.`.`.`?c,    $$F.`.`.`.`3
        <h;;;;;;;;`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.?$?cJ;,.`.`.`.`3>
        <C;;;;;;;.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.;;;.`.`.`.`3'
 
You wouldn't have two machines, typically, you'd have a single machine. Computers were expensive!

My primary experience was on a VAX 11/730, used to collect and process reliability data for Navy weapon systems. We used Datatrieve, which was a DEC reporting tool that leveraged RMS, which was the multiuser B-Tree database library built into VMS. We also wrote custom BASIC programs against that. We really pushed Datatrieve far. We had our own screen/form code to make data entry forms easier to write.

Also did a lot of work on Alpha Micros. We supported over 100 users on a 68030 based machine. That was all written in a BASIC dialect.

Later I moved on to UNIX boxes, and a SQL backend.

CP/M was very big in the small office space. BASIC and DBase were the killer apps there for writing applications. The B-Tree index is what made DBase (along with it's special language) very powerful. While the B-Tree index was available for BASIC, it was not routine in the CP/M BASICs. That's what prompted my original query about how folks were using BASIC back in the day.

Similarly, with the PDP-11 and RSTS/E and BASIC-PLUS, out of the box, it also did not support B-Tree indexes. I don't know if they every brought RMS to the PDP, or if that was only a VAX thing. But early BASIC-PLUS did not. It did have stuff like Virtual Arrays (BASIC Arrays backed by disk files), but also the typical BASIC style random record I/O capability.
 
Dbase the killer app 100%
Accountants didn’t need lotus 123 you still used the large tabulation books
Word processing was still on a typewriter back then
But a database where you punched in the customer information and had notes together with mail merge
And label making was the bee’s knees.

Even wordstar under c/pm supported mail merge which is amazing when you think about how early things were.

Then when you had multiple computers linking to the dbase meant multiple sales marketing stations all adding to the database at once.
 
Also, our office used (me) Borland Paradox under DOS back in the early 90's for some projects, but dBase was everywhere. As was WordPerfect for DOS.
 
Yes, dBase was everywhere.
Clipper/dBase III was a combo.

In BASIC you could make a flat-file app. I did that stuff commercially. It all depends on the frequency of data access and size of data. The bad algorithmic complexity doesn't matter if you can ensure low number of records. BASIC made a boom in productivity and business software in the 90s because someone could write a amateur piece of software for a limited business domain problem, and the computer could still run it with fairly good results.

Also there's a distinct difference between bookkeeping software and software that's in the business flow, like point of sale. The frequency of data access and size of data. Software I made was bookkeeping, someone would fire it couple of times daily and update something in a limited amount of records.

The more general purpose business software like POS and accounting was never done in BASIC at least in my local market. Visual Basic yes, in the late 90s. But normal BASIC no. Aforementioned Clipper/dBase was heavily used up to mid 90s.
 
Endersending said:
It sounds like most software was build with some type of BASIC. Where did COBOL, FORTRAN, FOURTH, PASCAL fit in?
Click to expand...

thing to remember was machines shipped with basic, didn't cost extra. so you worked with basic and if you needed something faster then you bought that software.
Cobol and Fortran i worked at a bank in the 1970s was the standard languages most of the code from the 60s ported over and was expanded and maintained.

Fourth was an obsure language back then. it is not something we came across.

Pascal started to become standard in the late 1980s from my experience. going into the early 1990s it was pushed for Information technology in colleges, this was replaced with Java by the mid 1990s.
pascal was of course around all through the 70s and 80s. there were commercial applications written in pascal, some even advertised as such.
Qbasic also i would say ran hand in hand with pascal as there was business software that again was advertised it was written in it.

what would happen is if something required speed and it was critical in those early low speed days then it was assembler or C written. pascal was a little slower and not as mainstream.
later the machines got faster and then higher level languages were good enough and exploded into the 1990s and beyond.

at the bank there was a bunch of frontend software written in pascal. the back end was always cobol or fortran.
 
furball1985 said:
thing to remember was machines shipped with basic,
Click to expand...
Many micros shipped with BASIC, CP/M machines, however, did not.

Many mini computers came with BASIC. DEC, DG, Prime, Alpha Micro. PICK was a BASIC dialect. IBMs came with BAL, RPG, and COBOL.

Appreciate that early on, BASIC was very efficient to develop software in. Pascal didn't really come into the fray until Turbo Pascal arrived, because PASCAL was a mostly academic language. FORTRAN wasn't that apt for business applications because with the FORTRAN IV/66 standard, working with character data was literally awful. This really isn't that big of a deal with a lot of reporting, but it was not natural in the slightest.

But either way, both of those languages tended to require a build step. Many BASICs did not. You made the change, hit RUN, and you're off. No edit/compile/link/run cycle. Folks don't appreciate how horrible old hardware was!

None of those languages really offered any specific benefit to business applications.

COBOL is the obvious exception, but while it was certainly available on other platforms than IBM and mainframes, it just wasn't popular in the mini/micro market. But on CP/M? The compiler was a FIVE pass compiler, that spit out p-code. You really want to sit through that watching the machine scrape rust off your floppy disks? Boy, I sure don't. COBOLs silver bullet was built in ISAM or B-Tree indexing.

BASICs ability to work well with random files, format output nicely (via PRINT USING), rapid development cycle, powerful string handling (BASIC strings were a magic bullet, not much else had anything like it) and low impact on the machine (8K BASIC was powerful enough) made it a good fit for business applications.
 
whartung said:
BASICs ability to work well with random files, format output nicely (via PRINT USING), rapid development cycle, powerful string handling (BASIC strings were a magic bullet, not much else had anything like it) and low impact on the machine (8K BASIC was powerful enough) made it a good fit for business applications.
Click to expand...
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”.
 
whartung said:
Appreciate that early on, BASIC was very efficient to develop software in. Pascal didn't really come into the fray until Turbo Pascal arrived, because PASCAL was a mostly academic language. FORTRAN wasn't that apt for business applications because with the FORTRAN IV/66 standard, working with character data was literally awful. This really isn't that big of a deal with a lot of reporting, but it was not natural in the slightest.

But either way, both of those languages tended to require a build step. Many BASICs did not. You made the change, hit RUN, and you're off. No edit/compile/link/run cycle. Folks don't appreciate how horrible old hardware was!
Click to expand...
UCSD Pascal was a major player in the later 70s and early 80s. Programs could be run inside the development environment before being "compiled" for distribution. Unfortunately, UCSD did not have the ability to continue to support a large user base so UCSD sold off the languages to a defense contractor that raised prices but otherwise largely ignored the product line. Turbo Pascal took design inspiration for UCSD Pascal but aimed for a fast in memory compilation. Turbo Pascal's Nascom based predecessor Blue Label had to do the compilation in memory since it was running on cassette.

Fortran-77 added all the character processing classic Fortran lacked. Fortran-77 broke a lot of existing Fortran IV code which slowed adoption considerably.
 
You must log in or register to reply here.
Back
Top