Re: Best (or any) practices to rewrite spaghetti
Personally, I consider a 'branch to abnormal exit' much better than trying to unwind all the 'perform' levels, be it COBOL or Assembler. I have seen programs where they attempted to unwind everything during an error and ended up processing code unintentionally. Tony Thigpen -Original Message - From: Miklos Szigetvari Sent: 02/03/2011 12:16 PM Hi Asking here for the best practices to rewrite spaghetti assembler code to use structured programming macros I think I red a number of SHARE presentations My concern is currently the error handling Till now, if an error occurred, there was a JUMP/BRANCH to an error block, with all the possible error messages , and after a JUMP/BRANCH to the module RETURN. Seems to me , instead of this, some DOEXIT or ASMLEAVE would be more complicated
Re: Best (or any) practices to rewrite spaghetti
There's no reason your SP macro code can't include a jump to an error handler when an error occurs. Donald Knuth once wrote a scholarly article called Structured Programming with GOTO Statements where he showed that attempts to be purely structured were often more obscure than using a GOTO when it was simplest. Miklos Szigetvari asked: Asking here for the best practices to rewrite spaghetti assembler code to use structured programming macros I think I red a number of SHARE presentations My concern is currently the error handling Till now, if an error occurred, there was a JUMP/BRANCH to an error block, with all the possible error messages , and after a JUMP/BRANCH to the module RETURN. Seems to me, instead of this, some DOEXIT or ASMLEAVE would be more complicated
Re: ASSEMBLER-LIST Digest - 20 Jan 2011 to 21 Jan 2011 (#2011-11)
Another thing to check is the LOCK or UNLOCK status by issuing the PROFILE command with no parameters on the ISPF command line while in edit on one of the affected members: =PROF JCL (FIXED - 80)RECOVERY ONNUMBER OFF.. =PROF CAPS ONHEX OFFNULLS ON STDTABS ON ` =PROF AUTOSAVE ONAUTONUM OFFAUTOLIST OFFSTATS ON. =PROF PROFILE UNLOCKIMACRO NONEPACK OFFNOTE ON... =PROF HILITE OFF CURSOR FIND. =TABS - * * * =COLS +1+2+3+4+5+6+7+ If you set the profile the way you want it, and then issue PROFILE LOCK. Changes you make during an individual edit session will then not affect the saved version of the profile and should always start an edit session with the saved profile settings. If you have UNLOCK then a change made during one session may affect your later sessions. --Roger On Mon, Jan 31, 2011 at 1:44 PM, John Walker jwalker...@yahoo.com wrote: Say, I have been noticing over the last year or so that i FREQUENTLY end up with my edit setting set to NULLS ON. This is an annoying and aberrant setting for any non-PC or non-unix use, which is to say ALL mainframe applications and work. However, when I set it to off, it ends up being reset somehow by ISPF. It seems that sometimes I am not even in browse or edit and it still does it. How can I reset this obvious over-riding default which I dislike?
Re: Best (or any) practices to rewrite spaghetti
One of the ways I avoid too many nested IF statements is to use straddling DO/ENDDO around code that may require several let's get outta here now moments. For example : DO, Some code DOEXIT (TM,flag,bit,NO) ... Some more code DOEXIT (CLC,field,NE,value) ... Call some subroutine DOEXIT (LTR,R15,R15,NZ) ...etc ENDDO You could also label the DO (eg MAIN) and then use something like ASMLEAVE MAIN from anywhere later in the logic. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Johanson, Adam Sent: 03 February 2011 18:42 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Best (or any) practices to rewrite spaghetti John Ehrman wrote: There's no reason your SP macro code can't include a jump to an error handler when an error occurs. Donald Knuth once wrote a scholarly article called Structured Programming with GOTO Statements where he showed that attempts to be purely structured were often more obscure than using a GOTO when it was simplest. Yeah, what they said. I recently changed a couple of multi-thousand-line programs to use SPMs and my first thought was that I was going to eliminate all of the branches in them. But as I got going, it became pretty apparent that to do so would require things that made the code a little bit less readable, like lengthening IF-blocks and adding a couple of more indentation spacings to blocks that already had a fair amount of indentation to them. Then, I told myself that the whole point of the exercise was to make the code more readable, so a branch to a return-to-caller label every now and then didn't really defeat the purpose and actually _did_ help things. IMHO, rather than seeing a big nested IF statement and chasing down the end point just to figure out that you're gonna return to the caller is a bit more involved than realizing, Oh, I'm just getting out of Dodge. And you've probably come across it in the SHARE presentations that you've seen, but if you're going to do this, download Ed Jaffe's FLOWASM exit. It makes life easier. Adam Johanson IMS Systems Programming USAA
Re: Best (or any) practices to rewrite spaghetti
On 2/3/2011 10:41 AM, Johanson, Adam wrote: Then, I told myself that the whole point of the exercise was to make the code more readable, so a branch to a return-to-caller label every now and then didn't really defeat the purpose and actually _did_ help things. IMHO, rather than seeing a big nested IF statement and chasing down the end point just to figure out that you're gonna return to the caller is a bit more involved than realizing, Oh, I'm just getting out of Dodge. Yup. You can find analogs in other languages. For example SIGNAL and EXIT in REXX. Programs can become unnecessarily complex if you require every condition to be surfaced back up through a deeply-nested logic hierarchy. Depending on your program design, an signal/exit jump from anywhere can be problematic when using a stack for (at least) saving/restoring registers. If you signal/exit with the stack pushed several levels deep, your current registers might not be appropriate for the signal/exit routine and, if the stack is needed for any processing after that, you'll need a way to unwind the stack to the appropriate level or else things might go horribly wrong--for example when the signal/exit routine itself tries to return to the original caller. The easiest way to avoid this is to never branch to a signal/exit label from an inner routine. Or put another way, each stack level has its own signal/exit routine. Another way we've handled the signal/exit jump from anywhere is to save the appropriate stack control and registers in some easily addressable non-stack storage from which they are loaded/copied as one of the very first things the signal/exit routine does. FWIW, when writing code from scratch it is often possible to avoid signal/exit branches entirely by enclosing the logic within two nested simple DOs as shown. We have used this technique quite effectively in some very large and complex programs. (This is only an example. Many other variants of this approach are possible.) | DO LABEL=MainLineDo for MainLine routine | | | * Process MainLine Logic Here * | | DO LABEL=MainLineLogic Do for MainLine logic | . | .(some deeply nested code here discovers an error) | LHI R15,ErrorCode1 Load error code | LEAVE MainLineLogic Go perform error processing | . | .(another error is discovered) | LHI R15,ErrorCode2 Load error code | LEAVE MainLineLogic Go perform error processing | . | .(this can be a very large and complex routine) | . | XRR15,R15Set return code = 0 | LEAVE MainLine Exit the routine | ENDDO , MainLineLogicEndDo for MainLine error trap | | | * Process MainLine Errors Here * | | SELECT CHI,R15,EQSelect error code | WHEN ErrorCode1 ErrorCode1 | (whatever) Issue msg, set retcode/rsn, etc. | WHEN ErrorCode2 ErrorCode2 | (whatever) Issue msg, set retcode/rsn, etc. | OTHRWISE , Unknown Error Code | J *+2Logic error. Force abend here. | ENDSEL , EndSel error code | ENDDO , MainLine EndDo for MainLine routine And you've probably come across it in the SHARE presentations that you've seen, but if you're going to do this, download Ed Jaffe's FLOWASM exit. It makes life easier. I'm glad you found it useful. 8-) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: Best (or any) practices to rewrite spaghetti
I'm sure others will tell you about coding techniques and structured macros etc. My advice when improving old spaghetti assembler code is this: Make sure you have a regression test library ready to insure that the behavior of the new code matches the old code. Spaghetti code can hide a lot of little subtleties and you need to make sure that the more structured, more readable code doesn't change or miss anything. You also need to compare performance. On more than one occasion we found the performance of the old spaghetti code module hard to beat or match. --Roger On Thu, Feb 3, 2011 at 10:16 AM, Miklos Szigetvari miklos.szigetv...@isis-papyrus.com wrote: Hi Asking here for the best practices to rewrite spaghetti assembler code to use structured programming macros I think I red a number of SHARE presentations My concern is currently the error handling Till now, if an error occurred, there was a JUMP/BRANCH to an error block, with all the possible error messages , and after a JUMP/BRANCH to the module RETURN. Seems to me , instead of this, some DOEXIT or ASMLEAVE would be more complicated
Re: Best (or any) practices to rewrite spaghetti
On Thu, Feb 3, 2011 at 6:29 PM, Tony Thigpen t...@vse2pdf.com wrote: Personally, I consider a 'branch to abnormal exit' much better than trying to unwind all the 'perform' levels, be it COBOL or Assembler. I have seen programs where they attempted to unwind everything during an error and ended up processing code unintentionally. My father used to say that 'anything with too in it is bad' and I had to think of that when I was recently trying to untange some ancient code. I allow myself premature exit to the end of the routine as well, but it's a glippery slope. At least I find that when you don't give it enough thought, it's easy to end up with a lot of them and make following the flow much harder. My dialect of Structured Assembler does a combined call with automatic exit on nonzero return code Though this is the same as coding that extra branch, the simplification to me is that it's always the same NZ that does the exit. If necessary, I will put a number of those diverse tests in a subroutine and let that conclude Z or NZ. That avoids things like this: CLC DEVADDR,RANGELO BL EXIT CLC DEVADDR,RANGEHI BH EXIT | Rob
Re: Best (or any) practices to rewrite spaghetti
Hi Thank you very much for everybody. The answers has confirmed my view , to overuse a good technique can lead to obscure results. On 2/3/2011 9:15 PM, Roger Bolan wrote: I'm sure others will tell you about coding techniques and structured macros etc. My advice when improving old spaghetti assembler code is this: Make sure you have a regression test library ready to insure that the behavior of the new code matches the old code. Spaghetti code can hide a lot of little subtleties and you need to make sure that the more structured, more readable code doesn't change or miss anything. You also need to compare performance. On more than one occasion we found the performance of the old spaghetti code module hard to beat or match. --Roger On Thu, Feb 3, 2011 at 10:16 AM, Miklos Szigetvari miklos.szigetv...@isis-papyrus.com wrote: Hi Asking here for the best practices to rewrite spaghetti assembler code to use structured programming macros I think I red a number of SHARE presentations My concern is currently the error handling Till now, if an error occurred, there was a JUMP/BRANCH to an error block, with all the possible error messages , and after a JUMP/BRANCH to the module RETURN. Seems to me , instead of this, some DOEXIT or ASMLEAVE would be more complicated
