John Summerfied writes:
>so how's the VM return code getting back to a script? As I recall that
>was one of the problems raised early in the thread.
I haven't been paying close attention to this thread, so I may have missed
someone else suggesting this or be repeating a lot, but... It seems to me
that all this talk of lockfiles under /sys is way too complex. We're
trying to make a sysfs (or procfs) interface to CP so that it can be
scripted, right? But the Linux way of doing this would be to have a
user-space program that handles all the complexity of dealing with the
kernel and presents a (simpler) interface that scripts and other programs
can use.
So why don't we do this: have one file in sysfs that provides a
communication path to the kernel module that actually does the DIAG. A
user-space program can open it and do ioctl(2) calls that specify the DIAG
function and provide the data. The ioctl() calls are synchronous, so we
know that we're always going to get back the results of our request; no
locking is needed.
We write a user-space program that accepts the data to be passed to DIAG on
its command line or standard input. Its exit code indicates if the request
was processed successfully or not (the Linux return code). If the DIAG
function succeeded, it writes the results to the standard output. If the
DIAG function failed, it writes the CP return code to its standard error
stream along with any message(s) it got. That's the default behaviour. It
also provides an option which causes the CP return code to be written to a
specified file descriptor. This lets a program obtain the CP return code
without interfering with output that users might want to see, and doesn't
require grep.
As an example, a shell script could use this code to run a DIAG 0x08
command to do a CP QUERY DASD
cpcmd -f5 -c 08 "QUERY DASD" 5>/tmp/diag.$$
if [ $? -ne 0 ]
then read CPrc < /tmp/diag.$$
case "$CPrc" in
... # Handle CP return codes.
esac
fi
Notice that this only uses shell built-in commands to deal with the error
handling; the only external process that is invoked is the user-space
interface program. (Note also that a well-written script would have a trap
to clean up that temporary file.)
I'm a Linux guy, just learning z/VM, so this proposal is entirely from the
Linux point of view. It's the kind of shell-level interface I'd expect to
have available. The only unusual thing is the CP return code, and this
handles it in a useful way. If we ever want other ways of getting at it,
we can just add more options.
I think this addresses all the points people have been making. So, what am
I missing? Flame away...
- MacK.
-----
Edmund R. MacKenty
Software Architect
Rocket Software, Inc.
Newton, MA USA
----------------------------------------------------------------------
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
