Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

Bad idea. The 31bit bar is there for a very, very good reason. Tony Thigpen Paul Edwards wrote on 05/06/2018 02:51 PM: 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

Re: GETMAIN LOC=32

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

Re: unexpected tape issue with RETAIN

Tony, I remember some behavior like this from the days of real tape. Was the behavior that RETAIN would rewind but not dismount the tape, even at the end of the step, and it was AVR that found the tape if an ensuing step needed it. If there was another mount request before the ensuing step

Re: GETMAIN LOC=32

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. Tony Thigpen Paul Edwards wrote on 05/06/2018 05:29 PM: On Sun, 6 May 2018 17:10:34 -0400, Tony Thigpen wrote: Most of your comments

Re: GETMAIN LOC=32

Most of your comments can be addressed simply by: "But, I do know the current addressing mode." So, unless you are going to add another addressing mode Tony Thigpen Paul Edwards wrote on 05/06/2018 04:00 PM: On Sun, 6 May 2018 15:45:31 -0400, Tony Thigpen wrote: Just

Re: GETMAIN LOC=32

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? 2) The programmer uses GETMAIN LOC=32 forgetting that he is passing an address that is in that area to a subprogram that is not 32bit. Oops. 3) I am looking at

GETMAIN LOC=32

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:

Re: GETMAIN LOC=32

Me thinks your logic is circular and not worth continuing this discussion. Tony Thigpen Paul Edwards wrote on 05/06/2018 06:01 PM: 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?

Re: Job submit using REXX

This process can be done by using a trap for a message on your system. MPF Exit might work CBTTAPE.ORG might have a process you can tailor Any Scheduling software will have a file trigger function What options are there? This is more complicated without scheduling software. You will need to

Re: IEFA107I when pointing to dataset alias

That may have been cool long ago in a galaxy far away, but after the advent of static system symbols it became unnecessary complexity. Not worth getting rid of if you're already doing it, but it's not the way to go for a new data center. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

What exactly would the benefit be? Currently, if one wants to address more than 2GiB of memory one has to be a full AMODE 64 program. This would let a program address 4GiB while only using 32-bit registers and addresses in storage -- is that the point? Or am I confused? Is that the whole point?

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

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.

Re: DFSMSdss Release command

Gadi, While this does not help to release the space on currently empty data sets, you can mitigate the problem by having allocation assign a DSORG. Set up your ACS rules to have datasets with an unspecified DSORG drop through to a DATACLAS with DSORG=PS and the EOF is updated at allocation, and

Re: GETMAIN LOC=32

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, similar to the already exisiting USE2GTO32G=NO|YES and USE2GTO64G=NO|YES. And I would like to have a way to tell the system to

Re: GETMAIN LOC=32

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.

Re: GETMAIN LOC=32

So, you will have a load module marked AM32. All instructions use only the lower half of the registers, no grande or high portion instructions. The program loader gets memory at x' 8 ' (or the next location not in use) and loads your program, sets AM64 and calls your entry

Re: GETMAIN LOC=32

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

Re: GETMAIN LOC=32

The effort would be on the part of "service" writers -- primarily IBM developers. 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 branch to, ... > So long as the top 32 bits of 64-bit registers remain

Re: z/VM Live Guest Relocation

re: http://www.garlic.com/~lynn/2018c.html#77 z/VM Live Guest Relocation http://www.garlic.com/~lynn/2018c.html#78 z/VM Live Guest Relocation http://www.garlic.com/~lynn/2018c.html#79 z/VM Live Guest Relocation http://www.garlic.com/~lynn/2018c.html#80 z/VM Live Guest Relocation some other trivia

Re: Job submit using REXX

Sorry in advance for the product plug. Our syzMPF/z console automation product (and SyzEMAIL/z if you want to get really fancy with the process) will do this and it's a lot cheaper than other automation software. The script can key off the message ID (and fully parse the message) and can set

Re: GETMAIN LOC=32

Before you (or anyone) writes an RFE telling IBM how to do something, you might want to think about the problem, and investigate how it might be solved. As it happens, this proposal should be rejected because the capability already exists. sas

Re: unexpected tape issue with RETAIN

Swaps? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: 04 May 2018 17:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: unexpected tape issue with RETAIN I currently think it has to do with a combination of a faulty

Re: Netview Login issue

Hello Lizette, We using Netview 6.2. Now problem has been resolved by one of the major node . Now i am able to login to netview for use. On Sat, May 5, 2018 at 8:14 PM, Lizette Koehler wrote: > First, the manuals should tell you how to set up Netview and log on > >