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
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
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
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
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
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
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
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’
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
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")
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
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
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
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
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
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
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
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
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
>> 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
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
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
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
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
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
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
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'
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
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:
> >>
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
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:
>>>
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
==
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
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
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:
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
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
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
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
39 matches
Mail list logo
