I've seen lots of things changed after assurances that they never would; if there's no performance penalty, I prefer to play safe.
I'd have to see the COBOL code in context to judge whether a subroutine is overkill, but I'm no fan of rigid stylistic rules. OTOH, a style that is a harmful requirement may still be a good ROT, and I prefer to use conditional and iteration structures where they make sense; That goes for, e.g., Perl, PL/I, REXX, just as much as HLASM. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Tom Brennan [[email protected]] Sent: Thursday, June 17, 2021 12:32 PM To: [email protected] Subject: Re: Coding for the future 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%2Fmason<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason> >>> gmu.edu/~smetz3<http://gmu.edu/~smetz3> >>> &data=04%7C01%7Cthomas.savor%40fisglobal.com%7Cb >>> e99c6f1bde54085afe408d930df9961%7Ce3ff91d834c84b15a0b418910a6ac575%7C0 >>> %7C0%7C637594559179362403%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi >>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kaKOh2 >>> 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
