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
