IBM Mainframe Forum

This is question is prompted by reading an old (last October) post from steve-myers. He had been researching the actual operation of a packed -0 (minus zero).

This lead to me googling for a POP manual. On the way (I never actually got to the packed instructions) I looked at my old friend MVCL.

Now, a common Cobol Caution (sorry to mention that name in here ) that we used to get was "An MVCL has been generated for an item in the File or Linkage Section. The move will not be performed if it overlaps destructively".

Now, in the POP I looked at, it seems to say that MVCL cannot overlap at all. It says that the "initialisation" that you can do using MVC (set the first byte to the character to initialise to, then do the MVC offset by one byte, and as if by magic the whole field is set to the same amount) cannot be done with MVCL. Now in Cobol (sorry again) I used to do this all the time to initialise arrays without have to do the looping. And I'm sure that most of the tables I did it with were longer than 256 bytes. I'm sure it did the initialisation, as no abends. I'm sure (fairly, anyway) that the compiler didn't "spot" what I was doing and put a load of MVC's together to do it. I did this lots and lots.

So, has something changed? Or is the POP not quite clear? Does Cobol (maybe the wrong place to ask ) still give the same Caution?

Billyboyo is correct. MVCL cannot do something like -
However, it can do -
Since the source length in register 1 is 0, you don't have to set register 0 because it will never be used. What we're doing is using the ability of MVCL to insert a "fill" character if the target length is greater than the source length.

One might think the MVC would be slow, but the microcode understands this very common "trick" and optimizes it.

You will see something like this in my code quite often -

And I assume this is not in any way a "recent" innovation. Having received confirmation that the POP is correct , I am sore confused about what I used to do.

To make a simple example:



I tried this after an Assembler guy explained to me about the MVC method to set something to a repeating value. He was only talking about a simple repeating value, as in Steve's example, but, I thought, why not try it with something more complex?

It works (worked). But now, I have no idea how. It is definitely not using the "fill" character. It is longer than 256 bytes. I used it on arrays much more complicated that this one and never had a problem.

And I'm also not sure about the "destructive" overlap in the Caution I got from Cobol. Previously, I thought this to mean that the address being moved to was above the start of the address being moved from and overlapped (so that bytes which have previously been moved from the sourece would be changed). That sounded "destructive" to me. But now I am at a loss

Hello,

It works (worked). But now, I have no idea how.

Once upon a time multiple MVCs were generated (at least as i recall ). But this was more than 30 years ago. . . On a much older compiler. . .

Thanks. I've been thinking since the post, and I came to that conclusion as well. I guess it still works, due to "backwards compatability" if nothing else. It's just funny that I always assumed it was an MVCL, being "misguided" as well by the MVCL caution and never having checked what was generated by the compiler. Everywhere I used it I explained "exactly" what was happening, and I was wrong (I got the effect right, but the wrong instruction - never as stupid as when I'm being clever ).

The Caution is correct. It won't do the move if it overlaps. We lost a file header that way once, but that is another story.

I no longer have an early System/370 Principles of Operation, but I suspect MVCL hasn't changed; it will reject a destructive move and set condition code 3 even in 1971.

I looked up MVCL in a fairly current z/Architecture Principles of Operation. It really is kind of ridiculous. I think it extends over 4 or 5 pages. I lost the page count while cursing PDF (it just does not work well when there are 2 columns on a page) and paging down through the description.

Hello,

but I suspect MVCL hasn't changed; it will reject a destructive move and set condition code 3 even in 1971.

If the older compilers used a series of MVCs, how/why does this apply . . .

I think it was just a confirmation that it couldn't be MVCL that was generated, since it is unlikely to have changed "recently".

A POP I found by google, does explain the "destructive overlap" for me. Can't say as I actually understand it. Or, more accurately, I don't exactly understand what a "non-destructive overlap" is. The POP describes it negatively, at several levels. It would seem that the only overlap (for this usage of MVCL) is something like the leftmost byte of each operand can coincide and then it is non-destructive.

Also, how would you use this: the MVLC can "wrap around" from maximum storage address through 0 to whatever in low storage address?

So there is a non-destructive overlap, I'm just unsure as to how it would be used, or what it really consists of, to be honest.

The issue of address wraparound with MVCL has always been more theoretical than real.

In practice, it was not possible with non-virtual memory System/370 machines. None of them had anything close to 16 meg real storage, so any attempt to invoke address wraparound with MVCL on those machines would most likely terminate with the long forgotten S0C5 ABEND.

I don't recall for sure, but I believe even OS/VS2 Rel 1 defined virtual storage up to 16 meg, so, at least in theory, you could do address wraparound with that system.

I think early MVS systems defined storage the same way.

The virtual storage restructure with MVS/XA had the nucleus straddling the 16 meg virtual storage line. I think the same storage map is still in use with z/OS, so you should be able to do MVCL wrap around in the 24-bit address mode in both MVS/XA and later MVS releases, as well as z/OS.
Part of a nucleus map of a z/OS nucleus

I don't know if MVS/XA defined virtual storage up to 2 gig, so it may not be possible to do address wraparound in the 31-bit addressing mode in MVS/XA and later MVS systems, or with z/OS.

Similarly, I don't know if z/OS defines virtual storage up to the end og 64-bit virtual memory, so I don't know if address wrap around is possible in 64-bit addressing mode.

I wrote up a small program to try MVCL wrapping in the 24-bit addressing mode. The program did an MVCL 4,2. I printed before and after images of the registers, and got -

R2 = 00FFFF80 R3 = 00000100 R4 = 0002AC30 R5 = 00000100
R2 = 00000080 R3 = 00000000 R4 = 0002AD30 R5 = 00000000

What I find interesting is reg 2 didn't just keep bumping; I would have expected 01000080.