I would normally use XC to clear a storage field to binary zero. I think current IBM Z hardware typically recognizes XC of a field with itself as a special case meaning "set storage to zero", so it does not need to fetch the operand at all, and it certainly doesn't need to fetch it twice.
As far as I know, the architecture does not yet guarantee that this will work for a field which is being updated concurrently by other processes, as there is a theoretical possibility that another process could update the field between XC fetching it for the first operand access and the second operand access. However, that's a very special case and I wouldn't worry about it, and I suspect that it probably can't even happen with current IBM hardware. My own assembler structured programming environment (from around 1988) allowed an assembler procedure to have an area containing initialised automatic local variables, including for example MF=L macro parameters. This was defined as a LOCTR which was in a separate CSECT but was copied to automatic storage by procedure prolog code (using one or more MVCs depending on total length), then a dependent USING was set up to base the original LOCTR on the dynamic copy. So multiple variables could all be initialised using a single MVC. With the USING limit enhancements that I implemented a few years ago, this could now be done without even needing a separate CSECT (which was tricky at the time because of needing a unique 8-character external name). Jonathan Scott
