Have you ever wanted your COBOL program to talk to you?
Have you had a need to have your COBOL programs “Tell” your computer operator’s that there was a problem during execution.
Have you had a need to have your COBOL programs talk to help the visual impaired?
See how easy it is to code a call to “Speech” software by clicking on the following video link.
Adding Voice to your COBOL Application
If you are interested in learning more about this please reply to this post. More COBOL fun to come!
This week I was talking to the Assistant of a General Manager at a not so small company.
Generally there were some questions regarding COBOL, SOA, BPEL and WebServices and how to get there. While talking about this and that we came to a point where I was talking about some work I did in the past weeks.
For their development environment we change the Visual Source Safe checkin methodology from a manual to an automated way. Production still runs on a BULL coupled system and another machine is type of integration. Parallel to this there is another production environment on the Windows side as well as an Integration. And not to forget about the Development on the Windows side. Once Sources are checked out from VSS it will reside on the developers local machine and once checked in the source will get write-protected on the local machine. But there was manual process to push sources to the two different Integrations as well as the two Production environments. Wherever human action is in place there is a small hole (or a big one?) for failures or simple immediate requirements. Over the last several years there were many sources, copies or programs, not synchronized causing potential issues in future. Now, I wrote a couple programs to control the push of sources. Instead checkin in manually there are now defined procedures to follow. Source must go to Mainframe Integration and being compiled there for use on the integration. At the same time another automated process will make sure sources are also pushed to the Windows Integration machine. No interaction required. Then, after the departments tested they have to use one command on the Mainframe production to move the sources to the Mainframe production and once successfully compiled the sources will pushed to the Windows Production and from there another process will pick up everything and automatically checkin the sources into the VSS database. It is doing so with the credentials of the user who originally checked the sources out from VSS!. To be able to do this the developers had once to provide there password and save it somewhere. There is a program that uses WinZip or WinRar to pick up the password and crypt it, the crypted string is then stored in file and converted back at the time we need to connect into VSS.
The question from the Assistant was: What language did you use to write all these processes like watching for files in directories, manipulating these in binary formats. How to interrogate with VSS? is this C++ or Java? How do the Processes on the Mainframe work?
My simple answer to all the questions! I used COBOL.
Remember at the beginning, sources on the local drive get their write protection with the manual process. Now, we checkin from the Production Windows Machine. There is no way to get back to the Developers machine. I’m blogging about it when it’s in place. In the meantime you can guess a bit about what language this can be written in? And guess about what problems may arise and how to get around these. Spread your mind.
The COBOL Kid
Managing COBOL legacy systems
Part 1 – migrations
Have you ever worked on a COBOL mainframe migrations to a server platform, or about to consider one? While working as a technical manager providing COBOL solutions for my customer base, it was obvious that there was a need for me and the customer to gain a better understanding of their COBOL source repository. For our migration, we needed a complete inventory – data files mapped and JCL hierarchies, and also extract business rules and produce flowcharts, but when I looked around for tools on the market that could provide some of these needs, they usually fell in one or all of the following categories:
- Too Expensive to license
- Difficult to work with
- Did not exactly provide what was needed
Frustrated I couldn’t meet my needs from an existing product, working with my team of experienced COBOL and VB programmers we came up with a generic platform independent COBOL portfolio analysis tool that works on a laptop. This tool functions seamlessly in the work place, and provides just about everything we needed:
- Data Maps
- File usage
- JCL hierarchies
- Business rules
We even got the tool to include business rules in the flowcharts, and with client input the tool is constantly evolving. Now, when I work on COBOL migrations at a customer site, I load up my laptop with the customer inventory and use the tool to map out a portfolio analysis to help guide the process.
If anyone else has needed to manage their COBOL legacy systems and has looked for a similar tool to assist, let me know your thoughts, I’d be happy to discuss issues and resolutions with you.