Yeah, I should have just left that last sentence out. My typical isn't necessarily anyone else's, and besides, I don't like to suppress warnings myself.
sas On Mon, Jan 26, 2015 at 12:28 PM, Robert Ngan <[email protected]> wrote: > The warning is not useful for MVHHI since there's no actual sign extension. > For MVGHI and MVHI, it is useful for flagging (unexpected) sign extension, > specifically when the immediate value is an expression. > > I remember using the -65536 trick, but for some reason I stopped using it > and then forgot about it (must be getting old!). > > Robert Ngan > CSC financial Services Group > > IBM Mainframe Assembler List <[email protected]> wrote on > 2015/01/26 10:37:40: > > > From: Steve Smith <[email protected]> > > To: [email protected] > > Date: 2015/01/26 10:44 > > Subject: Re: 8 character mnemonics > > Sent by: IBM Mainframe Assembler List <[email protected]> > > > > For this case you can append "-65536" (or x'10000') to get the value > > without a warning. > > > > 00000080 E544 D120 3039 00000120 210 MVHHI > > FIELD1,12345 > > 00000086 E544 D120 9C40 00000120 211 MVHHI > > FIELD1,40000 > > ** ASMA320W Immediate field operand may have incorrect sign or > > magnitude > > ** ASMA435I Record 71 in TSSAS.WORK.ASM(TEST3) on volume: > > TSO003 > > 0000008C E544 D120 9C40 00000120 212 MVHHI > > FIELD1,40000-65536 > > 214 > > @AUTO > > 00000120 00000000 00000128 215+@@TEST3D DSECT > > 00000120 216 FIELD1 DS H > > > > Another alternative is to just specify SUPRWARN(320), or > > TYPECHECK(NOMAGNITUDE) once, since it's typically not that useful anyway. > > > > On Fri, Jan 23, 2015 at 7:07 PM, Robert Ngan <[email protected]> wrote: > > > > > 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 > > > > > > > > > > > -- > > sas > -- sas
