Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this questionI'm working as a COBOL programmer - have a 6 months work experience - for a consulting firm . Today, with the rest the COBOL "department", I had a meeting with the new director of my company.
After an initial analysis made by the new team in charge, they noticed that, comparing to the other services/technologies our company has to offer - Java, C++, Objective-C, etc - COBOL was lacking "advertisement". He stated that whenever members of other teams are in-between projects they implement small demos which then can be shown to our clients whenever there is a presentation of our company. He gave examples of widgets for mobile devices in Objective-C, cool web-pages with HTML5, etc. And noticed that there is nothing in COBOL like that. So he wants us to develop some kind of tool/app to show what our competences.
We already told him that COBOL is used under the hood, and doesn't have bells and whistles to show. Also that when hiring a COBOL programmer/analyst the most important for the client is that he shows he has "business logic" knowledge.
I know that the coding part is very important but after a two weeks introduction to the mainframe environment and to COBOL I was capable of doing my programming tasks easily. But with a 6 months experience working in a bank I find myself having to, nearly everyday, ask questions regarding "business logic" to the "gurus" just so that I don't end up changing the logic of the process when performing some maintenance task.
Can we really make something (tool/app) that shows or future clients that we have something different to offer than all the other company's which provide the same services? Or if not, is there anything that we can say to our manager so that he understands that COBOL is different from t开发者_Go百科he other languages and it's purpose is not to display pretty graphics on the screen.
Thank you!
I think you're absolutely right - the "curly brace" languages have had a lot of marketing of the brand from IBM , Oracle/Sun and Microsoft over the last 20 years.
Micro Focus is trying to do something about this. They just relaunched www.cobol.com which includes a nice set of video testimonial to the power of COBOL.
There's a great video available showing some of the demos Micro Focus built as part of the development of the soon to be released "Visual COBOL R3" product. These demos include web services, rich browser-based clients, parallel processing and more (they aren't all shown in the video). Micro Focus will shortly be launching new resources for COBOL developers that will include these samples.
COBOL gets a bad rap in large part because there is the conception that it's outdated and unable to communicate with modern systems. A lot of people think that using COBOL "locks you in," unable to get data from other systems, push data to other systems, or call code that's written in other languages.
Potential clients would be very interested to know that, if they went with your COBOL solution, they could still share data with the rest of the world. I think you could build some compelling demos showing COBOL applications interacting with Web APIs or with code written in C++, Objective-C, etc. Two possibilities:
1) A simple program that submits a query to Google's search API and displays the returned results. This will show that you can issue HTTP requests and parse the responses.
2) A program that gathers data from a custom database and passes that data to a C++ function that somehow grinds up the data and returns a result. This will show that you can use COBOL's data handling strength and pass off to C++ or some other language the more processor-intensive calculation tasks that COBOL traditionally has not been as good at.
I think that's your biggest selling point: that you use COBOL for its strengths, that you're able to share data with the rest of the world, and your COBOL programs can leverage other tools for specific tasks that are not COBOL's primary function.
Having a slick demo in your back pocket to show (snow) clients is kind of like selling sizzle not the steak. Demo applications may illustrate how skillfully your staff can knock off a relatively light-weight problem with a lot of flair. But COBOL is less about sizzle and more about the steak - a marketing nightmare if style is emphasized over content.
Basically, a hot demo illustrates to clients that you have some imagination, know how to write code within a given framework that integrates various services. Undeniably these are all good selling points.
But COBOL applications don't make for great demos. Most clients running large COBOL shops already know this. It is unlikely they would be impressed by a demo - unless it addressed some specific point of interest to them. From my 20+ years experience as a contract COBOL programmer, I can say my clients are mostly interested in a solid resume backed up with solid references that illustrate a depth of experience in specific application domains (eg. accounting, human resources, inventory management, and the like).
A solid company portfolio is probably more important than a demo. A few things you might want to outline are:
- Type of businesses that you have supplied resources to (banking, finance, government, retail).
- Range of technologies, middleware and frameworks employed on given projects (eg. CICS, MQ-Series, DB/2, WebSphere, FTP, XML, RD/z, SAP, SAS etc.)
- Nature of skills provided to past clients (eg. programmers, technical analysts, business analysts, DBA, capacity planning, security analysts, data modeling, architect, project managers etc.)
- Other than "putting bums in seats", point to any added value your company brought to these projects (eg. found a no-cost optimization that reduced a clients batch schedule by 2 hours).
- Put together a project case history to show how your company was able to do something special and different for a client.
- Point to any technologies, frameworks or application domains where you feel your company has some sort of competitive advantage over the "other guys".
Try to address questions your prospective clients may have about you. Big COBOL shops have their own way of doing things. They often use a similar set of tools, but they all seem to have their own peculiar way of integrating them. They don't want some contractor coming in to rock their boat. But you can impress them by showing that your "guys" bring clear thinking, solid skills and a strong work ethic into the projects they have participated in.
Above all, make the most of what you have accomplished but never over state or fluff up your abilities beyond the absolute truth. If a client ever catches a whiff of BS from anything you present, they will be out the door before you can blink.
This is a late entry, but I had some fun linking OpenCOBOL WORKING-STORAGE data to CERN's ROOT/CINT framework. CINT is a way cool C/C++ interpreter, ROOT is the framework for visual analysis of particle collider and high energy physics datums. Interactive charts and graphs from COBOL working store.
A small example:
OCOBOL >>SOURCE FORMAT IS FIXED
*> ***************************************************************
*> Author: Brian Tiffin
*> Date: 20101119
*> Purpose: Pass arguments to ROOT/CINT invoked subprograms
*> Tectonics: cobc -fimplicit-init -C cobparams.cob
*> ***************************************************************
REPLACE ==ARRAYSIZE== BY ==450==.
identification division.
program-id. cobfloats.
data division.
working-storage section.
01 cnt pic 999.
01 val usage float-short.
01 xes.
02 an-x usage float-short occurs ARRAYSIZE times.
01 yes.
02 an-y usage float-short occurs ARRAYSIZE times.
linkage section.
01 vxes.
02 an-x usage float-short occurs ARRAYSIZE times.
01 vyes.
02 an-y usage float-short occurs ARRAYSIZE times.
*> ***************************************************************
procedure division using by reference vxes, vyes.
perform varying cnt from 1 by 1 until cnt >= ARRAYSIZE
compute val = cnt * function random() end-compute
move cnt to an-x in xes(cnt)
move val to an-y in yes(cnt)
end-perform
move xes to vxes
move yes to vyes
move cnt to return-code
goback.
end program cobfloats.
and a sample run
$ cobc -fimplicit-init -C cobparams.cob
$ vi cobparams.c
(Add a #pragma K&R to the top of cobparams.c so CINT lets up on type safety)
[btiffin@home cobol]$ root -l
root [0] gSystem->Load("/usr/local/lib/libcob.so");
root [1] .L cobparams.c+
root [2] int a = 0; float x[450]; float y[450];
root [3] a = cobfloats(&x, &y);
root [4] a
(int)450
root [5] TGraph *graph1 = new TGraph(450, x, y);
root [6] graph1->Draw("A*");
which produces an interactive graph of some arbitrarily constrained random numbers.
As you are working in a mainframe environment (I presume it's IBM) I suggest you check out the following link http://www-01.ibm.com/software/awdtools/cobol/ to IBM'S COBOL compiler section. There's information there about linking COBOL with web services and Java, in a mainframe environment.
As a previous answer mentioned, you could also look at Visual COBOL from Micro Focus. It's not a mainframe product but is a COBOL complier within Visual Studio and deploying in .NET
http://www.microfocus.com/products/micro-focus-developer/micro-focus-cobol/windows-and-net/micro-focus-visual-cobol.aspx
The kind of situation you may be looking at software for is called rapid prototyping and this involves a program code or script generator to demonstrate the visual appearance of displays or forms to a computer screen and can include some elements of data input and advancing to more screen pages. This is the data processing department type of style and presentation rather than one which has graphics, web access and so on that a programmer of a desk computer or laptop/notebook would probably encounter and use.
I realize this is quite a late entry, but why don't you highlight Cobol at it's strongest -- churning through massive chunks of data while applying business logic and extracting current state.
May I suggest you prepare a nice set of reports on your current database. Extract, detail, summarize, and slice and dice the data a dozen different ways. Make sure you note the runtimes to create the report suite compared to other languages trying to do the same things. And note the readability of the code (and thus, modifiability of the report suite) compared to what other languages might offer.
Extract to a CSV while you are at it and add in some Excel (or other spreadsheet) graphing and data analysis.
精彩评论