On Fri, 26 Jul 2024 at 14:44, Erik Janssen <
[email protected]> wrote:
> Hello All,
>
> I had this code in a user SVC:
> MVI DATA,X'40' BLANK OUT DATA
> MVC DATA+1(254),DATA
>
> As far as I'm aware this is a well known principle to clear a data area,
> it is explained in the POP under MVC that you can propagate a byte this way.
>
> Since the DATA area is provided by the caller of the user SVC I
> implemented this code to do the same with MVCDK to make sure the protection
> key of the storage area matches the callers key (in R1). The 'spatie' field
> is defined as 'SPATIE DC CL1' '
>
> LHI R0,L'SPATIE-1
> MVCDK DATA,SPATIE BLANK OUT DATA
> LHI R0,L'DATA-2 MOVE 254 CHARS
> MVCDK DATA+1,DATA
>
> I had assumed that MVCDK would also propagate a byte this way and tested
> this on a ZD&T machine and that seemed to work ok.
>
No - MVC has a specific exemption ("When the operands overlap, the result
is obtained as if the operands were processed one byte at a time and each
result byte were stored immediately after fetching the necessary operand
byte.") from the general destructive overlap rule, and MVCDK doesn't.
> Now that we have this code on our test lpar on a z16 machine I see that it
> will shift the full contents of the DATA field one position to the right.
> This causes residual data from the previous call to appear.
>
> The POP says under MVCDK:
> Each of the operands is processed left to right.
> When the operands overlap destructively in real storage, the results in
> the first-operand location are unpredictable.
>
Except for this unpredictability in the case of destructive overlap, the
> storage-operand consistency rules are the same as for the MOVE (MVC)
> instruction
>
Definition for this case: "Destructive overlap is said to exist when the
result location is used as a source after the result has been stored,
assuming processing to be performed one byte at a time." Alternatively
(but not in conflict): "Operands are said to overlap destructively when the
first-operand real location is used as a source after data has been moved
into it."
Did I encounter that unpredictability the POP is talking about? Is it
> possible that on a ZD&T MVCDK works byte for byte like MVC, while on real
> hardware MVCDK works more like a MVCL moving all the bytes at once?
It's entirely possible. When the POP says "unpredictable" it means a very
specific kind of unpredictable, and any implementation of the architecture
is free to do anything allowed within the "unpredictable" possibilities.
> And, if MVCDK does not work a byte at a time, what would be a correct
> solution for this? Copy a byte at a time with MVCDK in a loop, like the
> programming example in the POP with the MVCSK instruction?
>
That should work, though not with great efficiency. Why not just have a
constant containing 256 (or so) blanks, and MVCDK from that? It's a
tradeoff between CPU time and storage, and in the past storage always won,
but these days 256 bytes is generally nothing. You can even put it on a
cache line boundary for extra zip...
Tony H.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
