As always, the answer is it depends -- on what you mean by easier. 1. You have already finished the subroutine. To do it another way would mean more work, which is not easier. 2. You could probably do it in APL with only one instruction, but the result would be unintelligible gibberish to everyone except an APL expert. 3. What is easier for someone else to maintain your subroutine, to me, would imply making the code as intuitively obvious and straightforward as possible. If this is your definition of easier, then you are all done. 4. There could well be a new exotic instruction in the z/OS architecture that I haven't learned about yet that would reduce some of your logic by one or more instructions, but the result might be less intuitively obvious looking to someone else (similar to 3 above). 5. There might be another way to code this logic that would execute faster than your code now, but it might also be less intuitively obvious looking to someone else (see 3 above some more). 6. IBM could introduce a new instruction next year that would replace much of your logic, but ... (see 3 above). You wrote the code the way I would write it, except that I might not have counted the spaces while scanning left, in which case I would subtract the address of the right-most non-blank from the address of the end of the field to compute the number of spaces. This would probably execute faster than your technique. But "faster" is also relative -- how many million times per second will your subroutine run? How much will the savings in execution time be worth compared to your extra time to reinvent an already working wheel? Good job. Stop while you are ahead. Another thing to remember is that no matter how good, excellent, and optimal your code is, someone else might still be able to tweak it slightly so that it is even better. Back in the late 1960s some colleagues of mine and I challenged each other to code a text-editing subroutine such that the resulting code fit in the smallest number of bytes with no regard for how many instructions were executed, if the code was self-modifying or not, etc. The various results we all produced were interesting, convoluted, and surprisingly innovative. Bill Fairchild
----- Original Message ----- From: "John P Kalinich" <[email protected]> To: [email protected] Sent: Thursday, May 15, 2014 11:13:07 AM Subject: Right Justification Subroutine I wrote a small subroutine to right justify a field. I started scanning left at the end of the field and counted spaces until I found a non-blank character. Then I subtracted the number of blanks from the starting address of the field (which was prefixed with spaces) and then moved the data from that address to a new field. Is there an easier way to do this? Regards, John K
