Prev: Ping: Pete Dashwood
Next: Ping: Robert
From: Pete Dashwood on 27 Sep 2008 08:25
"SeaSideSam" <Sam(a)Sea.Side> wrote in message
news:1c587$48dde0be$6214c5e7$14321(a)ALLTEL.NET...
> Ref: http://primacomputing.co.nz/cobdata
>
> sss here. i've been going thru the change and am making changes on an
> hourly basis: replacing opera with chrome and grabit with thunderbird. i
> have been informed that both steps were necessary. i am not convinced.
>
> in "robert's original code" some pic clauses have periods following and
> others don't. the compiler must handle this okay.
> -snip-
> . 10 layout-type pic x(01)
> . 88 type-binary value 'b'
> . 88 type-packed value 'p'
> . 10 layout-redefines-name pic x(31).
> . 10 layout-redefines-stack.
> . 15 layout-redefines-depth binary pic s9(02).
> . 15 layout-redefines-entry occurs 10 binary pic s9(04).

Yes. It does. When I wrapped Robert's code, I did not always maintain his
coding style. This was because I was cuttting and pasting wrappers from
other OO COBOL programs and I found Robert's style a bit confusing at
first... (I've grown more accustomed to it now.).

>
> . procedure division.
> -end snip-
>
> "view license"... you guessed it; chrome displays a blue box.

Try it again, I have been applying style sheets to it for Firefox; it might
help chrome as well.

>
> "Process diagram"...
>
> when you complete this process how much 'cobol' remains? i'm trying to
> visualize the most complex program i've worked with (payroll; exempt,
> nonexempt, 5 unions, nonunion) after completing steps 1 and 3. my
> oldtymers keeps interfering. we had relocatables back in the day, and
> made use of them; so step 3 would not gain much. i never had the guts or
> the time to implement step 1.

The amount of COBOL that remains would depend on how much you were able (or
willing) to refactor in step 3. I'm working on a project at the moment where
we expect to refactor around 80% of the code. If the code is well written,
it isn't difficult to refactor. The whole idea is not to "cling to COBOL",
it is to move on, but not lose your existing investment. By step 4 everyone
will have been trained in C# (which is much quicker to write than COBOL,
mainly because the IDE (VS 2008) virtually writes it for you with
Intellisense), and the new development will be new components in new
languages (python, Ruby, C#, VB.NET, and so on. The language doesn't really
matter, although some languages are better than others for certain tasks.
What really matters are the objects. These are the building blocks of your
business. Glueing them together is not only fun, it is also profitable.
Being able to include legacy COBOL with the new stuff and have it all run
seamlessly together, is a big deal.

> you two seemed to get this done in a very short time. would this be
> typical?
>
Yes. Normally it would be quicker. I was sick and so was Robert some of the
time. Also I had other commitments and could not apply myself to this full
time. I have found that developments which would take me around three weeks
in COBOL i can now do in about 5 days. (It depends on what it is, how
complex it is, and how many existing components I can reuse. C# is
definitely quicker. It is free, quick to write, and because there is less of
it, it is easier to get into if you need to. I have no regrets about moving
to it at all. Certainly, it looks unfamiliar after COBOL and it does not
document itself (although there are tools that will automatically document
your code for you), but it is a different ball game and English-like
readability is not important in this world.

> not to nitpick; but... ever since i've had a tp monitor on my desk (at
> work or at home) with the capability of running a compile and having the
> listing available at my desk within moments i have had a dummy program
> available where i 'copy' the data structure i'm working with, compile, and
> get offset and displacement info directly from the compiler listing.
> worked for me.

Sure, everybody works differently. I had a particular requirement and the
tool meets it very well.

Not to nitpick, but can your compiler listing generate an equivalent C#
Class to service a data object that is equivalent to your COBOL record
layout? No...? Our tool will. And I'm thinking many people who are not COBOL
programmers will be glad to be able to interface directly to "COBOL files"
in C#. The irony is that the new C# Class generator may well be written in
COBOL... we are still looking at it. I had planned originally to write it in
C# but I am just too busy right now.Robert is looking at doing it in COBOL.
but some of the C# required is a bit tricky and it isn't his field of
expertise. I can help, of course, but it is still pretty tricky stuff. It is
much more complex than the offset/length tool. Still, I am confident that
within a few months we will have enhanced the existing tool with this
functionality.
>
> happy spring time.

Thank you. We are officially into Summer now and the clocks go forward
tonight.

Thanks for your post, Sam.

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



 | 
Pages: 1
Prev: Ping: Pete Dashwood
Next: Ping: Robert