Re: RMODE64
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 Virtual Summit from Tom Ross at IBM (aka Captain COBOL) that larger customers are clamoring for RMODE(64) COBOL support. Why? They must manage multiple CICS AORs to hold the literally *thousands* of RMODE(31) COBOL programs they have. If they could go with RMODE(64), they could consolidate them down to a single AOR image, which is the easiest to manage. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
It's a shame that IBM doesn't push the boundaries during Alpha testing. I have a dream of a testing laboratory with a large pool of users who know nothing about the product. That would be especially valuable for testing the documentation. -- Shmuel (Seymour J.) Metz http://mason.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 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 because we love z/OS and wish to > help push the boundaries of its technological limitations wherever we can. Shocker, Ed Jaffe pushes the boundaries of z/OS. Film at 11. For those of you who haven't been paying attention, and judging by your IBM-Main posts, you haven't, Ed Jaffe's goal in life is to push the boundaries of z/OS, as he's done continuously for the approximately 25 years I've known him. He's one of the main reasons that z/OS is as good as it is. If he's working on RMODE(64), rest assured, there's a there there, and Ed will find it. All the best to you and yours this holiday season! Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 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 boundaries of its technological limitations wherever we can. Shocker, Ed Jaffe pushes the boundaries of z/OS. Film at 11. For those of you who haven't been paying attention, and judging by your IBM-Main posts, you haven't, Ed Jaffe's goal in life is to push the boundaries of z/OS, as he's done continuously for the approximately 25 years I've known him. He's one of the main reasons that z/OS is as good as it is. If he's working on RMODE(64), rest assured, there's a there there, and Ed will find it. All the best to you and yours this holiday season! Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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, 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 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 boundaries of its technological limitations wherever we can. Shocker, Ed Jaffe pushes the boundaries of z/OS. Film at 11. For those of you who haven't been paying attention, and judging by your IBM-Main posts, you haven't, Ed Jaffe's goal in life is to push the boundaries of z/OS, as he's done continuously for the approximately 25 years I've known him. He's one of the main reasons that z/OS is as good as it is. If he's working on RMODE(64), rest assured, there's a there there, and Ed will find it. All the best to you and yours this holiday season! Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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") practically boasted that unlike Linkage Editor for which data specifications were open, Binder's were closed, saving IBM much anguish. The issue: programmers, especially ISVs coded to the Doc; did things that no IBM product did, and IBM never tested; and opened SRs when they didn't work as documented. I imagine many APARs were closed PRS. IBM can say, "We never said that would work." But if you stayed within the boundaries of what IBM says would work, you wouldn't get much done. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 because we love z/OS and wish to help push the boundaries of its technological limitations wherever we can. Shocker, Ed Jaffe pushes the boundaries of z/OS. Film at 11. For those of you who haven't been paying attention, and judging by your IBM-Main posts, you haven't, Ed Jaffe's goal in life is to push the boundaries of z/OS, as he's done continuously for the approximately 25 years I've known him. He's one of the main reasons that z/OS is as good as it is. If he's working on RMODE(64), rest assured, there's a there there, and Ed will find it. All the best to you and yours this holiday season! Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 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 covered ASC, SRB/TCB, AMODE, RMODE, problem/supervisor, etc. >> >> It need not be negative "callers cannot be above the bar" or "not SRB" but >> rather positive "callers must invoke the services from below the bar, in TCB >> mode, etc." If IBM were theoretically to add some new MVS "mode" in the >> future -- a third alternative to TCB/SRB or a new AMODE or whatever -- it >> would not be necessary to change the write-up for every service, only to add >> one sentence to this preamble (and change the write-ups for services that >> actually supported the new mode). >> >>> Do you think there is anyone in the IBM world who needs that sentence? >> >> Yes, new entrants to the IBM world. We do want new entrants, don't we? >> Without them, the platform dies as we retire. The platform dies as CIO's >> perceive that it is not possible to hire staff to support the platform. >> > Well said. I attempted to avoid any aura of negativity by saying "may" > where you properly said "unless ... must", and I left Peter to assume the > readers would infer the contrapositive. > > A few points: > o As z/OS grows in complexity, the needed documentation and its cost > grows proportionally, perhaps quadratically. > o It becomes increasingly unlikely that a typical user has the needed > background information. > o The cost of providing adequate documentation should be factored > into the business case for new features, not used as an excuse for > not providing it. > > >> -Original Message- >> From: Peter Relson >> Sent: Thursday, December 24, 2020 7:02 AM >> >> 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 that things prevalent by MVS/XA (the late 70's) are >> "known" and need not be stated. >> >> Regardless, such a statement is not what I read your previous post to >> suggest. >> >> 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)? >> >> >> To me, that asks about a negative statement. Such a statement might have >> been "No service may be invoked from a location >= 2G unless it explicitly >> is documented that it allows that". As I mentioned previously, we do not >> typically have such negative statements. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
> The cost of providing adequate documentation should be factored into the business case for new features, not used as an excuse for not providing it. AMEN! Well said. Correct documentation is not an optional luxury, it is fundamental part of the new feature. Charles -Original 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 grows proportionally, perhaps quadratically. o It becomes increasingly unlikely that a typical user has the needed background information. o The cost of providing adequate documentation should be factored into the business case for new features, not used as an excuse for not providing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 covered ASC, SRB/TCB, AMODE, RMODE, problem/supervisor, etc. > >It need not be negative "callers cannot be above the bar" or "not SRB" but >rather positive "callers must invoke the services from below the bar, in TCB >mode, etc." If IBM were theoretically to add some new MVS "mode" in the >future -- a third alternative to TCB/SRB or a new AMODE or whatever -- it >would not be necessary to change the write-up for every service, only to add >one sentence to this preamble (and change the write-ups for services that >actually supported the new mode). > >> Do you think there is anyone in the IBM world who needs that sentence? > >Yes, new entrants to the IBM world. We do want new entrants, don't we? >Without them, the platform dies as we retire. The platform dies as CIO's >perceive that it is not possible to hire staff to support the platform. > Well said. I attempted to avoid any aura of negativity by saying "may" where you properly said "unless ... must", and I left Peter to assume the readers would infer the contrapositive. A few points: o As z/OS grows in complexity, the needed documentation and its cost grows proportionally, perhaps quadratically. o It becomes increasingly unlikely that a typical user has the needed background information. o The cost of providing adequate documentation should be factored into the business case for new features, not used as an excuse for not providing it. >-Original Message- >From: Peter Relson >Sent: Thursday, December 24, 2020 7:02 AM > >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 that things prevalent by MVS/XA (the late 70's) are >"known" and need not be stated. > >Regardless, such a statement is not what I read your previous post to >suggest. > > >>> 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)? > > >To me, that asks about a negative statement. Such a statement might have >been "No service may be invoked from a location >= 2G unless it explicitly >is documented that it allows that". As I mentioned previously, we do not >typically have such negative statements. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 boundaries of its technological limitations wherever we can. We had a design meeting about this and no one in attendance was able to come up with a significant disadvantage to RMODE(64) once we proved such modules would automatically be loaded RMODE(31) under z/OS 2.2. (At that time, we thought 2.2 might be our minimum supported release at GA, but that has since been bumped up to 2.3.) RMODE(64) code is essentially indistinguishable from AMODE(64) code that happens to run RMODE(31). This new product uses many advanced z/OS facilities. RMODE(64) is just one of them. I believe the real reason for RMODE64 is Java Db2 was a major influencer in the decision to allow execution above the bar... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 covered ASC, SRB/TCB, AMODE, RMODE, problem/supervisor, etc. It need not be negative "callers cannot be above the bar" or "not SRB" but rather positive "callers must invoke the services from below the bar, in TCB mode, etc." If IBM were theoretically to add some new MVS "mode" in the future -- a third alternative to TCB/SRB or a new AMODE or whatever -- it would not be necessary to change the write-up for every service, only to add one sentence to this preamble (and change the write-ups for services that actually supported the new mode). > Do you think there is anyone in the IBM world who needs that sentence? Yes, new entrants to the IBM world. We do want new entrants, don't we? Without them, the platform dies as we retire. The platform dies as CIO's perceive that it is not possible to hire staff to support the platform. Charles -Original Message- From: IBM Mainframe 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 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 that things prevalent by MVS/XA (the late 70's) are "known" and need not be stated. Regardless, such a statement is not what I read your previous post to suggest. >> 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)? To me, that asks about a negative statement. Such a statement might have been "No service may be invoked from a location >= 2G unless it explicitly is documented that it allows that". As I mentioned previously, we do not typically have such negative statements. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 that things prevalent by MVS/XA (the late 70's) are "known" and need not be stated. Regardless, such a statement is not what I read your previous post to suggest. >> 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)? To me, that asks about a negative statement. Such a statement might have been "No service may be invoked from a location >= 2G unless it explicitly is documented that it allows that". As I mentioned previously, we do not typically have such negative statements. I would be OK with adding an RMODE section (which could describe to the "Using the Services" section of each of the MVS [Authorized] Assembler Services References if you request that that be done by a note to MHVRCFS. But those books cover only a small portion of the z/OS programming interfaces. Many other macros and services have far less environmental information. That's not a good thing. But I have no leverage to get it improved. They rely far more heavily than the MVS books do on "if we don't tell you it's OK, then assume you can't". For example, they don't bother saying "it is OK to be in primary ASC mode". Because that's all there was at the time these books were written. It "goes without saying" so they don't say. So maybe what you really want to suggest is that there be a place that applies to all of z/OS where such "global" information for interfaces could be put. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 one I would go > On Dec 23, 2020, at 9:46 AM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > 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 there be. The books document what z/OS supports your >> doing. They do not tend to document what is not supported. This should not >> be new news to anyone. >> > But they don't "document what z/OS supports". How many services make > an affirmative statement of support such as, "this service may be invoked > from a location below 2GiB"? > > 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." > Adding that doesn't seem to be such "a significant cost". Otherwise > you're arrogantly presuming every programmer has your profound > understanding of z/OS internals and needn't ask questions such as > the one that started this thread. > >> This applies to almost everything relating to an interface, including (but >> not limited to) AMODE 64, data above the bar, ASC mode, ARs, high halves >> of GRs. >> >> You could certainly argue that all services should be perfectly clear on >> all of these things. They should be. And if it cost nothing to make that >> happen, they would be. But doing so would incur a significant cost that >> has not been felt to be justified. Maybe if all the IBM-Main folks put >> together a "go fund me" page they could fund such an effort > course> > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 there be. The books document what z/OS supports your >doing. They do not tend to document what is not supported. This should not >be new news to anyone. > But they don't "document what z/OS supports". How many services make an affirmative statement of support such as, "this service may be invoked from a location below 2GiB"? 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." Adding that doesn't seem to be such "a significant cost". Otherwise you're arrogantly presuming every programmer has your profound understanding of z/OS internals and needn't ask questions such as the one that started this thread. >This applies to almost everything relating to an interface, including (but >not limited to) AMODE 64, data above the bar, ASC mode, ARs, high halves >of GRs. > >You could certainly argue that all services should be perfectly clear on >all of these things. They should be. And if it cost nothing to make that >happen, they would be. But doing so would incur a significant cost that >has not been felt to be justified. Maybe if all the IBM-Main folks put >together a "go fund me" page they could fund such an effort course> -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
>> 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. They do not tend to document what is not supported. This should not be new news to anyone. This applies to almost everything relating to an interface, including (but not limited to) AMODE 64, data above the bar, ASC mode, ARs, high halves of GRs. You could certainly argue that all services should be perfectly clear on all of these things. They should be. And if it cost nothing to make that happen, they would be. But doing so would incur a significant cost that has not been felt to be justified. Maybe if all the IBM-Main folks put together a "go fund me" page they could fund such an effort Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 CSECTs. >> On Dec 22, 2020, at 8:57 AM, 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)? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 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 slice). > > 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. In practice > services that are SVC-entered or PC-entered might well work enough for > your purposes (and I intentionally used the word "enough" because there > might be things that you do not notice that are not fully supported, > particularly with respect to diagnostic data). Things that are > branch-entered might "get there" but might well not "get back". Be careful > about referencing parameters that are within your module for a service > that does not document that it accepts parameter data above 2G. Any > service that has a "SAM31" (or SAM24) as part of its expansion will of > course not work in RMODE 64. Many things cannot be RMODE 64. including > IRBs, SRBs, recovery routines, retry points. All of these relate to there > being only a 4-byte area to capture the initial address. Obviously after > getting control you can branch elsewhere. For recovery routine retry, one > way to accomplish retrying to an area in an RMODE 64 module is to set up > 64-bit retry register 15 with the pointer-defined address of where you > "really want to go" and retry to CVTBSM0F. You might also need SETRP > RETRY15=YES so that your retry register 15 is honored. > > If your RMODE 64 module calls no services (and of course is AMODE 64) it > will work if correctly written. > > There has been no proven need for RMODE 64 for modules (despite the > abominable code bloat of some application approaches). Applications have > been moving their data above 2G for many years. > > The eventual intent is for LE to support your RMODE 64 modules via the LE > services that you can call. The LE services will pay attention to whether > the underlying system service supports RMODE 64 or not. I've lost track of > whether this is available or not, and, if not available, when it might be. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 slice). 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. In practice services that are SVC-entered or PC-entered might well work enough for your purposes (and I intentionally used the word "enough" because there might be things that you do not notice that are not fully supported, particularly with respect to diagnostic data). Things that are branch-entered might "get there" but might well not "get back". Be careful about referencing parameters that are within your module for a service that does not document that it accepts parameter data above 2G. Any service that has a "SAM31" (or SAM24) as part of its expansion will of course not work in RMODE 64. Many things cannot be RMODE 64. including IRBs, SRBs, recovery routines, retry points. All of these relate to there being only a 4-byte area to capture the initial address. Obviously after getting control you can branch elsewhere. For recovery routine retry, one way to accomplish retrying to an area in an RMODE 64 module is to set up 64-bit retry register 15 with the pointer-defined address of where you "really want to go" and retry to CVTBSM0F. You might also need SETRP RETRY15=YES so that your retry register 15 is honored. If your RMODE 64 module calls no services (and of course is AMODE 64) it will work if correctly written. There has been no proven need for RMODE 64 for modules (despite the abominable code bloat of some application approaches). Applications have been moving their data above 2G for many years. The eventual intent is for LE to support your RMODE 64 modules via the LE services that you can call. The LE services will pay attention to whether the underlying system service supports RMODE 64 or not. I've lost track of whether this is available or not, and, if not available, when it might be. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 specify 'RMODEX=64TRUE' on our binder parms. Could not find how to make that the default, but was eventually pointed to compilation and replacement of an options CSECT in the binder itself. Not the world's friendliest way to specify defaults... ;-) -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 Guide and Reference >> IBM SA23-1393-40 >>... >>ANY | 31 >>Indicates that the module might reside anywhere in virtual storage >>either above or below the 16-MB virtual storage line. synonym for ANY. >> >> (RCF submitted on error in paragraph quoted above.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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) 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's Guide and Reference > IBM SA23-1393-40 > > I read: >Residence mode >... >ANY | 31 >Indicates that the module might reside anywhere in virtual storage >either above or below the 16-MB virtual storage line. synonym for ANY. > > It matters little what a Glossary entry might say, no more than a Glossary > can redefine "black" as "white". > > (RCF submitted on error in paragraph quoted above.) > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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's Guide and Reference IBM SA23-1393-40 I read: Residence mode ... ANY | 31 Indicates that the module might reside anywhere in virtual storage either above or below the 16-MB virtual storage line. synonym for ANY. It matters little what a Glossary entry might say, no more than a Glossary can redefine "black" as "white". (RCF submitted on error in paragraph quoted above.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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: 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: 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 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 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 space like CICS. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 obtained from program objects through the binder API (for example, by the AMBLIST service aid) will show the original RMODE. However, for load modules, the ESD records are permanently modified. Joe On Mon, Dec 21, 2020 at 9:45 AM Joseph Reichman 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 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 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 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 > space like CICS. > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > > > > > > > > == > > > > Jeśli nie jesteś adresatem tej wiadomości: > > > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > > > mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 złotych. > > > > If you are not the addressee of this message: > > > > - let us know by replying to this e-mail (thank you!), > > - delete this message permanently (including all the copies which you > have printed out or saved). > > This message may contain legally protected information, which may be > used exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > > > mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.401.468 as at 1 January 2020. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
"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: > >> > >>> > >>> 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 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 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 > space like CICS. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.401.468 as at 1 January 2020. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 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 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 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 space like > CICS. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza > prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. > Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, > NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who disseminates > (copies, distributes) this message or takes any similar action, violates the > law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.401.468 as at 1 January 2020. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 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 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 space like CICS. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 tool I’m not sure But almost certain it wontvwork for Assembler Maybe for Java Am I on the right track ? Thanks > On Dec 21, 2020, at 10:19 AM, Ed Jaffe wrote: > > 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 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. > > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > > > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 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. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 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 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 in the environment but nothing > >>about the RMODE > > > >There are many, Many, MANY restrictions! > > > Are these listed anywhere? For code or for data? Services calls? Citation > needed. > > >Having said that, we're working on a not-yet-released product that is > >nearly 100% RMODE(64). > > > Why? 2GiB should be enough for anyone. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 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 in the environment but nothing about >>the RMODE > >There are many, Many, MANY restrictions! > Are these listed anywhere? For code or for data? Services calls? Citation needed. >Having said that, we're working on a not-yet-released product that is >nearly 100% RMODE(64). > Why? 2GiB should be enough for anyone. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 > 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 / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMODE64
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 nearly 100% RMODE(64). -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
