Source Code Beautifier for COBOL
Glenn Gordon
Greetings fellow programmers!
I am looking for SOURCE CODE for a COBOL BEAUTIFIER in COBOL or REXX!
My current client has a lengthly budget process that makes purchasing stuff
for evaluation and then buying it en-mass impossible to do in a timely
manner. They have a desire to standardize the format of their existing
COBOL code. Buying a tool is too political, hiring keyboard monkeys is too
expensive. The option left is roll-your-own source code beautifier! I do
not have a problem with this at all, and am perfectly willing to do it for
them. After all, I get paid for my work <g>. Anyway, due to the extensive
use of pre-processor macros and embedded languages in their source, they'd
probably have a hard time finding a tool to do the job without heavy
customization.
Before building this tool in COBOL and REXX (their choices, they have
people that could maintain them and expect to have code in those languages
around for a long time) I would like to find source for one that can be
studied and/or modified, thus saving me some time and possibly steering me
around some caveats the easy way instead of the hard way <G>. I have tried
a few searches on the web looking for such a COBOL source beautifier
available in source form and in the public domain, but have not found one.
Starting with something closer to the target languages than a C beautifier
written in C would be nice!!!
Does anyone have any links for me to investigate?
Please respond via e-mail if possible as I often don't have enough hours in
the day to read the newsgroups thoroughly:
ggo...@dimensional.com
gg
John M. Saxton, Jr.
IMHO .. in the immortal words of Jack Nicholson (sic ?) "The Joker" in
Batman; sounds like your clients need "an enema"... They don't want to
pay people, they can't make a decision to buy, and they are mired in
politics... who says downsizing is a bad thing...
Good luck.. I have had clients like yours and I don't wish them on
anyone.
--
Computer Programming Unlimited, Inc. (CPU, Inc.)
Return Address: cpuinc at sprynet dot com
This email address has been copyrighted. All rights reserved.
Sending unsolicted email to this address constitutes an infringement of
copyright.
All violators will be prosecuted to the fullest extent of the law.
Glenn Gordon
With regards to my client:
Aw, they aren't that bad. They pay their people and contractors reasonably
well for the area, pay for a lot of training (even for contractors) and are
pretty flexible. The part about not wanting to bring in people to do it is
that it would take a LOT of people to wade through and do the bulk of the
work. We are talking about a VERY large quantity of source code and a
largely mindless task. Perfect job for a computer.
The environment used is a bit unique. Incredible volumes of data are
processed every day. Some tools the client organization has built in the
past have been necessary if for no other reason they are doing things on a
very large scale with a systems architecture that is the stuff of
daydreams. Distributed and parallel processing are the norm here. They
have a technology plan and make it happen, integrating the old and new in
ways that work.
The client usually favors developing their own tools for things so that
they can control, maintain, and modify them to suit their needs. Doing
this kind of meta-level development is a nice change of pace for some of
the more technically apt people on their staff. The not buying part is
only political because it goes against the established culture of the
organization. It is not a matter of not being able to make a decision, the
decision is already made to build it in-house. They could buy a tool for
much cheaper than it will cost them to build their own, I am sure -- But
building and maintaining their own tool helps broaden the thinking and
creativity of their staff. Having a small group build the tool that does
95% of the work and then applying staff to the remaining 5% is their choice
and it makes sense. The surprising part is that they are willing to spend
the man-months needed to build the tool they could buy for a fraction of a
man-months pay because it provides new experiences and growth opportunities
for their staff.
I suppose in a cynical sense, though, having experience with an in-house
tool doesn't exactly make their staff more marketable should they seek
employment elsewhere <g>.
Sorry for rambling so much here, but I sincerely did not intend for my use
of a little light-heartedness to convey a negative impression of my client.
They have a wonderful organization and are rightfully considered a premier
employer in their market. This is a shop with which most contractors and
consultants in the area try very hard to do business. If I didn't enjoy
the freedom of consulting so much (and the better pay <g>) I would very
seriously consider being an employee of this client.
Glenn Gordon
ggo...@dimensional.com
Consultant
John M. Saxton, Jr. <cpu...@sprynet.com> wrote in article
<33A007...@sprynet.com>...
Dave Gomberg
In <01bc77b7$80bfb860$472c...@ggordon.ppp>, on 06/12/97
at 10:00 PM, Glenn Gordon <ggo...@DIMENSIONAL.COM> said:
> They could buy a tool for
>much cheaper than it will cost them to build their own, I am sure
>-- But building and maintaining their own tool helps broaden the
>thinking and creativity of their staff.
Building your own is more fun too!
There is an answer to your original question of a beautifier in
REXX. I believe that SLAC has a REXX beautifier written in REXX.
Maybe you could convert that. --
Dave Gomberg, FormMaestro! http://www.jcf.com
gom...@wcf.com
Help stop Internet spam! Join CAUCE: http://www.cauce.org/
Robert
If you were using an MVS environment I'd strongly suggest a product
called Q/Artisan. A very good standards/code checker.
RLS