Re: What features should I demonstrate as being smart in WSDCi?

Thorbjørn,

In a former job I was a COBOL and CL programmer, and I pushed my
fellow programmers to give WDSc a real try. After an initial learning
curve, they would only go back to SEU under protest. Here are some of
the things I remember (from 2 years ago)

* Colorizing of the source. This is a big one. When the comments are
different color than the commands and different than variables and
constants, then it is all easier to see where there is an error. Code
that is commented out stands out.

* Outlining the COBOL source was of limited value In OPM COBOL it
shows any major sections of the code, and procedure names. It can be
handy to jump to a procedure or module quickly if needed. . It has
greater value for RPGLE source.

* Code snippets allows standardization of procedure, comments, working
storage, etc. It can copy code that gives you a form to fill in.

* One of the most helpful things was the ability to see and edit my
source in 2 (or 3 or 4) editors. I could be looking at Working
Storage in one, and the Procedure Division in the other, and make sure
that names and field sizes were correct, and/or copy paste names from
one to the other. Saved lots of typing.

* Find/Replace - with WDSc you can find ALL instances of your search,
and all you see are the results. You can then determine if that
Replace All is appropriate for your needs.

* Custom compile commands. For CL as well as COBOL I had compile
commands that would compile to a test library, or into production. I
had DDS compiles commands set up for printer files that were unique,
or could set up a user option that would archive a data file, then
compile the new version and copy the data from the old to the new.

* Don't cut the number of lines visible in the editor short. I get
really frustrated with SEU and not being able to see those extra lines
of code.

I agree with David about moving toward ILE. SEP debug is one good
reason, as are Intrinsic Functions and externally shared and updated
areas of working storage, and files. For example, I had a series of
modules that allowed one program to do all file I/O for the COBOL run
group. Because the file was defined as "IS ETERNAL" a record that was
read by one module could be processed by another. Flags set in
MODUALA can be used and changed by MODULEB. Each module was a
separate program compiled into ILE modules and bound together.

I hope this helps somewhat with your evaluation of WDSc

Jim


On Wed, Mar 17, 2010 at 2:46 PM, Thorbjoern Ravn Andersen
<ravn@xxxxxxxxxx> wrote: