On Friday, 10/07/2005 at 06:20 ZE2, Christian Borntraeger <[EMAIL PROTECTED]> wrote: > Currently vmcp has the following logic. If there was a Linux error (like > EACCESS) this error code is used. If there was no Linux problem, the return > code of CP is returned modulo 256 (Unix only allows to return 0-255), so > some error codes are used twice but in most cases you get the error code > of CP. > If you use the device node directly (see the code of the userspace > application) you always get VMs response code via ioctl. > > I know that the mapping of all possible errors to 256 numbers cannot be > perfect but thats the best solution I could think of. > > About the output to stderr, I make no promises, but I will have a look if we > can produce a meaningful message on stderr.
Let me build on Rob's point that the CP return code is *output* from the diag 8. I think a compromise is that the Linux error code be along the lines of 0 - CP recognized the command, no truncation of the response 1 - Unknown CP command (CP return code = 1) 2 - Output truncated 3 - Out of memory An appropriate message for rc 1, 2, and 3 to stderr would be great. An option like --rc would tell vmcp to prefix the output string with the CP return code, similar to DIAG() vs. DIAGRC() in CMS REXX. If SET EMSG ON is used, the return code is implicit in the message number, so people won't typically need the return code. A program, however, may need it. The 255 limit on the Linux error code makes it unsuitable to hold the CP return code. (I think comedian Jerry Clower once said that "a lyin' return code is worse than a lyin' coon dog!") Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
