Arghh! Difference between 'GETMAIN R,LV=(0)' and 'STORAGE OBTAIN,LENGTH=(0)' 
Author Message
 Arghh! Difference between 'GETMAIN R,LV=(0)' and 'STORAGE OBTAIN,LENGTH=(0)'

While upgrading a set of programs to run with AMODE=31, I started getting S0C4
abends which I finally tracked down to the following change:
    GETMAIN R,LV=(0)
changed to:
    STORAGE OBTAIN,LENGTH=(0)

I couldn't understand why since they both have the same input and output register
specifications.

It turned out that GETMAIN does not alter R14 even though the doc says it is used
as a work register, program expected R14 value to be preserved across SVC and
this was not the case with STORAGE!

Yes, I know it's an error in the original program (which I didn't write), it's
just another case of being bitten by "known" (as opposed to documented) behaviour
of system macros.

--
Robert Ngan
CSC Financial Services Group



Sun, 02 Jul 2000 03:00:00 GMT  
 Arghh! Difference between 'GETMAIN R,LV=(0)' and 'STORAGE OBTAIN,LENGTH=(0)'


:>While upgrading a set of programs to run with AMODE=31, I started getting S0C4
:>abends which I finally tracked down to the following change:
:>    GETMAIN R,LV=(0)
:>changed to:
:>    STORAGE OBTAIN,LENGTH=(0)

:>I couldn't understand why since they both have the same input and output register
:>specifications.

:>It turned out that GETMAIN does not alter R14 even though the doc says it is used
:>as a work register, program expected R14 value to be preserved across SVC and
:>this was not the case with STORAGE!

The macro may alter R14 based on the parameters. But not necessarily.

:>Yes, I know it's an error in the original program (which I didn't write), it's
:>just another case of being bitten by "known" (as opposed to documented) behaviour
:>of system macros.

As the SVC only alters R15-R1 and the expansion may alter R14, the programmer
knew that R14 would not be altered in his expansion. The only expansion of the
SVC entry that uses R14 is the LIST form.

--


Director, Dissen Software, Bar & Grill - Israel



Mon, 03 Jul 2000 03:00:00 GMT  
 Arghh! Difference between 'GETMAIN R,LV=(0)' and 'STORAGE OBTAIN,LENGTH=(0)'

One of the very first things I learned when starting to use ASSEMBLY
is to NEVER assume anything about macro internal expansions.
Forward compatibility is based upon the right to modify the expansion
in future releases of the macro.

Rule #2: Unless specifically advised otherwise never assume anything
about the contents of general purpose registers 14, 15, 0 and 1 after
the execution of any system services macro. In this particular case the
DOC even stated that register 14 was (read: "could be") used as a work
register!

So the error here was obviously writing a program assuming that the
contents of register 14 was unchanged after a GETMAIN call. It clearly
did work once upon a time, but was a latent bomb. Stay glad you
discovered
it before more damage was done. Again this shows the danger of
programming
according to "what works (now)" instead of programming according to
documentation.

regards Sven

Quote:


. . . . . (snip)
> :>It turned out that GETMAIN does not alter R14 even though the doc says it is used
> :>as a work register, program expected R14 value to be preserved across SVC and
> :>this was not the case with STORAGE!

> The macro may alter R14 based on the parameters. But not necessarily.

> :>Yes, I know it's an error in the original program (which I didn't write), it's
> :>just another case of being bitten by "known" (as opposed to documented) behaviour
> :>of system macros.

. . . . . (snip)


Tue, 04 Jul 2000 03:00:00 GMT  
 Arghh! Difference between 'GETMAIN R,LV=(0)' and 'STORAGE OBTAIN,LENGTH=(0)'



Quote:
>One of the very first things I learned when starting to use ASSEMBLY is
>to NEVER assume anything about macro internal expansions. Forward
>compatibility is based upon the right to modify the expansion in future
>releases of the macro.

I disagree: give us examples of commonly-used macros whose use of
registers has changed over the last 20 years.

Quote:
>Rule #2: Unless specifically advised otherwise never assume anything
>about the contents of general purpose registers 14, 15, 0 and 1 after the
>execution of any system services macro. In this particular case the DOC
>even stated that register 14 was (read: "could be") used as a work
>register!

I disagree also.  Most forms of R-type GETMAIN do NOT use R14 for anything
and this is NOT going to change.  R-type GETMAIN has been frozen back in
1974.

In OS/VS2 R2 (MVS' first cut), SVC 10 (R-type GETMAIN/FREEMAIN) was
changed and R0 no longer contained the length of the area as it did in MVT
(and perhaps in SVS) after SVC 10 returned to the program.  A PTF quickly
reversed the change because many user (and IBM) programs were expecting R0
to retain its value, although this behaviour was NOT documented back then
(I'm not sure it is even today).  I remember patching the PL/1 (F)
compiler to work around this problem and allow it to run on MVS back in
1975.  Bottom line: it's R0, it's not documented, it should be documented,
and you can count on it.

Similar example: the doc for READ/WRITE/CHECK MF=E tells you that you
can't use R1 to pass the address of the DECB, which is not true (you can).
I tried to have the doc changed years ago, but last time I checked it
hadn't been modified.  If you look at the code generated by these macros,
it's obvious that it's absolutely safe to use R1 and that IBM can't
possibly change it or a million users would have to reassemble a zillion
programs.  But it's not documented and many people won't use R1 although
it's absolutely safe to do so.  Bottom line: it's R1, it's not documented,
it should be documented, and you can count on it.

Quote:
>So the error here was obviously writing a program assuming that the
>contents of register 14 was unchanged after a GETMAIN call. It clearly
>did work once upon a time, but was a latent bomb. Stay glad you
>discovered it before more damage was done. Again this shows the
>danger of programming according to "what works (now)" instead of
>programming according to documentation.

I disagree also.  The error was not caused because GETMAIN changed
unexpectedly; it was caused by the programmer who assumed that the STORAGE
macro worked like GETMAIN.  

BTW, why did the programmer change GETMAIN to STORAGE?  Why fix it if it
ain't broke?




Thu, 06 Jul 2000 03:00:00 GMT  
 Arghh! Difference between 'GETMAIN R,LV=(0)' and 'STORAGE OBTAIN,LENGTH=(0)'

Quote:



> >One of the very first things I learned when starting to use ASSEMBLY
> >is to NEVER assume anything about macro internal expansions. Forward
> >compatibility is based upon the right to modify the expansion in
> >future releases of the macro.
> I disagree: give us examples of commonly-used macros whose use of
> registers has changed over the last 20 years.

Well, maybe I am over-cautious, but that is still what I learned and
still
my opinion. As for macro expansion changes you don't need go farther
than
to the much used TIME macro. Agreed, the changes there are generally
controlled by changes in the parameters, but the rule anyway remains:
Use the macro according to documentation, not according to what you find
by studying the expansion of some samples.

Quote:
> >Rule #2: Unless specifically advised otherwise never assume anything
> >about the contents of general purpose registers 14, 15, 0 and 1 after
> >the execution of any system services macro. In this particular case
> >the DOC even stated that register 14 was (read: "could be") used as
> >a work register!
> I disagree also.  Most forms of R-type GETMAIN do NOT use R14 for
> anything and this is NOT going to change.  R-type GETMAIN has been
> frozen back in 1974.

Probably correct, I couldn't tell, and in any case I would NOT depend
upon it.
(My note on DOC here of course related to STORAGE, not to GETMAIN -
sorry)

Quote:
> In OS/VS2 R2 (MVS' first cut), SVC 10 (R-type GETMAIN/FREEMAIN) was
> changed and R0 no longer contained the length of the area as it did in MVT
> (and perhaps in SVS) after SVC 10 returned to the program.  A PTF quickly
> reversed the change because many user (and IBM) programs were expecting R0
> to retain its value, although this behaviour was NOT documented back then
> (I'm not sure it is even today).  I remember patching the PL/1 (F)
> compiler to work around this problem and allow it to run on MVS back in
> 1975.  Bottom line: it's R0, it's not documented, it should be documented,
> and you can count on it.

I think this part clearly confirms the problems arising from making a
program work by trial (and error) instead of programming according to
documentation. In my opinion that is one of the main causes for much of
the
errors associated with computers in the society. When IBM felt compelled
to
PTF something due to the widespread use of an undocumented feature this
does
not make the habit any better, but I suppose we have to live with it.

Quote:
> Similar example: the doc for READ/WRITE/CHECK MF=E tells you that you
> can't use R1 to pass the address of the DECB, which is not true (you can).
> I tried to have the doc changed years ago, but last time I checked it
> hadn't been modified.  If you look at the code generated by these macros,
> it's obvious that it's absolutely safe to use R1 and that IBM can't
> possibly change it or a million users would have to reassemble a zillion
> programs.  But it's not documented and many people won't use R1 although
> it's absolutely safe to do so.  Bottom line: it's R1, it's not documented,
> it should be documented, and you can count on it.

If you look at the code as it is today - sure, but tell me: Is there any
serious reason why a program must pass the DECB address in R1 instead of
in one of the registers 2 through 12 which is the proper way according
to
documentation? If there really is a zillion programs out there made this
way I really question the qualities of the programmers producing those
programs.

Quote:
> >So the error here was obviously writing a program assuming that the
> >contents of register 14 was unchanged after a GETMAIN call. It clearly
> >did work once upon a time, but was a latent bomb. Stay glad you
> >discovered it before more damage was done. Again this shows the
> >danger of programming according to "what works (now)" instead of
> >programming according to documentation.
> I disagree also.  The error was not caused because GETMAIN changed
> unexpectedly; it was caused by the programmer who assumed that the STORAGE
> macro worked like GETMAIN.

Agreed, but I still consider a program depending upon an undocumented
feature a latent bomb.

Quote:
> BTW, why did the programmer change GETMAIN to STORAGE?  Why fix it if it
> ain't broke?

THAT is a very good question!!!

Quote:



regards Sven


Fri, 07 Jul 2000 03:00:00 GMT  
 Arghh! Difference between 'GETMAIN R,LV=(0)' and 'STORAGE OBTAIN,LENGTH=(0)'


(snipped)

Quote:
>In OS/VS2 R2 (MVS' first cut), SVC 10 (R-type GETMAIN/FREEMAIN) was
>changed and R0 no longer contained the length of the area as it did in MVT
>(and perhaps in SVS) after SVC 10 returned to the program.  A PTF quickly
>reversed the change because many user (and IBM) programs were expecting R0
>to retain its value, although this behaviour was NOT documented back then
>(I'm not sure it is even today).  I remember patching the PL/1 (F)
>compiler to work around this problem and allow it to run on MVS back in
>1975.  Bottom line: it's R0, it's not documented, it should be documented,
>and you can count on it.
(snipped)



Yes, I noticed R0 was preserved after GETMAIN years ago when I copied some
SHARE programs to the ol' Fuj (F4) only to have them abend.  Turned out the
Fujitsu "MVS-like" OS did NOT preserve R0.  :(
Still, at least it was "compatible"....      :/
Cheers,
Greg


Mon, 10 Jul 2000 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. LV 6.02 won't work unless I'm logged in as Administrator

2. LV 6.02 won't work unless I'm logged in as Administrator

3. the difference between f : '' and f@]

4. Struct :symbol vs 'string' difference

5. Difference between C++'s templates and Ada's generic units

6. A difference between '(asymb) and (list 'asymb)

7. Oops: difference in operation of string.join and ''.join

8. problems and differences between Digitalk's ST's

9. stream('file','c','seek ='x) problem

10. Wanted: Hints'n'Tips'n'Bits'n'Bobs

11. There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand

12. 2nd try: Differences between '' and ;0#;:'0'

 

 
Powered by phpBB® Forum Software