Re: virtual hipersockets
On Thursday, 10/21/2004 at 04:17 AST, GWillis <[EMAIL PROTECTED]> wrote: > I am having a spot of trouble configuring virtual hipersockets. I have it > working to the extent that I can communicate between z/VM 4.3.0 and Debian > Linux s390 (kernel 2.4.19) however, I cannot communicate between Linux, and > the outside network. I'm hoping someone can point me in the right direction > to fix this. [snip] > ifconfig > ZVMETH0 inet addr: 10.1.1.90 mask: 255.255.0.0 > UP BROADCAST MULTICAST MTU: 1500 > vdev: 0E00 rdev: 0E00 type: QDIO ETHERNET portname: ETH0 > router type: NONROUTER > > HIPERLA0 inet addr: 10.8.1.95 P-t-P: 10.8.1.93 mask: 255.255.255.255 > UP MULTICAST POINTOPOINT MTU: 1500 > vdev: 0FA0 type: HIPERS > LAN owner: TCPIP name: NERAC1 1) HIPERLA0 is a LAN, not a point-to-point connection. While this p2p route will work ok for the first Linux guest, you'll get in trouble when you add another. Define an entire subnet to for use on the virtual hipersocket LAN. 2) The symptom you describe usually indicates that the external routers do not know to route 10.8.1.93 to 10.1.1.90. So, packets find their way out into the network just fine, but they can't find their way back again. Alan Altmark Sr. Software Engineer IBM z/VM Development -- 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
Betr.: Re: virtual hipersockets
[EMAIL PROTECTED] 21-10-04 22:43 >>> >Keeping in mind that I know nothing about z/VM TCP/IP configuration, the >Point-to-Point value (and netmask) on this response to the ifconfig command >would seem to be very wrong to me: >HIPERLA0 inet addr: 10.8.1.95 P-t-P: 10.8.1.93 mask: 255.255.255.255 > UP MULTICAST POINTOPOINT MTU: 1500 > >Hipersockets are in no way a point-to-point connection. I agree Hipersockets probably shouldn't be point-to-point, but that is what is in the PROFILE TCPIP: GATEWAY 10.8.1.93 = HIPERLA0 1500 HOST Host does mean 255.255.255.255. You more likely want it to be: 10.8.1.93 = HIPERLA0 1500 0.0.255.0 0.0.1.0 or somemthing like that, depending on what you addressing scheme is. As Geoff has local connections, it is likely a routine problem. The link itself is there or you wouldn't have any comm at all. Next step would be to verify what is actually in the routing table on Linux with the command: route Especially look for a default route to the world. If it is not there you will have only local subnet connections. With the route command you can also play with routing before putting it in a fixed config.. Thanks, Geoff Here are my definitions; TCPIP startup; CP DEFINE LAN NERAC1 CP DEFINE NIC FA0 CP COUPLE FA0 TO TCPIP NERAC1 Linux startup; CP DEFINE NIC FA4 CP COUPLE FA4 TO TCPIP NERAC1 q lan nerac1 details LAN TCPIP NERAC1 Type: HIPERS Active: 2 MAXCONN: INFINITE TRANSIENT UNRESTRICTED MFS: 16384 ACCOUNTING: OFF Adapter Owner: LIN999 NIC: 0FA4 Name: UNASSIGNED 10.8.1.93 224.0.0.1 Adapter Owner: TCPIPNIC: 0FA0 Name: HIPERPA0 10.1.1.90 10.1.1.97 10.8.1.95 224.0.0.1 Profile.tcpip; DEVICE [EMAIL PROTECTED] OSD 0E00 PORTNAME ETH0 NONROUTER LINK ZVMETH0 QDIOETHERNET [EMAIL PROTECTED] DEVICE HIPERDA0 HIPERS FA0 PORTNAME HIPERPA0 AUTORESTART LINK HIPERLA0 QDIOIP HIPERDA0 HOME 10.1.1.90 ZVMETH0 10.8.1.95 HIPERLA0 GATEWAY 10 = ZVMETH0 1500 0.255.0.0 0.1.0.0 DEFAULTNET 10.1.0.254 ZVMETH0 1500 0 10.8.1.93 = HIPERLA0 1500 HOST START [EMAIL PROTECTED] START HIPERDA0 ifconfig ZVMETH0 inet addr: 10.1.1.90 mask: 255.255.0.0 UP BROADCAST MULTICAST MTU: 1500 vdev: 0E00 rdev: 0E00 type: QDIO ETHERNET portname: ETH0 router type: NONROUTER HIPERLA0 inet addr: 10.8.1.95 P-t-P: 10.8.1.93 mask: 255.255.255.255 UP MULTICAST POINTOPOINT MTU: 1500 vdev: 0FA0 type: HIPERS LAN owner: TCPIP name: NERAC1 Linux /etc/network/interfaces 1 # Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or 2 # /usr/share/doc/ifupdown/examples for more information. 3 auto hsi1 9 iface hsi1 inet static 10 address 10.8.1.93 11 netmask 255.255.0.0 12 up ifconfig hsi1 mtu 1500 13 up route add default gw 10.8.1.95 hsi1 14 up ifconfig lo 127.0.0.1 15 down route del -net default hsi1 ifconfig hsi1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:10.8.1.93 Mask:255.255.0.0 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:604 (604.0 b) Interrupt:17 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:560 (560.0 b) TX bytes:560 (560.0 b) -- 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 Best regards, Pieter Harder [EMAIL PROTECTED] tel +31-73-6837133 / +31-6-47272537 -- 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: virtual hipersockets
Keeping in mind that I know nothing about z/VM TCP/IP configuration, the Point-to-Point value (and netmask) on this response to the ifconfig command would seem to be very wrong to me: HIPERLA0 inet addr: 10.8.1.95 P-t-P: 10.8.1.93 mask: 255.255.255.255 UP MULTICAST POINTOPOINT MTU: 1500 Hipersockets are in no way a point-to-point connection. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of GWillis Sent: Thursday, October 21, 2004 4:17 PM To: [EMAIL PROTECTED] Subject: virtual hipersockets Hello, I am having a spot of trouble configuring virtual hipersockets. I have it working to the extent that I can communicate between z/VM 4.3.0 and Debian Linux s390 (kernel 2.4.19) however, I cannot communicate between Linux, and the outside network. I'm hoping someone can point me in the right direction to fix this. Thanks, Geoff Here are my definitions; TCPIP startup; CP DEFINE LAN NERAC1 CP DEFINE NIC FA0 CP COUPLE FA0 TO TCPIP NERAC1 Linux startup; CP DEFINE NIC FA4 CP COUPLE FA4 TO TCPIP NERAC1 q lan nerac1 details LAN TCPIP NERAC1 Type: HIPERS Active: 2 MAXCONN: INFINITE TRANSIENT UNRESTRICTED MFS: 16384 ACCOUNTING: OFF Adapter Owner: LIN999 NIC: 0FA4 Name: UNASSIGNED 10.8.1.93 224.0.0.1 Adapter Owner: TCPIPNIC: 0FA0 Name: HIPERPA0 10.1.1.90 10.1.1.97 10.8.1.95 224.0.0.1 Profile.tcpip; DEVICE [EMAIL PROTECTED] OSD 0E00 PORTNAME ETH0 NONROUTER LINK ZVMETH0 QDIOETHERNET [EMAIL PROTECTED] DEVICE HIPERDA0 HIPERS FA0 PORTNAME HIPERPA0 AUTORESTART LINK HIPERLA0 QDIOIP HIPERDA0 HOME 10.1.1.90 ZVMETH0 10.8.1.95 HIPERLA0 GATEWAY 10 = ZVMETH0 1500 0.255.0.0 0.1.0.0 DEFAULTNET 10.1.0.254 ZVMETH0 1500 0 10.8.1.93 = HIPERLA0 1500 HOST START [EMAIL PROTECTED] START HIPERDA0 ifconfig ZVMETH0 inet addr: 10.1.1.90 mask: 255.255.0.0 UP BROADCAST MULTICAST MTU: 1500 vdev: 0E00 rdev: 0E00 type: QDIO ETHERNET portname: ETH0 router type: NONROUTER HIPERLA0 inet addr: 10.8.1.95 P-t-P: 10.8.1.93 mask: 255.255.255.255 UP MULTICAST POINTOPOINT MTU: 1500 vdev: 0FA0 type: HIPERS LAN owner: TCPIP name: NERAC1 Linux /etc/network/interfaces 1 # Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or 2 # /usr/share/doc/ifupdown/examples for more information. 3 auto hsi1 9 iface hsi1 inet static 10 address 10.8.1.93 11 netmask 255.255.0.0 12 up ifconfig hsi1 mtu 1500 13 up route add default gw 10.8.1.95 hsi1 14 up ifconfig lo 127.0.0.1 15 down route del -net default hsi1 ifconfig hsi1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:10.8.1.93 Mask:255.255.0.0 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:604 (604.0 b) Interrupt:17 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:560 (560.0 b) TX bytes:560 (560.0 b) -- 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: Sigh.. is it really too much trouble to check the terminal ty pe?
> On Thu, 21 Oct 2004, Alan Cox wrote: > > $TERM during init depends upon what the init scripts set. > Red Hat for > > example basically assumes "linux console" unless you are > running over a > > serial port in which case I believe it uses "dumb" > > Right. > That's where the problem lies. > RH (not alone, but for example) makes this assumption > in cases where it is not true. Perhaps detecting 'uname -m' and > varying based on that might help? I don't like it, but > it'd be a start. Possible solution (s): Add entry in /etc/ttytype for 'console' to be 'dumb' as the default on all distributions. Update this value during installation for the Intel or other ANSI compliant distributions. In the common header used by the scripts, use 'tset -m' to initialize the $TERM variable to the correct value and process accordingly. Then the Intel install can do the Right Thing and have cute ANSI stuff, and the non-ANSI versions can not have to filter. -- 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
virtual hipersockets
Hello, I am having a spot of trouble configuring virtual hipersockets. I have it working to the extent that I can communicate between z/VM 4.3.0 and Debian Linux s390 (kernel 2.4.19) however, I cannot communicate between Linux, and the outside network. I'm hoping someone can point me in the right direction to fix this. Thanks, Geoff Here are my definitions; TCPIP startup; CP DEFINE LAN NERAC1 CP DEFINE NIC FA0 CP COUPLE FA0 TO TCPIP NERAC1 Linux startup; CP DEFINE NIC FA4 CP COUPLE FA4 TO TCPIP NERAC1 q lan nerac1 details LAN TCPIP NERAC1 Type: HIPERS Active: 2 MAXCONN: INFINITE TRANSIENT UNRESTRICTED MFS: 16384 ACCOUNTING: OFF Adapter Owner: LIN999 NIC: 0FA4 Name: UNASSIGNED 10.8.1.93 224.0.0.1 Adapter Owner: TCPIPNIC: 0FA0 Name: HIPERPA0 10.1.1.90 10.1.1.97 10.8.1.95 224.0.0.1 Profile.tcpip; DEVICE [EMAIL PROTECTED] OSD 0E00 PORTNAME ETH0 NONROUTER LINK ZVMETH0 QDIOETHERNET [EMAIL PROTECTED] DEVICE HIPERDA0 HIPERS FA0 PORTNAME HIPERPA0 AUTORESTART LINK HIPERLA0 QDIOIP HIPERDA0 HOME 10.1.1.90 ZVMETH0 10.8.1.95 HIPERLA0 GATEWAY 10 = ZVMETH0 1500 0.255.0.0 0.1.0.0 DEFAULTNET 10.1.0.254 ZVMETH0 1500 0 10.8.1.93 = HIPERLA0 1500 HOST START [EMAIL PROTECTED] START HIPERDA0 ifconfig ZVMETH0 inet addr: 10.1.1.90 mask: 255.255.0.0 UP BROADCAST MULTICAST MTU: 1500 vdev: 0E00 rdev: 0E00 type: QDIO ETHERNET portname: ETH0 router type: NONROUTER HIPERLA0 inet addr: 10.8.1.95 P-t-P: 10.8.1.93 mask: 255.255.255.255 UP MULTICAST POINTOPOINT MTU: 1500 vdev: 0FA0 type: HIPERS LAN owner: TCPIP name: NERAC1 Linux /etc/network/interfaces 1 # Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or 2 # /usr/share/doc/ifupdown/examples for more information. 3 auto hsi1 9 iface hsi1 inet static 10 address 10.8.1.93 11 netmask 255.255.0.0 12 up ifconfig hsi1 mtu 1500 13 up route add default gw 10.8.1.95 hsi1 14 up ifconfig lo 127.0.0.1 15 down route del -net default hsi1 ifconfig hsi1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:10.8.1.93 Mask:255.255.0.0 inet6 addr: fe80::200:ff:fe00:0/10 Scope:Link UP RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:604 (604.0 b) Interrupt:17 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:560 (560.0 b) TX bytes:560 (560.0 b) -- 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: SLES9 installation problem - again
> When I chose option 3 I was asked for 3 devices. The devices > I gave (1200-1202) were not acceptable. > I don't want to use QDIO at this time. Non-qdio should be > supported according to evrything I've read. Not on the gigE cards. You don't have a choice -- if it's really a gigE card, then you must define it as a QDIO device and use QDIO. That's been the situation since the gigE cards were released. If you were using this card with the LCS driver on SLES8, it's not a gigE card. -- 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
SLES9 and TSM Manager
Is anyone aware if TSM Manager for Linux is supported for SLES9 s390x? Or do I have to run SLES8? Regards, Darren -- 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: Sigh.. is it really too much trouble to check the terminal ty pe?
On Thu, 21 Oct 2004, Alan Cox wrote: > This sounds a good basis if I understand S/390 console at all (which I > don't really I'll admit). Care to file it in bugzilla.redhat.com ? Perhaps Dave Boyes will hit bugzilla. Dave? -- 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: Sigh.. is it really too much trouble to check the terminal ty pe?
> During system init, is there actually a $TERM to be queried? The init scripts don't actually run >at a "terminal", do they? Just a thought, and may be showing my ignorance... There's output on /dev/console, which should/does have a $TERM. On Intel, the scripts do tabs and cursor positioning and text color changes and all kinds of useless stuff like that. That obviously *shouldn't* happen if the terminal type is not something that can actually handle the commands. Yes, it's boring to look at. I don't care. It's a pain to have to filter that garbage out when you're trying to do automation or hunt a problem. --d b -- 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: Sigh.. is it really too much trouble to check the terminal ty pe?
On Iau, 2004-10-21 at 17:11, Richard Troth wrote: > Right. > That's where the problem lies. > RH (not alone, but for example) makes this assumption > in cases where it is not true. Perhaps detecting 'uname -m' and > varying based on that might help? I don't like it, but it'd be a start. This sounds a good basis if I understand S/390 console at all (which I don't really I'll admit). Care to file it in bugzilla.redhat.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
Sigh.. is it really too much trouble to check the terminal ty pe?
The problem, of course, is that the ANSI sequences (on an x86 machine
and others with an "ansi mapped display") make the boot-up process look
"pretty" by reporting success/failure of each stage in a "clear" fashion.
That being said, for the x86 versions, doing an
ssh [EMAIL PROTECTED] "cd /etc/init.d && ./named
restart"
(Yes, yes, I know there are better ways to do this) no ANSI sequences
are returned.
All right, so that's using SuSE 8.2 and it's not on a zSeries.
-soup
John R. Campbell, Speaker to Machines (GNUrd) {813-356|697}-5322
Adsumo ergo raptus sum
MacOS X: Because making Unix user-friendly was easier than debugging
Windows.
Red Hat Certified Engineer (#803004680310286)
IBM Certified: IBM AIX 4.3 System Administration, System Support
- Forwarded by John Campbell/Tampa/IBM on 10/21/2004 12:20 PM -
David Boyes
<[EMAIL PROTECTED]To: [EMAIL PROTECTED]
e.net> cc:
Sent by: Linux onSubject: Re: [LINUX-390] Sigh.. is it
really too much trouble to check the terminal
390 Port ty pe?
<[EMAIL PROTECTED]
IST.EDU>
10/21/2004 11:13
AM
Please respond to
Linux on 390 Port
> It should always honour the setting of $TERM. Make sure your network
> login tool correctly propogated $TERM and a suitable value.
It does work properly for normal logins. The problem I'm complaining
about is messages generated by init during boot.
Either $TERM is not being set properly for /dev/console during the boot
process, or the init scripts are ignoring it and just spewing ANSI
terminal command sequences without checking whether the device is
capable of executing them. The latter may be the case, as when I do
explicitly set a $TERM of "dumb" or "tty" in the script, I still get
ANSI sequences.
IMHO, the Right Thing (tm) is to assume during boot that $TERM is "tty"
until and unless probed and/or explicitly told otherwise. Easy enough to
do in the console initialization scripts, and is just good programming
practice (good software development rule 10DC: never use a hardware
feature without probing for it first). I know I've given the Debian
folks a ton of grief about this, but it'd be nice to fix it across the
board.
-- 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: Sigh.. is it really too much trouble to check the terminal ty pe?
On Thu, 21 Oct 2004, Alan Cox wrote: > $TERM during init depends upon what the init scripts set. Red Hat for > example basically assumes "linux console" unless you are running over a > serial port in which case I believe it uses "dumb" Right. That's where the problem lies. RH (not alone, but for example) makes this assumption in cases where it is not true. Perhaps detecting 'uname -m' and varying based on that might help? I don't like it, but it'd be a start. -- 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: SLES9 installation problem - again
> 1. Try option 3 - this did not work. The GigE OSA cannot be used with the LCS driver, so option 2 will never work. The GigE OSA must be defined as a QDIO device, so you probably should go back to the IOCP/IODF and make sure it's defined as such. -- 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: Pointing to a DNS server
To get anything newer, you'll need to contact Novell/SUSE, or one of their business partners. Depending on whether your predecessor actually bought SLES7 or not, you might have been entitled to a free copy of SLES8. You might want to check that out. Asking which distribution is "best" is at best kind of useless, and as you seem to know, frequently inflammatory. No one has quite the same mix of business concerns/needs as you. What's important to you may not be to me. Too bad you missed SHARE in New York back in August. You could have gotten a lot of in-person networking done on questions like this. Much easier than via email and mailing lists. For some time, SUSE had about 80% of the mainframe Linux market because they were there first. Since that time, Red Hat has been closing the gap, but I don't know by how much. Technically speaking, they're both good platforms. I would say that what differentiates them are their contract and support terms. If you want to try a non-Red Hat version of Red Hat, also known as a "work-alike," there are a couple out there for S/390 and zSeries. The one that most people here have played with is Tao Linux, http://www.taolinux.org/ . It was rebuilt from the source RPMs that Red Hat makes available on their download servers. SUSE doesn't do that for it's SLES products, so there isn't a "no cost" equivalent for them. Other no-cost distributions include Debian/390, http://www.debian.org/ , and my mainframe version of Slackware, http://www.slack390.org/ . I'm going to be writing an article for zJournal about all this, but it won't be coming out until next year, so that won't help you much. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Herczeg, Zoltan Sent: Thursday, October 21, 2004 9:52 AM To: [EMAIL PROTECTED] Subject: Re: Pointing to a DNS server -snip- On the topic of new releases, how can one get a new distribution of the latest release of Suse Linux for S/390? I know this next question may border on asking about religion and politics but what is the best distribution for the S/390 platform? -snip- -- 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: Sigh.. is it really too much trouble to check the terminal ty pe?
> It should always honour the setting of $TERM. Make sure your network > login tool correctly propogated $TERM and a suitable value. It does work properly for normal logins. The problem I'm complaining about is messages generated by init during boot. Either $TERM is not being set properly for /dev/console during the boot process, or the init scripts are ignoring it and just spewing ANSI terminal command sequences without checking whether the device is capable of executing them. The latter may be the case, as when I do explicitly set a $TERM of "dumb" or "tty" in the script, I still get ANSI sequences. IMHO, the Right Thing (tm) is to assume during boot that $TERM is "tty" until and unless probed and/or explicitly told otherwise. Easy enough to do in the console initialization scripts, and is just good programming practice (good software development rule 10DC: never use a hardware feature without probing for it first). I know I've given the Debian folks a ton of grief about this, but it'd be nice to fix it across the board. -- 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: Pointing to a DNS server
On Thursday, 10/21/2004 at 09:52 AST, "Herczeg, Zoltan" <[EMAIL PROTECTED]> wrote: > On the topic of new releases, how can one get a new distribution > of the latest release of Suse Linux for S/390? You have to buy one from SUSE. > I know this next question > may border on asking about religion and politics but what is the best > distribution for the S/390 platform? I have a MP3000 so I guess I could > load a distribution from CD? No. The CD in a MP3000 requires special magic on the CD in order to emulate a 3422 tape drive. The Linux CDs don't have the magic. > I am currently running under lpars no VM My condolences. ;-) Alan Altmark Sr. Software Engineer IBM z/VM Development -- 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
Bastille compilation failure ....
This problem was identified and fixed months ago. The patches were slow to find their way to the light of day but check out SUSE bugzilla 33754 , you should see there are two patches for Bastille attached to this bugzilla - one for SLES8 and one for SLES9. Regards, Peter Linux for zSeries Security Design IBM System Integrity Competency Center zSeries Software System Design Group -- Date:Wed, 20 Oct 2004 13:50:21 -0400 From:Terry Spaulding <[EMAIL PROTECTED]> Subject: Bastille compilation failure Has anyone seen this failure during the InteractiveBastille compilation ? System is SuSE SLES8 Linux for zSeries (31 bit) w/fixpack 3 applied. -- 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: Pointing to a DNS server
Thank you that fixed it for me! I was missing the SuSEconfig process. I am running an old release of Linux because it came installed on the box and the project I am working on is a proof of concept and Linux is brand new to me. I feel like I am learning to walk again after working with VM and VSE for so many years. Once I prove Linux can be of value to us I can then justify the time and money to put in to this project. On the topic of new releases, how can one get a new distribution of the latest release of Suse Linux for S/390? I know this next question may border on asking about religion and politics but what is the best distribution for the S/390 platform? I have a MP3000 so I guess I could load a distribution from CD? I am currently running under lpars no VM :(( Again thanks for the help. Zoltan -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Post, Mark K Sent: Wednesday, October 20, 2004 5:48 PM To: [EMAIL PROTECTED] Subject: Re: Pointing to a DNS server This sounds like a SUSE system. If it is SLES8, updating /etc/rc.config is not the way to make the change. Use YaST instead. If it is SLES7 (in which case _why_ are you running something that old?), make sure to run the SuSEconfig process after updating /etc/rc.config. In either case, you should see the update reflected in /etc/resolv.conf afterwards. Mark Post -- 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: Sigh.. is it really too much trouble to check the terminal ty pe?
On Iau, 2004-10-21 at 13:53, Nix, Robert P. wrote: > During system init, is there actually a $TERM to be queried? The init scripts don't > actually run at a "terminal", do they? Just a thought, and may be showing my > ignorance... $TERM during init depends upon what the init scripts set. Red Hat for example basically assumes "linux console" unless you are running over a serial port in which case I believe it uses "dumb" 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: Formatting and Partitioning on SLES 8
Having just done some of that last night try dasdfmt -f /dev/dasda -b 4096 -d cdl That formats the DEVICE. Then use fdasd to partition it. /dev/dasda1 will not exist until a partition is created. If you partition it in 3 pieces, you'd have /dev/dasda1 /dev/dasda2 /dev/dasda3 John Kaba <[EMAIL PROTECTED]> Sent by: Linux on To 390 Port [EMAIL PROTECTED] <[EMAIL PROTECTED] cc IST.EDU> Subject Formatting and Partitioning on SLES 10/20/2004 04:44 8 PM Please respond to Linux on 390 Port <[EMAIL PROTECTED] IST.EDU> Getting the following error when trying to format one of my disks: SuSE Instsys zlinux:/root # dasdfmt -f /dev/dasda1 -b 4096 -d cdl Drive Geometry: 400 Cylinders * 15 Heads = 6000 Tracks I am going to format the device /dev/dasda1 in the following way: Device number of device : 0x150 Labelling device: yes Disk label : VOL1 Disk identifier : 0X0150 Extent start (trk no) : 0 Extent end (trk no) : 5999 Compatible Disk Layout : yes Blocksize : 4096 --->> ATTENTION! <<--- All data of that device will be lost. Type "yes" to continue, no will leave the disk untouched: yes Formatting the device. This may take a while (get yourself a coffee). dasdfmt: (invalidate first track) IOCTL BIODASDFMT failed. (Invalid argument) SuSE Instsys zlinux:/root # Any suggestions? Thanks, John -- 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: DASD configuration for SuSE SLES 8
Thats right.. I already forgot our humble beginnings with the ramdisk installation! The one thing that does apply is the default assignment of devices starting with dasda, dasdb, etc. to the defined VM DASDs from low to high address order. This feature affects how you add DASD or split file systems in the future, especially if you want to stick new DASD addresses below those already defined. Ray Mrohs Energy Information Administration U.S. Department of Energy -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 3:30 PM To: [EMAIL PROTECTED] Subject: Re: DASD configuration for SuSE SLES 8 Because the installation process will handle all that for him. He won't have to this unless he changes his configuration in the future. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mrohs, Ray Sent: Wednesday, October 20, 2004 2:46 PM To: [EMAIL PROTECTED] Subject: Re: DASD configuration for SuSE SLES 8 You didn't mention updating zipl.conf. Your DASD address ranges have to go in there. Then you run zipl to activate it. After that (you may have to reboot), your disks will show up in /proc/dasd/devices, which shows the correlation of DASDs and Linux devices, i.e. 200 = dasda , 201 = dasdb , etc. Ray Mrohs Energy Information Administration U.S. Department of Energy -Original Message- From: John Kaba [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 4:41 PM To: [EMAIL PROTECTED] Subject: DASD configuration for SuSE SLES 8 Hello again, I now have the network configured, and can get to my installation media. Now I am ready to format my DASD. The installation manual refers me to the dasdfmt command in the Device Drivers and Installation Commands document, which I am currently looking at, however the examples don't really show me how this all relates to the minidisks that I have set up on my LINUX guest ID on VM, and it doesn't give any recommendations other than to format with a blocksize of 4KB. I am just wanting to set up Linux so that I can run SSL. I have defined 3 minidisks as per the example in the SuSE Installation manual with mdisk 201 defined as the home disk, mdisk 150 with 200 cyl. for the swap device, and 151 with 2800 cyl. for the linux installation. Any suggestions/recommendations on how to go about formatting and partitioning these for this installation? John -- 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 -- 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: Sigh.. is it really too much trouble to check the terminal ty pe?
During system init, is there actually a $TERM to be queried? The init scripts don't actually run at a "terminal", do they? Just a thought, and may be showing my ignorance... -- Robert P. Nix 507-284-0844 Mayo Foundation 200 First St. SW Rochester, MN 55905 "In theory, theory and practice are the same, but in practice theory and practice are different." -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Wednesday, October 20, 2004 3:24 PM To: [EMAIL PROTECTED] Subject: Re: Sigh.. is it really too much trouble to check the terminal ty pe? IMHO, why should they? The application's been provided the information that the terminal is *not* ANSI -- the app (in this case the init script status reporting code) is just not paying attention. -- 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: [discuss] Re: [PATCH] Add key management syscalls to non-i386 archs
On Wed, 2004-10-20 16:04:50 -0700, David S. Miller <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Thu, 21 Oct 2004 00:56:25 +0200 > Andi Kleen <[EMAIL PROTECTED]> wrote: *VAX hacker's hat on* > I disagree quite strongly. One major frustration for users of > non-x86 platforms is that functionality is often missing for some > time that we can make trivial to keep in sync. Full ACK. > Simply put, if you're not watching the tree in painstaking detail > every day, you miss all of these enhancements. Right; and these missing enhancements will cause extra-pain when they're used some time later from core code. That is, you missed the feature while it was discusses/accepted and need to put it in place later on. So you've got to do extra searching etc. > The knowledge should come from the person putting the changes into > the tree, therefore it gets done once and this makes it so that > the other platform maintainers will find out about it automatically > next time they update their tree. Here's my proposal: $ mkdir ./Documentation/new_enhancements_to_implement $ cat ./Documentation/new_enhancements_to_implement/new_key_syscalls << EOF > Dear Architecture Maintailers, > > please add these four new cryptographic key functions to your syscall > table. It's quite easy; just extend the ./include/arch-xxx/unistd.h > for four new defines and then add them to your ./arch/xxx/kernel/entry.S > file. For reference, here's my i386 patch doing this: > > diff -Nurp > --- path-old/to/file/one > +++ path-new/to/file/one > text > -del > +add > more text > > > Thanks, your keychain hacker:-) > EOF $ This way, all arch maintainers just *see* what needs to be done and get a small introduction on how to do that. I'd *really* like to see that! That would particularly help those that cannot do full-time hacking on their port (like us VAX hackers:-) MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); -- 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 signature.asc Description: Digital signature
Re: [discuss] Re: [PATCH] Add key management syscalls to non-i386 archs
On Wed, 20 Oct 2004, David S. Miller wrote:
> On Thu, 21 Oct 2004 01:25:09 +0200
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > IMHO breaking the build unnecessarily is extremly bad because
> > it will prevent all testing. And would you really want to hold
> > up the whole linux testing machinery just for some obscure
> > system call? IMHO not a good tradeoff.
>
> Then change the unistd.h cookie from "#error" to a "#warning". It
> accomplishes both of our goals.
Please do so! And not only for syscalls, but also for other things.
That way we can procmail all mails sent to lkml or bk-commits-head that
add #warnings to arch// or include/asm-/.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: SLES9 installation problem - again
Hi, When I chose option 3 I was asked for 3 devices. The devices I gave (1200-1202) were not acceptable. I don't want to use QDIO at this time. Non-qdio should be supported according to evrything I've read. Gadi -Original Message- From: Istvan Nemeth [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 2:04 PM To: [EMAIL PROTECTED] Subject: Re: SLES9 installation problem - again Linux on 390 Port <[EMAIL PROTECTED]> Ãrta 2004.10.21 11:56:07 idÅpontban: > Hi Vic, > > Thanx for your response, but > > OSD and OSE are valid for the TYPE paramter. Only OSA and OSAD are > valid for the UNIT paramter. I'm really not a z/Hardware expert, but if you really have OSA-_EXPRESS_ then normally you need qdio driver(3) not lcs (2), and qdio driver should work. You did not gave us information what happened when you choose OSA-Express... > > As I said, this worked fine in SLES8. > > Also ^c does not work (at least from the HMC). > > Gadi > If you want to have a shell, just simply select option 0 (no network) in the main menu, so you can do a 'dmesg', etc.. Istvan -- 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: SLES9 installation problem - again
Linux on 390 Port <[EMAIL PROTECTED]> írta 2004.10.21 11:56:07 időpontban: > Hi Vic, > > Thanx for your response, but > > OSD and OSE are valid for the TYPE paramter. Only OSA and OSAD are > valid for the UNIT paramter. I'm really not a z/Hardware expert, but if you really have OSA-_EXPRESS_ then normally you need qdio driver(3) not lcs (2), and qdio driver should work. You did not gave us information what happened when you choose OSA-Express... > > As I said, this worked fine in SLES8. > > Also ^c does not work (at least from the HMC). > > Gadi > If you want to have a shell, just simply select option 0 (no network) in the main menu, so you can do a 'dmesg', etc.. Istvan -- 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: SLES9 installation problem - again
Hi Vic, Thanx for your response, but OSD and OSE are valid for the TYPE paramter. Only OSA and OSAD are valid for the UNIT paramter. As I said, this worked fine in SLES8. Also ^c does not work (at least from the HMC). Gadi -Original Message- From: Vic Cross [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 9:44 AM To: [EMAIL PROTECTED] Subject: Re: SLES9 installation problem - again On Thu, Oct 21, 2004 at 09:10:37AM +0200, ??? ?? ??? wrote: > My system has an OSA Express 1000Base-T which is configured using these IOCP > statements: > CHPID PATH=(CSS(0),02),SHARED,* >PARTITION=((LINTST,PROD,TEST),(=)),TYPE=OSE,* >PCHID=141 > CNTLUNIT CUNUMBR=1200,PATH=((CSS(0),02)),UNIT=OSA > IODEVICE ADDRESS=(1200,253),CUNUMBR=(1200),UNIT=OSA > IODEVICE ADDRESS=(12FE,1),CUNUMBR=(1200),UNIT=OSAD Technically, your CNTLUNIT and IODEVICE are incorrect[1]. Device type OSA and OSAD are for older OSAs like OSA-2. Use OSE or OSD instead -- unless you *really* want your OSA-Express to run in LCS mode, but I doubt that works. > I went back to the main menu and chose option 2 (Ethernet OSA). (This > worked in SLES8). I entered my first device address (1200) and waited. The message > that came up said: > Lcs: loading LCS driver ($ Revision: 1.72.2.4 $/$ Revision 1.15.2.2 $) > > And it's been like that for quite a while. > > What am I doing wrong? If your card is really an OSA-Express, do not use Option 2. It's loading the LCS module (as you can see) which is not correct for OSA-Express. > Suggestions I received: > 1. Try option 3 - this did not work. It should -- this might be your incorrect hardware definition causing a problem. > 2. Issue the dmesg command to look for more information - How do I > interrupt the configuration script so I can issue commands. You can issue "^c" (without the quotes) to simulate a Ctrl-C, which should break you out of the script and give you a prompt. Hope this helps, Vic Cross [1] I say *technically* incorrect because I have a system where I have an OSA-Express defined as OSA and it's okay. However this is a z/OS system, and the device type entries are only in the MVS definition not in the actual IOCDS. Why is it defined that way? Long story. :) -- 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: Formatting and Partitioning on SLES 8
On Wed, 20 Oct 2004 16:44:33 -0500, John Kaba <[EMAIL PROTECTED]> wrote: > SuSE Instsys zlinux:/root # dasdfmt -f /dev/dasda1 -b 4096 -d cdl > Drive Geometry: 400 Cylinders * 15 Heads = 6000 Tracks You mistake is the '1' in dasda1 - that's the first partition. You want to format the entire device, then run fdasd to make the entire thing into one partition, and then have the SuSE installer make a file system on that partition (dasda1). 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: SLES9 installation problem - again
On Thu, Oct 21, 2004 at 09:10:37AM +0200, ??? ?? ??? wrote: > My system has an OSA Express 1000Base-T which is configured using these IOCP > statements: > CHPID PATH=(CSS(0),02),SHARED,* >PARTITION=((LINTST,PROD,TEST),(=)),TYPE=OSE,* >PCHID=141 > CNTLUNIT CUNUMBR=1200,PATH=((CSS(0),02)),UNIT=OSA > IODEVICE ADDRESS=(1200,253),CUNUMBR=(1200),UNIT=OSA > IODEVICE ADDRESS=(12FE,1),CUNUMBR=(1200),UNIT=OSAD Technically, your CNTLUNIT and IODEVICE are incorrect[1]. Device type OSA and OSAD are for older OSAs like OSA-2. Use OSE or OSD instead -- unless you *really* want your OSA-Express to run in LCS mode, but I doubt that works. > I went back to the main menu and chose option 2 (Ethernet OSA). (This worked in > SLES8). I entered my first device address (1200) and waited. The message that came > up said: > Lcs: loading LCS driver ($ Revision: 1.72.2.4 $/$ Revision 1.15.2.2 $) > > And it's been like that for quite a while. > > What am I doing wrong? If your card is really an OSA-Express, do not use Option 2. It's loading the LCS module (as you can see) which is not correct for OSA-Express. > Suggestions I received: > 1. Try option 3 - this did not work. It should -- this might be your incorrect hardware definition causing a problem. > 2. Issue the dmesg command to look for more information - How do I interrupt the > configuration script so I can issue commands. You can issue "^c" (without the quotes) to simulate a Ctrl-C, which should break you out of the script and give you a prompt. Hope this helps, Vic Cross [1] I say *technically* incorrect because I have a system where I have an OSA-Express defined as OSA and it's okay. However this is a z/OS system, and the device type entries are only in the MVS definition not in the actual IOCDS. Why is it defined that way? Long story. :) -- 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
SLES9 installation problem - again
Hi, I am now trying to install SLES9. My system has an OSA Express 1000Base-T which is configured using these IOCP statements: CHPID PATH=(CSS(0),02),SHARED,* PARTITION=((LINTST,PROD,TEST),(=)),TYPE=OSE,* PCHID=141 CNTLUNIT CUNUMBR=1200,PATH=((CSS(0),02)),UNIT=OSA IODEVICE ADDRESS=(1200,253),CUNUMBR=(1200),UNIT=OSA IODEVICE ADDRESS=(12FE,1),CUNUMBR=(1200),UNIT=OSAD When I started the installation from the CD, I chose option 10 and listed all of the devices that linux knew about. I saw all of my dasd (devices 800-9ff) and device 1200,1201 and 12fe. Devices 1200 and 1201 were defined as 3088/60 and 12fe as 3088/62. I went back to the main menu and chose option 2 (Ethernet OSA). (This worked in SLES8). I entered my first device address (1200) and waited. The message that came up said: Lcs: loading LCS driver ($ Revision: 1.72.2.4 $/$ Revision 1.15.2.2 $) And it's been like that for quite a while. What am I doing wrong? Suggestions I received: 1. Try option 3 - this did not work. 2. Issue the dmesg command to look for more information - How do I interrupt the configuration script so I can issue commands. I am trying to install SLES9 in an LPAR. I do not have VM available. Gadi -- 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
VM & VSE & linux/390 Employment Web Page
Greetings; (Posted to VMESA-L and VSE-L and LINUX-390) - - Now in its sixth year! - - Includes VSE and linux/390! I have set up a public service web page at http://www.eskimo.com/~wix/vm/ for posting positions available and wanted for VM, VSE and linux/390. Please visit the web page for more information and feel free to send me any info you would like to have posted. Please make VM or VSE or linux/390 the first word in the subject. Questions and comments welcome! (Text or html OK. No java, gifs, .DOC, etc. NO RESUMES or CVs!) === Please check the web pages for === === examples before sending your ad! === Good luck, Dennis VM & VSE & linux/390 Positions Available last updated Oct 16. VM & VSE & linux/390 Positions Wanted last updated Oct 19. 176420 10/21/04 00:05:01 -- 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
