I've actually used both the new instruction and the macro of the same name,
e.g. for MVHHI
MACRO ,
&Label MVHHI &S,&I
PUSH ACONTROL,PRINT,NOPRINT
PRINT NOGEN,NOPRINT Suppress printing of following ACONTROL
ACONTROL NOTYPECHECK Suppress annoying ASMA320W messages
POP PRINT,NOPRINT Print following instruction
&Label MVHHI &S,&I
POP ACONTROL,NOPRINT
MEND
for values less than 32K, I just use the actual instruction:
MVHHI field,12345
but for (unsigned) values 32K or larger, I use the macro to avoid that (in
this particular situation) annoying warning:
MVHHI:MAC field,40000
Robert Ngan
CSC Financial Services Group
IBM Mainframe Assembler List <[email protected]> wrote on
2015/01/22 07:42:47:
> From: John McKown <[email protected]>
> To: [email protected]
> Date: 2015/01/22 07:46
> Subject: Re: 8 character mnemonics
> Sent by: IBM Mainframe Assembler List <[email protected]>
>
> On Thu, Jan 22, 2015 at 4:28 AM, Sharuff Morsa3
<[email protected]>
> wrote:
>
> > >Ain't progress wonderful?
> >
> > Anyone know how to stop it ? (progress that is)
> >
> > I would not rule out > 8 character mnemonics nor > 8 character HLASM
> > assembler directives (not that I'm currently planning any).
> >
> > Because of the very large number of mnemonics and extended mnemonics
which
> > have been added, there are some ISPF SuperC commands to assist users in
> > searching their source, copybook and macro libraries to see if they may
be
> > affected (http://www.ibm.com/support/docview.wss?uid=swg21694301).
> >
> > The new instructions have highlighted a problem for which we have to
> > strike a balance. Several of the new instructions have the same
mnemonics
> > but differing instruction formats. Who can successfully execute
ESA/390
> > vector instructions ? But some users will have these mnemonics are
coded
> > in their applications (anyone want to own up having some?).
> >
> > Should we always (100%) maintain the ability for users programs to
> > assemble programs cleanly even though they would not execute
successfully?
> > How much can a product change (or evolve) without users having to make
> > some or consider those changes ?
> >
> > IBM z Systems have a very long history of minimising the affect of
changes
> > on users - but products and their usage change over time. How
customers
> > use our products changes over time. Is that progress ?
> >
> > Sharuff
> >
> > Sharuff Morsa IBM Hursley Labs
> >
> >
> One thing that I can think of which _might_ be of some help would be to
> have either another program, or a PARM= value for HLASM for a source
> validation. That is, it would act like HLASM, but would flag all opcodes
> which are HLASM machine opcodes and which _also_ exist as members in the
> SYSLIB concatenation. I don't know if HLASM does this already, but it
would
> be nice if all machine instructions supported by HLASM, but _excluded_ by
> using the OPTABLE/MACHINE compile parameter, were only searched for as
> macros. Lastly, it might be nice to have a program which can
> "pseudo-compile" a source program and not only flag machine instruction
> opcodes which exist as members in the SYSLIB concatenation, but would
also
> create an IEBUPDTE control deck which puts a ":MAC" on the end of the
> opcode. The user could then edit this and use it to more easily update
> their source.
>
> Just some ideas.
>
>
> --
>
> While a transcendent vocabulary is laudable, one must be eternally
careful
> so that the calculated objective of communication does not become
ensconced
> in obscurity. In other words, eschew obfuscation.
>
> 111,111,111 x 111,111,111 = 12,345,678,987,654,321
>
> Maranatha! <><
> John McKown
