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!
Oh great, how did you do this, what language?
A good friend of mine had a question to me today. He had a simple text file with blocks of various number of lines that he would like to be sorted by a string identifiable in each blocks header line.
The file itself was about 22,000 lines, to much for manual sorting. He asked me if I would have an idea for a tool or software like Textpad to do this job.
I just told him I can make this happen in an hour and then he can check results and if it fulfils his requirements. We agreed to this.
After just 15 minutes I sent the file back to him. He tested quickly and figured out it still has some curious things like
While I am writing the friend is keen to get the information on how I did this. He is a real good programmer; he has all the tools I am having. But sometimes it is really beneficial to think about the good old tools that you have somewhere around. Yes, we have text files, but this must not require modern tools like Textpad to handle such files efficiently.
I used a simple 120 lines COBOL code and a small JCL to run the job. 105 of the lines were just COPY & PASTE and the rest was quickly typed in. The JCL was copied and only the file names had to be added. With some tricks we probably can write the same COBOL code in less then 50 lines. It would still do the same damned good job but it would not look that easy it is looking right now.
The CODE:
###############################################################################
###############################################################################
###############################################################################
******************************************************************
* *
* I D E N T I F I C A T I O N DIVISON *
* *
******************************************************************
IDENTIFICATION DIVISION.
PROGRAM-ID. TstSRT04.
******************************************************************
* *
* E N V I R O N M E N T DIVISON *
* *
******************************************************************
ENVIRONMENT DIVISION.
******************************************************************
* C O N F I G U R A T I O N SECTION *
******************************************************************
CONFIGURATION SECTION.
SPECIAL-NAMES.
DECIMAL-POINT is COMMA.
/*****************************************************************
* I N P U T - O U T P U T SECTION *
******************************************************************
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT I1
ASSIGN TO I1
ORGANIZATION IS SEQUENTIAL SARF
FILE STATUS IS STAT.
SELECT O1
ASSIGN TO O1
ORGANIZATION IS SEQUENTIAL SARF
FILE STATUS IS STAT.
SELECT S1
ASSIGN TO S1
FILE STATUS IS STAT.
/
******************************************************************
* *
* D A T A DIVISON *
* *
******************************************************************
DATA DIVISION.
******************************************************************
* F I L E SECTION *
******************************************************************
FILE SECTION.
FD I1.
01 I1Rec PIC X(500).
FD O1.
01 O1Rec PIC X(500).
SD S1.
01 S1Rec.
05 S1Key.
10 S1KeyID PIC X(100).
10 S1KeyCnt PIC 9(010).
05 S1Data PIC X(500).
******************************************************************
* W O R K I N G - S T O R A G E SECTION *
******************************************************************
WORKING-STORAGE SECTION.
01 WorkFlds.
05 wSrtKeyID PIC X(100).
05 wSrtKeyCnt PIC 9(010).
05 tLgI PIC 9(004) COMP-5.
******************************************************************
* global workfields used anywhere in the pgm *
******************************************************************
05 STAT PIC X(002).
******************************************************************
* *
* P R O C E D U R E DIVISON *
* *
******************************************************************
PROCEDURE DIVISION.
******************************************************************
* A - M a i n SECTION *
******************************************************************
A-Main SECTION.
PERFORM C-Sort1
STOP RUN
.
C-Sort1 SECTION.
OPEN INPUT I1
OPEN OUTPUT O1
MOVE LOW-VALUE TO wSrtKeyID
MOVE ZERO TO wSrtKeyCnt
SORT S1 ascending key S1Key
INPUT PROCEDURE IPROC
OUTPUT PROCEDURE OPROC
CLOSE I1
CLOSE O1
.
IPROC SECTION.
IPROC-Loop.
READ I1 next
at end EXIT SECTION
end-read
IF I1Rec(01:17) = "/****** Object: "
MOVE I1Rec(18:) TO wSrtKeyID
MOVE ZERO TO wSrtKeyCnt
MOVE length of wSrtKeyID TO tLgI
CALL "YUCASE01" using wSrtKeyID, tLgI
end-if
ADD 1 TO wSrtKeyCnt
MOVE wSrtKeyID TO S1KeyId
MOVE wSrtKeyCnt TO S1KeyCnt
MOVE I1Rec TO S1Data
RELEASE S1Rec
GO IPROC-Loop
.
OPROC SECTION.
OPROC-Loop.
RETURN S1
at end EXIT SECTION
end-return
MOVE S1Data TO O1Rec
WRITE O1Rec
GO OPROC-Loop
.
*-eof-*
###############################################################################
###############################################################################
###############################################################################
THE JOB CONTROL:
###############################################################################
###############################################################################
###############################################################################
stp TSTSRT04;
asg I1 C:\TEMP\SPS_TABLES_082311_NOTSORTED.TXT;
asg O1 C:\TEMP\SPS_TABLES_082311_SORTED.TXT;
def O1 StripSpace=Yes;
endstep;
done:
*eof
###############################################################################
###############################################################################
###############################################################################
The JOB EXECUTION:
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
Job ran in less then a second to sort all the blocks in the 22,000 lines.
COBOL can help you always. Just have the right ideas. And of course, you should have these at the right times. 🙂
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:
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:
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.
A complete GDT v5.1 / Net Express 5.1 environment including GDT_ODS / GDT_ETL / EYESYS ENTERPRISE is up and running on Windows 7 64 bit platform.
This took some time going from 32 bit to 64 bit environment but we are up and running!
I ran into some issues with 32bit .exe’s (GDT_ETL, GDT_ODS), getting them to run in 64 bit environment, but the corflags command under Visual Studio 2008 command prompt started as administrator fixed this issue.
Also, had to install IIS 7.5 and make sure all features under Application Development Features (when you run Programs and Features) are installed.
Creating a veirtual directory in IIS was a little tricky because the default website was using port 80 which was being used by SKYPE. Stopping SKYPE resolved this issue and thinclient session via eyesys started fine.
I learned alot about the Win 7 environment by getting this environment set up.
Based on a 2006 article I read, the following were responses to a survey conducted:
What programming languages do you use in your organization? Top 2 answers Visual Basic 67% COBOL 62%
If you don’t use Cobol, why not? Top 2 answers COBOL is an outdated language 55%, COBOL is an inferior language to other languages 34%
If your organization uses Cobol, how much internally developed business application software is written in Cobol? 43% say more than 60%, 16% say they are in the range of 31% – 50%
58% say they are using COBOL to develop new business applications.
What would the answers be today, 5 years later..2011?
My prediction would be the following:
For question #1, I would say it would be pretty close to the same. Based on the customer base I work with VB.NET seems to be a direction taken to migrate away from COBOL. This can and has shown to be a difficult and slow transition due to understanding the business rules of your COBOL applications and migration of data to a relational database. COBOL still remains a strong language with these companies. What could make these transitions easier?
For question #2, I think even though the top 2 responses from 2006 are probably way up there today, another one sneaking its way up is the fact that companies are losing their COBOL expertise due to retirement and are finding it quite difficult to replace that expertise. Is there a solution to this?
For questions #3 & #4, I think the same responses still hold true today!
So has time changed the way we view COBOL?
So has time changed the way we use COBOL?