And just so y'all know, I'm not forcefully arguing and certainly
appreciate the different points of view.
On 6/17/2021 10:15 AM, Mike Hochee wrote:
I suspect I'm a 'man overboard' on this one, but don't feel I need a life
preserver. Having worked on some larger products with many many moving parts,
and not of my own making, I would always welcome the use of Token_Len, and if
it is being used to prime a register, no comment really needed. I'm good with
the COBOL example as well, and might not even take note of potential overkill.
At some point, so called structured programming, functional decomposition,
re-usage, (maybe even 'elegance'), made their way into my brain and heart, so
that they are now tightly bound up with my soul, and I never even knew it was
happening! Powerful stuff!
On the other hand, when my performance and efficiency identity asserts itself,
the COBOL example would be a strong candidate for change, and I wouldn't think
twice about it.
Mike
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Tom Brennan
Sent: Thursday, June 17, 2021 12:33 PM
To: [email protected]
Subject: Re: Coding for the future
Caution! This message was sent from outside your organization.
Of course! But now let's say there's only one instance of TOKEN_LEN being
referenced and it's highly unlikely to ever be changed. That's the case I'm
talking about here - which I think happens far more often than fields that
change their size over time.
Sometimes people go a bit overboard coding for a future that never happens -
that's what I'm trying to describe. One example: I remember looking at
someone's COBOL source code that did a procedure call. That procedure was a
single line that called another procedure. So off to another member, and all
that final procedure did was a single MOVE statement. All this was to comply
with structured programming methods designed to handle future changes that
would likely never happen.
On 6/17/2021 8:19 AM, Wayne Driscoll wrote:
Until the definition of a token changes such that the new length is 32 instead
of 5. Changing the one macro that defines TOKEN_LEN is much easier than
searching for all instances of LA Rx,5 and then determining if it is process
a TOKEN, or if the value is for some other reason.
Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.
From: IBM Mainframe Discussion List <[email protected]> On
Behalf Of Tom Brennan
Sent: Wednesday, June 16, 2021 9:23 PM
To: [email protected]
Subject: Re: Coding for the future
EXTERNAL EMAIL
I'd actually rather read LA R7,5 so I don't have to hunt for where
Token_Len is defined.
On 6/16/2021 3:24 PM, Charles Mills wrote:
And if the instruction itself were
LA R7,Token_Len
Then it would be more clear and more maintainable.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]]
On Behalf Of Jesse 1 Robinson
Sent: Wednesday, June 16, 2021 3:07 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: Coding for the future
Avoid embedding code specific details in comments.
Init loop counter in R7 to 5
A comment should not name anything explicitly stated in the
instruction. 'R7' in the comment is not merely redundant. If the loop
register needs to be changed later on, then the comment will have to
be updated also. If it's not updated, then it becomes misleading,
perhaps worse than no comment at all. I would prefer
LA R7,5 Prepare to search for delimiter
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
[email protected]<mailto:[email protected]>
-----Original Message-----
From: IBM Mainframe Discussion List
<[email protected]<mailto:[email protected]>> On Behalf
Of Mike Schwab
Sent: Wednesday, June 16, 2021 2:17 PM
To: [email protected]<mailto:[email protected]>
Subject: (External):Re: EXTERNAL: Coding for the future
*** EXTERNAL EMAIL - Use caution when opening links or attachments
***
But what is Register 7 going to be used for, and why does it need a 5?
I. E. Init loop counter in R7 to 5.
On Wed, Jun 16, 2021 at 11:48 AM Savor, Thomas
<[email protected]<mailto:[email protected]>>
wrote:
==> LA R7,5 Put 5 in register 7
It depends on the intended target audience. Now I and you know that a 5 is put in
Register 7, but many shops have only a couple Assembler Programmers....but many more
Cobol programmers. Telling "them" that a 5 is put in Register 7 can be helpful
to solving a problem or learning what a program does.
Way too many Cobol programmers that I run into are scared of looking at Assembler...like
just looking at it or trying to learn it is going to give you Ebola...so even very basic
instructions can be helpful...especially if Instruction says LA 7,5 then it really helps
"them".
Thanks,
Tom
-----Original Message-----
From: IBM Mainframe Discussion List
<[email protected]<mailto:[email protected]>> On
Behalf Of Seymour J Metz
Sent: Wednesday, June 16, 2021 11:58 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: EXTERNAL: Coding for the future
Long ago in a galaxy far away, they handed each of us a stack of manuals and
told use that we were all enrolled in a 7070 class and had to read all of the
manuals before the class started. It turned out that some of the students were
answering questions that stumped the instructor, and that if you read the
manuals you didn't need the course.
The worst are the ones that score based on the quantity of comments instead of
their quality. That guaranties cluttered and unhelpful comments. People will
behave in such a fashion as to optimize how their organization ranks them; if
teir grades or performance reviews depend on doing something sub-optimal, then
that's what they'll do. Measure the things that actually matter.
I generally frown on marking students down on stylistic issues like
labels on separate lines, but I will mark down for
LA R7,5 Put 5 in register 7
Don't tell me what LA does, tell me why you're putting that value in that
register. If there is nothing useful to say in the comment, then omit it.
--
Shmuel (Seymour J.) Metz
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmas
on<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F
mason> gmu.edu/~smetz3<http://gmu.edu/~smetz3>
&data=04%7C01%7Cthomas.savor%40fisglobal.com%7Cb
e99c6f1bde54085afe408d930df9961%7Ce3ff91d834c84b15a0b418910a6ac575%7
C0
%7C0%7C637594559179362403%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
Ai
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kaKO
h2
8RkIFxgof3dWR3QMgfWMAyZeQ8ijJ7XLqXpXE%3D&reserved=0
________________________________________
From: IBM Mainframe Discussion List [[email protected]] on
behalf of Phil Smith III [[email protected]]
Sent: Wednesday, June 16, 2021 11:17 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: EXTERNAL: Coding for the future
Crawford, Robert C. wrote, in part:
Oh, and I used to this:
LOOP MVC HERE,THERE
And now do this:
LOOP DS 0H
MVC HERE,THERE
Yes, I was taught that early. Then I took a Commodore SuperPet
assembler class (after writing 370 assembler for several years).
That assembler had no
DS 0H
but it did have
EQU *
So I used that-and was marked down for it. At that point, I stopped taking the
class seriously.
---------------------------------------------------------------------
- For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
[email protected]<mailto:[email protected]> with the
message: INFO IBM-MAIN
---------------------------------------------------------------------
- For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
[email protected]<mailto:[email protected]> with the
message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [email protected]<mailto:[email protected]>
with the message: INFO IBM-MAIN
================================
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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
