Programming Languages

Computer Training Excuses - No ExcuseYou wouldn't go to a doctor who had never been to medical school, or hire a lawyer who never studied law. One side-effect of a world advancing as rapidly as ours is that fields are becoming more and more specialized and narrow. People can no longer get by on general knowledge in their careers, something I found out for myself not too long ago. I'd been out of high school for two years, scraping by on my own and picking up scraps of programming as I went. I saw all of the self-taught programmers breaking into the IT industry, and I hoped to do the same. After all, IT is one of the few industries out there where being creative and a quick learner is more important than a degree.
Divider Line

Which is the Easiest Programming Language? - Programming LanguagesIf you have some misconception in mind that the programming languages are easy or hard, I am afraid to say that you are mistaken. To tell you frankly about the programming languages, there is nothing such as easy or tough programming language. The only thing that you need to keep in mind while stepping into the world of programming languages is that which programming language would set your base by giving you in-depth knowledge of programming logics and the basics of programming techniques.
Divider Line

Entering into Programming World - Good Luck ProgrammingOnce you have learned some programming languages, you feel yourself completely prepared to enter into the programming world, and start working on the programming languages that you have learned. Many students also feel that they have learned extra things which might be helpful in their programming careers. The matter of fact is that the real world is entirely different from what you have been taught in the classrooms.
Divider Line

Why Programmers Love the Night - Programming at night One famous saying says that programmers are machines that turn caffeine from coffee and Coca Cola into a programming code. And if you ask a programmer when does he like working the most and when is he most productive - he is probably going to say late at night or early in the morning, that is when he has the greatest energy and concentration to work.
Divider Line

How to be a Programmer - Programing training To be a good programmer is difficult and noble. The hardest part of making real a collective vision of a software project is dealing with one's coworkers and customers. Writing computer programs is important and takes great intelligence and skill. But it is really child's play compared to everything else that a good programmer must do to make a software system that succeeds for both the customer and myriad colleagues for whom she is partially responsible. In this essay I attempt to summarize as concisely as possible those things that I wish someone had explained to me when I was twenty-one.
Divider Line

TW Tech Glossary - Misplaced your bible? Well here it is - Tech Glosasary! This truly took a while to complete and should be used by all from beginners to advance techies.
Divider Line

Cobol Tutorial - Cobol TutorialAs always, TechiWarehouse writers take the reader into the world of COBOL from ground up. The emphasis is on the fundamentals of COBOL programming. COBOL is a high level programming language of the procedural type. That is, it is not a functional, logic-oriented or object-oriented language. It is used primarily in the implementation phase of software development, like most programming languages.
Divider Line

What Programming Language To Learn - Programming LanguagesOne of the most common questions we hear from individuals hoping to enter the IT industry is, "What programming languages do I need to know?" Obviously this is a complex question, and the answer will depend on what field the questioner is going into. Many programming languages are taught during courses used to obtain a computer information science degree. However, those already in IT know that the greatest skill you can have is to be a jack-of-all-trades. A well-prepared worker can switch between computer programming jobs with only minimal training, thanks to a wide knowledge of multiple programming languages.
Divider Line

What is COBOL?

Cobol stands for common business oriented language. Developed in the late 1950s and early 1960s, COBOL is the second-oldest high-level programming language (FORTRAN is the oldest). It is particularly popular for business applications that runs on large computers.

Programs written in COBOL tend to be much longer than the same programs written in other languages. This can be annoying when you program in COBOL, but the wordiness makes it easy to understand programs because everything is spelled out. Although disparaged by many programmers for being outdated, COBOL is still the most widely used programming language in the world.


Avoid defining print lines

You can make use of the STRING statement with pointer, to move data to any part of a print line. It may seem hard work initially, but is more flexible and easier to maintain than all those working storage lines. If the size of the data item is changed, there is no need to change the code.

The work of coding can be made easier by cut & paste or by using COBFORM's MACRO facility.

For example,


instead of


Don't forget to clear the print line first!


Debugging tips

  • Are you following your flowchart? Did you walk through the flowchart before writing the code?
  • Does the SELECT statement match the FD exactly?
  • Have you used the exact same spelling of each variable throughout the program?
  • Are there any missing periods?
  • Have you written the 88 condition names correctly?
  • Do you have numeric data in an alphanumeric field? Or vice versa?
  • Did you OPEN the file for INPUT, OUTPUT, or do you need to OPEN it for BOTH? Did you OPEN all files needed?
  • Did you MOVE the data before WRITING it?
  • Have you left off an END statement such as END-IF, END-EVALUATE, END-READ, END-DIVIDE?
  • Did you include an ON SIZE ERROR on the calculations, especially on the divisions? Remember: Never ever divide by 0!!
  • Did you remember the Order of Operations on the calculations? Have you left off a parenthesis that was needed?
  • Have you typed an "O" when it should have been a "0" (zero)??
  • Have you called a paragraph that doesn't exist - yet?
  • Did you READ the file and is your loop set up to continue reading records?
  • Remember: Read a file-- Write a record.
  • Have you cluttered your paragraphs with too many tasks? This makes testing modules very complicated! One paragraph = 1 task or 1 job.
  • Have you written RECURSION - when a paragraph keeps calling itself over and over and over? This will likely cause your program to blow up big-time.


Cobol with Embedded SQL

The following describes a prototype INMOD routine that loads rows directly from a DB2 table into Teradata. This poses some additional challenges.

  1. Write the Cobol program
  2. Precompile, compile, link-edit, and bind
  3. Run the FastLoad

Creating a DLL

You create a DLL by telling the linker that you want a DLL instead of an EXE format executable. If you want to create a dynamically loaded subroutine "a" (A.DLL), use:

-dll -out:a.dll -def:module-definition-file.DEF

instead of:


Module Definition Files

The -DEF parameter tells the linker to create an import library, which allows your program to call entry points in the DLL in addition to the external name of the DLL.

Let's say that the COBOL program that is being linked as a DLL contains this source code:


Import Libraries

An import library is used exactly the same as an object library. You can even create an import library for a DLL and use LIB to add object modules to it, just as you would with any other object library.

You link your executable as usual, including the import library in your list of object libraries.

At runtime, however, when your program attempts to call an entry that resides in a DLL, the operating system will use information from the import library that was linked into the executable to determine which DLL contains the desired entry point.

If the DLL is not loaded, the operating system will load it from disk and then pass control to it, exactly as it would if it were a statically called subroutine that was linked directly into your executable!

Efficiencies in Using DLLs and Import Libraries

If you're perceptive, it might occur to you this could be quite useful, because calls that access a DLL via an import library are coded exactly the same as static calls.

This could be quite useful in a large application, because unlike statically linked modules, which are copied into every EXE and DLL that refer to them, subroutines stored in a DLL and accessed via an import library are loaded only once, and shared between all of your programs.

The Module Definition File

You tell the linker which entry points are to be placed in the import library (exported) by listing them in a module definition file, which has the extension .DEF.

The module definition file is a simple ASCII text file that contains the name of the import library, an optional description, and the names of the entry points within the DLL that you want to make available in the import library.

Here's the module definition file a.def used to make the entry points A and B (which are called exports, or exported symbols) from our sample program above, available in a.lib.


The description is optional. So, the basic format of the link statement needed is:

LINK a.obj -dll -def:a.def ...

Other parameters will be required, of course, depending on your compiler.

This, by the way, is how we created GS32.LIB. It's just a simple import library that exports the symbols GS32 and GK_WINAPI. Here's the module definition we used to create GS32.DLL and the import library GS32.LIB distributed with GUI ScreenIO.


Linking your application

LINK: Creating Executables

So you've compiled your COBOL program and you have an object module that the compiler produced. Now what?

That object module is not in an executable form; it needs to be tweaked a bit so that Windows knows what to do with it when you launch it. That's where the linker comes in. You don't see it in your source code, but all COBOL programs call subroutines in the operating system and in your compiler's runtime support modules. They may also call subroutines that you explicitly CALL in your code.

The linker ensures that all of these subroutine calls are resolved when the executable module is generated. For our purposes, you can assume that the linker does this by merging the object modules of called subroutines into your executable module.

Where does the linker obtain these additional object modules? From object libraries, of course. Let's say that you have a main program A, that calls subroutines B and C (which you stored in your object library my.lib, of course), and that it uses GUI ScreenIO, so it also calls GS. Your LINK statement would look like this:

link a.obj /out:a.exe my.lib gs32.lib compiler.lib ..

This LINK statement says, "Link my object module a.obj as an executable named a.exe, and search the libraries my.lib, gs32.lib, and compiler.lib (in order) for any subroutines it uses. "Unresolved Externals?

If a called entry point is not found in any of the object modules stored in any of the object libraries named in your link statement, the linker will return a message saying there is an "unresolved external".

The most likely causes of an unresolved external are forgetting to include the library that contains the missing object module, or, if the module is one of yours, you forgot to include it in my.lib.

Efficiency Considerations

The linker will only include the modules from the object library that are needed by your executable, so it be as small as possible.

Suppose, on the other hand, you don't use object libraries and, instead, list the modules that the linker is supposed to bundle into your executable individually. The linker will incorporate all of the modules you named, regardless of whether they're used or not! This won't happen if you use an object library and let the linker determine which modules should be included in your executable.

Creating a DLL

If you want to create a dynamically loaded subroutine "a" (A.DLL), use:

-dll -out:a.dll -def:module-definition-file.DEFinstead of:-out:a.exe

Note: The -DEF parameter is used when you need to have the linker create an import library, which allows your program to call entry points in the DLL in addition to the external name of the DLL.

A discussion on creating DLLs is found here.

Other LINK Switches

There are a couple of other parameters you need to use with your linker. If you want Windows to treat your module as a native Windows executable, you need to include the switch:


If you don't include this, you'll find that a Command window will open whenever you launch your application.

Object Library Maintenance

Now that you've decided it makes sense to use object libraries, how do you go about creating and maintaining your own?

Easy, you use Microsoft LIB. Microsoft LIB is a program that is distributed with your compiler. Unfortunately, however, compiler vendors rarely provide much, if any, documentation on actually using LIB.

Fortunately, LIB is easy to use. You can get a list of instructions by giving the command "lib/h" at your command prompt. That yields this somewhat terse output, but it's all we really need:

Microsoft (R) Library Manager Version 5.12.8181
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

usage: LIB [options] [files]options:/CONVERT/DEBUGTYPE:CV/DEF[:filename]/EXPORT:symbol/EXTRACT:membername/INCLUDE:symbol/LIBPATH:dir/LIST[:filename]/MACHINE:{ALPHA|ARM|IX86|MIPS|MIPS16|MIPSR41XX|PPC|SH3|SH4}/NAME:filename/NODEFAULTLIB[:library]/NOLOGO/OUT:filename/REMOVE:membername/SUBSYSTEM:{NATIVE|WINDOWS|CONSOLE|WINDOWSCE|POSIX}[,#[.##]]/VERBOSE

Creating a new object libraryYou must create the library before you can use it. You can't create an empty library, so you need to add a module to it when you create it. In this example, we'll create the object library my.lib and store the object module a.obj in it.

LIB /out:my.lib a.obj

Simple, no?

Adding or updating a module in an existing object library

Now that we've created the library, it's trivial to update it. Let's add our object module b.obj to my.lib:

LIB my.lib b.obj

If b.obj was already present in my.lib, this will replace the original b.obj with the new one.

The rest of the commands are about as simple, but they're rarely used.

Static and Dynamic CALLs

Keep in mind as you read this, that some compilers let you set options that will override the calling mechanisms shown below. Therefore, even if your program is coded to call a program statically, the compiler can convert it to the dynamic form of CALL.

This is something to beware of, because it can cause problems for you if you don't understand the issues.

Static CALLs

In COBOL, you normally call a subroutine like this:

CALL 'A' USING arguments

The static form of the CALL statement specifies the name of the subroutine as a literal; e.g., it is in quotes.

This is the static form of a subroutine call. The compiler generates object code for this which will cause the linker to copy the object module a.obj into your executable when it is linked. So, if you modify "A" and recompile it, you must also relink all of the executables that call "A", because the each of the executables contains its own copy of "A".

Good Things About Static CALLs

Fewer files are needed to distribute your application because your application can be built into a single EXE file, or perhaps an EXE for your main, and a couple of DLLs for subordinate modules. This generally makes it simpler to distribute and/or upgrade your end users.

No risk of mixing/matching different versions of your called subroutines, because they are bundled into your main program.

Bad Things About Static CALLs

You must relink all of the EXE and DLL files in your application that use a statically linked subroutine in order to use the newer version of the subroutine.

If your application contains DLLs that call a subroutine statically, each DLL will have its own copy of the subroutine, including the storage defined in the subroutine. As a result, your application uses more storage than necessary.

If your application has multiple DLLs that use the same statically named subroutine, each DLL has its own copy of that subroutine and its storage. Therefore, if you set a value in the subroutine in one of the DLLs, it's local to that DLL. The copy linked to the other DLLs will not know about this. This can be either a Good Thing or a Bad Thing, of course, but it's definitely a trap for the unwary.

Dynamic CALLs

In COBOL, the dynamic form of a subroutine call is coded like this:


The dynamic form of the CALL statement specifies the name of the subroutine using a variable; the variable contains the name of the subroutine to be invoked.

The difference is that the name of the subroutine is found in the variable SUBROUTINE-A. The compiled code will cause the operating system to load the subroutine when it is required instead of incorporating it into the executable.

Good Things About Dynamic CALLs

You don't need to relink your application if you change something in your subroutine; only the subroutine DLL needs to be relinked.

All executables that call this subroutine will share the same DLL; both the code and data. Since your application only loads one copy of a dynamically called subroutine, it uses less memory.

Changes in values contained within the dynamically called subroutine are available to all the DLLs that use it, because they all share the same copy of the subroutine.

You can free memory that a dynamically called subroutine was using by CANCELing the subroutine. This is, however, not generally of much use in the 32-bit Windows virtual-memory environment, since Windows will 'page out' inactive data from the computer's real memory pool anyway.

Bad Things About Dynamic CALLs

Every dynamically called subroutine must be linked as a DLL. Therefore, if you application consists of hundreds of subroutines and they're all called dynamically, you will need to distribute hundreds of DLLs.

It's possible to mix versions of your DLLs. This can be a problem both with distributing your application and with end-users installing updates improperly.

If one of your DLLs is missing, you won't know about it until the user exercises some facility that tries to call that DLL. At that point, your application will terminate abnormally unless you handle this situation.

If you CALL a DLL, CANCEL it, then CALL it again, you incur more I/O because the routine needs to be reloaded if you CANCEL it. This can slow down an application because it requires more disk activity. Again, in the Windows environment this is usually unnecessary because Windows does an excellent job of managing memory.

If you mix and match static and dynamic calls to the same subroutine, your software might have several different versions in memory at once. Guess how much fun it will be trying to debug THAT mess?

Which is better, Static or Dynamic CALLs?

The answer is, it depends. Static subroutines are nice, because your application can be built into a single EXE file, or perhaps an EXE for your main, and a couple of DLLs for subordinate modules. Dynamic subroutines are nice because you can manage memory differently and you can update a portion of your application by shipping a newer DLL instead of the entire application.

You really need to consider the pros and cons and how they affect your own application. For what it's worth, though, we favor using a minimum of executable modules because it reduces headaches with mismatched or lost pieces of an application.

Dynamic CALLs via an Import Library

It's possible to create a DLL that contains many subroutines, but which is accessed as though the subroutines are statically linked. This is a very neat trick that uses the best features of static and dynamic linking.

Make it easier to print numeric data

Keep a COBYLIB member full of standard edited numeric items. I like to use names such as WS-S7V2 for a signed item with 2 dec places:

01 WS-S7V2 PIC --,---,--9.99

You can then use COBFORM's MACRO facility to define a macro called MOVNUM:


instead of


Did You Know?

  • By many Y2K dooms day believers, COBOL was going to be terminated after the year 2000. And few of those believers are still teaching COBOL at local community colleges to this day.

  • 75% of the world's business data is in COBOL.

  • There are between 180 billion and 200 billion lines of COBOL code in use worldwide.

  • 15% of all new applications (5 billion lines) through 2005 will be in COBOL.

  • CICS transaction volume (such as COBOL-based ATM transactions) grew from 20 billion per day in 1998 to 30 billion per day in 2002.

  • Replacement costs for COBOL systems, estimated at $25 per line, are in the hundreds of billions of dollars.

  • There are 90,000 COBOL programmers in North America in 2002. Over the next four years there will be a 13% decrease in their number due to retirement and death.

  • There are at least 10,000 "Free Agent" COBOL programmers in the US today.

  • The most highly paid programmers in the next ten years are going to be COBOL programmers.

  • Any programmer with above average skills in COBOL can quickly learn the basics of Web Enabling, at home, through self-training.

  • COBOL programmers could be the key to new IT. The legions of COBOL programmers who helped organizations get legacy applications ready for Y2K could find new work bringing those applications into the Internet age.

Partners Links
- COBOL Reference and Examples