Conference turris::languages

6.0. "DIBOL (and some MUMPS) flames" by VAXUUM::DYER () Wed Jan 18 1984 23:58

	Here are a few things said about DIBOL (Digital Business Oriented
Language) and MUMPS (whatever) in ALIEN::SYS$NOTES:FLAMES.NOT.  I don't
know anything about either language, but here's what others have said!
	This note is about 12 pages long.
		<_Jym_>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  29-DEC-1983 17:03           ALIEN::SZETO       

The DIBOL folks will tell you that DIBOL, not BASIC or COBOL is the most 
important commercial language on DEC machines.  I don't have the figures to 
prove it, and I'm not interested in proving it.  However, I tend to agree that 
DIBOL is less well regarded as it ought to be, similar to BASIC-PLUS.

I'm no DIBOL guru, so I don't know how lean and mean DIBOL really is.  But I 
believe that compared to COBOL and BP2, DIBOL is a language that still hasn't 
outgrown the PDP-11.  Sometimes it's a good thing that some things escaped the 
clutches of Central Engineering (until recently).

It's probably unfair for me to bemoan how Languages killed both BASIC-PLUS and 
BP2, in two different ways.  I just hope we still have a decent language left 
for the 11.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   2-JAN-1984 10:30           ATFAB::WYMAN       

DIBOL is (or was definitely until 1 year ago when I last checked) Digital's
most popular and important commercial language. DSM has also been surprisingly
big in the field. DIBOL suffers, though, because it wasn't a Central
Engineering product until Marcus swallowed COEM Engineering. Although, DIBOL
was responsible for a massive amount of PDP-11 sales, and although it should
be credited with a good bit of DEC's success in the Commercial marketplace,
it is universally reviled and people are constantly trying to "replace" it
or "phase it out".
				   * * *
		bob wyman
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   2-JAN-1984 21:00           PIXEL::DICKSON     

I wouldn't say DSM-11 == VAXElan.  Both are an operating system,
but DSM is also a development environment.  You don't need a
host system to do your compiles, as I understand you do for
VAXElan.  DSM-11 also has the interpreter in it, as the nature
of the MUMPS language REQUIRES an interpretive (or partially
interpretive) implementation.

An application designed for VAXElan would undoubtedly run faster,
provided you wrote all the nifty optimization tricks that DSM
has built into it, due to not being interpretive.  The symbol-table
lookups are what really kill you.

For those not familiar with MUMPS, here is an example:

	SET A=3
	SET B="A"
	SET C=@B

The variable C now contains the value 3.  Or even worse:

	SET D="SET C=4"
	XECUTE D

Now C contains the value 4.  With things like that in the language,
MUMPS will always have an execution speed disadvantage.  But it
has a big DEVELOPMENT SPEED advantage.  And in real applications
pure cpu speed is not a problem, so it is feasible after all.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  31-DEC-1983 01:01           ARK::THOMPSON       
				   * * *
DIBOL is a highly under rated language. It is easy to learn with a
simple structure. CTS-300 which is basicly time-shared DIBOL under
RT-11 runs like a bat out of hell! DIBOL applications are getting more
transportable all the time. RT-11 to RSTS (or RSX now too!) to VMS.

Its simplicity offends people who want (or is it need?) complex
structures to write usable code. I love it. For business applications.

Alfred
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  11-JAN-1984 17:01           REX::MINOW       

Yeah, horray for Dibol.  Cobol for people who have to type their
own programs.

What the previous discussion of Mumps didn't explain is the reason
for Mumps: it's integrated database environment which treats the
entire disk as a tree.  You move along the tree by going down
one or more nodes, searching for the elements on a node that match
your application.  For example (all this is from memory), you
might use two-letter per level to encode names "Martin Minow" becomes
Ma.rt.in. M.in.ow  And the searcher wanders around in the disk
structure until it comes up with the answer.

Most mumps implementations are totally integrated with the operating
system, so the search loop (does this disk block contain the
key I'm looking for) is INSIDE the disk driver.  If it finds a
match, it decides whether there is another level and requeues a
read to the first block of the next level.

The mumps disk block allocator knows about searches, too, so it
allocates blocks using both rotational and head position latencies.
Mumps systems can search a 15-level index in two disk rotations.

Mumps does run on VMS (using RMS for the disk structures), but it's
nowhere near as fast as Mumps-11 or Mumps-15.

Martin.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  11-JAN-1984 21:40           SARAH::F_KLEINSORGE

	If I remember the screams from FS, Mumps-11 also
	doesn't deal well with bad disk blocks.

	By the way SWS sells a TECO macro to convert your
	DIBOL code into COBOL.  It's pretty accurate.  Too
	bad it can't convert it into DATATRIEVE...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

One of the aspects of DSM that doesn't get talked about enough in my opinion
is its unique way of dealing with files (although you don't really think of
them as such).  They have variable length records, keys and even field
definitions.  As a result, when you have very sparse fields in a record, you
don't have to waste a lot of room.  Furthermore, you can add new fields to
records without even modifying existing programs.

This is done by an internal DSM function called $PIECE (or $P for short).
With it you specify the record element, a separator charater and a segment
number.  The function returns that piece.  Therefore, if you have a record
containing a name and address, you might define it as such:

		NAME $ ADDRESS

Later, if you decide you really want city and state, you can turn it into

		NAME $ CITY - STATE

and the address is still the second piece, and you do a $P($P()) to get out
the city or state.  With a little imagination you can begin to see what
things can be done like this.

I've always wondered why noone ever though enough of this concept to include
$P's in other languages, seeing as I'm sure the overhead of executing such a
function could be kept minimal when done within the language impementation.


By the way, some of the wonderful things that RMS now does with key compression
and the like have been around in DSM for around 10 years (or at least 5).

The latest VAX DSM does not use RMS for its files, and is much faster
as a result.  VAX DSM took a beating on the "massive delete" function
using RMS, where every record has to be deleted one at a time.  In
the new implementation (lifted from DSM-11), it just marks the top
of the tree as "deleted", and a background process cleans it up
later.

  See Note 69.4 for more information about MUMPS in DEC.
                                               Bob Craig