Re: Learning one's tools

[Dave Beagle]

Nothing I’ve stated is untrue. The jealousy from likely non college graduates 
is obvious.


Sent from Yahoo Mail for iPhone


On Monday, March 18, 2024, 11:16 AM, David Crayford 
<0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:

> On 18 Mar 2024, at 22:33, Dave Beagle 
> <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
> 
> LOL, I was a programmer for almost half my 40+ year career. IMS/COBOL DB/DC 
> at first. Later mostly COBOL CICS and COBOL DB2. So I’m excellent in COBOL. 
> In college, I programmed in PL/I, fortran, watfiv, pascal, and some others. 
> Logic is my forte. Math major helps. (Double major Comp Sci)
> 

And a doctorate in bullshit


> As for code reviews, I’ve worked at 15 companies of various sizes and none of 
> them did code reviews. One company tried to implement, but it was a cluster 
> and a huge waste of time. Imagine having a staff of 10, who not only have 
> their own coding requirements and time constraints, but now have to hand hold 
> the less qualified employees. If you have a staff of 10 and they are making 
> $50/hour and up and each code review takes 10 hours, you have thousands of 
> dollars tied up hand holding weaker staff with more talented staff. A bad use 
> of money. A better method is mentoring, where a newer programmer is mentored 
> by a senior person. That’s how I was taught (IMS DB/DC) at my first 
> programming position after transferring from Operations at my first employer. 
> My code never failed. Because it was well tested. 
> 
> 
> 
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Sunday, March 17, 2024, 11:56 PM, Bob Bridges 
> <0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Boy, ain't THAT the truth!, he says sadly, thinking of an app he didn't write 
> and is now responsible for maintaining.
> 
> This thing passes multiple values between programs using (if I understand it 
> correctly) a single character string consisting of many assignment 
> statements, which are then parsed and evaluated upon returning to the calling 
> program.  Me, I probably would've used ISPF pool variables, but I'm not sure 
> that would be easier to follow.  So far I don't mess with it much; it works.
> 
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> 
> /* Every year, on April 15, all members of Congress would be placed in 
> individual prison cells with the necessary tax forms and a copy of the Tax 
> Code. They would remain locked in the cells, without food or water, until 
> they had completed their tax returns and successfully undergone a full IRS 
> audit. Of course this system would probably result in a severe shortage of 
> congresspersons. But there might also be some drawbacks. -Dave Barry's plan 
> to simplify the tax code, 2000-04-09 */
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Seymour J Metz
> Sent: Sunday, March 17, 2024 18:46
> 
> Expect the code to be modified by someone with significantly less knowledge 
> of the problem domain, even if they are an expert in the language.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[David Crayford]

> On 18 Mar 2024, at 22:33, Dave Beagle 
> <0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:
> 
> LOL, I was a programmer for almost half my 40+ year career. IMS/COBOL DB/DC 
> at first. Later mostly COBOL CICS and COBOL DB2. So I’m excellent in COBOL. 
> In college, I programmed in PL/I, fortran, watfiv, pascal, and some others. 
> Logic is my forte. Math major helps. (Double major Comp Sci)
> 

And a doctorate in bullshit


> As for code reviews, I’ve worked at 15 companies of various sizes and none of 
> them did code reviews. One company tried to implement, but it was a cluster 
> and a huge waste of time. Imagine having a staff of 10, who not only have 
> their own coding requirements and time constraints, but now have to hand hold 
> the less qualified employees. If you have a staff of 10 and they are making 
> $50/hour and up and each code review takes 10 hours, you have thousands of 
> dollars tied up hand holding weaker staff with more talented staff. A bad use 
> of money. A better method is mentoring, where a newer programmer is mentored 
> by a senior person. That’s how I was taught (IMS DB/DC) at my first 
> programming position after transferring from Operations at my first employer. 
> My code never failed. Because it was well tested. 
> 
> 
> 
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Sunday, March 17, 2024, 11:56 PM, Bob Bridges 
> <0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Boy, ain't THAT the truth!, he says sadly, thinking of an app he didn't write 
> and is now responsible for maintaining.
> 
> This thing passes multiple values between programs using (if I understand it 
> correctly) a single character string consisting of many assignment 
> statements, which are then parsed and evaluated upon returning to the calling 
> program.  Me, I probably would've used ISPF pool variables, but I'm not sure 
> that would be easier to follow.  So far I don't mess with it much; it works.
> 
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> 
> /* Every year, on April 15, all members of Congress would be placed in 
> individual prison cells with the necessary tax forms and a copy of the Tax 
> Code. They would remain locked in the cells, without food or water, until 
> they had completed their tax returns and successfully undergone a full IRS 
> audit. Of course this system would probably result in a severe shortage of 
> congresspersons. But there might also be some drawbacks. -Dave Barry's plan 
> to simplify the tax code, 2000-04-09 */
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Seymour J Metz
> Sent: Sunday, March 17, 2024 18:46
> 
> Expect the code to be modified by someone with significantly less knowledge 
> of the problem domain, even if they are an expert in the language.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Dave Beagle]

LOL, I was a programmer for almost half my 40+ year career. IMS/COBOL DB/DC at 
first. Later mostly COBOL CICS and COBOL DB2. So I’m excellent in COBOL. In 
college, I programmed in PL/I, fortran, watfiv, pascal, and some others. Logic 
is my forte. Math major helps. (Double major Comp Sci)

As for code reviews, I’ve worked at 15 companies of various sizes and none of 
them did code reviews. One company tried to implement, but it was a cluster and 
a huge waste of time. Imagine having a staff of 10, who not only have their own 
coding requirements and time constraints, but now have to hand hold the less 
qualified employees. If you have a staff of 10 and they are making $50/hour and 
up and each code review takes 10 hours, you have thousands of dollars tied up 
hand holding weaker staff with more talented staff. A bad use of money. A 
better method is mentoring, where a newer programmer is mentored by a senior 
person. That’s how I was taught (IMS DB/DC) at my first programming position 
after transferring from Operations at my first employer. My code never failed. 
Because it was well tested. 





Sent from Yahoo Mail for iPhone


On Sunday, March 17, 2024, 11:56 PM, Bob Bridges 
<0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:

Boy, ain't THAT the truth!, he says sadly, thinking of an app he didn't write 
and is now responsible for maintaining.

This thing passes multiple values between programs using (if I understand it 
correctly) a single character string consisting of many assignment statements, 
which are then parsed and evaluated upon returning to the calling program.  Me, 
I probably would've used ISPF pool variables, but I'm not sure that would be 
easier to follow.  So far I don't mess with it much; it works.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Every year, on April 15, all members of Congress would be placed in 
individual prison cells with the necessary tax forms and a copy of the Tax 
Code. They would remain locked in the cells, without food or water, until they 
had completed their tax returns and successfully undergone a full IRS audit. Of 
course this system would probably result in a severe shortage of 
congresspersons. But there might also be some drawbacks. -Dave Barry's plan to 
simplify the tax code, 2000-04-09 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Sunday, March 17, 2024 18:46

Expect the code to be modified by someone with significantly less knowledge of 
the problem domain, even if they are an expert in the language.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Bob Bridges]

Boy, ain't THAT the truth!, he says sadly, thinking of an app he didn't write 
and is now responsible for maintaining.

This thing passes multiple values between programs using (if I understand it 
correctly) a single character string consisting of many assignment statements, 
which are then parsed and evaluated upon returning to the calling program.  Me, 
I probably would've used ISPF pool variables, but I'm not sure that would be 
easier to follow.  So far I don't mess with it much; it works.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Every year, on April 15, all members of Congress would be placed in 
individual prison cells with the necessary tax forms and a copy of the Tax 
Code. They would remain locked in the cells, without food or water, until they 
had completed their tax returns and successfully undergone a full IRS audit. Of 
course this system would probably result in a severe shortage of 
congresspersons. But there might also be some drawbacks. -Dave Barry's plan to 
simplify the tax code, 2000-04-09 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Sunday, March 17, 2024 18:46

Expect the code to be modified by someone with significantly less knowledge of 
the problem domain, even if they are an expert in the language.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Seymour J Metz]

We don't seem to have the same definition of clever. To me, code that has me 
asking "Why didn't I think of that?" is clever; code that has me asking for 
hours "How does this work?", not so much. Sometimes the difference is good 
choice of label and helpful comments.

Expect the code to be modified by someone with significantly less knowledge of 
the problem domain, even if they are an expert in the language.

Bad standards are stifling and inefficient; that doesn't mean that all 
standards are bad. Good standards save time in the long run.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Jared Hunter 
Sent: Sunday, March 17, 2024 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Learning one's tools

Dave Beagle wrote:
> Code reviews are dumb and not needed by good programmers

Counterpoint: Code reviews are -most- essential when the authors are experts.

Why is that?  Because experts are most able to churn out code that functions 
correctly for today’s requirements, but that some less-expert future maintainer 
will have a difficult time modifying to suit a new requirement without 
introducing a bug.

“Standards” may feel stifling and inefficient to someone who wants to output 
“working” code as quickly as possible, and especially one with a deep desire to 
display their cleverness. [Dear reader, does that sound like anyone you know?]

In general, code written for the set of list-relevant platforms should be 
reviewed with the expectation that it will be maintained for decades longer 
than the original author is employed, and eventually by a generalist with 
significantly less overall depth of compiler-specific or arcane platform 
knowledge.  It’s an extremely hard balance to strike, to be sure, but it’s 
never too early or too late to start trying.

Jared Hunter
Rocket Software


Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[zMan]

+1
Remember, Bill isn't really a programmer, no matter what name he uses. He
was a sysprog at best.

On Sun, Mar 17, 2024 at 4:21 PM Jared Hunter 
wrote:

> Dave Beagle wrote:
> > Code reviews are dumb and not needed by good programmers
>
> Counterpoint: Code reviews are -most- essential when the authors are
> experts.
>
> Why is that?  Because experts are most able to churn out code that
> functions correctly for today’s requirements, but that some less-expert
> future maintainer will have a difficult time modifying to suit a new
> requirement without introducing a bug.
>
> “Standards” may feel stifling and inefficient to someone who wants to
> output “working” code as quickly as possible, and especially one with a
> deep desire to display their cleverness. [Dear reader, does that sound like
> anyone you know?]
>
> In general, code written for the set of list-relevant platforms should be
> reviewed with the expectation that it will be maintained for decades longer
> than the original author is employed, and eventually by a generalist with
> significantly less overall depth of compiler-specific or arcane platform
> knowledge.  It’s an extremely hard balance to strike, to be sure, but it’s
> never too early or too late to start trying.
>
> Jared Hunter
> Rocket Software
>
> 
> Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA
> 02451 ¦ Main Office Toll Free Number: +1 855.577.4323
> Contact Customer Support:
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
> http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy -
> http://www.rocketsoftware.com/company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential
> information of Rocket Software, Inc. All unauthorized use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> notify Rocket Software immediately and destroy all copies of this
> communication. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Jared Hunter]

Dave Beagle wrote:
> Code reviews are dumb and not needed by good programmers

Counterpoint: Code reviews are -most- essential when the authors are experts.

Why is that?  Because experts are most able to churn out code that functions 
correctly for today’s requirements, but that some less-expert future maintainer 
will have a difficult time modifying to suit a new requirement without 
introducing a bug.

“Standards” may feel stifling and inefficient to someone who wants to output 
“working” code as quickly as possible, and especially one with a deep desire to 
display their cleverness. [Dear reader, does that sound like anyone you know?]

In general, code written for the set of list-relevant platforms should be 
reviewed with the expectation that it will be maintained for decades longer 
than the original author is employed, and eventually by a generalist with 
significantly less overall depth of compiler-specific or arcane platform 
knowledge.  It’s an extremely hard balance to strike, to be sure, but it’s 
never too early or too late to start trying.

Jared Hunter
Rocket Software


Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Seymour J Metz]

That looks more like programming around deficiencies in the compiler than 
finding better algorithms. Between PL/I F V4 and V5 there was a serious 
degradation of code quality, anf there were  cases where the "optimizing" 
compiler was worse than F. I ran into that processing SMF data.

I'd be interested in seeing what the current Enterprise PL/I did with, e.g., 
unaligned bit strings, refers.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Robert Prins <05be6ef5bfea-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 17, 2024 10:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Learning one's tools

On Sun, 17 Mar 2024 at 11:42, Tom Harper <
05bfa0e23abd-dmarc-requ...@listserv.ua.edu> wrote:

> David,
>
> Yes, assembler can be used to improve performance.
>
> In the 64 years I have been programming, I have used COBOL for three
> years, C++ for six years, and assembler for 55 years.
>
> But it’s not just the language that affects performance. Design is
> critical and arranging your algorithms in the correct sequence is of the
> utmost importance.
>

It's way more important!

Here are statement counts obtained by the old PL/I Optimizing compiler for
the procedure(s) that produce one particular table:

My old algorithm:

NAT_SCAN  13,685,293,297  99.6441458%

The current algorithm, thanks to a Paul Greeen, and the result from a post
to comp.lang.pascal.borland, almost 26 years ago.

NAT_SCAN 246,805   0.6623430%
DISPOSE_RUN   14,064   0.0377431%
SETUP_RUN162,060   0.4349154%
CHECK_RUNS 1,229,773   3.3003039%

And for what it's worth, the old counts are probably correct, the transient
library of the optimizing compiler cannot handle counts over 2^31-1, so I
had to add code to emulate the loops according to the PL/I manual, using
FIXED DEC (15) variables.

Now this is only a private program <
https://prino.neocities.org/resources/lift.pli.html>, but I've updated PL/I
code myself reducing ***CPU*** time from well over three hours to just 20
minutes, by just changing two declarations, and while working at a Dutch
airline company, I reduced CPU usage of two PL/I programs calculating CRCs
by more than 99.5%, removing calls to the PL/I library. Hell, if you look
at the current Enterprise PL/I Programming Guide, GI13-5620-00, on PDF page
372 (book page 316) in the "Avoiding calls to library routines" paragraph,
the text that reads


When your code refers to a member of a BASED structure with REFER, the
compiler often has to generate
one or more calls to a library routine to map the structure at run time.
These calls can be expensive, and
so when the compiler makes these calls, it will issue a message so that you
can locate these potential
hot-spots in your code.

If you do have code that uses BASED structures with REFER, which the
compiler flags with this message,
you might get better performance by passing the structure to a subroutine
that declares a corresponding
structure with * extents. This will cause the structure to be mapped once
at the CALL statement, but there
will no further remappings when it is accessed in the called subroutine.


is almost a literal copy of text in an email I sent to IBM's Peter Elderon
close to 30 years ago, and if you use PL/I to build linked lists, and/or
trees using BASED storage, I'd suggest you think about the second
(area-reference) parameter of the ALLOC builtin function, and the NEXTALLOC
builtin, both are the result of my RFEs, and combining them with the EMPTY
builtin, well think about it. ;)

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather <https://prino.neocities.org/index.html>
Some REXX code for use on z/OS
<https://prino.neocities.org/zOS/zOS-Tools.html>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Seymour J Metz]

The difference is that you not only learn how to do it better next time, you 
get to improve it this time. Taking ownership doesn't mean keeping people off 
your turf; a professional should always be open to informed criticism.

I've exchanged code with a number of people over the years, and have always 
been glad when they've showed me a better way to do something. Sometimes you 
can even learn from your students.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 17, 2024 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Learning one's tools

I suppose code reviews are like post-battle debriefs, in which every choice of 
the commander is questioned, and when challenged with a better option he can 
only say "I didn't think of that at the time".  It must be extremely painful 
for the guy in the glare of the spotlight, but if it's done right -- too late 
to blame anyone now, we're just trying to make sure everyone has a chance to 
learn how to do it better next time -- it's also extremely valuable.  I truly 
hated having the code reviewers poke at my baby, and at the start of this 
thread I pointed out ways in which they didn't do it right.  But I agree with 
Shmuel, when done right you might even say they're necessary.

(And post-surgical reviews, too.  The patient lived, or the patient died, fine, 
but now we want to know what to do differently next time.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The kingdom of Heaven is not for the well-meaning; it is for the desperate.  
-James Denney (1856-1917) */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Sunday, March 17, 2024 00:41

However, disagree vehemently about "Code reviews are dumb and not needed by 
good programmers." The first two things that a good programmer learns are that 
nobody has a monopoly on good ideas and that "Even Jove nods". Code reviews are 
like auditors and tech writers: when they are good they are very very good, and 
when they are bad they are horrid.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Seymour J Metz]

Is this code clear? How can we improve the comments?

Have we considered all of the edge cases?

Is there a better way to do this?

How easy will it be to extend this?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Colin Paice <059d4daca697-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, March 17, 2024 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Learning one's tools

I think code reviews are very useful, especially for not yet experts.  It
is good education for all levels.
We had reviews, and comments like
- Do you need a latch across these instructions for when there is
concurrent execution?
- If it abends here, how will the frr code ...
- Would it help capturing foot prints to show how we got here, before the
following code which may abend.
- Some customers will not send us a dump, so we need to capture as much as
we can in registers.
Colin

On Sun, 17 Mar 2024 at 13:40, Bob Bridges <
0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:

> I suppose code reviews are like post-battle debriefs, in which every
> choice of the commander is questioned, and when challenged with a better
> option he can only say "I didn't think of that at the time".  It must be
> extremely painful for the guy in the glare of the spotlight, but if it's
> done right -- too late to blame anyone now, we're just trying to make sure
> everyone has a chance to learn how to do it better next time -- it's also
> extremely valuable.  I truly hated having the code reviewers poke at my
> baby, and at the start of this thread I pointed out ways in which they
> didn't do it right.  But I agree with Shmuel, when done right you might
> even say they're necessary.
>
> (And post-surgical reviews, too.  The patient lived, or the patient died,
> fine, but now we want to know what to do differently next time.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* The kingdom of Heaven is not for the well-meaning; it is for the
> desperate.  -James Denney (1856-1917) */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Seymour J Metz
> Sent: Sunday, March 17, 2024 00:41
>
> However, disagree vehemently about "Code reviews are dumb and not needed
> by good programmers." The first two things that a good programmer learns
> are that nobody has a monopoly on good ideas and that "Even Jove nods".
> Code reviews are like auditors and tech writers: when they are good they
> are very very good, and when they are bad they are horrid.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Colin Paice]

I think code reviews are very useful, especially for not yet experts.  It
is good education for all levels.
We had reviews, and comments like
- Do you need a latch across these instructions for when there is
concurrent execution?
- If it abends here, how will the frr code ...
- Would it help capturing foot prints to show how we got here, before the
following code which may abend.
- Some customers will not send us a dump, so we need to capture as much as
we can in registers.
Colin

On Sun, 17 Mar 2024 at 13:40, Bob Bridges <
0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:

> I suppose code reviews are like post-battle debriefs, in which every
> choice of the commander is questioned, and when challenged with a better
> option he can only say "I didn't think of that at the time".  It must be
> extremely painful for the guy in the glare of the spotlight, but if it's
> done right -- too late to blame anyone now, we're just trying to make sure
> everyone has a chance to learn how to do it better next time -- it's also
> extremely valuable.  I truly hated having the code reviewers poke at my
> baby, and at the start of this thread I pointed out ways in which they
> didn't do it right.  But I agree with Shmuel, when done right you might
> even say they're necessary.
>
> (And post-surgical reviews, too.  The patient lived, or the patient died,
> fine, but now we want to know what to do differently next time.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* The kingdom of Heaven is not for the well-meaning; it is for the
> desperate.  -James Denney (1856-1917) */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Seymour J Metz
> Sent: Sunday, March 17, 2024 00:41
>
> However, disagree vehemently about "Code reviews are dumb and not needed
> by good programmers." The first two things that a good programmer learns
> are that nobody has a monopoly on good ideas and that "Even Jove nods".
> Code reviews are like auditors and tech writers: when they are good they
> are very very good, and when they are bad they are horrid.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Bob Bridges]

I really gotta get back into PL/1.  It was my first language, and I still like 
it.  Just haven't used it in a few decades.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The more sophisticated the technology, the more vulnerable it is to 
primitive attack. People often overlook the obvious.  -Dr Who, 1978 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert Prins
Sent: Sunday, March 17, 2024 10:44

I've updated PL/I code myself reducing ***CPU*** time from well over three 
hours to just 20 minutes, by just changing two declarations, and while working 
at a Dutch airline company, I reduced CPU usage of two PL/I programs 
calculating CRCs by more than 99.5%, removing calls to the PL/I library. Hell, 
if you look at the current Enterprise PL/I Programming Guide, GI13-5620-00, on 
PDF page
372 (book page 316) in the "Avoiding calls to library routines" paragraph, the 
text that reads


When your code refers to a member of a BASED structure with REFER, the compiler 
often has to generate one or more calls to a library routine to map the 
structure at run time.  These calls can be expensive, and so when the compiler 
makes these calls, it will issue a message so that you can locate these 
potential hot-spots in your code.

If you do have code that uses BASED structures with REFER, which the compiler 
flags with this message, you might get better performance by passing the 
structure to a subroutine that declares a corresponding structure with * 
extents. This will cause the structure to be mapped once at the CALL statement, 
but there will no further remappings when it is accessed in the called 
subroutine.


is almost a literal copy of text in an email I sent to IBM's Peter Elderon 
close to 30 years ago, and if you use PL/I to build linked lists, and/or trees 
using BASED storage, I'd suggest you think about the second
(area-reference) parameter of the ALLOC builtin function, and the NEXTALLOC 
builtin, both are the result of my RFEs, and combining them with the EMPTY 
builtin, well think about it. ;)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Bob Bridges]

I suppose code reviews are like post-battle debriefs, in which every choice of 
the commander is questioned, and when challenged with a better option he can 
only say "I didn't think of that at the time".  It must be extremely painful 
for the guy in the glare of the spotlight, but if it's done right -- too late 
to blame anyone now, we're just trying to make sure everyone has a chance to 
learn how to do it better next time -- it's also extremely valuable.  I truly 
hated having the code reviewers poke at my baby, and at the start of this 
thread I pointed out ways in which they didn't do it right.  But I agree with 
Shmuel, when done right you might even say they're necessary.

(And post-surgical reviews, too.  The patient lived, or the patient died, fine, 
but now we want to know what to do differently next time.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The kingdom of Heaven is not for the well-meaning; it is for the desperate.  
-James Denney (1856-1917) */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Sunday, March 17, 2024 00:41

However, disagree vehemently about "Code reviews are dumb and not needed by 
good programmers." The first two things that a good programmer learns are that 
nobody has a monopoly on good ideas and that "Even Jove nods". Code reviews are 
like auditors and tech writers: when they are good they are very very good, and 
when they are bad they are horrid. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Robert Prins]

On Sun, 17 Mar 2024 at 11:42, Tom Harper <
05bfa0e23abd-dmarc-requ...@listserv.ua.edu> wrote:

> David,
>
> Yes, assembler can be used to improve performance.
>
> In the 64 years I have been programming, I have used COBOL for three
> years, C++ for six years, and assembler for 55 years.
>
> But it’s not just the language that affects performance. Design is
> critical and arranging your algorithms in the correct sequence is of the
> utmost importance.
>

It's way more important!

Here are statement counts obtained by the old PL/I Optimizing compiler for
the procedure(s) that produce one particular table:

My old algorithm:

NAT_SCAN  13,685,293,297  99.6441458%

The current algorithm, thanks to a Paul Greeen, and the result from a post
to comp.lang.pascal.borland, almost 26 years ago.

NAT_SCAN 246,805   0.6623430%
DISPOSE_RUN   14,064   0.0377431%
SETUP_RUN162,060   0.4349154%
CHECK_RUNS 1,229,773   3.3003039%

And for what it's worth, the old counts are probably correct, the transient
library of the optimizing compiler cannot handle counts over 2^31-1, so I
had to add code to emulate the loops according to the PL/I manual, using
FIXED DEC (15) variables.

Now this is only a private program <
https://prino.neocities.org/resources/lift.pli.html>, but I've updated PL/I
code myself reducing ***CPU*** time from well over three hours to just 20
minutes, by just changing two declarations, and while working at a Dutch
airline company, I reduced CPU usage of two PL/I programs calculating CRCs
by more than 99.5%, removing calls to the PL/I library. Hell, if you look
at the current Enterprise PL/I Programming Guide, GI13-5620-00, on PDF page
372 (book page 316) in the "Avoiding calls to library routines" paragraph,
the text that reads


When your code refers to a member of a BASED structure with REFER, the
compiler often has to generate
one or more calls to a library routine to map the structure at run time.
These calls can be expensive, and
so when the compiler makes these calls, it will issue a message so that you
can locate these potential
hot-spots in your code.

If you do have code that uses BASED structures with REFER, which the
compiler flags with this message,
you might get better performance by passing the structure to a subroutine
that declares a corresponding
structure with * extents. This will cause the structure to be mapped once
at the CALL statement, but there
will no further remappings when it is accessed in the called subroutine.


is almost a literal copy of text in an email I sent to IBM's Peter Elderon
close to 30 years ago, and if you use PL/I to build linked lists, and/or
trees using BASED storage, I'd suggest you think about the second
(area-reference) parameter of the ALLOC builtin function, and the NEXTALLOC
builtin, both are the result of my RFEs, and combining them with the EMPTY
builtin, well think about it. ;)

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Tom Harper]

David,

Yes, assembler can be used to improve performance. 

In the 64 years I have been programming, I have used COBOL for three years, C++ 
for six years, and assembler for 55 years. 

But it’s not just the language that affects performance. Design is critical and 
arranging your algorithms in the correct sequence is of the utmost importance.

Tom Harper
Phoenix Software International 


Sent from my iPhone

> On Mar 17, 2024, at 7:18 AM, David Spiegel 
> <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Hi Tom,
> Not new/difficult, but, must be used appropriately or it can cause 
> performance issues.
> When I worked at SIAC (NYSE) 2004-2010, one of the last mainframe activities 
> I did was to look into why 6 Batch Jobs (run nightly) took over the machine 
> to the point that TSO response time was painfully slow (after 1st period).  
> The original programmer decided to use UNSTRING to build CSV Data out of 
> records from a KSDS. On a hunch, I rewrote the UNSTRING call in Assembler. 
> The run times of these 6 (similar) Jobs went from 6 hours to just over a half 
> hour.
> 
> Regards,
> David
> 
>> On 2024-03-15 16:55, Tom Harper wrote:
>> I used STRING / UNSTRING back in the early 1970s it’s not new nor difficult.
>> 
>> Unbelievable.
>> 
>> Tom Harper
>> Phoenix Software International
>> 
>> Sent from my iPhone
>> 
>>>> On Mar 15, 2024, at 4:20 PM, Farley, Peter 
>>>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>>> +1 from me on continuing to learn the tools of our profession.  I use 
>>> STRING and UNSTRING where they make sense, and I am still learning new 
>>> things about their use every now and then.  Life-long learning is the only 
>>> path to happiness and success.
>>> 
>>> I got the same ridiculous pushback from a senior manager one time on the 
>>> use of “sophisticated” SORT verbs like JOIN because “. . . no one but you 
>>> will know how to fix it when it breaks . . . let someone do it in COBOL 
>>> instead . . .”.
>>> 
>>> Peter
>>> 
>>> From: IBM Mainframe Discussion List  On Behalf Of 
>>> Bob Bridges
>>> Sent: Friday, March 15, 2024 12:38 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Learning one's tools
>>> 
>>> 
>>> To rant on a related subject, I once worked at a company that instituted 
>>> code reviews; a new program would be gone over by a half-dozen coworkers to 
>>> be sure it adhered to local standards.  This sort of thing is always 
>>> painful to the coder, and nevertheless (I admit reluctantly) can have 
>>> considerable value if done right.  One problem I had with it, though, is 
>>> that the standards we created for ourselves admitted that there are times 
>>> when exceptions should be made for special cases, and yet when those cases 
>>> arose no exceptions were ever allowed; the team invariably flinched, leaned 
>>> back in their seats and said "no, that's not according to our standards".
>>> 



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[David Spiegel]

Hi Tom,
Not new/difficult, but, must be used appropriately or it can cause 
performance issues.
When I worked at SIAC (NYSE) 2004-2010, one of the last mainframe 
activities I did was to look into why 6 Batch Jobs (run nightly) took 
over the machine to the point that TSO response time was painfully slow 
(after 1st period).  The original programmer decided to use UNSTRING to 
build CSV Data out of records from a KSDS. On a hunch, I rewrote the 
UNSTRING call in Assembler. The run times of these 6 (similar) Jobs went 
from 6 hours to just over a half hour.


Regards,
David

On 2024-03-15 16:55, Tom Harper wrote:

I used STRING / UNSTRING back in the early 1970s it’s not new nor difficult.

Unbelievable.

Tom Harper
Phoenix Software International

Sent from my iPhone


On Mar 15, 2024, at 4:20 PM, Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

+1 from me on continuing to learn the tools of our profession.  I use STRING 
and UNSTRING where they make sense, and I am still learning new things about 
their use every now and then.  Life-long learning is the only path to happiness 
and success.

I got the same ridiculous pushback from a senior manager one time on the use of 
“sophisticated” SORT verbs like JOIN because “. . . no one but you will know 
how to fix it when it breaks . . . let someone do it in COBOL instead . . .”.

Peter

From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Friday, March 15, 2024 12:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Learning one's tools


To rant on a related subject, I once worked at a company that instituted code reviews; a 
new program would be gone over by a half-dozen coworkers to be sure it adhered to local 
standards.  This sort of thing is always painful to the coder, and nevertheless (I admit 
reluctantly) can have considerable value if done right.  One problem I had with it, 
though, is that the standards we created for ourselves admitted that there are times when 
exceptions should be made for special cases, and yet when those cases arose no exceptions 
were ever allowed; the team invariably flinched, leaned back in their seats and said 
"no, that's not according to our standards".



One particular example always rankled:  Whenever someone felt the need to use a 
STRING or UNSTRING command (I should have said we were COBOL developers), the 
team always struck it down on the grounds that STRING and UNSTRING are unusual 
commands and some COBOL coders would be unfamiliar with it.  My contention here 
is that that's absolutely true, and it's the job of the COBOL coder to ~learn~ 
the STRING and UNSTRING statements, as tools of his profession.  I never 
persuaded anyone to that view, though.



---



This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communic



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Seymour J Metz]

Sturgeon's law rules.

However, disagree vehemently about "Code reviews are dumb and not needed by 
good programmers." The first two things that a good programmer learns are that 
nobody has a monopoly on good ideas and that "Even Jove nods". Code reviews are 
like auditors and tech writers: when they are good they are very very good, and 
when they are bad they are horrid. 

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Dave Beagle <0525eaef6620-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, March 16, 2024 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Learning one's tools

Just like any profession, 20% of the IT professionals are highly qualified. The 
rest have achieved by luck, nepotism, favoritism, or connections. Of all the 
managers I’ve had, the best ones don’t micromanage because they were confident 
in their ability to hire qualified people. I’ve worked on code that was written 
by imbeciles and I’ve worked on code that was brilliant. Back when I first 
started, I supported code that was written in the 60’s. No documentation 
(written or inside the code) and nearly impossible to follow. Those hired in 
1960’s IT had very little if any IT experience, very little training, (the 
company trained them) and most had nothing more than a high school diploma.

Code reviews are dumb and not needed by good programmers.

Good programmers today can command a very good wage.

AI people are easily making 6 figures.


Sent from Yahoo Mail for iPhone


On Friday, March 15, 2024, 8:24 PM, Don Leahy  wrote:

I try to never show my code to a manager. No good can come from it.

On Fri, Mar 15, 2024 at 4:25 PM Seymour J Metz  wrote:

> You have to love it when a  manager tells you not to use a COBOL verb but
> instead to use COBOL..
>
> Fortunately, some <https://mason.gmu.edu/~smetz3/#bosses> bosses are
> better than that.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
> Sent: Friday, March 15, 2024 4:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Learning one's tools
>
> +1 from me on continuing to learn the tools of our profession.  I use
> STRING and UNSTRING where they make sense, and I am still learning new
> things about their use every now and then.  Life-long learning is the only
> path to happiness and success.
>
> I got the same ridiculous pushback from a senior manager one time on the
> use of “sophisticated” SORT verbs like JOIN because “. . . no one but you
> will know how to fix it when it breaks . . . let someone do it in COBOL
> instead . . .”.
>
> Peter
>
> From: IBM Mainframe Discussion List  On Behalf
> Of Bob Bridges
> Sent: Friday, March 15, 2024 12:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Learning one's tools
>
>
> To rant on a related subject, I once worked at a company that instituted
> code reviews; a new program would be gone over by a half-dozen coworkers to
> be sure it adhered to local standards.  This sort of thing is always
> painful to the coder, and nevertheless (I admit reluctantly) can have
> considerable value if done right.  One problem I had with it, though, is
> that the standards we created for ourselves admitted that there are times
> when exceptions should be made for special cases, and yet when those cases
> arose no exceptions were ever allowed; the team invariably flinched, leaned
> back in their seats and said "no, that's not according to our standards".
>
>
>
> One particular example always rankled:  Whenever someone felt the need to
> use a STRING or UNSTRING command (I should have said we were COBOL
> developers), the team always struck it down on the grounds that STRING and
> UNSTRING are unusual commands and some COBOL coders would be unfamiliar
> with it.  My contention here is that that's absolutely true, and it's the
> job of the COBOL coder to ~learn~ the STRING and UNSTRING statements, as
> tools of his profession.  I never persuaded anyone to that view, though.
>
>
>
> ---
>
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please n

Re: Learning one's tools

[Gabe Goldberg]

I recently argued with someone -- not here! -- when he was enthusiastic about 
AI generating code. Poof, no programmers, he said. What about bugs, I asked? 
Human-generated code has bugs, so will AI coding, since it will be trained on 
... human coding. No problem he said, people will check the AI generated code.

So they won't be programmers, I said, but they'll be good at desk checking 
code? And reading code will replace humans designing it and testing it? And 
that's more efficient than human coders? And AI code will likely not have 
comments/documentation. Won't that be fun debugging/maintaining/enhancing. What 
could go wrong?

AI coding assistant, sure. AI programmers, maybe not (yet?).


Bob Bridges  said:

To rant on a related subject, I once worked at a company that instituted code reviews; a 
new program would be gone over by a half-dozen coworkers to be sure it adhered to local 
standards.  This sort of thing is always painful to the coder, and nevertheless (I admit 
reluctantly) can have considerable value if done right.  One problem I had with it, 
though, is that the standards we created for ourselves admitted that there are times when 
exceptions should be made for special cases, and yet when those cases arose no exceptions 
were ever allowed; the team invariably flinched, leaned back in their seats and said 
"no, that's not according to our standards".

--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[roscoe5]

Yep, I started in ‘81, with the same two Deltac courses. They took me from 
trainee to retired in 40+ years. Not perfect but a great company.

Sent from [Proton Mail](https://proton.me/mail/home) for iOS

On Sat, Mar 16, 2024 at 4:44 PM, Bob Bridges 
<[0587168ababf-dmarc-requ...@listserv.ua.edu](mailto:On Sat, Mar 16, 2024 
at 4:44 PM, Bob Bridges < wrote:

> No place is all bad. The same company started me, upon hiring, on several 
> days of Deltak courses, one on JCL and one on COBOL. It is to them that I owe 
> a lifelong familiarity with JCL. I wonder sometimes how mainframers get on 
> without it.
>
> (Well, "lifelong": It was 1980, so I was probably 26.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* A strong conviction that something must be done is the parent of many bad 
> measures. -Daniel Webster */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Seymour J Metz
> Sent: Friday, March 15, 2024 15:38
>
> That sounds like a hostile working environment. The people doing a code 
> review should know the language and the local standards; nit sounds like they 
> knew neither.
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Bob Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu>
> Sent: Friday, March 15, 2024 12:37 PM
>
> I once worked at a company that instituted code reviews; a new program 
> would be gone over by a half-dozen coworkers to be sure it adhered to local 
> standards. This sort of thing is always painful to the coder, and 
> nevertheless (I admit reluctantly) can have considerable value if done right. 
> One problem I had with it, though, is that the standards we created for 
> ourselves admitted that there are times when exceptions should be made for 
> special cases, and yet when those cases arose no exceptions were ever 
> allowed; the team invariably flinched, leaned back in their seats and said 
> "no, that's not according to our standards".
>
> One particular example always rankled: Whenever someone felt the need to use 
> a STRING or UNSTRING command (I should have said we were COBOL developers), 
> the team always struck it down on the grounds that STRING and UNSTRING are 
> unusual commands and some COBOL coders would be unfamiliar with it. My 
> contention here is that that's absolutely true, and it's the job of the COBOL 
> coder to ~learn~ the STRING and UNSTRING statements, as tools of his 
> profession. I never persuaded anyone to that view, though.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Bob Bridges]

No place is all bad.  The same company started me, upon hiring, on several days 
of Deltak courses, one on JCL and one on COBOL.  It is to them that I owe a 
lifelong familiarity with JCL.  I wonder sometimes how mainframers get on 
without it.

(Well, "lifelong":  It was 1980, so I was probably 26.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* A strong conviction that something must be done is the parent of many bad 
measures.  -Daniel Webster */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, March 15, 2024 15:38

That sounds like a hostile working environment. The people doing a code review 
should know the language and the local standards; nit sounds like they knew 
neither.


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu>
Sent: Friday, March 15, 2024 12:37 PM

I once worked at a company that instituted code reviews; a new program 
would be gone over by a half-dozen coworkers to be sure it adhered to local 
standards.  This sort of thing is always painful to the coder, and nevertheless 
(I admit reluctantly) can have considerable value if done right.  One problem I 
had with it, though, is that the standards we created for ourselves admitted 
that there are times when exceptions should be made for special cases, and yet 
when those cases arose no exceptions were ever allowed; the team invariably 
flinched, leaned back in their seats and said "no, that's not according to our 
standards".

One particular example always rankled:  Whenever someone felt the need to use a 
STRING or UNSTRING command (I should have said we were COBOL developers), the 
team always struck it down on the grounds that STRING and UNSTRING are unusual 
commands and some COBOL coders would be unfamiliar with it.  My contention here 
is that that's absolutely true, and it's the job of the COBOL coder to ~learn~ 
the STRING and UNSTRING statements, as tools of his profession.  I never 
persuaded anyone to that view, though.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Dave Beagle]

Just like any profession, 20% of the IT professionals are highly qualified. The 
rest have achieved by luck, nepotism, favoritism, or connections. Of all the 
managers I’ve had, the best ones don’t micromanage because they were confident 
in their ability to hire qualified people. I’ve worked on code that was written 
by imbeciles and I’ve worked on code that was brilliant. Back when I first 
started, I supported code that was written in the 60’s. No documentation 
(written or inside the code) and nearly impossible to follow. Those hired in 
1960’s IT had very little if any IT experience, very little training, (the 
company trained them) and most had nothing more than a high school diploma.

Code reviews are dumb and not needed by good programmers.

Good programmers today can command a very good wage.

AI people are easily making 6 figures.


Sent from Yahoo Mail for iPhone


On Friday, March 15, 2024, 8:24 PM, Don Leahy  wrote:

I try to never show my code to a manager. No good can come from it.

On Fri, Mar 15, 2024 at 4:25 PM Seymour J Metz  wrote:

> You have to love it when a  manager tells you not to use a COBOL verb but
> instead to use COBOL..
>
> Fortunately, some <https://mason.gmu.edu/~smetz3/#bosses> bosses are
> better than that.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
> Sent: Friday, March 15, 2024 4:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Learning one's tools
>
> +1 from me on continuing to learn the tools of our profession.  I use
> STRING and UNSTRING where they make sense, and I am still learning new
> things about their use every now and then.  Life-long learning is the only
> path to happiness and success.
>
> I got the same ridiculous pushback from a senior manager one time on the
> use of “sophisticated” SORT verbs like JOIN because “. . . no one but you
> will know how to fix it when it breaks . . . let someone do it in COBOL
> instead . . .”.
>
> Peter
>
> From: IBM Mainframe Discussion List  On Behalf
> Of Bob Bridges
> Sent: Friday, March 15, 2024 12:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Learning one's tools
>
>
> To rant on a related subject, I once worked at a company that instituted
> code reviews; a new program would be gone over by a half-dozen coworkers to
> be sure it adhered to local standards.  This sort of thing is always
> painful to the coder, and nevertheless (I admit reluctantly) can have
> considerable value if done right.  One problem I had with it, though, is
> that the standards we created for ourselves admitted that there are times
> when exceptions should be made for special cases, and yet when those cases
> arose no exceptions were ever allowed; the team invariably flinched, leaned
> back in their seats and said "no, that's not according to our standards".
>
>
>
> One particular example always rankled:  Whenever someone felt the need to
> use a STRING or UNSTRING command (I should have said we were COBOL
> developers), the team always struck it down on the grounds that STRING and
> UNSTRING are unusual commands and some COBOL coders would be unfamiliar
> with it.  My contention here is that that's absolutely true, and it's the
> job of the COBOL coder to ~learn~ the STRING and UNSTRING statements, as
> tools of his profession.  I never persuaded anyone to that view, though.
>
>
>
> ---
>
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Don Leahy]

I try to never show my code to a manager. No good can come from it.

On Fri, Mar 15, 2024 at 4:25 PM Seymour J Metz  wrote:

> You have to love it when a  manager tells you not to use a COBOL verb but
> instead to use COBOL..
>
> Fortunately, some <https://mason.gmu.edu/~smetz3/#bosses> bosses are
> better than that.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
> Sent: Friday, March 15, 2024 4:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Learning one's tools
>
> +1 from me on continuing to learn the tools of our profession.  I use
> STRING and UNSTRING where they make sense, and I am still learning new
> things about their use every now and then.  Life-long learning is the only
> path to happiness and success.
>
> I got the same ridiculous pushback from a senior manager one time on the
> use of “sophisticated” SORT verbs like JOIN because “. . . no one but you
> will know how to fix it when it breaks . . . let someone do it in COBOL
> instead . . .”.
>
> Peter
>
> From: IBM Mainframe Discussion List  On Behalf
> Of Bob Bridges
> Sent: Friday, March 15, 2024 12:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Learning one's tools
>
>
> To rant on a related subject, I once worked at a company that instituted
> code reviews; a new program would be gone over by a half-dozen coworkers to
> be sure it adhered to local standards.  This sort of thing is always
> painful to the coder, and nevertheless (I admit reluctantly) can have
> considerable value if done right.  One problem I had with it, though, is
> that the standards we created for ourselves admitted that there are times
> when exceptions should be made for special cases, and yet when those cases
> arose no exceptions were ever allowed; the team invariably flinched, leaned
> back in their seats and said "no, that's not according to our standards".
>
>
>
> One particular example always rankled:  Whenever someone felt the need to
> use a STRING or UNSTRING command (I should have said we were COBOL
> developers), the team always struck it down on the grounds that STRING and
> UNSTRING are unusual commands and some COBOL coders would be unfamiliar
> with it.  My contention here is that that's absolutely true, and it's the
> job of the COBOL coder to ~learn~ the STRING and UNSTRING statements, as
> tools of his profession.  I never persuaded anyone to that view, though.
>
>
>
> ---
>
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Bob Bridges]

Heh - I just used this tagline in an email to someone else, and it seems 
appropriate here.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* I find that when someone's taking time to do something right in the present, 
he's a perfectionist with no ability to prioritize, whereas when someone took 
time to do something right in the past, he's a master artisan of great 
foresight.  -xkcd */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, March 15, 2024 15:38

That sounds like a hostile working environment. The people doing a code review 
should know the language and the local standards; nit sounds like they knew 
neither.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Bob Bridges]

My boss at a later job heartily agreed with you, Shmuel.  Not coïncidentally, I 
liked him a lot :).

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* You must ask for God's help.  Even when you have done so, it may seem to you 
for a long time that no help, or less help than you need, is being given.  
Never mind.  After each failure, ask forgiveness, pick yourself up, and try 
again.  Very often what God first helps us toward is not the virtue itself but 
just this power of always trying again.  -C S Lewis, _Christian Behavior_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, March 15, 2024 15:38

That sounds like a hostile working environment. The people doing a code review 
should know the language and the local standards; nit sounds like they knew 
neither.


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu>
Sent: Friday, March 15, 2024 12:37 PM

To rant on a related subject, I once worked at a company that instituted code 
reviews; a new program would be gone over by a half-dozen coworkers to be sure 
it adhered to local standards.  This sort of thing is always painful to the 
coder, and nevertheless (I admit reluctantly) can have considerable value if 
done right.  One problem I had with it, though, is that the standards we 
created for ourselves admitted that there are times when exceptions should be 
made for special cases, and yet when those cases arose no exceptions were ever 
allowed; the team invariably flinched, leaned back in their seats and said "no, 
that's not according to our standards".

One particular example always rankled:  Whenever someone felt the need to use a 
STRING or UNSTRING command (I should have said we were COBOL developers), the 
team always struck it down on the grounds that STRING and UNSTRING are unusual 
commands and some COBOL coders would be unfamiliar with it.  My contention here 
is that that's absolutely true, and it's the job of the COBOL coder to ~learn~ 
the STRING and UNSTRING statements, as tools of his profession.  I never 
persuaded anyone to that view, though.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Tom Harper]

I used STRING / UNSTRING back in the early 1970s it’s not new nor difficult. 

Unbelievable. 

Tom Harper 
Phoenix Software International 

Sent from my iPhone

> On Mar 15, 2024, at 4:20 PM, Farley, Peter 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> 
> +1 from me on continuing to learn the tools of our profession.  I use STRING 
> and UNSTRING where they make sense, and I am still learning new things about 
> their use every now and then.  Life-long learning is the only path to 
> happiness and success.
> 
> I got the same ridiculous pushback from a senior manager one time on the use 
> of “sophisticated” SORT verbs like JOIN because “. . . no one but you will 
> know how to fix it when it breaks . . . let someone do it in COBOL instead . 
> . .”.
> 
> Peter
> 
> From: IBM Mainframe Discussion List  On Behalf Of 
> Bob Bridges
> Sent: Friday, March 15, 2024 12:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Learning one's tools
> 
> 
> To rant on a related subject, I once worked at a company that instituted code 
> reviews; a new program would be gone over by a half-dozen coworkers to be 
> sure it adhered to local standards.  This sort of thing is always painful to 
> the coder, and nevertheless (I admit reluctantly) can have considerable value 
> if done right.  One problem I had with it, though, is that the standards we 
> created for ourselves admitted that there are times when exceptions should be 
> made for special cases, and yet when those cases arose no exceptions were 
> ever allowed; the team invariably flinched, leaned back in their seats and 
> said "no, that's not according to our standards".
> 
> 
> 
> One particular example always rankled:  Whenever someone felt the need to use 
> a STRING or UNSTRING command (I should have said we were COBOL developers), 
> the team always struck it down on the grounds that STRING and UNSTRING are 
> unusual commands and some COBOL coders would be unfamiliar with it.  My 
> contention here is that that's absolutely true, and it's the job of the COBOL 
> coder to ~learn~ the STRING and UNSTRING statements, as tools of his 
> profession.  I never persuaded anyone to that view, though.
> 
> 
> 
> ---
> 
> 
> 
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communic



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Seymour J Metz]

<https://www.goodreads.com/book/show/546936.Up_the_Organizationhttps://www.goodreads.com/book/show/546936.Up_the_Organization>
<https://en.wikipedia.org/wiki/Peter_principle>

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Michael Oujesky 
Sent: Friday, March 15, 2024 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Learning one's tools

Wonder how he made senior. Politics and not skills or expertise.

At 03:19 PM 3/15/2024, Farley, Peter wrote:
>Content-Transfer-Encoding: base64+1 from me on
>continuing to learn the tools of our
>profession.  I use STRING and UNSTRING where
>they make sense, and I am still learning new
>things about their use every now and
>then.  Life-long learning is the only path to happiness and success.
>
>I got the same ridiculous pushback from a senior
>manager one time on the use of “sophisticated”
>SORT verbs like JOIN because “. . . no one but
>you will know how to fix it when it breaks . . .
>let someone do it in COBOL instead . . .”.
>
>Peter
>
>From: IBM Mainframe Discussion List
>Sent: Friday, March 15, 2024 12:38 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Learning one's tools
>
>
>To rant on a related subject, I once worked at a
>company that instituted code reviews; a new
>program would be gone over by a half-dozen
>coworkers to be sure it adhered to local
>standards.  This sort of thing is always painful
>to the coder, and nevertheless (I admit
>reluctantly) can have considerable value if done
>right.  One problem I had with it, though, is
>that the standards we created for ourselves
>admitted that there are times when exceptions
>should be made for special cases, and yet when
>those cases arose no exceptions were ever
>allowed; the team invariably flinched, leaned
>back in their seats and said "no, that's not according to our standards".
>
>
>
>One particular example always rankled:  Whenever
>someone felt the need to use a STRING or
>UNSTRING command (I should have said we were
>COBOL developers), the team always struck it
>down on the grounds that STRING and UNSTRING are
>unusual commands and some COBOL coders would be
>unfamiliar with it.  My contention here is that
>that's absolutely true, and it's the job of the
>COBOL coder to ~learn~ the STRING and UNSTRING
>statements, as tools of his profession.  I never
>persuaded anyone to that view, though.
>
>
>
>---
>
>
>
>This message and any attachments are intended
>only for the use of the addressee and may
>contain information that is privileged and
>confidential. If the reader of the message is
>not the intended recipient or an authorized
>representative of the intended recipient, you
>are hereby notified that any dissemination of
>this communication is strictly prohibited. If
>you have received this communication in error,
>please notify us immediately by e-mail and
>delete the message and any attachments from your system.
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Seymour J Metz]

You have to love it when a  manager tells you not to use a COBOL verb but 
instead to use COBOL..

Fortunately, some <https://mason.gmu.edu/~smetz3/#bosses> bosses are  better 
than that.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Friday, March 15, 2024 4:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Learning one's tools

+1 from me on continuing to learn the tools of our profession.  I use STRING 
and UNSTRING where they make sense, and I am still learning new things about 
their use every now and then.  Life-long learning is the only path to happiness 
and success.

I got the same ridiculous pushback from a senior manager one time on the use of 
“sophisticated” SORT verbs like JOIN because “. . . no one but you will know 
how to fix it when it breaks . . . let someone do it in COBOL instead . . .”.

Peter

From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Friday, March 15, 2024 12:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Learning one's tools


To rant on a related subject, I once worked at a company that instituted code 
reviews; a new program would be gone over by a half-dozen coworkers to be sure 
it adhered to local standards.  This sort of thing is always painful to the 
coder, and nevertheless (I admit reluctantly) can have considerable value if 
done right.  One problem I had with it, though, is that the standards we 
created for ourselves admitted that there are times when exceptions should be 
made for special cases, and yet when those cases arose no exceptions were ever 
allowed; the team invariably flinched, leaned back in their seats and said "no, 
that's not according to our standards".



One particular example always rankled:  Whenever someone felt the need to use a 
STRING or UNSTRING command (I should have said we were COBOL developers), the 
team always struck it down on the grounds that STRING and UNSTRING are unusual 
commands and some COBOL coders would be unfamiliar with it.  My contention here 
is that that's absolutely true, and it's the job of the COBOL coder to ~learn~ 
the STRING and UNSTRING statements, as tools of his profession.  I never 
persuaded anyone to that view, though.



---



This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Michael Oujesky]

Wonder how he made senior. Politics and not skills or expertise.

At 03:19 PM 3/15/2024, Farley, Peter wrote:
Content-Transfer-Encoding: base64+1 from me on 
continuing to learn the tools of our 
profession.  I use STRING and UNSTRING where 
they make sense, and I am still learning new 
things about their use every now and 
then.  Life-long learning is the only path to happiness and success.


I got the same ridiculous pushback from a senior 
manager one time on the use of “sophisticated” 
SORT verbs like JOIN because “. . . no one but 
you will know how to fix it when it breaks . . . 
let someone do it in COBOL instead . . .”.


Peter

From: IBM Mainframe Discussion List 

Sent: Friday, March 15, 2024 12:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Learning one's tools


To rant on a related subject, I once worked at a 
company that instituted code reviews; a new 
program would be gone over by a half-dozen 
coworkers to be sure it adhered to local 
standards.  This sort of thing is always painful 
to the coder, and nevertheless (I admit 
reluctantly) can have considerable value if done 
right.  One problem I had with it, though, is 
that the standards we created for ourselves 
admitted that there are times when exceptions 
should be made for special cases, and yet when 
those cases arose no exceptions were ever 
allowed; the team invariably flinched, leaned 
back in their seats and said "no, that's not according to our standards".




One particular example always rankled:  Whenever 
someone felt the need to use a STRING or 
UNSTRING command (I should have said we were 
COBOL developers), the team always struck it 
down on the grounds that STRING and UNSTRING are 
unusual commands and some COBOL coders would be 
unfamiliar with it.  My contention here is that 
that's absolutely true, and it's the job of the 
COBOL coder to ~learn~ the STRING and UNSTRING 
statements, as tools of his profession.  I never 
persuaded anyone to that view, though.




---



This message and any attachments are intended 
only for the use of the addressee and may 
contain information that is privileged and 
confidential. If the reader of the message is 
not the intended recipient or an authorized 
representative of the intended recipient, you 
are hereby notified that any dissemination of 
this communication is strictly prohibited. If 
you have received this communication in error, 
please notify us immediately by e-mail and 
delete the message and any attachments from your system.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Farley, Peter]

+1 from me on continuing to learn the tools of our profession.  I use STRING 
and UNSTRING where they make sense, and I am still learning new things about 
their use every now and then.  Life-long learning is the only path to happiness 
and success.

I got the same ridiculous pushback from a senior manager one time on the use of 
“sophisticated” SORT verbs like JOIN because “. . . no one but you will know 
how to fix it when it breaks . . . let someone do it in COBOL instead . . .”.

Peter

From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Friday, March 15, 2024 12:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Learning one's tools


To rant on a related subject, I once worked at a company that instituted code 
reviews; a new program would be gone over by a half-dozen coworkers to be sure 
it adhered to local standards.  This sort of thing is always painful to the 
coder, and nevertheless (I admit reluctantly) can have considerable value if 
done right.  One problem I had with it, though, is that the standards we 
created for ourselves admitted that there are times when exceptions should be 
made for special cases, and yet when those cases arose no exceptions were ever 
allowed; the team invariably flinched, leaned back in their seats and said "no, 
that's not according to our standards".



One particular example always rankled:  Whenever someone felt the need to use a 
STRING or UNSTRING command (I should have said we were COBOL developers), the 
team always struck it down on the grounds that STRING and UNSTRING are unusual 
commands and some COBOL coders would be unfamiliar with it.  My contention here 
is that that's absolutely true, and it's the job of the COBOL coder to ~learn~ 
the STRING and UNSTRING statements, as tools of his profession.  I never 
persuaded anyone to that view, though.



---



This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Seymour J Metz]

That sounds like a hostile working environment. The people doing a code review 
should know the language and the local standards; nit sounds like they knew 
neither.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu>
Sent: Friday, March 15, 2024 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Learning one's tools

To rant on a related subject, I once worked at a company that instituted code 
reviews; a new program would be gone over by a half-dozen coworkers to be sure 
it adhered to local standards.  This sort of thing is always painful to the 
coder, and nevertheless (I admit reluctantly) can have considerable value if 
done right.  One problem I had with it, though, is that the standards we 
created for ourselves admitted that there are times when exceptions should be 
made for special cases, and yet when those cases arose no exceptions were ever 
allowed; the team invariably flinched, leaned back in their seats and said "no, 
that's not according to our standards".

One particular example always rankled:  Whenever someone felt the need to use a 
STRING or UNSTRING command (I should have said we were COBOL developers), the 
team always struck it down on the grounds that STRING and UNSTRING are unusual 
commands and some COBOL coders would be unfamiliar with it.  My contention here 
is that that's absolutely true, and it's the job of the COBOL coder to ~learn~ 
the STRING and UNSTRING statements, as tools of his profession.  I never 
persuaded anyone to that view, though.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Democracy is where you can say what you think even if you don't think. */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rupert Reynolds
Sent: Thursday, March 14, 2024 22:22

There's nothing wrong with 'signal', of course, except that a lot of people 
reading the code won't be expecting it :-)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Learning one's tools

[Michael Oujesky]

A chain is only as strong as it's weakest link.

Michael

At 11:37 AM 3/15/2024, Bob Bridges wrote:

To rant on a related subject, I once worked at a company that 
instituted code reviews; a new program would be gone over by a 
half-dozen coworkers to be sure it adhered to local standards.  This 
sort of thing is always painful to the coder, and nevertheless (I 
admit reluctantly) can have considerable value if done right.  One 
problem I had with it, though, is that the standards we created for 
ourselves admitted that there are times when exceptions should be 
made for special cases, and yet when those cases arose no exceptions 
were ever allowed; the team invariably flinched, leaned back in 
their seats and said "no, that's not according to our standards".


One particular example always rankled:  Whenever someone felt the 
need to use a STRING or UNSTRING command (I should have said we were 
COBOL developers), the team always struck it down on the grounds 
that STRING and UNSTRING are unusual commands and some COBOL coders 
would be unfamiliar with it.  My contention here is that that's 
absolutely true, and it's the job of the COBOL coder to ~learn~ the 
STRING and UNSTRING statements, as tools of his profession.  I never 
persuaded anyone to that view, though.


---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Democracy is where you can say what you think even if you don't think. */

-Original Message-
From: IBM Mainframe Discussion List  On 
Behalf Of Rupert Reynolds

Sent: Thursday, March 14, 2024 22:22

There's nothing wrong with 'signal', of course, except that a lot of 
people reading the code won't be expecting it :-)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Learning one's tools

[Bob Bridges]

To rant on a related subject, I once worked at a company that instituted code 
reviews; a new program would be gone over by a half-dozen coworkers to be sure 
it adhered to local standards.  This sort of thing is always painful to the 
coder, and nevertheless (I admit reluctantly) can have considerable value if 
done right.  One problem I had with it, though, is that the standards we 
created for ourselves admitted that there are times when exceptions should be 
made for special cases, and yet when those cases arose no exceptions were ever 
allowed; the team invariably flinched, leaned back in their seats and said "no, 
that's not according to our standards".

One particular example always rankled:  Whenever someone felt the need to use a 
STRING or UNSTRING command (I should have said we were COBOL developers), the 
team always struck it down on the grounds that STRING and UNSTRING are unusual 
commands and some COBOL coders would be unfamiliar with it.  My contention here 
is that that's absolutely true, and it's the job of the COBOL coder to ~learn~ 
the STRING and UNSTRING statements, as tools of his profession.  I never 
persuaded anyone to that view, though.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Democracy is where you can say what you think even if you don't think. */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rupert Reynolds
Sent: Thursday, March 14, 2024 22:22

There's nothing wrong with 'signal', of course, except that a lot of people 
reading the code won't be expecting it :-)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN