Classification: Confidential I always thought the MVI, MVC method was very inefficient. If I had storage available I would always define a constant of the required length and move it.
-----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Tony Harminc Sent: Friday, July 26, 2024 2:31 PM To: [email protected] Subject: Re: Does MVCDK move 'per byte' like MVC? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] 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 ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
