MXG's "asmguy" wrote
<begin snippet>
The SYSSTATE macro is an assembler directive - it sets
a flag that tells any macros that support AR mode
(Access Register, used for cross memory access) to use
their AR mode compatible expansion. Macros that don't
have an AR mode expansion used to ignore this because
they had nothing to do, and it's always the coder's
responsibility to make sure that when those non-AR
compatible macros are executed, that the system is not
in AR mode. This is similar to switching back and forth
from 24-bit to 31-bit mode: some macros can't tolerate
31-bit mode. Nothing has really changed though; it is
still the coders responsibility to make sure the system
is not in AR mode and macros that can't tolerate AR mode
still can't, except now IBM is requiring the coder to
explicitly set SYSSTATE to indicate to the assembler
that the system is not in AR mode.
Of course this is all very silly because the assembler
can't know ahead of time that the system is or isn't in
AR mode. So regardless of whether or not SYSSTATE is
coded this way the system still could be in AR mode,
</end snippet>
I am with Rob Scott in this matter. Much of this gentleman's comment
seems to me to either 1) "very silly", or 2) uninformed, or 3) both.
It is of course true that the HLASM cannot know that a routine it is
assembling will be executed, wholly or in part, in AR Mode (In
passing let me not that AR mode has many uses that that do not have to
do with CMS [overloaded acronym].) There is indeed much else that
the HLASM cannot know at assembly time about what the execution-time
environment in which some piece of code it is assembling will be.
It is, however, the business of the programmer who wrote the routine
being assembled to know these things, and to inform the assembler
about them.
On occasion, of course, that environment is not fully determined. I
have been working this morning on a routine I have designed to be
usable under both a TCB and an SRB; and this is necessarily reflected,
sometimes tediously, in my code and testing regime.
The notion that since the HLASM cannot know something without being
informed of it makes informing it moot or silly is itself silly or
worse.
John Gilmore - Ashland, MA 01721 - USA
On 12/16/11, Rob Scott <rsc...@rocketsoftware.com> wrote:
> Barry
>
> Maybe I am strange - but I welcome the new stricter approach to the SYSSTATE
> by IBM macros.
>
> Anything that can flag up a potential problem in my code due to my lack of
> care of the declared environment seems very useful to me.
>
> 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 Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
> Of Barry Merrill
> Sent: 16 December 2011 15:20
> To: IBM-MAIN@bama.ua.edu
> Subject: z/OS 1.13 ASCENV incompatible change in Assembler
>
> Change 29.280 -z/OS 1.13 ASM ERROR when assembling ASMTAPEE/MXGTMNT:
> ASMTAPEE "YOU SPECIFIED ASCENV=AR OR ANY ON THE SYSSTATE MACRO.
> Dec 15, 2011 THE OPEN MACRO SUPPORTS ONLY ASCENV=P."
> But there is NO NEED to ASM a new load module under 1.13;
> your currently executing MXGTMNT module works just fine!
>
> -This IBM note (migration guide) is the ONLY clue of the
> incompatible change, which impacts OPEN/CLOSE macros, but
> doesn't mention any by name:
> DFSMSdfp: Accommodate 64-bit & AR mode rules enforcement
> in DFSMS macros; required if you have code that invokes
> DFSMS macros (but not all!). Before z/OS V1R13, many
> DFSMS macros that did not support 64-bit or AR mode did
> not react to being invoked in 64-bit or AR mode, and
> generated code that might have been invalid in 64-bit or
> AR mode. Starting with z/OS V1R13, these macros are
> changed to issue an assembly-time message and suppress
> expansion if they are invoked in 64-bit or AR mode."
>
> -But as noted above, you didn't really need to ASM. Now,
> from MXG's "asmguy", his comments on this change:
>
> Nothing is going to happen to an existing site using
> MXGTMNT and in fact the modification I have to make for
> this does not result in any change to the executable
> code.
>
> The SYSSTATE macro is an assembler directive - it sets
> a flag that tells any macros that support AR mode
> (Access Register, used for cross memory access) to use
> their AR mode compatible expansion. Macros that don't
> have an AR mode expansion used to ignore this because
> they had nothing to do, and it's always the coder's
> responsibility to make sure that when those non-AR
> compatible macros are executed, that the system is not
> in AR mode. This is similar to switching back and forth
> from 24-bit to 31-bit mode: some macros can't tolerate
> 31-bit mode. Nothing has really changed though; it is
> still the coders responsibility to make sure the system
> is not in AR mode and macros that can't tolerate AR mode
> still can't, except now IBM is requiring the coder to
> explicitly set SYSSTATE to indicate to the assembler
> that the system is not in AR mode.
> Of course this is all very silly because the assembler
> can't know ahead of time that the system is or isn't in
> AR mode. So regardless of whether or not SYSSTATE is
> coded this way the system still could be in AR mode,
> OPEN/CLOSE will still expand the same way, and if the
> system really is in AR mode OPEN/CLOSE will abend when
> executed.
> So the bottom line is that nothing has changed except
> our need to do something for no reason at all.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
--
John Gilmore, Ashland, MA 01721 - USA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
