I date my career as a programmer/analyst from 1975. However, I was actually employed in 1974 as a programmer/analyst writing COBOL and RPG programs for an insurance company and university administration on an IBM 360/40 running DOS (release 26).
In 1989 I took a break from programming to open and operate an independent bookstore for a couple of years. Subsequently I have been involved in contract programming assignments. Eventually I would like to return to programming on a full-time, employment basis.
For anyone who is interested in seeing
my formal resume, I have included it
here:
I am currently living in Abilene, Texas, and continue to look for an opportunity for me to return to full-time employment in a mainframe environment.
If you wish to see some examples of my COBOL and Assembler programs, continue reading below on this page. There are also some source programs (mostly Assembler at this time), JCL and procedure documentation on my Micro Mainframe page here on this site.
In 1999 I moved to Charlotte, North Carolina. I was seeking a change of weather climate, having lived in Texas all of my life, but I was also hoping that I would be able to return to full-time employment as a Programmer/Analyst with one of the banks that have their headquarters in Charlotte. Little did I know that the timing of my move would coincide with massive layoffs by First Union and a hiring moratorium at Bank of America as a result of the NationsBank/Bank of America merger.
I never sit around idle, so I became involved with several social and service organizations, the most significant of them was serving as a volunteer with the Charlotte Gay and Lesbian Switchboard. They had a real need for an upgraded database query program for use by their telephone operators to field calls for referrals. The solution they had been using for several years was a dBase program that was incredibly slow due to the inefficient design of the query program. In addition to the need to speed up the access, there was a desire to incorporate some new features into the indexing scheme that the dBase design just would not accommodate. I decided that a COBOL solution offered the needed speed and kept the resulting program simple and straightforward. Also, there was a fairly strict memory constraint as the program would be implemented on relatively old "AT" microcomputers running an older version of MS-DOS. There was no funding available to upgrade either the hardware or system software, and the switchboard wanted to make the upgrade as simple and as transparent to the volunteer users as possible. To fit the memory constraints, I divided the logical functions up and implemented them in separate modules to be called by a central module that maintained security and kept track of time logged onto the system by each volunteer operator. This proved useful because as the development progressed it became obvious that there was need for some additional reporting after the initial design. The modular design allowed new reports to be easily added into the structure. To view any of the programs in this system, click on the program name below:
In addition to writing, installing and testing the programs, I wrote a 65 page user manual which includes screen snapshots of all user screens and sample pages of all reports. The manual is available here as an Adobe Acrobat PDF file: In 1998 I, along with most of the rest of the world, was thinking about the approach of the year 2000 and the implications that held for incompatible two digit years. I brought together some routines I had written earlier in several languages (COBOL, BASIC, and Assembler) and the result was this group of Assembler subroutines that can be used to perform any required date format conversion:
In order to test these routines, I wrote a very simple COBOL driver program to read a series of card images to invoke a specific routine with the data appropriate to that routine, sometimes containing errors to test error detection logic. After the routine is called the input data and the output from the routine is printed. If you would like to see that report, use the following link: For several financial applications I had written in the past, I required a date record to be provided from which interest would be calculated either from the prior run date to the current run date or from the current run date forward to the next run date. I wrote a program that utilized the date routines above to derive such a date record using the current system date and a file of rules to specify the observed holidays:
In addition to the date routines, I wrote a COBOL program to scan source code for likely date references. The program is based upon the design of a BASIC program that was placed in the public domain by the National Institute of Standards. The program is driven by a glossary table read in at run time. In 1998, as I began readying for a move from Abilene, I came upon the archive ZIP disks that contained all of the sales detail records from Books Etc. I decided that it would be interesting to have all of the sales history consolidated into a single file and be able to extract reports from these records. So I wrote this program to process the sales history records and produce the desired report based upon a run-time parameter: Over the course of several years of designing and writing CICS programs, I built up a small collection of subroutines, written in 370 Assembler, that I used to perform editing on input fields and formatting on output fields. The original versions were not re-entrant, as they used internal variables to store intermediate information. After I closed Books Etc in 1992, I had the time to devote to "cleaning up" these routines to make them uniformly consistent with each other and totally re-entrant.
In order to test these routines, I wrote a very simple COBOL driver program to read a series of card images to invoke a specific routine with the data appropriate to that routine, sometimes containing errors to test error detection logic. After the routine is called the input data and the output from the routine is printed. If you would like to see that report, use the following link: Have you ever needed to figure out the amount of time that has elapsed between a couple of dates? I frequently need to do this and it isn't something I enjoy "tallying" up using my fingers. Back in 1997 I wrote a C++ program to do the computation for me. I was sort of curious to see how difficult it would be to write in COBOL and I also wanted to make the output a bit more polished. The result is this small "main" program with an embedded subprogram to process the command line parameter. I use a call to the Y2KLAGE subprogram to actually compute the period between the dates. Naturally, the most complex part of the problem is isolating and validating the input parameter(s), so the most significant portion of the program is the nested subprogram 'GETPARM'. If you want to execute the program, you can download the compiled executable. It may be run from a DOS window under Windows 95/98/NT/2K. It may also be run under a DOS window under OS/2. Of course, it will also run just fine under MS/PC-DOS. If you execute the program without any parameter it will display the parameter syntax. Although I will probably never be interested in returning to programming in RPG, I was recently encouraged to write an introductory tutorial for RPG I. When I went to find answers to some questions I had (after all, it has been 20 years since I last wrote any production RPG programs), I was amazed at how little information there is available on RPG. So, if you are interested in looking at my tutorial, it is available at this link: RPG Tutorial. I recently needed to sort some elements of a table and when I went looking for something a bit better than the bubble sort I used the last time I needed to do this, I found out about a newer sort algorithm, the comb sort. It is an extended bubble sort that performs better and is very simple to implement. If you want to look at how I implemented it in COBOL, here is the program I used to write, test, and time it: The test program will sort 1,000 elements on a ten byte alphanumberic key in less than one second. This is much better performance than the last time I used a bubble sort to order a table in a C.I.C.S. program. In November/December, 2001, I wrote a couple of Assembler routines to allow programs written in COBOL and PL/1 access to VSAM clusters. Why would that even be necessary, I suspect you are thinking. Well, under Hercules, the latest compilers people have legal access to are those from around 1972, and those early compilers lacked any native access to VSAM objects. With these two routines, some fairly sophisticated programs can be written using these vintage compilers. The PL/1 routine is simply a "wrapper" to verify the parameters received, and it then makes an intermediate call to the COBOL routine. Detailed instructions for using the routines may be read at vscobol and vspl1. A short time later, I decided that the amount of interest dictated the need for a VSAM tutorial, partly because of the tremendous (global!) reception my RPG tutorial had generated, so I wrote what evolved into a short course on VSAM and IDCAMS, complete with a wealth of sample job streams. It can be viewed at vstutor. This page was last modified on January 30, 2015. |