I apparently stopped reading before the 'limited to 256' statement in the original post and incorrectly assumed it covered long moves as well, since you mentioned MVCL* type instructions (of course they cover all lengths). I see it being a lot more useful if it had long capabilities.
-----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Tom Harper Sent: Friday, April 15, 2022 2:19 PM To: [email protected] Subject: Re: Next instruction needed Caution! This message was sent from outside your organization. I think that is unnecessary because the proposal is only for one to 256 bytes so no need to make it interruptible. If you want to use for longer areas, use a move long. Many instructions have been added over the years for small items. This would find significant use as soon as the instruction would become available without dual pathing. The cost to implement should be minimal. Sent from my iPhone > On Apr 15, 2022, at 1:51 PM, Paul Gilmartin > <[email protected]> wrote: > > On Apr 15, 2022, at 11:34:40, Tom Harper wrote: >> >> If it was interrupted, where would the hardware restart? The instruction >> itself cannot be changed. >> > Make it an RFE. Support it with a business case, that it would > provide added value to end users inducing them to spend more on IBM > equipment than the engineering cost of developing the new hardware. > > -- > gil -------------------------------------------------------------------------------- This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
