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.
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-operandconsistency rules are the same
as for the MOVE
(MVC) instruction
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? 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?
Kind regards,
Erik Janssen.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
