Boy, it has been many years since someone reported an issue with XFRMMO!
Unfortunately, being such an old routine, the internal error logging hasn't been upgraded to the standard used in many of the newer routines (whereby nearly any unexpected error would be reported to the ashlog.log file).
The error 3 only means that an error occurred but it was not "link error" (1) or "file full" (2).
Looking at the code, the XFRMMO operation is broken down into the following sub-operations, each of which returns an internal success/failure code:
1. Load the source memo
2. Save the destination memo
3. (optional) Delete the source memo
Each of those operations in turn rely on lower level disk reads and writes, each of which will return an error code on failure (seek error, privilege error, in use error, device error, etc.)
On the read side, it looks like any such errors would result in a screen message (possibly overlooked). But on the write side, it looks like you just get the failure code.
There are also locking operations, which generally result in screen messages, but perhaps those aren't obvious either.
If you are on 5.1.1134+, you can set the XTREE trace flag (XTREE uses INMEMO when in text mode) to log various unexpected conditions (mostly locking related). You can also set the LOCKS trace to log further details about the locking. And in case you don't know which record is causing the problem, you can set the XLOCK trace to see the parameters being passed to the XCALL XFRMMO that fails.
Once you know what starting link you're trying to copy from, you can easily determine if the issue is on the read or the write side by using a utility such as DMPMMO (which prompts for a starting link and then loads/displays it).
Beyond that, in order to find out the actual file system error code, it looks like I would need to upgrade the error handling/tracing within that routine, which I'm willing to do (but it would mean that you would have to update to the latest version).
