Re: COBOL tool

Pete,
I am not certain that this actually made it to CLC. If so, I don't think that
I saw any reply from you. Any comment?

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:...
> Pete,
> I haven't read all the thread yet, but I agree with Richard that the BEST way
> to do this is with a compiler. I say this because SO much of this (especially
> offset and size of fields) is dependent upon compiler, compiler options, etc.
>
> Consider:
> Pic 9(4) Packed-Decimal
> in most compilers that I have worked with, this takes 3 bytes of storage, but
> SOME do support "even-number unsigned" packed decimal fields without "sign
> nibbles".
>
> Or consider the Micro Focus compiler directive IBM-COMP which impact how much
> storage is allocated for
> Pic S9(2) Binary
>
> ***
>
> I see that Robert has posted a program (using "@OPTIONS" - so I guess it is
> for Fujitsu). Certainly you (one) could modify it for whichever compiler (and
> compiler options/directives) you want. However, I still think that the "best"
> solution would be to use a compiler with the options you plan on using with
> the layout. Putting something like this in a "dummy" program and working with
> the output seems most efficient to me.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:6hs3k8FnsgebU1@mid.individual.net...
>>
>>
>> "Richard" <riplin@azonic.co.nz> wrote in message
>> news:342fc890-38d5-4f8f-b1a7-13867deac1ce@r35g2000prm.googlegroups.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.
>>
>> 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.
>>
>> [Pete]
>>
>> I'm amazed you wrote this, Richard.
>>
>> Every COBOL compiler I have ever worked with has this capability as a listing
>> option.
>>
>> 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...
>>
>> Pete.
>> --
>> "I used to write COBOL...now I can do anything."
>>
>>
>>> 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. The idea is that you could
>>> select with the mouse all or part of a COBOL record layout viewed in your
>>> Editor of choice, and have a popup window that would give you the offset and
>>> length of each selected field and the total length overall. (It may be a
>>> requirement that selection starts from the 01 level, or not, depends on how
>>> your code works...)
>>>
>>> So the code should be able to accept or read COBOL Data Division source as
>>> input, and output a simple text list with an entry for each dataname showing
>>> the offset and length of it. (The offset represents the total bytes
>>> preceding the field, so the total length of a record definition is easily
>>> obtained, and saves all that very tedious counting or searching for the
>>> compiler output.)
>>>
>>> I already have some COBOL code that parses COBOL source and analyses
>>> pictures. I can amend it to do this as well, but it is tricky and would not
>>> be publicly available.
>>>
>>> Please express interest here if you think you want to have a go at this.
>>>
>>> If no-one is up for it, I'll write it myself in C#, when I get time. :-)
>>>
>>> Pete.
>>> --
>>> "I used to write COBOL...now I can do anything."
>>
>>
>
>

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:KJ8wk.59402$vn1.15722@fe03.news.easynews.com. ..
> Pete,
> I am not certain that this actually made it to CLC. If so, I don't think
> that I saw any reply from you. Any comment?
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:...
>> Pete,
>> I haven't read all the thread yet, but I agree with Richard that the
>> BEST way to do this is with a compiler. I say this because SO much of
>> this (especially offset and size of fields) is dependent upon compiler,
>> compiler options, etc.
>>

I didn't see this post before, Bill, but I have already responded as to why
I don't want to re-process compiler output. Yes, the point Richard made
regarding compiler options is valid, but we are writing a freeware tool, and
it doesn't have to be comprehensive, provided the limitations are stated.

I have had (and am having more...) occasions where I really need to have
offsets and lengths when I am in the middle of developing a COBOL layout
which must also be converted to a C# structure. It hasn't been compiled yet,
I am in the middle of doing it and I have a mouse or trackpad available. I
want to select the parts I'm interested in and know what their offsets and
lengths are, immediately.



>> Consider:
>> Pic 9(4) Packed-Decimal
>> in most compilers that I have worked with, this takes 3 bytes of storage,
>> but SOME do support "even-number unsigned" packed decimal fields without
>> "sign nibbles".

I don't care :-) This is not going to be all things to all people and if
you happen to use a Bendix compiler that runs your washing machine using
some obscure form of packed, then this isn't for you.
>>
>> Or consider the Micro Focus compiler directive IBM-COMP which impact how
>> much storage is allocated for
>> Pic S9(2) Binary

Yes, I considered it. We can work on binary being 4 or 8 bytes, no problem.

>>
>> ***
>>
>> I see that Robert has posted a program (using "@OPTIONS" - so I guess it
>> is for Fujitsu). Certainly you (one) could modify it for whichever
>> compiler (and compiler options/directives) you want. However, I still
>> think that the "best" solution would be to use a compiler with the
>> options you plan on using with the layout. Putting something like this
>> in a "dummy" program and working with the output seems most efficient to
>> me.

I don't disagree. But there are other implications at work here also. You'll
probably understand better if you go to the website and download it when it
is released next week.

Actually, my main need for this was as an extension to metadata I already
generate from a parse of the COBOL data definition source (both SELECT and
FD). My solution DOES cater for various formats and includes separate signs,
synchronization, and numeric formats other than short and long floating
point. I'm really not bothered about compiler options. If they invalidate
the result that is something I can live with. Most people are NOT using
esoteric compiler options and most people don't change them frequently.

The exercise with Robert is addressing other considerations as well as the
obtaining of offset/length data.

Besides, it's a pretty cool exercise to get a mouse selection from C#,
convert it to a data stream and feed it to a COBOL engine running in the
..NET framework...:-)

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

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:6icr1nFpssa5U1@mid.individual.net...
>
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:KJ8wk.59402$vn1.15722@fe03.news.easynews.com. ..
>> Pete,
>> I am not certain that this actually made it to CLC. If so, I don't
>> think that I saw any reply from you. Any comment?
>>
>> --
>> Bill Klein
>> wmklein <at> ix.netcom.com
>> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:...
>>> Pete,
>>> I haven't read all the thread yet, but I agree with Richard that the
>>> BEST way to do this is with a compiler. I say this because SO much of
>>> this (especially offset and size of fields) is dependent upon compiler,
>>> compiler options, etc.
>>>
>
> I didn't see this post before, Bill, but I have already responded as to
> why I don't want to re-process compiler output. Yes, the point Richard
> made regarding compiler options is valid, but we are writing a freeware
> tool, and it doesn't have to be comprehensive, provided the limitations
> are stated.
>
> I have had (and am having more...) occasions where I really need to have
> offsets and lengths when I am in the middle of developing a COBOL layout
> which must also be converted to a C# structure. It hasn't been compiled
> yet, I am in the middle of doing it and I have a mouse or trackpad
> available. I want to select the parts I'm interested in and know what
> their offsets and lengths are, immediately.
>
>
>
>>> Consider:
>>> Pic 9(4) Packed-Decimal
>>> in most compilers that I have worked with, this takes 3 bytes of
>>> storage, but SOME do support "even-number unsigned" packed decimal
>>> fields without "sign nibbles".
>
> I don't care :-) This is not going to be all things to all people and if
> you happen to use a Bendix compiler that runs your washing machine using
> some obscure form of packed, then this isn't for you.
>>>
>>> Or consider the Micro Focus compiler directive IBM-COMP which impact how
>>> much storage is allocated for
>>> Pic S9(2) Binary
>
> Yes, I considered it. We can work on binary being 4 or 8 bytes, no
> problem.

Oops! It's late and I'm tired... I completely overlooked the 2 byte
halfword...

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

On Sat, 6 Sep 2008 01:45:26 +1200, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>
>
>"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
>news:6icr1nFpssa5U1@mid.individual.net...
>>
>>
>> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
>> news:KJ8wk.59402$vn1.15722@fe03.news.easynews.com. ..
>>> Pete,
>>> I am not certain that this actually made it to CLC. If so, I don't
>>> think that I saw any reply from you. Any comment?
>>>
>>> --
>>> Bill Klein
>>> wmklein <at> ix.netcom.com
>>> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:...
>>>> Pete,
>>>> I haven't read all the thread yet, but I agree with Richard that the
>>>> BEST way to do this is with a compiler. I say this because SO much of
>>>> this (especially offset and size of fields) is dependent upon compiler,
>>>> compiler options, etc.
>>>>
>>
>> I didn't see this post before, Bill, but I have already responded as to
>> why I don't want to re-process compiler output. Yes, the point Richard
>> made regarding compiler options is valid, but we are writing a freeware
>> tool, and it doesn't have to be comprehensive, provided the limitations
>> are stated.
>>
>> I have had (and am having more...) occasions where I really need to have
>> offsets and lengths when I am in the middle of developing a COBOL layout
>> which must also be converted to a C# structure. It hasn't been compiled
>> yet, I am in the middle of doing it and I have a mouse or trackpad
>> available. I want to select the parts I'm interested in and know what
>> their offsets and lengths are, immediately.
>>
>>
>>
>>>> Consider:
>>>> Pic 9(4) Packed-Decimal
>>>> in most compilers that I have worked with, this takes 3 bytes of
>>>> storage, but SOME do support "even-number unsigned" packed decimal
>>>> fields without "sign nibbles".
>>
>> I don't care :-) This is not going to be all things to all people and if
>> you happen to use a Bendix compiler that runs your washing machine using
>> some obscure form of packed, then this isn't for you.
>>>>
>>>> Or consider the Micro Focus compiler directive IBM-COMP which impact how
>>>> much storage is allocated for
>>>> Pic S9(2) Binary
>>
>> Yes, I considered it. We can work on binary being 4 or 8 bytes, no
>> problem.
>
>Oops! It's late and I'm tired... I completely overlooked the 2 byte
>halfword...

Binary s9(2) is one byte under default byte-storage mode in Micro Focus IBMCOMP puts it
in word-storage mode, where 1 through 4 is rounded up to two bytes. Fujitsu has only
word-storage mode, I'm fairly sure. Realia required non-default SMALLCOMP to get one byte.

SYNCHRONIZED is also involved.

My parser assumes word-storage mode. I will add NOIBMCOMP, but not as the default.