The Minimum You Need to Know

About Service Oriented Architecture

By Roland Hughes

Logikal Solutions

Copyright © 2007 by Roland Hughes
All rights reserved

ISBN 
ISBN­13

0­9770866­6­6
978­0­9770866­6­5

This book was published by Logikal Solutions for the author.  Neither Logikal Solutions nor the 
author shall be held responsible for any damage, claim or expense incurred by a user of this book 
as a result of its use or reliance upon.
These trademarks belong to the following companies:
ACMS
Hewlett­Packard Corporation
Ask.com
IAC (InterActiveCorp)
Attunity
Attunity Ltd.
Borland
Borland Software Corporation
        DEC
Digital Equipment Corporation / Hewlett­Packard Corporation
DECdtm
Digital Equipment Corporation / Hewlett­Packard Corporation 
DECForms
Digital Equipment Corporation / Hewlett­Packard Corporation 
DR DOS
DRDOS, Inc.
MS DOS
Microsoft Corporation
JBuilder
Borland
JSP
Sun Microsystems
Linux
Linus Torvalds
MQSeries
IBM (International Business Machines Corporation)
MySQL
MySQL AB
OnPlatform
Hewlett­Packard Corporation / Attunity Ltd.
Oracle
PostgreSQL
RDB
Reactivity
RMS
Tru64
Ubuntu
Unix
Windows

Oracle Corporation
PostgreSQL Global Development Group
Oracle Corporation
IBM
Hewlett­Packard Corporation
Hewlett­Packard Corporation
Canonical Ltd.
The Open Group
Microsoft Corporation

All other trademarks inadvertently missing from this list are trademarks of their respective owners.   A best effort was 
made to appropriately capitalize all trademarks that were known at the time of this writing.  Neither the publisher nor the 
author can attest to the accuracy of this information.  Use of a term in this book should not be regarded as affecting the  
validity of any trademark or service mark.

Acknowledgments
Books  like this,  the  planned  closing  of  a  series  segment,  come  about  because  dedicated 
readers like yourself purchased, read and wrote about the prior books in the series.  When that 
doesn't happen, a series segment simply gets left undone.   To paraphrase the Bartles & James 
commercials:  I thank you for your support.

Source Code License
Any   person   owning   a   copy   of   this   book   may   use   the   source   code   from   this   book   and 
accompanying   CD­ROM   freely   when   developing   software   for   their   personal   use,   their 
company's use or their client's use.  Such persons may include the source code either modified or 
unmodified provided that the source delivered makes reference to the original author and is part 
of a fully functional application.  It is expressly forbidden for anyone to post this source code on 
any bulletin board system, Internet Web site, or other electronic distribution medium without the 
express written permission of the author.  It is also expressly forbidden to sell this source as part 
of a library or shareware distribution of source.
Users of the source code contained within this book and on the accompanying CD­ROM 
agree to hold harmless both he author and the publisher for any errors, omissions, losses, or other 
financial consequences resulting from the use of said source.    The source code is supplied “as 
is” with no warranty of any kind expressed or implied.

Table of Contents
1.   Introduction...............................................................................................................................1
1.1  SOA – Where We Came From............................................................................................1
1.2  The Disaster We Are Headed Toward................................................................................4
1.3  Why We Are Headed There................................................................................................6
1.4  The Roots of SOA...............................................................................................................8
1.5  Additional Reading..............................................................................................................8
2.   Clustering..................................................................................................................................9
2.1  What is Clustering...............................................................................................................9
2.2  Distributed Transaction Management...............................................................................14
2.3  Two­phase Commit...........................................................................................................15
2.4  Shared Resources..............................................................................................................16
3.   What is Wrong Today.............................................................................................................19
3.1  We Sold Modules..............................................................................................................19
3.2  We Are Still Selling Modules...........................................................................................20
3.3  The End of Modules..........................................................................................................21
3.4  How Do We Fix This?.......................................................................................................22
3.5  Today's SOA Camps.........................................................................................................24
3.6  Start Small.........................................................................................................................28
4.   Green Screens on the Web......................................................................................................31
4.1  Obtaining a Web Server....................................................................................................31
4.2  Obtaining a Web Terminal................................................................................................32
4.3  Is This SOA?.....................................................................................................................35
5.   ACMS Fundamentals..............................................................................................................37
5.1  Why Are You Only Hearing About ACMS Now?............................................................37
5.2  Flow Description...............................................................................................................39
5.3  General Principals.............................................................................................................40
5.4  IO Routines........................................................................................................................43
5.5  The Major Pieces...............................................................................................................44
5.6  Which Type of ACMS Application?.................................................................................49
5.7  Security..............................................................................................................................50
5.8  The March Forward...........................................................................................................51

6.   Our First Steps.........................................................................................................................55
6.1  Deciding on the Method....................................................................................................55
6.2  Direct Database Access via Remote Java..........................................................................56
6.3  Some Thoughts on Editors................................................................................................62
  Illustration 6.1. .................................................................................................................64
  Illustration 6.2. .................................................................................................................65
  Illustration 6.3. .................................................................................................................66
  Illustration 6.4. .................................................................................................................68
  Illustration 6.5. .................................................................................................................70
6.4  Database Access via Java Applet......................................................................................72
  Illustration 6.6. .................................................................................................................73
  Illustration 6.7. .................................................................................................................81
6.5  A Bit More on Shell Scripts..............................................................................................83
6.6  What About MySQL?.......................................................................................................84
  Illustration 6.8. .................................................................................................................90
6.7  What Have We Learned?..................................................................................................94
7.   A Direct Port............................................................................................................................95
7.1  Why This Method?............................................................................................................95
7.2  How Will We Proceed?.....................................................................................................96
7.3  The Login Dialog..............................................................................................................98
  Illustration 7.1. .................................................................................................................98
  Illustration 7.2. ...............................................................................................................103
  Illustration 7.3. ...............................................................................................................104
  Illustration 7.4. ...............................................................................................................105
  Illustration 7.5. ...............................................................................................................113
  Illustration 7.6. ...............................................................................................................114
  Illustration 7.7. ...............................................................................................................130
  Illustration 7.8. ...............................................................................................................131
  Illustration 7.9. ...............................................................................................................132
7.4  Assignments....................................................................................................................143
7.5  Experts.............................................................................................................................143
7.6  Too Much Time On Your Hands....................................................................................144
7.7  Is this SOA?.....................................................................................................................144

8.   Service Types........................................................................................................................149
8.1  Different Types of Service..............................................................................................149
  Illustration 8.1. ...............................................................................................................152
8.2  Exposing RMS Files via Services...................................................................................154
8.3  Assignments Part 1..........................................................................................................174
8.4  Using Those Services......................................................................................................174
  Illustration 8.2. ...............................................................................................................175
  Illustration 8.3. ...............................................................................................................186
8.5  Assignments Part Two.....................................................................................................189
8.6  Is This SOA?...................................................................................................................192
8.7  What About Security?.....................................................................................................193
8.8  Summary.........................................................................................................................195
9.   Load Balancing and Fault Tolerance.....................................................................................197
9.1  Brute Force......................................................................................................................197
9.2  Back­End Balancing........................................................................................................198
9.3  Warehousing Policy Effect on Load Balancing..............................................................205
9.4  How Do You Balance the Load?.....................................................................................208
9.5  How Do You Protect the Transaction?............................................................................208
9.6  Can I Use DECdtm Without ACMS?..............................................................................213
9.7  How Much Fault Tolerance Does DECdtm Buy You?...................................................214
  Illustration 9.1. ...............................................................................................................216
  Illustration 9.2. ...............................................................................................................217
9.8  Can I Use MQ Series Without ACMS?...........................................................................221
9.9  Queue Trigger.................................................................................................................221
9.10  Summary.......................................................................................................................222
10.  An ACMS Example..............................................................................................................223
10.1  Scope of Our Example..................................................................................................223
10.2  Our DTD........................................................................................................................226
10.3  Our Files .......................................................................................................................231
10.4  ACMS Queues...............................................................................................................240
10.5  The Interim Record Formats.........................................................................................249
10.6  Parsing XML on OpenVMS With Xerces.....................................................................251
10.7  Parsing XML on OpenVMS With libXML2.................................................................256
10.8  Our Standalone XML Parser.........................................................................................262
10.9  One Last Bit About ACMS Queues..............................................................................278
10.10  Standalone to Server....................................................................................................283
10.11  Authorizing, Installing, Starting, Stopping and Testing..............................................316
10.12  Monitoring Your ACMS Applicaiton.........................................................................336

10.13  Controlling Your ACMS Application.........................................................................338
10.14  Our Port Service..........................................................................................................339
10.15  Our Order Generator...................................................................................................342
10.16  Assignments................................................................................................................346
11.  Whine and Snivel..................................................................................................................347
11.1  But, but, but...................................................................................................................347
11.2  The Item Service...........................................................................................................347
11.3  Our New Applet............................................................................................................350
  Illustration 11.1. .............................................................................................................350
11.4  Summary.......................................................................................................................360
12.  Observations and Incantations..............................................................................................363
12.1  Overview.......................................................................................................................363
12.2  The Future of SOA........................................................................................................363
12.3  Java, Write Once, Run a Few Places.............................................................................367
12.4  Grade 8 Bolt Syndrome.................................................................................................368
12.5  In Closing......................................................................................................................370

Chapter 1
Introduction
1.1

SOA – Where We Came From

For quite some time now, marketing shills have been preaching and selling SOA (Service 
Oriented Architecture).  Vast quantities of money have been poured into “The Next Big Thing.” 
Well, it is time to ask a few questions and rain on their parade.
What is the Service Oriented Architecture?  This is a re­hash of an old business model that 
played itself out from the 1970s into the 1980s.  Back then computers were multi­million­dollar 
investments.   Small to mid­sized companies simply couldn't afford them.   Programmers were 
scarce and qualified programmers even scarcer.   Small to mid­sized companies could afford a 
few thousand dollars for terminals and special modems.  Then they spent several more thousand 
dollars per month leasing time on computer systems.   There were actually businesses that did 
little more than lease time.  They would also sell consulting services and lease access to some of 
their applications.  
Those   of   you   who   grew   up   with   $20/month   Internet   access   probably   have   a   hard   time 
imagining someone paying thousands of dollars per month for access to a computer system, but 
it   happened.     Commercial­class   operating   systems   provided   system   and   application   run­time 
accounting.  Among other things they would measure the amount of computer time, connection 
time,   and   IO   that   each   user   ID   performed   on   the   system.     Every   month   the   subscribing 
companies would be billed by the CPU second, connection minute and block of IO.  It shouldn't 
take a rocket scientist to do the math here.  One thousand customers paying $10K+/month to use 
your computer system paid off a $2 million price tag pretty quickly.  Even 100 customers could 
make it viable if you were using the computer system to run your own business.  You bought the 
machine on time and they made the payments for you.
Of course, the companies looking to lease time didn't have programmers (initially) and didn't 
have applications, so those time­share businesses got into the custom software business.  They 
had proprietary data layouts that locked their clients into ever escalating support costs.   It was 
like a drug addiction you couldn't kick.  (Sound familiar to those of you using stored procedures 
in a commercial database?)

2

Chapter 1 ­ Introduction

Mid­range computers came onto the scene.  Many of the customers of mainframe time­share 
systems opted to buy a mid­range computer for about 6­12 months worth of their time share cost. 
Eventually, they too got into the custom application and time­share business, but not on as wide 
a scale.
Then came the PC.  Promising to put computing power in the hands of the people without 
any regard for where that would lead.  Vendors of hardware and software for these little boxes 
(for the time anyway) made money hand over fist.   Competition became cut­throat, and soon 
carcasses of once proud vendor corporations littered the landscape.   Companies had a rash of 
“desk drawer” applications that were now required to keep their businesses functioning.   Very 
little could communicate effectively or exchange data reliably.
To  stem  the   bloodshed,   companies   began  focusing   on  networking   technology.    Multiple 
competing   proprietary   networking   protocols   emerged.     File   servers   and   network   application 
servers   sprang   up   all   over  the   place.     If   you   could   afford   the   proprietary   network   interface 
equipment and the licensing, you could all use the same applications and share data (in theory).
Greed set in even worse than before.  It was nothing to end up paying well over $1,000 for a 
network card to get a computer online.  Sadly, you usually only paid about $3,000 for the PC to 
begin with.  Somewhere, in my souvenirs from the past, I have an ISA­based BiSync modem that 
operated at a whopping 1200 baud.  I paid just over $1,300 for it and it was a buy!  The name  
brand version was around $2,500 as I recall.  The great part about these proprietary networking 
systems was that they didn't talk to each other.  Communicating across them required even more 
expensive bridging software and dedicated hardware.  Even when you had the networking people 
configuring your machine in the office, you didn't always get network access.  In their own weird 
way, the same barriers people complained about provided a nearly unparalleled level of security. 
Networks were so finicky to get working from the inside, hacking in from the outside was almost 
a myth.

Chapter 1 ­ Introduction

3

Next came the TCP/IP standard, and the Internet.  People wanted everything to connect to 
the Web.  Hackers now had a standardized medium to exploit and they took to it with zeal.  PC 
prices dropped dramatically and PCs started popping up all over the place.  PC operating systems 
were (and still are) so unstable and riddled with security holes that every application and project 
had to have its own server.   Servers started appearing around corporations like rabbits taking 
both Viagra and fertility drugs.  Suddenly companies found they were spending as much on these 
“cheap” systems as they had been on the mainframes that took up less total space and consumed 
less power.
Enter the great server consolidation move.  Completely disregard the fact your PC server OS 
is unstable, requiring frequent  rebooting and patching, taking the applications off­line.   Load 
virtualization software on one, and consolidate 8 or more into one machine.  Uptime be damned! 
Now when you have to reboot you can take out 8 or more servers.
One problem still remained though.  Each application running on a server was pretty much 
its own data island.  Even when it stored its data in a database, that database was either on the 
same server itself, or the database wasn't the same one used by other applications.  Management 
had cost cut its way into a very bitter pickle indeed.
Fear   not   though,  the   marketing   shills  had   even   more   to   sell  them   under  the   heading   of 
“cutting costs.”  Management always listens intently to the “buy more to spend less” sales pitch. 
Repackage these applications with this magic middleware (for an additional fee) and you can use 
pieces of them, tying them together as you wish.  They will all have a protocol to exchange data. 
You can use order entry from this company, inventory management from that company, and if 
you   buy  today,   company   three   will   sell  you   a   piece   of   their  picking   ticket   &  truck   loading 
module.
In fact, if you want to use it all from one vendor, it will work the best.  No need to install 
their applications, simply lease time on their machines.  Get rid of all these pesky servers.  Let 
someone handle the updates and capacity issues for you.   Vendor A has built a massive data 
center in a single location with redundancy upon redundancy all in the same 40 acres.  After all, 
the world is one network now isn't it?   Why should you keep buying all of this equipment, 
simply pay for the time you use...

4

Chapter 1 ­ Introduction

Sounds   kind   of   familiar   doesn't   it?     Pay   by   the   application   module,   computer   use   and 
storage. If it only ended there, it would be laughable.  But it gets worse.

1.2

The Disaster We Are Headed Toward

What are they using to host all of this wonderful stuff?   Racks and racks of PC­on­a­card 
servers.  Heat is a bigger problem for them than it was for the old mainframes.  Some companies 
are   now   looking   into   liquid   cooling   systems   for   those   “personal   computer”   chips.     Liquid 
cooling, just like some of the big mainframes used.
What operating systems are they running?  The same crummy operating systems that were 
running at the client company.   Security holes and patches are a seemingly daily if not hourly 
occurrence,   but the  client  companies  are   used  to  outages.   Outages   have  become   a  business 
standard.
What   happens   when   one   of   those   PC­on­a­card   devices   fries?     Why,   they   load   you   up 
another one at some point.   Can't really say how long the outage will be, but you're used to it 
already.  Sorry about the transactions that were being processed, but you are used to losing those 
as well.
These faults can all be classified under the heading “Ignorance of a Cheap Mind.” 
What cannot be classified under that heading, or even forgiven, is the packaging.   These 
supposed forward thinkers have all bought into the idea that one massive data center located on 
X acres some place cheap is a good idea.   What is even more unthinkable is that Congress is 
letting them do it.
I'm not talking about Congress being in control of business.   I'm talking about Congress 
letting the National Security Agency take these “industry leaders” into a dark alley with ball bats 
and cattle prods to educate them on the finer points of economic and industry stability.
Let us assume for a moment that Congress is too busy getting re­elected to do anything 
useful.     (Admittedly,   not   a   big   assumption.)     These   data   centers   on   steroids   are   allowed   to 
prosper.    They have huge dollars behind them and drive  out competitors so we have only a 
handful.   Nah, let's shrink the number.   We end up with only three, just like we did with auto 

Chapter 1 ­ Introduction

5

manufacturers years ago.
With greed coursing through their veins stronger than any narcotic on the market, they enter 
a cut­throat competition just like the PC manufacturers did.  Pretty soon, they've driven the price 
down to just a couple  thousand per month no matter how  much  you use.   Talking heads  at 
companies around the country start chanting “cut costs” and looking in the direction of these 
“service providers.”  Yes, it's a financial Utopia all right.
In a need to differentiate themselves in this market, the “Big 3” buy up applications focusing 
on specific market segments.   One provides the best of the best in banking software.   Soup to 
nuts   online   checking,   accounting,   wire   transfer,   you­name­it­they­can­do­it   banking   product. 
Another ends up focusing on the complete solution for manufacturing.   We are talking order 
entry, inventory control, sales force management, assembly line systems, shop floor control, the 
works.   The last of the three ends up providing best in class shipping logistics.   From truck 
loading to routing, and everything in between, they have modules to do it.
Ah, Utopia.  They even develop a working relationship, so the manufacturing systems can 
use the shipping logistics modules and they both use parts of the financial modules.  It truly is 
bliss.  This is what marketing has promised and they finally delivered.  Sort of...
No matter how you slice it, these providers spent heaps of money building up one location. 
Usually where there was really cheap power.  One of them ends up getting built well within the 
blast radius of Mt. Rainier when it finally pops its top.  (According to scientists within the next 
20 years, but they guessed a little long on Mt. St. Helens, so it is probably at the shallow end of 
the 20.)  Another gets built on a major fault line because power was half the price of anywhere 
else.   The last gets built in the low cost real estate district found near the end of major airport 
runways because they got a sweet deal from the state and city governments.
It   shouldn't   be   any   surprise   where   this   is   heading.     It   doesn't   matter   how   much   power 
generation   and   redundancy   each   location   has   built   into   it,   they   will   be   taken   out,  either   for 
months or permanently.  A jet has engine trouble on take off and crashes, Mt. Rainier decides to 
prove the nay sayers wrong, and that 8.2 quake finally does originate from the dormant fault line 
just like geologists said it would eventually.  In this day and age, we also have to deal with the 
possibility   of   a   terrorist   group   either   crashing   a   jet   or   driving   a   truck   load   of   homemade 
explosives into the site.   Let us not forget things like Katrina and the tsunami for the centers 
within a few miles of a coast line.  Once we get to a “Big 3” or even “Big 4” situation with these 

6

Chapter 1 ­ Introduction

single location service centers, the destruction of one, by any means, cripples a nation and quite 
possibly the world economy.   PC and UNIX people think only about loss of a single piece of 
equipment or power.  Midrange developers think about the loss of an entire facility.

1.3

Why We Are Headed There

Where we are headed is not good because of the premise which started it all.  Actually, there 
were multiple premises that lead us down this gilded path:



Running   core   business   systems   on   feeble   operating   systems   was   OK   because   the 
hardware was cheap.
Using operating systems which cannot cluster completely is OK when they are cheap.
Replacing existing systems with a flat monthly fee service was a great way of cutting 
costs.
Building a single massive location to do everything and get economies of scale was a 
good idea.

Cheap hardware  lead to the PCs on Viagra and fertility drugs scenario.    Well, that, and 
unstable operating systems.   Even IBM is running ads about servers being so numerous you 
cannot walk in a building.   While they are an exaggeration, they aren't off by much.   Oddly 
enough, IBM marketed the original IBM PC direct to businesses in the first place, so this is kind 
of like profiting from the sins of your past.
Cheap operating systems.  Gotta love that.  I remember companies and people complaining 
about   spending   $80  for DOS.    At  least  with  DOS,  once   you  bought  it,  it  was  yours.     Now 
Windows is moving toward the “As soon as you stop paying for the service agreement your use  
license expires” model with an initial rental price of around $300.  Commercial flavors of UNIX 
had their own trappings when it came to license agreements.  Now people hold up Linux as the 
be all and end all.  Only one problem, none of these operating systems cluster correctly or well. 
They network, but do not cluster.   Even the Tru64 version of UNIX, released by the company 
that gave the world its first (and still only) commercially viable clustered operating system didn't 
manage to get clustering working correctly in UNIX.  The problem is, you can't be loyal to the 
UNIX installed base and cluster.  The platform is missing critical pieces, and when those pieces 
are  added, it won't be UNIX anymore, it will be a clone of OpenVMS with some command 
syntax changes.

Chapter 1 ­ Introduction

7

Flat monthly cost.  Management loves the flat monthly cost model.  Indeed, Internet access 
providers   and   now   cable   phone   providers   are   herding   consumers   towards   that   mentality. 
Management loves it because they now only have one thing to look at when they sit around in a 
talking heads meeting chanting “cut costs.”  Leaves more time for the golf course.
A single massive data center.  Now here is an idea straight from the 1970s.  You have to be 
old to remember it.  The classic IBM mainframe data center.  Raised floor to hide cabling, route 
air conditioning, and provide a water trap.  Bullet resistant glass wall so people could walk by 
and be amazed by the equipment.   Two to three layers of fire protection.   Multiple lock entry 
security.  In some cases, even data center guards by the doors.  Let's not forget the massive diesel 
engine   generators   parked  right  outside  the  building  and  in  later  years  the  room   full  of  UPS 
(Uninterruptable Power Supply) equipment.
IBM was the originator of the “big iron” trend.   It didn't cluster, but it did have it's own 
proprietary networking for communications.   As the platform progressed it also had machine 
partitioning.     This   would   let   you   divide   up   your   “big   iron”   box   so   it   looked   like   multiple 
mainframes to the outside world.  Sounds a lot like  virtualization  doesn't it?   Big iron was big 
bucks.  They didn't bother with clustering technology because very few companies could afford 
to scatter a dozen or so of these around the country.  Instead, they put forth what became known 
as the “moat and fortress” data center design.  This lead to the bank teller bullet resistant glass 
plates and the other things we talked about.   I never really did figure out what the moat was, 
unless it was the raised floor or the fact many companies were told to locate their data center on 
the second floor, not the first or the basement.  They used to get put in the basement because the 
equipment was so heavy, then someone thought about the flooding issue.
DEC (Digital Equipment Corporation) focused primarily on the midrange market for mid­
sized companies.  These were companies that could afford to spend one half to two million for 
their entire data center and computer system.   The companies knew they needed  a computer 
system to compete and keep growing, but they couldn't bite the bullet for a multi­million­dollar 
mainframe setup.   As the companies ran more efficiently with the computer system they kept 
finding more and more uses for it.   For a time they bought bigger and bigger boxes, but the 
engineers at DEC came up with an even better solution.  Buy more of the same and hook them 
all together so files, batch jobs, users and processing power could be utilized throughout a cluster 
of computers.   As communications improved worldwide,  these clusters, literally spanned the 
globe.

8
1.4

Chapter 1 ­ Introduction
The Roots of SOA

Both   DEC   and   IBM   hit   on   the   need   for   transaction   management.     IBM   created  CICS 
(Customer   Information   Control   System)   and   DEC   created   ACMS   (Application   Control 
Management System).  Both of these were and still are amazing products. ACMS had the most 
far reaching implications, yet few realized it.  Sadly, much of the market missed it.
While the concept will be completely foreign to those coming from the PC and UNIX sides 
of life, these systems allowed you to both package functions for a Service Oriented Architecture 
and provided guaranteed execution.  A side effect was that each SOA task you created with them 
had a messaging format that did not allow for data overrun or SQL injection like the current Web 
fiascoes.   Yes, there are many third­party messaging systems these days making claims about 
guaranteed message delivery, but none will go so far as to guarantee its execution.
Because ACMS was the most far reaching and the one I have the most experience with, we 
will be discussing ACMS combined with clustering in this book. 

1.5

Additional Reading

If you like the style and content of this book, or would simply like to learn more about 
application development on OpenVMS, please pick up copies of “The Minimum You Need to 
Know to Be an OpenVMS Application Developer”  ISBN 0­97708660­7.  You can follow it up 
with   “The   Minimum   You   Need   to   Know   about   Java   on   OpenVMS       Volume   1”     ISBN 
0­9770866­1­5  ISBN­13 978­0­9770866­1­0.  
At some point “The Minimum You Need to Know About Logic to Work in IT” will be 
available as well.  This is not an OpenVMS specific book, but meant to be used as a textbook to 
teach those new to IT about logic.  It appears today's graduates haven't the foggiest clue about it. 
ISBN 0­9770866­2­3  ISBN­13  978­0­9770866­2­7.

9

Chapter 2 ­ Introduction

Chapter 2

Clustering
2.1

What is Clustering

Clustering, even today, is one of the most forward thinking concepts in the IT industry.  It 
was so far ahead of its time, the market couldn't really comprehend it.  Clustering requires that 
when a node joins the cluster, it honors and respects the consensus of the cluster.  To start with, 
it must use the same UAF (User Authorization File) as the rest of the cluster.  Access to cluster 
resources is controlled both by the standard (System, Owner, Group, World) protection settings 
provided by many platforms and ACLs (Access Control Lists).
ACLs require quite a bit of knowledge to implement.  You cannot simply bolt them onto an 
OS   which   doesn't   have   native   support   for   them.     Their   use   and   concept   must   be   firmly 
entrenched within the OS kernel.  Let me show you an example of a set of ACLs on a directory.
$ dir/sec dka1200:[000000]acl_test.dir
Directory DKA1200:[000000]
ACL_TEST.DIR;1
1/18
29-NOV-2004 17:37:24.04 [HUGHES]
(RWE,RWE,RE,E)
(IDENTIFIER=GST_S,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=GST_RE,OPTIONS=DEFAULT,ACCESS=READ+EXECUTE)
(IDENTIFIER=GST_RO,OPTIONS=DEFAULT,ACCESS=READ)
(IDENTIFIER=[*,*],OPTIONS=DEFAULT,ACCESS=NONE)

The   series   of   RWE   letters   enclosed   in   parenthesis   to   the   right   is   the   standard   (System, 
Owner, Group, World) protection I mentioned before.  Read, Write, Execute and Delete are the 
access privileges you can use for each class of user.  If a user is missing one of those letters, it 
cannot perform that function on the file or directory.   UNIX and its derivative works do not 
implement four levels, so they fall a little short from the start.
Take   a   look   at   the  ACL  list   though.     Each   identifier   gets   its   own   unique   set   of   access 
privileges.    The possible entries  are  READ,  WRITE, EXECUTE,  DELETE and CONTROL. 
Because this is a directory, the OPTIONS=DEFAULT clause is used to cause the  ACL  to be 
inherited by all files and directories created underneath this directory.  The very last entry in this 
list tells the operating system to completely ignore the standard (System, Owner, Group, World) 
settings for anyone other than the file owner.  The wild card entry [*,*] matches all identifiers.

10

Chapter 2 ­ Clustering

Order is very important within an Access Control List.  The entries must be in the order you 
wish them to be found.  For this reason, the highest privilege access levels are always listed first. 
The reason: the  ACL  is searched sequentially for the first matching rights identifier.   Once a 
match is found, that level of privilege or access is given to the user or process.  If [*,*] were first, 
it wouldn't matter what came after.
But what is a rights identifier, and where does it come from?  Rights identifiers are created 
by one of the system administrators from within the UAF utility.  They are then granted to user 
accounts   as   the   company   or   system   administrators   see   fit.     Normally,   companies   set   up 
procedures and forms for creating rights identifiers and granting them to accounts.
$ set def sys$system
$ run authorize
UAF> add/ident gst_ro
%UAF-I-RDBADDMSG, identifier GST_RO value %X80010001 added to rights database
UAF> add/ident gst_re
%UAF-I-RDBADDMSG, identifier GST_RE value %X80010002 added to rights database
UAF> add/ident gst_s
%UAF-I-RDBADDMSG, identifier GST_S value %X80010003 added to rights database
UAF> grant/ident gst_ro guest
%UAF-I-GRANTMSG, identifier GST_RO granted to GUEST
UAF> grant/ident gst_re guest
%UAF-I-GRANTMSG, identifier GST_RE granted to GUEST
UAF> grant/ident gst_s guest
%UAF-I-GRANTMSG, identifier GST_S granted to GUEST

As   you  can   see,   the   operating   system   chooses   a   numeric   value   for  them   at   the   time   of 
creation.  This is another reason each member in the cluster must respect the UAF chosen by the 
cluster.  While you might be able to manually create matching authorization files as far as users 
go on all machines, getting the rights identifiers to have the same value on all machines would be 
a very tedious task.
Once a user has some rights identifiers, it doesn't matter if they don't have any operating 
system level privileges.  As long as they have the authority to log in, they will be able to use any 
resource with a matching  ACL  entry for one of their rights identifiers.   In this way, you can 
spoon out access on a file by file, directory by directory, disk by disk,  batch queue  by  batch 
queue, executable by executable, etc. basis.  Most companies don't take it to quite that level, but 
you can if you wish.

Chapter 2 ­ Clustering

11

The UAF and rights identifiers provide the primary access keys to opening up the power of a 
cluster.  The hidden beauty of a cluster is the support for it built into the kernel.  One of the main 
foundations for that hidden beauty is logical name tables.  Most PC and UNIX type developers 
are only familiar with the concept of environment variables.  Under OpenVMS those are known 
as symbols.  Symbols aren't really useful in a secured and robust operating system.  They have 
some purposes, mostly for programs running under a single user ID, but they don't allow for 
controlled access or for being cluster aware.  The solution here comes in the form of logicals.
OpenVMS and RMS (Records Management System) utilize logicals extensively.  A logical 
is much like an alias only much more powerful.  Some of them are provided by the system and 
others you can create yourself as a programmer.  Logicals occur at what are called “levels.”  A 
level is nothing more than a logical name table in your logical search path.  Your search path is 
defined by a logical known as  LNM$FILE_DEV.   Every logged in process starts out with a 
default   version   of    LNM$FILE_DEV,  which   is   found   in   the   logical   name   table   LNM
$SYSTEM_DIRECTORY.   Various levels of “privileges” are required to define logicals, but 
every process can define its own process level logicals.
$

1
2
1

show log/table=lnm$system_directory lnm$file_dev
“LNM$FILE_DEV” = “LNM$PROCESS” (LNM$SYSTEM_DIRECTORY)
= “LNM$JOB”
= “LNM$GROUP”
= “LNM$SYSTEM”
= “DECW$LOGICAL_NAMES”
“LNM$SYSTEM” = “LNM$SYSTEM_TABLE” (LNM$SYSTEM_DIRECTORY)
= “LNM$SYSCLUSTER”
“LNM$SYSCLUSTER” = “LNM$SYSCLUSTER_TABLE” (LNM$SYSTEM_DIRECTORY)
“DECW$LOGICAL_NAMES” [table] = “” (LNM$SYSTEM_DIRECTORY)

The default definition of  LNM$FILE_DEV  shows you the primary levels of logical name 
tables.   LNM$JOB is the job level name table.   Each time a user logs in or a detached/batch 
process is created, it gets assigned a unique job ID and a job level logical name table is created. 
The   process   level   logical   name   table   is   created   for   each   process   as   that   process   is   created. 
Processes which are spawned, or otherwise created as children of a parent process inherit the 
parent job level table.  The group level logical name table exists for everyone in a group.  One 
table is created for each user group found in the UAF at system startup.  Each user process maps 
onto the group table for its group.

12

Chapter 2 ­ Clustering

The   system   level  table   gives  us  some  interesting  talking  points.    As  each  node   boots  it 
creates system level logicals which are available to all processes and users.  As each node joins a 
cluster, the cluster imposes its will by defining cluster­wide logicals.  These logicals exist in the 
local copy of the system table on each node in the cluster, but any update or modification of a 
cluster­wide logical gets replicated across the entire cluster.
Each application you create, buy or otherwise install, can, and usually does, create its own 
application level logical name table.   Sometimes access to these tables is thrown open to the 
world, and other times the table is created with an ACL for security reasons.  (You don't want a 
guest user to be able to look at logicals used by your accounting system.)   When a user needs 
access to these application level logicals, the name table is usually inserted into their local copy 
of LNM$FILE_DEV.
CREATE_NAME_TABLE.COM
$ create/name_table/parent_table=lnm$system_directory
my_app_tbl
$!
$ set security/class=logical/acl=(identifier=gst_re,access=read+execute)
$!
$ set security/class=logical/prot=(w) my_app_tbl
$!
$ define/table=my_app_tbl first_logical sys$login
$!
$ exit

my_app_tbl

The   above   is   a   command   file   or  script   for  creating   a   logical   name   table.     Below   is   its 
execution and output.
$ @create_name_table
$ show log/full/table=my_app_tbl
(MY_APP_TBL)

[super] [shareable]
[Protection=(RW,RW,R,)] [Owner=[HUGHES]]
(IDENTIFIER=GST_RE,ACCESS=READ+CREATE)

“FIRST_LOGICAL” [super] = “SYS$LOGIN”

You will notice that the protection on this table wasn't opened up to the world.  The world 
portion of (S,O,G,W) has no entries in it.  Somewhere in the user's login, or the startup for the 
application, there would be a command like the following to insert this application name table 
into the users definition of LNM$FILE_DEV.
$ DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$FILE_DEV LNM$PROCESS, LNM$JOB, LNM$GROUP, LNM$SYSTEM

Chapter 2 ­ Clustering

13

Logicals are required to make clustering work.  You cannot try to simply expand symbols or 
environment variables past their current local and global types.  It simply isn't their lot in life. 
Global symbols, by their nature, are unprotected.  There primary use is to simplify commands or 
exchange non­sensitive data.  Trying to add security to them would break their functionality 
badly.  Logicals were designed with security in mind.
One thing you may or may not have caught onto is that an application level logical name 
table can also be declared as a cluster­wide name table.   Instead of having the parent be lnm
$system_directory, the parent would be  lnm$cluster_table.   As each node joined the cluster it 
would inherit the table and enforce all access rules to it.  Any change made to the table on one 
node would be reflected in the table on all nodes.
Earlier I told you that each node joining a cluster makes its resources available to the cluster. 
In the early days of clustering, making the disk drives mount across the cluster and appear as 
local drives to a user was a great achievement.   Now that most disk farms consist of multiple 
SAN  (Storage   Area   Network)   or   disk   array   subsystems,   this   may   not   seem   like   such   an 
achievement.  To the contrary, it still is.
Disk storage subsystems have the built in capability to map an amazing number of spindles 
into what looks like a single physical disk to the connecting computer.  Their built in RAID and 
hot swapping capabilities off load a lot of work from the computers utilizing them.  The built in 
caching supplements the operating system level drive caching, increasing overall performance. 
These are great achievements indeed!  They have some limits though.
Because disk arrays and storage networks focus on the IO subsystem directly, in order to 
support   a   large   number   of   operating   systems,   they   don't   provide   anything   in   the   way   of 
transactional integrity.   Yes, the subsystem can do local drive shadowing, and will not return 
success   until   all   writes   have   completed,   but   this   still   doesn't   provide   you   with   transactional 
integrity.   To achieve transactional integrity, you need a distributed transaction manager built 
into the OS kernel.

14
2.2

Chapter 2 ­ Clustering
Distributed Transaction Management

A distributed transaction manager (DECdtm) makes the transactional integrity provided by 
relational   databases   seem   almost   weak   by   comparison.     A   distributed   transaction   manager 
provides a transaction level safety net across a wide range of items.  These include, but are not 
limited   to,   indexed   files,   message   queues   and   relational   databases.     If   you   write   a   program 
utilizing the distributed transaction manager, you can read a message from a queue, update some 
indexed files and write information to a relational database with the full confidence no changes 
will take place until you actually commit the distributed transaction.
Most of you are familiar with the COMMIT and ROLLBACK commands found in relational 
databases.  These commands are part of the integrity provided by the relational database engine. 
They do not provide any functionality outside of the relational database.   If 100% of our data 
resided inside of a relational database, this would be a good thing.  The fact of life is our data 
doesn't all reside there.   In the world of SOA, we have hundreds, if not thousands of message 
queues to deal with.  There always seems to be some “legacy” data that must remain in indexed 
files as well.  Quite simply, you can never get there.  DECdtm understands this and makes your 
life better.
What happens when you are half way through processing a message from a queue and your 
program crashes for some reason?   Without a distributed transaction manager, your relational 
database  “might” be able to realize  your process has died and  ROLLBACK  your transaction 
there, but what about the indexed files you wrote to?  What about the message you pulled off the 
queue?  You have a partially processed transaction with no method of starting over.  You have 
lost data integrity.
The   vast   majority   of   commercial   messaging   systems   try   to   provide   their   own   form   of 
COMMIT and ROLLBACK.  A few of these might also have the ability to determine the process 
that read a message from them no longer exists.  Most do not have that capability.  Because the 
messaging systems try to support a large number of operating systems to increase their market 
share, they tend to implement things like “triggers,” which kick off a job to read and process the 
message.  They only promise the message will not be lost between queues, and that they will fire 
the  trigger  the first time a message arrives.   If you read the message, start processing and fail, 
they will never fire the trigger for that message again.

Chapter 2 ­ Clustering

15

Many   shops   try   to   implement   a   work   around   by   having   the  trigger  fire   whenever   the 
message depth hits N messages in the queue.  The  trigger  process then is supposed to drain at 
least that many messages from the queue.   All well and good I suppose, but what about that 
partially processed message?  Nothing has done any cleanup, and your next trigger fire will try to 
process   it again  if  it has  been  restored  to the  message   queue.   If  the  message  has  not  been 
restored, it is lost forever.  What happens when your trigger depth is set to 10, and the very first 
message being processed was the one that made the trigger process abend?  Depending on how 
your queuing system counts, the depth will either be nine or still be sitting at 10.  If it is at 10, 
your trigger will never fire again.  If it is nine, your trigger will fire with the very next message, 
but the message being processed during the abend is lost and gone forever.
A cluster­aware distributed transaction manager is able to determine your process has died 
no matter what node it was running on.   It then performs the  ROLLBACK  operation for you. 
Robust queue managers like IBM's  MQ Series  are fully integrated with  DECdtm.   When you 
start a distributed transaction and read a message from an MQ queue, the message stays there, 
but is flagged as unavailable until the transaction completes.  If the transaction is committed, the 
message goes away.  In the event of a ROLLBACK, the message is reactivated, maintaining its 
place at the head of the queue.  This ensures the message will not be dispatched to another server 
prior to the cleanup having completed, and it ensures the message will not be lost.  Guaranteed 
delivery without guaranteed execution is a meaningless feature.

2.3

Two­phase Commit

A feature common to the OpenVMS market and quite rare on other platforms is something 
called a two­phase  commit.   While there are several very detailed (and some might say mind 
numbing)   explanations   around,   let   me   sum   it   up   for   you.     The   DEC   transaction   manager 
communicates with all other resource managers.  When you issue a DECdtm commit, it queries 
all of the involved transaction managers.   If they say they are ready and able to perform the 
commit, it issues the  commit  to them.   Once they have all responded  the  commit  completed 
successfully, the commit then returns a completion success to your application.  If even a single 
resource manager responds that it cannot participate at this time, no commit happens.
There are quite a few conceptual states to the two­phase commit.  If you really wish to know 
how it works, you can delve deeper into the documentation provided by HP.  What is important 
to know is that you will never get a partially committed transaction.  

16

Chapter 2 ­ Clustering

ACMS   is   capable   of   handling   this   for   you.     Each   time   a   transaction   starts   it   can 
automatically start a distributed transaction.   You can, if your logic requires it, start your own 
DECdtm transactions from within your ACMS server.
Without a two­phase  commit, it is physically impossible to coordinate a transaction across 
multiple resources.   When looking at potential message queue software, you need to see what 
external  transaction managers they support.   Roll­your­own logic is what you will find most 
shops using free or cheap message queuing systems doing.  This is inherently flawed and leads to 
significant problems.  When a message queue cannot be synchronized with database and legacy 
file updates, you end up with either lost messages, or partially committed transactions.  This is a 
problem when you have to face an audit.  It's a major PR problem when you have to explain to 
your biggest customer why you processed their order multiple times.

2.4

Shared Resources

We   have   mentioned   a   little   bit   about   shared   resources   in   a   cluster,   but   haven't   really 
discussed  it.    We  have   already   spoken  about  disk drives  (either  physical  or the  virtual  kind 
provided by a disk array) being mounted and shared across a cluster.   We have also discussed 
that user accounts and rights identifiers are common across the cluster.   Now we need to talk 
about the other resources.
A batch queue created on any given node in the cluster will make itself available to all nodes 
in the cluster.   A user anywhere in the cluster can submit a job to it, provided they have the 
correct rights identifiers or privileges to do that.  You can also create generic queues that simply 
hold and spool jobs for other batch queues.  This generic queue can be made to know about all of 
the batch queues on all of the nodes.  Each batch queue typically gets created with a limit of how 
many batch jobs it can run simultaneously.  The generic queue will dispatch to whatever actual 
batch queue is available at the time it receives a job.  
Although it may seem somewhat primitive, it is a form of dynamic load balancing.   Just 
because you are on one node and all of the available  batch queue  slots are consumed by long 
running jobs, doesn't mean your job has to wait for their completion.  With all of the resources 
available to all of the nodes, the job simply gets routed to a node with the capacity to run it.

Chapter 2 ­ Clustering

17

Generic batch queues tend to be served by select groups of actual batch queues.  This isn't 
due to any restriction of the cluster, it has to do with software licensing.   Some commercial 
packages get licensed in funky ways making it prohibitively expensive to license a product for 
all nodes in the cluster.   If you bought some form of commercial accounting system, but only 
licensed it to run on three nodes of a 20­node cluster, you may create a generic  batch queue 
called ACCOUNTING$BATCH that only distributes jobs to batch queues on those three nodes. 
The setup for the package, or the user login, would define this generic queue as the default batch 
queue for that application.
Print queues have similar features.  You can create both generic spooling and device specific 
print queues.  When you are on a node running in California and create a report for a department 
at your Germany location, you can simply print it to the queue being serviced by a printer in their 
area. The queue looks like it is a local queue to you.   Some shops will go so far as to set up 
symbols in each user's account for printing to the different print queues and assign the logical for 
their default print queue (SYS$PRINT) to be the printer closest to where they sit.
While   physically   separate   nodes   do   not   directly   share   memory,   it   is   possible   to   create 
regions of memory with common contents kept in sync via QIO calls and/or daemons.  It is also 
possible for users on one node to create processes that run on other nodes without them ever 
actually logging into those nodes.  Once again, the user must have the correct level of privilege 
and rights identifiers.
The largest sharing of resources occurs when you implement your SOA architecture using 
ACMS.   Each node may run an instance of your ACMS application.   As tasks are queued for 
servers   in   that   application,   ACMS   searches   and   finds   the   instance   of   the   application   with   a 
currently available server.  If no servers are currently available, but the application running on a 
given node hasn't reached its limit for that server (set by you or an operator) ACMS will start 
another instance of that server underneath the application and dispatch the task to it.  Likewise, 
after servers have been idle for a certain period of time (set by you or an operator) it will begin 
shutting down those servers, thus decreasing overall cluster usage and helping to maintain load 
balancing.  

18

Chapter 2 ­ Clustering

There is also a minimum “keep alive” server count which you control.   It is important to 
note that these servers will not stay alive forever.  After a server has been idle for the period of 
time which you set, ACMS will kill it off.  If the resulting server count is below the minimum 
“keep alive” value, it will start a new one.  While that may seem odd to many readers, it is an 
incredible feature.  It promises your application will not come to a screeching halt due to hung 
servers.  
If your server initialization code has an issue with tramp data or some other programming 
bug that causes it to go into sleep mode, it will only sleep as long as the idle server timeout 
period.  While it is true that this could mask a bug for you, ACMS errs on the side of application  
stability.   The last executable statement in each of your procedures (initialization, process and 
termination) should be to write a single text line to the server log file. When you see the message 
from the termination procedure in a log which doesn't have the message from the initialization 
procedure, you know you have a problem and need to take corrective action.

Chapter 3

What is Wrong Today
3.1

We Sold Modules

My   first  programming   job  was  at  a   DEC  (Digital  Equipment  Corporation)  VAR  (Value 
Added Re­seller).  There were a lot of them back then.  Every one of them seemed to have some 
“canned” package  they were selling along with the hardware.   Most of them focused on the 
basics of manufacturing:   Order Entry, Shipping, Inventory Management and Bill of Materials 
(BOM).   Every one of these packages came in a “customizable” form.   This means the “base” 
package was so stripped you couldn't do anything but operate the most generic of businesses.
Why were they sold this way?  Because the real money was in the modifications.  A staff of 
developers existed at each of the VARs to both work on the next version of the package and to 
provide time & materials modification services to the clients.  No customer bought the canned 
version of the package.  They all wanted it tweaked for their own business rules.  Few, if any, of 
the customers had their own programming staffs.  Every customer had their own unique set of 
business rules they wanted incorporated into the application.
The VARs sold their applications in “modules.”  You could buy as little or as much as you 
could afford.   Start with Order Entry.   When you decide you liked it, buy one or two more 
modules.  Eventually you ended up with the entire system.  Of course, there were some gotcha's. 
Part of the Inventory and Customer Management software had to be included with the Order 
Entry   modules.     They   simply   couldn't   work   without   it.     Eventually,   sales   would   talk   most 
customers into buying the holy trinity, Order Entry, Inventory and Customer Management.  The 
rules they needed would be implemented in those modules and only those modules.  When they 
came  back to get additional modules, they had to pay for another round of modifications to 
support the modifications already in place in what they bought the first time.   Once you got a 
customer to buy the holy trinity, it was a license to print money.

20

Chapter 3­ What is Wrong Today

Customized systems have a caveat that vendors don't talk about even today.  You are either 
locked into that version forever, or you pay for the same modifications over and over again with 
each new release of the product.   There is no middle ground.   Oh, yes, the billing rates being 
charged for modifications to the new version of the package are higher than they were for the old 
version as well.  This problem exists even with the big vendors today.  No matter how external 
you try to make the rules modules, you still end up having to open up their code to hook in the 
rules.   As soon as the code has been opened, you are looking at having to make those same 
modifications every time a new release comes out.
Some companies tried to ease this pain.   I know of some payroll systems that used ANSI 
COBOL with line numbers.  They would ship modification source merge files to the customer 
and make it the customers responsibility to ensure none of their modifications would be walked 
on by these new lines.  For small releases and fixes it worked.  With major releases, you didn't 
have a prayer.

3.2

We Are Still Selling Modules

The 1980s established a mind­set that applications should be sold by module.  That mind­set 
still exists today.  When you move to one of the big vendors, you buy a module at a time.  They 
would   like   to   sell   you   every   product   they   have,   but   you   simply   cannot   afford   it.     Some 
companies  have  sought to eliminate  the “locked  into a version”  problem  by modifying their 
business to fit the rules already built into the system they are buying.
I love watching technology commercials on TV, especially software commercials.  From the 
1970s to the early 1990s, the software you ran your company on was a strategic edge.  You may 
have sold the same products as your competitors, but you did business differently, that was why 
customers came to you instead of them.  Then the marketing arms...err...I mean the independent 
analysts, got paid to promote the concepts of “software  as an expense” and “using the same 
software as everybody else.”   The lemmings snapped into line.   They started axing all of the 
programmers they had which understood the business rules, buying canned packages from the 
major vendors (as dictated by the independent analysts), and modifying their business to use only 
the rules already coded into the package so they could upgrade.  Now you sell the same products 
as your competitors and use the same software to run your business in the exact same way. 
Hello price war, goodbye stock options.  Recently, I've seen some commercials on TV saying, “if 
you're just like everyone else, why do business with you?”  I guess the fallout nobody thought 

Chapter 3­ What is Wrong Today

21

about when resurrecting a 1970s business model is that 1970s business mentality would come 
back with it.
In the 1970s, companies leased time on computer systems because they couldn't afford their 
own.     They   paid   to   have   customized   applications   installed   on   those   systems   so   they   could 
continue   to   run   their   businesses   the   way   they   always   had,   just   more   efficiently.     In   2007, 
marketing   types   are   trying   to   get   customers   to   lease   time   on   computer   systems   owned   by 
someone else, but still use the same canned generic business packages everyone else is using. 
Does anyone else see the problem here?

3.3

The End of Modules

If the industry really  is going to embrace  Service  Oriented Architecture  (SOA) then the 
module mentality has to die.  You can still use modular development and stepwise refinement, 
but the concept of an application module has to die.  This is going to be a hard sell, especially to 
the current  leaders  in the SOA field.   They are trying to sell modules as a service.    This is 
destined to fail.
Some of you reading this might not be familiar with what I mean when I say module.  I'm 
talking about an application module.  Let me try to break it down for you with an example.  
Consider a Customer Management module for your typical manufacturing company.  There 
will be many components of this module.  The bulk of these components will be accessed via the 
Customer   Maintenance   screen   or   menu.     The   main   or   driving   screen   will   allow   you   to 
lookup/enter/modify all of the information for a main customer account.  Additional screens will 
allow you to setup secondary locations or alternate shipping addresses for this master account. 
The accounting people will have their own screens where they adjust the customers credit and 
status.   Higher­end systems will also have a history table showing total dollars for the master 
account and break it down into total dollars for each alternate address or secondary location. 
There will also be a mailing piece using this information to inform the customer of various price 
cuts and company news.  This same piece will be used by accounting to send ever increasingly 
nasty messages to customers who are past due.

22

Chapter 3­ What is Wrong Today

All of the above would be a Customer Management module.   There would be additional 
pieces   for   businesses   which   offering   rolling   accumulated   pricing   discounts   to   customers. 
(Rolling accumulated pricing discounts would be an additional percentage off for total sales.  i.e. 
$8 million in total sales gets you an additional 5%, $10 million an additional 8%, etc.)
The module mentality has worked for 30 some years in this industry, but it won't work in 
SOA when your services are hosted by multiple vendors at multiple locations.  This is the dirty 
little secret behind the sales pitch for SOA.   Once your data is on their system, it's not yours 
anymore.  You have to buy what they sell from that point on, and pay the price they ask.  You no 
longer have computers capable of hosting all this stuff.  Even if you did you couldn't afford the 
licensing.

3.4

How Do We Fix This?

When SOA is done in­house, it represents what the programmers were telling management 
they needed all along.  Management has been unwilling to bear the cost of it in the past, so I'm 
doubtful they will bear the cost of it now.   If they are willing to bite the bullet, it could be as 
industry changing as the invention of the semiconductor chip.
To start with, the pieces in your existing modules aren't small enough.   They need to be 
much smaller than you would imagine.  Every “feature” in that customer maintenance screen has 
to be broken out into its own service that will accept a message and issue a response.  You have 
to standardize what those messages are and publish their format to all who will use them.
Let's look at the basic functionality.  The very first screen for new customer entry usually 
accepts the customer name, contact info, address, etc., prior to writing it to the database.  It also 
does something which goes unnoticed.   It assigns a unique customer number to that customer. 
You should  split  this into two services.    The first  will accept  a request  for a new  customer 
number and return it.   The second will send a message with all of the new customer data.   It 
won't send it to an “add customer”  service,  it will send it to the “update  customer”  service. 
Why?  Because the services assigning the unique customer number will have to create the record 
in   your   database,   unless   you   create   a   separate   table   which   contains   only   unique   customer 
numbers.   The current “module” is most likely locking the customer number it has during the 
entry   process,   or   waiting   to   request   it   at   the   time   of   record   creation.     If   you   take   the   last 
approach,   you   can   have   an   “add   customer”   service,   but   it   must   be   capable   of   returning   the 

Chapter 3­ What is Wrong Today

23

customer number back in its response, or an error message if there was a problem with the add.
The   “update   customer”   service   gets   a   little   trickier.     In   a   traditional   environment,   the 
modifying application reads the record and locks it while the user is making modifications.  The 
application generally has some form of built­in idle time out to kill off the lock if the user has not 
entered  anything for a while.   This exists to prevent deadlocks in your database.    The SOA 
version cannot operate in this manner.   When a user wants to update a customer record from 
some Web screen, they have to send a request to the “customer inquiry” service to obtain the 
record, then send a message to the “update customer” service for the updates to be written.  The 
message to “update customer” has to contain before and after images of the customer record.
Why does the “update customer” service have to get both copies of the record you ask? 
Because it has to have brains.  The record was not locked while it was being modified.  Another 
user could have used the service to modify it.  The “update customer” module has to perform a 
field by field comparison of the before image with what is currently on the database to determine 
if there were any changes.  Most shops will attempt to be lazy at this point.  They will simply 
return an error and tell the user to retrieve again.  The smart shops will apply the changed fields 
if their before image matches the database current value.  
There are some schools of thought which say you should only send the before and after 
images of the changed fields to reduce network traffic.  These schools of thought also tell you to 
use XML for the transfer.  If you really are worried about network traffic, you don't use XML, 
you transfer binary data as it is the most compact and secure.   Binary data is certainly not in 
vogue, until you talk to people who have to do encrypted transmissions.
You use XML when you need  the widest possibility of acceptance.    Know this:   Every 
service will have to parse and generate XML if you plan to go this route. You cannot have some 
of the external services use it and some not when they are all part of the same business concept. 
If the “update customer” service is going to send and receive XML, then the “customer inquiry” 
and “customer add” service also must use it.  They are all services related to the same business 
concept.  Generating and parsing XML is a processing overhead.  While there are free libraries 
such as Xerces, their CPU and memory usage is not free.  

24

Chapter 3­ What is Wrong Today

We are now seeing what some refer to as a “middle ground” between secure encryption and 
the XML users.  The data contained between the XML tags is encrypted in a textual format.  The 
vendors of XML tools are trying to keep their products relevant in the world of identity theft. 
When I see a file transmitted in this manner I am always reminded about the definition of an 
elephant.  An elephant is a mouse designed to government specifications.
When moving to an in­house SOA, you must make a decision about how many interfaces 
you wish to allow.   Is the bulk of your SOA going to be for in­house use only over a secured  
network?  If the answer is yes, you don't need XML.  The token few services which the outside 
world could access can use XML, but send it through some form of general server that is both on 
the secured network and capable of bidirectional XML.  The part of it that communicates with 
the actual services you have hosted will be communicating using binary records or messages. 
This is by far the best implementation because you can ensure no Web page has direct access to 
your customer database.   SQL injection techniques simply don't work when the message being 
sent is going to be parsed into a binary or fixed­width record that gets passed on.  That server in 
the middle will need some form of maintenance every time you add information to the outside 
world, but if written correctly, it can ignore any new fields you don't allow the outside world to 
see.

3.5

Today's SOA Camps

Currently there are two competing camps championing their vision of the Service Oriented 
Architecture.  The first camp is run primarily by the large package vendors.  Their vision of SOA 
is a return to the 1970s computing model.  You pay only for the pieces you use, but you use it on 
their machines.  This means your only choice is what they sell, and they kind of like that model.
Our second camp is run primarily by the software vendors.  Yes, they are promoting open­
source tools like Java, Ruby and Web 2.0.   They are also pushing very expensive commercial 
middleware with ever escalating support contracts.  If they can no longer sell you the compiler, 
they are going to sell you something you can't live without.  Their view of the Service Oriented 
Architecture is that you write thousands of little Web apps with the tools they vend to directly 
access your databases from the Web.   Yes, they think it is a great thing.   Nothing better than 
being able to access your customer's private data from anywhere on the Web.  All of these little 
servers will be scattered around the world and you will hook them together on a pay­per­use 
basis.   They will each do one little thing and return you the result.   Forget about that Internet 

Chapter 3­ What is Wrong Today

25

being free stuff.   Web 2.0 will be a completely commercial pay­per­use environment in their 
mind.
Both of these approaches will have billions flushed down the toilet after them.  Both of these 
approaches will ruin lives.  Neither of these approaches will create a successful Service Oriented 
Architecture for your company.   We've already discussed the module by module approach, so 
let's take a look at the second approach.
PC and UNIX vendors can't get enough of doing what has been done before,  putting a new 
name on it or providing some other form of marketing spin.   They have consistently repeated 
development   blunders   that   occurred   during   the   evolution   of   the   mainframe   and   midrange 
computing market.  
Mainframes were data islands, they didn't network, then midrange computers came out and 
were able to cluster, so mainframes got better at networking.   Initially PC's were data islands. 
They didn't network.   Then people started developing file servers so people wouldn't have to 
hand walk floppies around, and they started networking.
Initially,   mainframes   and   midranges   didn't   have   databases.     When   data   requirements 
exceeded the capabilities of what they had, they got hierarchical databases.  When the limits of 
those were encountered, they got relational databases.  Some companies now even have object­
oriented databases.  Initially, PC's did not have any form of records management system.  It was 
a roll your own situation.   Then they got some stand­alone products like the various XBASE 
products.  Next they got a good server­based product, Btrieve.  For the most part they seem to 
have   skipped   hierarchical   databases   and   went   straight   to   either   relational   or   object­oriented 
databases now.
Initially midrange and mainframe computers didn't have any quick method of tossing up a 
data   entry   screen   or   writing   a   report.     You   had   to   code   it   all   by   hand   in   either   a   3GL   or 
Assembler.  Next they got some report writers and screen generators.  Then they got Common 
Data Dictionaries and 4GL tools.   PC's initially didn't have anything useful along these lines 
either.  Then they came out with a bunch of development tool sets (not really 3GL and not really 
4GL) and code generators that would access  the database to generate  data entry screens and 
reports.  They kind of skipped the Common Data Dictionary thing because there was little in the 
way   of   organized   code   control   or   multi­tool   development   like   midrange   and   mainframe 
computers.

26

Chapter 3­ What is Wrong Today

When  DOS finally gave  way to a  GUI version of  itself,  then a  re­engineered  GUI, this 
development tool set concept got recycled all over again.  Report generators, screen generators, 
you   name   it,   all   directly   connected   to   your   databases   across   the   company   network.     Your 
programs  could   now  integrate   with  spreadsheets  and   a  host  of  other  things  they   couldn't  do 
before.
Enter the World Wide Web.   After a period of time giving it away  for free,  it is being 
redeveloped as Web 2.0, the commercial version.  Make no mistake, while some parts of the new 
Web   will   remain   free,   this  is   quickly   becoming   a   pay­per­use   business  model.     Guess   what 
concept is being recycled?  You betcha!  A whole bunch of tool sets and languages that will let 
you   directly   (via   commercial  middleware)   connect   to   your   database   from   any   Web   page 
anywhere in the world.   All of your information and your customer's information exposed to 
whomever tries an SQL injection or other hacking technique first.
What is different between then and now is the network and the risk.  Back around the time 
frame of DR DOS 6.0 and Windows 3.1, networks didn't have a lot of external exposure.  True, 
some companies put password protected modems on the network to allow full access, but most 
companies communicated over leased lines from location to location.  The development tool sets 
were used in­house by people who already had access to the data.
Don't forget, hackers are also pushing for the Service­Oriented Architecture.  They want the 
very same data you are obligated to protect, passed around the Web to utilize service components 
which will be out there.  If you take this to the logical end, it means that your customer credit 
application screen would have an entry for Social Security Number and a button for “Check 
Credit Score.”  The SSN would be put into an XML message and passed to a server returning the 
customer's credit score.  One of three situations would have to occur;
1) your account and password would have to be stored on the machine to be included in 
the message.
2) The user at the terminal would have to have this information and enter it every time, 
even though you make use of dozens of these different services on that same screen.
3) The raw SSN with all identifying information would have to be passed to the service 
across an insecure Internet connection.
Any way you slice it, things sure don't look good for data security.

Chapter 3­ What is Wrong Today

27

Opponents of what I say here will try to tell you I'm painting a worst­case picture for you 
and it really won't be that bad.  Well, as an IT professional I have to always look at the worst­
case scenario and defend against it.
The argument always offered up is you will link in things like a Google search to your page 
or some other free service which has no security risk.  While services like that are both useful 
and familiar in this day and age, they don't completely fulfill the Service­Oriented Architecture 
mantra.
Companies   headed   down   the   path   of   developing   a   Service   Oriented   Architecture   must 
develop with a single mind­set.  All of the services they develop must be optically isolated from 
the Internet.  Any service available to the outside world must go through a middle server which 
reformats messages between internal and external use.  Never directly connect a Web page to a 
database that has any data that isn't for public consumption anywhere inside it.  Eventually, the 
tool that made it so easy for you to toss up that page will have a design flaw or a programming 
bug exploited that will give an outside hacker complete access to the database.  Most of you will 
have read about SQL injection techniques; they are pretty commonplace.  There are also buffer 
overruns and a host of other problems that will continue to surface in each new trendy tool and 
be exploited by hackers.  Because you cannot eliminate this problem, you must design it out of 
your Service­Oriented Architecture plans.
XML seems to be the standard (for now) of how the external world wishes to communicate. 
That's fine.  Use XML for the messages coming into and going out of that server which optically 
isolates your SOA components from the Internet.  Use a completely different message format for 
your SOA  components.   Put all of your XML parsing  out on that optically isolating server. 
Make it create internal consumption messages, and translate the internal consumption messages 
it receives back to XML for transmission to the Internet user.  Whatever techniques the hackers 
try to use in doctoring up those messages will be thwarted by the conversion process.  Either the 
parser   will   gag   on   it,   or   the   internal   consumption   message   will   be   garbage   and   your   SOA 
component will reject it.  Either way, you've stopped putting your sensitive data at risk.

28

Chapter 3­ What is Wrong Today

Moving to SOA is a big bullet to bite.  You have to overcome not only 30+ years of module 
mentality, but of module growth.  As new features and functions were needed, it was far simpler 
to add a few lines of code to an existing program which already had all of the necessary files 
open.  Programs that started out as less than 2,000 lines are now over 30,000 lines and growing. 
They've been in place so long, nobody really knows everything they do anymore.  The business 
rules that have run your company for decades are primarily forgotten, yet they live on in the 
code.

3.6

Start Small

Please allow me to emphasize one point again, start small.   There is no point in trying to 
stuff a complete module into a service.   There  is also no point in trying to stuff a complete 
program from that logical module into a service.  It will only end in disaster after you've sunk a 
lot of time and resources into it.
Remember my tiny example with the customer file maintenance screen?   Break each IO 
operation up into its own service as I instructed.   Once those are done, create some form of 
screen to use them from your internal network.  Expand out, taking each function the Customer 
Management system did and break it down into its smallest logical components.  Make each of 
those components a service.   Establish an interface for them.   Hook them up to some form of 
screen.   Do this in parallel with the existing system until you have it functioning the way you 
want, then turn off the old interface and train users in the new interface.
Choose another module and do the same thing.  Be sure to document what each service is in 
your  architecture   and   what   its  interface   messages   are.     Eventually,   you   will   find  the   people 
creating the screens start to add new functionality to the screens because the services are there, 
they just needed to be hooked together.
How would that happen you ask?  It depends on the order of migration you choose.  If you 
start with Customer Management, then move to order entry and inquiry, then to several other 
systems,   by   the   time   you   get   to   inventory,   you   will   probably   be   able   to   give   the   inventory 
managers something they've always wanted:  The ability to “see” what customers are buying an 
item.  You will probably have already developed a service for the order inquiry system that will 
let customer service find an order with a specific item on it.  If the service is designed correctly, 
it will find the order numbers for any customer if the customer number isn't specified.  This will 

Chapter 3­ What is Wrong Today

29

give the inventory manager the order numbers they need and their screen might now have an 
order inquiry option on it. 
Once you have all of the low level services in place, hooking them together becomes the 
choice of the screen designer.  You will need to implement policies which restricting access to 
some information.  The inventory manager has a valid reason for wanting to see what customers 
are buying a slow­moving item.  If it is walk­in only customers who do little business, they may 
wish to make the item a special order item.  If the customer is someone they know does a lot of 
business with your firm, they will opt to keep the item in stock to retain the customer's business. 
Previously,   the   type   of   inquiry   they   needed   to   do   was   coded   directly   into   the   Customer 
Management system, which they didn't have access to.  Now, the pieces of it that are needed for 
them to do their job properly can be parceled out.
From what I read and hear, most companies try jumping into SOA with both feet.   The 
industry marketing...errr...analysts tell them it is the next big thing so they throw their resources 
behind it.   They issue a mandate that all of their systems must employ the SOA model by a 
certain date, then sit back and update their resume.  It's a good thing they keep that resume up to 
date, because they just ordered their people to walk off a cliff.

Chapter 4

Green Screens on the Web
4.1

Obtaining a Web Server

You   have   a   lot   of   options   when   it   comes   to   obtaining   and   running   a   Web   server   for 
OpenVMS.   To implement this little trick, you need to actually run the Web server on your 
OpenVMS box.  I opted to download the WASD product.  Why?  Because WASD didn't require 
me to fill out a bunch of registration information.   WASD comes to you in source form with a 
build procedure  and installation procedure.    You get a Web server compiled directly for the 
installed libraries on your machine.
The best place to start looking for your Web server software is www.openvms.org.  This is a 
great site for the OpenVMS community.  On the left­hand side of the main page, you will find a 
Navigation menu item worded something like “Open Source & Freeware.”  Click that link and 
look around on the resulting page for your Web server options.
Once you have the file unzipped, follow the instructions to launch the build and installation. 
DO NOT SKIP ANY STEPS, even if they say they are optional.   During my first pass at the 
installation I skipped the “optional” security step.  Because the Web server didn't own any of the 
files in its directory tree, it wouldn't start, but the test one launched during the install would work 
because that ran under my user id.  Yes, tracking that down was a fun half hour.  Good thing I 
keep a massive scroll back buffer.
The installation will create an HT_ROOT directory tree on the disk drive you tell it to use. 
You then need to create a rooted logical named HT_ROOT so things will run correctly.
$ define/system/exec/trans=(conceal,terminal) ht_root dqa0:[ht_root.]
$ show log ht_root
"HT_ROOT" = "DQA0:[HT_ROOT.]" (LNM$SYSTEM_TABLE)

After that, you are ready to launch your Web server.
$ @ht_root:[startup]startup

32
4.2

Chapter 4­ Green Screens on the Web
Obtaining a Web Terminal

Java Applets have a lot of security rules.  To open a socket, an Applet must only open that 
socket back to either the DocumentBase or CodeBase of the Web server the Applet was loaded 
from.  Unless you have the site set up as a trusted site or the JAR correctly signed, it will not be 
able to open local files or do much else on the system running the Web browser.
Thankfully, someone dealt with these issues for you.   You can visit  http://javassh.org  and 
download a Java based VT320 emulator.  To use it, you need to copy the JAR file to a directory 
accessible by your Web server, then create an HTML page to serve it up.  I put mine in the root, 
but you probably want to put yours in different directories so you can have a local  applet.conf 
file for each application you run.
Terminalapplet.html
<html>
<body>
<applet CODEBASE="http://192.168.2.8"
ARCHIVE="jta26.jar"
CODE="de.mud.jta.Applet"
WIDTH=960 HEIGHT=560>
<param name="config" value="applet.conf">
</applet>
</body>
</html>

If you are like me, you will stumble around pretty bad until you finally find the page on the 
Web site with a good default.conf to create your applet.conf from.  Here is what mine looks like.

Chapter 4­ Green Screens on the Web

33

Applet.conf
#
#
#
#
#
#

-- IMPORTANT NOTICE -Copy this file when creating your own configuration and name it different.
default.conf is used by the software for initial setup. Your own config
may not need all the fields found in this file but only those you want
to change.
-- IMPORTANT NOTICE --

# =======================================================================
# common program defaults
# =======================================================================
plugins
=
Status,Socket,Telnet,Terminal
pluginPath
=
de.mud.jta.plugin
layout
=
BorderLayout
layout.Terminal
=
Center
layout.Status
=
South
layout.MudConnector
=
North
# help url/filename
Help.url
= /index.html
# =======================================================================
# Applet defaults
# =======================================================================
Applet.detach
=
false
Applet.detach.fullscreen
=
false
Applet.detach.immediately
=
false
Applet.detach.menuBar
=
true
Applet.detach.startText
=
Connect
Applet.detach.stopText
=
Disonnect
Applet.detach.title
=
Logikal Solutions Alpha
Applet.disconnect
=
true
Applet.disconnect.closeWindow
=
true
# to make Netscape behave good we would like to have some privileges
Applet.Netscape.privilege
UniversalConnect,UniversalPrintJobAccess,UniversalSystemClipboardAccess
# =======================================================================
# Socket defaults
# =======================================================================
# This is set to the webserver by default.
Socket.host
= 192.168.2.8
Socket.port
= 23
# for SSH use the port below
#Socket.port
=
22
# =======================================================================
# Timeout settings
# =======================================================================
Timeout.seconds
=
60
Timeout.command
=
exitn
# =======================================================================
# Terminal defaults
# =======================================================================
Terminal.foreground
=
#ffff00
Terminal.background
=
#000000
Terminal.cursor.foreground
=
#000000
Terminal.cursor.background
=
#ffffff
Terminal.print.color
=
true
Terminal.border
=
2
Terminal.borderRaised
=
false
# if you use your own file use a fully qualified URL!
Terminal.colorSet
=
/de/mud/terminal/colorSet.conf
Terminal.scrollBar
=
West
# now the real terminal configuration
Terminal.id
=
vt320

=

34

Chapter 4­ Green Screens on the Web

Terminal.buffer
=
5000
Terminal.size
=
[132,34]
Terminal.resize
=
font
Terminal.font
=
Monospaced
Terminal.fontStyle
=
plain
Terminal.fontSize
=
12
# if you use your own file use a fully qualified URL!
Terminal.keyCodes
=
at386.keycodes
# /de/mud/terminal/keyCodes.conf
Terminal.VMS
=
true
Terminal.IBM
=
false
# the setting below should be correct, but it does not work
#Terminal.encoding
=
ISO8859_1
# the setting used it probably incorrect but forces the default behaviour
Terminal.encoding
=
latin1
#Terminal.beep
=
http://www.mud.de/se/jta/BOUNCE.WAV
# =======================================================================
# MudConnect defaults
# =======================================================================
MudConnector.listURL
=
http://www.mudconnector.com/java/Telnet/javalist.db
# =======================================================================
# MudConnect defaults
# =======================================================================
Capture.url
= Configure this URL!

This terminal has a ways to go.  It does seem to handle the VT320 escape sequences pretty 
well,   but   it   has   no   support   for   the   numeric   keypad.     Most   of   the   keys   are   controlled   by   a 
keycodes file.  You may notice that the file is specified in the applet.conf file.  I highlighted the 
line above.  On my dual core 64­bit AMD machine running Ubuntu Linux “Gutsy” distribution, 
it seems to give adequate typing performance.  Some of the keys aren't currently opened up for 
redefinition.  It is most infuriating that the NumLock key hasn't been opened up because this is 
the   key   most   of   us   define   to   be   the   GOLD   key.     The   full­source   code   is   available   on   the 
download page, so, anyone could add the support for this and return the code to the authors.

Chapter 4­ Green Screens on the Web

35

The above image shows the terminal.  Yes, the scaling down made the text quite hard to read 
in this book.  It is pretty readable on my terminal.  You do have to get used to clicking on the  
terminal before logging in since the applet doesn't get focus upon load.

4.3

Is This SOA?

The short answer is no.  It is a way for you to avoid paying large fees for terminal emulation 
programs and a way for you to let employees log in remotely from anywhere.  As I stated, the 
emulator needs some work.
The long answer is that most managers believe anything that can be accessed from a Web 
page  is SOA.   Because  most of them are pretty clueless  when it comes to technology, only 
hearing buzzwords, you must let your own ethical threshold guide you.

Chapter 5

ACMS Fundamentals
5.1

Why Are You Only Hearing About ACMS Now?

This is probably a very valid question.   ACMS appeared in the 1980s.   It was a “Best in 
Class” software product.  There were several major strikes against it though.  First and foremost, 
it had the world's worst marketing campaign.  This was a horrible time in the industry.  DEC had 
let MBAs get into the company and MBAs thought they could manage anything.  Naturally, they 
wanted   to   manage   the   sales   and   marketing   since   that   meant   traveling   to   parties   and   having 
expense accounts.  They didn't actually know anything about what they were marketing, but that 
didn't stop them from trying to manage it.
The software engineers had managed to keep the MBAs out of the software and product 
development process.   They didn't manage to keep them out of the packaging side of things, 
Hence the disasters which happened in the PC market for DEC.  The dutiful software engineers 
were busily looking 30 years into the future and planning for what the industry would need. 
They saw the ultimate use of their distributed cluster as being distributed fault tolerant tasks. 
They created ACMS.
MBAs couldn't even understand the cluster, so they had completely passed out by the time 
the engineers finished spelling out what ACMS meant.   Engineering went through a lengthy 
presentation on the features and benefits.   Finally, at the end, one of the engineers shook an 
MBA to wake them up.   As they groggily came to, they heard the phrase “It's our answer to 
CICS.”   That one phrase,  became the entirety of the marketing campaign, which, if memory 
serves me, lasted about three weeks.  Once again, it was up to the engineers and documentation 
to push a product.
You see, CICS had both batch and interactive transaction control, but almost nobody knew 
about the back­end controls.  Everybody on the blue boxes seemed to be using CICS for screen 
interaction and leaving the back­end alone.   The beauty of ACMS was its capabilities on the 
back­end.  The complete tool for a service­oriented architecture.  

38

Chapter 5 ­ ACMS Fundamentals

When people started buying the VAXStations of the day, they found the boxes to be both 
pricey and extremely underpowered.  Loading them up as full­time cluster members to use them 
as intelligent terminals much like the IBM 3780 was for CICS, really bogged these boxes down. 
They were originally designed for developers to write and test code before moving it up to the 
development   cluster.     They   were   also   designed   for   the   document   processing   market. 
VAXStations came with 20­inch monitors long before most other computers had them.  At the 
time, the extreme end of the PC market was using 17­inch monitors.   Some people (not me) 
actually liked WPS for document writing and creation.  Letting these users share documents on a 
cluster, but work locally was a major benefit.  It also dramatically reduced licensing fees.
You see, the problem was in that last phrase the MBAs heard.  Since they used it for their 
marketing campaign, customers tried to use the product like  CICS.   The hardware  DEC had 
available for the desktop at the time couldn't be a full cluster member and give adequate response 
time to users.   These boxes came with 1Gig hard drives that had a 17 or 21ms seek time if 
memory serves me correct.  Large for their day, but very slow.  Paging memory in and out was 
extremely time consuming and it degraded response time.  Memory for these boxes was (and still 
is) quite pricey so most buyers skimped on RAM and got the bigger disk.
Had   the   MBAs   never   heard   that   phrase,   we   would   have   been   doing   Service­Oriented 
Architecture back in the late 1980s.  Indeed, some companies did set up services this way back 
then.  They are still using ACMS today.
Oddly enough, IBM is now making a massive marketing push for the back­end services 
CICS  can provide.   It is becoming a cornerstone of their SOA offerings.   If you can live with 
knowing your moat and fortress can be taken out by any number of natural disasters or terrorist 
acts, it is definitely the best tool on that platform.  HP doesn't seem to be making the same push 
with ACMS.  They have had TP Web Connector and TP Desktop Connector for quite some time. 
The   major   drawbacks   for   both   of   these   products   is   they   currently   only   support   Microsoft 
operating systems.  Because the TP Desktop Connector now has its license included with ACMS, 
it would be sweet beyond description if they added support for 64­bit Ubuntu  Linux  on AMD 
boxes.

Chapter 5 ­ ACMS Fundamentals
5.2

39

Flow Description

ACMS was designed to use as little or as much of the entire cluster as you choose to give it. 
When operating in the CICS style using DECForms, one or more light­weight nodes can handle 
the forms processing while one or more seriously equipped back­end nodes handle the bulk of 
the transactional processing.  The theory at the time was that customers would buy several less 
expensive VAXStation machines to handle all of the forms and buy the higher horsepower VAX 
models for the back­end.  What eventually happened is we all learned the VAXStations were too 
underpowered for the amount of users businesses wished to run.
From an architectural standpoint this was a grand design.   It just took a long time for the 
hardware to catch up with it.   In today's world you think nothing of using your desktop PC to 
enter data on a Web form, then submit it off for back­end processing.  It was a hard sell in the 
'80s.
While the real­time aspects of ACMS were a technical marvel, the completely overlooked 
queueing   capabilities   were   jaw   dropping.     Terminal   IO   (real   time)   requests   were   normally 
handled with the RI (Requestor Interface) library calls.  If you did not wish to use DECForms, 
you could use the SI (Submitter Interface) to create a real­time interface.  You could also use the 
queueing facility to submit tasks for later processing.
The queueing interface could give you real­time response, depending on system load.  Either 
your task or the message had to contain information about where to send the real­time response. 
Normally, when I'm doing this kind of development I use MQ Series for the external messaging 
so   the   entire   system   has   end­to­end   guaranteed   delivery.     The   real   beauty   of   the   queueing 
interface is that the ACMS application itself doesn't have to be available.  As long as the entity 
which queued the task can handle delayed response in some manner, you are golden.
Many who are taking the initial steps towards SOA only wish to look at real­time solutions. 
They have completely forgotten about the vast quantity of activities that are a delayed process by 
their very nature.   Too many purchase real­time only solutions, then find themselves trying to 
make everything fit into the real­time methodology.

40

Chapter 5 ­ ACMS Fundamentals

Think for a minute about how you place an order online.   You pick and choose items for 
your shopping cart.   At some point you choose to check out.   At the point of check out, the 
shipping charges and tax are calculated, a payment method is chosen and verified, then the order 
is submitted.  
Up until we get to the submitted stage, you need real­time solutions.  The SI interface can 
give that to you.  The submission portion is by its nature, a delayed response task.  At some point 
a picking ticket will be generated for the warehouse(s).  The product(s) will eventually be picked 
and   packed.     Once   they   enter   the   packed   stage,   a   shipping   label   and   notification   will   be 
generated.  Most companies send the shipping notification via e­mail today.  E­mail is a delayed­
response communication.   The picking and packing are  delayed­response activities.   Because 
everything   that will occur  after  the  submitting is  a  delayed­response   activity, you  should be 
queuing the task for order submission, not handling it in real­time.
The   distributed   nature   of   ACMS   and   its   process   flow   makes   it   ideal   for   SOA 
implementation.   Both the SI library and the task queueing capability give you all of the tools 
you need to process information from your Web interface.

5.3

General Principals
ACMS works on the ACID principle:  Atomic, Consistent, Isolated, Durable.  

For a transaction to be atomic, it must be structured in such a way to provide an all­or­none 
completion.  If a transaction fails, no part of it can be left around.  This is why ACMS integrates 
with DECdtm.  Any indexed file you are going to update or modify needs to be an have  RMS 
journaling enabled so DECdtm can work its COMMIT and ROLLBACK magic.
Consistency is provided by the application developer.  It means your transaction consistently 
applies the same additions or updates in the same manner every time.  If you have a bug in your 
program where you periodically skip updating some fields in a database or indexed file record, 
then your transaction is inconsistent.

Chapter 5 ­ ACMS Fundamentals

41

Isolation is a unique concept.  Not so much unique as it is difficult for a lot of module­based 
developers to understand.   It is not uncommon for there to be jobs in a customer management 
system that perform a bulk update of telephone area codes.   During the late 1980s and early 
1990s telephone companies went on a spree of creating new area codes.   In part it was due to 
population growth, and the other part was that they didn't initially allocate area codes for cell 
phones and pagers.   Nobody knew how successful the new technology was going to be.   You 
would not make this type of job part of your SOA.  It is still the type of job which must be run in 
batch   during   a   maintenance   window.     Earlier   I   gave   you   an   example   using   just   the 
entry/maintenance portion of the customer management system.  Splitting the IO operations so 
that each  was an  independent  IO  process.    This is how you obtain isolation.   It ensures  the 
transactions can run however the task manager dispatches them.
Durability  sounds really good, but means nothing more than the changes to your database 
are permanent upon completion of the transaction.  You aren't going to successfully complete the 
transaction, then roll it back.  Ad hoc SQL updates don't fall into the durability class.  You are 
experimenting with those until you find the update you like.   Then and only then, would you 
issue a commit.
The   primary   concept   behind   ACMS   is   re­startable   units   of   work.     Each   transaction   is 
considered a unit of work.   Units of work are dispatched to tasks in servers that perform the 
work.  If a server dies, for any reason, the unit of work will be dispatched to another server once 
DECdtm  has   done   its   cleanup.     This   cycle   will   continue   until   the   unit   of   work   has   been 
dispatched as many times as you configured or it completes.  Assuming you have a malformed 
message or a bug in your server code, the unit of work will end up getting placed on an errors 
queue.  You must then have a means of either manually junking this message, or fixing it and re­
queuing it to the correct task queue.
No system can be fault tolerant or claim to offer clustered transactions without a distributed 
transaction   manager   built   into   the   operating   system   kernel.     This   transaction   manager   also 
provides durability when your machine is running as an independent system.  If you start a unit 
of work in ACMS, then suffer a catastrophic power failure, DECdtm automatically cleans things 
up when the operating system is started.   There is no manual sweep up.   When your ACMS 
application starts, the entries will still be on the queue for it to process.  I have found nothing else 
in  the  marketplace   that can   honestly make  this  claim.    The  third­party  transaction  managers 
require manual intervention, or simply lose the transaction which was being processed.

42

Chapter 5 ­ ACMS Fundamentals

Let us take a look again at the few customer management  transactions  we have already 
talked about.  We will assume you made the choice to have a separate “customer add” service. 
The new unique customer number will be generated either directly by your service, or logic built 
into your relational database.  Once the new customer number is generated, the new row is added 
to the table.   The result of the add and the customer number will be placed on the outbound 
message queue back to the program or screen that requested the service.
This task is isolated.   It may very well fail on the add if there  are  other constraints on 
columns in the row and the requester did not provide the correct data, but it is isolated from other 
transactions.  Even if two add operations attempt to start at the same time, the result will only be 
a slight delay.
How about the update transaction we talked about?  Your service requires both the before 
and after image.   If your programmer isn't lazy, they can perform an intelligent update.   This 
handles the case  of another user updating the credit limit or status while the current  user is 
changing the shipping address.   What you cannot have is a lazy programmer who just blindly 
updates the row.   They can only do this if the before  image matches the current row in the 
database.   Your existing application got around this problem by locking the row until it was 
done.  We do not wish to allow a Web or other outside operation, which may simply go away,  to 
have a lock on a record in our database.
To make these transactions secure, they must not consist of dynamically parsed/interpreted 
SQL statements.   Each SQL interaction must be pre­compiled and linked into the task.   There 
can   be   no   calls   to   any   “PREPARE”   function/method   which   dynamically   compiles   an   SQL 
statement based upon any user input.  This rule effectively stops all SQL injection techniques.

Chapter 5 ­ ACMS Fundamentals
5.4

43

IO Routines

Two decades ago, when I started out in IT, we were all instructed to use IO routines so the 
underlying storage method could change without impacting our application.   This was a great 
idea, but it had some flaws.
The   first   flaw   was   the   nature   of   the   languages   themselves.     Every   language   on   robust 
business platforms included direct access to the storage methods on that platform.  In the case of 
VMS (later named OpenVMS), this meant that every language had built in extensions for RMS 
indexed file access.  Writing IO library routines was a lot of work and didn't provide much in the 
way of immediate payback.
A second flaw was error handling.   I actually worked at a shop that used IO routines to 
encapsulate file access.  Every one of our major indexed files had an IO routine and an assigned 
channel number.   Every developer was required to use those routines.   In theory, we handled 
every conceivable error inside of those routines.  Sadly, only the common errors were actually 
tested.  We were working with DEC BASIC at the time.  Every routine returned the BASIC error 
code for those errors  for which BASIC had an error number.   What happened when BASIC 
didn't have a corresponding number for that error?   You betcha!   We returned the  RMS  error 
code and the application had to deal with it.
Why were we using IO routines in the first place?  Because the application was originally 
written for Singer computers.  Good luck finding information about them today.  The vendor of 
the application wanted to be able to jump to a new platform as easily as possible.   They just 
didn't look too close at what we returned when BASIC didn't have an error code.  Then, they got 
pressured by customers to come out with a Unix version of the product.  The Unix platform in 
question didn't have a BASIC compiler, or didn't have one with anywhere near the capabilities of 
the DEC BASIC dialect.   So, they used a commercial translator to convert from BASIC to C. 
That went well...NOT!
Of course, those of you who read “The Minimum You Need to Know to Be an OpenVMS 
Application Developer” know what came next.   Client companies wanted a relational database 
version.  IO routines are a nice idea.  Implemented correctly they can let you survive hardware 
architecture jumps.  They cannot let you survive storage architecture jumps.

44

Chapter 5 ­ ACMS Fundamentals

Indexed files of the day contained  multi­typed records.   This meant all of the records for 
something like an order were grouped together in one file.   It was fast, efficient and the way 
things were done on most business platforms.  Relational databases make you store each of the 
record types in a separate table.  The logic in your program was a complete do­over even if the 
IO routine could handle it.
Those of you who think we had it bad should talk to some from the IBM camp who went 
from ISAM to VSAM to a hierarchical database to finally land in a relational database.  Every 
change was a do­over.   Over the course of the past decade or so, vendors of object­oriented 
databases have been trying to get us to switch again.  Their products have merit, but we are tired 
of do­overs and not every language can directly support an object database.
One thing you will hear most database vendors hawking now is stored procedures.  While 
I'm certain some companies will jump in with both feet, that is a recipe for disaster.   You are 
locked   into   that   database   from   the   first   day   you   put   your  stored   procedure   into   production. 
Stored procedures tend to be very vendor specific with their method of invocation, development 
and result sets. Have you ever been on a project to port an application from one database to 
another?   I have.   IO routines might have actually saved us, but they weren't used.   The past 
history of getting burned by them has most companies avoiding them.   RDB is one of the few 
databases   with   external   SQL   Module   compilation.     This   was   done   so   the   database   or   the 
architecture could change out painlessly.  Naturally, most other database vendors don't provide 
this capability.

5.5

The Major Pieces

ACMS development must be done from the inside out.   When it originally came out, this 
was the most confusing trait about the development cycle.  Now that we are in the middle of the 
SOA wave, this is the common development methodology.  Everyone is setting up Web pages 
linking   to   a   bunch   of   services   that   already   exist   somewhere.     ACMS   has   the   same   design 
methodology.

Chapter 5 ­ ACMS Fundamentals
 Application            
    ADF
 
 
username
Logical Name Table Search List
CDD definitions
Other details
 Group     
          
   GDF
 
 
CDD definitions
3GL Initialization modules
3GL  Termination modules
Server Definitions
 Task       
   TDF
   
CDD defintions
3GL Procedure module
 Task       
   TDF
   
CDD defintions
3GL Procedure module
 Task       
   TDF
   
CDD defintions
3GL Procedure module

 Task       
   TDF
   
CDD defintions
3GL Procedure module

45

46

Chapter 5 ­ ACMS Fundamentals

The diagram on the preceding page is attempting to show you that an ACMS application 
consists  of  a   group  of   servers.    Each  server   must  have  one  initialization  procedure  and   one 
termination   procedure.     A   server   may   have   many   task   procedures   (or   as   I   call   them   later 
Procedure procedures).   For your own sanity and the sanity of any developer following you, I 
humbly suggest you don't put more than one task in any given server.   Before you can begin 
developing   the   ACMS   portion   of   your   application,   you   must   choose   a   3GL   programming 
language   and   code   each   Init,   Term   and   procedure   for   each   server   so   each   compiles   into   a 
separate object file.  No, you cannot use Java or some other interpreted language.
If the server you are assigned to create were to be called foo_serv, then you would need to 
create   FOO_INIT_PROC.OBJ,   FOO_TERM_PROC.OBJ,   and   FOO_PROC.OBJ.     I   put   the 
_PROC wart in my file names when developing ACMS so I don't accidentally blast an OBJ file 
during compilation by having a name collision with one of the ACMS source files.  The reason I 
do it now is because at one time I didn't, then I had some real fun trying to track down a problem. 
It linked just fine, but the server kept deploying itself rather than executing the procedure it was 
supposed to execute.  At least until the username the server was running under ran out of quota, 
then it died a horrible death.
Each server initialization procedure needs to do the following:
Create a uniquely named log file


Attach to the queue manager for any messaging system (like MQ Series)

Map onto any global sections you are using
Initialize any global data that could be used by the application 


Connect to any databases that will be needed
Return an accurate completion code to ACMS

Each server termination procedure has the following responsibilities:
Close any message queues that might still be open

Disconnect from any queue manager the initialization procedure connected

Disconnect from all databases
Free all mapped global sections


Close log file

Return an accurate completion code to ACMS

Chapter 5 ­ ACMS Fundamentals

47

The   responsibilities   listed   for   the   initialization   and   termination   procedures   need   to   be 
performed in exactly the order they are listed.  The list of responsibilities should make it pretty 
apparent why I try to keep each server to one task.  If your actual procedure is simply processing 
a raw data packet it gets via some TCP/IP service on a port, then you could put as many tasks as 
you want in a server.    If you are using some form of message queuing for reliable message 
delivery, then you really want to restrict how many tasks you bundle into a server.
The first ACMS source file you need to concern yourself with has the extension TDF.  This 
is the Task Definition File.  Each task is meant to encompass a single restartable unit of work.  It 
defines the workspace (if any) that is used by the task, the task itself and the actions to perform 
depending on how it completes.  There is no logic here.  While there is a particular syntax (which 
we will go into later), this is not “yet another programming language.”   The procedure(s) you 
define here are all the names of object modules you have written and compiled in your 3GL of 
choice.   As each task gets compiled, it puts information into  CDD  (Common Data Dictionary 
now owned by Oracle Corporation).  That information is used by the GDF when it compiles.
A task should not establish any database connections.  All of those connections need to be 
handled by the initialization procedure.   Feel free to write any log messages or create any log 
files you wish in a task, but do not establish new connections.   A task is concerned with an 
update, a read, a write or a delete.  The grey area here is when you have RMS indexed files used 
for reference.  You should open them in the initialization procedure, but you could make a case 
for opening them on an as needed basis since they won't be updated.
Why does the server establish all connections during its initialization procedure?  To ensure 
all resources are available to the task.   If a database has to be shut down for some reason, the 
server will then get shut down because all connections must be closed.  This will be an orderly 
and graceful exit.   Any additional entries queued for this server to process will remain queued 
until a new server is brought to life.  It is a little thing we call reliability.
Please pay careful attention to the wording.  I said “connections.”  I did not say transactions 
or cursors.   Each task will need to create at least one of those when dealing with a database. 
Some connections are created behind the scenes when you use things like SQLMOD so you need 
to be careful.

48

Chapter 5 ­ ACMS Fundamentals

A  GDF  (Group Definition File) defines all of the  WORKSPACES, return value message 
files and servers that will be grouped together in your application.   Each server needs to have 
three procedures defined for it:  


Initialization procedure 
Termination procedure 
and for lack of a better name, the Procedure procedure.  

You only have one initialization and one termination procedure for each server, but could 
have many procedures for the server.  It all depends on how many tasks you decide to bundle in 
the server.  A GDF file also declares which tasks are part of this group.  That declaration is what 
retrieves the task definition from CDD.
Most developers will write all three of these procedures at the same time.  They are rather 
tightly   integrated.     I   have   seen   developers   write   a   single,   well   written   program   with   a 
housekeeping section, an application section and a termination section; test it; then split it up into 
three   separate   compilation   modules.     I've   actually   ported   programs   to   ACMS   in   this   exact 
manner.
Once you have gotten your GDF to compile cleanly, you can write your ADF (Application 
Definition File).  After you look at the source for a GDF file, it may seem there could be nothing 
left to define, but ACMS is a finely tuned system.  The ADF file is where much of that tuning 
takes place.  Here you define the logical name table search path for the application, the username 
under which it will run, and the attributes for each server in the application. 
Attributes may be a somewhat confusing term because it is so over used in this industry. 
There are many things that can be configured on a server by server basis.  Some of them are the 
log file, the error file, the minimum and maximum number of servers and the group definition 
the server belongs to.  While it is not a good practice, you could, in theory, declare servers of the 
same name in different group files and make both group files part of the application.  I humbly 
suggest you do not try it.

Chapter 5 ­ ACMS Fundamentals

49

We have only one real drawback with the application definition.  It defines the name for the 
application as it will be known by ACMS.   That name will be known cluster­wide by ACMS. 
You cannot have a production version of MY_ACMS_APP running on one node in the cluster 
and   a   development   version   running   on   a   different   node.     To   ACMS   they   will   be   multiple 
instances of the same application and it will dispatch work to whichever application has a free 
server   at   the   time   it   gets   work   to   dispatch.     I   have   been   to   places   where   people   did   this. 
Production data went to the test system and then back out again.  In one case, a developer was 
trying to test a modification to the order printing so it could handle a 12­digit dollar value.  That 
order slipped into a production system at the end of a month and the warehouse picked the order.
The result of this drawback is that we need a different  ADF  file for each environment or 
your build procedure has to modify the application name in this source file when it is being built. 
Either approach can be justified, as hard as that may be to swallow.  We shall see what needs to 
be done later in this book when we get to the coding portions.
From a development standpoint, we have covered the major coding pieces required by all 
ACMS applications.  There are environmental and configuration things that we will get into after 
we develop our ACMS application.  Every application must be “installed” in ACMS.  You need 
to define and authorize a user within ACMS (most notably for operator level control).  You also 
need to create and activate at least one queue.  All of those things will be covered later.

5.6

Which Type of ACMS Application?

As we discussed earlier in this book, there are two main types of ACMS applications.  The 
first is the interactive terminal type and the second is the detached process or batch type.  For a 
brief period of time, many of the terminal­type applications were running on the Web.  They had 
used the  DECForms  screen product with a Web interface product.   For whatever reason, HP 
decided the Web interface product shouldn't exist anymore.
While it may have been nice to have the existing green screen application already up on the 
Web in some fashion, it certainly wasn't SOA.  There was still a module type mentality to the 
application.   The customer management system we have been talking about was still a single 
entity.  Generally the tasks weren't split up enough so that they could be used by entities outside 
of the application.

50

Chapter 5 ­ ACMS Fundamentals

The detached  process­type of application fits much more  cleanly into the SOA lifestyle. 
Each task does only one thing and can be called from many places, provided you chose a proper 
method of communication.  You may end up having to provide both sets of functionality inside 
of the same application.  It is certainly not unheard of.  Once a task has been queued, QTI doesn't 
really care where it came from.  All of the user and rights validation occurred prior to the entry 
being written to the task queue.  QTI will dispatch the task.  If you don't understand how security 
works within OpenVMS, that may sound strange to you, but all of you are supposed to have read 
“The Minimum You Need to Know to Be an OpenVMS Application Developer” before reading 
this.
We will experiment with different answers to this question during our journey through this 
book.

5.7

Security

A very short time ago I told you that the ADF controlled which username the application ran 
under (by default).   You don't realize it yet, but that is a massive plus in the world of SOA. 
Instead of having to grant each and every user access to files and tables, you can grant a single 
known   user   (the   user   under   which   the   ACMS   application   runs)   all   of   the   rights   identifiers 
needed.    You then only need to ensure that the external communication occurs via a trusted 
source.  
We have many more methods of ensuring that trust than may first be apparent.   To start 
with, SOA need not be deployed via the Internet, it may exist only on an intranet.   We can 
mandate all external communication occur via  MQ Series,  which means each queue has to be 
authorized   to   connect   to   our   queue   manager.     We   could   choose   a   roll   your   own  TCP/IP 
connection or something else.  We are a long way from covering the external security.  Internal 
security   is   provided   by   the   DOD­certified   operating   system   named   OpenVMS.     The   only 
operating system to be banned from ever reappearing at the national black hat conferences.  Yes, 
it is that secure.

Chapter 5 ­ ACMS Fundamentals
5.8

51

The March Forward

I'm going to start out showing you the “bad” way because that is what your management will 
push you into.  We will directly connect Java to an RDB database.  After that we will develop a 
small order entry application using ACMS.
While it may seem like overkill developing such a small application to ACMS, and the 
direct database via Java may seem the more expedient route, directly connecting databases to 
Java applications run from a Web browser is not a good idea.  I have said it before, and I will 
beat upon it profusely throughout this book.  A directly connected database, no matter what kind 
of front end you put on it to block SQL injection and other attacks, will still be vulnerable.
Management falls victim to marketing and their unnatural desire for a “quick win” when it 
comes to monumental undertakings.  Many of your managers will probably run out and purchase 
a product like Reactivity because the marketing literature says it blocks  SQL injection  attacks. 
Well, it does, just like a virus scanner blocks viruses.  It blocks all of those techniques it knows 
about.     All   you   have   to   do   is   read   the   news   to   understand   that   a   new   virus   effects   tens   of 
thousands, if not millions, of computer systems before there is a new signature or virus scanner 
patch available.
What is different between  SQL injection and viruses?  Intent.  Someone launching a virus 
into the world is looking to either damage your PC for fun, install a key logger to snag all of your 
account/password information for sale/use or turn your machine into a zombie they can rent out 
for attacks.   In other words, you notice two of the viruses main intents.   Your machine starts 
running really slow or you notice a lot of network activity which tells you something is running 
on it you don't know about.   Those intent of wiping your machine make themselves apparent 
eventually as well.
An SQL injection attack is done primarily to expose your data.  Identity theft is a big ticket 
item   today.     Insurance   companies   are   making   fortunes   selling   insurance   against   it   and   the 
attackers are making millions with the data they get.  There intent is to gain enough control over 
your database(s) to glean all of your sensitive customer information.  There intent is to remain 
undetected for as long as possible mining and using/selling as much as possible.

52

Chapter 5 ­ ACMS Fundamentals

Let me tell a story to you which was first told to me back in my college days by a professor. 
My apologies if you have heard this story before.  
Before we had the Internet, we had modem access to systems.   A lot of companies didn't 
think   much   about   data   security.     Some   went   so   far   as   to   use   a   modem   with   an   embedded 
password in it.  Others just used an odd communications setting so hackers wouldn't be able to 
connect properly.   While there were those who would dutifully try to “guess” a password and 
account   name   once   they   found   a   system,   the   most   reliable   method   of   gaining   access   was 
dumpster diving.  Kids would actually go to the recycling  or other dumpsters at large companies 
and dig through the trash looking for software manuals.   The manuals weren't the interesting 
portion though.   Most users would write their account and password in the front of the user 
manual for a system.  When they got a new manual, they rarely, if ever, changed their password.
What is interesting about this story is it is rumored to have been an electric company that 
took the hit.   Not in billing where one would expect, but the installation/repairs division.   The 
kid(s) found information that let them get into this system.  One of them had a relative of some 
kind who was an electrician.  The new installation group had a very detailed bid account online. 
It   kept  all   of   the  contact   information,   components,   text  of   the   layout   and  amount   bid.    The 
biggest help was that from there you could actually place a work order for equipment delivery to 
a job site.
The   way   they   chose   to   make   money   was   to   follow   the   electric   company   around   to   the 
companies they had just done bids for and make their own bid.  All of the same equipment, but 
30% cheaper.   Once they got the contract, they would have the equipment delivered, do the 
work, and collect the money.  They never got billed for the equipment.  It went on for quite a 
while until an inventory audit turned up why accounting was so far out of balance.  Eventually 
they were caught and prosecuted.
If the preceding story isn't your biggest fear with SOA, it should be.  Right now, companies 
have managed to avoid going to prison over identity theft.  That will most likely change with the 
next presidential election.  The bigger financial impact for a company and its shareholders is the 
story   above.     What   if   your   company   routinely   ships   product   to   job   sites   rather   than   only 
customers?  If you normally do $40­50 million, they could probably hit you for $2­3 million per 
year for a very long time.  The real kicker is, you won't be able to prosecute them without going 
public with the story.   Sometimes I ponder just how many companies have been hit like this, 
found out about it and buried the loss rather than prosecuting.

Chapter 5 ­ ACMS Fundamentals

53

Sadly, most of you will be forced into a  LAMP architecture because some MBA saw a 4­
color glossy on it or is stupid enough to follow the advice of the Industry Marketing...err I mean 
Analysts.   (Don't even get me started about those daft enough to actually pay for that advice.) 
LAMP  tends   to   be   defined   as  Linux,  Apache,  MySQL,  PHP.     It   also   happens   to   include 
PostgreSQL, Perl and basically any other open­source tool on the market.  (We don't currently 
have a build of PostgreSQL for OpenVMS.)  One thing I have noticed at client sites that claim to 
be implementing LAMP is that they write a boatload of Java code, but you don't see Java listed 
anywhere in the acronym translations.
Consider   once   again   the   commercial   tool   you   or   your   company   purchased   to   provide 
security and control outside connections to your LAMP architecture.  I'm sure the employees at 
the company slaved away plugging every known SQL injection technique.  Just how big of an 
information pool do you think they had to work with.   Other than the white hats spouting off 
about what they discover on “test systems,” how much information could they have had to work 
with?  The primary intent of an SQL injection attack is to go unnoticed for as long as possible 
stealing as much data as possible.  How many companies out there are willing to go public with a 
story about someone clipping them for $5­12 million dollars over the course of 3­12 years?
A funny thing is happening with XML.  You remember back when XML came out and we 
all used DTDs don't you?  This was supposed to be so great because the length of the data could 
change and nothing else had to.  This is exactly what left the door open to SQL injection.  Now 
everyone is mandating you use a schema and set the maximum length attribute for all tags that 
could/will be used in an SQL expression.  We have almost moved back to completely proprietary 
data formats, but we are too stubborn to admit it.   Yes, fixing the maximum (and minimum) 
length of one to N tags in a schema is easier than up­ending a proprietary record format so you 
can expand a field which doesn't happen to be the last field in the record.  Many of the benefits 
have went away though.

54

Chapter 5 ­ ACMS Fundamentals

There is no way to avoid XML in today's market.   Companies have sunk too much into 
buying parsers and developing standards.   Let me beat this dead horse once again.   Use XML  
between external sources and a proprietary fixed format to communicate with your back­end.  
This   one   simple   act,   while   creating   some   maintenance   work   on   your   part   will   protect   you 
99.99999% from SQL injection attacks.  The only loop hole is having a column in your database 
that is used for selection criteria and is sufficiently wide to allow an injection.  You can weed out 
a lot more by setting the attributes for your selection columns in your XML schema to only allow 
A­Z, a­z and 0­9.
I'm not dissing the commercial front ends that control access and provide lots of different 
kinds of security.  I'm telling you to know, in your heart of hearts as a developer, that they will 
fail at some point and your code is the second line of defense.  Write it wisely.

Chapter 6

Our First Steps
6.1

Deciding on the Method

At this point in the book it is assumed you have read “The Minimum You Need to Know to 
Be   an   OpenVMS   Application   Developer”     ISBN   0­97708660­7.     It   is   also   assumed   you 
understand both the application and the fundamental development concepts on the OpenVMS 
platform.  While it is not required that you have read “The Minimum You Need to Know About 
Java   on  OpenVMS       Volume   1”     ISBN   0­9770866­1­5,  it  is   highly   advisable.     We   will  be 
stealing some concepts and source code from that book during the course of this book.
Management doesn't understand SOA.  They just want to say they have implemented SOA, 
want it done yesterday and want it to use Java so it can be supported by student and tourist Visa 
workers they are paying through a third party.  As far as management knows, if you can run it 
from the Web, it must be SOA.  
Your first cut at this will be to simply put it on the Web.  It's not how you want to do it, but 
you know it will work and that the off­shore team won't be able to support it.  While many will 
say that is a bad and evil thing for you to do, putting the entire application on some insecure Web 
server using a mish­mash of Java+Ruby+Ajax+trend­of­the­week is an even eviler thing to do. 
You are looking out for the security of your customer's data, those using the other tool set aren't.
The correct method is to first port the application to use ACMS.  Once you have the ACMS 
servers running using the existing interface, set up TCP/IP port services to expose those servers 
or MQ Series to communicate with them.  Virtually nobody is using the correct method today.

56
6.2

Chapter 6 ­ Our First Steps
Direct Database Access via Remote Java

I might as well start off showing you the worst possible way of doing it.  This is going to be  
what your knee­jerk boss asks you to do.  It is wrong, so very wrong.  We will start out small and 
work our way forward.  
To really understand this section and the rest of the chapter you need to have read “The 
Minimum You Need to Know About Java on OpenVMS”   ISBN 0­9770866­1­5.  I will be re­
using things from that book throughout this chapter and not covering them again.
The  first small step we  need  to take  is ensuring we  can  access  the  RDB  database  from 
outside the OpenVMS machine.  To do this I copied down rdbThin.jar via binary FTP transfer to 
the soa_work subdirectory on my Ubuntu machine.  Then I copied down TestRdb.java via a text 
transfer.  Because that program required a few modifications I will list the final version below.
TestRdb.java
/*
** The bulk of this code was stolen from RDBJDBCCHECKUP.JAVA which
** you will find in the RDB$JDBC_HOME directory when you install
** the RDBJDBC driver.
*/
// You need to import the java.sql package to use JDBC
import java.sql.*;
import java.io.*;
class TestRdb
{
public static void main(String args[])
throws SQLException, IOException, Exception
{
int l_x;
System.out.println( "Obtaining classname");
Class.forName ("oracle.rdb.jdbc.rdbThin.Driver");
String driverConStr = "jdbc:rdbThin://192.168.2.8:1701/";
System.out.println("Please enter information to test connection to the database");
String user;
String password;
String database = "MEGA_DB_RDB";
user = readEntry("user: ");
password = readEntry("password: ");
System.out.print("Connecting to the database...");
System.out.flush();
System.out.println("Connecting...");
Connection conn = DriverManager.getConnection
(driverConStr + database, user, password);

Chapter 6 ­ Our First Steps

57

System.out.println("connected.");
// Create a statement
Statement stmt = conn.createStatement(
ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
ResultSet rset = stmt.executeQuery("select * from drawing_data limit to 10 rows");
while (rset.next()) {
for (l_x=1; l_x <= 7; l_x++)
System.out.print(rset.getString(l_x) + "\t");
System.out.println( " ");
}
// Go back to top of cursor
//
rset.first();
System.out.println( "\n\nRetriving via column names");
System.out.println( "Draw_Dt
\tNo_1\tNo_2\tNo_3\tNo_4\tNo_5\tMega_No");
System.out.print( rset.getString( "DRAW_DT") + "\t");
System.out.print( rset.getString( "NO_1") + "\t");
System.out.print( rset.getString( "NO_2") + "\t");
System.out.print( rset.getString( "NO_3") + "\t");
System.out.print( rset.getString( "NO_4") + "\t");
System.out.print( rset.getString( "NO_5") + "\t");
System.out.println( rset.getString( "MEGA_NO"));
while (rset.next()) {
System.out.print( rset.getString( "DRAW_DT") + "\t");
System.out.print( rset.getString( "NO_1") + " \t");
System.out.print( rset.getString( "NO_2") + " \t");
System.out.print( rset.getString( "NO_3") + "\t");
System.out.print( rset.getString( "NO_4") + "\t");
System.out.print( rset.getString( "NO_5") + "\t");
System.out.println( rset.getString( "MEGA_NO"));
}

}

// close the result set, the statement and connect
rset.close();
stmt.close();
conn.close();
System.out.println("Your JDBC installation is correct.");

// Utility function to read a line from standard input
static String readEntry(String prompt)
{
try
{
StringBuffer buffer = new StringBuffer();
System.out.print(prompt);
System.out.flush();
int c = System.in.read();
while (c != '\n' && c != -1)
{
buffer.append((char)c);
c = System.in.read();
}
return buffer.toString().trim();
}
catch(IOException e)
{
return "";
}
}
}

58

Chapter 6 ­ Our First Steps

While   it   may   seem   like   I'm   just   taking   up   space   in   this   book,   here   are   the   differences 
between the program we have now and the one from the last book.
$ diff TestRdb.java ref_dir:
************
File DEV_DSK:[HUGHES]TestRdb.java;1
11
******
File MEGA_ROOT:[CMS_REF]TESTRDB.JAVA;1
11
import com.logikal.OpenVMS.routines.*;
12
13
************
************
File DEV_DSK:[HUGHES]TestRdb.java;1
19
System.out.println( "Obtaining classname");
******
File MEGA_ROOT:[CMS_REF]TESTRDB.JAVA;1
21
String driverConStr = "jdbc:rdbNative:";
22
VMSLogical db_logical = new VMSLogical();
23
24
System.out.println( "Obtaining classname");
************
************
File DEV_DSK:[HUGHES]TestRdb.java;1
22
String driverConStr = "jdbc:rdbThin://192.168.2.8:1701/";
23
******
File MEGA_ROOT:[CMS_REF]TESTRDB.JAVA;1
27
driverConStr = "jdbc:rdbThin://localhost:1701/";
28
************
************
File DEV_DSK:[HUGHES]TestRdb.java;1
27
String database = "MEGA_DB_RDB";
28
******
File MEGA_ROOT:[CMS_REF]TESTRDB.JAVA;1
32
String database = db_logical.firsttrans( "MEGA_DB_RDB");
33
************
Number of difference sections found: 4
Number of difference records found: 7
DIFFERENCES /IGNORE=()/MERGED=1DEV_DSK:[HUGHES]TestRdb.java;1MEGA_ROOT:[CMS_REF]TESTRDB.JAVA;1

The first difference you will notice is that we removed the library we created in the last 
book.   Because the platform where execution occurs is not OpenVMS, we cannot use any of 
those library routines.   That same removal lead to the differences found at lines 27 and 28.   It 
also lead to the hard­coded IP address you see in the driverConStr.  Yes, I could have prompted 
the user for that just like we did for the password and username.  That won't be the case when 
you convert this code to an applet though.   An applet will need to connect back to the host it 
came from so you will need to pass it as a parameter.

Chapter 6 ­ Our First Steps

59

Notice that we are using a different JDBC driver as well.  When running on OpenVMS we 
used the native driver, which contains a lot of C code for speed.   Here we use the pure Java 
driver.  This driver connects with the thin server on the OpenVMS machine.
To compile this on Ubuntu I had to complete some setup.  My first setup step was to install 
Sun Java 6.  The default on Ubuntu is a GNU Java implementation.  This means I had to do some 
tweaking because that implementation remains the default even after you install Sun Java.
Note:  I issued the command export PS1=”Ubuntu:>” to change my prompt for use in this 
book.  The default Ubuntu prompt is user @ node:path$.  While that is very informative, when 
using OpenOffice, or any other current word processor pasting something like that in generally 
causes it to be highlighted as a mailto: link.  Most Unix/Linux books will simply use a $ for the 
prompt, but given that is the default prompt on OpenVMS I opted to use this prompt so it would 
be clear which platform we were using.
Ubuntu:> sudo update-java-alternatives -s java-6-sun-1.6.0.03
Ubuntu:> sudo gedit /etc/jvm

I changed my file to look like the following:
#
#
#
#

This file defines the default system JVM search order. Each
JVM should list their JAVA_HOME compatible directory in this file.
The default system JVM is the first one available from top to
bottom.

/usr/lib/jvm/java-6-sun
/usr/lib/jvm/java-6-sun-1.6.0.03
/usr/lib/jvm/ia32-java-1.5.0-sun
/usr/lib/jvm/java-1.5.0-sun
/usr
/usr/lib/jvm/java-gcj

If you are unfamiliar with the “sudo” command, it allows you to temporarily become the 
root user on most forms of  Linux, if you enter the correct password.   In theory you could use 
java­6­sun in the update command because that link is supposed to float between all updates.  I 
rebooted  after completing the above  just to make  certain  all things were  using the Sun Java 
platform.  Gedit is the default editor when you install the default Ubuntu configuration.  It uses 
the Gnome desktop.  If you installed Kubuntu the editor would be Kate.

60

Chapter 6 ­ Our First Steps

We   still  have   just   a   little   work   to  do   on  Ubuntu   before   we   are   ready   for   development. 
Compiling will go just fine, but running will have issues:
Ubuntu:> javac TestRdb.java
Ubuntu:> java TestRdb
Obtaining classname
Exception in thread "main" java.lang.ClassNotFoundException: oracle.rdb.jdbc.rdbThin.Driver
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at TestRdb.main(TestRdb.java:20)

To fix this problem we need to issue the following command:
Ubuntu:>export CLASSPATH=.:/home/roland/soa_work/rdbThin.jar

Notice that I separated the “.” for the current directory from the path to my JAR file with a 
colon.     This   is  a   Unix   thing.     Actually   both   the   “.”   for  the   current   directory   and   the   colon 
separator are Unix things.
Ubuntu:> java TestRdb
Obtaining classname
Please enter information to test connection to the database
user: hughes
password: **************
Connecting to the database...Connecting...
connected.
2005-06-24 00:00:00.0
14
43
44
50
56
2005-06-28 00:00:00.0
2
20
37
43
46
2005-07-01 00:00:00.0
14
25
41
42
50
2005-07-05 00:00:00.0
22
38
48
50
55
2005-07-08 00:00:00.0
9
23
45
48
50
2005-07-12 00:00:00.0
5
17
32
39
53
2005-07-15 00:00:00.0
9
13
25
36
48
2005-07-19 00:00:00.0
7
13
48
51
54
2005-07-22 00:00:00.0
7
18
27
35
54
2005-07-26 00:00:00.0
1
10
18
29
55
Retriving via column names
Draw_Dt
No_1
No_2
2005-06-24 00:00:00.0
14
43
2005-06-28 00:00:00.0
2
20
2005-07-01 00:00:00.0
14
25
2005-07-05 00:00:00.0
22
38
2005-07-08 00:00:00.0
9
23
2005-07-12 00:00:00.0
5
17
2005-07-15 00:00:00.0
9
13
2005-07-19 00:00:00.0
7
13
2005-07-22 00:00:00.0
7
18
2005-07-26 00:00:00.0
1
10
Your JDBC installation is correct.

No_3
44
37
41
48
45
32
25
48
27
18

No_4
50
43
42
50
48
39
36
51
35
29

No_5
56
46
50
55
50
53
48
54
54
55

7
4
40
29
3
36
2
11
34
8

Mega_No
7
4
40
29
3
36
2
11
34
8

Chapter 6 ­ Our First Steps

61

You've now taken your first step to making RDB on OpenVMS the relational database for 
your entire company.  Is this an SOA implementation?  No, it is client server.  Both the JAR file 
and the Java program were stored on the PC I was using.  It does prove that you can hit RDB 
from any of these cheap platforms MBAs are all ga­ga over so there is no reason to abandon the 
most robust database platform on the planet.  
There are a few things I need to mention.  The definition of CLASSPATH and the change to 
the   terminal   prompt   will   not   survive   a   log   out   nor   will   they   be   available   in   other   terminal 
windows you open unless you edit the file .bashrc found in your home directory to add these 
statements.  I am assuming, of course, that you are using the default bash shell on Ubuntu.  There 
are two separate files which perform what LOGIN.COM does for us on OpenVMS.  The second 
file is also found in your home directory and is named .profile.  There are comments at the top of 
both about the kinds of modifications you should/can make to each.  In the comments you will 
also find an explanation of what gets run for an interactive login verses a batch or detached login.
When you enter your password it will actually be visible on the screen.  I edited over that 
part   when   pasting  it  into  this  book.    I  didn't  use  any   fancy   classes   or functions   to  hide   the 
password.    If you are  looking to do that when prompting in console mode, you can  use the 
following snippet.
java.io.Console cons;
if ((cons = System.console()) != null) {
char[] passwd;
passwd = cons.readPassword("[%s]", "Password:");
password = new String( passwd);
}

Please note that this only works in later versions of Java.   Because I'm using Java 6 from 
Sun, it works.  The drawback to this approach is it doesn't print any characters, so the user has no 
idea how many keys they have actually hit if they aren't a touch typist.  The prompting sequence 
looks as follows:
Ubuntu:>java TestRdb
Obtaining classname
Please enter information to test connection to the database
user: hughes
[Password:]

62

Chapter 6 ­ Our First Steps

So, you did all of the stuff I told you to do and you received some form of connection error. 
You ran it multiple times and are absolutely positive you typed the password correctly for your 
account.  Well, you did.  You simply forgot about a few things from my Java book.  The first 
thing you forgot was to submit the file LAUNCH_JDBC_SRV.COM to batch.  The second you 
forgot was what port you used in LGKL_RDBJDBCCFG.XML.  I must admit that for this book I 
changed two lines in that file; not because I had to, I just thought it would save pain down the 
road if my machine was rebooted.
autostart = "true"
autorestart = "true"

In the previous  book I had left them set to “false”  because  we weren't  connecting from 
outside of the system.   Because I would always be logged in and had the startup file in my 
directory,   there   was   no  reason   to  make   certain   the  JDBC  services   were   up  and   running   for 
anyone else.  In a production environment there are reasons.  You might even want to add the 
launch command file to your system startup.
Please keep troubleshooting until you have at least this much working.   Make certain that 
your LOGIN.COM file is defining any logicals you need to access the database you want.  Once 
you can successfully access RDB from Ubuntu, you are ready to proceed.

6.3

Some Thoughts on Editors

We   will   assume   that   you   obtained   a   CD   or   downloaded   Ubuntu   and   took   the   default 
installation.   This means you are using the Gnome desktop instead of KDE.   There are many 
more desktops available for Linux, but these are two of the most widely supported.  Indeed, their 
supporting camps contain what most would call “religious extremists.”
When using Gnome, the default text editor is Gedit.  KDE provides Kate as its default editor. 
Both of these editors have syntax highlighting and configuration options that make them passable 
for the amount of coding we will do in this book.  If you are used to more powerful editors from 
other platforms, there are many options available to you.  

Chapter 6 ­ Our First Steps

63

If you are an old hand on OpenVMS who never moved from EDT, there is even hope for 
you.  Some poking around on SourceForge.net will locate an EDT clone for X­windows systems. 
It is distributed in source form with a README.TXT file that explains how to compile and 
configure the keypad.   The default mappings certainly aren't what I normally configure when 
setting up a VT emulator, but there is a process for changing such things.  I didn't dig through the 
product enough to see if it supports commands like F=PASTE, but feel free to spend your time 
doing this if you want.  What I'm pointing out is that you can remain pretty close to what you are 
used to if you really want.  
When being forced to work with Java or Perl, I prefer syntax highlighting.  Sometimes it is 
even nice to have when working with C/C++.   The default editors of  Gedit  and Kate provide 
syntax highlighting.   They even let you turn on things like line numbers and configure other 
settings.   I don't care for the colors chosen.   It seems that Unix developers and those on the 
derivative platforms never learned what we on OS/2 and other platforms learned.   Comments 
should be green and they should be the only green color in your editor.  
Before anyone leaps to defend the color choices found in the editors I mention, or points out 
that you can change all of them, let me mention portability.  As a software consultant I make it a 
point to not change much when I arrive at a client site.  While I may add a few lines to the LSE 
startup, I won't completely reconfigure an editor preloaded onto the box I've been given.  I may 
pull down a free editor which is run from a local directory if that is allowed; but otherwise, I 
attempt to conform to the environment.  Why?  Because I'm a tourist.  My contract there is going 
to end at some point and the code/environment  needs to be what the employees  are  used to 
seeing or working with.
The nice part about working on Ubuntu is that there is absolutely no need what so ever to 
purchase a commercial editor.   If you are giving up one of those other crummy PC operating 
systems   put   out   by   some   company   in   Washington   state,   then   you   no   longer   have   to   spend 
hundreds of dollars on editors like SlickEdit.  Here are some things for you to look at:
Bluefish Editor
Geany
jEdit
MadEdit
SciTE

64

Chapter 6 ­ Our First Steps

Illustration 6.1. 

Chapter 6 ­ Our First Steps

65

The  image  on  the  preceding   page  is the  editor  I've  worked  the  least  with while  on this 
platform.  I'm going to cover it first because of one very nice feature it has.  Notice the column 
between the line numbers and the source code?  When you click on one of those boxes with a 
dash in it, the span of code/comments between it and the matching enclosure folds/hides and the 
box will then have a plus sign in it.  The editor we are looking at is called Geany.  It is free and 
one you should seriously consider when choosing an editor on this platform.

Illustration 6.2. 

66

Chapter 6 ­ Our First Steps

Bluefish  is an editor that a lot of people swear by.   The original market it was serving 
appears to have been HTML developers.  Somehow this open­source project is tied in with the 
OpenOffice project.  In case you weren't paying attention earlier, this book is being written with 
OpenOffice.  I haven't used Bluefish enough to be good with it, but, like most of the graphical 
text editors, you can be a bumbling idiot and still get your source code entered.   By “be good 
with it” I mean perform complex substitutions or substitutions across multiple files.  In short, the 
kind of stuff we did with EDT_MASS_SUB.COM.

Illustration 6.3. 

Chapter 6 ­ Our First Steps

67

SciTE is a very capable editor on this platform.  Yes, Gedit is the default and I use it a lot 
because   of   that,   but   SciTE   has   some   endearing   qualities.     For   one   it   has   the   comments 
highlighted in green out of the box.  This was obviously an editor written by professionals who 
know what they are doing.  Configuring things on the editor can take a little poking around.  It 
uses option files.   When you install the editor via the Synaptic Package Manager, the global 
option file will be owned by root so you won't be able to accidentally change it.  You can look at 
it and copy things from it into your user options file, then change the values there.   At first I 
found this a bother, but after using the editor for a while, I think it is more consistent with the 
Linux philosophy and how we configure LSE on OpenVMS.  So far my personal configuration 
file looks like this:
strip.trailing.spaces=1
tabsize=4
indent.size=4
use.tabs=0
indent.auto=1
indent.automatic=1
indent.opening=0
indent.closing=0
line.margin.visible=1
font.base=$(font.monospace)
font.small=$(font.monospace)
font.comment=$(font.monospace)
font.text=$(font.monospace)
font.text.comment=$(font.monospace)
font.embedded.base=$(font.monospace)
font.embedded.comment=$(font.monospace)
font.vbs=$(font.monospace)
save.recent=1
save.session=1
buffers=30
position.width=800
position.height=800

The general rule of thumb is that 1 turns something on and 0 turns it off.  Given the fact I 
believe all text should line up in a programming editor, you will see I set everything to use the 
configured “monospace” font.  One thing you need to be aware of with graphical editors is that 
they don't always use a mono­spaced font.  Many of them will try to use a predetermined point 
size with a Courier font.  It will look as if things line up, until you change the point size.
One of the more interesting editors in the world of free is  MadEdit.   You can find it on 
SourceForge.  As far as I can tell it doesn't come on any distributions of Linux by default, but it 
is a very capable editor.  One of the best things about it is you can try it right now on your icky 
Windows box.  Once you get used to it, moving to Ubuntu won't be such a culture shock.

68

Chapter 6 ­ Our First Steps

Illustration 6.4. 

You have been reading a free preview. Please visit
http://www.theminimumyouneedtoknow.com to learn more about
this award winning technical book series and where it can be
purchased.