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:

Resumè of Jay Moseley, CCP

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:

ROLODEX.CBL Main control/security
ROLODEX0.CBL Year end housekeeping
ROLODEXA.CBL Security maintenance
ROLODEXB.CBL Security record report
ROLODEXC.CBL Keyword set maintenance
ROLODEXD.CBL Database maintenance
ROLODEXE.CBL Cross-reference key list
ROLODEXF.CBL Import into database
ROLODEXG.CBL Database contents list
ROLODEXH.CBL Database query
ROLODEXI.CBL Export from database
ROLODEXJ.CBL Export from security file
ROLODEXK.CBL Rolodex contents dump
ROLODEXL.CBL Calendar rule maintenance
ROLODEXM.CBL Calendar rule list
ROLODEXN.CBL Calendar query
ROLODEXO.CBL Volunteer name list
ROLOFD01.CPY Security record copy book
ROLOFD02.CPY Database record copy book
ROLOFD03.CPY Cross-reference record copy book
ROLOFD04.CPY Calendar rule record copy book

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:

Rolodex manual

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:

Y2KATOG.ALC Astronomical number to Gregorian
Y2KCONV.ALC 2 digit year to 4 digit year - various formats
Y2KDFMT.ALC Gregorian date to various output formats
Y2KDOWN.ALC Day of week number for Gregorian date
Y2KESTR.ALC Easter date for given year
Y2KGETD.ALC Return system date in various formats
Y2KGTOA.ALC Gregorian to astronomical number
Y2KGTOJ.ALC Gregorian to Julian (day of year)
Y2KJTOG.ALC Julian (day of year) to Gregorian
Y2KLAGE.ALC Large span age between Gregorian dates
Y2KLEAP.ALC Determines if given year is a leap year
Y2KPROJ.ALC Derives target date forward/back from given date
Y2KSAGE.ALC Small span age between Gregorian dates
Y2KTDOW.ALC Derives target date for given date and day of week

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:

RUNDATES.CBL Program to build run dates record
RUNDATES.CPY Copy book for run dates record

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.

IFMTFILL.ALC Scans an input field to verify that all character positions are filled (no leading, trailing, or embedded blanks).
IFMTFLPT.ALC Scans an input field containing a floating point numeric value.  The numeric value is extracted into a COBOL PICTURE S9(11)V9(7) field.
IFMTHEX.ALC Accepts an input field containing the character representation of hex digits and outputs the equivalent hex field.
IFMTLJST.ALC Left justifies the non-blank characters in an input field.
IFMTMASK.ALC Scans an input field and verifies the characters against a mask field.  Characters are extracted from the input field to an output field based upon the mask.
IFMTNIB.ALC Scans in input field to verify that there are no embedded blanks in the data contained in the field.
OFMTHEX.ALC Converts the hex value of the input field into the corresponding character based representation.
OFMTMONY.ALC Generates written words representing the numeric value contained in the input field.

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.