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. Y
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 th
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
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 h
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
--
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
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
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,
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
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 Pi
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 susp
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
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
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 ma
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 pa
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
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 impleme
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
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 sec
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
-
-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 addres
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 sep
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
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
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
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
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
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'
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
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
ina
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 prese
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 st
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 presen
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
a
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
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, s
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:
>
>
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 pi
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 u
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 refe
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
> 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 sc
> 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
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 cause
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 vmc
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
> -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,
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
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 h
OTECTED] 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 c
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 wit
> -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
>
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 availa
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 envir
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 en
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 c
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
> 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;
--
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
> -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
>
>
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
[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
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 Altma
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
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
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
> 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
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;
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 fo
> 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 comman
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 '
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 retu
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 retu
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. Tha
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
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 k
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
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
> (
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 re
bject: 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 sho
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 retu
> 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 defin
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 co
> -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
>
&g
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 descr
> 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
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 h
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 mea
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:
>
/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 zS
> 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 thi
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 mak
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
> 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 t
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 w
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 c
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.
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.
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://ww
1 - 100 of 125 matches
Mail list logo
