Why GLOBALS ?Contestant

During my work with customers and also following I often met the 
explicit or embedded question: What is this "GLOBALS" ?
I'll try to explain the history to unfold the context.

First, the naming:
Several programming languages know the expression "GLOBAL"
In InterSystems ObjectScript (ISOS) GLOBAL it's a persistent variable 
in opposition to a (LOCAL) variable that just exists in the partition
where your code is running in.

Back in the 60ties & 70ties persisting data meant writing it to a disk.
No surprise. Having a FileSystem on your disk was already some comfort.
Files were dominated by fixed-length records with a few exceptions.

Missing a filesystem meant calculating cylinder + sector addresses to write
your data sector by sector to some disk-like storage.  
The invention of the B-Tree in 1970 showed a far more efficient solution.
More details on B-Tree in Wikipedia
Developing a B-Tree based disc storage system was a masterpiece
that allowed the storage of variable-length data items persistently on disk.
As these items were not files but free structures of variable data. They 
were named GLOBALS, being available globally all over the data store.

The native language for access has evolved with many features and 
has become InterSystems ObjectScript today. It contains many new 
extensions and options but has not dropped any of the original features. 

First implementation as an autonomous operating system (DSM) in combination 
with a clever compression algorithm made it the fastest database in its class. 

WHY ?

1. Data transfer between core and disk is the slowest piece.
   smaller + compressed packages mean faster traffic
2. Fewer (generic) layers between data creation and data store speed up.
   With other DBs you pass OS level, FileSystem level to get to DB level.
   By today's technology, this has become less important              
3. But the main contributor was the B-Tree structured GLOBAL store.
   At a presentation of Oracle around 1995, they proudly announced:
   "We now also offer a B-Tree store strategy" or similar. Just 20 years later 😉

This success also had a sad side.
DEC was not aware of the jewel they had in their portfolio and focused only on VAX, 
Clusters and ported DSM as a layered product on top of VMS and their RMS file system.
And the effect of #2 above hit them hard just as other DBs before. No surprise to me, 
as I did a similar experiment with RSX-11M some months before with similar poor results. 
Any DSM on 16bit PDP-11/34 outperformed at that time their pride (32bit VAX). 

Disappointed by their hard-minded ignorance, I joined a customer to write our own
stand-alone OS+GLOBAL DB operating system on barebone VAX, which we named VISOS.

How did this run?

• Polish the strategy, design useful enhancements, and targets
• Buy a naked machine and start reading the processor's handbook
• Passing page 40 start typing your code by 2 expert engineers.
• 18 months later, run your first customer installation

Then the implementation on VAX outperformed the PDPs significantly.
Just one special feature: 
As data blocks were 2048 bytes sized,  I implemented also my sector size on disk 
with 2024 bytes. Besides the performance gain, this turned out to be also as a 
security feature. Even DEC HW support was unable to read these disks.
Time went by. DEC and its buyer vanished, and VISOS ran out of available hardware. 

Today data and program store in IRIS is still based on the GLOBAL architecture.
It's now far more advanced with many modern features, but the basics haven't changed.
To my knowledge, it is the only DB+programming environment that is able to run without 
any change some code that was written ~50 years ago over all versions since creation.
My (former) customers always noted this as a special feature, unavailable anywhere else.
So you might understand that GOBAL is burned deep into the minds of developers in IRIS.