COBOL and Visual Basic on .NET ”A Guide for the Reformed Mainframe Programmer
All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher.
ISBN (pbk): 1-59059-048-1
Printed and bound in the United States of America 12345678910
Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked
, we use the
only in an editorial fashion and to the benefit of the trademark owner, with no
of infringement of the trademark.
Technical Reviewer: Hung Tran
Editorial Directors: Dan Appleman, Gary Cornell, Simon Hayes, Martin Streicher, Karen Watterson, John Zukowski
Assistant Publisher: Grace Wong
Project Manager: Sofia Marchant
Developmental Editor: Valerie Perry
Copy Editor: Nicole LeClerc
Compositor: Argosy Publishing
Artist: Faith Bradford
Indexer: Kevin Broccoli
Cover Designer: Kurt Krames
Production Manager: Kari Brooks
Manufacturing Manager: Tom Debolski
Distributed to the book trade in the United States by Springer-Verlag New York, Inc., 175 Fifth Avenue, New York, NY, 10010 and outside the United States by Springer-Verlag GmbH & Co. KG, Tiergartenstr. 17, 69112 Heidelberg, Germany.
In the United States, phone 1-800-SPRINGER, email
, or visit
. Outside the United States, fax +49 6221 345229, email
, or visit
For information on translations,
contact Apress directly at 2560 Ninth Street, Suite 219, Berkeley, CA 94710. Phone 510-549-5930, fax 510-549-5939, email
, or visit
The information in this book is distributed on an "as is" basis, without warranty. Although every precaution has been taken in the preparation of this work,
the author(s) nor Apress shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work.
The source code for this book is available to readers at
in the Downloads section.
In loving memory of my parents,
Mable Lois and Carroll Wayne Richardson.
As Rodney Dangerfield says, "I don't get no respect," so too COBOL doesn't "get no respect." The COBOL language has been underappreciated, disrespected, criticized, and bashed for much of its existence. It is
perceived as an inefficient, verbose application development tool, irrelevant to modern software development methodologies. Nothing could be further from the truth. The very existence of Christopher Richardson's book,
COBOL and Visual Basic on .NET: A Guide for the Reformed Mainframe Programmer,
is a testament to COBOL's
The timing of Mr. Richardson's book couldn't be better. The fourth official publication of the COBOL standard (COBOL o2002
) is pending as of this writing. It
COBOL 68, COBOL 74, and COBOL 85. If you consider the Intrinsic Functions Addendum published in o1989, the new COBOL o2002 actually marks the fifth official release of standard COBOL.
The disrespect for the COBOL programming language, which is encouraged in many universities, is not new. The earliest gesture of "COBOL bashing" lies in the Computer Museum in Boston. It is a COBOL tombstone. Soon after the Conference on Data Systems Languages (CODASYL) committee was
in o1959, a COBOL tombstone was given as a (gag) gift from some of the CODASYL COBOL committee
to the chairperson of CODASYL. It was
to express their lack of confidence that this new "common business language" (CBL, later COBOL) would be used in the IT industry for very long. As it turned out, the COBOL language, defined by the CODASYL "short-range" committee and first published in o1960, has been an important part of the IT industry for 43
”and still counting. Perhaps it is natural to presume that anything in the IT industry
back to the o1950s/o1960s must be obsolete and irrelevant in the twenty-first century. The mistake in this logic is that the COBOL language (features and syntax) has evolved dramatically over its lifetime. I like to
an old General Motors commercial: "COBOL o2002 is not your father's/mother's COBOL."
Although the COBOL tombstone may have been the earliest example of COBOL bashing, it
wasn't the last. The
of the IT industry are filled with other instances of public disrespect for COBOL. Dutch computer
Edsgar Djikstra wrote in 1982, "The teaching of COBOL should be made a criminal offense!" For years, I have been speaking at universities around the world. Generally, COBOL has been on the defensive in these academic environments. Few people in my audiences (
included) were/are aware of what the modern COBOL language can do. COBOL has no real technical problems ”it has "public relations" problems.
In the early o1980s, COBOL bashing took a
. Serious efforts were underway to "kill" COBOL. In preparation for the publication of ISO/ANSI COBOL 85, there were serious legal and lobbying attempts (led by Travelers Insurance and joined by other respectable corporations) to block any new COBOL standardization effort. Some wanted to freeze the COBOL language as described in the ANSI COBOL 74 standard. Others wanted to roll back the COBOL standard to its "official" COBOL 68 version. The argument
by these groups was that it involved a great corporate cost to update their enterprise applications in order for older COBOL programs to compile cleanly in
COBOL compilers. No one told them that they didn't need to recompile any programs unless the business application required updating.
This frustration is still felt by many IT departments today. It's similar to the frustration
by many home computer users who object to frequent hardware changes, operating system upgrades, application updates, and the
all of this "progress." This is a
dilemma. The ISO/ANSI COBOL committees became very sensitive to any change (addition, modification, deletion) to the COBOL standard that might affect programs written earlier. Still to this day, the (INCITS/ANSI) X3J4 COBOL committee, which is responsible for the technical evolution of COBOL, maintains a special list of new and changed features incorporated in COBOL o2002 that could possibly produce incompatible results with older COBOL programs. Special voting rules were put into effect before "
incompatible" features can be added to the COBOL language. COBOL features designated as "obsolete" are required to
in the new COBOL standard for at least one more iteration before they're permanently removed from the official COBOL standard. This is done to give the COBOL community ample time (a
or more) to update the affected programs and remove the obsolete features. COBOL is nonproprietary. The "official" COBOL standard is not owned by any one software manufacturer. It's developed by a cross-section of IT professionals, both COBOL compiler/tools manufacturers and COBOL users. This requirement of balancing the COBOL committee representation was built into the membership rules of the COBOL development
so there would be a broad range of views regarding how COBOL could best serve the business application development community. It isn't accidental, therefore, that COBOL earned its reputation over the years as a solid, dependable application development language that protects its constituency ”application developers ”from whimsical changes. It is one of COBOL's many strengths.
Few things that were around in the IT industry in o1960 are still around today, except perhaps in museums and in basements. Yet the COBOL language, albeit highly evolved from its origins, remains relevant. The corporate assets represented by the billions (trillions?) of lines of COBOL code still running on commercial computers aren't about to be
. Nor should they be. New tools that help integrate legacy (read: COBOL) systems with PC applications, Web services, new data formats, and protocols have been available since distributive systems emerged years ago. As today's application environment has evolved, .NET for instance, so has COBOL's capability to link to it, merge with it, and interact with it. Stretching the lifespan of an enterprise's legacy systems
the value and productivity of its IT development staff and of the assets they produce.
. The use of five digits years (e.g., o2002) throughout this foreword is done so as not to be shortsighted in the year 9999 prior to the turn of the eleventh
. Sure, you might say, "Isn't it a bit early to be worrying about the Y10K problem?" But as we now know in retrospect, this is the same kind of thinking over the past three to four decades that led us to the Y2K crisis. Well, maybe I'm being a bit too cautious. If most enterprise applications are developed in COBOL for the
8,000 years, I suppose the Y10K crisis, as the Y2K crisis, will turn out to be a "