IARV64 REQUEST=DISCARDDATA Question

[Mike Shaw]

Based on the IARV64 doc in the z/OS Assembler Services Guide and in the
z/OS Assembler Services Reference, an IARV64 REQUEST=GETSTOR should be
followed by an IARV64 REQUEST=DISCARDDATA,CLEAR=YES in order to be certain
that the obtained memory object contains no residual data.

The doc does not say what that memory object's pages contain just after
IARV64 REQUEST=GETSTOR is issued. Does anyone on the list know?

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

[Ed Jaffe]

On 9/26/2023 2:27 PM, Mike Shaw wrote:
> The doc does not say what that memory object's pages contain just after
> IARV64 REQUEST=GETSTOR is issued. Does anyone on the list know?

Assuming you're referring to pageable memory, the object is completely
empty waiting for you to reference something.

There are no "pages" yet.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/


--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

[Binyamin Dissen]

As this function can never return partial pages, it will always be zero upon
first use.

On Tue, 26 Sep 2023 17:27:30 -0400 Mike Shaw <techs...@QUICKREF.COM> wrote:

:>Based on the IARV64 doc in the z/OS Assembler Services Guide and in the

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

[Mike Shaw]

Thanks Binyamin and Ed. Clear explanations.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

On Wed, Sep 27, 2023 at 3:23 AM Binyamin Dissen <bdi...@dissensoftware.com>
wrote:

[Peter Relson]

Mike Shaw wrote
<snip>

The doc does not say what that memory object's pages contain just after
IARV64 REQUEST=GETSTOR is issued.

</snip>

The "doc" actually does say so. But it's not surprising you didn't notice it, because it's in the "guide" (and not in a section specifically for IARV64) rather than in the "reference" for IARV64.

The macro has "The initial value of storage within a memory object is binary zero."
The assembler services guide has "IARV64 GETSTOR service creates memory objects; storage is cleared to zeros".

We will look into updating the reference's GETSTOR function to have the same information.

Peter Relson
z/OS Core Technology Design

[Mike Shaw]

Thank you Peter.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

[Peter Relson]

<snip>

As this function can never return partial pages, it will always be zero upon

first use.

</snip>

To be picky, the "As" phrase of this is not quite true. IARV64 does not, but could return a partial page, such as a partial 2G page for a smaller request when the conditions were right (but the implementation does not do that). The conclusion is, similarly, not quite true. It does happen always to be zero. A different (likely felt to be insecure) implementation that did not clear pages upon new usage when those pages had been used, but are no longer in use, would not guarantee "always be zero".

In any case, that's why we agree that it would be nice to document.