Same here Sam. Too many old programs, not enough personnel (especially those conversant in assembler), and way too many "new business" needs. "If it ain't broke, don't fix it" still rules the roost, regardless of the TCO.
No technician worth his salt likes it, but those are the rules we get paid by. Though I will say the mgmt would probably listen to us more often if we technicians could write a cogent TCO analysis. If anyone out there has ever put together such a justification to "fix" the old stuff (especially the ancient assembler that just about every job in the shop uses) and prove ** in management terms ** that the TCO was actually worth the effort, I would love to see a copy (suitably redacted, of course -- no need to invite lawyers into the mix). Peter -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Sam Siegel Sent: Friday, April 19, 2013 12:50 PM To: [email protected] Subject: Re: AMODE(24). How much is there? On Fri, Apr 19, 2013 at 9:31 AM, Ed Jaffe <[email protected]>wrote: > I saw a discussionon IBM-MAINrecently about how many MVS TCBs was "too > many" MVS TCBs in an address space. > > System control blocks like TCB, located in LSQA below 16MB, will likely > never be moved above 16MB since it's still possible for a 24-bit program > to load PSATOLD and reference GUPI fields in the TCB. > > This got me wondering about just how much AMODE(24) code is still out > there--not only for z/OS but for other operating systems as well. Any > ideas? Are most programs still 24-bit? Half of them? Ten percent or less? > > For my employer there is a substantial about of simple batch COBOL and Assembler program that are amode(24). They are not converted to amode(31) because a) work effort required to recompile/assemble and test; b) certain old programs whose source code is lost are amode(24) and are called by many other programs. There is no business case to modify so they stays the same. The dev staff does not have time to "fix" this because of the volume of business change requests far outweighs the ability to update programs for issues like this. We only specifically converted 1 set of program to amode(31) because that job was running out of below the line memory. And it was an important job. > -- > Edward E Jaffe > Phoenix Software International, Inc > 831 Parkview Drive North > El Segundo, CA 90245 > http://www.phoenixsoftware.**com/ <http://www.phoenixsoftware.com/> > 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.
