In the 1980s, like most shops, we ran JES2 Exit 13 in order to get notify 
messages. For some reason you had to give JES2 a non-default return code 
from Exit 13 or the message was suppressed. I became the JES2 guy after a 
decade or more of MVS history in the shop. At some point--for reasons lost 
in the mists of time--I decided that we needed to give a different return 
code conditionally, so I added a compare and branch to the vanilla code 
taken directly the IBM sample. We started getting occasional bizarre 
abends in the most unlikely spots in JES2. The only commonality was that 
there was no reason to have been running the abending code in the first 
place. After a series of more or less daily calls from Level 2, the 
culprit was finally outed. The fine sample Exit 13 legitimately defined a 
base register but never initialized it. Every time my exit took the new 
branch, it went hurtling off into some random piece of code depending on 
which JES2 module had most recently set that register. IBM fixed the 
sample exit. ;-) 

Moral: this sort of problem is not necessarily the product of modern 
whippersnapper coding. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[email protected]



From:   Tony Harminc <[email protected]>
To:     [email protected], 
Date:   02/27/2013 12:32 PM
Subject:        Re: SAVE macro
Sent by:        IBM Mainframe Discussion List <[email protected]>



On 27 February 2013 10:08, Phil Smith <[email protected]> wrote:
> Thanks, Steve. I had searched for that book but somehow wound up in the 
Assembler Services Guide, which of course wasn't as helpful.
>
> Removing the extra quotes seems to have fixed it:
>          SAVE  (14,12),,'&SYSPARM &SYSDATE &SYSTIME'
>
> Am I unreasonable to be vaguely horrified that the samples don't even 
work?

No. But it's a fact of life these days. IBM ships all sorts of
assembler stuff that either doesn't work at all (e.g. some VTAM/VSAM
macros), breaks commonly used conventions or newer HLASM functions
(e.g. SETRP), or is so badly designed as to be near impossible to use
without local changes or ugly workarounds (some IRX macros).

I am sure the main reason for this is that hardly anyone in IBM writes
assembler code anymore. IBM developers use PL/X, and only if defined
programming interfaces or the need for sample programs call for it,
are assembler pieces written, but often enough they are not tested
even to the point of obtaining a clean assembly.

There is the related problem of many "assembler" mapping macros (e.g.
IGWSMF)  being generated in a programmer-surly form from PL/X (or some
other?) originals, but that is perhaps another rant.

Tony H.



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to