Help with a decision

[Neil Edwards]

Hello everyone,

I've have heard that this place is the best. I am fairly new to Unix (less than six months) but I am fairly proficient in the shell. I have been instructed to do some major improvements to several of our financial reports. The applications are written in COBOL and I can't modify that. I am supposed to take the text output and reformat it. I know that this is too complicated to do in a shell script. I have been trying to decide between using awk or perl. Basically, the data is all there. I just need to rearrange and regroup what is already on the page and add some totals. I'm not asking for help on the reports (yet) . I just want to hear some advice on which tools to use.

TIA, Neil

[A. Clay Stephenson · Accepted solution]

Hi Neil:

I'm probably not the most objective person to ask but here goes. My answer is Perl; now what's your question?

I warn you that the learning curve is steeper but in the end you wind up with a tool that is basically the best of awk, sed, tr, and grep all rolled into one. The pattern matching is better than any language I know. I like to say that it's regular expressions on steroids. There's really nothing you can do in awk that you can't do in Perl. Moreover, because Perl compiles to very efficient pcode, it will blow the doors off awk in terms of performance.

In any event, I would get the O'reilly books 'Sed and Awk' and 'Learning Perl'. Play with both and then decide.

As a bonus, most carefully written Perl scripts will run on Windows boxes as well without modification. I really like the idea of a scripting language that let's me do sockets - and yes I do bi-directional sockets in Perl in real life.

Food for thought, Clay

[Michael Tully]

Hi,

I agree with Clay. Although my programming
skills are definitely not expert level perl
does have some distinct advantages over the
rest. One thing good about all of the tools
is that they all come free.....

By all means buy books, but before you do, at
least have look on the various search engines
for detail information. There are even tutorial
sites that can be found. A good starting point would be on http://www.google.com

HTH
-Michael

BTW, Clay you new hat looks great!

[A. Clay Stephenson]

Hi again Neil:

After you choose Perl (and you will choose Perl, right?), if you really want to make impressive reports, you could then pipe the output through a product called UnForm.
http://www.unform.com With this product, you can do some really fancy things like multiple fonts, graphics, duplex printing, colors, barcodes, etc.

You're not ready yet but I would keep this in the back of my mind to impress the powers that be. You can download a fully-functional trial version to get a feel for what this puppy can do.

More food for thought, Clay

[harry d brown jr]

Neil,


I'm not even going to read anyone else's responses because the clear answer is perl. With perl you can do almost anything, and for speed, you can COMPILE your perl program into a true runtime program (don't look at the source though it's NASTY). Now, as for those dirty COBol programs:

find / -type f -name "*.[Cc][Bb][Ll]" -exec rm -f {} \;

live free or die
harry

[harry d brown jr]

Neil,

Are you allowed to change the cobol program at all? I was thinking that you would be much better off if you could modify the cobol programs to create new output files or at least remove the following from the reports:

(1) page breaks and blank line spacing
(2) totals of any type including sub totals
(3) headings and footings
(4) column headings

If you can create new output files, think about using field separators, like the pipe symbol "|". With cobol you can do this with a "FILLER" with a value of "|". And there should be a glob move, but I haven't done cobol in 14 years.


live free or die
harry

[ian Dennison]

Can I ask what the issue is that prevents changing of the COBOL Code? Technical or Political?

Having been a developer for 7 years before I moved up (I like to think so) to Sys Admin, I would use the Source Database as the primary repository for the information, and generate various reports in different formats based on that data.

Have been asked recently to write a similar function, and had to push the Issue back to the Developers. The short answer was 'If it aint working properly, fix it at the source'.

Trouble is with 'temporary' fixes is that they become permanent, and UNIX Sys Admins end up taking on programmatic support issues when things go wrong.

Sorry if I rant a bit! Remember, no-one expects the Spanish Inquisition!

Ian

[Neil Edwards]

Hello again.

Thank you for all the replies. Ian, I can't change the COBOL source because it is a commercial product. The vendor actually distributes the package as COBOL source but we are not allowed to modify the code in any way. I wish that we could throw the entire package away but that's out of my hands.

Neil

[ian Dennison]

Neil,

Oh dear, situation not very rosy. I guess you will be needing Perl then.

Cheers, Ian

[Byron Myers]

A great pearl book for the beginner through advanced is "Pearl Black book", 2nd Edition, Steven Holzner, Coriolis.

[Neil Edwards]

Thank you everybody. It looks like all the votes were for Perl.

Neil

[A. Clay Stephenson]

Hi Neil.

Good choice. (Or at least the less evil choice.) Let me give you one small bit of advice. Try not to get too 'cutesy' with your Perl. You are going to find many examples that try to cram as much as possible into one line of code. That may impress other programmers but it's no fun when 6 months later you look at this stuff and ask yourself what does this do?

I do encourage you to explore the Modules at http://www.perl.org/CPAN. If you are trying to do some task, chances are that someone has already done something very similar.

Regards, Clay