> -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:[email protected]] On Behalf Of John Gilmore > Sent: Monday, July 02, 2012 9:37 AM > To: [email protected] > Subject: Re: Detecting RMODE at assembly time > > Paul Gilmartin wrote > > <begin extract> > Regardless, nowadays, any 24->31 bit conversion is underreaching; > shortsighted; mostly wasted resource. Go for 64! Even while RMODE 64 > execution is mostly unsupported, the 64-bit interfaces can be coded > and the code run AMODE 64 below the bar in the interim. > </end extract> > > This is a sentiment that I agree with strongly. > > It is, moreover, my own practice. Why then didn't I advocate it in my > earlier posts in this thread? > > I took the temporizing position that AMODE(24) routines should be > converted to AMODE(31) ones instead. Cowardice? Perhaps in some > measure, but I had the strong sense that it would be a futile gesture > to recommend AMODE(64). > > It often seems to me---Witness the neanderthal reactions to even that > recommendation---that trailing-edge shops are emotionally unprepared > to respond to technical imperatives. At most and not always they may > be willing to take faltering baby steps in one of the right > directions. > > I did learn something from this experience. I shall do no > more temporizing. > > John Gilmore, Ashland, MA 01721 - USA
I will say that my shop, which is small and shrinking, is mainly AMODE(31). Of course, that's because 95+% of all applications are COBOL based. 4+% of the remainder are EasyTrieve Plus, and I think we have maybe 10 HLASM subroutines. And we will become AMODE(64) when: (1) COBOL supported and (2) we are __forced__ to upgrade the compiler. The __forced__ in the previous is because we are on 3.4 and won't go to 4.1 due to the price increase. I, personally, use AMODE(31)/RMODE(ANY) for most of my code, except for that which RMODE(24) is required. Which I bundle into a subroutine. Some would say this proves that using an HLL is inherently superior than HLASM. I would likely agree for business applications. Definitely not true if we were capable of "real time" processing. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
