Re: Moving ethernet.

[Mark Post]

Steve,

One more caveat, I guess.  If this is a CHPID that has not been defined to
this LPAR before, you're going to need to either do a POR, or configure it
online to the LPAR from the service console.  This has caused a few people
problems in the past (just this month, I believe.)

Mark Post

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of
Steve Bui
Sent: Friday, December 20, 2002 3:32 PM
To: [EMAIL PROTECTED]
Subject: Re: Moving ethernet.


Thank you very much, Mark.

S.B.


-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED]] On Behalf Of Mark
Post
Sent: Friday, December 20, 2002 1:25 PM
To: [EMAIL PROTECTED]
Subject: Re: Moving ethernet.


Steve,

You should only need to update the contents of /etc/modules.conf to make
sure the addresses specified there are correct.  There may not be any
specified, if you allowed the driver to auto detect the card.  As long as
the only thing changing in your I/O configuration is the address of the
card, you should be fine.  Otherwise, or just to be sure, specify the
addresses anyway.  (I like to do that anyway, just to document things.)

If you ever move to a 2.4 kernel, you'll need to be concerned about the
contents of /etc/chandev.conf, but in your case that's not necessary now.

Mark Post

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of
Steve Bui
Sent: Friday, December 20, 2002 1:38 PM
To: [EMAIL PROTECTED]
Subject: Moving ethernet.


We have a need to move our current ethernet to a different chpid and
different address (cua), and is wondering what needs to be done in Linux
(SuSE 2.2.16)? Thanks for any help.

 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Steve Bui , IRIS - IBM Systems Support Mgr.
Phone(480) 965-3070 / fax(480) 965-6317

Re: gigabit OSA qeth timeout

[Mark Post]

Jan,

Show us what you're specifying in your parmfile, or as input to the
installation scripts.  (I would recommend that you put all the information
possible into the parmfile.  It can eliminate having to answer any questions
during the network setup phase of the install.)

Mark Post

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Jan
As
Sent: Friday, December 20, 2002 7:59 AM
To: [EMAIL PROTECTED]
Subject: gigabit OSA qeth timeout


I want to use our OSA Gigabit adapter.
Everytime the qeth wants to initialize it, i can read the following message:

(...)
qeth: Trying to use card with devnos 0x9500/0x9501/0x9502
 qeth: IDX_ACTIVATE(rd) on read channel irq 0x1c: timeout
 qeth: There were problems in hard-setting up the card.
(...)

I tried it in both LPAR and z/VM.
I tried RH72 Kernel 2.4.9-17 and 2.4.9-38 with OCO qeth und qdio modules.
I tried 2.4.17 with OCOs.
The OCOs in various versions. The last one was
qeth: loading qeth S/390 OSA-Express driver ($Revision: 1.136.6.3
$/$Revision: 1.53.6.2 $/$Revision: 1.18.6.1 $)

Well, I don't have any ideas any more! :-
Do you have any ideas maybe???
Please help!!!

The Hipersockets work with the same modules greatly!!!

Thanks in advance
and merry x-mas

Jan As

--
__
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Meet Singles
http://corp.mail.com/lavalife

Re: Moving ethernet.

[Steve Bui]

Thank you very much, Mark.

S.B.


-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED]] On Behalf Of Mark
Post
Sent: Friday, December 20, 2002 1:25 PM
To: [EMAIL PROTECTED]
Subject: Re: Moving ethernet.


Steve,

You should only need to update the contents of /etc/modules.conf to make
sure the addresses specified there are correct.  There may not be any
specified, if you allowed the driver to auto detect the card.  As long as
the only thing changing in your I/O configuration is the address of the
card, you should be fine.  Otherwise, or just to be sure, specify the
addresses anyway.  (I like to do that anyway, just to document things.)

If you ever move to a 2.4 kernel, you'll need to be concerned about the
contents of /etc/chandev.conf, but in your case that's not necessary now.

Mark Post

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of
Steve Bui
Sent: Friday, December 20, 2002 1:38 PM
To: [EMAIL PROTECTED]
Subject: Moving ethernet.


We have a need to move our current ethernet to a different chpid and
different address (cua), and is wondering what needs to be done in Linux
(SuSE 2.2.16)? Thanks for any help.

 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Steve Bui , IRIS - IBM Systems Support Mgr.
Phone(480) 965-3070 / fax(480) 965-6317

Re: Moving ethernet.

[Mark Post]

Steve,

You should only need to update the contents of /etc/modules.conf to make
sure the addresses specified there are correct.  There may not be any
specified, if you allowed the driver to auto detect the card.  As long as
the only thing changing in your I/O configuration is the address of the
card, you should be fine.  Otherwise, or just to be sure, specify the
addresses anyway.  (I like to do that anyway, just to document things.)

If you ever move to a 2.4 kernel, you'll need to be concerned about the
contents of /etc/chandev.conf, but in your case that's not necessary now.

Mark Post

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of
Steve Bui
Sent: Friday, December 20, 2002 1:38 PM
To: [EMAIL PROTECTED]
Subject: Moving ethernet.


We have a need to move our current ethernet to a different chpid and
different address (cua), and is wondering what needs to be done in Linux
(SuSE 2.2.16)? Thanks for any help.

 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Steve Bui , IRIS - IBM Systems Support Mgr.
Phone(480) 965-3070 / fax(480) 965-6317

Re: RAMAC Virtual Array Full !!

[Mark D Pace]

># 2) remove the heading and root| tail +3
># 3) squeeze out unwanted blanks| tr -s ' '
># 4) use gawk to generate a line for each mounted
># file system of the form

Something I have never thought about.  In the script   tail +3  removes the
header and the line for the / fs.  Why?  Is there some reason you should
not do this to the / fs?   I modified the script to +2 so to get all fs's.
Am I opening myself up to problems?



Mark D Pace
Senior Systems Engineer
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317
[EMAIL PROTECTED]
Office: 850.219.5184
Fax: 850.219.5050
http://www.mainline.com

Moving ethernet.

[Steve Bui]

We have a need to move our current ethernet to a different chpid and
different address (cua), and is wondering what needs to be done in Linux
(SuSE 2.2.16)? Thanks for any help.

 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Steve Bui , IRIS - IBM Systems Support Mgr.
Phone(480) 965-3070 / fax(480) 965-6317

Re: Claw Driver problems

[Alan Altmark]

On Friday, 12/20/2002 at 02:20 EST, Mark Post <[EMAIL PROTECTED]> wrote:
> Paul,
>
> Glad you could jump in here, since you can speak with a whole lot more
> authority on this than most.  I did hear back from my co-worker, and he
> provided a somewhat different set of definitions that also seem to work:
>
> IODEVICE ADDRESS=(1000,128),CUNUMBR=(B000),STADET=Y,UNIT=SCTC
> CNTLUNIT CUNUMBR=B000,PATH=(B0),UNITADD=((00,128)),UNIT=SCTC

Mark, UNIT=SCTC is needed for ESCON-attached routers.  For parallel
attachment, use UNIT=3088 on CNTLUNIT and UNIT=CTC on IODEVICE.

Alan Altmark
Sr. Software Engineer
IBM z/VM Development

Re: Adding an additional network interface (OSA-Express)

[Mark Post]

Daniel,

I'm not sure why they recommend deleting the modules.dep file.  Simply
running "depmod -a" will completely rebuild the file, based on what's
currently in the /lib/modules/ hierarchy.  Which is the answer to your other
question, too.  If you decide to back out your changes, simply re-run depmod
and you should be all set.

Mark Post

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of
Daniel Jarboe
Sent: Friday, December 20, 2002 8:50 AM
To: [EMAIL PROTECTED]
Subject: Adding an additional network interface (OSA-Express)


RH 7.2 in an LPAR.  Currently connected to network via CTC to z/OS
gateway.
We'd like to try out the OSA-Express card with the linux LPAR.  It's in
QDIO mode, and is being used by one other z/OS LPAR right now.

According to the Large Scale Linux Deployment redbook (sg246824), on
page 79-80 (97-98 in the pdf file), with EMIF two LPARs can use the same
device channels to communicate to the OSA adapter.  Is there any reason
NOT to do this?

Also, at the IBM OCO RH page
(http://www10.software.ibm.com/developerworks/opensource/linux390/specia
l_oco_rh_2.4.shtml)
It states:
delete the old module dependencies using: rm -f
/lib/modules/2.4.9-38*/modules.dep

Do the dependencies get rebuilt on the insmod qeth or some other time?
After I'm done trying it out, removing the OCO modules and deleting the
modules.dep files will effectively have me back where I was before (or
should I restore the old modules.dep files)?

Thanks,
~ Daniel





---

This message is the property of Time Inc. or its affiliates. It may be
legally privileged and/or confidential and is intended only for the use
of the addressee(s). No addressee should forward, print, copy, or
otherwise reproduce this message in any manner that would allow it to be
viewed by any individual not originally listed as a recipient. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is strictly prohibited. If you have received this communication
in error, please immediately notify the sender and delete this message.
Thank you.

Re: RAMAC Virtual Array Full !!

[Mark D Pace]

I had forgotten about that script.   Here is a before and after running
that script.

SIBADMIN QUERY MINIDISK(DEV(201) USER(sles001) NCL DRCT(YES))
Userid   Vdev Volser Rdev  Cyls Start Type   SSname   FDID Physical-MB
Ratio
SLES001   201 LNX006 C00A  1669 1 33903  MLRVA010A 735.359
1.9:1
Ready; T=0.05/0.05 13:19:08

SIBADMIN QUERY MINIDISK(DEV(201) USER(sles001) NCL DRCT(YES))
Userid   Vdev Volser Rdev  Cyls Start Type   SSname   FDID Physical-MB
Ratio
SLES001   201 LNX006 C00A  1669 1 33903  MLRVA010A 496.488
2.9:1
Ready; T=0.05/0.05 13:21:39


That's a pick of 238MB on a 1669 cyl drive.


Mark D Pace
Senior Systems Engineer
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317
[EMAIL PROTECTED]
Office: 850.219.5184
Fax: 850.219.5050
http://www.mainline.com

Re: Claw Driver problems

[Mark Post]

Paul,

Glad you could jump in here, since you can speak with a whole lot more
authority on this than most.  I did hear back from my co-worker, and he
provided a somewhat different set of definitions that also seem to work:

IODEVICE ADDRESS=(1000,128),CUNUMBR=(B000),STADET=Y,UNIT=SCTC
CNTLUNIT CUNUMBR=B000,PATH=(B0),UNITADD=((00,128)),UNIT=SCTC

Mark Post

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of
Paul Winder
Sent: Friday, December 20, 2002 4:48 AM
To: [EMAIL PROTECTED]
Subject: Re: Claw Driver problems


Tom,
The claw driver expects to see the c7000 as a 3088.

If you cat /proc/subchannels you should see something like:
Device sch.  Dev Type/Model CU  in use  PIM PAM POM LPUM CHPIDs
--
33A4   00103088/61  yes 80  80  FF  80   9FFF 
33A5   00113088/61  yes 80  80  FF  80   9FFF 

The driver expects a CU type of 0x3088 and a CU model of 0x61

At UTS Global our c7000's are genned as:
C#9F CHPID PATH=9F,TYPE=CNC,PART=(VM1,REC)
*
CU9F01   CNTLUNIT PATH=9F,CUNUMBR=9F01,UNITADD=((00,256)), +
UNIT=CISCO
  IODEVICE CUNUMBR=9F01,ADDRESS=(3300,256),UNIT=CISCO

Regards
Paul Winder

Re: Hercules and Redhat s/390

[Steve Kotzmoyer]

Heinrich,

I have Redhat 7.2 (s/390) running with Hercules, but it has been a
while since I installed.  I suggest checking with the gurus at
hercules-390.  Good luck.

Steve Kotzmoyer

On Fri, 20 Dec 2002 16:46:16 +0200
 Heinrich Venter <[EMAIL PROTECTED]> wrote:
>Can anybody help?
>
>
>
>I'm trying to load Red Hat 7.2 on the Hercules emulator but get the
>following error:
>
>
>
>"Unable to determine geometry of file/device /tmp/dasda.  You should
>not use
>Parted unless you REALLY know what you're doing."
>
>
>
>The emulator starts up fine and I get into the Red Hat installation.
>
>
>
>I've done everything according to the
>http://www.linuxvm.org/Info/HOWTOs/hercules.html
>  howto.
>
>
>
>If I ignore this error it goes on to format the dasda drive but
>directly
>afterwards I get an error saying that the device doesn't exist.
>
>
>
>Regards
>
>
>
>Heinrich Venter
>
>Design Centre
>
>South African Revenue Services
>
>Tel: +27 12 452 5016
>
>Fax: +27 12 452 5070
>
>Cell: +27 82 652 7874
>
>E-mail: [EMAIL PROTECTED] 
>
>
>
>The information transmitted is intended only for the person or
>entity to
>which it is addressed and may contain confidential and/or privileged
>material.  Any review, retransmission, dissemination or other use of
>or
>taking of any action in reliance upon, this information by persons
>or
>entities other than the intended recipient is prohibited.   If you
>received
>this in error, please contact the sender and delete the material
>from any
>computer.

Steve Kotzmoyer
TCP/IP Monitor Development
Landmark Systems

2002-12-19 Code drop to DeveloperWorks

[Gerhard Hiller]

Please see the "What's New" page at:

http://www10.software.ibm.com/developerworks/opensource/linux390/whatsnew.shtml
for a change summary of the 2002-12-19 additions and changes to the
Linux for S/390 and zSeries DeveloperWorks-pages.

- New OCO modules for both kernel 2.4 "streams", Red Hat and SuSE

- Experimental modutils 2.4.22 biarch patch for the "May 2002 stream"

- Performance Hints & Tips on the HowTo page.





Happy downloading!

* end of message

Mit freundlichem Gruß / Kind regards,
Gerhard Hiller

eServer Software Management, D4357
IBM Development Lab, Boeblingen
Phone ext. (+49) 7031 - 16 - 4388
Internet: [EMAIL PROTECTED]

FW: Open Source Software for z/OS and OS/390

[Rich Blair]

-Original Message-
From: Bill Lalonde [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 20, 2002 6:19 AM
To: [EMAIL PROTECTED]
Subject: Open Source Software for z/OS and OS/390


The open source tools are back online.
See page http://www.ibm.com/servers/eserver/zseries/zos/unix/redbook/
This page also contains a link to a copy of the associated Redbook at
http://www.ibm.com/servers/eserver/zseries/zos/unix/redbook/sg245944.pdf

 Bill

__
Post your free ad now! http://personals.yahoo.ca

--
For MVS-OE subscribe / signoff / archive access instructions, send email to
[EMAIL PROTECTED] with the message: INFO MVS-OE

Re: RAMAC Virtual Array Full !!

[Ledbetter, Scott E]

Here is the situation.

There is currently no utility that will actually free up unused space in a
Linux file system that resides on an RVA.  The physical management of data
in an RVA is done at a track granularity.  This is fine for MVS because
physical management of freespace in MVS is done at a track level.  In VM and
Linux, freespace is basically managed at a byterange granularity.  For CMD
minidisks, there is a utility called SIBRUB that will write compressible
data into free areas of CMS minidisks.  There is also a system extension
called SIBVMCUR that will do the same thing whenever a CMS minidisk is
accessed.  There is no equivalent for Linux.

DO NOT run the 'RELEASE MINIDISK' command unless you want to wipe out your
data.  RELEASE MINIDISK tells the RVA that all tracks allocated to the
minidisk can be blown away.  If you are managing things at a full volume
level, this is the RVA freespace management equivalent of deleting a volume
and redefining it.

For Linux, freespace can be recovered by writing NULLS into areas of the
filesystem that are marked as 'free' in whatever filesystem you are using.
This works because all data in an RVA is compressed when it passes over the
channel interface, and writing long strings of binary zeros into the free
areas of the files systems uses much less space in the storage unit.  Jim
Sibley of IBM posted a neat shell script to do this.  Hopefully he doesn't
mind my posting it again.  No warrantee expressed or implied by anyone, but
I have used it and it does work.

#!/bin/bash
# sample script to write zeroes on the end of all
# mounted ext2 volumes then remove file to compress RVA
# volumes.  [EMAIL PROTECTED]
#
# No warranty given or implied by the author or IBM.
# Use at your own risk
#
# 1) display the local ext2 files   df -l -t ext2
# 2) remove the heading and root| tail +3
# 3) squeeze out unwanted blanks| tr -s ' '
# 4) use gawk to generate a line for each mounted
# file system of the form
#
# dd bs=1k count="$4" if=/dev/zero of="$6"/zeroes;rm "$6"/zeroes"
#
#   where   $4 is the fourth column (available space)
#   $6 is the sixth column (mount point)
#
# | gawk -F ' ' '{print "dd bs=1k count="$4" if=/dev/zero of="$6"/zeroes;rm
"$6"/zeroes"}'
#
# 5) execute the script | /bin/bash
#you could delete this command if you just want to see the script
generated
#or write it to a file write to a file
#
# the actual command is a single line of code!
df -l -t ext2 | tail +3 | tr -s ' ' | gawk -F ' ' '{print "dd bs=1k
count="$4" if=/dev/zero of="$6"/zeroes;rm "$6"/zeroes"}' | /bin/bash


Use of this script does not require IXFP.  I kind of doubt IBM will sell you
IXFP for VM at this point, but the equivalent StorageTek product is called
SVAA for VM, and it will work with any Iceberg/RVA/STK SVA storage unit.
(The RVA and associated software was developed by StorageTek, and the
technology still lives on today three generations advanced in the SVA V2X
storage unit.)  It would not be a bad idea to get SVAA for VM so that you
can at least manage your CMS minidisks and monitor your NCL (Net Capacity
Load, the "gas gauge" for an RVA).

Scott Ledbetter
StorageTek








-Original Message-
From: Ashley Chaloner [mailto:[EMAIL PROTECTED]]
Sent: December 20, 2002 4:11 AM
To: [EMAIL PROTECTED]
Subject: RAMAC Virtual Array Full !!


Our RVA is full and we don't know how to get the usage back down. The IBM
documentation is ... less than helpful.

We've offline'd 6 (out of 256) DASD, which dropped the usage by 0.5%, but
we'd like it to get it little further down than that.

Boths LPARs hung (got hanged?) and refused to re-IPL, with no error
message at all.

We have tried deallocating DASD ('DETach 10E0 SYSTEM') and labelling
them as "FREE", or putting a clean CMS filesystem on, but to no avail. In
fact, everything tried so far makes the usage creep up by 0.02% every hour
or so.

I'm told "IXFP" might be the thing we need, but I'm also told it only
knows about CMS filesystems, so Linux deleted stuff never gets freed up by
the RVA.

Any help much appreciated.

Ashley Chaloner.

and just for the archives, in case anyone searches for this, before the
system hang, we got the "information" message "CACHE MODERATE ALERT",
which in our case meant disk unit full, which then made both LPARs fall
over. And refuse to re-IPL.

Re: RAMAC Virtual Array Full (not any more)

[Dave Jones]

- Original Message -
From: "Ashley Chaloner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 20, 2002 8:52 AM
Subject: Re: RAMAC Virtual Array Full (not any more)


> Thanks very much, usage now down to 90% after releasing 32 minidisks of
> 3338 cylinders each.
>
> The SIBADMIN QUERY command fails though, with:
> SIB4807E   User not authorized to execute CP diagnose 0E4 function 1.
>
> Any ideas?
>
Ashley, the user id that you are using to issue the SIBADMIN QUERY command
must have the  DEVINFO or DEVMAINT options of the OPTION directory control
statement set in it's USER DIRECT entry.

DJ

Re: RAMAC Virtual Array Full !!

[Holger Smolinski]

We recommend to allocate any available space on a filesystem by a
file containing all zeroes and delete it immediately:
dd if=/dev/zero of= bs=1M; rm ; sync;

That will at least grant a maximum RVA compression ratio of 1:25 for
unused storage.

Best Regards
Holger Smolinski
--
Dr. Holger Smolinski, Linux on zSeries Service
IBM Deutschland Entwicklung GmbH,Schönaicher Str. 220, 71032 Böblingen
FAX: +49-7031-16-3456, Tel. +49-7031-16-4652


|-+>
| |   Ashley Chaloner  |
| |   <[EMAIL PROTECTED]|
| |   k.ac.uk> |
| |   Sent by: Linux on|
| |   390 Port |
| |   <[EMAIL PROTECTED]|
| |   IST.EDU> |
| ||
| ||
| |   20.12.02 12:11   |
| |   Please respond to|
| |   Linux on 390 Port|
| ||
|-+>
  
>--|
  |
  |
  |   To:   [EMAIL PROTECTED]
  |
  |   cc:  
  |
  |   Subject:  RAMAC Virtual Array Full !!
  |
  |
  |
  |
  |
  
>--|



Our RVA is full and we don't know how to get the usage back down. The IBM
documentation is ... less than helpful.

We've offline'd 6 (out of 256) DASD, which dropped the usage by 0.5%, but
we'd like it to get it little further down than that.

Boths LPARs hung (got hanged?) and refused to re-IPL, with no error
message at all.

We have tried deallocating DASD ('DETach 10E0 SYSTEM') and labelling
them as "FREE", or putting a clean CMS filesystem on, but to no avail. In
fact, everything tried so far makes the usage creep up by 0.02% every hour
or so.

I'm told "IXFP" might be the thing we need, but I'm also told it only
knows about CMS filesystems, so Linux deleted stuff never gets freed up by
the RVA.

Any help much appreciated.

Ashley Chaloner.

and just for the archives, in case anyone searches for this, before the
system hang, we got the "information" message "CACHE MODERATE ALERT",
which in our case meant disk unit full, which then made both LPARs fall
over. And refuse to re-IPL.

Re: RAMAC Virtual Array Full (not any more)

[Ashley Chaloner]

Thanks very much, usage now down to 90% after releasing 32 minidisks of
3338 cylinders each.

The SIBADMIN QUERY command fails though, with:
SIB4807E   User not authorized to execute CP diagnose 0E4 function 1.

Any ideas?

Anyway, thanks again Hank and Mark.

Ashley Chaloner.

On Fri, 20 Dec 2002, Hank Calzaretta wrote:

> The following procedure can be used if you have IXFP installed on VM.  This
> will release the backend storage for a given minidisk defined in the VM
> directory:
>
> ATT  to SYSTEM(this is the real address of the RVA ECAM
> device used for communication)
> Logon to user MAINTSTK
> LINK USERNAME   MW(USERNAME is the owner of the minidisk)
> ACC 454 I (454 is where the IXFP software is installed
> on my system)
> SIBADMIN RELEASE MINIDISK(DEV())
> SIBADMIN QUERY MINIDISK(DEV() USER(MAINT) NCL DRCT(YES))
>

Re: HTTPD server won't stay up

[Davis, Lawrence]

Thanks, Sergey

Mine was set to 2 rather than 10, I will see if all is OK next time I
reboot.

Larry Davis

-Original Message-
From: Sergey Korzhevsky [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 16, 2002 05:48
To: [EMAIL PROTECTED]
Subject: Re: HTTPD server won't stay up


If you use SLES7, try to increase timeout in

/etc/rc.config.d/apache.rc.config

HTTPD_START_TIMEOUT=40  (was 10)



WBR, Sergey




"Davis, Lawrence" <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port <[EMAIL PROTECTED]>
13.12.2002 21:53
Please respond to Linux on 390 Port


To: [EMAIL PROTECTED]
cc:
Subject:HTTPD server won't stay up


I am seeing my HTTPD server starting in the console

Starting Name Service Cache Daemon
..done
Starting inetd
..done
Starting httpd [
LDAP PERL ]
..done
Master Resource Control: runlevel 5 has been reached

but when I try to connect I get connection refused as though the server is
not running.
If I manually start the apache web server it comes up fine. before I
started
httpd I did not see anything with netstat -a that showed http anything
listening. After the manual start I saw http-www listening

tcp0  0 *:www-http  *:* LISTEN
550/httpd

Any Suggestions on where I can look to help with more information.

\|/
(. .)
TIA, ___ooO-(_)-Ooo___, Larry Davis

Hercules and Redhat s/390

[Heinrich Venter]

Can anybody help?



I'm trying to load Red Hat 7.2 on the Hercules emulator but get the
following error:



"Unable to determine geometry of file/device /tmp/dasda.  You should not use
Parted unless you REALLY know what you're doing."



The emulator starts up fine and I get into the Red Hat installation.



I've done everything according to the
http://www.linuxvm.org/Info/HOWTOs/hercules.html
  howto.



If I ignore this error it goes on to format the dasda drive but directly
afterwards I get an error saying that the device doesn't exist.



Regards



Heinrich Venter

Design Centre

South African Revenue Services

Tel: +27 12 452 5016

Fax: +27 12 452 5070

Cell: +27 82 652 7874

E-mail: [EMAIL PROTECTED] 



The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.

Re: RAMAC Virtual Array Full !!

[Mark D Pace]

There is not an IXFP user.  You can run any from any  guest that has access
to the SIB routines and linked to the ECAM device.

Here is an EXEC I use to get a report.You will need R/W links to your
ECAM device.

/* */
Trace off
Queue 'msg * Report Started'
Queue 'sibadmin'
Queue 'listcfg subsys(subsys(*) level(1))'
Queue 'end'
Queue 'msg * Report Complete'
Exit



Mark D Pace
Senior Systems Engineer
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317
[EMAIL PROTECTED]
Office: 850.219.5184
Fax: 850.219.5050
http://www.mainline.com



Ashley Chaloner
<[EMAIL PROTECTED]   To: [EMAIL PROTECTED]
ick.ac.uk>cc:
Sent by: LinuxSubject: Re: RAMAC Virtual Array Full !!
on 390 Port
<[EMAIL PROTECTED]
ARIST.EDU>


12/20/2002
09:03 AM
Please respond
to Linux on 390
Port






On Fri, 20 Dec 2002 [EMAIL PROTECTED] wrote:
> With IXFP you have the ability to delete a functional device (VM Volume)
> which will totally remove any backend storage.  Doing a CMS format of a
> volume stills leaves a few megabytes of backend storage.   You can also
get
> reports that will show the amount space used on each functional devices.
> You may find that some volumes still have data on them that you were not
> aware of.

Listing how much each functional device is being used would be great,
because before I started working here, a lot of snapdisk was done, so I'd
rather get rid of real data than snapshots that aren't taking up much
space. But how do I do that ? There's no IXPF user, but I did find loads
of SIB* EXEC files on one of MAINTSTK's disks, is that something to do
with it?

Is there no Rexx script that simply issues RVA commands to colect all free
space now? or a way to remove all backend storage associated with DASD
labelled as FREE?

(Or, if there exists a Linux utility to do this, that would be even
better.)

The problem is, as with normal HD defragmenting, it's difficult to
defragment with no free space, and our usage now reads 99.402%. The RVA
documentation reccomends 75% usage...  so we'd like to force some
deletions as it's unlikely the RVA will want to defragment or tidy itself
up.

Thanks again for the help.

Ashley Chaloner.

Re: RAMAC Virtual Array Full !!

[Hank Calzaretta]

The following procedure can be used if you have IXFP installed on VM.  This
will release the backend storage for a given minidisk defined in the VM
directory:

ATT  to SYSTEM(this is the real address of the RVA ECAM
device used for communication)
Logon to user MAINTSTK
LINK USERNAME   MW(USERNAME is the owner of the minidisk)
ACC 454 I (454 is where the IXFP software is installed
on my system)
SIBADMIN RELEASE MINIDISK(DEV())
SIBADMIN QUERY MINIDISK(DEV() USER(MAINT) NCL DRCT(YES))




Hank Calzaretta
Wallace Computer Services, Inc.



-Original Message-
From: Ashley Chaloner [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 20, 2002 5:11 AM
To: [EMAIL PROTECTED]
Subject: RAMAC Virtual Array Full !!


Our RVA is full and we don't know how to get the usage back down. The IBM
documentation is ... less than helpful.

We've offline'd 6 (out of 256) DASD, which dropped the usage by 0.5%, but
we'd like it to get it little further down than that.

Boths LPARs hung (got hanged?) and refused to re-IPL, with no error message
at all.

We have tried deallocating DASD ('DETach 10E0 SYSTEM') and labelling them as
"FREE", or putting a clean CMS filesystem on, but to no avail. In fact,
everything tried so far makes the usage creep up by 0.02% every hour or so.

I'm told "IXFP" might be the thing we need, but I'm also told it only knows
about CMS filesystems, so Linux deleted stuff never gets freed up by the
RVA.

Any help much appreciated.

Ashley Chaloner.

and just for the archives, in case anyone searches for this, before the
system hang, we got the "information" message "CACHE MODERATE ALERT", which
in our case meant disk unit full, which then made both LPARs fall over. And
refuse to re-IPL.

gigabit OSA qeth timeout

[Jan As]

I want to use our OSA Gigabit adapter.
Everytime the qeth wants to initialize it, i can read the following message:

(...)
qeth: Trying to use card with devnos 0x9500/0x9501/0x9502
 qeth: IDX_ACTIVATE(rd) on read channel irq 0x1c: timeout
 qeth: There were problems in hard-setting up the card.
(...)

I tried it in both LPAR and z/VM.
I tried RH72 Kernel 2.4.9-17 and 2.4.9-38 with OCO qeth und qdio modules.
I tried 2.4.17 with OCOs.
The OCOs in various versions. The last one was
qeth: loading qeth S/390 OSA-Express driver ($Revision: 1.136.6.3 $/$Revision: 
1.53.6.2 $/$Revision: 1.18.6.1 $)

Well, I don't have any ideas any more! :-
Do you have any ideas maybe???
Please help!!!

The Hipersockets work with the same modules greatly!!!

Thanks in advance
and merry x-mas

Jan As

--
__
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Meet Singles
http://corp.mail.com/lavalife

Re: Adding an additional network interface (OSA-Express)

[Alan Altmark]

On Friday, 12/20/2002 at 08:50 EST, Daniel Jarboe
<[EMAIL PROTECTED]> wrote:
> RH 7.2 in an LPAR.  Currently connected to network via CTC to z/OS
> gateway.
> We'd like to try out the OSA-Express card with the linux LPAR.  It's in
> QDIO mode, and is being used by one other z/OS LPAR right now.
>
> According to the Large Scale Linux Deployment redbook (sg246824), on
> page 79-80 (97-98 in the pdf file), with EMIF two LPARs can use the same
> device channels to communicate to the OSA adapter.  Is there any reason
> NOT to do this?

It is a fine thing to do.  With shared OSAs, everyone using the OSA must
specify the same port name.  Just make sure you specify the port name in
UPPERCASE in the Linux config.  The value to use is on the PORTNAME= parm
in the z/OS VTAM TRLE definition for the OSA.

Alan Altmark
Sr. Software Engineer
IBM z/VM Development

Re: RAMAC Virtual Array Full !!

[Ashley Chaloner]

On Fri, 20 Dec 2002 [EMAIL PROTECTED] wrote:
> With IXFP you have the ability to delete a functional device (VM Volume)
> which will totally remove any backend storage.  Doing a CMS format of a
> volume stills leaves a few megabytes of backend storage.   You can also get
> reports that will show the amount space used on each functional devices.
> You may find that some volumes still have data on them that you were not
> aware of.

Listing how much each functional device is being used would be great,
because before I started working here, a lot of snapdisk was done, so I'd
rather get rid of real data than snapshots that aren't taking up much
space. But how do I do that ? There's no IXPF user, but I did find loads
of SIB* EXEC files on one of MAINTSTK's disks, is that something to do
with it?

Is there no Rexx script that simply issues RVA commands to colect all free
space now? or a way to remove all backend storage associated with DASD
labelled as FREE?

(Or, if there exists a Linux utility to do this, that would be even
better.)

The problem is, as with normal HD defragmenting, it's difficult to
defragment with no free space, and our usage now reads 99.402%. The RVA
documentation reccomends 75% usage...  so we'd like to force some
deletions as it's unlikely the RVA will want to defragment or tidy itself
up.

Thanks again for the help.

Ashley Chaloner.

Adding an additional network interface (OSA-Express)

[Daniel Jarboe]

RH 7.2 in an LPAR.  Currently connected to network via CTC to z/OS
gateway.
We'd like to try out the OSA-Express card with the linux LPAR.  It's in
QDIO mode, and is being used by one other z/OS LPAR right now.

According to the Large Scale Linux Deployment redbook (sg246824), on
page 79-80 (97-98 in the pdf file), with EMIF two LPARs can use the same
device channels to communicate to the OSA adapter.  Is there any reason
NOT to do this?

Also, at the IBM OCO RH page
(http://www10.software.ibm.com/developerworks/opensource/linux390/specia
l_oco_rh_2.4.shtml)
It states:
delete the old module dependencies using: rm -f
/lib/modules/2.4.9-38*/modules.dep

Do the dependencies get rebuilt on the insmod qeth or some other time?
After I'm done trying it out, removing the OCO modules and deleting the
modules.dep files will effectively have me back where I was before (or
should I restore the old modules.dep files)?

Thanks,
~ Daniel





---

This message is the property of Time Inc. or its affiliates. It may be
legally privileged and/or confidential and is intended only for the use
of the addressee(s). No addressee should forward, print, copy, or
otherwise reproduce this message in any manner that would allow it to be
viewed by any individual not originally listed as a recipient. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is strictly prohibited. If you have received this communication
in error, please immediately notify the sender and delete this message.
Thank you.

Re: RAMAC Virtual Array Full !!

[Steve Gentry]

Something you didn't mention if you had done.  IIRC, the RAMAC's will
automatically do a "defrag" (I don't remember the IBM term for this) from
time to time.  It seems that there is also some way to force it to do a
defrag.  Have you considered this?
Regards,
Steve G.

Re: RAMAC Virtual Array Full !!

[Mark . Pace]

With IXFP you have the ability to delete a functional device (VM Volume)
which will totally remove any backend storage.  Doing a CMS format of a
volume stills leaves a few megabytes of backend storage.   You can also get
reports that will show the amount space used on each functional devices.
You may find that some volumes still have data on them that you were not
aware of.

If you have OS390 and VM - get the OS390 version.  It is kept current.



Mark D Pace
Senior Systems Engineer
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317
[EMAIL PROTECTED]
Office: 850.219.5184
Fax: 850.219.5050
http://www.mainline.com



Ashley Chaloner
<[EMAIL PROTECTED]   To: [EMAIL PROTECTED]
ick.ac.uk>cc:
Sent by: LinuxSubject: RAMAC Virtual Array Full !!
on 390 Port
<[EMAIL PROTECTED]
ARIST.EDU>


12/20/2002
06:11 AM
Please respond
to Linux on 390
Port






Our RVA is full and we don't know how to get the usage back down. The IBM
documentation is ... less than helpful.

We've offline'd 6 (out of 256) DASD, which dropped the usage by 0.5%, but
we'd like it to get it little further down than that.

Boths LPARs hung (got hanged?) and refused to re-IPL, with no error
message at all.

We have tried deallocating DASD ('DETach 10E0 SYSTEM') and labelling
them as "FREE", or putting a clean CMS filesystem on, but to no avail. In
fact, everything tried so far makes the usage creep up by 0.02% every hour
or so.

I'm told "IXFP" might be the thing we need, but I'm also told it only
knows about CMS filesystems, so Linux deleted stuff never gets freed up by
the RVA.

Any help much appreciated.

Ashley Chaloner.

and just for the archives, in case anyone searches for this, before the
system hang, we got the "information" message "CACHE MODERATE ALERT",
which in our case meant disk unit full, which then made both LPARs fall
over. And refuse to re-IPL.

Re: FW: InfoWorld Article: German City Drops Windows for Linux

[Phil Payne]

> SCHWDBISCH HALL, A community of 36,000 in southern Germany, plans to build
> its entire IT infrastructure on the open source Linux operating system,
> replacing Windows from Microsoft Corp.

Not the first.  Schwdbish Hall is a particulary beautiful place, too -
much more worthy of a visit than somewhere boring like Heidelberg.

RAMAC Virtual Array Full !!

[Ashley Chaloner]

Our RVA is full and we don't know how to get the usage back down. The IBM
documentation is ... less than helpful.

We've offline'd 6 (out of 256) DASD, which dropped the usage by 0.5%, but
we'd like it to get it little further down than that.

Boths LPARs hung (got hanged?) and refused to re-IPL, with no error
message at all.

We have tried deallocating DASD ('DETach 10E0 SYSTEM') and labelling
them as "FREE", or putting a clean CMS filesystem on, but to no avail. In
fact, everything tried so far makes the usage creep up by 0.02% every hour
or so.

I'm told "IXFP" might be the thing we need, but I'm also told it only
knows about CMS filesystems, so Linux deleted stuff never gets freed up by
the RVA.

Any help much appreciated.

Ashley Chaloner.

and just for the archives, in case anyone searches for this, before the
system hang, we got the "information" message "CACHE MODERATE ALERT",
which in our case meant disk unit full, which then made both LPARs fall
over. And refuse to re-IPL.

Re: Yet Another IBM Conspiracy Theory

[Mainframe Support at welton.de]

> >Did it mention Hercules? If not, Phil will have to come up with some 
other
>> conspiracy theory to explain its withdrawal.
 
>They don't delete the book for that - they just expunge all the
>references.
 
>And then those that delight in intellectual property theft infringe
>their copyright by continuing to distribute it.
 
>Not likely to win them as friends.

Personally I always thought that Hercules was a software offering from 
IBM Global Solutions, see (probably wrapped):

http://www8.software.ibm.com/solutions/isv/igssg.nsf/AllSolutionsbyID/4EB9FD02B331C9788625681700302760?OpenDocument

or 

http://www.qed.co.nz

-- 

MfG / Best Regards

Sebastian Welton

www.welton.de
-

Re: Claw Driver problems

[Paul Winder]

Tom,
The claw driver expects to see the c7000 as a 3088.

If you cat /proc/subchannels you should see something like:
Device sch.  Dev Type/Model CU  in use  PIM PAM POM LPUM CHPIDs
--
33A4   00103088/61  yes 80  80  FF  80   9FFF 
33A5   00113088/61  yes 80  80  FF  80   9FFF 

The driver expects a CU type of 0x3088 and a CU model of 0x61

At UTS Global our c7000's are genned as:
C#9F CHPID PATH=9F,TYPE=CNC,PART=(VM1,REC)
*
CU9F01   CNTLUNIT PATH=9F,CUNUMBR=9F01,UNITADD=((00,256)), +
   UNIT=CISCO
 IODEVICE CUNUMBR=9F01,ADDRESS=(3300,256),UNIT=CISCO

Regards
Paul Winder