Re: GETMAIN and LOC=(xx,64)

2013-09-07 Thread Manfred Lotz
Thanks for your (and the others) reply.  

What I read from the replies confirms my view that LOC=(xx,64) is generally 
good if I have no special stuff regarding real pages in my code. 


-- 
Thanks,
Manfred

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


GETMAIN and LOC=(xx,64)

2013-09-06 Thread Manfred Lotz
Hi there,
I'm maintaining a larger program written in assembler where GETMAINs have 
mostly LOC=(BELOW,ANY) or LOC=(ANY,ANY). 

This program doesn't  use anything like PGSER, EXCPVR or the like. 

My question: In order to give the operating system most flexibility wouldn't it 
be recommended to change:

LOC=(BELOW,ANY)  --- LOC=(24,64)
 LOC=(ANY,ANY)---  LOC=(31,64)

?

Any  opinion appreciated.


-- 
Manfred

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN and LOC=(xx,64)

2013-09-06 Thread Gerhard Postpischil

On 9/6/2013 1:52 PM, Manfred Lotz wrote:

I'm maintaining a larger program written in assembler where GETMAINs have 
mostly LOC=(BELOW,ANY) or LOC=(ANY,ANY).
This program doesn't  use anything like PGSER, EXCPVR or the like.
My question: In order to give the operating system most flexibility wouldn't it 
be recommended to change:
 LOC=(BELOW,ANY)  --- LOC=(24,64)
  LOC=(ANY,ANY)---  LOC=(31,64)
Any  opinion appreciated.


You need to verify that nothing in a relocated area uses 3-byte address 
constants, and that the address of the acquired storage isn't treated as 
24-bit anywhere. You can either run with PRINT ON,GEN,DATA and go 
through the listing line by line, or change everything and hope you get 
an 0C4 on all bad references.


P.S. The program does run in AM31 already?

Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN and LOC=(xx,64)

2013-09-06 Thread Tony Harminc
On 6 September 2013 16:53, Gerhard Postpischil gerh...@valley.net wrote:
 On 9/6/2013 1:52 PM, Manfred Lotz wrote:

 I'm maintaining a larger program written in assembler where GETMAINs have
 mostly LOC=(BELOW,ANY) or LOC=(ANY,ANY).
 This program doesn't  use anything like PGSER, EXCPVR or the like.
 My question: In order to give the operating system most flexibility
 wouldn't it be recommended to change:
  LOC=(BELOW,ANY)  --- LOC=(24,64)
   LOC=(ANY,ANY)---  LOC=(31,64)
 Any  opinion appreciated.


 You need to verify that nothing in a relocated area uses 3-byte address
 constants, and that the address of the acquired storage isn't treated as
 24-bit anywhere. You can either run with PRINT ON,GEN,DATA and go through
 the listing line by line, or change everything and hope you get an 0C4 on
 all bad references.

Surely Manfred is just asking about the real storage that backs the
virtual. Which, except in rare cases such as using EXCPVR or LRA or
perhaps some fast-path VTAM operations, is entirely transparent to the
application program.

I see no problem with the proposed changes, and they should indeed
provide some added flexibility to RSM.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: GETMAIN and LOC=(xx,64)

2013-09-06 Thread Blaicher, Christopher Y.
Interesting question, with a number of answers.

The second value only comes into play at PAGEFIX time, be that your program 
doing it explicitly, or the system doing it for you, most often as part of an 
I/O operation, such as a BSAM READ or WRITE, or a QSAM GET or PUT.

Up until that PAGEFIX happens any real page frame can back any virtual page.  I 
have seen 24-bit real backing a 64-bit virtual and the reverse.  Only at 
PAGEFIX does he make sure that the real page backing the virtual is less than 
or equal to what you specified in the LOC= parameter.

When you do a GETAMIN, or STORAGE OBTAIN, or whatever, the system notes your 
request and sets up some control areas, but no frames are assigned, yet.  Once 
you touch the page, then a real frame is assigned to the virtual page, and the 
system doesn't care where that real frame is.

At PAGEFIX time, then it matters.  If you had a LOC=(31,31) and the initial 
backing frame is a 24-bit frame, it may do nothing or it may move the data to a 
31-bit frame.  If the initial backing frame is a 64-bit frame, then it will 
move the data to a 24-bit or 31-bit frame.

Now to your question.  Unless you are doing something special where you know 
you need 24 or 31 bit real, you can use LOC=(24,64), or LOC=(31,64).  BSAM, 
QSAM and VSAM all support 64-bit backing frames.  Since most normal programs 
can't do a LRA/LRAG/LRAY, you are probably safe.  I can't think of any 
non-privileged instructions that are real frame sensitive.

DCB's can be LOC=(24,64)

As with any change, TEST, TEST, TEST.  And if I have miss-spoken at any point, 
I am sure someone will set the record straight.

HTH

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com


On 9/6/2013 1:52 PM, Manfred Lotz wrote:
 I'm maintaining a larger program written in assembler where GETMAINs have 
 mostly LOC=(BELOW,ANY) or LOC=(ANY,ANY).
 This program doesn't  use anything like PGSER, EXCPVR or the like.
 My question: In order to give the operating system most flexibility wouldn't 
 it be recommended to change:
  LOC=(BELOW,ANY)  --- LOC=(24,64)
   LOC=(ANY,ANY)---  LOC=(31,64)
 Any  opinion appreciated.




ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other  confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN