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
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
On Sat, 2005-10-08 at 12:53 -0400, Neale Ferguson wrote:
Christoph's point is well taken: The best place for the code was to be
submitted for inclusion in the mainstream and subject to peer review. My
point is that I hadn't avoided that process but had been trying to work
with IBM (via SHARE
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
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
On Fri, 2005-10-07 at 14:46 -0400, Post, Mark K wrote:
And this has been one of my worries, and why we initially tried to go
through IBM Legal to get things changed there. It may very well be that
the answer needs to be we keep pursuing that long-term, while having
non-IBM contributors
Neale Ferguson wrote:
Christoph's point is well taken:
snip
so I think I'm familiar with what the process
involves.
I think Neale's point is well taken too: The Boeblingen people
need to focus on peer-reviewing more.
It's good to see that at the end of day after a long emotional
discussion we
On Mon, 2005-10-10 at 10:43 +0200, Carsten Otte wrote:
It's good to see that at the end of day after a long emotional
discussion we got to the real bottom-line:
Neale needs to submit his things for peer-review, and we IBMers
need to focus on actually reviewing until the result is feasible
for
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
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
Not so much emoition but jet lag. I should learn not to respond to
e-mail after a 21 hour trip from Australia! However, the outcome is a
fair result.
-Original Message-
It's good to see that at the end of day after a long emotional
discussion we got to the real bottom-line:
Neale needs to
Welcome to Monday... I've had something I am either insufficiently
caffeinated to figure out, or this is something more subtle...
In any case, I installed a SLES-9 system, which then rebooted and came back
for configuration. After I did the remaining bits, hardening with Bastille,
etc, installing
On Oct 10, 2005, at 9:10 AM, James Melin wrote:
Welcome to Monday... I've had something I am either insufficiently
caffeinated to figure out, or this is something more subtle...
[1A..doneWaiting for mandatory devices: qeth-bus-ccw-0.0.9000
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
When I boot the install system the device is detected.
Loading qeth...
snip-
3 OSA Express, Gigabit Ethernet or High Speed Token Ring Channels were
detected.
First OSA Express, Gigabit Ethernet or High Speed Token Ring Channels that
were
detected:
Device Addresses CHPID(s)
Is it coupled to the guest lan?
David
James Melin wrote:
qeth: Device 0.0.9000/0.0.9001/0.0.9002 is a Guest LAN QDIO card (level:
V519)
---snip
--
For LINUX-390 subscribe / signoff / archive access instructions,
send
Providing our TCP/IP person did things correctly I would have to believe so
- given that I can access the installation system without problem and it
even was working after the first boot from install. Failure was encountered
on second boot from install.
David Kreuter
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
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
According to
http://ftp.support.veritas.com/pub/support/products/NetBackup_Enterprise
_Server/263839.pdf the Vertias netbackup client is support on SLES7,8,9
and RHEL 3.0.
Has anyone on the list tried incorporating Linux on z into their
enterprise Veritas installation (if you have one)?
Eric
I have a customer that will be switching to Netbackup. They haven't
started yet, so I have nothing to report.
Biggs, Eric J [IT] wrote:
According to
http://ftp.support.veritas.com/pub/support/products/NetBackup_Enterprise
_Server/263839.pdf the Vertias netbackup client is support on SLES7,8,9
I have a customer that will be switching to Netbackup. They
haven't started yet, so I have nothing to report.
I faintly remember either Marcy Cortes or Ann Smith posting something about
this a while back. My memory is going.
General (faint) image in my mind was that it worked, but the support
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
As an ISV, I must say that it is FRUSTRATING
to have to code my products to now look for additional commands.
Up to now, our customers would install CPINT or we would employ
a work-around. But now, I have to dig around for 'vmcp',
which also will be in flux for a while. ARGH!!!
But ... I
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;
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,
Not necessarily. Your customers can still install cpint and you would
not have to worry about vmcp. Choice is a wonderful thing.
Rick Troth wrote:
As an ISV, I must say that it is FRUSTRATING
to have to code my products to now look for additional commands.
Up to now, our customers would
Eric,
We don't have it in production, but we tested it. All of the testing was
successful. According to our storage management people, it behaved the
same on zLinux as it did on Unix. I heard at the September SHARE
conference that it was not certified for zLinux. I have not had time to
verify
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
David Boyes wrote:
Perhaps one of the positive things to come out of this discussion might be
to set down what those rules *are*.
Well that's an easy one: Follow the coding-style guideline and make your
code such that John Doe kernel hacker can understand it easily. In case
something is not
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. me adds mapping CP return value to Linux rc to his list of bad
ideas.
--
Carsten Otte
IBM Linux technology center
ARCH=s390
We have it. We've gotten as far as installing it on a single Linux instance
(31bit SLES8 ) and verifying that we could indeed backup and restore. I'd
like to do so more testing, but haven't had the time.We haven't had an
application that's required it as part of their disaster plans, yet, so
Ok, good point(s). I keep forgetting about RedHat... :)
David Boyes wrote:
Not necessarily. Your customers can still install cpint and
you would not have to worry about vmcp.
Except on RH, which won't ship cpint, at which point he *does* have to care
about vmcp, and now he has to test for
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. me adds mapping CP return value to Linux rc to his
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
All,
Due to vendor issues, we here have been moving back and forth between
31-bit and 64-bit SLES9, using the LPAR to Virtual Servers Redbook as
our guide. We're settled (for now) on 64-bit, after being told that
this will never, ever change, that the ports and migrations we're going
to move to
James,
lsmod
cat /etc/modprobe.conf
find /sys -name *0.0.9000*
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
James Melin
Sent: Monday, October 10, 2005 10:11 AM
To: LINUX-390@VM.MARIST.EDU
Subject: After creation of SLES-9 system network
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
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
-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
snip
be only one line of
Matt,
It might be. I know that the s390x distribution does have a s390
directory with some 31-bit RPMs in it, and it might be seeing some sort
of conflict there.
If you had been using YOU, there are a couple of log files you can look
at to see what's going on:
/var/log/YaST2/y2log*
Matt,
Due to vendor issues, we here have been moving back and forth
between 31-bit and 64-bit SLES9, using the LPAR to Virtual
Servers Redbook as our guide.
Do you have two controllers? Because of the churn of moving from 31-bit
to 64-bit, some folks are in the same situation you are.
Looks like something got spanked during the patch installation process.
I've gone to re-creating the thing as I want to understand the failure
mode. Hopefully I can re-create this.
Post, Mark K
[EMAIL PROTECTED]
m
James,
Looks like something got spanked during the patch installation process.
Just checking the obvious - your ID still has privilege to the VSWITCH,
correct? (Q VSWITCH VSW1 ACC)
Mike MacIsaac [EMAIL PROTECTED] (845) 433-7061
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
One of the better aspects of the CPINT package is /dev/diag8
(or /dev/cpint8). You can use it as a character file
(that is, write commands to it, read responses from it)
but you can also perform ioctl() to recover the return code.
vmcp has the same capability. You can open the devicenode
On Oct 10, 2005, at 2:31 PM, Gregg, Jim wrote:
I have SUSE 9 running in an LPAR for testing purposes. We are
swapping out
our Hitachi 3390-9 DASD for IBM ESS 3390-9 and need to move all of
the DASD
volumes. I tried using DFDSS/DFHSM with no success. Is there a way
to use
LINUX commands to move
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On
Behalf Of Gregg, Jim
Sent: Monday, October 10, 2005 2:32 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Move DASD volume from one device to a new one.
I have SUSE 9 running in an LPAR for testing purposes. We are
You missed the point.
The point is that neither 'vmcp' nor /dev/vmcp offer even a hint of
the underlying DIAG interface. Both 'vmcp' and /dev/vmcp obscure
the DIAG interface from the very programmers who should see it.
In the CPINT case, yes, 'hcp' hides the DIAG details.
That's as it
I copy DASD volumes all the time from our z/OS system. However I use FDR
Full Volume Copy. However, DF/DSS should do the same. If you run in native
lpar, it gets a little harder. He are my procedures that I always use:
___ Have good Linux backups
___ Logon to linux LPAR
___ Modify
On Monday, 10/10/2005 at 09:57 ZE2, Christian Borntraeger
[EMAIL PROTECTED] wrote:
Ah, now I get you. You are moving beyond cpint/vmcp and you want a
generic
diagnose interface which currently does not exist, right?
At least I havent found a diag8 device in cpint which does not hide
details.
What sort of problem(s) did you run into? If you make sure you copy
from cylinder 0 out you should be OK. Just make sure the Linux system
is completely down when you do the dump to tape.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Gregg,
Ah, now I get you. You are moving beyond cpint/vmcp and you want a
generic diagnose interface which currently does not exist, right?
Yes. That's close enough. You do get it now.
At least I havent found a diag8 device in cpint which does not hide
details.
Am I still missing your
Noone noticed that mke2fs is missing after fdasd??
You made only a partition, and you have no filelesystem, on it!
But you can also dump/restore a dasd volume with ADRDSSU with ALLX option.
My thoughts were to dasdfmt, fdasd, mount volume, copy / to new volume.
Then
what about the boot
53 matches
Mail list logo
