Re: diagnose 8 / interesting dilemma

Thank you for all of the responses and ideas. I guess if your 'guest operating system' is something like 'CMS' then it is quite easy to get consecutive pages of real storage addresses. But not quite so easy with z/os. I guess if you really want to do 'query virtual dasd' under z/os pre z/vm 6.4

AW: Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)

> Data chaining was the original solution to this problem. It was probably a bad idea to mention I/O in my post (I know about data chainging and IDAW). I was thinking more about the possible need to have more than 4k of contiguous real storage. Like Tony mentioned, new interfaces such as

Re: diagnose 8 / interesting dilemma

> What happens if AMODE 31 code issues LRA and the real address > is above the bar? Program check? yes. The ramifications of using the mod-2G part of the real address were quite obvious. The architecture reflected that understanding by making this case program check. >Or does LRA simply

Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)

Data chaining was the original solution to this problem. On Wed, 19 Oct 2016 00:27:56 +0200 Peter Hunkeler wrote: :> :>Below discussion triggered a question I could not answer by RTFM. I had never thought about this before in this detail, but now that I do, I wonder if the

Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)

On Tue, 18 Oct 2016 19:34:10 -0400, Tony Harminc wrote: > >If you want to do I/O to your real storage, that is what IDAWs are >for. Perhaps there are undocumented (or at least not publicly >documented) IBM facilities -- I'm guessing things like crypto, >compression, newer non traditional I/O --

Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)

On 18 October 2016 at 18:27, Peter Hunkeler wrote: > Below discussion triggered a question I could not answer by RTFM. I had never > thought about this before in this detail, > but now that I do, I wonder if the following is correct. > > Program allocates >4k of virtual storage. The

Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)

Below discussion triggered a question I could not answer by RTFM. I had never thought about this before in this detail, but now that I do, I wonder if the following is correct. Program allocates >4k of virtual storage. The real frames backing it may or may not be contiguous. The program wants

Re: diagnose 8 / interesting dilemma

On 18 October 2016 at 13:15, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > I find: > z/OS 2.2.0 > z/OS MVS > z/OS MVS Programming: Assembler Services Guide > Understanding 31-bit addressing > Understanding the use of central storage > Central

Re: diagnose 8 / interesting dilemma

On Mon, 17 Oct 2016 10:08:50 -0700, Ed Jaffe wrote: >> >> Hmmm... What happens if AMODE 31 code issues LRA and the real address >> is above the bar? Program check? Or does LRA simply (always?) load a >> 64-bit register? Is there an LRAG instruction? > >Why not take at least a cursory glance at

Re: diagnose 8 / interesting dilemma

> Of course there's the question of whether z/VM yet supports the large > pages (EDAT-1) needed to make this work. I don't believe it does as of > 6.3, though I may have missed an announcement. Good point, and the second time in a month that I have embarassingly forgotten about that (Peter

Re: diagnose 8 / interesting dilemma

On 17 October 2016 at 13:47, Jim Mulder wrote: > There is IARV64 GETSTOR with TYPE=FIXED and PAGEFRAMESIZE=1M. It's perhaps not 100% clear how it uses the 64-bit registers, but z/VM does seem to support AMODE 64 for the caller of Diagnose 8, so I think this could work. I

Re: diagnose 8 / interesting dilemma

>>> On 10/17/2016 at 02:23 AM, Paul Schuster wrote: > I am issuing DIAGNOSE 8 on my z/os image under VM (z/vm) to do a QUERY > VIRTUAL DASD. It works*up to a certain point: > > The QUERY VIRTUAL DASD command returns (for me) 38617 (decimal) bytes, > according to the

Re: diagnose 8 / interesting dilemma

> I am issuing DIAGNOSE 8 on my z/os image under VM (z/vm) to do a > QUERY VIRTUAL DASD. It works?up to a certain point: > > The QUERY VIRTUAL DASD command returns (for me) 38617 (decimal) > bytes, according to the CC=0 after the DIAGNOSE 8 command. My > buffer is large enough to accommodate

Re: diagnose 8 / interesting dilemma

On 10/17/2016 9:16 AM, Paul Gilmartin wrote: Hmmm... What happens if AMODE 31 code issues LRA and the real address is above the bar? Program check? Or does LRA simply (always?) load a 64-bit register? Is there an LRAG instruction? Why not take at least a cursory glance at Principles of

Re: diagnose 8 / interesting dilemma

On Mon, 17 Oct 2016 12:12:38 +0200, Christian Borntraeger wrote: > >As you already guessed, the memory you get is virtual, so the pages are not >consecutive. The LRA will give you the address of the first page, but the 2nd, >3rd and so on will be somewhere else. Please note that your code will

Re: diagnose 8 / interesting dilemma

On 10/17/2016 08:23 AM, Paul Schuster wrote: > I am issuing DIAGNOSE 8 on my z/os image under VM (z/vm) to do a QUERY > VIRTUAL DASD. It works—up to a certain point: > > The QUERY VIRTUAL DASD command returns (for me) 38617 (decimal) bytes, > according to the CC=0 after the DIAGNOSE 8 command.

diagnose 8 / interesting dilemma

I am issuing DIAGNOSE 8 on my z/os image under VM (z/vm) to do a QUERY VIRTUAL DASD. It works—up to a certain point: The QUERY VIRTUAL DASD command returns (for me) 38617 (decimal) bytes, according to the CC=0 after the DIAGNOSE 8 command. My buffer is large enough to accommodate this. I