Re: Any Recovery for RMODE64

2024-01-26 Thread Jon Perryman
On Fri, 26 Jan 2024 08:30:54 -0500, Joseph Reichman wrote: >For Estae says amode 24 or 31 ESTAEX supports SYSSTATE AMODE=64 >Regardless if I established a recovery in 31 but storage and then branched to >64 bit storage >Under the same RB > >I assume the recovery routine would cover me It

Re: Any Recovery for RMODE64

2024-01-26 Thread Joseph Reichman
Searched the archives and saw an article from Peter Relson dated 12/2020 I just did search on the authorized services vol 4 ( set-wto) for rmode Got a hit on the storage and wait macros “including 64” For Estae says amode 24 or 31 For SETFRR includes amode 64 Regardless if I established a r

Re: Any Recovery for RMODE64

2024-01-26 Thread Binyamin Dissen
On Thu, 25 Jan 2024 18:38:10 -0500 Joseph Reichman wrote: :>Just wondering is there any recovery for a program running RMODE 64 don't :>see that with ESTAE or SETFRR CVTBSM0F :>As more and more services run above the bar :>More so SDWAEC1 and SDWAEC2 are only 8 bytes SDWARC4 -- Binyamin Dis

Re: Any Recovery for RMODE64

2024-01-25 Thread Rob Scott
ussion List on behalf of Joseph Reichman Sent: Thursday, January 25, 2024 11:38:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Any Recovery for RMODE64 EXTERNAL EMAIL Just wondering is there any recovery for a program running RMODE 64 don't see that with ESTAE or SETFRR As more and mo

Any Recovery for RMODE64

2024-01-25 Thread Joseph Reichman
Just wondering is there any recovery for a program running RMODE 64 don't see that with ESTAE or SETFRR As more and more services run above the bar More so SDWAEC1 and SDWAEC2 are only 8 bytes thanks -- For IBM-MAIN subscribe

Re: RMODE64

2021-03-10 Thread Ed Jaffe
On 12/22/2020 6:09 AM, Joseph Reichman wrote: Peter Thanks I’m not writing RMODE64 code don’t see a reason to I don’t know why Ed co. does cann’t believe the code is that large Thanks for the heads up about LE I believe the real reason for RMODE64 is Java I learned today at the SHARE 2021

Re: RMODE64

2020-12-24 Thread Seymour J Metz
on.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Conley [pinnc...@rochester.rr.com] Sent: Thursday, December 24, 2020 6:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RMODE64 On 12/24/2020 12:01 PM, Ed Jaffe w

Re: RMODE64

2020-12-24 Thread Tom Brennan
LOL I was going to say, "Because it's there" On 12/24/2020 3:38 PM, Tom Conley wrote: On 12/24/2020 12:01 PM, Ed Jaffe wrote: On 12/22/2020 6:09 AM, Joseph Reichman wrote: Thanks I’m not writing RMODE64 code don’t see a reason to  > > I don’t know why Ed co. does cann’

Re: RMODE64

2020-12-24 Thread Chris Hoelscher
ecember 24, 2020 6:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] RMODE64 [External Email: Use caution with links and attachments] On 12/24/2020 12:01 PM, Ed Jaffe wrote: > On 12/22/2020 6:09 AM, Joseph Reichman wrote: >> Thanks I’m not writing RMODE64 code don’t see a reason

Re: RMODE64

2020-12-24 Thread Paul Gilmartin
On Thu, 24 Dec 2020 09:01:40 -0800, Ed Jaffe wrote: > >We are writing an RMODE(64) product because we love z/OS and wish to >help push the boundaries of its technological limitations wherever we can. > IBM hates people like that. At a SHARE meeting (where I believe I met you), John E. (FSVO "E")

Re: RMODE64

2020-12-24 Thread Tom Conley
On 12/24/2020 12:01 PM, Ed Jaffe wrote: On 12/22/2020 6:09 AM, Joseph Reichman wrote: Thanks I’m not writing RMODE64 code don’t see a reason to  > > I don’t know why Ed co. does cann’t believe the code is that large > Thanks for the heads up about LE We are writing an RMODE(64

Re: RMODE64

2020-12-24 Thread Joseph Reichman
The new platform is mainframe Java Nobody cares about dinos > On Dec 24, 2020, at 12:36 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > On Thu, 24 Dec 2020 08:44:09 -0800, Charles Mills wrote: > >> I would never presume to tell IBM what to do, but if I were r

Re: RMODE64

2020-12-24 Thread Charles Mills
nal Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, December 24, 2020 9:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RMODE64 A few points: o As z/OS grows in complexity, the needed documentation and its cost gr

Re: RMODE64

2020-12-24 Thread Paul Gilmartin
On Thu, 24 Dec 2020 08:44:09 -0800, Charles Mills wrote: >I would never presume to tell IBM what to do, but if I were responsible for >the "MVS Services" documentation I would start with a preamble much like >@Gil describes in which I said "unless otherwise specified, callers must be >..." and cov

Re: RMODE64

2020-12-24 Thread Ed Jaffe
On 12/22/2020 6:09 AM, Joseph Reichman wrote: Thanks I’m not writing RMODE64 code don’t see a reason to > > I don’t know why Ed co. does cann’t believe the code is that large > Thanks for the heads up about LE We are writing an RMODE(64) product because we love z/OS and wish to help

Re: RMODE64

2020-12-24 Thread Charles Mills
rame Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, December 24, 2020 7:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RMODE64 Perhaps you don't understand what I mean by "blanket statement": a single affirmative sentence in the Introduc

Re: RMODE64

2020-12-24 Thread Peter Relson
Perhaps you don't understand what I mean by "blanket statement": a single affirmative sentence in the Introduction to the manual, "Any service described herein may be invoked from a location below 2 GiB." Do you think there is anyone in the IBM world who needs that sentence? It might be thought

Re: RMODE64

2020-12-23 Thread Joseph Reichman
Gil IBM caters to the big picture like Java Those few of us who program in assembler use internals including vendors are not worth their time Peter happens to go the extra yard affording us info that’s not documented at times Maybe there could be a share session on this If there would be o

Re: RMODE64

2020-12-23 Thread Paul Gilmartin
On Wed, 23 Dec 2020 08:43:31 -0500, Peter Relson wrote: >>> VERY FEW system services officially support invocation in RMODE 64. If >>> they don't say that they do, then do not assume that they do. >> >>Is there a blanket statement to this effect in the relevant manual(s)? > >No, nor likely will

Re: RMODE64

2020-12-23 Thread Peter Relson
>> VERY FEW system services officially support invocation in RMODE 64. If >> they don't say that they do, then do not assume that they do. > >Is there a blanket statement to this effect in the relevant manual(s)? No, nor likely will there be. The books document what z/OS supports your doing. The

Re: RMODE64

2020-12-22 Thread Paul Gilmartin
On Tue, 22 Dec 2020 09:09:06 -0500, Joseph Reichman wrote: > >Thanks I’m not writing RMODE64 code don’t see a reason to > >I don’t know why Ed co. does cann’t believe the code is that large >Thanks for the heads up about LE > >I believe the real reason for RMODE64 is Java

Re: RMODE64

2020-12-22 Thread Joseph Reichman
Peter Thanks I’m not writing RMODE64 code don’t see a reason to I don’t know why Ed co. does cann’t believe the code is that large Thanks for the heads up about LE I believe the real reason for RMODE64 is Java > On Dec 22, 2020, at 8:57 AM, Peter Relson wrote: > > Since z/O

Re: RMODE64

2020-12-22 Thread Peter Relson
Since z/OS 2.3 you have been able to identify modules as wanting to be RMODE 64, via what Ed Jaffe mentioned (including RMODEX=64TRUE). Just about the only thing that is guaranteed for an RMODE 64 module is that your module will survive being undispatched and redispatched (such as on a time slic

Re: RMODE64

2020-12-21 Thread Ed Jaffe
On 12/21/2020 8:48 AM, Paul Gilmartin wrote: On Mon, 21 Dec 2020 10:14:21 -0600, Joe Monk wrote: RMODE(64)When neither binder options RMODE=64 nor RMODEX are specified, RMODE(64) ESD are treated as RMODE(ANY) RMODE(ANY) is antiquated and misleading. I prefer to see RMODE(31). FWIW, we spec

Re: RMODE64

2020-12-21 Thread Paul Gilmartin
On Mon, 21 Dec 2020 10:50:42 -0600, Joe Monk wrote: >Well that quote is from the z/os 2.3 binder. > Thanks. I pretty clearly cited 2.4, where it remains unchanged. > >On Mon, Dec 21, 2020 at 10:48 AM Paul Gilmartin wrote: >> >> In: z/OS Version 2 Release 4 >> MVS Program Management: User's G

Re: RMODE64

2020-12-21 Thread Joe Monk
Well that quote is from the z/os 2.3 binder. Joe On Mon, Dec 21, 2020 at 10:48 AM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 21 Dec 2020 10:14:21 -0600, Joe Monk wrote: > > >RMODE(64)When neither binder options RMODE=64 nor RMODEX are specified, > >RMODE(64

Re: RMODE64

2020-12-21 Thread Paul Gilmartin
On Mon, 21 Dec 2020 10:14:21 -0600, Joe Monk wrote: >RMODE(64)When neither binder options RMODE=64 nor RMODEX are specified, >RMODE(64) ESD are treated as RMODE(ANY) RMODE(ANY) is antiquated and misleading. I prefer to see RMODE(31). In: z/OS Version 2 Release 4 MVS Program Management: User'

Re: RMODE64

2020-12-21 Thread R.S.
MODE(64). For those, even the inout/output parameters must be below the bar. (my humble question) Out of curiosity: why did you choose RMODE(64)? I understand AMODE(64) - more memory for data, but RMODE64 seems to me good solutions for really large programs or maybe multi-program address spac

Re: RMODE64

2020-12-21 Thread Joe Monk
if RMODE64 was available on 2.3 > > I looked up the CDE and it had an extension ihacdx so did xtentlist to > take into account 64 bit address > > > On Dec 21, 2020, at 10:38 AM, R.S. > wrote: > > > > W dniu 21.12.2020 o 16:19, Ed Jaffe pisze: > >>

Re: RMODE64

2020-12-21 Thread Joe Monk
g primarily to services. Our approach has been to invoke > > those that don't support RMODE(64) from GLUE code running below the > > bar. Many services still don't support AMODE(64). For those, even the > > inout/output parameters must be below the bar. > > (my humb

Re: RMODE64

2020-12-21 Thread Joseph Reichman
I personally wanted to know I’m not sure if RMODE64 was available on 2.3 I looked up the CDE and it had an extension ihacdx so did xtentlist to take into account 64 bit address > On Dec 21, 2020, at 10:38 AM, R.S. wrote: > > W dniu 21.12.2020 o 16:19, Ed Jaffe pisze: >>>

Re: RMODE64

2020-12-21 Thread R.S.
you choose RMODE(64)? I understand AMODE(64) - more memory for data, but RMODE64 seems to me good solutions for really large programs or maybe multi-program address space like CICS. -- Radoslaw Skorupka Lodz, Poland ==

Re: RMODE64

2020-12-21 Thread Joseph Reichman
But my points of the post is that documentation is lacking So Ed you figured out which services didn’t work trial and error meaning you would get an abend look it up in systems codes Also in addition am I correct that the only debugger available for RMODE64 is XDC Test won’t work and debug

Re: RMODE64

2020-12-21 Thread Ed Jaffe
On 12/21/2020 6:27 AM, Paul Gilmartin wrote: On Sun, 20 Dec 2020 21:14:21 -0800, Ed Jaffe wrote: There are many, Many, MANY restrictions! Are these listed anywhere? For code or for data? Services calls? Citation needed. I was referring primarily to services. Our approach has been to

Re: RMODE64

2020-12-21 Thread Mike Schwab
Before you can ask for RMODE64, your program must be AMODE64. Then linkage editor option RMODE(64) asks for the program to be located above the 2GB line, but may or may not be honored. On Mon, Dec 21, 2020 at 8:27 AM Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

Re: RMODE64

2020-12-21 Thread Paul Gilmartin
020 21:14:21 -0800, Ed Jaffe wrote: >On 12/20/2020 9:01 PM, Joseph Reichman wrote: >> Just wondering as there doesn’t seem too much documentation on this but I am >> wondering if there are any restrictions running RMODE64 >> >>The assembler services guide has a AMODE

Re: RMODE64

2020-12-20 Thread Mike Schwab
his but I am > wondering if there are any restrictions running RMODE64 > > > The assembler services guide has a AMODE in the environment but nothing about > the RMODE > > Thanks > -- > For IBM-MAIN subscribe

Re: RMODE64

2020-12-20 Thread Ed Jaffe
On 12/20/2020 9:01 PM, Joseph Reichman wrote: Just wondering as there doesn’t seem too much documentation on this but I am wondering if there are any restrictions running RMODE64 There are many, Many, MANY restrictions! Having said that, we're working on a not-yet-released product th

RMODE64

2020-12-20 Thread Joseph Reichman
Hi Just wondering as there doesn’t seem too much documentation on this but I am wondering if there are any restrictions running RMODE64 The assembler services guide has a AMODE in the environment but nothing about the RMODE Thanks