Be an OpenVMS Application Developer
Excerpt - Introduction
I.1 Purpose of This Book
The purpose of this book is to be an aid for developers switching platforms to OpenVMS. It is
also designed to be useful to college level students who have had at least one of the
programming languages covered in this book as course work. Anyone who is currently successful
at writing applications on the lesser platforms, namely Windows and UNIX, should be able to use
this book and in a relatively short period of time become productive on the much more robust and
stable platform of OpenVMS.
There are quite a few third party books which have been written over the years on/about the
OpenVMS platform. Those books go into great detail about very specific areas of this platform.
What you should glean from this book is a very broad understanding of development tools and
techniques you will encounter when working on the OpenVMS platform. While we will delve into
some of the obscurities a developer needs to be aware of as we cover each topic, we will not cover
all of the minutiae.
This book is not intended to be the last and final word on OpenVMS development, nor is it
intended to replace the dozens upon dozens of manuals written for OpenVMS by its owners.
(Currently HP at the time of this writing.) You should know enough when you finish with this book
to both not be afraid of development, and know where to look for further information. Upon
completion of this book you will have more than enough knowledge and skills to become a
maintenance programmer at many shops running OpenVMS.
I.2 What You Need to Know to Read This Book
This book is intended to be used by applications developers, consultants, and to some extent
systems analysts. You should have had at least one course in logic and be comfortable with at
least one of the programming languages covered in this book or a language very similar to it.
Managers will find much of the information useful when making technical direction decisions.
Those developers whose only language is “Visual something or other” didn’t learn a language and
will flounder miserably with this book.
I.3 Who Should Read This Book
Anyone who plans to become employed or a consultant using the OpenVMS platform should both
own and read this book. No matter how seasoned you are on a platform, even if OpenVMS is your
current platform, it is nice to have a cheat-sheet to flip through when the mind gets a little foggy. As
I get older, I find I cheat more when having to go back and maintain some of the really old stuff at
client sites. Hence, it was part of the incentive to write this book.
I.4 How to Read This Book
This book is meant to be read from front to back initially, then serve as a reference manual on
your desk. Each chapter builds upon the previous chapter. Once we talk about DCL in Chapter 2
we use it and talk about it throughout much of the book. Likewise, once we talk about BASIC, we
will continue talking about it most of the way through the book.
Some books cover only one topic like a single language. They bombard you with the mass of the
syntax in such a general way as to be useless when taken in the context of any single platform.
This book is not a dry and sterile treatise on the syntax of languages. This book starts you out with
the minimum you need to know just to log on and use the platform. Then it builds one application
teaching many different aspects of the platform as you need to know them during the course of the
development. Where appropriate, the historical reasons for the way things are get passed along
as well.
It is the hope of the author that using a single application which requires all of the basic skills
needed to be a maintenance developer on this platform with each of the languages covered will
teach you more than just those skills. Following the journey through to the end will also give you
an idea of the trade offs you make using each tool. There is no one tool which is perfect for all
jobs. There are many reasons you will find shops using 4 or more languages. Sometimes they
bought a package written in a language they currently weren’t using, other times they wrote the
package themselves in that language or tool because it was the best tool for the job even if they
had to encounter a learning curve to make it work.
At the end of your journey is a reward. The chapter entitled “Ruminations and Observations” is a
series of essays about IT topics and life in general. This chapter is my reward for writing this
book. Some of the sections there may offend you beyond any scope of reason — good. Others
may provoke thoughts which keep you lying awake at night trying to figure out a solution — also
good. The topics I choose to cover in this chapter are problems and concepts which must be
addressed in IT for the good of the industry. How they actually get addressed will be up to you the
reader, and you the voting shareholder of corporations. There are sections in that chapter covering
information gathering, optimal technology, the reason Y2K happened and off shore computing.
I.5 Our Sample Application
We will have a single sample application redeveloped in all languages. I’m not going to bore you
to tears with a contrived and hokey inventory or order entry system which seems to be the bane of
academia. Let’s face it, we have all read books like that, and we never spent any time after we
finished the book playing with the application because it was boring. I’m also not going to create a
useless paint application which you will find touted in almost every GUI platform book on the
market.
Our sample application will track the Mega-Zillionare lottery. No, that is not its official name.
There are several different multi-state lotteries with similar rules and official web sites where you
can download data. The test data for this application will be provided on the CD-ROM and be
called DRAWING_DATA.TXT. Once you are comfortable with using the various editors you can
download and format your own bulk data file for import.
Initially we will use RMS indexed files to store the data. One for the drawing data, and two for
statistical data. Don’t get nervous; we will only be doing some crude stats on the data. Mainly we
will count the number of hits, percentage of hits, sequence of hits, average and maximum of
misses between hits. Calling it statistics is probably being too grandiose.
The input data file is a CSV (comma separated values) formatted file. It contains one record per
line in the format: drawing date, number 1, number 2, number 3, number 4, number 5, and the
mega number. The primary indexed file will be laid out in much the same way.
We will have the following main components in each application:
• Import program to create a new data file from a bulk import file.
• Stats generation program to create two new indexed statistics files.
• Report programs to print off numbers based upon their statistical ranking.
• A form of data entry to add additional drawing data on a single record basis.
• A browse program to scroll through the drawing data.
As you can see this little application will encompass all of the core functionality you need to know
to begin being productive with each tool set described. By redeveloping the same application with
different languages and different tools you will get a feeling for the design tradeoffs each tool set
has. When we get to the relational database chapters the indexed files will be replaced by tables.
Hopefully you will experiment yourself with each of the tool sets to find improvements to make the
application more to your liking. As I said, I’ve chosen an application you might actually wish to play
with if for no other reason than the new data is available every week.
As stated, we will have 3 indexed files for this application. The first will be an indexed file
containing the drawing data, the second will contain stats for the main drawing numbers, and the
third will contain stats for the mega/power number. Below are the file layouts. The tag of “k0” to
the right of a field is my way of flagging the primary key.
Drawing_Data
Draw_dt char[8] k0
No_1 integer
No_2 integer
No_3 integer
No_4 integer
No_5 integer
Mega_no integer
Drawing_Stats Mega_Stats
Elm_no integer k0 Elm_no integer k0
Hit_count integer Hit_count integer
Last_draw_no integer Last_draw_no integer
Since_last integer Since_last integer
Curr_seq integer Curr_seq integer
Longest_seq integer Longest_seq integer
Pct_hits double Pct_hits double
Max_btwn integer Max_btwn integer
Ave_btwn double Ave_btwn double
I.6 Why OpenVMS?
Many of you reading this will be coming from other platforms you are comfortable with and believe
they can be used to do anything. Most of these platforms haven’t existed as long as OpenVMS.
Few, if any, had the number of operating systems and hardware changes which culminated with
OpenVMS. Near the dawn of the computer age (you know you are really old if you can remember
the dawn of an age) some of the first platforms made by Digital Equipment Corporation (DEC)
were the DEC-10 and DEC-20 time sharing computers. I never had the privilege of working on
those platforms but have talked with some that did. They performed exceptionally well for their era
running TOPS-10 and TOPS-20 operating systems.
Later DEC came out with the PDP line of computers. These computers ran various operating
systems: RSTS/E, RSX-11 and RT-11 among them. (Those coming from the UNIX side of life may
also remember that UNIX was originally developed on the PDP hardware platform.) Each of the
previously mentioned OS’s still have their followers today. Though the job opening advertisements
for those operating systems may be few and far between now, you will still find some PDP
hardware running today. There are even some manufacturers making PDP-11 emulators to use
inside various other boxes. Each of the operating systems was designed to handle some niche
applications incredibly well; so well, some companies have opted not to replace them as long
there is some method of keeping them running.
When DEC came out with the VAX platform they had over a decade of seasoning and think
tanking by some incredible minds behind them. Both the platform and the operating system were
designed from the ground up to create a seamless network. Today, with the Internet available to
the masses for a fee, most would say “so what.” OpenVMS, however, wasn’t designed today; it
was originally laid out in the late 1970’s for platforms selling in the early 1980’s. With OpenVMS
came the original definition of clustering.
Many operating systems today claim clustering capabilities and many application packages claim
to be “cluster aware” on many platforms, but once you become accustomed to the power, stability
and flexibility of clustering in an OpenVMS environment, you will see just how hollow those claims
really are. We won’t cover much on clustering in this book, not because there isn’t much to cover,
but because once a system manager sets up a cluster, the application developer really doesn’t
care where the nodes are. When a system manager chooses to mount a disk drive on one node
as available to the cluster it looks just like a local disk drive to the application developer no matter
what node they are working on. By “nodes” I’m not just talking about servers in the same building.
These machines can be anywhere in the world. I have personally consulted for companies that
had nodes scattered across the US, England, Ireland, Germany and other countries. From time to
time you may see some lag accessing one of the drives due to congestion on the network, but you
don’t access them any differently.
Batch queues, print queues, and ACMS (Application Control and Management System)
applications can be defined so that any node in the cluster can use them without the faintest idea
of where they are. Admittedly, you might want to know where the printer actually is which is
servicing a print queue, but you don’t have to. More importantly, that printer could very well be on a
different continent from the cluster node servicing it. Indexed, sequential and other file types can
be shared by multiple users from any node in the cluster.
The Records Management System (RMS) on OpenVMS provides a feature developers can
choose to use called RMS Journaling. This works in unison with a component/product called DTM
(Distributed Transaction Manager). DTM keeps everything in sync and rolls partial transactions
back. This allows a developer a great amount of both freedom and security. You can have a
single transaction which encompasses multiple RMS Journalled files and multiple RDB tables
and know profoundly that nothing will be updated until you actually commit the DTM transaction. If
the power grid drops on your machine while your program is running, when the OS comes back up
and starts the DTM portion, DTM cleans itself up. If you develop your application correctly, you can
simply restart the application once the system has come up and rejoined the cluster.
OpenVMS doesn’t suffer from the e-mail and other viruses which plague other platforms. It has
passed numerous DOD security tests. Some hacker conferences have even declared the OS
unhackable. While I would never go so far as to make that claim about any OS, coming from
groups like that it is quite a statement.
A concept which was pioneered on the PDP platform has become a force of unprecedented
power - logicals. We will cover logicals in Chapter 1. They are a truly amazing creation which
provide security, simplicity and complexity all at the same time. A person could write almost an
entire book just covering the concept and implementation of logicals. This book will give you
enough understanding about them to both use and respect them.
I.7 The Definition of Application
For the purposes of this book and the possible follow up book I am defining application as a
single hosted program or set of programs running on a single cluster. While many people would
call these “systems”, I do not. In my view, “systems” development requires a data interface to the
outside world.
While one could make the argument that an application which gets tapes loaded via “sneaker
net” is a system using a tape interface, in today’s world those types of systems don’t usually exist.
(Sneaker net refers to operators wearing sneakers running around a computer room gathering
print outs and handling tapes.) Systems in today’s world interface via a communications library
(MQ Series, Tibco, DECNET, Tuxedo, and if desperate, TCP/IP) to non homogenous platforms.
They feed each other in real time or batch mode. Their function and failure is visible outside the
company. Application failure is only visible inside the company.
The purpose of this book is to be an aid for developers switching platforms to OpenVMS. It is
also designed to be useful to college level students who have had at least one of the
programming languages covered in this book as course work. Anyone who is currently successful
at writing applications on the lesser platforms, namely Windows and UNIX, should be able to use
this book and in a relatively short period of time become productive on the much more robust and
stable platform of OpenVMS.
There are quite a few third party books which have been written over the years on/about the
OpenVMS platform. Those books go into great detail about very specific areas of this platform.
What you should glean from this book is a very broad understanding of development tools and
techniques you will encounter when working on the OpenVMS platform. While we will delve into
some of the obscurities a developer needs to be aware of as we cover each topic, we will not cover
all of the minutiae.
This book is not intended to be the last and final word on OpenVMS development, nor is it
intended to replace the dozens upon dozens of manuals written for OpenVMS by its owners.
(Currently HP at the time of this writing.) You should know enough when you finish with this book
to both not be afraid of development, and know where to look for further information. Upon
completion of this book you will have more than enough knowledge and skills to become a
maintenance programmer at many shops running OpenVMS.
I.2 What You Need to Know to Read This Book
This book is intended to be used by applications developers, consultants, and to some extent
systems analysts. You should have had at least one course in logic and be comfortable with at
least one of the programming languages covered in this book or a language very similar to it.
Managers will find much of the information useful when making technical direction decisions.
Those developers whose only language is “Visual something or other” didn’t learn a language and
will flounder miserably with this book.
I.3 Who Should Read This Book
Anyone who plans to become employed or a consultant using the OpenVMS platform should both
own and read this book. No matter how seasoned you are on a platform, even if OpenVMS is your
current platform, it is nice to have a cheat-sheet to flip through when the mind gets a little foggy. As
I get older, I find I cheat more when having to go back and maintain some of the really old stuff at
client sites. Hence, it was part of the incentive to write this book.
I.4 How to Read This Book
This book is meant to be read from front to back initially, then serve as a reference manual on
your desk. Each chapter builds upon the previous chapter. Once we talk about DCL in Chapter 2
we use it and talk about it throughout much of the book. Likewise, once we talk about BASIC, we
will continue talking about it most of the way through the book.
Some books cover only one topic like a single language. They bombard you with the mass of the
syntax in such a general way as to be useless when taken in the context of any single platform.
This book is not a dry and sterile treatise on the syntax of languages. This book starts you out with
the minimum you need to know just to log on and use the platform. Then it builds one application
teaching many different aspects of the platform as you need to know them during the course of the
development. Where appropriate, the historical reasons for the way things are get passed along
as well.
It is the hope of the author that using a single application which requires all of the basic skills
needed to be a maintenance developer on this platform with each of the languages covered will
teach you more than just those skills. Following the journey through to the end will also give you
an idea of the trade offs you make using each tool. There is no one tool which is perfect for all
jobs. There are many reasons you will find shops using 4 or more languages. Sometimes they
bought a package written in a language they currently weren’t using, other times they wrote the
package themselves in that language or tool because it was the best tool for the job even if they
had to encounter a learning curve to make it work.
At the end of your journey is a reward. The chapter entitled “Ruminations and Observations” is a
series of essays about IT topics and life in general. This chapter is my reward for writing this
book. Some of the sections there may offend you beyond any scope of reason — good. Others
may provoke thoughts which keep you lying awake at night trying to figure out a solution — also
good. The topics I choose to cover in this chapter are problems and concepts which must be
addressed in IT for the good of the industry. How they actually get addressed will be up to you the
reader, and you the voting shareholder of corporations. There are sections in that chapter covering
information gathering, optimal technology, the reason Y2K happened and off shore computing.
I.5 Our Sample Application
We will have a single sample application redeveloped in all languages. I’m not going to bore you
to tears with a contrived and hokey inventory or order entry system which seems to be the bane of
academia. Let’s face it, we have all read books like that, and we never spent any time after we
finished the book playing with the application because it was boring. I’m also not going to create a
useless paint application which you will find touted in almost every GUI platform book on the
market.
Our sample application will track the Mega-Zillionare lottery. No, that is not its official name.
There are several different multi-state lotteries with similar rules and official web sites where you
can download data. The test data for this application will be provided on the CD-ROM and be
called DRAWING_DATA.TXT. Once you are comfortable with using the various editors you can
download and format your own bulk data file for import.
Initially we will use RMS indexed files to store the data. One for the drawing data, and two for
statistical data. Don’t get nervous; we will only be doing some crude stats on the data. Mainly we
will count the number of hits, percentage of hits, sequence of hits, average and maximum of
misses between hits. Calling it statistics is probably being too grandiose.
The input data file is a CSV (comma separated values) formatted file. It contains one record per
line in the format: drawing date, number 1, number 2, number 3, number 4, number 5, and the
mega number. The primary indexed file will be laid out in much the same way.
We will have the following main components in each application:
• Import program to create a new data file from a bulk import file.
• Stats generation program to create two new indexed statistics files.
• Report programs to print off numbers based upon their statistical ranking.
• A form of data entry to add additional drawing data on a single record basis.
• A browse program to scroll through the drawing data.
As you can see this little application will encompass all of the core functionality you need to know
to begin being productive with each tool set described. By redeveloping the same application with
different languages and different tools you will get a feeling for the design tradeoffs each tool set
has. When we get to the relational database chapters the indexed files will be replaced by tables.
Hopefully you will experiment yourself with each of the tool sets to find improvements to make the
application more to your liking. As I said, I’ve chosen an application you might actually wish to play
with if for no other reason than the new data is available every week.
As stated, we will have 3 indexed files for this application. The first will be an indexed file
containing the drawing data, the second will contain stats for the main drawing numbers, and the
third will contain stats for the mega/power number. Below are the file layouts. The tag of “k0” to
the right of a field is my way of flagging the primary key.
Drawing_Data
Draw_dt char[8] k0
No_1 integer
No_2 integer
No_3 integer
No_4 integer
No_5 integer
Mega_no integer
Drawing_Stats Mega_Stats
Elm_no integer k0 Elm_no integer k0
Hit_count integer Hit_count integer
Last_draw_no integer Last_draw_no integer
Since_last integer Since_last integer
Curr_seq integer Curr_seq integer
Longest_seq integer Longest_seq integer
Pct_hits double Pct_hits double
Max_btwn integer Max_btwn integer
Ave_btwn double Ave_btwn double
I.6 Why OpenVMS?
Many of you reading this will be coming from other platforms you are comfortable with and believe
they can be used to do anything. Most of these platforms haven’t existed as long as OpenVMS.
Few, if any, had the number of operating systems and hardware changes which culminated with
OpenVMS. Near the dawn of the computer age (you know you are really old if you can remember
the dawn of an age) some of the first platforms made by Digital Equipment Corporation (DEC)
were the DEC-10 and DEC-20 time sharing computers. I never had the privilege of working on
those platforms but have talked with some that did. They performed exceptionally well for their era
running TOPS-10 and TOPS-20 operating systems.
Later DEC came out with the PDP line of computers. These computers ran various operating
systems: RSTS/E, RSX-11 and RT-11 among them. (Those coming from the UNIX side of life may
also remember that UNIX was originally developed on the PDP hardware platform.) Each of the
previously mentioned OS’s still have their followers today. Though the job opening advertisements
for those operating systems may be few and far between now, you will still find some PDP
hardware running today. There are even some manufacturers making PDP-11 emulators to use
inside various other boxes. Each of the operating systems was designed to handle some niche
applications incredibly well; so well, some companies have opted not to replace them as long
there is some method of keeping them running.
When DEC came out with the VAX platform they had over a decade of seasoning and think
tanking by some incredible minds behind them. Both the platform and the operating system were
designed from the ground up to create a seamless network. Today, with the Internet available to
the masses for a fee, most would say “so what.” OpenVMS, however, wasn’t designed today; it
was originally laid out in the late 1970’s for platforms selling in the early 1980’s. With OpenVMS
came the original definition of clustering.
Many operating systems today claim clustering capabilities and many application packages claim
to be “cluster aware” on many platforms, but once you become accustomed to the power, stability
and flexibility of clustering in an OpenVMS environment, you will see just how hollow those claims
really are. We won’t cover much on clustering in this book, not because there isn’t much to cover,
but because once a system manager sets up a cluster, the application developer really doesn’t
care where the nodes are. When a system manager chooses to mount a disk drive on one node
as available to the cluster it looks just like a local disk drive to the application developer no matter
what node they are working on. By “nodes” I’m not just talking about servers in the same building.
These machines can be anywhere in the world. I have personally consulted for companies that
had nodes scattered across the US, England, Ireland, Germany and other countries. From time to
time you may see some lag accessing one of the drives due to congestion on the network, but you
don’t access them any differently.
Batch queues, print queues, and ACMS (Application Control and Management System)
applications can be defined so that any node in the cluster can use them without the faintest idea
of where they are. Admittedly, you might want to know where the printer actually is which is
servicing a print queue, but you don’t have to. More importantly, that printer could very well be on a
different continent from the cluster node servicing it. Indexed, sequential and other file types can
be shared by multiple users from any node in the cluster.
The Records Management System (RMS) on OpenVMS provides a feature developers can
choose to use called RMS Journaling. This works in unison with a component/product called DTM
(Distributed Transaction Manager). DTM keeps everything in sync and rolls partial transactions
back. This allows a developer a great amount of both freedom and security. You can have a
single transaction which encompasses multiple RMS Journalled files and multiple RDB tables
and know profoundly that nothing will be updated until you actually commit the DTM transaction. If
the power grid drops on your machine while your program is running, when the OS comes back up
and starts the DTM portion, DTM cleans itself up. If you develop your application correctly, you can
simply restart the application once the system has come up and rejoined the cluster.
OpenVMS doesn’t suffer from the e-mail and other viruses which plague other platforms. It has
passed numerous DOD security tests. Some hacker conferences have even declared the OS
unhackable. While I would never go so far as to make that claim about any OS, coming from
groups like that it is quite a statement.
A concept which was pioneered on the PDP platform has become a force of unprecedented
power - logicals. We will cover logicals in Chapter 1. They are a truly amazing creation which
provide security, simplicity and complexity all at the same time. A person could write almost an
entire book just covering the concept and implementation of logicals. This book will give you
enough understanding about them to both use and respect them.
I.7 The Definition of Application
For the purposes of this book and the possible follow up book I am defining application as a
single hosted program or set of programs running on a single cluster. While many people would
call these “systems”, I do not. In my view, “systems” development requires a data interface to the
outside world.
While one could make the argument that an application which gets tapes loaded via “sneaker
net” is a system using a tape interface, in today’s world those types of systems don’t usually exist.
(Sneaker net refers to operators wearing sneakers running around a computer room gathering
print outs and handling tapes.) Systems in today’s world interface via a communications library
(MQ Series, Tibco, DECNET, Tuxedo, and if desperate, TCP/IP) to non homogenous platforms.
They feed each other in real time or batch mode. Their function and failure is visible outside the
company. Application failure is only visible inside the company.
| Copyright © 2007 TheMinimumYouNeedtoKnow.com. The information on this page may not be reproduced or republished without prior permission from Roland Hughes. |
| HOME :: ROLAND HUGHES :: BOOKS in the SERIES :: ORDER :: SITE MAP |
| About the Book || Reviews || Table of Contents || Excerpt || Behind the Scenes |