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
/~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 wrote
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’t believe the code is
And if there is a "there" there, Ed will find in a jaffe
Chris Hoelscher
Lead Sys DBA
IBM Global Technical Services on assignmemt to Humana Inc.
T 502.476.2538 or 502.407.7266
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Tom
Conley
Sent: Thursday, December 24,
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) product
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
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
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 push the
ssion 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 Introduction to the man
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
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
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.
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
>
And, perhaps, data
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/OS 2.3 you
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
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
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
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,
>
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:
Yes, it is.
However nowadays it seems to be harder than use RMODE31 and the need
seems to be in far future.
Again: I'm not talking about AMODE.
BTW: I wish I would forget about 24-bit modes.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 21.12.2020 o 17:07, Joe Monk pisze:
"Out of curiosity:
RMODE(64)When neither binder options RMODE=64 nor RMODEX are specified,
RMODE(64) ESD are treated as RMODE(ANY) for module loading and execution,
with the exception of data class C_WSA64, which can be loaded above the
2-gigabyte bar. In this case, the map in the binder listing and ESD records
"Out of curiosity: why did you choose RMODE(64)?"
Hey man - its the way of the future!
Joe
On Mon, Dec 21, 2020 at 9:38 AM R.S. wrote:
> W dniu 21.12.2020 o 16:19, Ed Jaffe pisze:
> > On 12/21/2020 6:27 AM, Paul Gilmartin wrote:
> >>
> >> On Sun, 20 Dec 2020 21:14:21 -0800, Ed Jaffe wrote:
>
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:
>>> On 12/21/2020 6:27
W dniu 21.12.2020 o 16:19, Ed Jaffe pisze:
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
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:
>
> On
On Sun, 20 Dec 2020 23:26:22 -0600, Mike Schwab wrote:
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ceev100/am64ap.htm
>xplink 64. Also available for 24/31 bit programs.
>
I see no mention of RMODE there. Am I looking in the wrong place?
On Sun, 20 Dec 2020
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ceev100/am64ap.htm
xplink 64. Also available for 24/31 bit programs.
On Sun, Dec 20, 2020 at 11:03 PM Joseph Reichman wrote:
>
> Hi
>
> Just wondering as there doesn’t seem too much documentation on this but I am
>
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 that is
33 matches
Mail list logo
