Hopefully, I can keep this project alive long enough to produce something useful…

COBOL was originally designed when a single program was a single piece of source.  However, it has for almost as long been able to split that source up into modules by using the CALL verb to get one source to use another.  Let’s see how we get Tiny COBOL to build us one executable from a couple of pieces of source.

First, here’s the 2 source files in question.

 *main.cob
 IDENTIFICATION DIVISION.
 PROGRAM-ID. MAIN.
 AUTHOR.  MARK HOPKINS.
 DATE-WRITTEN. 21 November, 2008.
 ENVIRONMENT DIVISION.
 DATA DIVISION.
 WORKING-STORAGE SECTION.
 01  MSG   PIC X(65).
 PROCEDURE DIVISION.
   MOVE "Hello, World!" TO MSG.
   CALL "MSGDISP" USING MSG.
   STOP RUN.

*msgdisp.cob
 IDENTIFICATION DIVISION.
 PROGRAM-ID. MSGDISP.
 AUTHOR.  MARK HOPKINS.
 DATE-WRITTEN. 21 November, 2008.
 ENVIRONMENT DIVISION.
 DATA DIVISION.
 LINKAGE SECTION.
 01  MSG   PIC X(65).
 PROCEDURE DIVISION USING MSG.
   DISPLAY MSG.
   EXIT PROGRAM.

First, let’s get them compiled up.  I tried this…

$ htcobol -o hello2 main.cob msgdisp.cob
Invalid number of input parameters

Seems htcobol compiles one source at a time, so we need to compile each one up to object format then link them manually.  Okay here goes nothing.

$ htcobol -c main.cob
$ htcobol -c msgdisp.cob

Now to get the two things joined together.  To figure this out I used the -n option of htcobol which prints out all the commands that will be executed but will not actually do anything.  I ran it against the single source “Hello, World!” example from last time and got this.

$ htcobol hello.cob -n
Pre-processing 'hello.cob' into 'hello.i'
as -o hello.o hello.s
gcc -o hello hello.o -L/usr/local/lib -lhtcobol -ldl -ldb -lncurses -lm

From that I then ran this

$ gcc -o hello2 main.o msgdisp.o -L/usr/local/lib -lhtcobol -ldl -ldb -lncurses -lm

And hey presto we have an executable that when run gives our wonderful “Hello, World!” message.

$ ./hello2
Hello, World!

So we now have a way of modularising our COBOL code we may even be able to produce something useful.

Firstly, the COBOL code itself…

 IDENTIFICATION DIVISION.
 PROGRAM-ID. HELLO.
 AUTHOR.  MARK HOPKINS.
 DATE-WRITTEN. 21 November, 2008.
 ENVIRONMENT DIVISION.
 DATA DIVISION.
 PROCEDURE DIVISION.
   DISPLAY "Hello, World!".
   STOP RUN.

Nice and simple, some would say overly verbose, but that’s a debate for another day.  Now on to compiling it.

Tiny COBOL provides a compiler htcobol which is invoked as follows to compile the above sample to an executable file.

htcobol hello.cob

This will produce an executable called hello which when run gives the following output.

Hello, World!

Nice!  Right, one thing that I’ve done in the past when working on COBOL software professionally is to build the executable with the RTS (run time system) statically linked into the executable.  It means the executable is larger than it has to be but then there is no need to provide the RTS, in this case libhtcobol.so, separately; nor do we have to ensure it’s in the correct path come runtime.  So how to do that with TinyCOBOL…

Looking at the htcobol man page seems to suggest the -Bmode is the way to do it (where mode is either static or dynamic) so here goes.

$ htcobol -Bstatic hello.cob
/usr/bin/ld: cannot find -lhtcobol
collect2: ld returned 1 exit status

Oops.  Seems it can’t find the RTS.  But if I run the program it works fine.  Um, perhaps another option, let’s try again.

$ htcobol -Bstatic -L/usr/local/lib hello.cob
/usr/bin/ld: cannot find -lhtcobol
collect2: ld returned 1 exit status

Same again.  As it is the ld command that seems to be complaining maybe a different option.  Doing another man suggests we can get htcobol to pass parameters through to the linker.  Okay, here goes…

$ htcobol -Bstatic -Wl,-L/usr/local/lib hello.cob
/usr/bin/ld: cannot find -lhtcobol
collect2: ld returned 1 exit status

Oh no, not again.  Looking at the man page for ld seems to suggest that I need to specify the directory to the -L option where the ‘archive library’ resides.  I gave it /usr/local/lib which is where the shared object sits, so try again.

$ htcobol -Bstatic -L/home/mark/work/tinycobol-0.64/lib hello.cob
... LOTS OF ERRORS ...

Double oops!  Lots of errors reported time for more Googling…

Oh well, no luck there.  I shall have to come back to that at another time.  I am disappointed I couldn’t get it to work but hey it ain’t the end of the world…

I have been using various text editors on various platforms for the last couple of years, Crimson Editor on Windows and various Gnome editors on Ubuntu Linux, but my background in COBOL programming on Unix means I am comfortable with VI.

The first job was to install VIM and this was simply a case of downloading the latest release, 7.2, and running the installer. Having read certain other blogs and the like that indicate path names with spaces are bad for VIM I always install into either c:\opt\vim or c:\programs\vim (on Vista).

Once installed, run it up and we have VIM in a GUI in all its glory. Now on to settings. Following Jamis’ lead I have the following .vimrc file.

" Turn on line numbering by default
set number
" Show ruler line - to display line and column position of cursor
set ruler
" Syntax highlighting and file type stuff
syntax on
filetype on
" Allow buffer switching without the need to save
set hidden

I then look at editing certain different files to see if syntax highlighting is truely working. The only one where I found an issue was with a Pro*COBOL source file with a .pco extension so a few googles later and I ended up creating myself a filetype.vim file in my %USERPRIFILE%\vimfiles directory which contained this.

augroup filetypedetect
au BufNewFile,BufRead *.pco setf cobol
augroup END

I’ve not gone through all of Jamis’ settings yet to see if I want to use any of them but my usage of VIM has only just started. Stay tuned and I may let you in on how it goes…

Firstly, to save cluttering up my Windows Vista machine with *nix emulation layers such as MinGW I use virtualisation courtesy of VirtualBox and run an Ubuntu instance atop Vista.

After downloading the 0.64 source zip file and unpacking inside my home directory I set about building and installing it.  Basically, this mean’t running ./configure, installing any missing software, rinse and repeat until complete.  I can’t remember the entire list but for each of the following I did a sudo apt-get install <missing package>

1. flex
2. libncurses5-dev
3. db4.6-util
4. libdb4.6-dev

Once the configure was complete a very quick make was followed by an equally quick sudo make install followed by a period of confusion as I couldn’t get a simple program to compile.  Each time I compiled the program I kept getting.

/usr/bin/ld: cannot find -lhtcobol
collect2: ld returned 1 exit status

After some searching for the htcobol shared library I found that it hadn’t been installed. It had been built in …/tinycobol-0.64/lib, but not installed. So after looking at the make file within the lib directory I found that a sudo make install-shared-libs within the lib directory solved the issue.

More on COBOL and my hope to prove Agile Development techniques are not just for Object Oriented languages, later…

I don’t know about you but I will admit to being lazy when it comes to testing.  I love pounding code but hate it when I have to stop mid-session to test the thing I’ve just changed.  Some would argue that is what programming is all about, but I for one find it difficult to stop coding to run a set of manual tests.  Even stopping to run automated tests where the setup takes 10 minutes, and the testing takes 20 minutes, is a waste of my time.  I want to be able to punch a button and see a progress bar shoot across all green, so I can continue.  If it actually goes red (when I don’t expect it to) then if it’s been only minutes since my last green bar I can quickly figure out why.

As professional programmers our superiors and/or customers expect that we can mould the code into whatever shape we, or more rightly they as it’s they that pay us to do it, want it to be.  As professional programmers we can only do this if we are fearless of change, and yes, you guessed it, we can only do this if we have the safety net of a comprehensive test suite at our disposal.

Being fearless of change and having a comprehensive test suite in place go hand in hand and it is up to us, as professional programmers, to ensure we can change the software to meet our customers needs.

As it is ultimately the customers who pay our wages it isn’t unreasonable for them to expect us to be professional…

To address this issue I have started a new project over on SourceForge called Refactor FIT which is intended to provide automated refactoring tools for the contents of the HTML FIT test pages.  To begin with their won’t be a GUI interface but I do intend to provide scripting capabilities probably based around Groovy.

I shall be blogging more about this in the future…

Stay tuned and we’ll see exactly how this thing takes shape…