Re: Productivity

Pete Dashwood<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> 12/27/06 5:59 PM >>>

"Frank Swarbrick" <Frank.Swarbrick@xxxxxxxxxxxxxx> wrote in message
news:4vfl66F1as7a4U1@xxxxxxxxxxxxxxxxxxxxx
Pete Dashwood<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> 12/27/06 3:40 AM >>>
"Frank Swarbrick" <infocat@xxxxxxxxxxxxx> wrote in message
<snipped>

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? :-)

Umm, maybe. I didn't know I was supposed to respond. I was only
commenting
that I had never used it; not that it was not a useful thing to have.

No Frank, what prompted me to post a comprehensive example, with an
explanation, was your comment:

(From your post in the 'Looking for sample code' thread dated 14th
December,
2006)

"For better or for worse I don't think I've ever written a complex perform
statement such as that. And I'm not sure I'd ever want to! :-)"

The last sentence certainly implies it is NOT a useful thing to have and,
as
I believe you are involved in teaching people COBOL (I may have confused
you
with someone else.. if you're not responsible for instructing others then
it
doesn't really matter and I wouldn't have taken the time to post), I
thought
some explanation/clarification from me might be in order.

I guess I'm sensitive about powerful constructs being banned on sites
(having worked in many places where they are) simply because people don't
take the trouble to understand how they work. When teachers start
dismissing
them too ... well, I was hoping to get you to look again.

I was only joking about that. If I ever came upon a situation where it
appears this construct would be useful I would have no problem using it. I
just don't recall ever coming upon such a thing. Or, if I did, I probably
didn't realize it and thus did something else. :-)

I am certainly *not* against using all of the power that COBOL provides. I
only recently used DECLARATIVES recently to handle file I/O errors. It's
actually quite nice, not having to check the status after each I/O. Should
be a bit more powerful to be *really* useful, but I'd be happy to see others
understand and use it. My manager at first was against my use of this, but
I convinced him by pointing out that it's an "implicit perform" rather than
an "implicit goto".

I've also recently been using UNSTRING, which I hadn't made a lot of use of
in the past. Below is something I was working on the other day. I had
hoped to be able to get it in to a single "UNSTRING", but I ended up with
two and I'm fairly happy with it. Essentially, it parses some input where
fields are delimited by '¦' (MSG-FIELD-DELIMITER), and for each field there
can be both a parm name and a parm value delimited by '='
(MSG-FIELD-SEPARATOR), or just a parm name (no '='). Each perform of
300-PARSE-INPUT-DATA should result in the parsing of one field, putting the
parm name into INPUT-STRING-ID and the parm value (if present) into
INPUT-STRING-PARM. If the field is a "null" field (essentially '¦¦') then
the flag END-OF-REQUEST should be set.

300-PARSE-INPUT-DATA.
MOVE LOW-VALUES TO INPUT-STRING-ID
INPUT-STRING-PARM
STRING-ID-DELIM
STRING-PARM-DELIM
MOVE ZEROES TO STRING-ID-LEN
STRING-PARM-LEN
IF INPUT-DATA-POS > INPUT-DATA-LENGTH
SET END-OF-REQUESTS TO TRUE
ELSE
UNSTRING INPUT-DATA
DELIMITED BY MSG-FIELD-DELIMITER
OR MSG-FIELD-SEPARATOR
INTO INPUT-STRING-ID
DELIMITER IN STRING-ID-DELIM
COUNT IN STRING-ID-LEN
POINTER INPUT-DATA-POS
END-UNSTRING
IF STRING-ID-DELIM = MSG-FIELD-SEPARATOR
UNSTRING INPUT-DATA
DELIMITED BY MSG-FIELD-DELIMITER
INTO INPUT-STRING-PARM
DELIMITER IN STRING-PARM-DELIM
COUNT IN STRING-PARM-LEN
POINTER INPUT-DATA-POS
END-UNSTRING
END-IF
IF STRING-ID-LEN = ZERO
SET END-OF-REQUEST TO TRUE
END-IF

I'm guessing there is no way to make this a single UNSTRING, but if anyone
can do it I'd love to see it! :-)

Of course you are not required to respond; I just hoped that you would. (My

post was in response to yours).

Sorry. I simply didn't feel I had any more to add.

Thanks for the clarification about NetExpress COBOL under VS 2005. It looks

very much as NetCOBOL for DotNET would.

There is no doubt that VS2005 is a superb development environment, whatever

language you are using

I sometimes (often?) wish I worked in a job where I could take advantage of
such tools, rather than just fooling around with them at home. Our Windows
applications team is now using Visual C# and sometimes I am jealous! (They
had been using Borland Delphi previously, but were having a hard time
finding Delphi developers.)

The questions are not relevant if VS2005 is used, as the DotNET framework
handles them.

When do we get .NET for the mainframe? :-)

Leaving all of that aside, I am coming to the conclusion that I AM wasting

my time here :-) As I'm on holiday at the moment I can afford to waste
some,
but in the coming year I'll look to wind down my contributions here.

That is up to you, of course. I, for one, value your contributions, even if
it sometimes appears that I don't. :-)

Frank


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
.