[z/OS] REXX Programming for DBAs: a Rant

Philip Sevetson

[z/OS] REXX Programming for DBAs: a Rant
I have been a DBA now some three times longer than I was a programmer.
None the less, programmer habits persist for me.



In the late 1970's, if you were learning COBOL, it was assumed that you
would learn it in a Structured Programming style. The Structured
paradigm was top-down design driven, sometimes "GO TO"-less, and assumed
the use of only three command structures: sequential execution,
iteration, and branching. The preferred style of programming was to use
"loosely coupled" modules, where you passed to a subroutine (or a
paragraph) the information that it needed, it performed its operation,
and returned control to the calling module (usually by an EXIT statement
in an otherwise empty paragraph, or by the end of a paragraph). This
form of design has become more firmly defined over the succeeding years
with such structures as parameter-driven Database Stored Procedures,
which don't care where they're called from and return control to the
calling routine at the end of the procedure.



Except, apparently, for REXX programming.



This is not the fault of the REXX designers. They have provided for
transfer of control points (comparable to COBOL Paragraphs) with
statement labels and the PROCEDURE and RETURN statements. They have
provided for commenting in industry standard ways.



So why, whenever I look at a REXX program in any given environment,
doesn't ANYBODY do structured programming with it? The whole industry
is full of what we used to call spaghetti code, with statements
uncommented, unlabeled, executing in sequence with no explanation; full
of indexes named "I" and "J" and so forth; the only good thing I see
about the code I've inspected and modified at four different companies
where I've been involved in the process is that everyone uses CALL
instead of SIGNAL.



People, the code I've read looks like crap. Where is the pride in
workmanship? Where is the concern for the next person to look at this
stuff?



Put a label at the beginning of a group of related statements, such as
reading an input record and checking for valid data, and a RETURN at the
end of it, and put a number on the label indicating its relative
position in the program. Such as: 0100-ALLOCATE-FILES. Or
1000-CONTROL-LOGIC. Or 1600-DEFINE-SYSTABLES-CURSOR, and
1700-FETCH-SYSTABLES-CURSOR. Use PROCEDURE and EXPOSE. Use extensive
comments and put them in asterisk boxes or hyphen boxes. Get a book on
structured programming and read the basics. PLEASE.



Okay, rant over. We now return you to your regular technical forum.



--Phil Sevetson, NYCAPS DBA Support

Financial Information Services Agency of The City of New York

450 West 33rd Street, 4th Floor

New York, NY 10001

phone: (212) 857-1688

mailto: [login to unmask email] <mailto:[login to unmask email]>




______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Edward Long

Re: [z/OS] REXX Programming for DBAs: a Rant
(in response to Philip Sevetson)
And here I thought you were going to complain about the funky DB2 support.
The Open a Cursor just to get CURRENT TIMESTAMP is one of my favorites.

REXX code often suffers, as you correctly note, from the Q&D syndrome; that is, its only a Q&D script so why bother documenting it. 5 Years later, the stupid thing is still running every 8 hours.

There is no reason not to document these little gems as if they were real programs; wait, they are real programs!
Edward Long


--- On Wed, 1/7/09, Sevetson, Phil <[login to unmask email]> wrote:

> From: Sevetson, Phil <[login to unmask email]>
> Subject: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant
> To: [login to unmask email]
> Date: Wednesday, January 7, 2009, 11:18 AM
> I have been a DBA now some three times longer than I was a
> programmer.
> None the less, programmer habits persist for me.
>
>
>
> In the late 1970's, if you were learning COBOL, it was
> assumed that you
> would learn it in a Structured Programming style. The
> Structured
> paradigm was top-down design driven, sometimes "GO
> TO"-less, and assumed
> the use of only three command structures: sequential
> execution,
> iteration, and branching. The preferred style of
> programming was to use
> "loosely coupled" modules, where you passed to a
> subroutine (or a
> paragraph) the information that it needed, it performed its
> operation,
> and returned control to the calling module (usually by an
> EXIT statement
> in an otherwise empty paragraph, or by the end of a
> paragraph). This
> form of design has become more firmly defined over the
> succeeding years
> with such structures as parameter-driven Database Stored
> Procedures,
> which don't care where they're called from and
> return control to the
> calling routine at the end of the procedure.
>
>
>
> Except, apparently, for REXX programming.
>
>
>
> This is not the fault of the REXX designers. They have
> provided for
> transfer of control points (comparable to COBOL Paragraphs)
> with
> statement labels and the PROCEDURE and RETURN statements.
> They have
> provided for commenting in industry standard ways.
>
>
>
> So why, whenever I look at a REXX program in any given
> environment,
> doesn't ANYBODY do structured programming with it? The
> whole industry
> is full of what we used to call spaghetti code, with
> statements
> uncommented, unlabeled, executing in sequence with no
> explanation; full
> of indexes named "I" and "J" and so
> forth; the only good thing I see
> about the code I've inspected and modified at four
> different companies
> where I've been involved in the process is that
> everyone uses CALL
> instead of SIGNAL.
>
>
>
> People, the code I've read looks like crap. Where is
> the pride in
> workmanship? Where is the concern for the next person to
> look at this
> stuff?
>
>
>
> Put a label at the beginning of a group of related
> statements, such as
> reading an input record and checking for valid data, and a
> RETURN at the
> end of it, and put a number on the label indicating its
> relative
> position in the program. Such as: 0100-ALLOCATE-FILES.
> Or
> 1000-CONTROL-LOGIC. Or 1600-DEFINE-SYSTABLES-CURSOR, and
> 1700-FETCH-SYSTABLES-CURSOR. Use PROCEDURE and EXPOSE.
> Use extensive
> comments and put them in asterisk boxes or hyphen boxes.
> Get a book on
> structured programming and read the basics. PLEASE.
>
>
>
> Okay, rant over. We now return you to your regular
> technical forum.
>
>
>
> --Phil Sevetson, NYCAPS DBA Support
>
> Financial Information Services Agency of The City of New
> York
>
> 450 West 33rd Street, 4th Floor
>
> New York, NY 10001
>
> phone: (212) 857-1688
>
> mailto: [login to unmask email]
> <mailto:[login to unmask email]>
>
>
>
>
> ______________________________________________________________________
>
> * IDUG 2009 Denver, CO, USA * May 11-15, 2009 *
> http://IDUG.ORG/Events *
> ______________________________________________________________________
>
>
>
>
> IDUG.org was recently updated requiring members to use a
> new password. You should have gotten an e-mail with the
> temporary password assigned to your account. Please log in
> and update your member profile. If you are not already an
> IDUG.org member, please register at
> http://www.idug.org/component/juser/register.html

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Byron Pierce

Re: [z/OS] REXX Programming for DBAs: a Rant
(in response to Edward Long)
Because in the 70's/80's the [structured] programmers who wrote the code
were likely the same programmers who maintained it.... call it perhaps 'job
security' (aka 'job longevity') or just down-and-dirty programmers
entrenched in their trade (and proud of it).

But then came the 90's and object oriented programming with programmers
(contractors) coming and going like it was nobody's business. They didn't
have to make things look pretty, readable or maintainable - heck, it was
just a contract - someone else would maintain it ! Then, much of the work
started to move offshore.... need I say more ? Hmmmmm, kindof speaks to our
overall American industry, no ?

Phil, you're a dying breed... I commend you for your commentary. If one
programmer changes his or her method of coding, mission accomplished !

Byron C. Pierce
Prudential Retirement Technology
Database Services - DBA
280 Trumbull Street - H18C
Hartford, CT 06103-3509
Work: 860.534.4222
Fax: 860.534.3135



"Sevetson, Phil"
<[login to unmask email]
YC.GOV> To
[login to unmask email]
Sent by: DB2 Data cc
Base Discussion
List Subject
<[login to unmask email] [DB2-L] [z/OS] REXX Programming for
ORG> DBAs: a Rant



Wed 01/07/2009
11:18 AM


Please respond to
DB2 Database
Discussion list
at IDUG
<[login to unmask email]
2-l.org>





I have been a DBA now some three times longer than I was a programmer.
None the less, programmer habits persist for me.



In the late 1970's, if you were learning COBOL, it was assumed that you
would learn it in a Structured Programming style. The Structured
paradigm was top-down design driven, sometimes "GO TO"-less, and assumed
the use of only three command structures: sequential execution,
iteration, and branching. The preferred style of programming was to use
"loosely coupled" modules, where you passed to a subroutine (or a
paragraph) the information that it needed, it performed its operation,
and returned control to the calling module (usually by an EXIT statement
in an otherwise empty paragraph, or by the end of a paragraph). This
form of design has become more firmly defined over the succeeding years
with such structures as parameter-driven Database Stored Procedures,
which don't care where they're called from and return control to the
calling routine at the end of the procedure.



Except, apparently, for REXX programming.



This is not the fault of the REXX designers. They have provided for
transfer of control points (comparable to COBOL Paragraphs) with
statement labels and the PROCEDURE and RETURN statements. They have
provided for commenting in industry standard ways.



So why, whenever I look at a REXX program in any given environment,
doesn't ANYBODY do structured programming with it? The whole industry
is full of what we used to call spaghetti code, with statements
uncommented, unlabeled, executing in sequence with no explanation; full
of indexes named "I" and "J" and so forth; the only good thing I see
about the code I've inspected and modified at four different companies
where I've been involved in the process is that everyone uses CALL
instead of SIGNAL.



People, the code I've read looks like crap. Where is the pride in
workmanship? Where is the concern for the next person to look at this
stuff?



Put a label at the beginning of a group of related statements, such as
reading an input record and checking for valid data, and a RETURN at the
end of it, and put a number on the label indicating its relative
position in the program. Such as: 0100-ALLOCATE-FILES. Or
1000-CONTROL-LOGIC. Or 1600-DEFINE-SYSTABLES-CURSOR, and
1700-FETCH-SYSTABLES-CURSOR. Use PROCEDURE and EXPOSE. Use extensive
comments and put them in asterisk boxes or hyphen boxes. Get a book on
structured programming and read the basics. PLEASE.



Okay, rant over. We now return you to your regular technical forum.



--Phil Sevetson, NYCAPS DBA Support

Financial Information Services Agency of The City of New York

450 West 33rd Street, 4th Floor

New York, NY 10001

phone: (212) 857-1688

mailto: [login to unmask email] <mailto:[login to unmask email]>




______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You
should have gotten an e-mail with the temporary password assigned to your
account. Please log in and update your member profile. If you are not
already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html
(See attached file: C.htm)












______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Todd Burch

Re: [z/OS] REXX Programming for DBAs: a Rant
(in response to Byron Pierce)
Every language has a particular (stealing from the desktop world)
"look and feel". REXX is one of those languages whose typical look
and feel more closely resembles past programming experiences of those
who code in it.

Many years ago, I was in a code review up north at a client's shop, in
a big conference room with application programmers and DBA's, and I
was reviewing the REXX code used for utility automation. After
reading about a page worth of code, I looked up, paused, and asked the
group "what cobol programmer wrote this REXX code?" Everyone
laughed, and the guy who wrote it, a cobol programmer, admitted he
wrote it.

One of REXX's stated characteristics is that it tries not to get in
the way of "your" programming style - whatever that might be. And, I
think it does that quite well.

Yes, there is some ugly REXX out there. I try not to write any REXX
over a few hundred lines. After that, if there is that much logic
that needs to be applied, I revert to a compiled language. The small
investment in time to write in a HLL (or asm) pays off in the end,
many fold.

I agree with your rant. There's no excuse for poorly structured code
or code that is not commented. Some languages on certain platforms
have evolved to be somewhat self-documenting (like when using
Hungarian notation with C on Windows, or through Apple's Core XXXXX
APIs when using Objective-C on the Mac) and the programmer can relax a
bit in comments department for the mundane stuff. Assembler
programmers I think are some of the worst, like putting "CLEAR THE
REGISTER" after a XR R15,R15 instruction. Duh. Tell me WHY you are
clearing it.

Several years ago I wrote a commercial product that centered around
the use of REXX. With it, I shipped a sample REXX application that
generated REXX code to use the product. I actually received a call
from a Systems Programming manager, for the sole purpose of telling me
that my sample application "wrote better code" than his tenured
programmers. That's a sad state of affairs.


--- On Wed, 1/7/09, Sevetson, Phil <[login to unmask email]> wrote:

> From: Sevetson, Phil <[login to unmask email]>
> Subject: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant
> To: [login to unmask email]
> Date: Wednesday, January 7, 2009, 11:18 AM
> I have been a DBA now some three times longer than I was a
> programmer.
> None the less, programmer habits persist for me.
>
>
>
> In the late 1970's, if you were learning COBOL, it was
> assumed that you
> would learn it in a Structured Programming style. The
> Structured
> paradigm was top-down design driven, sometimes "GO
> TO"-less, and assumed
> the use of only three command structures: sequential
> execution,
> iteration, and branching. The preferred style of
> programming was to use
> "loosely coupled" modules, where you passed to a
> subroutine (or a
> paragraph) the information that it needed, it performed its
> operation,
> and returned control to the calling module (usually by an
> EXIT statement
> in an otherwise empty paragraph, or by the end of a
> paragraph). This
> form of design has become more firmly defined over the
> succeeding years
> with such structures as parameter-driven Database Stored
> Procedures,
> which don't care where they're called from and
> return control to the
> calling routine at the end of the procedure.
>
>
>
> Except, apparently, for REXX programming.
>
>
>
> This is not the fault of the REXX designers. They have
> provided for
> transfer of control points (comparable to COBOL Paragraphs)
> with
> statement labels and the PROCEDURE and RETURN statements.
> They have
> provided for commenting in industry standard ways.
>
>
>
> So why, whenever I look at a REXX program in any given
> environment,
> doesn't ANYBODY do structured programming with it? The
> whole industry
> is full of what we used to call spaghetti code, with
> statements
> uncommented, unlabeled, executing in sequence with no
> explanation; full
> of indexes named "I" and "J" and so
> forth; the only good thing I see
> about the code I've inspected and modified at four
> different companies
> where I've been involved in the process is that
> everyone uses CALL
> instead of SIGNAL.
>
>
>
> People, the code I've read looks like crap. Where is
> the pride in
> workmanship? Where is the concern for the next person to
> look at this
> stuff?
>
>
>
> Put a label at the beginning of a group of related
> statements, such as
> reading an input record and checking for valid data, and a
> RETURN at the
> end of it, and put a number on the label indicating its
> relative
> position in the program. Such as: 0100-ALLOCATE-FILES.
> Or
> 1000-CONTROL-LOGIC. Or 1600-DEFINE-SYSTABLES-CURSOR, and
> 1700-FETCH-SYSTABLES-CURSOR. Use PROCEDURE and EXPOSE.
> Use extensive
> comments and put them in asterisk boxes or hyphen boxes.
> Get a book on
> structured programming and read the basics. PLEASE.
>
>
>
> Okay, rant over. We now return you to your regular
> technical forum.
>
>
>
> --Phil Sevetson, NYCAPS DBA Support
>

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Richard Fazio

Re: [z/OS] REXX Programming for DBAs: a Rant
(in response to Todd Burch)
Phil,



Hmm let me think about this....



<Return rant >

So, you've never seen unstructured Cobol code? Unstructured Assembler?
Unstructured C, C++, Fortran, EasyTrieve Plus...take your pick.



I can right crappy code in any language (it's a gift).



I have written several Rexx execs that exceed 1000 lines. Each of these
EXECs I'm pretty proud of and published to this very community. As
such, the code is beautiful, well structured, well documented (300-500
lines of comments in each exec)....heck, I even lined up the IF
statements throughout the whole exec.



Regarding messages, I not only put out descriptive messages, I also have
my own Messages and Codes reference that I use consistently across ALL
the Rexx code that I publish: Say "RFMI0010 - IGNORING UNRECOGNIZED
KEYWORD: "KEY_WORD



As a programmer (or at least used to be) I always want people to see my
BEST work!



That all said, do I write little hacks that perform wild and crazy
things with little or no doc...probably, but if it's something complex,
you bet I put in doc and always use a structured style by default. Not
for anyone else but FOR ME. Who knows when I'll need that little
snippet of code and with my memory...I NEED THE NOTES :- )



So, the question is not "why do 'these people' write bad code"...the
question should be "why to 'these people' ALLOW themselves to be caught
writing bad code!"



The "art" of programming is not getting caught presenting a poor piece
of code by others.



Don't lump all Rexx programmers in one bunch. I would venture to say
that due to the extremely "change and go" nature of any dynamic
scripting language you will see this same loose style of programming.
Take a walk on the Unix side. Sed, awk, korn, pearl....now thar's some
hacks! It will make non-structured Rexx code look pretty darn nice.



</Return rant>



On second thought...never mind. : - P

faz



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Sevetson, Phil
Sent: Wednesday, January 07, 2009 10:18 AM
To: [login to unmask email]
Subject: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant



I have been a DBA now some three times longer than I was a programmer.
None the less, programmer habits persist for me.



In the late 1970's, if you were learning COBOL, it was assumed that you
would learn it in a Structured Programming style. The Structured
paradigm was top-down design driven, sometimes "GO TO"-less, and assumed
the use of only three command structures: sequential execution,
iteration, and branching. The preferred style of programming was to use
"loosely coupled" modules, where you passed to a subroutine (or a
paragraph) the information that it needed, it performed its operation,
and returned control to the calling module (usually by an EXIT statement
in an otherwise empty paragraph, or by the end of a paragraph). This
form of design has become more firmly defined over the succeeding years
with such structures as parameter-driven Database Stored Procedures,
which don't care where they're called from and return control to the
calling routine at the end of the procedure.



Except, apparently, for REXX programming.



This is not the fault of the REXX designers. They have provided for
transfer of control points (comparable to COBOL Paragraphs) with
statement labels and the PROCEDURE and RETURN statements. They have
provided for commenting in industry standard ways.



So why, whenever I look at a REXX program in any given environment,
doesn't ANYBODY do structured programming with it? The whole industry
is full of what we used to call spaghetti code, with statements
uncommented, unlabeled, executing in sequence with no explanation; full
of indexes named "I" and "J" and so forth; the only good thing I see
about the code I've inspected and modified at four different companies
where I've been involved in the process is that everyone uses CALL
instead of SIGNAL.



People, the code I've read looks like crap. Where is the pride in
workmanship? Where is the concern for the next person to look at this
stuff?



Put a label at the beginning of a group of related statements, such as
reading an input record and checking for valid data, and a RETURN at the
end of it, and put a number on the label indicating its relative
position in the program. Such as: 0100-ALLOCATE-FILES. Or
1000-CONTROL-LOGIC. Or 1600-DEFINE-SYSTABLES-CURSOR, and
1700-FETCH-SYSTABLES-CURSOR. Use PROCEDURE and EXPOSE. Use extensive
comments and put them in asterisk boxes or hyphen boxes. Get a book on
structured programming and read the basics. PLEASE.



Okay, rant over. We now return you to your regular technical forum.



--Phil Sevetson, NYCAPS DBA Support

Financial Information Services Agency of The City of New York

450 West 33rd Street, 4th Floor

New York, NY 10001

phone: (212) 857-1688

mailto: [login to unmask email] <mailto:[login to unmask email]>




________________________________

IDUG 2009 - North America * May 11-15 * Denver, Colorado, USA
< http://idug.org/lsna >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Philip Sevetson

Re: [z/OS] REXX Programming for DBAs: a Rant
(in response to Richard Fazio)
Rich,



Actually, I've seen unstructured code in a bunch of languages. I've
just been working with REXX and SQL and JCL almost exclusively for the
past year and a bit. I certainly didn't mean to imply that REXX is the
only place to find badly structured code.



I've been careful to name no names, and frankly don't want to know who
wrote the code I'm maintaining at the moment (conversion from DB2V8 to
DB2V9, the code parses the results of DISPLAY THREAD and issues CANCEL
THREADs in certain circumstances). Paul Fegan, in a different post
above, issued an example of good structured code (a little differently
than the way I write, but that's code for you). I don't think
_everybody_ writes badly structured or unstructured code, and for a
twenty-line-or-so piece of work even I have done it. But there's a
depressing amount of stuff that _is_ bad and _isn't_ only one page long,
out there.



I'm not on a "jihad" to improve code generally, though it'd be nice to
see good quality, of course. Just letting out some frustration to a
bunch of friends - you all - who have no doubt had similar experiences.



--Phil



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Fazio, Richard
Sent: Wednesday, January 07, 2009 4:04 PM
To: [login to unmask email]
Subject: Re: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant



Phil,



Hmm let me think about this....



<Return rant >

So, you've never seen unstructured Cobol code? Unstructured Assembler?
Unstructured C, C++, Fortran, EasyTrieve Plus...take your pick.



I can right crappy code in any language (it's a gift).



I have written several Rexx execs that exceed 1000 lines. Each of these
EXECs I'm pretty proud of and published to this very community. As
such, the code is beautiful, well structured, well documented (300-500
lines of comments in each exec)....heck, I even lined up the IF
statements throughout the whole exec.



Regarding messages, I not only put out descriptive messages, I also have
my own Messages and Codes reference that I use consistently across ALL
the Rexx code that I publish: Say "RFMI0010 - IGNORING UNRECOGNIZED
KEYWORD: "KEY_WORD



As a programmer (or at least used to be) I always want people to see my
BEST work!



That all said, do I write little hacks that perform wild and crazy
things with little or no doc...probably, but if it's something complex,
you bet I put in doc and always use a structured style by default. Not
for anyone else but FOR ME. Who knows when I'll need that little
snippet of code and with my memory...I NEED THE NOTES :- )



So, the question is not "why do 'these people' write bad code"...the
question should be "why to 'these people' ALLOW themselves to be caught
writing bad code!"



The "art" of programming is not getting caught presenting a poor piece
of code by others.



Don't lump all Rexx programmers in one bunch. I would venture to say
that due to the extremely "change and go" nature of any dynamic
scripting language you will see this same loose style of programming.
Take a walk on the Unix side. Sed, awk, korn, pearl....now thar's some
hacks! It will make non-structured Rexx code look pretty darn nice.



</Return rant>



On second thought...never mind. : - P

faz



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Sevetson, Phil
Sent: Wednesday, January 07, 2009 10:18 AM
To: [login to unmask email]
Subject: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant



I have been a DBA now some three times longer than I was a programmer.
None the less, programmer habits persist for me.



In the late 1970's, if you were learning COBOL, it was assumed that you
would learn it in a Structured Programming style. The Structured
paradigm was top-down design driven, sometimes "GO TO"-less, and assumed
the use of only three command structures: sequential execution,
iteration, and branching. The preferred style of programming was to use
"loosely coupled" modules, where you passed to a subroutine (or a
paragraph) the information that it needed, it performed its operation,
and returned control to the calling module (usually by an EXIT statement
in an otherwise empty paragraph, or by the end of a paragraph). This
form of design has become more firmly defined over the succeeding years
with such structures as parameter-driven Database Stored Procedures,
which don't care where they're called from and return control to the
calling routine at the end of the procedure.



Except, apparently, for REXX programming.



This is not the fault of the REXX designers. They have provided for
transfer of control points (comparable to COBOL Paragraphs) with
statement labels and the PROCEDURE and RETURN statements. They have
provided for commenting in industry standard ways.



So why, whenever I look at a REXX program in any given environment,
doesn't ANYBODY do structured programming with it? The whole industry
is full of what we used to call spaghetti code, with statements
uncommented, unlabeled, executing in sequence with no explanation; full
of indexes named "I" and "J" and so forth; the only good thing I see
about the code I've inspected and modified at four different companies
where I've been involved in the process is that everyone uses CALL
instead of SIGNAL.



People, the code I've read looks like crap. Where is the pride in
workmanship? Where is the concern for the next person to look at this
stuff?



Put a label at the beginning of a group of related statements, such as
reading an input record and checking for valid data, and a RETURN at the
end of it, and put a number on the label indicating its relative
position in the program. Such as: 0100-ALLOCATE-FILES. Or
1000-CONTROL-LOGIC. Or 1600-DEFINE-SYSTABLES-CURSOR, and
1700-FETCH-SYSTABLES-CURSOR. Use PROCEDURE and EXPOSE. Use extensive
comments and put them in asterisk boxes or hyphen boxes. Get a book on
structured programming and read the basics. PLEASE.



Okay, rant over. We now return you to your regular technical forum.



--Phil Sevetson, NYCAPS DBA Support

Financial Information Services Agency of The City of New York

450 West 33rd Street, 4th Floor

New York, NY 10001

phone: (212) 857-1688

mailto: [login to unmask email] <mailto:[login to unmask email]>




________________________________

IDUG 2009 - North America * May 11-15 * Denver, Colorado, USA
< http://idug.org/lsna >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


________________________________

IDUG 2009 - North America * May 11-15 * Denver, Colorado, USA
< http://idug.org/lsna >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >



=========
Confidentiality Notice: This e-mail communication, and any attachments, contains confidential and privileged information for the exclusive use of the recipient(s) named above. If you are not an intended recipient, or the employee or agent responsible to deliver it to an intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communication in error, please notify me immediately by replying to this message and delete this communication from your computer. Thank you.

Any opinions, expressed or implied, presented are solely those of the author and do not necessarily represent the opinions of the agency or the City.
=========



______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Sharon Heller

Re: [z/OS] REXX Programming for DBAs: a Rant
(in response to Philip Sevetson)
You have a secure email message waiting for you from Sharon L Heller at AES/PHEAA with the subject: Re: [z/OS] REXX Programming for DBAs: a Rant.

How to Retrieve Your Message

To retrieve your message from Sharon L Heller with the subject: Re: [z/OS] REXX Programming for DBAs: a Rant, go to:
https://securemail.aessuccess.org/messenger/msg?x=d-27604679-nYJRlYnzFuJQ4ET9

This message will be available until 03/08/2009.

Why You Are Receiving this Email

AES/PHEAA has sent you a message that may include sensitive information or personal data, as defined by federal law. To protect the privacy of this information, the email has been encrypted.


Personal data protected by federal law includes:
Social Security numbers
Driver's license numbers
credit reports/scores


If you have questions regarding the authenticity of this message, please
visit us online at www.aesSuccess.org/securemail, or contact us:

Phone: 1-800-233-0557
Email: [login to unmask email]
Postal mail: AES/PHEAA
1200 N 7th St
Harrisburg, PA 17102


=====
This message contains privileged and confidential information intended for the
above addressees only. If you receive this message in error please delete or
destroy this message and/or attachments.

The sender of this message will fully cooperate in the civil and criminal
prosecution of any individual engaging in the unauthorized use of this message.
=====

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Richard Fazio

Re: [z/OS] REXX Programming for DBAs: a Rant
(in response to Sharon Heller)
Phil,



I'm right there with you...just having a bit of fun.



I detest sloppy, poorly written code. I think we should all be on a
quest to accept only the highest quality code. There's no excuse for
poor doc or no doc.



Coders in the 60's and 70's were highly technical and true
pioneers...privileged few whom were given resources to create software.


The 80s brought a glut of programmers into the fray with more resources
than knowledge and a "let's just try it" approach to coding.

The 90s bring us the instant gratification of the web and real 4GL
programming. Self describing, self-documenting programming. A promise
that has just started to come to fruition (AbInitio and Data Stage are
pushing massive data volumes efficiently and graphically).



Methodology, SDLC, whatever you call it has moved us out of the cowboy
wild west of the 80's. Structure, discipline and procedure should
prevent crap from being promoted beyond POC status.



We need to keep our expectations high and our tolerance for crap way way
low.



By the way...crappy database design counts too. Who knows...maybe this
DB2 Thang will catch on.



Keep up the faith!

faz



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Sevetson, Phil
Sent: Wednesday, January 07, 2009 3:48 PM
To: [login to unmask email]
Subject: Re: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant



Rich,



Actually, I've seen unstructured code in a bunch of languages. I've
just been working with REXX and SQL and JCL almost exclusively for the
past year and a bit. I certainly didn't mean to imply that REXX is the
only place to find badly structured code.



I've been careful to name no names, and frankly don't want to know who
wrote the code I'm maintaining at the moment (conversion from DB2V8 to
DB2V9, the code parses the results of DISPLAY THREAD and issues CANCEL
THREADs in certain circumstances). Paul Fegan, in a different post
above, issued an example of good structured code (a little differently
than the way I write, but that's code for you). I don't think
_everybody_ writes badly structured or unstructured code, and for a
twenty-line-or-so piece of work even I have done it. But there's a
depressing amount of stuff that _is_ bad and _isn't_ only one page long,
out there.



I'm not on a "jihad" to improve code generally, though it'd be nice to
see good quality, of course. Just letting out some frustration to a
bunch of friends - you all - who have no doubt had similar experiences.



--Phil



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Fazio, Richard
Sent: Wednesday, January 07, 2009 4:04 PM
To: [login to unmask email]
Subject: Re: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant



Phil,



Hmm let me think about this....



<Return rant >

So, you've never seen unstructured Cobol code? Unstructured Assembler?
Unstructured C, C++, Fortran, EasyTrieve Plus...take your pick.



I can right crappy code in any language (it's a gift).



I have written several Rexx execs that exceed 1000 lines. Each of these
EXECs I'm pretty proud of and published to this very community. As
such, the code is beautiful, well structured, well documented (300-500
lines of comments in each exec)....heck, I even lined up the IF
statements throughout the whole exec.



Regarding messages, I not only put out descriptive messages, I also have
my own Messages and Codes reference that I use consistently across ALL
the Rexx code that I publish: Say "RFMI0010 - IGNORING UNRECOGNIZED
KEYWORD: "KEY_WORD



As a programmer (or at least used to be) I always want people to see my
BEST work!



That all said, do I write little hacks that perform wild and crazy
things with little or no doc...probably, but if it's something complex,
you bet I put in doc and always use a structured style by default. Not
for anyone else but FOR ME. Who knows when I'll need that little
snippet of code and with my memory...I NEED THE NOTES :- )



So, the question is not "why do 'these people' write bad code"...the
question should be "why to 'these people' ALLOW themselves to be caught
writing bad code!"



The "art" of programming is not getting caught presenting a poor piece
of code by others.



Don't lump all Rexx programmers in one bunch. I would venture to say
that due to the extremely "change and go" nature of any dynamic
scripting language you will see this same loose style of programming.
Take a walk on the Unix side. Sed, awk, korn, pearl....now thar's some
hacks! It will make non-structured Rexx code look pretty darn nice.



</Return rant>



On second thought...never mind. : - P

faz



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Sevetson, Phil
Sent: Wednesday, January 07, 2009 10:18 AM
To: [login to unmask email]
Subject: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant



I have been a DBA now some three times longer than I was a programmer.
None the less, programmer habits persist for me.



In the late 1970's, if you were learning COBOL, it was assumed that you
would learn it in a Structured Programming style. The Structured
paradigm was top-down design driven, sometimes "GO TO"-less, and assumed
the use of only three command structures: sequential execution,
iteration, and branching. The preferred style of programming was to use
"loosely coupled" modules, where you passed to a subroutine (or a
paragraph) the information that it needed, it performed its operation,
and returned control to the calling module (usually by an EXIT statement
in an otherwise empty paragraph, or by the end of a paragraph). This
form of design has become more firmly defined over the succeeding years
with such structures as parameter-driven Database Stored Procedures,
which don't care where they're called from and return control to the
calling routine at the end of the procedure.



Except, apparently, for REXX programming.



This is not the fault of the REXX designers. They have provided for
transfer of control points (comparable to COBOL Paragraphs) with
statement labels and the PROCEDURE and RETURN statements. They have
provided for commenting in industry standard ways.



So why, whenever I look at a REXX program in any given environment,
doesn't ANYBODY do structured programming with it? The whole industry
is full of what we used to call spaghetti code, with statements
uncommented, unlabeled, executing in sequence with no explanation; full
of indexes named "I" and "J" and so forth; the only good thing I see
about the code I've inspected and modified at four different companies
where I've been involved in the process is that everyone uses CALL
instead of SIGNAL.



People, the code I've read looks like crap. Where is the pride in
workmanship? Where is the concern for the next person to look at this
stuff?



Put a label at the beginning of a group of related statements, such as
reading an input record and checking for valid data, and a RETURN at the
end of it, and put a number on the label indicating its relative
position in the program. Such as: 0100-ALLOCATE-FILES. Or
1000-CONTROL-LOGIC. Or 1600-DEFINE-SYSTABLES-CURSOR, and
1700-FETCH-SYSTABLES-CURSOR. Use PROCEDURE and EXPOSE. Use extensive
comments and put them in asterisk boxes or hyphen boxes. Get a book on
structured programming and read the basics. PLEASE.



Okay, rant over. We now return you to your regular technical forum.



--Phil Sevetson, NYCAPS DBA Support

Financial Information Services Agency of The City of New York

450 West 33rd Street, 4th Floor

New York, NY 10001

phone: (212) 857-1688

mailto: [login to unmask email] <mailto:[login to unmask email]>



________________________________

=========
Confidentiality Notice: This e-mail communication, and any attachments,
contains confidential and privileged information for the exclusive use
of the recipient(s) named above. If you are not an intended recipient,
or the employee or agent responsible to deliver it to an intended
recipient, you are hereby notified that you have received this
communication in error and that any review, disclosure, dissemination,
distribution or copying of it or its contents is prohibited. If you have
received this communication in error, please notify me immediately by
replying to this message and delete this communication from your
computer. Thank you.

Any opinions, expressed or implied, presented are solely those of the
author and do not necessarily represent the opinions of the agency or
the City.
=========


________________________________

IDUG 2009 - North America * May 11-15 * Denver, Colorado, USA
< http://idug.org/lsna >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


________________________________

IDUG 2009 - North America * May 11-15 * Denver, Colorado, USA
< http://idug.org/lsna >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


________________________________

IDUG 2009 - North America * May 11-15 * Denver, Colorado, USA
< http://idug.org/lsna >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

cliff boley

Re: [z/OS] REXX Programming for DBAs: a Rant
(in response to Richard Fazio)
I blame the current state of programming & software on MicroSoft and
General Motors.

MicroSoft's 'just good enough' and GM's 'get it out the door as cheap as
possible and let the buyers make it work' business models seems to have

permeated the industry.

And I understand Phil's plight, I've been cleaning up some PERL scripts,
s/[(]+/ /g; now that's good code.



cliff:-)

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Fazio, Richard
Sent: Wednesday, January 07, 2009 8:39 PM
To: [login to unmask email]
Subject: Re: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant



Phil,



I'm right there with you...just having a bit of fun.



I detest sloppy, poorly written code. I think we should all be
on a quest to accept only the highest quality code. There's no excuse
for poor doc or no doc.



Coders in the 60's and 70's were highly technical and true
pioneers...privileged few whom were given resources to create software.


The 80s brought a glut of programmers into the fray with more
resources than knowledge and a "let's just try it" approach to coding.

The 90s bring us the instant gratification of the web and real
4GL programming. Self describing, self-documenting programming. A
promise that has just started to come to fruition (AbInitio and Data
Stage are pushing massive data volumes efficiently and graphically).



Methodology, SDLC, whatever you call it has moved us out of the
cowboy wild west of the 80's. Structure, discipline and procedure
should prevent crap from being promoted beyond POC status.



We need to keep our expectations high and our tolerance for crap
way way low.



By the way...crappy database design counts too. Who
knows...maybe this DB2 Thang will catch on.



Keep up the faith!

faz




________________________________


From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Sevetson, Phil
Sent: Wednesday, January 07, 2009 3:48 PM
To: [login to unmask email]
Subject: Re: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant



Rich,



Actually, I've seen unstructured code in a bunch of languages.
I've just been working with REXX and SQL and JCL almost exclusively for
the past year and a bit. I certainly didn't mean to imply that REXX is
the only place to find badly structured code.



I've been careful to name no names, and frankly don't want to
know who wrote the code I'm maintaining at the moment (conversion from
DB2V8 to DB2V9, the code parses the results of DISPLAY THREAD and issues
CANCEL THREADs in certain circumstances). Paul Fegan, in a different
post above, issued an example of good structured code (a little
differently than the way I write, but that's code for you). I don't
think _everybody_ writes badly structured or unstructured code, and for
a twenty-line-or-so piece of work even I have done it. But there's a
depressing amount of stuff that _is_ bad and _isn't_ only one page long,
out there.



I'm not on a "jihad" to improve code generally, though it'd be
nice to see good quality, of course. Just letting out some frustration
to a bunch of friends - you all - who have no doubt had similar
experiences.



--Phil




________________________________


From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Fazio, Richard
Sent: Wednesday, January 07, 2009 4:04 PM
To: [login to unmask email]
Subject: Re: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant



Phil,



Hmm let me think about this....



<Return rant >

So, you've never seen unstructured Cobol code? Unstructured
Assembler? Unstructured C, C++, Fortran, EasyTrieve Plus...take your
pick.



I can right crappy code in any language (it's a gift).



I have written several Rexx execs that exceed 1000 lines. Each
of these EXECs I'm pretty proud of and published to this very community.
As such, the code is beautiful, well structured, well documented
(300-500 lines of comments in each exec)....heck, I even lined up the IF
statements throughout the whole exec.



Regarding messages, I not only put out descriptive messages, I
also have my own Messages and Codes reference that I use consistently
across ALL the Rexx code that I publish: Say "RFMI0010 - IGNORING
UNRECOGNIZED KEYWORD: "KEY_WORD



As a programmer (or at least used to be) I always want people to
see my BEST work!



That all said, do I write little hacks that perform wild and
crazy things with little or no doc...probably, but if it's something
complex, you bet I put in doc and always use a structured style by
default. Not for anyone else but FOR ME. Who knows when I'll need that
little snippet of code and with my memory...I NEED THE NOTES :- )



So, the question is not "why do 'these people' write bad
code"...the question should be "why to 'these people' ALLOW themselves
to be caught writing bad code!"



The "art" of programming is not getting caught presenting a poor
piece of code by others.



Don't lump all Rexx programmers in one bunch. I would venture
to say that due to the extremely "change and go" nature of any dynamic
scripting language you will see this same loose style of programming.
Take a walk on the Unix side. Sed, awk, korn, pearl....now thar's some
hacks! It will make non-structured Rexx code look pretty darn nice.



</Return rant>



On second thought...never mind. : - P

faz




________________________________


From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Sevetson, Phil
Sent: Wednesday, January 07, 2009 10:18 AM
To: [login to unmask email]
Subject: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant



I have been a DBA now some three times longer than I was a
programmer. None the less, programmer habits persist for me.



In the late 1970's, if you were learning COBOL, it was assumed
that you would learn it in a Structured Programming style. The
Structured paradigm was top-down design driven, sometimes "GO TO"-less,
and assumed the use of only three command structures: sequential
execution, iteration, and branching. The preferred style of programming
was to use "loosely coupled" modules, where you passed to a subroutine
(or a paragraph) the information that it needed, it performed its
operation, and returned control to the calling module (usually by an
EXIT statement in an otherwise empty paragraph, or by the end of a
paragraph). This form of design has become more firmly defined over the
succeeding years with such structures as parameter-driven Database
Stored Procedures, which don't care where they're called from and return
control to the calling routine at the end of the procedure.



Except, apparently, for REXX programming.



This is not the fault of the REXX designers. They have provided
for transfer of control points (comparable to COBOL Paragraphs) with
statement labels and the PROCEDURE and RETURN statements. They have
provided for commenting in industry standard ways.



So why, whenever I look at a REXX program in any given
environment, doesn't ANYBODY do structured programming with it? The
whole industry is full of what we used to call spaghetti code, with
statements uncommented, unlabeled, executing in sequence with no
explanation; full of indexes named "I" and "J" and so forth; the only
good thing I see about the code I've inspected and modified at four
different companies where I've been involved in the process is that
everyone uses CALL instead of SIGNAL.



People, the code I've read looks like crap. Where is the pride
in workmanship? Where is the concern for the next person to look at
this stuff?



Put a label at the beginning of a group of related statements,
such as reading an input record and checking for valid data, and a
RETURN at the end of it, and put a number on the label indicating its
relative position in the program. Such as: 0100-ALLOCATE-FILES. Or
1000-CONTROL-LOGIC. Or 1600-DEFINE-SYSTABLES-CURSOR, and
1700-FETCH-SYSTABLES-CURSOR. Use PROCEDURE and EXPOSE. Use extensive
comments and put them in asterisk boxes or hyphen boxes. Get a book on
structured programming and read the basics. PLEASE.



Okay, rant over. We now return you to your regular technical
forum.



--Phil Sevetson, NYCAPS DBA Support

Financial Information Services Agency of The City of New York

450 West 33rd Street, 4th Floor

New York, NY 10001

phone: (212) 857-1688

mailto: [login to unmask email] <mailto:[login to unmask email]>




________________________________


=========
Confidentiality Notice: This e-mail communication, and any
attachments, contains confidential and privileged information for the
exclusive use of the recipient(s) named above. If you are not an
intended recipient, or the employee or agent responsible to deliver it
to an intended recipient, you are hereby notified that you have received
this communication in error and that any review, disclosure,
dissemination, distribution or copying of it or its contents is
prohibited. If you have received this communication in error, please
notify me immediately by replying to this message and delete this
communication from your computer. Thank you.

Any opinions, expressed or implied, presented are solely those
of the author and do not necessarily represent the opinions of the
agency or the City.
=========


________________________________

IDUG 2009 - North America * May 11-15 * Denver, Colorado, USA
< http://idug.org/lsna >

IDUG.org < http://www.idug.org > was recently updated requiring
members to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


________________________________

IDUG 2009 - North America * May 11-15 * Denver, Colorado, USA
< http://idug.org/lsna >

IDUG.org < http://www.idug.org > was recently updated requiring
members to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


________________________________

IDUG 2009 - North America * May 11-15 * Denver, Colorado, USA
< http://idug.org/lsna >

IDUG.org < http://www.idug.org > was recently updated requiring
members to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


________________________________

IDUG 2009 - Australasia * 18-20 March * Melbourne, Australia
< http://idug.org/lsAU >

IDUG.org < http://www.idug.org > was recently updated requiring
members to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Glen Gasior

Re: [z/OS] REXX Programming for DBAs: a Rant
(in response to cliff boley)
From the Unix Hater's Handbook.

In an announcement that has stunned the computer industry, Ken Thompson,

Dennis Ritchie, and Brian Kernighan admitted that the Unix operating

system and C programming language created by them is an elaborate April

Fools prank kept alive for more than 20 years. Speaking at the recent

UnixWorld Software Development Forum, Thompson revealed the following:

"In 1969, AT&T had just terminated their work with the GE/AT&T

Multics project. Brian and I had just started working with an early

release of Pascal from Professor Nichlaus Wirth's ETH labs in Switzerland,

and we were impressed with its elegant simplicity and

power. Dennis had just finished reading *Bored of the Rings*, a hilarious

National Lampoon parody of the great Tolkien *Lord of the Rings
*

trilogy. As a lark, we decided to do parodies of the Multics environment

and Pascal. Dennis and I were responsible for the operating

environment. We looked at Multics and designed the new system to

be as complex and cryptic as possible to maximize casual users' frustration

levels, calling it Unix as a parody of Multics, as well as other

more risque allusions.

"Then Dennis and Brian worked on a truly warped version of Pascal,

called "A." When we found others were actually trying to create real

programs with A, we quickly added additional cryptic features and

evolved into B, BCPL, and finally C. We stopped when we got a

clean compile on the following syntax:

for(;P("\n"),R=;P("|"))for(e=C;e=P("_"+(*u++/

8)%2))P("|"+(*u/4)%2);

"To think that modern programmers would try to use a language that

allowed such a statement was beyond our comprehension! We actually

thought of selling this to the Soviets to set their computer science

progress back 20 or more years.


On Wed, Jan 7, 2009 at 10:18 AM, Sevetson, Phil <[login to unmask email]>wrote:

> I have been a DBA now some three times longer than I was a programmer.
> None the less, programmer habits persist for me.
>
>
>
> In the late 1970's, if you were learning COBOL, it was assumed that you
> would learn it in a Structured Programming style. The Structured paradigm
> was top-down design driven, sometimes "GO TO"-less, and assumed the use of
> only three command structures: sequential execution, iteration, and
> branching. The preferred style of programming was to use "loosely coupled"
> modules, where you passed to a subroutine (or a paragraph) the information
> that it needed, it performed its operation, and returned control to the
> calling module (usually by an EXIT statement in an otherwise empty
> paragraph, or by the end of a paragraph). This form of design has become
> more firmly defined over the succeeding years with such structures as
> parameter-driven Database Stored Procedures, which don't care where they're
> called from and return control to the calling routine at the end of the
> procedure.
>
>
>
> Except, apparently, for REXX programming.
>
>
>
> This is not the fault of the REXX designers. They have provided for
> transfer of control points (comparable to COBOL Paragraphs) with statement
> labels and the PROCEDURE and RETURN statements. They have provided for
> commenting in industry standard ways.
>
>
>
> So why, whenever I look at a REXX program in any given environment, doesn't
> ANYBODY do structured programming with it? The whole industry is full of
> what we used to call spaghetti code, with statements uncommented, unlabeled,
> executing in sequence with no explanation; full of indexes named "I" and "J"
> and so forth; the only good thing I see about the code I've inspected and
> modified at four different companies where I've been involved in the process
> is that everyone uses CALL instead of SIGNAL.
>
>
>
> People, the code I've read looks like crap. Where is the pride in
> workmanship? Where is the concern for the next person to look at this
> stuff?
>
>
>
> Put a label at the beginning of a group of related statements, such as
> reading an input record and checking for valid data, and a RETURN at the end
> of it, and put a number on the label indicating its relative position in the
> program. Such as: 0100-ALLOCATE-FILES. Or 1000-CONTROL-LOGIC. Or
> 1600-DEFINE-SYSTABLES-CURSOR, and 1700-FETCH-SYSTABLES-CURSOR. Use
> PROCEDURE and EXPOSE. Use extensive comments and put them in asterisk boxes
> or hyphen boxes. Get a book on structured programming and read the basics.
> PLEASE.
>
>
>
> Okay, rant over. We now return you to your regular technical forum.
>
>
>
> *--Phil Sevetson, NYCAPS DBA Support*
>
> *Financial Information Services Agency of The City of New York*
>
> *450 West 33rd Street**, 4th Floor*
>
> *New York**, NY 10001*
>
> *phone: (212) 857-1688*
>
> *mailto: [login to unmask email] <[login to unmask email]>v*
>
>
>
> ------------------------------
>
> *IDUG 2009 - North America * May 11-15 * Denver, Colorado, USA* < http://idug.org/lsna >
>
> *IDUG.org* < http://www.idug.org/ > was recently updated requiring members
> to use a new password. You should have gotten an e-mail with the temporary
> password assigned to your account. Please log in and update your member
> profile. If you are not already an IDUG.org member, please register here. < http://www.idug.org/component/juser/register.html >
>



--
Glen J. Gasior
(630) 712-2104
Chicago, Illinois 60611
"Leadership that improves the process of change"

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Max Scarpa

Re: [z/OS] REXX Programming for DBAs: a Rant
(in response to Glen Gasior)
I'm a REXX user/programmer. I never was a programmer. I was born something
else. Neverthless I never used SIGNAL or GOTO, I always used branching
and all other cited stuff. I tried to be a structured programmer. I use
subroutine CALL but I tested it's more expensive in most of cases than
'embedding' the same code so for simple REXX I prefere to avoid to use
CALL. I've always tried to write REXX as surgeons do their cuts, ie. as
little and simpler as possible. Neverthless in almost 20 years of REXX
programming, some doing very complicated things for DB2 I saw/heard:

- The most common sport in IT world is to say the previous programmer had
not enough experience.
- Sometimes you inherited the code, done by a consultant who wrote it
complicated to maintain her/his contract longer.
- Sometimes your REXX is not well-written because you don't use lower
case.
- Sometimes your code is written in a great hurry so it can be defined, if
you're lucky, 'disgusting'.
- Sometimes you write a REXX while a WLM problem is waiting for you and
later you've to clean windows (the things with glass, not the operating
system).
- Sometimes you have to write code in this way because your boss want it
in this way.
- Sometimes you aren't in good mood (maybe you wife's/husband's fault).
- Sometimes who evaluate your code doesn't know anything about, just to
say, DB2.
- Someone thinks world is a perfect sphere, or is perfectly flat, but it
isn't.
- Someone thinks Elvis is still alive and writing structured REXX
programs.
- ............(to be continued)

One thing is war in theory, another on battlefield. This doesn't means
you are authorized to write garbage/spaghetti code (which could sound
offensive for some Italians) but no one is without sin.

Just to add rant to a rant.

Max Scarpa



______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Paul Ogborne

Re: [z/OS] REXX Programming for DBAs: a Rant
(in response to Max Scarpa)
Hi Phil,

For me it depends on what the problem is and how long I have to solve it.  For typical, quick one-off solutions I have to look hard at REXX code to understand it a week after it has been written but then I never tend to reuse such code (I also probably don't delete it either and perhaps I should).
For REXX written for myself and for other people to use that will need to be around for a bit then good structure and comments are a must.
No need for a Fabergé egg if you only want to make an omlette ;-)

Regards,
Paul.

-----Original Message-----
From: Sevetson, Phil <[login to unmask email]>
To: [login to unmask email]
Sent: Wed, 7 Jan 2009 16:18
Subject: [DB2-L] [z/OS] REXX Programming for DBAs: a Rant




I have been a DBA now some three times longer than I was a programmer.  None the less, programmer habits persist for me.

 

In the late 1970’s, if you were learning COBOL, it was assumed that you would learn it in a Structured Programming style.  The Structured paradigm was top-down design driven, sometimes “GO TO”-less, and assumed the use of only three command structures:  sequential execution, iteration, and branching.  The preferred style of programming was to use “loosely coupled” modules, where you passed to a subroutine (or a paragraph) the information that it needed, it performed its operation, and returned control to the calling module (usually by an EXIT statement in an otherwise empty paragraph, or by the20end of a paragraph).  This form of design has become more firmly defined over the succeeding years with such structures as parameter-driven Database Stored Procedures, which don’t care where they’re called from and return control to the calling routine at the end of the procedure.

 

Except, apparently, for REXX programming.

 

This is not the fault of the REXX designers.  They have provided for transfer of control points (comparable to COBOL Paragraphs) with statement labels and the PROCEDURE and RETURN statements.  They have provided for commenting in industry standard ways. 

 

So why, whenever I look at a REXX program in any given environment, doesn’t ANYBODY do structured programming with it?  The whole industry is full of what we used to call spaghetti code, with statements uncommented, unlabeled, executing in sequence with no explanation; full of indexes named “I” and “J” and so forth; the only good thing I see about the code I’ve inspected and modified at four different companies where I’ve been involved in the process is that everyone uses CALL instead of SIGNAL.

 

People, the code I’ve read looks like crap.  Where is the pride in workmanship?  Where is the concern for the next person to look at this stuff?

 

Put a label at the beginning of a group of related statements, such as reading an input record and checking for valid data, and a RETURN at the end of it, and pu
t a number on the label indicating its relative position in the program.  Such as:  0100-ALLOCATE-FILES.  Or 1000-CONTROL-LOGIC.  Or 1600-DEFINE-SYSTABLES-CURSOR, and 1700-FETCH-SYSTABLES-CURSOR.  Use PROCEDURE and EXPOSE.  Use extensive comments and put them in asterisk boxes or hyphen boxes.  Get a book on structured programming and read the basics.  PLEASE.

 

Okay, rant over.  We now return you to your regular technical forum.

 


--Phil Sevetson, NYCAPS DBA Support

Financial Information Services Agency of The City of New York

450 West 33rd Street, 4th Floor

New York, NY 10001

phone: (212) 857-1688

mailto: [login to unmask email]


 



IDUG 2009 - North America * May 11-15 * Denver, Colorado, USA
IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register here.


IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register here.


________________________________________________________________________
AOL Email goes Mobile! You can now read your AOL Emails whilst on the move. Sign up for a free AOL Email account with unlimited storage today.

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html