Re: *INZSR - I still love you!!!

[Hans Boldt <boldt@xxxxxxxxxx>]

DeLong, Eric wrote:
> Rick, as I recall it, the real need for *INZSR came from the RESET opcode,
> which depends on a step in the cycle where initialized storage is saved
> before starting the main calcs.  *INZSR lets you programatically initialize
> storage before it is captured as "initialized".  This lets you RESET complex
> structures easily and quickly to their original initialized values.  For
> some reason, I've never seen RESET used much in the code I've maintained.  

I'm not sure when or where I last told this story:

I still remember the design meetings where this particular set of 
enhancements was discussed. At the time, I was busy working on the SAA 
RPG 370 compiler, but was occasionally invited to design meetings for 
the RPG III compiler on the 400. At this particular set of meetings, we 
were discussing what enhancements were needed in the area of 
initialization, such as initial values on I-Specs, named constants, 
CLEAR opcode, etc. I was arguing to keep things simple, but others 
wanted more and more functionality. I got fed up with that "creeping 
featurism" and suggested something I thought was totally ridiculous. 
Unfortunately, that backfired on me when the developer loved the idea, 
and I couldn't talk her out of it. That "ridiculous" idea was the RESET 
opcode. It took many releases before RESET worked properly, long after 
the original developer left IBM for a job in Redmond.

Personally, I'd just as soon see explicit assignments instead of the 
RESET opcode. If something needs to be reset to some value in several 
places, then the initializations should go into a separate procedure or 
subroutine and called as needed. There's nothing magical about a 
separate RESET opcode, and the use of such an opcode can increase the 
resources needed for the program.

Cheers! Hans