Re: ASSEMBLER-LIST Digest - 29 Mar 2016 to 30 Mar 2016 (#2016-39)

2016-04-01 Thread John Walker
Why use the STG instead of ST? Is this ostensibly for 640bit or are we just assuming everyone wants 64bits now? On Wed, 3/30/16, ASSEMBLER-LIST automatic digest system wrote: Subject: ASSEMBLER-LIST Digest - 29 Mar 2016

Re: Csect - Dsect Question

2016-04-01 Thread Bob Rutledge
Ol' friend, your test is incomplete. That LMG doesn't go far enough. Bob On 4/1/2016 3:36 PM, Ed Jaffe wrote: On 3/31/2016 2:03 PM, Tom Marchant wrote: ITYM R0. Indeed! And the manual doesn't specify that the address returned is a clean 64-bit address except if it is AMODE 64. So I'd

Re: Csect - Dsect Question

2016-04-01 Thread Tom Marchant
On Fri, 1 Apr 2016 12:36:01 -0700, Ed Jaffe wrote: >Empirical testing shows R0 is returned with a clean 64-bit address, even >for an old 24-bit program: I believe it, but do we want to rely on undocumented behavior? Perhaps an RCF is in order? -- Tom Marchant

Re: Csect - Dsect Question

2016-04-01 Thread Tom Marchant
On Fri, 1 Apr 2016 15:08:59 -0400, Tom Marchant wrote: >TMLL R0,X'0001' RMODE(64) >JORMODE64 Oops. I mean TMLL R0,X'0001' AMODE(64) JOAMODE64 Yes, leave bits 0-32 as is -- Tom Marchant

Re: Csect - Dsect Question

2016-04-01 Thread Ed Jaffe
On 3/31/2016 2:03 PM, Tom Marchant wrote: ITYM R0. Indeed! And the manual doesn't specify that the address returned is a clean 64-bit address except if it is AMODE 64. So I'd suggest replacing the NILH with LLGTR R0,R0 Empirical testing shows R0 is returned with a clean 64-bit

Re: Csect - Dsect Question

2016-04-01 Thread Tom Marchant
On Fri, 1 Apr 2016 12:55:44 -0500, Chuck Arney wrote: >If you intend to use RMODE64 in the future with that code you will want to >NOT use that LLGTR. Right. To cover that case you might want something like this: LOAD EP=MSGTABLE Load external message table TMLL

Re: Csect - Dsect Question

2016-04-01 Thread Martin
Mark, >> z/TPF has supported RMODE64 code for over 10 years. Oups- I love writing code transformed to being run on the metal by HLASM (I do know Pops by heart), but yet my CV lacks doing anything in TPF. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at

Re: Csect - Dsect Question

2016-04-01 Thread Chuck Arney
It works fine on z/OS 1.13 and above. We have lots of code running from there. However, only a directed LOAD can be done into RMODE64 or you have to do the program management yourself which is what we do. I wrote a blog post on running RMODE64 code a while back. Chuck Arney Arney Computer

Re: Csect - Dsect Question

2016-04-01 Thread Mark Boonie
z/TPF has supported RMODE64 code for over 10 years. But we're a little different than most other OSes. :-) - mb IBM Mainframe Assembler List wrote on 04/01/2016 02:17:06 PM: > is RMODE64 supported yet on any op-sys (and don't forget > Scott; he wants it for

Re: Csect - Dsect Question

2016-04-01 Thread Martin
Chuck, holy sh.. is RMODE64 supported yet on any op-sys (and don't forget Scott; he wants it for COBOL)? -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de

Re: Csect - Dsect Question

2016-04-01 Thread Chuck Arney
<<

Re: Csect - Dsect Question

2016-04-01 Thread Martin
Ed, >> ...and then finally pasted it ... cann't you see the power of a "mass"-compile any bug left we have yet to find? -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de

Re: Csect - Dsect Question

2016-04-01 Thread Gord Tomlin
If we're insisting on correctness (I wasn't, since Ed just blasted code from his head into an email), LOAD has no EPNAME argument. Coded as below, EPNAME should be EPLOC. On 2016-04-01 03:14, mar...@pi-sysprog.de wrote: The complete "corrected" version of the loading is this .. LOAD