Re: Endianness and bit numbering Was RE: STORAGE OBTAIN doc inconsistency?

That's only partly true. Of the three such languages that I'm familiar with, they all write the numbers so that higher order digits are to the left of lower order digits but not all of them read in left to right order. One of them reads the numbers right to left i.e. units tens hundreds order.

Re: Endianness and bit numbering Was RE: STORAGE OBTAIN doc inconsistency?

On Wed, 3 Jul 2019 17:14:12 +, Seymour J Metz wrote: >> I think the cultures that read from right to left number the pages that way >> also. > >The cultures that read from right to left still read Arabic numerals (not to >be confused with the numerals in the Arabic script) from left to

Re: Endianness and bit numbering Was RE: STORAGE OBTAIN doc inconsistency?

smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, July 2, 2019 7:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Endianness and bit numbering Was RE: STORAGE OBTAIN doc inconsistency? You are right of course: pr

Re: Endianness and bit numbering Was RE: STORAGE OBTAIN doc inconsistency?

Charles Mills wrote: >Absent a total re-engineering of the hardware, that will never >change on a Z box. And if it somehow magically did change, every >bit of Z software would have to be examined and tested and in >many cases re-coded. There are many "bi-endian" processors, including Power

Re: Endianness and bit numbering Was RE: STORAGE OBTAIN doc inconsistency?

ay consistent: groups of bits are numbered the same way no > matter what the size of the group. Even if that size is 1. In this scheme too: the LSb is numbered 0, the next is numbered 1, and so forth, no matter what the size of the group. That is the whole advantage: in the documentation of STO

Re: Endianness and bit numbering Was RE: STORAGE OBTAIN doc inconsistency?

mbering are mostly not. Tony H. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tony Harminc > Sent: Tuesday, July 2, 2019 10:38 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: STORAGE OBTAIN doc inconsistency? >

Re: Endianness and bit numbering Was RE: STORAGE OBTAIN doc inconsistency?

Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Tuesday, July 2, 2019 10:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STORAGE OBTAIN doc inconsistency? On Mon, 1 Jul 2019 at 15:06, Charles Mills wrote: > > You're right, of course. Not to start

Endianness and bit numbering Was RE: STORAGE OBTAIN doc inconsistency?

ssion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Tuesday, July 2, 2019 10:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STORAGE OBTAIN doc inconsistency? On Mon, 1 Jul 2019 at 15:06, Charles Mills wrote: > > You're right, of course. Not to start a religious war, but

Re: STORAGE OBTAIN doc inconsistency?

On Mon, 1 Jul 2019 at 15:06, Charles Mills wrote: > > You're right, of course. Not to start a religious war, but even on a > big-endian machine, it seems to me to make sense to number > the bits from LSB to MSB. Bit n then represents 2^n -- in an 8-, 16-, 32-, > 64- or 128-bit integer. What

Re: STORAGE OBTAIN doc inconsistency?

-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Monday, July 1, 2019 6:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STORAGE OBTAIN doc inconsistency? The notation that would be clearest is to number the bits from

Re: STORAGE OBTAIN doc inconsistency?

Steve, Absolutely, clarification always helps. Scott On Mon, Jul 1, 2019 at 9:41 AM Steve Smith wrote: > The notation that would be clearest is to number the bits from right to > left. However, that may well cause other logical problems on a big-endian > architecture. And obviously, such a

Re: STORAGE OBTAIN doc inconsistency?

The notation that would be clearest is to number the bits from right to left. However, that may well cause other logical problems on a big-endian architecture. And obviously, such a change would be ludicrous at this point. I don't think there's any way to support the old 32-bit numbering that

Re: STORAGE OBTAIN doc inconsistency?

Peter, I always liked to see the macro, with the options and then examples. Maybe because I am a visual learner, but this is easier for me.. Just a thought... Scott On Thu, Jun 27, 2019 at 7:49 AM Peter Relson wrote: > I (to some extent "unfortunately") expect such inconsistency across the >

Re: STORAGE OBTAIN doc inconsistency?

I (to some extent "unfortunately") expect such inconsistency across the suite of books (imagine if we still supported both ESA/390 and z Architectures as options -- what "notation" would we use)? The effort to change every 32-bit-register bit reference to its "appropriate" 64-bit-register bit

Re: STORAGE OBTAIN doc inconsistency?

:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STORAGE OBTAIN doc inconsistency? On Wed, 26 Jun 2019 09:36:26 -0700, Charles Mills wrote: Is this worthy of an RFC or am I missing something? https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3 .ieaa400

Re: STORAGE OBTAIN doc inconsistency?

On Wed, 26 Jun 2019 at 13:21, Charles Mills wrote: > > Yep. A typo in my typo complaint. https://en.wikipedia.org/wiki/Muphry's_law Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: STORAGE OBTAIN doc inconsistency?

Yep. A typo in my typo complaint. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Wednesday, June 26, 2019 10:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STORAGE OBTAIN doc inconsistency? On Wed, 26

Re: STORAGE OBTAIN doc inconsistency?

On Wed, 26 Jun 2019 09:36:26 -0700, Charles Mills wrote: >Is this worthy of an RFC or am I missing something? > >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3 >.ieaa400/iea3a4_STORAGE_OBTAIN.htm says > >,SP=subpool number >Specifies the subpool number for the

Re: STORAGE OBTAIN doc inconsistency?

be described as being in bits 60-63, > right? > > Or am I confused? > > Charles > > Looks to me like an RFC is appropriate. I did a quick test: Obviously the subpool in R2 is moved from bits 60-63. Looks like somebody didn't update the old 32 bit register designatio

STORAGE OBTAIN doc inconsistency?

Is this worthy of an RFC or am I missing something? https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3 .ieaa400/iea3a4_STORAGE_OBTAIN.htm says ,SP=subpool number Specifies the subpool number for the storage. (See z/OS MVS Programming: Authorized Assembler Services Guide

Re: Another STORAGE OBTAIN question.

On 6/11/2019 4:49 AM, Peter Relson wrote: Whether or not a page is page-fixed, for example, is not part of the architectural definition. Right. We and (I assume) everyone else use PFTCADS for that. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA

Re: Another STORAGE OBTAIN question.

>You can't get much more "GUPI" than issuing the LPTEA instruction. LPTEA gets you the address, but is the page table entry itself PI? No. Anything beyond what is architecturally required to be in the PTE should not be considered part of the programming interface. Any program that chooses to

Re: Another STORAGE OBTAIN question.

On 6/10/2019 8:44 AM, John McKown wrote: Thanks for the pointer on where to look. I am trying to stay as GUPI as possible in this code. Haha! You can't get much more "GUPI" than issuing the LPTEA instruction. LOL -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El

Re: Another STORAGE OBTAIN question.

On Mon, Jun 10, 2019 at 10:28 AM Ed Jaffe wrote: > On 6/10/2019 5:47 AM, John McKown wrote: > > If I do a STORAGE OBTAIN,STARTBDY=20,LOC=(31,PAGEFRAMESIZE1M) is there > any > > way to see if z/OS did indeed use a 1 Meg frame size? I am trying to get > > (and FIX) a

Re: Another STORAGE OBTAIN question.

On 6/10/2019 5:47 AM, John McKown wrote: If I do a STORAGE OBTAIN,STARTBDY=20,LOC=(31,PAGEFRAMESIZE1M) is there any way to see if z/OS did indeed use a 1 Meg frame size? I am trying to get (and FIX) a contiguous area of real storage to use in communicating to z/VM via the DIAG X'08' (Virtual

Another STORAGE OBTAIN question.

If I do a STORAGE OBTAIN,STARTBDY=20,LOC=(31,PAGEFRAMESIZE1M) is there any way to see if z/OS did indeed use a 1 Meg frame size? I am trying to get (and FIX) a contiguous area of real storage to use in communicating to z/VM via the DIAG X'08' (Virtual Console Function). In order to work

Re: dumb STORAGE OBTAIN question.

had the need to take storage off line. > Similarly, in that case, you should use SYSEVENT TRANSWAP instead of > SYSEVENT DONTSWAP to become nonswappable. > Thanks. I had forgotten about that. > > Note that specifying FIX=LONG on STORAGE OBTAIN does not FIX the > storage. It is

Re: dumb STORAGE OBTAIN question.

FIX=LONG on STORAGE OBTAIN does not FIX the storage. It is simply a hint to RSM that you intend to do a PGSER FIX, LONG=YES later, so that if RSM backs the page before that, it will try to use a frame that won't require the page to be moved when you subsequently do FIX it. Jim Mulder z/OS

Re: dumb STORAGE OBTAIN question.

I am trying to avoid running key 0 or supervisor state to the extent possible Avoiding key 0 is nice. Avoiding supervisor state is less important. Unintended bad consequences of running with more privilege than absolutely needed are quite uncommon when the privilege is "supervisor state"

Re: dumb STORAGE OBTAIN question.

ly exclusive. > LOCHIH REG,VALUE yes, load max Yeah, jumps are cache-killers. LOCxxx is goodness. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, June 7, 2019 10:38 AM To: IBM-MAIN@LISTSERV.UA.EDU

Re: dumb STORAGE OBTAIN question.

IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: Friday, June 7, 2019 9:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: dumb STORAGE OBTAIN question. > > On Fri, Jun 7, 2019 at 11:24 AM Charles Mills wrote: > > > > Why is F

Re: dumb STORAGE OBTAIN question.

open in front of me, so perhaps I am off base.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, June 7, 2019 9:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: dumb STORAGE OBTAIN question. On Fri, Jun

Re: dumb STORAGE OBTAIN question.

; -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: Friday, June 7, 2019 9:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: dumb STORAGE OBTAIN question. > > On Fri, Jun 7, 2019 at 10:45 AM C

Re: dumb STORAGE OBTAIN question.

. I am doing the STORAGE OBTAIN,FIX=LONG to avoid doing the PGSER functions entirely. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: Friday, June 7, 2019 6:33 AM >

Re: dumb STORAGE OBTAIN question.

e STORAGE OBTAIN,FIX=LONG to avoid doing the PGSER functions entirely. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: Friday, June 7, 2019 6:33 AM > To: IBM-MAIN@LIS

Re: dumb STORAGE OBTAIN question.

, June 7, 2019 6:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: dumb STORAGE OBTAIN question. I know this is a dumb question in that the answer should obviously be "no problem". I am messing around with rewriting MVSCPMCD. It currently does PGFIX & PGFREE to fix and free the areas bein

STORAGE OBTAIN FIX= question.

Consider the following STORAGE OBTAIN request: STORAGE OBTAIN, SP=12, LV=8192, LOC=(31,PAGEFRAMESIZE1M), FIX=LONG, STARTBDY=12 * 4K BOUNDRY LR R6,R1 LRA R5,0(,R6) Will the real address gotten by the LRA

dumb STORAGE OBTAIN question.

iting the code to use PGSER instead, when it occurred to me that this is only 8K of real memory. So fixing it for the entire duration of the program really shouldn't be a problem. This led me to decide to use FIX=LONG on the STORAGE OBTAIN. After a short discussion with Tom (original author), wher

STORAGE OBTAIN with ADDR= does not set ALET???

SYSSTATE ASCENV=AR,AMODE64=YES STORAGE OBTAIN ,ALET=1,ADDR=(Rx) generates LGR Rx,R1 rather than the expected LAE Rx,0(,R1) Very annoying -- Binyamin Dissen <bdis...@dissensoftware.com> http://www.dissensoftware.com Director,

AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

>>Allocating 100 MB area, I found that the first page in the newly allocated >>area always seems to be backed by real storage upon return from STORAGE >>OBTAIN. >Before or after actual reference? I tought "upon return from STORAGE OBTAIN" would be clear. Anyway

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

On Wed, 2 Dec 2015 14:12:04 +, Blaicher, Christopher Y. wrote: >If you are doing anything other than a full page, or full pages, STORAGE >OBTAIN, >the system has to put a FQE element in the top of the page I've never seen an FQE located within the area containing the free space.

AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

> Do you specify BNDRY=PAGE? No, but from what the manual says I guess in my case the rule "8192 or more from pageable, private subpool" applies", so the storage is cleared. I was just expecting that the backing and clearing only takes place when I access the storage. > Are you using

AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

>If you are doing anything other than a full page, or full pages, STORAGE >OBTAIN, the system has to put a FQE element in the top of the page, and so it >would have to back the first virtual page with a real page. I'm allocating 10MiB, that is to work like fill page, I assume. IPCS

at Re: AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

from STORAGE OBTAIN. Before or after actual reference? I tought "upon return from STORAGE OBTAIN" would be clear. Anyway, no I have not referenced any byte within the new area. I found by looking at the area in a dump. -- Pete

Re: AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

Peter, > I'm allocating 10MiB, that is to work like fill page, I assume. IPCS tells me > the full page is X'00', so there is nothing written in that page. > As said in another response, it's pure curiosity. ask IPCS if the first page is really backed (ip rsmdata virtpage ra(x'page address'))

Re: AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

On 2 December 2015 at 13:38, nitz-ibm wrote: > ask IPCS if the first page is really backed (ip rsmdata virtpage ra(x'page > address')) and check the flags in the output. He already knows that *his* first page is backed; he's asking if this is always the case. Tony H.

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

> Allocating 100 MB area, I found that the first page in the newly > allocated area always seems to be backed by real storage upon return > from STORAGE OBTAIN. Is this true? Where is this documented? For requests where RSM is involved: If you specify BACK=ALL or BACK=NONE on the STOR

AW: Re: AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

what IPCS tells me. IPCS Browse to the address returned by STORAGE OBTAIN says that all bytes in the first page (x000 to xFFF) are X'00' and then it says "y000 to zFFF storage is unavailable". From this I conclude that the first page is backed. I'll double check with t

Re: at Re: AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

> It's been several years since I had a hand in that code (as the team > leader of the VSM development team for the first release of MVS back in > 1972-1974), but someone mentioned the existence of the FQE (Free Queue > Element). The FQE described the number of bytes that were free within >

Is first page always backed by real storage upon return from STORAGE OBTAIN?

Allocating 100 MB area, I found that the first page in the newly allocated area always seems to be backed by real storage upon return from STORAGE OBTAIN. Is this true? Where is this documented? -- Peter Hunkeler -- For IBM

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

Peter Hunkeler wrote: >Allocating 100 MB area, I found that the first page in the newly allocated >area always seems to be backed by real storage upon return from STORAGE >OBTAIN. Before or after actual reference? Say you execute some instructions after STORAGE OBTAIN, do yo

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

On Wed, 2 Dec 2015 14:06:28 +0100, Peter Hunkeler wrote: >Allocating 100 MB area, I found that the first page in the newly >allocated area always seems to be backed by real storage upon >return from STORAGE OBTAIN. Do you specify BNDRY=PAGE? Are you using z/OS 1.9 rules or z/OS 1.10 r

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

Not knowing the internals, but making some reasonable, I think, assumptions... If you are doing anything other than a full page, or full pages, STORAGE OBTAIN, the system has to put a FQE element in the top of the page, and so it would have to back the first virtual page with a real page. If you

Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?

In <7481950488678847.wa.m42tomibmmainyahoo@listserv.ua.edu>, on 12/02/2015 at 10:02 AM, Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> said: >I've never seen an FQE located within the area containing the free >space. Newby. From IBM System/3S0 Operating System: Programmer's

Re: Clarification Of STORAGE OBTAIN Parameters

Regarding Common Storage SP253 or SP241 SP253 is not common storage. It is fixed task-owned private (LSQA). STORAGE OBTAIN,LENGTH=(R0),LOC=31,BNDRY=DBLWD STORAGE OBTAIN,LENGTH=(R0),LOC=31,BNDRY=DBLWD,SP=0 What I found puzzling about the query is why the need for clarification

Clarification Of STORAGE OBTAIN Parameters

Looking for some clarification rearding STORAGE OBTAIN. . . Two Storage OBTAIN Macros STORAGE OBTAIN,LENGTH=(R0),LOC=31,BNDRY=DBLWD STORAGE OBTAIN,LENGTH=(R0),LOC=31,BNDRY=DBLWD,SP=0 My understanding is that If I omit the SP parameter (scenario 1), the system uses a default subpool of 0

Re: Clarification Of STORAGE OBTAIN Parameters

In b6c1eb4364c30e47950e0f68ef65f467cc6f0...@proditmailbox1.us.syncsort.com, on 03/22/2015 at 05:43 PM, Blaicher, Christopher Y. cblaic...@syncsort.com said: yes No. Only his first statment is correct. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see

Re: Storage Obtain .....

In 0a5001cf2857$e991b560$bcb52020$@mcn.org, on 02/12/2014 at 05:07 PM, Charles Mills charl...@mcn.org said: And then the OP would have cleared that dummy storage area passed back from OBTAIN and wondered how _that_ happened. If someone does a zero length GETMAIN and then tries to clear the

Re: Storage Obtain .....

In cae1xxdg-tbeuyzbzjna0wesezkvephtdr-utd3y+-lkogb1...@mail.gmail.com, on 02/13/2014 at 08:35 AM, John Gilmore jwgli...@gmail.com said: My personal view is that the original design decision was not a bad but a good one. I understand Jim Mulder's view. Caricatured only a little, it is that

Re: Storage Obtain .....

In 7320538829520852.wa.paulgboulderaim@listserv.ua.edu, on 02/12/2014 at 07:11 PM, Paul Gilmartin paulgboul...@aim.com said: The subpool thing oughtn't be checked unless one or more bytes are to be freed. There is no nonzero length associated with a subpool FREEMAIN. -- Shmuel

Checking Years( was - Re: Storage Obtain .....)

Lloyd Fuller wrote: Actually in some products quite a lot. Some other applications like your example: 1. Astronomy: (Calculating position/movements of space things from x year/month/day/etc to y year/etc...) 2. Statistics and Mathematics: Census processing of population of people, animals,

Re: Checking Years( was - Re: Storage Obtain .....)

elardus.engelbre...@sita.co.za To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, February 14, 2014 8:29 AM Subject: Checking Years( was - Re: Storage Obtain .) Lloyd Fuller wrote: Actually in some products quite a lot. Some other applications like your example: 1. Astronomy: (Calculating position

Re: Storage Obtain .....

either insert code after a STORAGE OBTAIN to test for return code = 0 and also storage address = 0 and then ABEND your own code (or do something else other than try to use the non-existent storage that you didn't really get), or else test for requested length = 0 before you do the STORAGE ABEND

Re: Storage Obtain .....

- Original Message - From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, February 12, 2014 7:11:00 PM Subject: Re: Storage Obtain . On Wed, 12 Feb 2014 18:39:14 -0500, Tony Harminc wrote: ..., freeing zero length is an instant disaster

Re: Storage Obtain .....

On Thu, 13 Feb 2014 12:10:54 +, DASDBILL2 wrote: If you are allocating such a data set with disposition=new, the request will fail if there is not at least one available (Format 0) DSCB in the VTOC which z/OS can change into a Format 1 DSCB in which to save all the information about your

Re: Storage Obtain .....

Two rather different situations need to be distinguished here. There is 1) the case of code that always executes a STORAGE OBTAIN (or GETMAIN) requesting zero bytes of storage, and there is 2) the case of code that executes a STORAGE OBTAIN (or GETMAIN) for a calculated number of bytes B, where

Re: Storage Obtain .....

In 035b01cf27fa$791cc6b0$6b565410$@TheThomasResidence.us, on 02/12/2014 at 07:58 AM, Jim Thomas j...@thethomasresidence.us said: Twice because the first is for R0,R1 and the second is for R12,R13. Isn't there just a single slot in the stack frame, so that the second overlays the first? --

Re: Storage Obtain .....

In 033a01cf2784$19dffdf0$4d9ff9d0$@TheThomasResidence.us, on 02/11/2014 at 05:50 PM, Jim Thomas j...@thethomasresidence.us said: MSTA R0 MSTA R12 What are you trying to do? The second MSTA replaces the data stored by the first. L R11,PSAAOLD-PSA

Re: Storage Obtain .....

unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: DASDBILL2 dasdbi...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 02/13/2014 06:50 AM Subject:Re: Storage Obtain . Sent by:IBM

Re: Storage Obtain .....

: DASDBILL2 dasdbi...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 02/13/2014 07:11 AM Subject:Re: Storage Obtain . Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU If you are allocating such a data set with disposition=new, the request will fail

Re: Storage Obtain .....

:Re: Storage Obtain . Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU These legacy constructs were known as model DSCBs, not model DCBs. I used them a few times long ago. Bill Fairchild - Original Message - From: Thomas H Puddicombe tpudd...@csc.com

Re: Storage Obtain .....

. From:   DASDBILL2 dasdbi...@comcast.net To:     IBM-MAIN@LISTSERV.UA.EDU Date:   02/13/2014 07:11 AM Subject:        Re: Storage Obtain . Sent by:        IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU If you are allocating such a data set with disposition=new, the request

Re: Storage Obtain .....

On Thu, 13 Feb 2014 09:42:32 -0500, Thomas H Puddicombe wrote: If your application didn't want any storage, why did it waste the system service's time by asking for none? It might be that the size is variable, as John G. suggested, and 0 is so unlikely that it is on average a greater waste of

Re: Storage Obtain .....

: STORAGE OBTAIN, : LENGTH=LCLDSCTL, : SP=244, : LOC=(31,31), : CAUB=CURRENT, : OWNER=HOME, : LINKAGE=BRANCH : LRR11,R1 : LRR0,R1

Re: Storage Obtain .....

My LTR after the STORAGE OBTAIN does not catch a failure. Your LTR after the STORAGE OBTAIN is not in the code you posted.   Bill Fairchild - Original Message - From: Jim Thomas j...@thethomasresidence.us To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, February 11, 2014 5:50:53 PM

Re: Storage Obtain .....

: Storage Obtain . BAKR R0,R0 MSTA R0 MSTA R12 MODESET MODE=SUP, KEY=ZERO L R11,PSAAOLD-PSA SETLOCK OBTAIN, ASCB=(11), TYPE=CML, MODE=UNCOND XRR4

Re: Storage Obtain .....

: Tuesday, February 11, 2014 8:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage Obtain . What is the MVCL trying to accomplish? Clear a number of bytes equal to the address of WORKAREA? Might you want the length of the OBTAIN and the length of the MVCL to be the same? Charles -Original

Re: Storage Obtain .....

, Jim Thomas -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Wednesday, February 12, 2014 3:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage Obtain . On Tue, 11 Feb 2014 17:50:53 -0600 Jim Thomas j

Re: Storage Obtain .....

Obtain . My LTR after the STORAGE OBTAIN does not catch a failure. Your LTR after the STORAGE OBTAIN is not in the code you posted. Bill Fairchild - Original Message - From: Jim Thomas j...@thethomasresidence.us To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, February 11, 2014 5:50:53 PM

Re: Storage Obtain .....

On 2/12/2014 8:50 AM, Jim Thomas wrote: XRR14,R14 XRR15,R15 L R1,=AL4(WORKAREA) MVCL R0,R14 Minor quibble - when the from length is zero, the from register is never referenced nor inspected, so the XR R14,R14 is extraneous. (If I had a

Re: Storage Obtain .....

[mailto:IBM-MAIN@LISTSERV.UA.EDU] On :Behalf Of Binyamin Dissen :Sent: Wednesday, February 12, 2014 3:55 AM :To: IBM-MAIN@LISTSERV.UA.EDU :Subject: Re: Storage Obtain . : :On Tue, 11 Feb 2014 17:50:53 -0600 Jim Thomas j...@thethomasresidence.us :wrote: : ::Given the below ... : :: BAKR R0,R0

Re: Storage Obtain .....

List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Postpischil Sent: Wednesday, February 12, 2014 15:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage Obtain . On 2/12/2014 8:50 AM, Jim Thomas wrote: XRR14,R14 XRR15,R15 L R1,=AL4(WORKAREA

Re: Storage Obtain .....

You didn't show the code involved with where you said it. You wrote that it was trying to chain backward / forward save area's. LENGTH=LCLDSCTL, what is this value? You wrote about an LTR after the STORAGE OBTAIN. You showed no such LTR. LRR11,R1 LR

Re: Storage Obtain .....

Gerhard, Thank you for pointing that out.. Kind Regards. Jim Thomas -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Postpischil Sent: Wednesday, February 12, 2014 8:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage

Re: Storage Obtain .....

[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Wednesday, February 12, 2014 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage Obtain . On Wed, 12 Feb 2014 07:58:13 -0600 Jim Thomas j...@thethomasresidence.us wrote: :Twice because the first is for R0,R1

Re: Storage Obtain .....

Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Wednesday, February 12, 2014 8:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage Obtain . You didn't show the code involved with where you said it. You wrote that it was trying to chain backward

Re: Storage Obtain .....

: Wednesday, February 12, 2014 9:40 AM Subject: Re: Storage Obtain . A similar one: How to determine a leap year: Q1:Is year a multiple of 4? If yes: Q2: is year a multiple of 100? If yes: Q3: is year a multiple of 400? If yes: it is a leapyear. (skipping the 'If No' branches). Q2 and Q3

Re: Storage Obtain .....

was 0. When a length of 0 is requested on GETMAIN or STORAGE OBTAIN, VSM treats this as a successful request, and returns an address of 0. In my opinion, this was a poor design choice, made long before my time, and I have seen it lead to diagnosis confusion like this several times over the years. I

Re: Storage Obtain .....

sizes/lengths of zero, would have met everyone's needs. It is, however, decades too late to change this behavior. It could have been changed for STORAGE obtain, but another such opportunity will not come along any time soon. John Gilmore, Ashland, MA 01721 - USA

Re: Storage Obtain .....

On 12 February 2014 14:21, Jim Mulder d10j...@us.ibm.com wrote: When a length of 0 is requested on GETMAIN or STORAGE OBTAIN, VSM treats this as a successful request, and returns an address of 0. In my opinion, this was a poor design choice, made long before my time, and I have seen it lead

Re: Storage Obtain .....

On 2/12/2014 6:06 PM, Tony Harminc wrote: I object far more to returning an address of 0 than to accepting a length of 0 on the request. To be sure, you are allowed to store no more than 0 bytes in your obtained area, so the 0 address sounds reasonable, but some instructions are allowed by the

Re: Storage Obtain .....

On 12 February 2014 18:22, Gerhard Postpischil gerha...@charter.net wrote: On 2/12/2014 6:06 PM, Tony Harminc wrote: I object far more to returning an address of 0 than to accepting a length of 0 on the request. To be sure, you are allowed to store no more than 0 bytes in your obtained area,

Re: Storage Obtain .....

On Wed, 12 Feb 2014 18:06:56 -0500, Tony Harminc wrote: ..., but some instructions are allowed by the architecture to recognize access exceptions in the case where no data is stored, e.g. STCM with a zero mask. Ouch! How does this work when the 4 bytes that might be accessed span a page

Re: Storage Obtain .....

Of Tony Harminc Sent: Wednesday, February 12, 2014 3:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage Obtain . On 12 February 2014 18:22, Gerhard Postpischil gerha...@charter.net wrote: On 2/12/2014 6:06 PM, Tony Harminc wrote: I object far more to returning an address of 0 than

Re: Storage Obtain .....

On Wed, 12 Feb 2014 18:39:14 -0500, Tony Harminc wrote: ..., freeing zero length is an instant disaster. That ought to be a no-op. You can't free 0 bytes at address 0? Now that is an inconsistency. Ah - the subpool thing on FREEMAIN. Is that also true for STORAGE RELEASE? The subpool thing

Re: Storage Obtain .....

On 12 February 2014 20:07, Charles Mills charl...@mcn.org wrote: Sure - it could assign one. It wouldn't have to be unique; just access-exception correct. And then the OP would have cleared that dummy storage area passed back from OBTAIN and wondered how _that_ happened. If you clear only

Re: Storage Obtain .....

it gets. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, February 12, 2014 6:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage Obtain . On 12 February 2014 20:07, Charles Mills charl

Re: Storage Obtain .....

, MODE=UNCOND XRR4,R4 L R7,PSAAOLD-PSA STORAGE OBTAIN, LENGTH=LCLDSCTL, SP=244, LOC=(31,31), CAUB=CURRENT, OWNER=HOME

Re: Storage Obtain .....

R7,PSAAOLD-PSA STORAGE OBTAIN, LENGTH=LCLDSCTL, SP=244, LOC=(31,31), CAUB=CURRENT, OWNER=HOME, LINKAGE=BRANCH LRR11,R1 LRR0,R1 XRR14,R14

Re: Storage Obtain .....

Of Jim Thomas Sent: Tuesday, February 11, 2014 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage Obtain . Hello ... Given the below ... BAKR R0,R0 MSTA R0 MSTA R12 MODESET MODE=SUP, KEY=ZERO L R11

  1   2   >