COBOL tool

"Robert" <no@e.mail> wrote in message
news:a3vib4t5j6ppa20sg69eg8hrb81g0d164r@4ax.com...
> On Sun, 31 Aug 2008 00:12:36 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>>"Robert" <no@e.mail> wrote in message
>>news:umnhb490a0jpnau4rjd4qu1l4g8pl250c7@4ax.com. ..
>
>>>
>>>>On Aug 30, 12:07 pm, "Pete Dashwood"
>>>><dashw...@removethis.enternet.co.nz> wrote:
>>>>> I need a tool that can analyse the source of a COBOL record layout and
>>>>> calculate the offset and length (true length occupied in bytes, not
>>>>> the
>>>>> virtual length implied in the picture... for example, "pic s9(7)v99
>>>>> comp-3"
>>>>> has a virtual length of 9 digits but occupies 5 actual bytes), for
>>>>> each
>>>>> field defined in the definition, including group fields and REDEFINEd
>>>>> and
>>>>> OCCURring fields.
>>>
>>> A few years ago I posted a program -- cob2csv -- which did that so it
>>> could convert any
>>> 'Cobol file' to a csv. Here is a stripped down version showing only the
>>> parsing.
>
>>If you can amend it to support REDEFINES and group levels, say up to 6
>>levels should be fine...(my own code uses a pushed and popped stack of
>>levels with total lengths and offsets),
>
> That will require two additional passes through the structure -- one to
> look backward for
> redefines and one to look forward from group names. I will work on it.
> I'll have to use
> Fujitsu because I forgot to bring the server access device (DigiPass) home
> this weekend.
>
How's it going?

The framework and presentation layer for it is ready. (It took just 5 hours
using VS 2008 and existing components. This includes all forms, pictures,
and icons. I also have a COBOL project to build the COM server, waiting for
your code. I will probably need a couple of days after I receive the code to
prepare the Web Server and finish the .NET Assembly.(I can't spend full time
on it right now, but I'd like to get it done as quickly as possible.

There are a couple of things I'd like you to OK before it goes public.

Can you contact me privately, please?

Cheers,

Pete.

--
"I used to write COBOL...now I can do anything."

On Mon, 1 Sep 2008 21:28:22 +1200, Pete Dashwood wrote:
> I see no need to spend thousands of dollars on the Fujitsu .NET COBOL
> product when C# is free.

So how many thousands did you have to fork out for NetCOBOL?

Bruce.

-- Posted on news://freenews.netfront.net - Complaints to news@netfront.net --

"Bruce M. Axtens" <bruce.axtens@gmail.com> wrote in message
news:5u7jfsa8ysj7$.gl8dm5qii15a$.dlg@40tude.net...
> On Mon, 1 Sep 2008 21:28:22 +1200, Pete Dashwood wrote:
>> I see no need to spend thousands of dollars on the Fujitsu .NET COBOL
>> product when C# is free.
>
> So how many thousands did you have to fork out for NetCOBOL?

I moved to NetCOBOL when they gave version 3 away, to pick up the MF people
who were upset over the Visoc fiasco.

I paid maintenance (I think it was around $300 a year) which entitled me to
free version upgrades, and Fujitsu did give me a free upgrade to Enterprise
with one of the versions (I think it was version 4) as I had been publicly
supportive of their products. (It wasn't a "deal", I was gratefully
surprised by it...and it didn't bias my opinon of their products, which was
then, and is now, high.) Some years later when I enquired about buying
NetCOBOL for .NET my enquiries went unanswered so I moved to C#. Best thing
I ever did.

In total over the years, while I was paying maintenance, I probably spent
around $2000 with Fujitsu. I certainly don't intend to spend any more. I was
looking at the .NET COBOL product for a client so would not have been paying
for it myself. We are bringing him to .NET using C# and he is very happy. I
am currently writing migration tools to assist others to refactor their
COBOL legacy and do the same.

I don't know about Fujitsu's .NET COBOL product so cannot comment, but their
standard COBOL products (NETCobol and PowerCobol) are both excellent
products. I believe I have had my money's worth from these products. It is
ironic that money which was ostensibly paid for maintenance and support
(which was hopeless and worth nothing...) was actually good value for a
product that was very worthwhile and useful. I guess things balance out in
the end...

Pete.

On Sat, 30 Aug 2008 12:07:59 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>I need a tool that can analyse the source of a COBOL record layout and
>calculate the offset and length (true length occupied in bytes, not the
>virtual length implied in the picture... for example, "pic s9(7)v99 comp-3"
>has a virtual length of 9 digits but occupies 5 actual bytes), for each
>field defined in the definition, including group fields and REDEFINEd and
>OCCURring fields.
>
>If anyone has code that does this and is prepared to share it, mail it to
>me. I'll wrap it for windows with a GUI front end and put it on a server for
>freeware download so that everyone can use it.

I wrote one once - in CoBOL (I believe it used 3 passes). But there
are differences between machines that would make this a non-universal
tool.

On Fri, 29 Aug 2008 17:54:45 -0700 (PDT), Richard
<riplin@azonic.co.nz> wrote:

>I have one, it is called a 'compiler'. Actually the Microfocus
>compiler can do this with such options as COPYLIST, REF, and such it
>will output the byte address of each variable into the listing on
>disk. A simple script can then extract the various records from the
>listing and do a few simple calculations to arrive at the answers you
>want.
>
>It also has the advantage of taking into account implicit or explicit
>redefines, renames, synchronized and any effects of compiler options.

And copy members and pre-compiler data dictionary copies.

On Sat, 30 Aug 2008 17:20:08 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>I don't want to re-process compiler output (which I cannot guarantee has
>even been produced yet... the tool will be used during development. You
>could be developing a record layout that has never been compiled...)
>
>I thought the requirement was clear; maybe it wasn't...

You don't have a compiler available at this early development stage?
I've used shells of programs just to get compile listings of copy
members, I just don't create a load module. What is it that you are
wanting that the compiler listing doesn't provide?

On Sun, 31 Aug 2008 12:44:36 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>I have solved this problem for myself and amended my own metadata generator
>to include the information on offset and length. However, Robert is going to
>amend his code and I'll wrap it as a GUI tool that can be used with a mouse.
>I think this would be a useful thing to have for many programmers dealing
>with COBOL. (Not necessarily just COBOL Programmers.)

Non CoBOL programmers might be the primary audience.

On Tue, 02 Sep 2008 07:58:30 -0600, Howard Brazee <howard@brazee.net>
wrote:

>On Sun, 31 Aug 2008 12:44:36 +1200, "Pete Dashwood"
><dashwood@removethis.enternet.co.nz> wrote:
>
>>I have solved this problem for myself and amended my own metadata generator
>>to include the information on offset and length. However, Robert is going to
>>amend his code and I'll wrap it as a GUI tool that can be used with a mouse.
>>I think this would be a useful thing to have for many programmers dealing
>>with COBOL. (Not necessarily just COBOL Programmers.)
>
>Non CoBOL programmers might be the primary audience.

What might be nice would be to turn this into a conversion tool -
input the CoBOL file format, select your language from a list, and
output a file format that is useable by some other language.

"Howard Brazee" <howard@brazee.net> wrote in message
news:r0hqb4p50ddcfunusikfll1plm5gl7t6ad@4ax.com...
> On Sat, 30 Aug 2008 12:07:59 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>>I need a tool that can analyse the source of a COBOL record layout and
>>calculate the offset and length (true length occupied in bytes, not the
>>virtual length implied in the picture... for example, "pic s9(7)v99
>>comp-3"
>>has a virtual length of 9 digits but occupies 5 actual bytes), for each
>>field defined in the definition, including group fields and REDEFINEd and
>>OCCURring fields.
>>
>>If anyone has code that does this and is prepared to share it, mail it to
>>me. I'll wrap it for windows with a GUI front end and put it on a server
>>for
>>freeware download so that everyone can use it.
>
> I wrote one once - in CoBOL (I believe it used 3 passes). But there
> are differences between machines that would make this a non-universal
> tool.

It is interesting to me that both you and Robert talked about multiple
passes.

My version uses a single pass and handles group fields, OCCURS and
REDEFINES to 32 levels, along with binary, packed, big and little endian
formats, synchronized (it calculates and inserts slack bytes as filler where
needed) and sign separate clauses. It doesn't handle floating point or
object references or index data names (all of which have no picture...)

I manage this by detecting reserved words and so knowing what are datanames
and what are not, and PUSHing and POPping information at each level.

It emits metadata for every dataname in the record layout, but the group
levels are emitted after their constituent fields. (It would be a simple
matter to sort them if they needed to be in the same sequence as the
original record layout. For my purposes they don't have to be.)

I can't release the code because it is commercially sensitive. However, it
underlines the old adage that if you give the same job to more than one
programmer, you will get more than one result, none of which is necessarily
wrong.

I really like Robert's latest code which he posted here and the output is
ideal for the tool I have in mind.

I hope you'll download the final product, Howard, if for no more reason than
to seee what I've been talking about.

Pete.
--
"I used to write COBOL...now I can do anything."

O
>> I wrote one once - in CoBOL (I believe it used 3 passes). But there
>> are differences between machines that would make this a non-universal
>> tool.
>
>It is interesting to me that both you and Robert talked about multiple
>passes.
>
>My version uses a single pass and handles group fields, OCCURS and
>REDEFINES to 32 levels, along with binary, packed, big and little endian
>formats, synchronized (it calculates and inserts slack bytes as filler where
>needed) and sign separate clauses. It doesn't handle floating point or
>object references or index data names (all of which have no picture...)
>
>I manage this by detecting reserved words and so knowing what are datanames
>and what are not, and PUSHing and POPping information at each level.

My main interest in multiple passes was to avoid more tables than I
needed. It was written on mainframe CoBOL about a decade ago. I
was told to not look at every possible compiler USAGE clause, only the
USAGE clauses our shop used (no floating point). But it did look at
explicit and implicit synchronization. I'm not sure, but I don't
think it handled sign separate clauses (these days that would be
mandatory).

>It emits metadata for every dataname in the record layout, but the group
>levels are emitted after their constituent fields. (It would be a simple
>matter to sort them if they needed to be in the same sequence as the
>original record layout. For my purposes they don't have to be.)

What do you use the metadata for?

>I hope you'll download the final product, Howard, if for no more reason than
>to seee what I've been talking about.

I don't own that code and didn't take it with me when I changed jobs.