Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Edmund R. MacKenty wrote: Rob van der Heij writes: On 10/13/05, Alan Altmark <[EMAIL PROTECTED]> wrote: to stdout itself. (I do this all the time in REXX execs - handle the return codes I can deal with myself and dump to the console if I don't recognize it. Is Linux so different?) Yep. You're missing CMS Pipelines and maybe REXX stems. As the examples show you must redirect output to a temporary file (and deal with the fact that some commands produce different output when redirected) and then read the file back in to see what was there.That's not elegant. My `vmcprc` was as close as I could get. Actually, you can capture the output of any command into a shell variable, While that is true, as I've popinted out before, hiding messages from suers is evil. Sooner or later, something will break, and the user will need information being hidden. That is why I suggested a different file descriptor, and Alan was agreeing that, with a small proviso, that's okay. Way back, I showed how that "different file descriptor" can be created and accessed in shell scripts. The vmcprc example involved sending stdout to an environment variable, and this I think is *bad*. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Martin Schwidefsky wrote: On Thu, 2005-10-13 at 08:58 -0700, Fargusson.Alan wrote: But it isn't a device is it? It isn't a filesystem either. It looks like sysfs is the best fit even if it isn't really the right place for it. Actually a architecture specific system call might be the right thing to do, but I suspect it would be hard to get it implemented. It's not a device, it's not a filesystem, it is a service that lets you call a hypervisor function (z/VM AND LPAR by the way). Dependent on the diagnose code it has to do memory copies. That screams for a system call and they are not harder to implement then e.g. an ioctl. Doing the diagnose via a system call would have the benefit that you don't have to open some device first. Even better you don't need any special device node, /proc or /sys entry at all. So if we decide that we want such a It's very like controlling the fan on my laptop, or CPU frequencies, or loading firmware, and those functions are implemented in procfs/sysfs, and are accessible from the shell. beast then we can as well implement it as a system call. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Oct 14, 2005, at 4:03 PM, Alan Altmark wrote: On Friday, 10/14/2005 at 03:37 EST, Adam Thornton <[EMAIL PROTECTED]> wrote: Doobie != Do-Bee Just saying. Ok. Fine. (cough) (cough) If you're coughing it's probably time to trade in the doobies for the cough syrup. Emphysema is no laughing matter. Adam -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Friday, 10/14/2005 at 03:37 EST, Adam Thornton <[EMAIL PROTECTED]> wrote: > On Oct 14, 2005, at 3:34 PM, Alan Altmark wrote: > > A command line user who runs with SET EMSG ON (as all Good Doobies > > will) does not need to see the CP command return code since it will be > > part of any message header. > > Doobie != Do-Bee > > Just saying. Ok. Fine. (cough) (cough) Alan -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Oct 14, 2005, at 3:34 PM, Alan Altmark wrote: A command line user who runs with SET EMSG ON (as all Good Doobies will) does not need to see the CP command return code since it will be part of any message header. Doobie != Do-Bee Just saying. Adam -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Friday, 10/14/2005 at 08:07 ZE8, John Summerfied <[EMAIL PROTECTED]> wrote: > I have suggested several times writing the return code to a separate > descriptor - I nominated 4 for no particular reason, but I don't recall > any response to that. The writing can be unconditional; a script-writer > can use it, a commandline user ignore it. As long as the command handles the diag8 error codes in a useful way, this works. A command line user who runs with SET EMSG ON (as all Good Doobies will) does not need to see the CP command return code since it will be part of any message header. The only exception is CP RC=1 (the diag completes ok, but the command wasn't recognized). This case plus all error returns from the diag itself need to result in messages sent to stderr. 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Edmund R. MacKenty wrote: 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 Have a look at firmware.agent on peecee linux. It's a script loads firmware, and the kernel provides some interlock. 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 Does one do ioctl() files on stuff in sysfs? (I'm ignorant, I know that). If we can agree on an approach that can be done entirely in scripts, that will be far easier, or so I think, for people to use. As I've said before, I can start and stop the fan in my Toshiba laptop entirely from the commandline. This is easy to use. Writing a C program isn't, I'm a pretty feeble C programmer. 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 Some 15 or so years ago I had a corneal graft in my left eye. Medically, it was a great success and they eye is in no danger of rupturing. However, I the user have a different idea: they eye focusses at about two centimetres and I really cannot see anything useful with it. It was way better before. In the Linux context, I expect that success would mean the exchange with the host environment succeeded, but doesn't say anything about the CP outcome of the transaction. 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. I have suggested several times writing the return code to a separate descriptor - I nominated 4 for no particular reason, but I don't recall any response to that. The writing can be unconditional; a script-writer can use it, a commandline user ignore it. 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 ] thenread 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.) and use mktemp, but that's a nit for the example. 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. Take the time to read the history, it's quicker than having us recap (and exposing our biases again). -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Edmund R. MacKenty wrote: Fargusson.Alan writes: I think procfs is definitely the wrong place. It should have process specific stuff only. I even think that new procfs entries will be rejected in the mainline kernel. I know there is some stuff in procfs right now that isn't process specific, but I have also seen patches rejected because they put stuff in procfs that was not process specific. Usually these ended up in sysfs. True, but this tool has to run under 2.4.* kernels too, where there is no sysfs. In that case, it should go in procfs. For 2.6.* and future kernels, it does belong in sysfs. We've got to support the old stuff too. Make the tool look in both places (or allow it to be told). firmware.agent checks and can use procfs or sysfs. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Fargusson.Alan writes: >Doesn't cpint run on 2.4 right now? > >We should not break anything that runs on 2.4, but we don't need to back >port new tools to 2.4. I wish I had been reading this thread early on; I thought we were talking about a cpint enhancement or replacement. It sure would be nice to have one tool that works under any kernel, so other programs don't have to decide which interface to use based on the kernel version. I think that any kernel differences should be hidden inside of whatever user-space tool we come up with, so that programs and scripts that use it don't have to deal with those differences. - 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Rob van der Heij writes:
>On 10/13/05, Alan Altmark <[EMAIL PROTECTED]> wrote:
>
>> to stdout itself. (I do this all the time in REXX execs - handle the
>> return codes I can deal with myself and dump to the console if I don't
>> recognize it. Is Linux so different?)
>
>Yep. You're missing CMS Pipelines and maybe REXX stems. As the
>examples show you must redirect output to a temporary file (and deal
>with the fact that some commands produce different output when
>redirected) and then read the file back in to see what was
>there.That's not elegant. My `vmcprc` was as close as I could get.
Actually, you can capture the output of any command into a shell variable,
you don't need to use the filesystem at all. With bash, you can then do
pattern matches on the variable value, so you don't need grep either. It
can all be done with shell built-ins:
Output="`vmcp ...`"
LinuxErr=$?
CPerr="${Output#CP Error: }"
Assuming that the output of the command contains a line that begins with
the string "CP Error: " followed by the CP error code, the above gives you
both the Linux and CP return codes. I still would like to see an option
that writes just the CP return code to a specified file descriptor, though.
- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Thu, 2005-10-13 at 08:58 -0700, Fargusson.Alan wrote: > But it isn't a device is it? It isn't a filesystem either. > > It looks like sysfs is the best fit even if it isn't really the right > place for it. Actually a architecture specific system call might be the > right thing to do, but I suspect it would be hard to get it implemented. It's not a device, it's not a filesystem, it is a service that lets you call a hypervisor function (z/VM AND LPAR by the way). Dependent on the diagnose code it has to do memory copies. That screams for a system call and they are not harder to implement then e.g. an ioctl. Doing the diagnose via a system call would have the benefit that you don't have to open some device first. Even better you don't need any special device node, /proc or /sys entry at all. So if we decide that we want such a beast then we can as well implement it as a system call. -- blue skies, Martin Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland Entwicklung GmbH -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Carsten Otte wrote: John Summerfied wrote: The kernel implementation can make it easy, or it can make it hard. The kernel support for loading blobs of firmware into devices makes it easy to do in scripts; the use of devices and ioctls make it hard. As pointed out before, if userspace locks are used to lock a kernel resource this is either broken (deadlock when program crashed after the lock was aquired) or racy (no locking, or timeout scheme). The ease of use from a shell script or whatever program language is a pure userspace problem and should be solved there - not in the OS kernel. Shell scripts can call programs that handle the details for them. I have already suggested how the kernel can provide a means for shell scripts to do the lock, and provide a timeout in case of a crash. I don't recall anyone poking holes in the suggestion; someone else suggested something similar (but without the timeout and without my identifying token). -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On 10/13/05, Alan Altmark <[EMAIL PROTECTED]> wrote: > to stdout itself. (I do this all the time in REXX execs - handle the > return codes I can deal with myself and dump to the console if I don't > recognize it. Is Linux so different?) Yep. You're missing CMS Pipelines and maybe REXX stems. As the examples show you must redirect output to a temporary file (and deal with the fact that some commands produce different output when redirected) and then read the file back in to see what was there.That's not elegant. My `vmcprc` was as close as I could get. Rob -- Rob van der Heij rvdheij @ gmail.com -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Doesn't cpint run on 2.4 right now? We should not break anything that runs on 2.4, but we don't need to back port new tools to 2.4. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Edmund R. MacKenty Sent: Thursday, October 13, 2005 12:48 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks Fargusson.Alan writes: >I think procfs is definitely the wrong place. It should have process >specific stuff only. I even think that new procfs entries will be >rejected in the mainline kernel. > >I know there is some stuff in procfs right now that isn't process >specific, but I have also seen patches rejected because they put stuff in >procfs that was not process specific. Usually these ended up in sysfs. True, but this tool has to run under 2.4.* kernels too, where there is no sysfs. In that case, it should go in procfs. For 2.6.* and future kernels, it does belong in sysfs. We've got to support the old stuff too. - 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 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Fargusson.Alan writes: >I think procfs is definitely the wrong place. It should have process >specific stuff only. I even think that new procfs entries will be >rejected in the mainline kernel. > >I know there is some stuff in procfs right now that isn't process >specific, but I have also seen patches rejected because they put stuff in >procfs that was not process specific. Usually these ended up in sysfs. True, but this tool has to run under 2.4.* kernels too, where there is no sysfs. In that case, it should go in procfs. For 2.6.* and future kernels, it does belong in sysfs. We've got to support the old stuff too. - 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
I think procfs is definitely the wrong place. It should have process specific stuff only. I even think that new procfs entries will be rejected in the mainline kernel. I know there is some stuff in procfs right now that isn't process specific, but I have also seen patches rejected because they put stuff in procfs that was not process specific. Usually these ended up in sysfs. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Edmund R. MacKenty Sent: Thursday, October 13, 2005 10:06 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks Fargusson.Alan writes: >But it isn't a device is it? It isn't a filesystem either. > >It looks like sysfs is the best fit even if it isn't really the right >place for it. Actually a architecture specific system call might be the >right thing to do, but I suspect it would be hard to get it implemented. Yeah, sysfs is supposed to expose devices and other kernel objects, not provide arbitrary interfaces to kernel modules. But one could argue that CP (or DIAG) is the "object" we're communicating with via an entry in sysfs (or procfs). We're exposing a way to communicate with that object with an entry in the sysfs. Is that too much of a stretch? - 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 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Fargusson.Alan writes: >But it isn't a device is it? It isn't a filesystem either. > >It looks like sysfs is the best fit even if it isn't really the right >place for it. Actually a architecture specific system call might be the >right thing to do, but I suspect it would be hard to get it implemented. Yeah, sysfs is supposed to expose devices and other kernel objects, not provide arbitrary interfaces to kernel modules. But one could argue that CP (or DIAG) is the "object" we're communicating with via an entry in sysfs (or procfs). We're exposing a way to communicate with that object with an entry in the sysfs. Is that too much of a stretch? - 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Thu, 13 Oct 2005, John Summerfied wrote: > Whatever is done, it should be consistent with other virtual > environments such as XEN and VMWARE. Amen! Let me again invite all interested persons to join us on the FreeVM-L discussion list. The very purpose of that list is to drive consistency among the various hypervisors (whether "para" or full). Sign up at your nearest LISTSERV robot. -- R; -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Wed, 12 Oct 2005, Christian Borntraeger wrote: > I think, that the command/return code query should be as > atomic as possible to prevent concurrent vmcp calls from > disturbing each other. ... We are in violent agreement. We may have different approaches to resolving what happens when a second process needs to access the atom while a first has not yet finished. I only meant to illustrate one or two ways to resolve that, not to say that my solution was best, or even elegant. -- R; -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Fargusson.Alan wrote: > Actually a architecture specific system call might be the right thing > to do, but I suspect it would be hard to get it implemented. Full agree. Also for to the "but..". -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
But it isn't a device is it? It isn't a filesystem either. It looks like sysfs is the best fit even if it isn't really the right place for it. Actually a architecture specific system call might be the right thing to do, but I suspect it would be hard to get it implemented. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Carsten Otte Sent: Thursday, October 13, 2005 8:40 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks Edmund R. MacKenty wrote: > I think this addresses all the points people have been making. So, what am > I missing? Flame away... So here comes my part of the flame: It is exactly the right thing to do conceptually, but sysfs isn't the right place for it. I'd rather prefer a device or maybe a seperate filesystem. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Edmund R. MacKenty wrote: > I think this addresses all the points people have been making. So, what am > I missing? Flame away... So here comes my part of the flame: It is exactly the right thing to do conceptually, but sysfs isn't the right place for it. I'd rather prefer a device or maybe a seperate filesystem. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
John Summerfied wrote: > The kernel implementation can make it easy, or it can make it hard. > > The kernel support for loading blobs of firmware into devices makes it > easy to do in scripts; the use of devices and ioctls make it hard. As pointed out before, if userspace locks are used to lock a kernel resource this is either broken (deadlock when program crashed after the lock was aquired) or racy (no locking, or timeout scheme). The ease of use from a shell script or whatever program language is a pure userspace problem and should be solved there - not in the OS kernel. Shell scripts can call programs that handle the details for them. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
John Summerfied writes: >Most times, when I "grep" the output I do so in a pipe. I used the quote >because I also often use awk. > >The result of grepping is usually that most of the output is discarded. >This illustrates my point without boring with the detail: >[EMAIL PROTECTED] ~]$ locate ~ | wc -l >114109 >[EMAIL PROTECTED] ~]$ locate ~ | grep A | wc -l >3479 >[EMAIL PROTECTED] ~]$ > >For those who don't know what's going on: >The tilde is replaced with the name of my home directory, so the locate >command produces a list of files in my home directory and its >subdirectories. wc as used just prints the number of lines. Another problem with this approach is that the return code of the locate command is lost. This is because the shell defines the return code of a pipe to be the return code of the last simple-command within the pipe. So if we "grep" output like this, we can't tell if the command we're interested in succeeded or not. - 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
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 ] thenread 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Carsten Otte wrote: John Summerfied wrote: No it will not _if_ the lock is done where it belongs: system kernel, not flock or sysfs or whatever vehicle that locks in userspace. That's what vmcp does, and that's what would work for other diagnoses in a similar way. 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. The return code delivery to the script is a pure userspace problem. My comment is about the interface to the system kernel. The kernel implementation can make it easy, or it can make it hard. The kernel support for loading blobs of firmware into devices makes it easy to do in scripts; the use of devices and ioctls make it hard. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
John Summerfied wrote: >> No it will not _if_ the lock is done where it belongs: system kernel, not >> flock or sysfs or whatever vehicle that locks in userspace. >> That's what vmcp does, and that's what would work for other diagnoses in >> a similar way. > > > 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. The return code delivery to the script is a pure userspace problem. My comment is about the interface to the system kernel. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Alan Altmark wrote: On Thursday, 10/13/2005 at 08:53 ZE8, John Summerfied <[EMAIL PROTECTED]> wrote: Are people happy that they will not be able to use these functions from the commandline or from a shell script? The earlier suggestion (not mine) was to do it in a posix shell. But it doesn't make sense to have all of the diagnose functions available from the command line anyway. I won't ague against that, but I think some that have been highlighted might be used so. > And if a script greps stdout, and it decides that the user should see the output, it can write the output back to stdout itself. (I do this all the time in REXX execs - handle the return codes I can deal with myself and dump to the console if I don't recognize it. Is Linux so different?) Most times, when I "grep" the output I do so in a pipe. I used the quote because I also often use awk. The result of grepping is usually that most of the output is discarded. This illustrates my point without boring with the detail: [EMAIL PROTECTED] ~]$ locate ~ | wc -l 114109 [EMAIL PROTECTED] ~]$ locate ~ | grep A | wc -l 3479 [EMAIL PROTECTED] ~]$ For those who don't know what's going on: The tilde is replaced with the name of my home directory, so the locate command produces a list of files in my home directory and its subdirectories. wc as used just prints the number of lines. The grep command eliminates all those files without an "A" in the path name, so there are around 111000 files removed from the report. I'm betting that many people will not take the added steps needed to ensure users actually see what the progam said. What they need to do us domething like this: vmcp | tee /tmp/reportfile or vmcp 2>/tmp/reportfile cat /tmp/reportfile and then grep the report file. As you can see, it's more involved. For my own purposes I'm often prepared to discard most of the report, but it's not always appropriate and it looks to me like an accident waiting to inconvenience. That is why I proposed writing the return code to a separate file (descriptor). Someone using it from the commandline can see the results which, presumably, describe what happened and ignore the descriptor (the write will simply fail) while a script-writer can capture it by redirection, possibly as I described earlier. vmcp is a Linux command interface to a CP command interface (diag 8). The rest of the diagnose functions are programming interfaces of one sort or another. This isn't some new limitation being proposed; this is inherent in the limitations of the [e.g. bash] shell scripting language, is it not? I can certainly envision some userspace apps in the package that do common things with those diags, making them useful in a command environment, but I don't think we need a command interface to the diags themselves. Integrate some into /proc and others into /dev. Add the userspace apps on top. Rob's analysis seemed right on the money to me. 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 -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Thursday, 10/13/2005 at 08:53 ZE8, John Summerfied <[EMAIL PROTECTED]> wrote: > Are people happy that they will not be able to use these functions from > the commandline or from a shell script? The earlier suggestion (not > mine) was to do it in a posix shell. But it doesn't make sense to have all of the diagnose functions available from the command line anyway. And if a script greps stdout, and it decides that the user should see the output, it can write the output back to stdout itself. (I do this all the time in REXX execs - handle the return codes I can deal with myself and dump to the console if I don't recognize it. Is Linux so different?) vmcp is a Linux command interface to a CP command interface (diag 8). The rest of the diagnose functions are programming interfaces of one sort or another. This isn't some new limitation being proposed; this is inherent in the limitations of the [e.g. bash] shell scripting language, is it not? I can certainly envision some userspace apps in the package that do common things with those diags, making them useful in a command environment, but I don't think we need a command interface to the diags themselves. Integrate some into /proc and others into /dev. Add the userspace apps on top. Rob's analysis seemed right on the money to me. 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Carsten Otte wrote: John Summerfied wrote: > Much earlier in this thread (which seems to have changed its subject from time to time), folk were talking about using this in scripts, and examples using /bin/sh were given. For this purpose, serialisation and paralellisation by the driver are inadequate. The state must be preserved for use by the script. Then use a scripting language that can do multiple commands on an open file descriptor [=session]. Like Perl or so. Are people happy that they will not be able to use these functions from the commandline or from a shell script? The earlier suggestion (not mine) was to do it in a posix shell. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Carsten Otte wrote: John Summerfied wrote: Carsten Otte wrote: Rick Troth wrote: Lock the file. Or have the device driver enforce single access. But why lock? CP can handle multiple parralel diag8 As I recall someone asserted there's a problem getting the proper cp feedback at present. VM return codes don't map to *x return codes, so another action is needed to get the VM return code and publish it some place a script can use it. Without locking, this will fail from time to time. No it will not _if_ the lock is done where it belongs: system kernel, not flock or sysfs or whatever vehicle that locks in userspace. That's what vmcp does, and that's what would work for other diagnoses in a similar way. 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. Mark P suggested putenv() Carsten O thought this "This is the right soloution (tm)." John M pointed out that getting it into the _parent's_ environment isn't actually possible, Carsten O suggested grepping the output. This didn't seem to be received with any enthusiasm. Rob van der Heij suggested vmcprc which, as far as I can recall, is still on the table, I'm one who doesn't like grepping the output, because many people are going to discard information users might need. What we do not yet have is a satisfactory, agreed, way to get the CP return code into a shell script. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
John Summerfied wrote: > Much earlier in this thread (which seems to have changed its subject > from time to time), folk were talking about using this in scripts, and > examples using /bin/sh were given. > > For this purpose, serialisation and paralellisation by the driver are > inadequate. The state must be preserved for use by the script. Then use a scripting language that can do multiple commands on an open file descriptor [=session]. Like Perl or so. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
John Summerfied wrote: > Carsten Otte wrote: > >> Rick Troth wrote: >> >>> Lock the file. >>> Or have the device driver enforce single access. >> >> >> But why lock? CP can handle multiple parralel diag8 > > > As I recall someone asserted there's a problem getting the proper cp > feedback at present. VM return codes don't map to *x return codes, so > another action is needed to get the VM return code and publish it some > place a script can use it. > > Without locking, this will fail from time to time. No it will not _if_ the lock is done where it belongs: system kernel, not flock or sysfs or whatever vehicle that locks in userspace. That's what vmcp does, and that's what would work for other diagnoses in a similar way. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Alan Altmark wrote: On Thursday, 10/13/2005 at 09:11 ZE8, John Summerfied <[EMAIL PROTECTED]> wrote: But why lock? CP can handle multiple parralel diag8 As I recall someone asserted there's a problem getting the proper cp feedback at present. VM return codes don't map to *x return codes, so another action is needed to get the VM return code and publish it some place a script can use it. Without locking, this will fail from time to time. All output data areas and registers must be stashed in instance-specific memory such as that associated with a file descriptor. But this is normal coding practice in file/network drivers. Implicit locks would be appropriate for those diagnose functions that are stateful. E.g. you can't have two processes using diag 14 at the same time. But there's no reason they can't both issue diag 210 (for example). Much earlier in this thread (which seems to have changed its subject from time to time), folk were talking about using this in scripts, and examples using /bin/sh were given. For this purpose, serialisation and paralellisation by the driver are inadequate. The state must be preserved for use by the script. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Thursday, 10/13/2005 at 09:11 ZE8, John Summerfied <[EMAIL PROTECTED]> wrote: > > But why lock? CP can handle multiple parralel diag8 > > As I recall someone asserted there's a problem getting the proper cp > feedback at present. VM return codes don't map to *x return codes, so > another action is needed to get the VM return code and publish it some > place a script can use it. > > Without locking, this will fail from time to time. All output data areas and registers must be stashed in instance-specific memory such as that associated with a file descriptor. But this is normal coding practice in file/network drivers. Implicit locks would be appropriate for those diagnose functions that are stateful. E.g. you can't have two processes using diag 14 at the same time. But there's no reason they can't both issue diag 210 (for example). 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Carsten Otte wrote: Rick Troth wrote: Lock the file. Or have the device driver enforce single access. But why lock? CP can handle multiple parralel diag8 As I recall someone asserted there's a problem getting the proper cp feedback at present. VM return codes don't map to *x return codes, so another action is needed to get the VM return code and publish it some place a script can use it. Without locking, this will fail from time to time. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
I am under the impression that Linus does not want any more stuff like this in /proc. I think he has requested that some of the stuff in /proc be moved elseware. The procfs filesystem was originally only for process related stuff. It was kind of lazy to put other things in it. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of John Summerfied Sent: Wednesday, October 12, 2005 4:55 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks Carsten Otte wrote: > McKown, John wrote: > >>This is likely a foolish question, but could the /sys/devices/diagnose >>be set up like the /dev/fd ? E.g. for pid 12345, there exists an entire >>tree /sys/devices/diagnose/12345. Then have "self" as a symlink to the >>current pid so that for any particular pid, it could reference >>/sys/devices/diagnose/self/... It might even be possible to "interlock" >>on /sys/devices/diagnose/self/8/command so that you could not cat to it >>a second time until you had read /sys/devices/diagnose/self/8/status or >>maybe even 'echo "1">/sys/devices/diagnose/self/8/active' where that >>pseudo-file gets changed to "0" when ../command is written to you cannot >>again write a line to ../command until you write a "1" to ../active (or >>something to that effect). Hope this makes sense. I'm not a kernel type >>person. > > Sounds terrible & complicated to me. What's wrong with the existing > soloution with vmcp? It's safe against races _because_ it splits the whole > thing into a userspace program that keeps an open file handle and a kernel > component that can identify subsequent calls by that handle. > I don't really get where the problem with that one is, could you elaborate > where you see the issue? _I_ think devices are ultimately for processing user data and preparing to process user data. So, partitioning & formatting disk, tape handling, communicating with users and other processes are in order (I've always wondered about network devices!). Where you are manipulating the environment, by turning fans on or off, by starting or stopping CPUs, by sending commands to the host OS, or by loading firmware into wireless and other cards and peripherals then something else should be done. In the past, the right thing has been to manipulate files in procfs. Whatever is done, it should be consistent with other virtual environments such as XEN and VMWARE. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Carsten Otte wrote: McKown, John wrote: This is likely a foolish question, but could the /sys/devices/diagnose be set up like the /dev/fd ? E.g. for pid 12345, there exists an entire tree /sys/devices/diagnose/12345. Then have "self" as a symlink to the current pid so that for any particular pid, it could reference /sys/devices/diagnose/self/... It might even be possible to "interlock" on /sys/devices/diagnose/self/8/command so that you could not cat to it a second time until you had read /sys/devices/diagnose/self/8/status or maybe even 'echo "1">/sys/devices/diagnose/self/8/active' where that pseudo-file gets changed to "0" when ../command is written to you cannot again write a line to ../command until you write a "1" to ../active (or something to that effect). Hope this makes sense. I'm not a kernel type person. Sounds terrible & complicated to me. What's wrong with the existing soloution with vmcp? It's safe against races _because_ it splits the whole thing into a userspace program that keeps an open file handle and a kernel component that can identify subsequent calls by that handle. I don't really get where the problem with that one is, could you elaborate where you see the issue? _I_ think devices are ultimately for processing user data and preparing to process user data. So, partitioning & formatting disk, tape handling, communicating with users and other processes are in order (I've always wondered about network devices!). Where you are manipulating the environment, by turning fans on or off, by starting or stopping CPUs, by sending commands to the host OS, or by loading firmware into wireless and other cards and peripherals then something else should be done. In the past, the right thing has been to manipulate files in procfs. Whatever is done, it should be consistent with other virtual environments such as XEN and VMWARE. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Rick Troth wrote: > Lock the file. > Or have the device driver enforce single access. But why lock? CP can handle multiple parralel diag8 calls from different processors just fine, and if the Linux userspace interface is done proper there is no race-issue at all. File locking is limited to super user "root" versus the existing implementation allows root to specify who can issue CP commands [default: only root is allowed to issue CP commands]. And what if a malfunctioning program does flock() and then ends up in an endless loop? That would leave the file locked and the diag8 service would be unavailable. All those issues don't exist with the current implementation. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
McKown, John wrote: > This is likely a foolish question, but could the /sys/devices/diagnose > be set up like the /dev/fd ? E.g. for pid 12345, there exists an entire > tree /sys/devices/diagnose/12345. Then have "self" as a symlink to the > current pid so that for any particular pid, it could reference > /sys/devices/diagnose/self/... It might even be possible to "interlock" > on /sys/devices/diagnose/self/8/command so that you could not cat to it > a second time until you had read /sys/devices/diagnose/self/8/status or > maybe even 'echo "1">/sys/devices/diagnose/self/8/active' where that > pseudo-file gets changed to "0" when ../command is written to you cannot > again write a line to ../command until you write a "1" to ../active (or > something to that effect). Hope this makes sense. I'm not a kernel type > person. Sounds terrible & complicated to me. What's wrong with the existing soloution with vmcp? It's safe against races _because_ it splits the whole thing into a userspace program that keeps an open file handle and a kernel component that can identify subsequent calls by that handle. I don't really get where the problem with that one is, could you elaborate where you see the issue? -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Adam Thornton wrote: > I don't know if this would be considered an abuse of sysfs, but, > presuming that you'd have something like > > /sys/devices/diagnose > > Then for this you could just > > cat /sys/devices/diagnose/8/status > > In the same directory, you could have buffer_size, command, and so > forth. That would be limited to a single user as far as I can see. What if script A wants to set buffer size to 1024 then execute its favorite command while script B wants to set buffer size to 4096 then execute its command? This is racy! -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> Spin ... if the open() fails because of EBUSY, > then wait some fraction of a second and try again. > Or fail immediately with a "the hypervisor is busy". > If after a wait and re-try it fails again, then fail > with the busy error message, or wait a second interval. > > This is not rocket science. > It's not elegant either, but functional. No, imagine one of your automatic system maintenance scripts crashes for some reason. Then you have to solve the "vmcp is locked" situation manually or implement a "steal lock" method - ugly. I think, that the command/return code query should be as atomic as possible to prevent concurrent vmcp calls from disturbing each other. I think for application programmers this is quite simple, they can always use the device node, which guaqrantees to separate each call from others. The only open question is, how to solve our needs in scripts. I still like the stderr method, but will discuss this question with some colleagues if we can think of a better method. -- Mit freundlichen Grüßen / Best Regards / Un cordial saludo Christian Bornträger Linux Software Engineer zSeries Linux & Virtualization IBM Deutschland Entwicklung GmbH email: [EMAIL PROTECTED] Tel +49 7031 16 1975 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> I run vmcp which causes the drive (or file) to be locked > You run vmcp and it fails > I run vmcprc which unlocks the drive (or file) > You scratch your head in wonderment because it's okay now. Spin ... if the open() fails because of EBUSY, then wait some fraction of a second and try again. Or fail immediately with a "the hypervisor is busy". If after a wait and re-try it fails again, then fail with the busy error message, or wait a second interval. This is not rocket science. It's not elegant either, but functional. > Have some syrup while you think about why your vmcp failed;-\ ;-) -- R; -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Rick Troth wrote:
Lock the file.
Or have the device driver enforce single access.
I run vmcp which causes the drive (or file) to be locked
You run vmcp and it fails
I run vmcprc which unlocks the drive (or file)
You scratch your head in wonderment because it's okay now.
I run vmcp which causes the drive (or file) to be locked
You run vmcp and it fails
I run don't vmcprc to unlock the drive (or file)
You scratch your head in wonderment because it worked yesterday and
doesn't now.
Perhaps you decide to run vmcprc first, "just in case." It won't fix
_your_ problem (but you could think it has), and it could cause more
problems.
Having vmcp write to a user-specified file (or descriptor) will work.
Perhaps it could create one using mktemp(), and write its name to stdout
(or would writing the information to stdout be better?) unless it's told
otherwise by commandline option. A script-writer should tell vmcp what
to do, someone at the commandline could view the information or file if
needed.
Have some syrup while you think about why your vmcp failed;-\
-- R;
On Wed, 12 Oct 2005, John Summerfied wrote:
Rob van der Heij wrote:
On 10/11/05, Carsten Otte <[EMAIL PROTECTED]> wrote:
I was just suggesting that this problem can easily be solved in scripts
outside vmcp. I agree that my proposal may require the script author to
think about his best way to retrieve that output - but because
Would it be terribly ugly to have a command that outputs the CP return
code for the most recently issued vmcp command? The would avoid the
Most recently issued by whom?
Where would it be stored?
issues with one-byte return code and separate the Linux return code
from the CP response.
#! /bin/sh
vmcp MSG ROB Testing
rc = `vmcprc`
Nit: if this is a shell script, no spaces allowed.
if $rc = 54 ; then
s/=/-eq/ for numbers
echo User not logged on
fi
I guess the only safe place to store the vmrc is in a guaranteed unique
file. So both parties agree on its name, the name has to be provided by
whatever calls vmcp.
We're getting very close to my very crude hack which does in fact
provide a guaranteed unique file.
I'm not keen on my hack - it's bound to confuse lots of readers - but
this is quite straightforward:
F=$(mktemp /tmp/${USER}-XX)
vmcp MSG ROB Testing 4>${F}
and then the script reads and analyses ${F}, and then removes it.
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
do not reply off-list
--
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
--
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
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
do not reply off-list
--
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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Lock the file.
Or have the device driver enforce single access.
-- R;
On Wed, 12 Oct 2005, John Summerfied wrote:
> Rob van der Heij wrote:
> > On 10/11/05, Carsten Otte <[EMAIL PROTECTED]> wrote:
> >
> >
> >>I was just suggesting that this problem can easily be solved in scripts
> >>outside vmcp. I agree that my proposal may require the script author to
> >>think about his best way to retrieve that output - but because
> >
> >
> > Would it be terribly ugly to have a command that outputs the CP return
> > code for the most recently issued vmcp command? The would avoid the
> Most recently issued by whom?
>
> Where would it be stored?
>
> > issues with one-byte return code and separate the Linux return code
> > from the CP response.
> >
> > #! /bin/sh
> > vmcp MSG ROB Testing
> > rc = `vmcprc`
> Nit: if this is a shell script, no spaces allowed.
> > if $rc = 54 ; then
> s/=/-eq/ for numbers
>
> >echo User not logged on
> > fi
>
> I guess the only safe place to store the vmrc is in a guaranteed unique
> file. So both parties agree on its name, the name has to be provided by
> whatever calls vmcp.
>
> We're getting very close to my very crude hack which does in fact
> provide a guaranteed unique file.
>
> I'm not keen on my hack - it's bound to confuse lots of readers - but
> this is quite straightforward:
> F=$(mktemp /tmp/${USER}-XX)
> vmcp MSG ROB Testing 4>${F}
> and then the script reads and analyses ${F}, and then removes it.
>
>
>
>
> --
>
> Cheers
> John
>
> -- spambait
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
>
> do not reply off-list
>
> --
> 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
>
--
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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Rob van der Heij wrote:
On 10/11/05, Carsten Otte <[EMAIL PROTECTED]> wrote:
I was just suggesting that this problem can easily be solved in scripts
outside vmcp. I agree that my proposal may require the script author to
think about his best way to retrieve that output - but because
Would it be terribly ugly to have a command that outputs the CP return
code for the most recently issued vmcp command? The would avoid the
Most recently issued by whom?
Where would it be stored?
issues with one-byte return code and separate the Linux return code
from the CP response.
#! /bin/sh
vmcp MSG ROB Testing
rc = `vmcprc`
Nit: if this is a shell script, no spaces allowed.
if $rc = 54 ; then
s/=/-eq/ for numbers
echo User not logged on
fi
I guess the only safe place to store the vmrc is in a guaranteed unique
file. So both parties agree on its name, the name has to be provided by
whatever calls vmcp.
We're getting very close to my very crude hack which does in fact
provide a guaranteed unique file.
I'm not keen on my hack - it's bound to confuse lots of readers - but
this is quite straightforward:
F=$(mktemp /tmp/${USER}-XX)
vmcp MSG ROB Testing 4>${F}
and then the script reads and analyses ${F}, and then removes it.
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
do not reply off-list
--
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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of Rob van der Heij > Sent: Tuesday, October 11, 2005 1:50 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: 2005-10-04 Recommended Linux on zSeries code > drop to developerWorks > > > On 10/11/05, Adam Thornton <[EMAIL PROTECTED]> wrote: > > > cat /sys/devices/diagnose/8/status > > My worries with each of these non-atomic implementations is that by > the time I get to inspect the return code, something else may have > issued a CP command after mine. So my return code would have been > lost, and I would see the return code of that other command without > knowing better. > When the interface requires the process to establish some kind of > binding, that kind of problems is avoided. And isn't that what the > ioctl( ) approach does? > > Rob > -- Rob, This is likely a foolish question, but could the /sys/devices/diagnose be set up like the /dev/fd ? E.g. for pid 12345, there exists an entire tree /sys/devices/diagnose/12345. Then have "self" as a symlink to the current pid so that for any particular pid, it could reference /sys/devices/diagnose/self/... It might even be possible to "interlock" on /sys/devices/diagnose/self/8/command so that you could not cat to it a second time until you had read /sys/devices/diagnose/self/8/status or maybe even 'echo "1">/sys/devices/diagnose/self/8/active' where that pseudo-file gets changed to "0" when ../command is written to you cannot again write a line to ../command until you write a "1" to ../active (or something to that effect). Hope this makes sense. I'm not a kernel type person. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On 10/11/05, Adam Thornton <[EMAIL PROTECTED]> wrote: > cat /sys/devices/diagnose/8/status My worries with each of these non-atomic implementations is that by the time I get to inspect the return code, something else may have issued a CP command after mine. So my return code would have been lost, and I would see the return code of that other command without knowing better. When the interface requires the process to establish some kind of binding, that kind of problems is avoided. And isn't that what the ioctl( ) approach does? Rob -- Rob van der Heij rvdheij @ gmail.com -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Oct 11, 2005, at 1:28 PM, Rob van der Heij wrote: Would it be terribly ugly to have a command that outputs the CP return code for the most recently issued vmcp command? The would avoid the issues with one-byte return code and separate the Linux return code from the CP response. I don't know if this would be considered an abuse of sysfs, but, presuming that you'd have something like /sys/devices/diagnose Then for this you could just cat /sys/devices/diagnose/8/status In the same directory, you could have buffer_size, command, and so forth. Adam -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On 10/11/05, Carsten Otte <[EMAIL PROTECTED]> wrote: > I was just suggesting that this problem can easily be solved in scripts > outside vmcp. I agree that my proposal may require the script author to > think about his best way to retrieve that output - but because Would it be terribly ugly to have a command that outputs the CP return code for the most recently issued vmcp command? The would avoid the issues with one-byte return code and separate the Linux return code from the CP response. #! /bin/sh vmcp MSG ROB Testing rc = `vmcprc` if $rc = 54 ; then echo User not logged on fi -- Rob van der Heij rvdheij @ gmail.com -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
At the risk of boring everyone:
There are a couple of reasons that we have to type "int main( ... )". The
biggest one is that way back in the early days of C there were no qualifiers on
functions, so it was just "main( ... )". The int was implied, and you could
not say "unsigned char main".
There were no prototypes and no declarations in the arguments, so main looked
like this:
main( argc, argv )
char *argv[];
{
/* Some code. */
}
Note that argc is implied to be int.
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Rob
van der Heij
Sent: Monday, October 10, 2005 8:42 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to
developerWorks
On 10/10/05, Alan Altmark <[EMAIL PROTECTED]> wrote:
> If I understood correctly, the Linux return code cannot carry the full
> range of CP return codes as it can only have a value from 0-255 and no
> negative values. Did I misunderstand?
Bummer. Why do we write 'int main( )' then rather than 'char main( )' ?
Rob
--
Rob van der Heij rvdheij @ gmail.com
--
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
--
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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
John Summerfied wrote: > Whilst I often grep the output of something, I do so for my own purpose > and knowing I am throwing away information the author felt should be > displayed*. I'd not be happy if my supplier decided to throw that > information away. Indeed, several times I've been cauught with > postgresql not starting and there being no messages because some Red > Twit discarded them. I was just suggesting that this problem can easily be solved in scripts outside vmcp. I agree that my proposal may require the script author to think about his best way to retrieve that output - but because being a scripting language dyslexic that probably takes implementation by someone who knows better. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of Carsten Otte > Sent: Tuesday, October 11, 2005 6:12 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: 2005-10-04 Recommended Linux on zSeries code > drop to developerWorks > > > McKown, John wrote: > > However, it would be useless because, as best as I know, there is no > > way to propagate the variable back to the parent. > But a shell script can grep the output (stderr) and set that variable. > If that one is included via "source" command, it will be available in > the shell environment that did do the vmcp command before. > -- > > Carsten Otte > IBM Linux technology center > ARCH=s390 True. I hadn't thought. But that is not "built in" to the vmcp code. That is code which is "external" to vmcp. I know, a nit. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Carsten Otte wrote: McKown, John wrote: However, it would be useless because, as best as I know, there is no way to propagate the variable back to the parent. But a shell script can grep the output (stderr) and set that variable. If that one is included via "source" command, it will be available in the shell environment that did do the vmcp command before. Whilst I often grep the output of something, I do so for my own purpose and knowing I am throwing away information the author felt should be displayed*. I'd not be happy if my supplier decided to throw that information away. Indeed, several times I've been cauught with postgresql not starting and there being no messages because some Red Twit discarded them. (I'm sure you can find that in BZ if you try; it's several years old by now). That is why I proposed my rather crude hack. * It is possible to tee the report to a file so the user sees all that happened, and the program can then grep the file, but that is more work and likely a lot of folk will not do it. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
McKown, John wrote: > However, it would be useless because, as best as I know, there is no > way to propagate the variable back to the parent. But a shell script can grep the output (stderr) and set that variable. If that one is included via "source" command, it will be available in the shell environment that did do the vmcp command before. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Post, Mark K wrote: > I think that we should, as much as possible, stick to Linux/UNIX > conventions, and this probably comes as close as we can hope for, right > now. Errors should always go to stderr. There's no requirement that it > be only one line of output. There's also no reason why an environment > variable, say CPRC, cannot be set to some number that just happens to be > the same as the CP return code. Goood idea. I like the environment variable thing. This is the right soloution (tm). -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Rick Troth wrote: If you invoke the command as: . cmdname It works just fine, since "cmdname" is executed in the current shell. Yes, exactly. But that cannot be done for a binary. In other words, an "executable" cannot be "sourced". If you're suitably determined, something like this could be made to work: eval $(binary 2>&4 4>&1) 4>&1 Sure, it's grubby, gruesome and/or a Crude Hack. I sometimes find the need to do something like his, but without the redirections. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Rob van der Heij wrote: On 10/10/05, Alan Altmark <[EMAIL PROTECTED]> wrote: If I understood correctly, the Linux return code cannot carry the full range of CP return codes as it can only have a value from 0-255 and no negative values. Did I misunderstand? Bummer. Why do we write 'int main( )' then rather than 'char main( )' ? or "unsigned char main();" -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> If you invoke the command as: > . cmdname > > It works just fine, since "cmdname" is executed in the current shell. Yes, exactly. But that cannot be done for a binary. In other words, an "executable" cannot be "sourced". -- R; -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
If you invoke the command as: . cmdname It works just fine, since "cmdname" is executed in the current shell. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, October 10, 2005 2:15 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of Post, Mark K > Sent: Monday, October 10, 2005 12:50 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: 2005-10-04 Recommended Linux on zSeries code > drop to developerWorks > > > be only one line of output. There's also no reason why an environment > variable, say CPRC, cannot be set to some number that just happens to > be the same as the CP return code. > > > Mark Post Huh? I know that a program can set an environment variable. However, it would be useless because, as best as I know, there is no way to propagate the variable back to the parent. -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of Post, Mark K > Sent: Monday, October 10, 2005 12:50 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: 2005-10-04 Recommended Linux on zSeries code > drop to developerWorks > > > be only one line of output. There's also no reason why an environment > variable, say CPRC, cannot be set to some number that just > happens to be > the same as the CP return code. > > > Mark Post Huh? I know that a program can set an environment variable. However, it would be useless because, as best as I know, there is no way to propagate the variable back to the parent. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
I think that we should, as much as possible, stick to Linux/UNIX conventions, and this probably comes as close as we can hope for, right now. Errors should always go to stderr. There's no requirement that it be only one line of output. There's also no reason why an environment variable, say CPRC, cannot be set to some number that just happens to be the same as the CP return code. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Monday, October 10, 2005 4:36 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks -snip- When the diag8 is issued correctly it returns two responses: 1. The CP return code (a number) 2. The human readable response (in text) Although we're told not to use the text as an API, real life is different. But the CP return code is very useful to deal with expected errors. Looking at how Linux programs work, I believe the logical approach would be for cpint/vmcp to write (2) either to stdout or to stderr, depending on whether (1) is zero or not. But I doubt this would be practical for people to use. And we still would not have the return code to use. That's why I suggested to cheat. -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Rob said that, actually. Essentially, POSIX made a lot of things look silly in retrospect, because it had to impose some sort of order on a sea of chaos. Not everything got adjusted to accommodate that (and probably rightfully so). Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, October 10, 2005 1:10 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks -snip- I think DJ is right: why have int main() if the program can't [usefully] return the full range of ints? -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
See the wait(2) man page for the reason why the return-code limited...
Basically, more than the return code is returned when a process
"ends" - and that consumes some flag bits.
- Dave Rivers -
>
> On Monday, 10/10/2005 at 06:45 ZE2, Carsten Otte <[EMAIL PROTECTED]> wrote:
> > Alan Altmark wrote:
> > > Eh? CP has *thousands* of return codes. I is just Plain Wrong to try
> to
> > > map them to the smaller name space of the Linux return code.
> > Good point. adds mapping CP return value to Linux rc to his list of
> bad
> > ideas.
>
> If a program makes a rc = system("vmcp foo") call, will it get the full
> return code? Or can a program call vmcp in some other way?
>
> I am wondering if the problem with the 8-bittedness of the return code is
> a result of real truncation or if it's just an artifact of the shell's
> rendering of the return code. Maybe we should fix it? I think DJ is
> right: why have int main() if the program can't [usefully] return the full
> range of ints?
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
--
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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Monday, 10/10/2005 at 06:45 ZE2, Carsten Otte <[EMAIL PROTECTED]> wrote:
> Alan Altmark wrote:
> > Eh? CP has *thousands* of return codes. I is just Plain Wrong to try
to
> > map them to the smaller name space of the Linux return code.
> Good point. adds mapping CP return value to Linux rc to his list of
bad
> ideas.
If a program makes a rc = system("vmcp foo") call, will it get the full
return code? Or can a program call vmcp in some other way?
I am wondering if the problem with the 8-bittedness of the return code is
a result of real truncation or if it's just an artifact of the shell's
rendering of the return code. Maybe we should fix it? I think DJ is
right: why have int main() if the program can't [usefully] return the full
range of ints?
I remember we had a similar problem with the CMS Ready message a few years
ago: The program could pass a full int back to CMS, but the command shell
would truncate the displayed value to 6 characters with bizzare results.
We fixed the command shell to put as many digits in there as needed.
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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Alan Altmark wrote: > Eh? CP has *thousands* of return codes. I is just Plain Wrong to try to > map them to the smaller name space of the Linux return code. Good point. adds mapping CP return value to Linux rc to his list of bad ideas. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Monday, 10/10/2005 at 11:21 EST, Rick Troth <[EMAIL PROTECTED]> wrote: > > Forgetting the limit of 8 bits for POSIX return codes, there's no way > all these layers can be completely accomodated. But with the CP > commands having the broadest meaningful numeric assignments, I let > that take precedent: that is, 45 means "nog logged on". The other > "layers" will just have to cope and fit in where they can. Eh? CP has *thousands* of return codes. I is just Plain Wrong to try to map them to the smaller name space of the Linux return code. 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> If I understood correctly, the Linux return code cannot carry the full > range of CP return codes as it can only have a value from 0-255 and no > negative values. Did I misunderstand? No. You understood correctly. The POSIX return code (historically or otherwise) is limitted to 8 bits. Sad, but true. This is true on OpenVM too. But the "return code" from a shell command (OpenVM, Linux, or whatever) which is effecting a CP command should immediately reflect pass/fail. There are two possible failures for DIAG 08 itself, reflected by the CC of the pseudo-instruction and the indicated RC register. There are at least two more possible failures for a Linux interface, in both kernel space and user space. Forgetting the limit of 8 bits for POSIX return codes, there's no way all these layers can be completely accomodated. But with the CP commands having the broadest meaningful numeric assignments, I let that take precedent: that is, 45 means "nog logged on". The other "layers" will just have to cope and fit in where they can. -- R; -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Mon, 10 Oct 2005, Alan Altmark wrote: > To be clear, my proposal was the the Linux return code remains constant. > --rc would prefix the stdout output with the CP return code. Understood. This renders 'vmcp' much more difficult to use from my position. -- R; -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Alan Altmark wrote: > If I understood correctly, the Linux return code cannot carry the full > range of CP return codes as it can only have a value from 0-255 and no > negative values. Did I misunderstand? Almost. Negative return values are well defined for everything that can possibly go wrong for Linux. A return value of zero is defined to indicate that everything is perfectly well. A positive return value in the range from 1-255 is supposed to have a user-defined semantics depending on the application. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> On 10/7/05, Christian Borntraeger <[EMAIL PROTECTED]> wrote: > > # vmcp > > # echo $? ... On Fri, 7 Oct 2005, Rob van der Heij wrote: > Cool. I learned something on the late friday afternoon. Can I stuff > this also in my ready prompt to have a R($?) displayed in case of > error for any command? Yes. BASH supports this trick. (Dunno about other shells.) -- R; -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On 10/10/05, Alan Altmark <[EMAIL PROTECTED]> wrote: > If I understood correctly, the Linux return code cannot carry the full > range of CP return codes as it can only have a value from 0-255 and no > negative values. Did I misunderstand? Bummer. Why do we write 'int main( )' then rather than 'char main( )' ? Rob -- Rob van der Heij rvdheij @ gmail.com -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Monday, 10/10/2005 at 05:10 ZE2, Rob van der Heij <[EMAIL PROTECTED]> wrote: > Separation of the prefaced return code and the output is not easy in > shell scripts (especially since we lack multi-stream pipelines and a > 'not' stage). > > I would prefer the --rc to make the $? carry the CP return code (and > map unexpected Linux events into a negative value). I can see some > value in writing the response to stderr for rc>0 but I am not sure you > want that. If I understood correctly, the Linux return code cannot carry the full range of CP return codes as it can only have a value from 0-255 and no negative values. Did I misunderstand? 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On 10/10/05, Alan Altmark <[EMAIL PROTECTED]> wrote: > To be clear, my proposal was the the Linux return code remains constant. > --rc would prefix the stdout output with the CP return code. That was certainly not clear, otherwise I would have disagreed sooner :-) Separation of the prefaced return code and the output is not easy in shell scripts (especially since we lack multi-stream pipelines and a 'not' stage). I would prefer the --rc to make the $? carry the CP return code (and map unexpected Linux events into a negative value). I can see some value in writing the response to stderr for rc>0 but I am not sure you want that. Rob -- Rob van der Heij rvdheij @ gmail.com -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Monday, 10/10/2005 at 10:47 ZE2, Martin Schwidefsky <[EMAIL PROTECTED]> wrote: > If you use the vmcp api in a program you can get the CP return code by > an ioctl. I kind of like the idea to use an option, e.g. "--rc" to make > vmcp return the CP return code instead of the Linux return code. That > way everybody is happy. You get what you ask for. To be clear, my proposal was the the Linux return code remains constant. --rc would prefix the stdout output with the CP return code. $> vmcp "query virt 91" --rc 40 HCPQVD040E Device 0091 does not exist $> echo $? 0 $> vmcp "q v 191" --rc 0 DASD 0191 3390 USE71C R/W 13 CYL ON DASD 73AD SUBCHANNEL = 0007 $> echo $? 0 $> vmcp "foobar" --rc -1 Unknown CP Command: foobar<-- this is on stderr $> echo $? 1 $> vmcp "query all" --rc -2 Response buffer too small; try --buffer=12k<-- on stderr $> echo $? 2 Note that rc < 0 indicates something was written to stderr. 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Mon, 2005-10-10 at 10:36 +0200, Rob van der Heij wrote: > On 10/10/05, Carsten Otte <[EMAIL PROTECTED]> wrote: > > > No. The Linux kernel should return Linux error codes. This way you get > > reasonable messages like "out of memory", localized in the language the user > > has chosen. Users don't expect to see CP return values in Linux. > > The users who are Linux kernel developers do not expect that... ;-) > and you may even claim that you know what the users *should* expect... > but the other part was the PLA that Arty brought up. There is obviously a clash between what a CP programmer expects to see as the return code and what a Linux programmer wants to see. > The point I tried to make is that CP command return codes are part of > the response and allow the user (programs) to deal with expected > errors (as opposed to things like 'out of memory' which is unexpected > errors). When the diag8 is issued correctly it returns two responses: > 1. The CP return code (a number) > 2. The human readable response (in text) > Although we're told not to use the text as an API, real life is > different. But the CP return code is very useful to deal with expected > errors. > > Looking at how Linux programs work, I believe the logical approach > would be for cpint/vmcp to write (2) either to stdout or to stderr, > depending on whether (1) is zero or not. But I doubt this would be > practical for people to use. And we still would not have the return > code to use. That's why I suggested to cheat. If you use the vmcp api in a program you can get the CP return code by an ioctl. I kind of like the idea to use an option, e.g. "--rc" to make vmcp return the CP return code instead of the Linux return code. That way everybody is happy. You get what you ask for. -- blue skies, Martin Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland Entwicklung GmbH -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On 10/10/05, Carsten Otte <[EMAIL PROTECTED]> wrote: > No. The Linux kernel should return Linux error codes. This way you get > reasonable messages like "out of memory", localized in the language the user > has chosen. Users don't expect to see CP return values in Linux. The users who are Linux kernel developers do not expect that... ;-) and you may even claim that you know what the users *should* expect... but the other part was the PLA that Arty brought up. The point I tried to make is that CP command return codes are part of the response and allow the user (programs) to deal with expected errors (as opposed to things like 'out of memory' which is unexpected errors). When the diag8 is issued correctly it returns two responses: 1. The CP return code (a number) 2. The human readable response (in text) Although we're told not to use the text as an API, real life is different. But the CP return code is very useful to deal with expected errors. Looking at how Linux programs work, I believe the logical approach would be for cpint/vmcp to write (2) either to stdout or to stderr, depending on whether (1) is zero or not. But I doubt this would be practical for people to use. And we still would not have the return code to use. That's why I suggested to cheat. Rob -- Rob van der Heij rvdheij @ gmail.com -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Post, Mark K wrote: > Oh, God, no. XML is the devil's spawn for stuff like this. Human > readable/scriptable is the way to go. I would like to second that. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Adam Thornton wrote: > Well, if we're outputting error text to stderr, how about a defined > text format for that output which includes the CP DIAG return code > (or perhaps, retcode, reason code, text)? Then I can parse that with > "cut" or something if I want the equivalent of parsing Diagrc > (08,whatever) in my scripting code, and perhaps also a -q option to > say, "emit no output to either stdout or stderr, just tell me the > return code." I like that suggestion. Sounds reasonable to me. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
David Boyes wrote: > Usability suggestion: since this is a VM-specific widget, could you return > codes that are consistent with the implementation of DIAG 8 on CMS? I think > it would help in understanding how to use the gadget, and folks coming over > from CMS would be more familiar with those return codes. No. The Linux kernel should return Linux error codes. This way you get reasonable messages like "out of memory", localized in the language the user has chosen. Users don't expect to see CP return values in Linux. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Oh, God, no. XML is the devil's spawn for stuff like this. Human readable/scriptable is the way to go. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Friday, October 07, 2005 12:19 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks Well, if we're putting in "blue sky" ideas, I think it might be nice to have an option to direct the output to a file (instead of or in addition to stdout/stderr). The output should be in XML format. -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> Well, if we're putting in "blue sky" ideas, I think it might > be nice to have an option to direct the output to a file > (instead of or in addition to stdout/stderr). With you so far... > The output > should be in XML format. OK, I'm getting a bit crazy now. But > there are a TON of well defined XML parsers that could be > used in an application which might use this interface (say > for a GUI or something). Why impose the XML transcoder overhead? Most of this stuff is CR/LF-terminated text lines. What value does XML encoding add here (given the extra complexity of stripping all that noise out)? -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
David Boyes: > Usability suggestion: since this is a VM-specific widget, could you return > codes that are consistent with the implementation of DIAG 8 on CMS? I > thinkit would help in understanding how to use the gadget, and folks > coming over from CMS would be more familiar with those return codes. David Jones: > Besides the 0 and ENOBUF (105) return values, what other codes > can vmcp product? Adam Thornton > Well, if we're outputting error text to stderr, how about a defined > text format for that output which includes the CP DIAG return code > (or perhaps, retcode, reason code, text)? Then I can parse that with > "cut" or something if I want the equivalent of parsing Diagrc > (08,whatever) in my scripting code, and perhaps also a -q option to > say, "emit no output to either stdout or stderr, just tell me the > return code." 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. thanks for the feedback Christian -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of Adam Thornton > Sent: Friday, October 07, 2005 11:03 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: 2005-10-04 Recommended Linux on zSeries code > drop to developerWorks > > > On Oct 7, 2005, at 10:55 AM, Ingo Adlung wrote: > > David, > > I beg you pardon, but i don't like the CP return code approach. > > While a VM > > "widget" it is nonetheless a Linux module and should adhere to > > Linux return > > code principles. But your point is well taken, it would certainly be > > valuable > > to describe how those get mapped to Linux values. > > Well, if we're outputting error text to stderr, how about a defined > text format for that output which includes the CP DIAG return code > (or perhaps, retcode, reason code, text)? Then I can parse that with > "cut" or something if I want the equivalent of parsing Diagrc > (08,whatever) in my scripting code, and perhaps also a -q option to > say, "emit no output to either stdout or stderr, just tell me the > return code." > > Adam Well, if we're putting in "blue sky" ideas, I think it might be nice to have an option to direct the output to a file (instead of or in addition to stdout/stderr). The output should be in XML format. OK, I'm getting a bit crazy now. But there are a TON of well defined XML parsers that could be used in an application which might use this interface (say for a GUI or something). -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On 10/7/05, Ingo Adlung <[EMAIL PROTECTED]> wrote: > I beg you pardon, but i don't like the CP return code approach. While a VM > "widget" it is nonetheless a Linux module and should adhere to Linux return > code principles. But your point is well taken, it would certainly be > valuable > to describe how those get mapped to Linux values. I beg two pardons, but you both may be missing a level of virtualization here. 1) The fact whether the Linux thing did what it should do for diag8 and did not suffer from problems getting the command to CP or obtain the result (out of memory, result truncated, etc) 2) The return code from CP on the command that you issued (e.g. userid not logged on, device not in directory) What a VM user would expect to get when he issues a CP command is two things: a) return code from CP b) output of the command It gets hairy when you mix the two. CMS Pipelines does this by a secondary output stream, but that is the kind of plumbing we don't have here. I expect it is rare that the Linux thing itself did not work (1) so we could stuff that in stderr. The CP return code (a) is useful for the user, and I was thinking you could have that one as the return code of the vmcp command. This gives an easy way to get hold of it as I learned. Rob -- Rob van der Heij rvdheij @ gmail.com -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> I beg you pardon, but i don't like the CP return code > approach. While a VM "widget" it is nonetheless a Linux > module and should adhere to Linux return code principles. But > your point is well taken, it would certainly be valuable to > describe how those get mapped to Linux values. If you can document the mapping of the common return codes (0, 4, 8, 16, 28) to something reasonable in Linux, that'll work for me. -- db -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Oct 7, 2005, at 10:55 AM, Ingo Adlung wrote: David, I beg you pardon, but i don't like the CP return code approach. While a VM "widget" it is nonetheless a Linux module and should adhere to Linux return code principles. But your point is well taken, it would certainly be valuable to describe how those get mapped to Linux values. Well, if we're outputting error text to stderr, how about a defined text format for that output which includes the CP DIAG return code (or perhaps, retcode, reason code, text)? Then I can parse that with "cut" or something if I want the equivalent of parsing Diagrc (08,whatever) in my scripting code, and perhaps also a -q option to say, "emit no output to either stdout or stderr, just tell me the return code." Adam -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Linux on 390 Port wrote on 07.10.2005 17:35:05: > > vmcp has a return value, which you can check in scripts. > > e.g: > > > > # vmcp > > # echo $? > > > > 0 stands for everything is fine, any other value for problems. > > vmcp returns ENOBUFS (105) if the buffer was not large enough > > That means the output was larger than 64kb. > > Usability suggestion: since this is a VM-specific widget, could you return > codes that are consistent with the implementation of DIAG 8 on CMS? I think > it would help in understanding how to use the gadget, and folks coming over > from CMS would be more familiar with those return codes. David, I beg you pardon, but i don't like the CP return code approach. While a VM "widget" it is nonetheless a Linux module and should adhere to Linux return code principles. But your point is well taken, it would certainly be valuable to describe how those get mapped to Linux values. > > > > If there is a consensus that vmcp should always print > > something to stderr if the buffer was not large enough, tell > > us and we can add that. > > A combination of the "familiar" return codes noted above, and an explanatory > message to stderr would be my preferred approach. > > -- db > > -- > 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 Ingo -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Christian, my personal opinion, for what it's worth, would be for vmcp to print an error message of some sort to stderr, if the vmcp commands fails. Besides the 0 and ENOBUF (105) return values, what other codes can vmcp product? DJ Christian Borntraeger wrote: > Rob, > > I forgot that comment: > >> It's annoying to silently truncate the response, so should you not >> write something into stderr to point that out? > > vmcp has a return value, which you can check in scripts. > e.g: > > # vmcp > # echo $? > > 0 stands for everything is fine, any other value for problems. > vmcp returns ENOBUFS (105) if the buffer was not large enough > That means the output was larger than 64kb. > > You can also print a message using the or code in shells: > > # vmcp || echo "error code: $?" > > If there is a consensus that vmcp should always print something > to stderr if the buffer was not large enough, tell us and we can > add that. > > > > > -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
I recommend that you issue a message to stderr for any error that occurs. You could add an option to suppress messages and only set the status, but you don't really need to if all the errors go to stderr. If a script wants to suppress the message the usual way is to redirect stderr to /dev/null (with "vmcp some_large_query 2>/dev/null"). -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Christian Borntraeger Sent: Friday, October 07, 2005 7:48 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks Rob, I forgot that comment: > It's annoying to silently truncate the response, so should you not > write something into stderr to point that out? vmcp has a return value, which you can check in scripts. e.g: # vmcp # echo $? 0 stands for everything is fine, any other value for problems. vmcp returns ENOBUFS (105) if the buffer was not large enough That means the output was larger than 64kb. You can also print a message using the or code in shells: # vmcp || echo "error code: $?" If there is a consensus that vmcp should always print something to stderr if the buffer was not large enough, tell us and we can add that. -- Mit freundlichen Grüßen / Best Regards / Un cordial saludo Christian Bornträger Linux Software Engineer zSeries Linux & Virtualization IBM Deutschland Entwicklung GmbH email: [EMAIL PROTECTED] Tel +49 7031 16 1975 -- 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 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> vmcp has a return value, which you can check in scripts. > e.g: > > # vmcp > # echo $? > > 0 stands for everything is fine, any other value for problems. > vmcp returns ENOBUFS (105) if the buffer was not large enough > That means the output was larger than 64kb. Usability suggestion: since this is a VM-specific widget, could you return codes that are consistent with the implementation of DIAG 8 on CMS? I think it would help in understanding how to use the gadget, and folks coming over from CMS would be more familiar with those return codes. > If there is a consensus that vmcp should always print > something to stderr if the buffer was not large enough, tell > us and we can add that. A combination of the "familiar" return codes noted above, and an explanatory message to stderr would be my preferred approach. -- db -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On 10/7/05, Christian Borntraeger <[EMAIL PROTECTED]> wrote: > # vmcp > # echo $? > # vmcp || echo "error code: $?" Cool. I learned something on the late friday afternoon. Can I stuff this also in my ready prompt to have a R($?) displayed in case of error for any command? Yes, I think it makes sense to complain upon truncation. Except maybe when you specified 0 buffer yourself. Rob -- Rob van der Heij rvdheij @ gmail.com -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Rob, I forgot that comment: > It's annoying to silently truncate the response, so should you not > write something into stderr to point that out? vmcp has a return value, which you can check in scripts. e.g: # vmcp # echo $? 0 stands for everything is fine, any other value for problems. vmcp returns ENOBUFS (105) if the buffer was not large enough That means the output was larger than 64kb. You can also print a message using the or code in shells: # vmcp || echo "error code: $?" If there is a consensus that vmcp should always print something to stderr if the buffer was not large enough, tell us and we can add that. -- Mit freundlichen Grüßen / Best Regards / Un cordial saludo Christian Bornträger Linux Software Engineer zSeries Linux & Virtualization IBM Deutschland Entwicklung GmbH email: [EMAIL PROTECTED] Tel +49 7031 16 1975 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
> You could have asked "any VM person" on what the "right way" would be > to address the buffer size. Yes, you want a way to set the buffer > size, and otherwise for query commands you want to automagically > extend the buffer and retry (but not for all commands, please). I Agreed, I should have talked to more VM persons about that. My decision was based on limitations in the linux kernel about getting guest real storage. Nevertheless, I have not seen a problem in real life with normal commands. If anybody faces a problem with the current buffering in vmcp it should be quite simple to change the userspace tool. The kernel part is very flexible about buffering. In other words, if you show me a scenario where vmcp fails, send a bug report and we will try to find a solution. > personally would not have suggested an interface where the option can > be confused with the actual command: > vmcp msg operator why does --buffer= does not work? Rob, using " like in vmcp "msg operator why does --buffer= does not work?" is the UNIX way to pass - or -- in parameters, so there is no problem. I hope that clarifies some of the questions. -- Mit freundlichen Grüßen / Best Regards / Un cordial saludo Christian Bornträger Linux Software Engineer zSeries Linux & Virtualization IBM Deutschland Entwicklung GmbH email: [EMAIL PROTECTED] Tel +49 7031 16 1975 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On 10/7/05, Martin Schwidefsky <[EMAIL PROTECTED]> wrote: > 2) Be prepared for criticism, sometimes it is very harsh. We had an > example of one of the extremes how "bad news" is delivered. Even if you > don't like the style you need to listen to what is said. These people, > tend to be right in what they say. Unfortunatly not in the how... In my sheltered life I am only exposed to the criticism from those in Boeblingen who still talk to me ;-) When I was forced to prototype the 2GB I/O bypass myself to prove that I was right, the comments on my code did not appear helpful at that time. Looking back, the comments from Carsten was not the reason I had to do the work again. The reason was that during the first attempt I had no clear view on the finish and the path I followed was curved. Doing it again is easier. I am sure the solution provided by the folks in Boeblingen did not use anything from my work. That's good because Martin c.s. need to sign off with their blue blood and they probably did not trust I did this myself. :-) But I had a good day being proud of myself, and still believe I made a difference in getting something out in the field. Rob -- Rob van der Heij rvdheij @ gmail.com -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Thu, 2005-10-06 at 12:37 -0400, Neale Ferguson wrote: > Please don't patronise me. I and several others from the VM/Linux > Technical Steering committee of SHARE have been working hand-in-hand > with the lab people since SHARE was in San Francisco a few years ago to > work out a means of doing co-operative development. Those involved > determined it would be a good idea if instead of an uncoordinated > approach to kernel development for s390 we could do things in a more > planned way. This way we could avoid the reinvention syndrome. We had > setup a system on the Marist VM/Linux complex and ported bitkeeper over > so that we had up to date kernel sources; there would be general access > for the s390 people interested in kernel development; and the lab people > could see what we were up to. It was then going to be a matter of > submitting our changes to the kernel we made through the s390 > maintainer. Technically this was done. Legally we couldn't get it going. > Not our legals: YOURS. Yes we need a central place where we can kepp all the code that is floating around for mainframe linux so that all interested parties can look at the code. However that only addresses one aspect, the code doesn't magically get better if we keep it at one place. Some important facts I have learned over the past few years about Linux kernel development: 1) It is a push model, not a pull model. If you want to get something in you need to actively push it up the chain. 2) Be prepared for criticism, sometimes it is very harsh. We had an example of one of the extremes how "bad news" is delivered. Even if you don't like the style you need to listen to what is said. These people, tend to be right in what they say. Unfortunatly not in the how... 3) Be prepared to rewrite your code. Completly. Even it the function is desperatly needed, code that is considered inferior is not accepted. Inferior in the sense that how things are done is improvable. The function is often good, but the how is lacking. As an example (sorry Neale): last time I looked at Neales iucv driver it still used a character device driver as user interface to connect to the z/VM service via iucv. That does work but imho the "correct" solution is to implement a AF_IUCV network family and use netcat. > So yes, the alternative approach of going through the standard mailing > lists appears to be our only option now. We were keen to work closely > with the s390 lab so that stuff like my "utterly crap code" could be > made less crappy. But please don't complain to me about my complaints > when we've been trying to do what we feel has been the best for the s390 > Linux branch. What we need to set up is a way how we can do peer reviews. I still hope that the marist proposal takes place, it would solve some of our current problems. For now please send the patches to one of the appropriate mailing lists, if you want me to comment include me on the CC list. -- blue skies, Martin Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland Entwicklung GmbH -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Hello from Gregg C Levine Mark, the way people argue, won't change much when they get older, when it covers technology. I am convinced however. This is far more restrained then the usual flame war, "Why do this, this way?", as opposed to "Do this, this way?". --- Gregg C Levine [EMAIL PROTECTED] --- "Remember the Force will be with you. Always." Obi-Wan Kenobi > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of > Mark D Pace > Sent: Thursday, October 06, 2005 2:15 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to > developerWorks > > I thought flame wars were for game playing teenagers, not adult > professionals. Ah another myth down in flames. Pun definitely intended. > > > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > 1700 Summit Lake Drive > Tallahassee, FL. 32317 > Office: 850.219.5184 > Fax: 888.221.9862 > http://www.mainline.com > > > This e-mail and files transmitted with it are confidential, and are > intended solely for the use of the individual or entity to whom this e-mail > is addressed. If you are not the intended recipient, or the employee or > agent responsible to deliver it to the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you are not one of the named > recipient(s) or otherwise have reason to believe that you received this > message in error, please immediately notify sender by e-mail, and destroy > the original message. Thank You. > > -- > 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 -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Thu, 6 Oct 2005, Christoph Hellwig wrote: ... > That's bullshit. I've many ACKs for my patches touching arch/s390 from > IBM people. Nevermding, cpint is not only doing the split wrong, it's > also utter crap code. I haven't actually looked at the replacement, but > I doubt it can be worse. -- R; -- 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
I thought flame wars were for game playing teenagers, not adult professionals. Ah another myth down in flames. Pun definitely intended. Mark D Pace Senior Systems Engineer Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 Office: 850.219.5184 Fax: 888.221.9862 http://www.mainline.com This e-mail and files transmitted with it are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you are not one of the named recipient(s) or otherwise have reason to believe that you received this message in error, please immediately notify sender by e-mail, and destroy the original message. Thank You. -- 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
