I have developed a S/390 (and S/370) operating
system called PDOS, source code here:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/s370/pdos.c
It works fine under Hercules, but I was
wondering if anyone wanted to try it out
on real hardware. It IPLs from a 3390
(or I can put it on other d
I forgot to mention that since it is S/390,
not z/Arch, it will need any processor
from z13 back to S/370 XA. It only uses
instructions contained in S/370 XA.
Also, by "EBCDIC ANSI" terminal I mean
something that will handle an ESC [ 2 J
in EBCDIC instead of ASCII as a command
to clear the screen.
On Mon, 18 Mar 2019 21:17:10 +, Seymour J Metz wrote:
>WTF is an "EBCDIC ANSI terminal"? ANSI X3.64 specifies ASCII. Do you mean SCS,
>which is very different?
A terminal that conforms to ANSI X3.64
if all references to ASCII were replaced
with EBCDIC.
BFN. Paul.
-
On Mon, 18 Mar 2019 16:22:53 -0500, Paul Edwards wrote:
>A terminal that conforms to ANSI X3.64
>if all references to ASCII were replaced
>with EBCDIC.
And also the control characters like ctrl-x
and ctrl-c and ctrl-s that are typed need to
go through to the operating system and
Sorry for the excessive posts.
I forgot to mention that PDOS/390 is
designed to run (some) MVS load modules.
BFN. Paul.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu wi
On Tue, 19 Mar 2019 19:15:37 +, Seymour J Metz wrote:
>What translation of ASCII C-A through C-Z does PDOS/390 assume?
PDOS/390 just passes that through to the
application, but the applications are
expecting this:
static unsigned char atoe[256] = {
"\x00\x01\x02\x03\x37\x2D\x2E\x2F\x16\x05\
I was thinking that z/Arch and z/OS could
be updated to support AMODE 32.
If a load module is marked AMODE ANY,
RMODE ANY it could signify that it is
32-bit clean. That combination is
currently not really used, and the linker
can be updated to accept this combination.
PSW bit 30 can be used to si
On Wed, 3 Apr 2019 19:38:02 -0500, Paul Gilmartin wrote:
>>I was thinking that z/Arch and z/OS could
>>be updated to support AMODE 32.
>Cui bono?
Combined with making GETMAIN LOC=ANY,
when executed AM32, getting memory in the
2 GiB to 4 GiB region, it would allow a long
term plan of having pure
On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen
wrote:
>What problem would this solve?
It would set the long-term model for the
mainframe, instead of being stuck with
24/31-bit software for eternity.
>This would be of zero use for existing applications,
I don't agree. Existing applications
On Thu, 4 Apr 2019 07:46:59 -0400, Don Poitras wrote:
> When you brought this up a year ago, I don't think you convinced anyone
> that this was a useful change or that IBM should reasonably spend
> dollars doing it. I doubt much has changed since then to improve your
> chances.
Last time I was t
On Thu, 4 Apr 2019 12:54:28 +, Martin Packer
wrote:
> Plus, how would you map Shared or
> Common/System 64-Bit objects into such
> an address space?
I don't understand this technical question.
Can you rephrase?
BFN. Paul.
--
On Thu, 4 Apr 2019 13:19:03 +, Martin Packer
wrote:
>OK, I'll try...
>
>... Presumably you'd want this putative 32-bit address space to have
>access to all the stuff other address spaces have access to, such as
>Shared/Common areas above the bar.
No, I'd like current data above the 2 GiB
ba
On Thu, 4 Apr 2019 14:22:16 +, Gene Hudders wrote:
> How is the system going to interpret the X'80'
> used to indicate the end of a CALL parameter list.
This is one of the 32-bit changes, the same
as needs to be done if using AM64.
There is a set of changes that need to be
done when going f
On Thu, 4 Apr 2019 09:33:46 -0500, Tom Marchant
wrote:
>>The BSM instruction can use bit x'4000 '
>>to get/set AM32.
>
>No, it can't, for compatibility reasons.
What are you referring to? I don't see
any compatibility problem.
>>This introduces a 1 GiB
>>restriction where the module should
On Thu, 4 Apr 2019 15:03:43 +, Gene Hudders wrote:
> I'm sorry, but I don't have to make any changes
> to my 31 bit programs using CALLs and using
> 64-bit addressing. We have lots of programs
> doing both AM31 and AM64 with the only change
> is the instructions to change the addressing mode.
I'm sorry I don't understand your technical point.
Could you rephrase?
As far as I am aware, if you do a:
CALL xxx,VL
to set the high bit to signify end of parameter
list, then if the target is operating in AM64, it
will fail with a S0C4.
BFN. Paul.
On Thu, 4 Apr 2019 15:12:24 +, Gene Hu
On Thu, 4 Apr 2019 14:42:47 +0300, Binyamin Dissen
wrote:
>Sounds like a pretty narrow range of applications, where the existing above
>the line is not enough, but an extra 2G will be enough forever.
It's sometimes not a matter of "not enough"
so much as "capability". E.g. a 32-bit editor
is ca
On Thu, 4 Apr 2019 17:45:27 +, Seymour J Metz wrote:
>> I don't agree. Existing applications can be
>> modified to be 32-bit clean
>
>Only if the never use storage above the line for parameters.
Or they don't use VL, the same requirement
that AM64 has.
BFN. Paul.
--
On Thu, 4 Apr 2019 18:14:48 +, Seymour J Metz wrote:
>Existing programs will be using VL,
Not always. It is relatively rare to take
a variable number of parameters.
> so you're talking a total rewrite to exploit AMODE32.
No, fairly minor changes, not a rewrite.
> How is that short-term fi
On Thu, 4 Apr 2019 12:59:03 -0500, Mike Schwab wrote:
>A lot of installations run multiple CICS / IMS / DB2 regions because
>one or two 2GiB regions is not nearly enough.
Why are they not running as 64-bit?
BFN. Paul.
--
For I
On Thu, 4 Apr 2019 19:32:01 +, Martin Packer
wrote:
>They will be (running 64-bit). However, apart from Db2*, much of their
>virtual storage components can't tolerate being above the bar.
Which virtual storage components can't tolerate
being above the bar, and why is that and what
would nee
ossible. You will then be limited to incrementing
>registers by 4GiB or less. Just establishing addressability will need
>to set all 64 bits.
>
>On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards wrote:
>>
>> On Thu, 4 Apr 2019 19:32:01 +, Martin Packer
>> wrote:
>&
On Fri, 5 Apr 2019 15:55:42 -0400, Joe Monk wrote:
>> I'm trying to understand why some sites
>> are running multiple CICS regions because
>> 2 GiB is not enough. Yet they haven't
>> gone to AM64..."
>
> Who is going to pay for programmer time to convert applications to 64-bit?
> The cost of runn
I have just released the below software, which
represents a significant chunk of my life's work.
I'd especially like to thank Gerhard Postpischil
for enabling MVS/380 to do multiple ATL
getmains plus work on the C library, and Alica Okano
for getting PDOS to the point where it can run
some Windows
On Sun, 6 May 2018 18:34:35 -0500, Paul Edwards wrote:
Sorry for the necro ...
>On Sun, 6 May 2018 16:11:57 -0700, Charles Mills wrote:
>
>>2. A 31/32-bit program cannot count on the high
>> halves being zero in any event. There is no
>> guarantee that you are entered
h-half of the register, unless executing in AMODE 64.
>
>Anyway, what's the point of clearing registers unless or until you need to
>use them?
>
>sas
>
>
>On Wed, Feb 1, 2023 at 8:02 PM Paul Edwards wrote:
>
>> On Sun, 6 May 2018 18:34:35 -0500, Paul
On Thu, 2 Feb 2023 16:38:38 +, Peter Relson wrote:
>I couldn't find the original post for this thread even in the archives, so I
>don't know what this has to do with GETMAIN, or where "LOC=32" came into
>things since the parameter is LOC=31.
Here is the first post:
https://listserv.ua.edu
On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe wrote:
>On 2/2/2023 2:36 PM, Paul Edwards wrote:
>> But on top of that, I was looking for a z/OS change to
>> guarantee the high halves were zero. And the new
>> information is that I don't need that guarantee. I can
>>
switch to different semantics if you
can tell me what they are.
The use of 32-bit vs 64-bit load/store/etc instructions is
completely independent of whether EITHER of those
(32 vs 64) program types is running as AMODE 24/31/32/64.
BFN. Paul.
>On Thu, Feb 2, 2023 at 4:36 PM Paul Edwards wrote:
>
never be touched, so there is no issue with only using the traditional
STM instruction to save registers in a subroutine.
BFN. Paul.
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
>Paul Edwards [mutazi...
scussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
>Paul Edwards [mutazi...@gmail.com]
>Sent: Thursday, February 2, 2023 5:59 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe
>wrote:
>
>>On 2/2/2023 2:36 PM, Pa
On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote:
>> And given that the high 32 bits are required to be 0, by convention,
>
>Where do you see that?
That was my first message in the last 24 hours.
Do an LA on program entry, for all undefined registers.
Maybe I should have said "proposed
On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz wrote:
>I now of no IBM documentation to justify an expectation that the high halves
>will be zero on entry.
Correct. Which is why my opening message was to add a series of LA
instructions to force that to be the case myself.
The main thing I
ad an address, it is a 32-bit address, which will
suddenly be visible when running in AM64 (or a restored
360/67 running as AM32).
BFN. Paul.
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List
2 bits will be set to 0 by the
caller (since the program will be located in RM24, RM31 or
potentially one day RM32 space), so doesn't need to be preserved
(it is defacto preseved/unchanged).
BFN. Paul.
>On Thu, Feb 2, 2023 at 5:42 PM Paul Edwards wrote:
>
>> On Thu, 2 Feb 2
http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
>Paul Edwards [mutazi...@gmail.com]
>Sent: Thursday, February 2, 2023 6:47 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GE
;
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
>Paul Edwards [mutazi...@gmail.com]
>Sent: Thursday, February 2, 2023 6:42 PM
>To: IBM-MAIN
mour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
>Paul Edwards [mutazi...@gmail.com]
>Sent: Thursday, February 2, 2023 7:26 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subjec
r J Metz wrote:
>No, I'm claiming that LA R1,0(,R1) doesn't clear bits 0-31. Specifying base
>and index as 0 is a special case and clears all but the 12 bits of the
>displacement.
>
>
>From: IBM Mainframe Discussion List o
rote:
>My concern is that in no case does LA clear bits 0-31 while leaving the lower
>bits intact. A secondary concern is indexing with negative index values.
From: IBM Mainframe Discussion List on behalf of
Paul Edwards
Sent: Thursday, February 2, 2023
___
>From: IBM Mainframe Discussion List on behalf of
>Paul Edwards
>Sent: Thursday, February 2, 2023 7:50 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: GETMAIN LOC=32
>
>We're in agreement then.
>
>So what's the issue?
>
>In my first message I
Feb 2023 00:58:54 +, Seymour J Metz wrote:
>What happens when the AM31 caller passes the PLIST address in R1? Who clears
>bits 9031, and how?
From: IBM Mainframe Discussion List on behalf of
Paul Edwards
Sent: Thursday, February 2, 2023
Link:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvsstart.asm#l94
On Thu, 2 Feb 2023 19:04:05 -0600, Paul Edwards wrote:
>Here is my code:
>
>* First save away the R1 in case it is needed because it is
>* a TSO environment and this is the CPPL
>
are "ready" for a z/OS change - even if
that never happens. Or if it only happens on some other OS.
What code do you suggest for both program entry and for
calling z/OS services?
Thanks. Paul.
On Thu, 2 Feb 2023 19:06:21 -0600, Paul Edwards wrote:
>Link:
>
>https://source
map the 4-8 GiB region onto
0-4 GiB (DAT/virtual storage).
This has already been proven to work with z/PDOS.
Note that it took me years to realize this, and it was
Joe Monk (who posts here) who told me the problem
could be solved with DAT.
BFN. Paul.
On Thu, 2 Feb 2023 18:55:41 -0600, Paul Edward
the IBM C compiler doing optimization.
BFN. Paul.
On Tue, 7 Feb 2023 15:33:38 -0600, Tom Marchant
wrote:
>Is that all you want?
>
>
>
>"I want it because I think it would be cool" is not a business justification.
>
>--
>Tom Marchant
>
>On Tue, 7
I now have a pure public domain 3390 disk containing z/PDOS
and assorted utilities.
There isn't a lot of public domain (as opposed to copyrighted
freeware like most z/Linux stuff) stuff available for the mainframe,
so currently there are only crude editing capabilities available.
But you can IPL
Hi.
I have mentioned the PDOS (Public Domain Operating
System) project before, but just recently I have updated
it to work on z/Arch.
It's still somewhat in "Proof of Concept" stage, but it is
already producing interesting results.
You can obtain a CKD image from the bottom of this page:
http://
Hi.
Would someone be able to try out the latest z/PDOS on
real hardware?
It's available from http://pdos.org (down the bottom)
It is a 3390-1 CKD image and you will need OSS-ICC in
order to define a 3270 terminal (SYSG is not used).
In addition you will need to know the subchannel id of the
327
On Wed, 21 Dec 2022 20:15:49 +, Rahim Azizarab
wrote:
>I don't have access to real iron; but did you ever try to run it under qemu
>x390?
As far as I know, qemu doesn't support CKD disks or
connecting a 3270 terminal.
But if that assumption is wrong, I can try it if you give
me a syntax t
On Wed, 21 Dec 2022 03:44:56 -0600, Paul Edwards wrote:
>Would someone be able to try out the latest z/PDOS on
>real hardware?
There is a new version at http://pdos.org which allows
IPL from tape (and restore from 3390 disk image on
tape) - no IBM or other vendor software required - and
I wish to create "executables" by running iewl, doing an iebcopy
unload, and then doing the equivalent of ftp with option rdw to
create a simple flat/sequential file that is self-contained.
(rightly or wrongly, this is my design goal)
And I want to use the MVS 3.8J version of the tools and then h
Thanks all for your replies.
> I agree with Binyamin - XMIT format (aka NETDATA format, also transportable
> to VM systems) is fixed-length,
Being fixed length isn't a selling point to me. zip files aren't
fixed length either. It's actually a non-selling point.
You can consider that I have a riv
On Sat, 15 Jun 2024 23:30:13 -0700, Michael Stein wrote:
>> Well that's basically my question - "any kind of DASD". I had an idea
>> that maybe I should use a 2314 so that there is only one block per
>> track. Someone told me elsewhere that I can't use VIO regardless -
>> you can't have a VIO PDS
On Sun, 16 Jun 2024 08:34:14 -0500, Paul Gilmartin wrote:
>>> I agree with Binyamin - XMIT format (aka NETDATA format, also transportable
>>> to VM systems) is fixed-length,
>>
>What's important is not fixed-length, but that the data may
>be regarded as a featureless binary stream.
Yes. Or at le
On Sun, 16 Jun 2024 23:48:56 +, Seymour J Metz wrote:
> What's wrong with using 3330 or 3350?
I didn't say there was something wrong with them - that's
basically my question.
> Both have track sizes less than 32KiB.
I wasn't aware that that was even an issue.
But yes - the answer may well
On Sun, 16 Jun 2024 21:07:59 -0500, Paul Gilmartin wrote:
>On Mon, 17 Jun 2024 01:19:27 +, Seymour J Metz wrote:
>
>>If you have to unload to 3330, then use BLKSIZE=13030 for SYSLMOD; IEBCOPY
>>doesn't support COPYMOD reblocking for load/unload.
>>
>Has everyone noticed what a grievous desi
On Mon, 17 Jun 2024 01:15:33 +, Seymour J Metz wrote:
> If you're running on a supported system,
pdld is C90-compliant and can run anywhere - like Windows -
processing EBCDIC object code and producing an unloaded
load module. It does this all itself - not using any IBM tools.
So there is no
On Mon, 17 Jun 2024 04:57:31 +, Seymour J Metz wrote:
> By "running" I'm referring to the IBM OS that will load and use
> the load module, not to the system used to transport it.
(and presumably - "or create it").
Ok, sorry for the misinterpretation.
> AFAIK IEBCOPY load does not depend on
On Mon, 17 Jun 2024 00:04:55 -0500, Paul Gilmartin wrote:
>>It would be nice if one day that RECFM=U file could be plonked
>>into any linklib on z/OS and also be executed. And yes, there will
>>be a slight overhead in doing so - but close to zero chance any
>>application will be bottlenecked on o
On Mon, 17 Jun 2024 11:40:37 -0500, Paul Gilmartin wrote:
>On Mon, 17 Jun 2024 04:54:55 -0500, Paul Edwards wrote:
>>>>...
>>>You are on the very verge of re-inventing program objects in UNIX
>>>files, which work that way.
>>
>>Thanks for the poi
There has been a recent development that means that I now
have a C90-compliant compiler, assembler and linker that
allows me to produce MVS load modules (in IEBCOPY unload)
on basically any environment - ASCII or EBCDIC (I've only tested
building on Windows and running on z/PDOS though).
So here i
On Wed, 3 Jul 2024 16:04:09 -0500, Paul Edwards wrote:
>Anyway, this is my question.
>
>I am wondering whether there is an existing C interface to MVS. There
>wasn't at the time of MVS 3.8J - not from IBM anyway - but there might
>have been some 3rd party vendor. Or maybe
On Mon, 8 Jul 2024 17:08:15 -0500, Charles Mills wrote:
>I wasn't sure what you meant. I think what you are asking is:
Hi Charles (and others). Thanks for your reply and sorry for the
delay. During the delay I have managed to prove the concept
that PDOS-generic works on the mainframe too. So the
On Sat, 20 Jul 2024 06:46:40 +1000, Wayne Bickerdike wrote:
>Some kind of false economy to make the PC the entire tool of choice for
>certain routine tasks.
>
>In the 1980s we had proprietary banking terminals, private/leased line
>point to point communications and passbooks.
This is a topic of
On Fri, 19 Jul 2024 18:39:02 -0500, Joe Monk wrote:
>More to the point, the issue is not Windows, but the abuse of Windows.
>Example: requiring administrator rights to do ordinary, everyday tasks.
Can you elaborate on this? Who made the decision to require
admin rights?
>This led to "script kid
On Sat, 20 Jul 2024 10:26:46 +1000, Clement Clarke wrote:
>Can we bring back OS/2?
It's still available. I bought a commercial license for ArcaOS
because I was thinking of switching to it - where there is the
ability to actually report bugs and get them fixed without
being asked to pay full west
On Fri, 19 Jul 2024 14:38:53 +, Nash, Jonathan S.
wrote:
>This reminded me of Danny Hillis's discussion about
>how we need a plan B for the Internet:
>
>https://youtu.be/2K6WN3LBHiw?si=R1-dBlYzdZRwCvSr
I just watched the video.
One of the things he mentioned was the police department
being
On Sat, 20 Jul 2024 13:04:00 +1000, Wayne Bickerdike wrote:
>*Are you suggesting using physical cash because software andhardware
>engineers are unable to create a reliable alternative?*
>
>Absolutely yes. There are myriad reasons, in my case I have a pension paid
>into a UK account. Domiciled in
You might find this useful:
/*/
/* */
/* This Program Written By Paul Edwards.*/
/* Released to the public domain
Hi ZA.
This concept of "C is not available in many many shops"
is the exact reason I spent a large chunk of my life
porting GCC to MVS (gccmvs). I considered the lack of
a universal language for computers to be a serious
flaw in the computer industry. With the advent of
GCCMVS, C is now either bun
Hi gil.
> Making gcc a prerequisite might be onerous.
I think "any C compiler, including the freely available
one - gccmvs, is a prerequisite" is not onerous.
> And to my knowledge all z/OS ports of gcc are biased
> toward legacy data sets and against UNIX files, which
> I regard as a flaw.
I
on
non-standard utilities.
Thanks. Paul.
/*/
/* */
/* This Program Written By Paul Edwards.
> If the OP hasn't access to z/OS, his interest must be only academic.
I wish to distribute VB files (developed on MVS/380) via PC,
with z/OS as a target. I don't want BDW, just the RDW format
that ftp produces. I'm very happy with the RDW format that
IBM's ftp produces, I just want it to be rever
>> I wish to distribute VB files (developed on MVS/380) via PC,
>> with z/OS as a target. I don't want BDW, just the RDW format
>> that ftp produces. I'm very happy with the RDW format that
>> IBM's ftp produces, I just want it to be reversible.
> STRU R is reversible; RDW isn't. For your objecti
> It produces a V-format file that can be
> processed by a C program.
As an example, I want to be able to transmit an
SMF file (which I believe contains binary data) to
the PC, and then have a PC program to process
the SMF file. The PC program must handle the
RDW itself, but that's all.
IBM's ftp
>> That is not even close to the RDW format that IBM
>> provides. I have based PDPCLIB around IBM's RDW
>> format.
> And you're not flexible about this?
That's correct. When I open a VB file in binary
mode, there's only one single choice for the
data stream to be in, so I had to pick one single
> You should submit an RFE for FTP to IBM.
Hi Kirk. I am not an IBM customer. Is this something
you could do yourself? Or will anyone else volunteer?
Thanks. Paul.
--
For IBM-MAIN subscribe / signoff / archive access instruction
> And he wants to be
> able to read the envelope file on a PC, but he hasn't mentioned the
> EBCDIC<-->ASCII problem. Perhaps it's considered a given; SMoP again.
That's fine. It's well-defined that the binary file is in
EBCDIC, uses big-endian 4-byte integers etc. Thus
any EBCDIC text will be ru
Thanks for the pointer Kirk.
I have submitted it:
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=63596
BFN. Paul.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@
> I have submitted it:
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=63596
IBM has responded with:
Thank you for submitting this request. Your enhancement request was submitted
against the software product "InfoSphere Streams". From the description, I
believe that thi
Hi. I would like to submit an RFE to IBM to
support a LOC=32 parameter to GETMAIN,
giving 32-bit programs access to a full 4 GiB
instead of the current 2 GiB provided by
LOC=31. IBM can use the LOC=31 bits
plus the top bit of the option byte seen here:
https://www.ibm.com/support/knowledgecenter/S
Who is disadvantaged by making memory above
2 GiB available to anyone who specifically requests it?
BFN. Paul.
On Sun, 6 May 2018 15:23:38 -0400, Tony Thigpen wrote:
>Bad idea. The 31bit bar is there for a very, very good reason.
>
>Tony Thigpen
>
>Paul Edwards wrote on 05/0
On Sun, 6 May 2018 15:45:31 -0400, Tony Thigpen wrote:
>Just for starters.
>
>1) I am looking at the registers at abend. Is it a 31 bit address with
>the high-bit on, or is it a 32 bit address?
If you don't want to debug 32-bit programs
that have 4 GiB of memory available to them,
then simply do
On Sun, 6 May 2018 17:10:34 -0400, Tony Thigpen wrote:
> Most of your comments can be addressed simply by:
>"But, I do know the current addressing mode."
I'm sorry. I don't understand this comment.
>So, unless you are going to add another addressing mode
No new addressing mode is required.
On Sun, 6 May 2018 17:57:07 -0400, Tony Thigpen wrote:
>Well, if you have to be in 64bit mode anyway, what do you care that BAR
>is unusable? It's not like you are running out of 64bit storage.
I wish to run 32-bit programs, with 32-bit data
pointers, not 64-bit programs.
With some minor change
On Sun, 6 May 2018 18:04:42 -0400, Tony Thigpen wrote:
> Me thinks your logic is circular and not worth
> continuing this discussion.
I have no idea what you are talking about.
32-bit programs can suddenly access 4 GiB
of memory instead of being restricted to 2 GiB.
There's nothing circular abou
On Sun, 6 May 2018 15:08:24 -0700, Charles Mills wrote:
>What exactly would the benefit be?
Any 32-bit program currently coming up
against the 2 GiB barrier can have its life
extended by bumping the limit up to 4 GiB.
> Currently, if one wants to address more than
> 2GiB of memory one has to be
On Sun, 6 May 2018 18:07:02 -0500, Mike Schwab wrote:
>So, you will have a load module marked AM32.
That doesn't exist as far as I know. The module
can either be marked AM64 or the program can
switch to AM64 at startup. My preference is for
the module to be marked AM64.
>All instructions use
>o
On Sun, 6 May 2018 16:11:57 -0700, Charles Mills wrote:
> The effort would be on the part of "service" writers -- primarily IBM
> developers.
Sure.
>This is a new sort of-AMODE. Storage that you can
> reference but cannot pass to the unwary, cannot
> use with standard MVS VL=1 linkage, cannot
On Mon, 7 May 2018 02:58:38 -0500, Elardus Engelbrecht
wrote:
>> GETMAIN is not going to ever manage 32-bit
>> storage. I would word you requirement this way:
> Why specific GETMAIN? What about STORAGE macro?
For an existing 32-bit program, being able to
change LOC=31 or LOC=ANY to LOC=32 is
On Sun, 6 May 2018 21:14:38 -0400, Jim Mulder wrote:
>> GETMAIN is not going to ever manage 32-bit storage.
>> I would word you requirement this way:
>
> " I would like to have a USE2GTO4G=NO|YES
> parameter on IARV64 GETSTOR,
Hi Jim. Thanks for the interesting suggestion, but
by separating th
On Mon, 7 May 2018 07:05:19 -0500, Tom Marchant
wrote:
>>If GETMAIN is modified as I requested,
>>the 16 MiB to 4 GiB region will be a continuous
>>region and a GETMAIN of 3 GiB will work so long
>>as there hasn't been fragmentation. ie a 32-bit
>>program can allocate a single 3 GiB chunk.
>
>No
On Mon, 7 May 2018 07:15:23 -0500, Tom Marchant
wrote:
>>For an existing 32-bit program, being able to
>>change LOC=31 or LOC=ANY to LOC=32 is
>>the simplest change, and on an old system
>>it will still work, just obtaining LOC=31 memory
>>instead of LOC=32 memory, better than nothing.
>
>You wa
On Mon, 7 May 2018 12:49:31 +, Allan Staller wrote:
>AM64 is very different than what you are have been asking for in this thread.
>
>z/OS currently supports 3 addressing modes;
>AM24, AM31 and AM64. What you are asking for is a major re-architecting of
>z/OS to create AM32.
In a way you ca
On Mon, 7 May 2018 08:15:45 -0400, Peter Relson wrote:
>The term "32-bit program" has been repeated in this thread. It appears
>that the OP means by this that the program can be AMODE 31 or AMODE 64 but
>never directly touches bits 0-31 of a GR.
Thanks for providing that clarification. You ar
On Mon, 7 May 2018 08:29:23 -0500, Tom Marchant
wrote:
>>Oh - I'm also assuming that IBM will update
>>the operating system so that READ etc can
>>be executed in AM64.
>
>ROFL! You didn't ask for that.
I didn't ask for it yet because the first step is to
just have RM32 memory available. If I ca
On Mon, 7 May 2018 08:42:00 -0500, Joel C. Ewing wrote:
>From the early days of S/360 the high-order bit of a full-word address
>pointer has a documented function in standard subroutine linkage of
>indicating the last parameter address for subroutines that accept a
>variable number of parameters,
On Mon, 7 May 2018 09:54:34 -0400, Tony Thigpen wrote:
>I thing you are just 'digging your heels in' at this point and not
>listening to what people are trying to tell you. I suggest you re-read
>some of the responses with a more open mind.
Almost everything I have talked about here is
*already*
On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant
wrote:
>>Updating 32-bit programs to conform to
>>AM64 requirements is far less onerous
>>than the massive changes required to
>>create a 64-bit application.
>
>No, it isn't. Why do you think it is?
All references to "L" to load an address need
to
1 - 100 of 153 matches
Mail list logo
