Productivity

I've been doing a lot of thinking about productivity lately. (Of course
thinking about something doesn't necessarily make you more productive, but
you hope that it improves the quality of the end product.)

Just as an exercise and without any particular bias, I recently finished
rewriting a COBOL application that originally took six ws to develop.
(This includes design, writing, testing/debugging). The design took around 4
days, say, take a w off for design, and it took 5 ws to develop.

It was rewritten in C# and DotNET in 5 days.

Given that I am a newbie in C#, but am no slouch when it comes to COBOL, I
was at a loss to explain this.

1. Having developed it once, it is true that I now understand the whole
thing a lot better.
2. Part of the 5 days for the C# development was spent doing video tutorials
on C#.
3. Some of the things that took a fair bit of effort in OO COBOL were easy
in DotNET.

But despite all of that, it is quite obvious that my productivity in Visual
Studio 2005 is MUCH better than my productivity using the Fujitsu IDE.

This made me think about tools.

VS 2005 provides an Interactive Development Environment that is simply years
ahead of any other development environment I have ever worked in (on both
mainframes and PCs).

Colour coding of code, rollaway windows that you can pin down when you want
them or send to a tab when you don't, intuitive context sensitive tooltips,
having all your defined variables available for selection at the moment you
want to reference them, having all methods, events and properties for the
object you are referencing available as you type, along with help tooltips
for any you select, ...all of these things collectively add up to MAJOR
productivity improvements. There's no flipping through a listing (or opening
other windows on the data division) to check variable names. No wondering or
having to check parameter lists to methods. No syntax errors; you simply
can't make them. No spelling errors...(Keywords are inserted for you and
variables are selected from lists as you begin typing the name).  You can
view or hide any section of code at any time. Online contextual help is
instantly available for any method you want to use. If you don't know what
methods are available (always part of the problem when you start learning
something), they are organised by type so you can browse them instantly.

But.most importantly of all, the environment is NOT focused on code
development. It is pure event driven programming. You DON'T start by writing
IDENTIFICATION DIVISION (or its equivalent). You design what you want and
the code for the events is placed into the right contexts for you. All of
the housekeeping, fixed context, and overhead is hidden (unless you WANT to
see it). You focus totally on your application and what you want to happen
when events occur in it.

I find myself wondering how much quicker I could have built COBOL apps if I
had had this kind of development environment.

I understand that Fujitsu DotNET COBOL comes with this environment. It costs
several thousand dollars (if you can get them to sell it to you...I
couldn't).

Visual C# Express comes with the same environment and is a FREE download.
(This has been so for nearly two years now. I wouldn't be surprised if they
stop it soon...) MicroSoft WANT you to use their products. They are
confident (and with good reason) that, once you experience this environment,
you will want to upgrade to Enterprise version and support multiple teams
all working in it. (The enterprise version also supports source control).

There are over 400 FREE video tutorials on C# available on the web,
thousands of code snippets and samples, and a positive and upbeat user
community which is growing daily.

(What am I doing here... :-))

After a couple of months evaluating alternatives to COBOL, I am satisfied
that C# and Java between them have everything I need. Visual Studio is
simply the icing on the cake. I don't need to write off my existing
investment in COBOL, as DotNET  runs my existing COBOL components as
unmanaged code. (This will do until I need to replace them, if I need to
replace them.) I have been finding ways to minimize COBOL maintenance for
some years now, and components achieve this. I simply use C# as the glue to
hold them together.

So, it looks like I will be winding down my COBOL development.

The tools for cutting edge development are MUCH better and cheaper than
COBOL. It remains useful for batch development, which is what it was
invented for, and where we came in...

Forty years of writing it.

Guess it's time for a change... :-)

Pete.

Pete Dashwood wrote:
>
> Guess it's time for a change... :-)
>
> Pete.

Don't jump to conclusions. It has been my experience that luck has a lot to
do with program development - maybe more than anything else.

How many times have you said to yourself: "I'll be damned. It worked the
first time!" And how many times have you just never been able to get the
sucker to function at all?

Same tools, experience, money, etc. The only difference is providence.

Maybe you just got lucky.

FYI,
The current Micro Focus product for .NET development comes with both the
"traditional" (GUI) MF IDE *and* VisualStudio 2005 development.  It is up to
 the
programmer which is "most" convenient for them.  (I tend to run "simple"
ANSI/ISO conforming NON-OO, non-dotNET programs, so the old IDE works fine f
or
me.  If I were developing "real" Windows applications, I suspect, that I wou
ld
switch over.

--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:4v33ipF1a006cU1@mid.individual.net...
> I've been doing a lot of thinking about productivity lately. (Of course
> thinking about something doesn't necessarily make you more productive, but
 you
> hope that it improves the quality of the end product.)
>
> Just as an exercise and without any particular bias, I recently finished
> rewriting a COBOL application that originally took six ws to develop. (
This
> includes design, writing, testing/debugging). The design took around 4 day
s,
> say, take a w off for design, and it took 5 ws to develop.
>
> It was rewritten in C# and DotNET in 5 days.
>
> Given that I am a newbie in C#, but am no slouch when it comes to COBOL, I
 was
> at a loss to explain this.
>
> 1. Having developed it once, it is true that I now understand the whole th
ing
> a lot better.
> 2. Part of the 5 days for the C# development was spent doing video tutoria
ls
> on C#.
> 3. Some of the things that took a fair bit of effort in OO COBOL were easy
 in
> DotNET.
>
> But despite all of that, it is quite obvious that my productivity in Visua
l
> Studio 2005 is MUCH better than my productivity using the Fujitsu IDE.
>
> This made me think about tools.
>
> VS 2005 provides an Interactive Development Environment that is simply yea
rs
> ahead of any other development environment I have ever worked in (on both
> mainframes and PCs).
>
> Colour coding of code, rollaway windows that you can pin down when you wan
t
> them or send to a tab when you don't, intuitive context sensitive tooltips
,
> having all your defined variables available for selection at the moment yo
u
> want to reference them, having all methods, events and properties for the
> object you are referencing available as you type, along with help tooltips
 for
> any you select, ...all of these things collectively add up to MAJOR
> productivity improvements. There's no flipping through a listing (or openi
ng
> other windows on the data division) to check variable names. No wondering 
or
> having to check parameter lists to methods. No syntax errors; you simply c
an't
> make them. No spelling errors...(Keywords are inserted for you and variabl
es
> are selected from lists as you begin typing the name).  You can view or hi
de
> any section of code at any time. Online contextual help is instantly avail
able
> for any method you want to use. If you don't know what methods are availab
le
> (always part of the problem when you start learning something), they are
> organised by type so you can browse them instantly.
>
> But.most importantly of all, the environment is NOT focused on code
> development. It is pure event driven programming. You DON'T start by writi
ng
> IDENTIFICATION DIVISION (or its equivalent). You design what you want and 
the
> code for the events is placed into the right contexts for you. All of the
> housekeeping, fixed context, and overhead is hidden (unless you WANT to se
e
> it). You focus totally on your application and what you want to happen whe
n
> events occur in it.
>
> I find myself wondering how much quicker I could have built COBOL apps if 
I
> had had this kind of development environment.
>
> I understand that Fujitsu DotNET COBOL comes with this environment. It cos
ts
> several thousand dollars (if you can get them to sell it to you...I couldn
't).
>
> Visual C# Express comes with the same environment and is a FREE download.
> (This has been so for nearly two years now. I wouldn't be surprised if the
y
> stop it soon...) MicroSoft WANT you to use their products. They are confid
ent
> (and with good reason) that, once you experience this environment, you wil
l
> want to upgrade to Enterprise version and support multiple teams all worki
ng
> in it. (The enterprise version also supports source control).
>
> There are over 400 FREE video tutorials on C# available on the web, thousa
nds
> of code snippets and samples, and a positive and upbeat user community whi
ch
> is growing daily.
>
> (What am I doing here... :-))
>
> After a couple of months evaluating alternatives to COBOL, I am satisfied 
that
> C# and Java between them have everything I need. Visual Studio is simply t
he
> icing on the cake. I don't need to write off my existing investment in COB
OL,
> as DotNET  runs my existing COBOL components as unmanaged code. (This will
 do
> until I need to replace them, if I need to replace them.) I have been find
ing
> ways to minimize COBOL maintenance for some years now, and components achi
eve
> this. I simply use C# as the glue to hold them together.
>
> So, it looks like I will be winding down my COBOL development.
>
> The tools for cutting edge development are MUCH better and cheaper than CO
BOL.
> It remains useful for batch development, which is what it was invented for
,
> and where we came in...
>
> Forty years of writing it.
>
> Guess it's time for a change... :-)
>
> Pete.
>
>
>
>
>
>
>
>
>
>
>
>
>

William M. Klein wrote:
> FYI,
>   The current Micro Focus product for .NET development comes with both the
> "traditional" (GUI) MF IDE *and* VisualStudio 2005 development.  It is up 
to the
> programmer which is "most" convenient for them.  (I tend to run "simple"
> ANSI/ISO conforming NON-OO, non-dotNET programs, so the old IDE works fine
 for
> me.  If I were developing "real" Windows applications, I suspect, that I w
ould
> switch over.
>
I have been browsing the security problems involved with mixing
components and languages. C# and .NET are better than others for bounds
checking, string length, and stack problems we see in the news today.
http://en.wikipedia.org/wiki/Buffer_overflow

A paper from SANS has a little more depth, and background, as well as
how it's done. In the 24 pages it explains quite a lot, and is
supprisingly easy to read.
http://www.sans.org/reading_room/wh...urecode/386.php

COBOL is not mentioned in either of the two links above, but the methods
suggested to block a lot of the errors involve replacing the libraries
with other safer ones, and third-party products that add the protections
simply provided by COBOL. By design, COBOL doesn't lend itself to most
of the above, but some protections could be disabled for fasted
processing. I wouldn't do that when mixing languages. Over half of the
vulnerabilities reported by SANS are failures to validate the
(user's/caller's) input, which I think was taught in my 3rd day of COBOL
class.

Just my $.02

Gary

gary drummond wrote:
> William M. Klein wrote: 
> I have been browsing the security problems involved with mixing
> components and languages. C# and .NET are better than others for bounds
> checking, string length, and stack problems we see in the news today.
> http://en.wikipedia.org/wiki/Buffer_overflow
>
> A paper from SANS has a little more depth, and background, as well as
> how it's done. In the 24 pages it explains quite a lot, and is
> supprisingly easy to read.
> http://www.sans.org/reading_room/wh...urecode/386.php
>
> COBOL is not mentioned in either of the two links above, but the methods
> suggested to block a lot of the errors involve replacing the libraries
> with other safer ones, and third-party products that add the protections
> simply provided by COBOL. By design, COBOL doesn't lend itself to most
> of the above, but some protections could be disabled for fasted
> processing. I wouldn't do that when mixing languages. Over half of the
> vulnerabilities reported by SANS are failures to validate the
> (user's/caller's) input, which I think was taught in my 3rd day of COBOL
> class.
>
> Just my $.02
>
> Gary
That should be "faster", as in NOT checking ranges and etc.

Also, thanks for the updates. Between you and Frank's comments, I may
just give C# and MF Net Express both a try.

Gary

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12oosqtmgaqcd81@news.supernews.com...
> Pete Dashwood wrote: 
>
> Don't jump to conclusions. It has been my experience that luck has a lot
> to do with program development - maybe more than anything else.

The same way luck decides who wins at Chess? :-)

I'm not dismissing luck; as a keen Backgammon player I know that a lucky
player will beat an expert player, in the short term. In the long term;
skill will out. And every lucky streak eventually goes cold...

Nevertheless, your comment may be fair, because I only have a sample of one
and it COULD be luck.

I don't think it is. I don't think it is because, (when it comes to
programming) I am meticulous and have acquired skill. Assigning success to
having lucked out, simply devalues the many hours of thought and effort I
invested in the project..


>
> How many times have you said to yourself: "I'll be damned. It worked the
> first time!"

When this happens it isn't luck; it is care, thought, skill, and a lot of
sweat. I EXPECT stuff to work the first time; If it takes more than 3
compiles, I start thinking about a redesign...:-)

I should qualify this by saying that I write and debug at a function level.
I don't write huge programs with thousands of lines of code and then compile
them as a single entity.  I write say, 50 to 100 lines  (a SECTION) then
check that it works. The end product could be many thousands of lines, but
that will be many building blocks glued together, and each block will be
separately focused on, designed, built and debugged. (And many of these are
simply reusable modules that are plugged in and are known to work.) .

And how many times have you just never been able to get the
> sucker to function at all?

Only once. Forty years ago... the very first production program I ever wrote
in COBOL. It had to produce 6 reports and one of them never worked... :-)
These days if I found myself writing code that never worked, I'd consider
some other form of employment...

>
> Same tools, experience, money, etc. The only difference is providence.

No, I've never been to Rhode Island so I don't know what life changing
catharsis could be experienced there, and I don't believe in a Higher Power
who throws dice to decide whether COBOL programs work or not. Providence
simply doesn't cut it for me.

I am reasonably satisfied in this instance that, although luck cannot be
ruled out, it is far more probable that the superiority of the tools made
the difference.

I have come to believe in Visual Studio 2005... : -)  The DotNET framework
also simplifies a number of  things.

(And C# is a pretty  language too...)

It seems I am not the only one finding this. Demand for C# skills has almost
doubled in the last 6 months and is still steeply rising.

Quote from 'Information W'  October 4th, 2006...

"Hudson sees particularly strong demand for developers, especially those
with C# skills, says Taylor. At this time last year, the demand from Hudson
clients for developers was 70% related to Java, 25% to C#, and 5% to C++.
That's not the case this year, with 70% of demand for developers with C#
talent, 25% for Java, and 5% for C++. "

Here's the full article:

[url]http://www.informationw.com/management/showArticle.jhtml?articleID=193104411&su
bSection=Career+Development[/url]

People wondering where their COBOL career may be going, should consider
this.

Sometimes it is comforting to have a parachute, even if the plane is flying
steadily...

It isn't hard to learn but it DOES require some time and effort. And there
are new concepts, (like OO), which reqire suspension of what you already
know, and acceptance of a different way of approaching things.. There is a
huge amount of information and (downloadable or runnable online video)
tutorials available, at all levels of programming skill (including Absolute
Beginner), for FREE, along with software and IDE downloads, for FREE. I have
been quite stunned by the quality of some of this material and would expect
to pay for it...


>
> Maybe you just got lucky.

Possible, but unlikely.

Pete.

 
>
> Possible, but unlikely.
>
> Pete.

I have no doubt you are very skilled, but a rewrite will take advantage
of a number of design decisions and perhaps experiments that may have
take the original writer some time to get right.  You also have to bear
in mind that perhaps you are more skilled than the person who
originally wrote it and would have done the job rather faster had you
written the original.  The difference can be dramatic and even the same
person could be a lot faster with regular practice or better training.

Perhaps a fairer comparison would be a two way test, where one person
rewrites a Java and C# application in OO COBOL of roughly similar
complexity.

Having said that, I am nevertheless very impressed and can see your
point.

Robert

"Robert Jones" <rjones0@hotmail.com> wrote in message
news:1166980834.471149.102990@i12g2000cwa.googlegroups.com...
> 
>
> I have no doubt you are very skilled, but a rewrite will take advantage
> of a number of design decisions and perhaps experiments that may have
> take the original writer some time to get right.

I WAS the original designer/writer... that was the whole point. I was amazed
because I expected the rewrite to take at least as long, given my
inexperience with C#. And I noted in my post that  I had a better
understanding the second time.

I am totally persuaded that the toolset makes a major difference.

The whole approach under VS 2005 allows you to focus entirely on the
application and how you want it to behave. Hundreds (thousands?) of lines of
working, debugged code are generated for you (in whatever language you have
selected... C#, C++, or VB in the full version; I only have C# in the
Express version) and you only NEED to write specific code for specific
events. All of the necessary contexts are produced automatically as you
specify event handling.

In the same way that we don't write COBOL programs from scratch, but take a
previous program or template and modify it, VS2005 inserts what you actually
write into the right place in the code and does all of the housekeeping and
context for you. (You can change it if you want to, but so far I have not
had any need to.) Things like allocation of namespaces, connection to
appropriate support libraries, automatic scoping of variables and so on are
all wrapped around your code and you never have to worry about them. It's
like having someone present you with only the part of your COBOL template
that you want to deal with right now, and then ensuring that any variables
you create are automatically placed in the DATA division and any existing
variables are available on a drop down that appears as soon as you reach a
point where the syntax requires a dataname. (The list shrinks automatically
as you type further characters, or you can simply select the dataname you
want immediately from the list. There is no possibility of spelling or
syntax errors, unless you force them deliberately... I did this just to see
what compiler diagnostics looked like and how they were presented; if I
hadn't, I never would have seen this... :-)) Not only that, but a tooltip
describing the picture of the variable flashes up when you move the mouse
over the list. No more keeping listings of the data division while you write
procedure division code, or having to refer back to see what you named
something...it is all automatically at your fingertips.

That is just one tiny part of it. It is a truly interactive environment and
you interact with it to describe your application, rather than to write
code. The whole thing is component based and appropriate components are
simply dragged and dropped to where you want them. The DotNET framework is
an "object rich" environment, so a very large percentage of what you want is
already available. Things like list views, directory searches, etc are a
mouse click to install then you can decide what properties you want set, and
when.

I remember battling to get the standard directory/file selection dialog
included in an OO COBOL  (PowerCOBOL)application. It was difficult and
non-intuitive. There was no documentation provided by Fujitsu and I had no
idea what the component was even called or where it lived. I had to use an
Object Browser to locate it amongst thousands of Operating System
components, and then try and figure out what its methods, properties,
events, and interfaces were and provide the correct format for them in
COBOL. Finally got it working, but it took a day. In C#/DotNET I did the
same job in literally 5 minutes, dragging the component from the toolbar
directly into my codeview. And it displays in the Windows XP theme
automatically, so the program does not look "alien" to the user. I actually
wrote 9 lines of code to support this, and 6 of those are comments...:

Here's the C# code:

private void button1_Click(object sender, EventArgs e)    //provided by
VS2005
{
//provided by VS2005

/* User clicks "Browse for database" button. Open the standard dialog
* and put the selected file and path into the current form.
*
* This is only for MS ACCESS... other databases and ODBC have other
selections.
*
*/

openFileDialog1.InitialDirectory = "C:\\";         // start at the
beginning...
openFileDialog1.ShowDialog();
textBox1.Text = openFileDialog1.FileName;

}
//provided by VS2005

(I have included the // strings for clarity. They don't appear in the actual
listing.) The code to actually construct the "openFileDialog1" object is
automatically included in the right place in the C# program as soon as I
drag and drop the component icon from the DotNET toolbox. I never need to
refer or even look at it, just use the object immediately. Furthermore, it
has default properties that ensure that any selection made is a valid path
and the file selected actually exists...

First time I've done it in this environment... 5 minutes work.(Drag and drop
took seconds...) Tested it, worked perfectly first time (Jerry, please note
:-))

Here's the same stuff in OO COBOL... (about 10 hours work the first time I
wrote it, at least 1 hour to debug)...

ENVIRONMENT     DIVISION.
DATA            DIVISION.
WORKING-STORAGE SECTION.
01 FileMask Pic X(55) Value "ACCESS RDB Files (.mdb .mde)|*.mdb;*.mde|All
Files|*.*".
01 DeskFile.
12 FileName Pic X(255) Value Spaces.
12 Filler Pic X Value X"00".
01  ReturnValue pic s9(4) comp-5.
PROCEDURE       DIVISION.
a000.
Move Spaces to FileName
INVOKE POW-SELF "GetFileName" USING FileName
"Select ACCESS Database File"
FileMask
POW-CDOPEN
RETURNING ReturnValue
END-INVOKE

* If ReturnValue is true, user did select a db...
if ReturnValue = POW-TRUE
move FileName to DB-path
else
move spaces to DB-path
end-if
move DB-path to "Text" of CmText2
if DB-path NOT = spaces
move spaces to "Text" of CmText1
call 'SetCaption'
else
invoke CmText2 "SetFocus"
end-if

Pete Dashwood wrote:
> I remember battling to get the standard directory/file selection dialog
> included in an OO COBOL  (PowerCOBOL)application. It was difficult and
> non-intuitive. There was no documentation provided by Fujitsu and I had no
> idea what the component was even called or where it lived. I had to use an
> Object Browser to locate it amongst thousands of Operating System
> components, and then try and figure out what its methods, properties,
> events, and interfaces were and provide the correct format for them in
> COBOL. Finally got it working, but it took a day. In C#/DotNET I did the
> same job in literally 5 minutes, dragging the component from the toolbar
> directly into my codeview. And it displays in the Windows XP theme
> automatically, so the program does not look "alien" to the user. I actuall
y
> wrote 9 lines of code to support this, and 6 of those are comments...:
>
> Here's the C# code:
>
> private void button1_Click(object sender, EventArgs e)    //provided by
> VS2005
> {
> //provided by VS2005
>
> /* User clicks "Browse for database" button. Open the standard dialog
> * and put the selected file and path into the current form.
> *
> * This is only for MS ACCESS... other databases and ODBC have other
> selections.
> *
> */
>
> openFileDialog1.InitialDirectory = "C:\\";         // start at the
> beginning...
> openFileDialog1.ShowDialog();
> textBox1.Text = openFileDialog1.FileName;
>
> }
> //provided by VS2005

How about this?

method-id.  "button1_Click" final private.
linkage section.
01 sender object.
01 e System-EventArgs.
procedure division using by value  sender e.

*> everything above here generated
move "C:\\"
to self::"openFileDialog1"::"InitialDirectory"
invoke self::"openFileDialog1"::"ShowDialog"()
move self::"openFileDialog1"::"FileName"
to self::"textBox1"::"Text"
*> everything below here generated

end method "button1_Click".

:-)

Frank

"Frank Swarbrick" <infocat@earthlink.net> wrote in message
news:dElkh.4094$yx6.3439@newsread2.news.pas.earthlink.net...
> Pete Dashwood wrote: 
>
> How about this?
>
> method-id.  "button1_Click" final private.
> linkage section.
> 01 sender object.
> 01 e System-EventArgs.
> procedure division using by value  sender e.
>
> *> everything above here generated
>     move "C:\\"
>       to self::"openFileDialog1"::"InitialDirectory"
>     invoke self::"openFileDialog1"::"ShowDialog"()
>     move self::"openFileDialog1"::"FileName"
>       to self::"textBox1"::"Text"
> *> everything below here generated
>
> end method "button1_Click".
>
> :-)
>

OK, but what's your point?

You don't specifiy what the above actually is, so I can only speculate...

That looks very much like what I would expect DotNET COBOL to look like.
(As this runs in the VS2005 environment, the questions below would not
apply.)

If it is MicroFocus you will pay run time fees for it as well as the
compiler cost.

If it is either of the above, it cost several thousand dollars (hardly
competitive with the FREE C# solution); if it isn't, then I have some
questions...

How does openFileDialog1 get instantiated?
How do you know what library is required?
What happens if no file is selected?
Suppose the selected file is deleted moments after you select it?

I'm also still waiting for your comments on the nested perform I posted
sample code for, in response to your comment about that...

Am I wasting my time here? :-)

Pete.