Goal:

Seamlessly convert MF generated COBOL reports
into XML data which can then be imported into Excel 2003.

Given a bunch of report files.

Each line on the report maps to a COBOL layout.

Each COBOL layout can be used to parse out the line.

There will be enough info on the line to match
the particular layout.

There will be a variety of headers, footers, sub-totals,
and a variety of data lines.

Does XML conversion make sense in this context?

Given this simple report:

\nGeneral Report\n\nTitle Qty Cost\n--------------\naaa   23  $25\nbbb   20  $30\nccc   21  $20\nddd   23  $ 5\n--------------\nTotal     $80\n\nDifferent Set of data in same report.\n\nTitle Loss\n-----------\nqqq   29\nxxx   60\n\n\n

Does it even make sense to put it in XML to place it in Excel?
I could put it directly in Excel. Why use the XML? Other than
the fact my boss told me to. Can someone point me to a decent
online tutorial since I can't even figure out how to correctly
handle the main title or total lines.

I dunno, ask Peter if it is correct usage over there.

#1 The data is not truly tabular. There can be many different
layouts in a single report, skewing all over the place. Then
add in a bunch of subtotal, average, and other info lines, and
none of it will ever line up.

#2 There are hundreds of these reports, and they change all
the time. The only way to KNOW what is in them is to parse
the COBOL layout, and there might be a dozen layouts per report.

We will setup a standard for the COBOL programmers to add an identifier
AFTER the end of the normal printed record. This way they can use the
same layout to generate both reports, except when it gets printed the
identifier will never show up. This way I know EXACTLY which of
the 100s of possible layouts that particular line came from so
I know how to parse it.

Ever write code to parse COBOL layouts? COBOL is a COMPLEX language
if people really use it to it's fullest extent. But print layouts
are simple, no implied decimal, no binary, no redefines, no occurs,
so it only took me about 30 minutes for this parser.

#3 My boss knows that I can generate them directly in Perl,
including tagging numbers VS zipcodes VS text VS $$ amounts, setting
up the proper justification, comma-izing, etc. He was a Perl
programmer before his brain started to atrophe. In this case,
he thought it would be a good idea for me to play with XML, learn
a bit, and then make up my own mind how to do it.

With this data delimited of any type does not work for me since I need
to juggle data types constantly.

Spreadsheet::WriteExcel and Spreadsheet::WriteExcel::Utility are
your friends.

If I generate the additional XML based data later, it will add to
our buzzword compliance, which is always a "GOOD THING (tm)"