IEAVPSE parameter question

[Charles Mills]

For IEAVPSE, can pause_element_token and updated_pause_element_token both be
the same field? I don't see much use for the old pause_element_token after
IEAVPSE completes.

Charles

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

[Blaicher, Christopher Y.]

It was a while ago when I wrote a bunch of code using pause elements, but as I remember having those the same was not good. It may have been because I was using XFR.

PAUSE/RELEASE and XFER are great services, a bear to get setup and get right, but 4 years and probably trillions of uses later, and never had a problem.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234 | M: 512-627-3803
E: ***@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Wednesday, October 4, 2017 2:40 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: IEAVPSE parameter question

For IEAVPSE, can pause_element_token and updated_pause_element_token both be the same field? I don't see much use for the old pause_element_token after IEAVPSE completes.

Charles

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

________________________________



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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Steve Smith]

I can really only echo what Chris Blaicher said. Setting up multiple
DUs (TCBs and SRBs) with their own PEs, and managing the PETs can be a
mind-bending experience. I can't say why you can't use the same field
for the updated token, but I strongly suspect you cannot. It's been
more than a year since I wrote that code... while it works well, I've
forgotten some details.

That said, why not give it a try? You might wind up smarter than us.

sas

On Wed, Oct 4, 2017 at 3:15 PM, Blaicher, Christopher Y.

Post by Blaicher, Christopher Y.
It was a while ago when I wrote a bunch of code using pause elements, but as I remember having those the same was not good. It may have been because I was using XFR.
PAUSE/RELEASE and XFER are great services, a bear to get setup and get right, but 4 years and probably trillions of uses later, and never had a problem.

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

[Charles Mills]

I don't need any optional adventures in debugging. I have 16 bytes to spare; not sure I have much hair to spare.

I just thought that perhaps someone might say "yeah, we do it all the time," or that Peter or Jim might know.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Wednesday, October 4, 2017 12:36 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: IEAVPSE parameter question

I can really only echo what Chris Blaicher said. Setting up multiple DUs (TCBs and SRBs) with their own PEs, and managing the PETs can be a mind-bending experience. I can't say why you can't use the same field for the updated token, but I strongly suspect you cannot. It's been more than a year since I wrote that code... while it works well, I've forgotten some details.

That said, why not give it a try? You might wind up smarter than us.

sas

On Wed, Oct 4, 2017 at 3:15 PM, Blaicher, Christopher Y.

Post by Blaicher, Christopher Y.
It was a while ago when I wrote a bunch of code using pause elements, but as I remember having those the same was not good. It may have been because I was using XFR.
PAUSE/RELEASE and XFER are great services, a bear to get setup and get right, but 4 years and probably trillions of uses later, and never had a problem.

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

[Peter Relson]

It is fine with z/OS itself if you use the same field for both the input
token and the updated token.
Whether it works for you will depend on whether you care. Maybe your
recovery looks at something that wants to know if you still have the old
token vs the updated one.

The functionality of IEAVPSE (and the other similar "pause" targets, but
not "multi-pause" IEAVPME2 / IEA4PME2):
-- does a LM of the token into registers while running in your state and
key
-- PC's to change state (where the target uses the registers
and never looks at the parameter list)
-- does a LM into registers of the updated token
-- PR's back to your state and key
-- STM's to your updated-token

Peter Relson
z/OS Core Technology Design


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

[Charles Mills]

Thanks!

Should the doc contain a hint that performance would be improved if the
token were doubleword aligned? I looked and looked for such an assertion,
and finding none, took it that a character field is a character field is a
character field. Why not document as two doublewords, or at least point out
that doubleword alignment would be beneficial?

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, October 5, 2017 4:59 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: IEAVPSE parameter question

It is fine with z/OS itself if you use the same field for both the input
token and the updated token.
Whether it works for you will depend on whether you care. Maybe your
recovery looks at something that wants to know if you still have the old
token vs the updated one.

The functionality of IEAVPSE (and the other similar "pause" targets, but not
"multi-pause" IEAVPME2 / IEA4PME2):
-- does a LM of the token into registers while running in your state and key
-- PC's to change state (where the target uses the registers
and never looks at the parameter list)
-- does a LM into registers of the updated token
-- PR's back to your state and key
-- STM's to your updated-token

Peter Relson
z/OS Core Technology Design


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

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

[Steve Smith]

Some more memory paged in (to my brain). It's the Pause that returns
an updated PET, but while paused, something else needs that current
PET to Release you. I suspect the updated PET isn't stored until the
Release is done, but that's internal processing and so isn't
guaranteed (although the usual considerations apply).

If the Pause immediately overwrote the current PET, you'd be in limbo
forever, I guess, as the correct PET would be lost (currently, it
could easily be "guessed" (from what I've seen), but IBM could also
easily get more creative in how they're updated).

Frankly, I'm not sure what problem the PET-updating is supposed to
solve. It definitely makes the service harder to use, but maybe
that's the point ;-)

Re alignment: I suppose almost everything benefits from the best
alignment you can reasonably give it, all else equal. LM and STM
don't imply doubleword alignment is especially needed, although again,
that's internals, and subject to change.

Post by Charles Mills
Thanks!
Should the doc contain a hint that performance would be improved if the
token were doubleword aligned? I looked and looked for such an assertion,
and finding none, took it that a character field is a character field is a
character field. Why not document as two doublewords, or at least point out
that doubleword alignment would be beneficial?
Charles
-----Original Message-----
Behalf Of Peter Relson
Sent: Thursday, October 5, 2017 4:59 AM
Subject: Re: IEAVPSE parameter question
It is fine with z/OS itself if you use the same field for both the input
token and the updated token.
Whether it works for you will depend on whether you care. Maybe your
recovery looks at something that wants to know if you still have the old
token vs the updated one.
The functionality of IEAVPSE (and the other similar "pause" targets, but not
-- does a LM of the token into registers while running in your state and key
-- PC's to change state (where the target uses the registers
and never looks at the parameter list)
-- does a LM into registers of the updated token
-- PR's back to your state and key
-- STM's to your updated-token
Peter Relson
z/OS Core Technology Design

[Greg Dyck]

Post by Charles Mills
Should the doc contain a hint that performance would be improved if the
token were doubleword aligned? I looked and looked for such an assertion,
and finding none, took it that a character field is a character field is a
character field. Why not document as two doublewords, or at least point out
that doubleword alignment would be beneficial?

I doubt you would see a measurable difference in aligning the PET, give
the z/OS path length to perform a pause.

However, where you *publish* the PET for use with the release should be
on a double word boundary to ensure that double word consistency is
applied when updating and retrieving the value. Failure to do so has
been known to cause release failures in high stress situations,
depending on the how the pause/release protocols are implemented.

Regards,
Greg

[Mike Schwab]

The cache line size is 256 bytes. The performance should be higher if
the token doesn't cross that boundary.

Post by Charles Mills
Thanks!
Should the doc contain a hint that performance would be improved if the
token were doubleword aligned? I looked and looked for such an assertion,
and finding none, took it that a character field is a character field is a
character field. Why not document as two doublewords, or at least point out
that doubleword alignment would be beneficial?
Charles
-----Original Message-----
Behalf Of Peter Relson
Sent: Thursday, October 5, 2017 4:59 AM
Subject: Re: IEAVPSE parameter question
It is fine with z/OS itself if you use the same field for both the input
token and the updated token.
Whether it works for you will depend on whether you care. Maybe your
recovery looks at something that wants to know if you still have the old
token vs the updated one.
The functionality of IEAVPSE (and the other similar "pause" targets, but not
-- does a LM of the token into registers while running in your state and key
-- PC's to change state (where the target uses the registers
and never looks at the parameter list)
-- does a LM into registers of the updated token
-- PR's back to your state and key
-- STM's to your updated-token
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

[Greg Dyck]

Post by Charles Mills
For IEAVPSE, can pause_element_token and updated_pause_element_token both be
the same field? I don't see much use for the old pause_element_token after
IEAVPSE completes.

When IEAVPSE is called it is actually a glue routine which saves the
registers and then loads all of the input data, including the original
PET, into registers and then invokes the actual pause service. On
return from the actual pause service any return data, including the new
PET, are in registers and the glue routine stores them prior to
restoring the registers and returning the the caller. So there is no
reason you can't use the same area from a pause/release service point of
view.

That said, I would *not* recommend using the same area for a couple of
reasons. One is that if a failure occurs using the same area makes it
impossible to know if a new PET was stored prior to the failure or not.
The other is to avoid 'publishing' the new PET for use with a release
before you want it to be.

Regards,
Greg

[Peter Relson]

should the doc contain a hint that performance would be
improved if the token were doubleword aligned?

I say "no". Individual services are not going to document things that are
true everywhere.

Not aligning things might work but might perform worse (not necessarily
because of the instruction itself, but perhaps because the data might
cross cache lines).

If there is a functional requirement, then it would be documented.
Sometimes, for example, something must be on a doubleword boundary.
If there was a big performance difference between two options, that might
be discussed.

Peter Relson
z/OS Core Technology Design


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