dcss2:~# mount /dev/dcssblk/USR /usr
mount /dev/dcssblk/USR /usr
dcss2:~# df
df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/dasd/0150/part1174248104572 60684 64% /
/dev/dasd/0151/part1396744360588 15676 96% /usr
/dev/dcssblk/USR396744
Well, the only guarantee I can offer is that it works for me
Which means, on *my* system, it can run before /usr is mounted.
All standard Linux distributions are made in a way like this. You have
everything needed to get up-and-running to the point where you mount
filesystems in /bin, /sbin,
I am new to Linux on 390 but not Linux. I was wondering if there is a
better file system to use when installing Linux on 390 on EMC DASD?
--
_
Thanks, Bob
YahooIM: bobif
AOLIM: bobifmd
ICQ: 111083556
MSN: [EMAIL PROTECTED]
MCSE and CNE trained,
Most (if not all) of the usual Linux filesystems are available with
Linux for zSeries (ext2, ext3, JFS, Reiser, GFS, AFS and others).
On Wed, 2004-02-18 at 05:07, Bob wrote:
I am new to Linux on 390 but not Linux. I was wondering if there is a
better file system to use when installing Linux on
Congrats, and thanks for your Honest and open Words in the past few Years.
Larry Davis
-Original Message-
From: David Boyes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 17, 2004 17:04 PM
To: [EMAIL PROTECTED]
Subject: OT: Scott Courtney selected as winner of 2003 NASPA Industry
but is there one that performs better with EMC DASD or are they all pretty
much the same performance-wise?
On Wed, 18 Feb 2004 06:09:01 -0600, Rich Smrcina [EMAIL PROTECTED]
wrote:
Most (if not all) of the usual Linux filesystems are available with
Linux for zSeries (ext2, ext3, JFS, Reiser, GFS,
On Wednesday 18 February 2004 14:30, Bob wrote:
but is there one that performs better with EMC DASD or are they all pretty
much the same performance-wise?
Choosing the file system depends almost exclusively on what kind of data
you want to put on it and is pretty independent of the manufacturer
Alan, Et al;
I'm getting this same error from one VM Guests, but not from any of the others.
The route tables are identical for all.
For me, the difference is, the VM Guest issuing the error is running Sambs, and
at boot, I see the error on the console, just after Samba is started.
Cheers;
Hi list,
An issue came up with file systems that have a lot of small files. This
question might be helpful given the current more generic thread on file
systems.
I did a small test to create 5 20 byte files. An ext3 file system
with the default 4096 block size is quite inefficient. while
Hi,
If I install a package using the configure/make method, how do I tell RPM
that the package is installed so that it will know about it?
Thanks.
So then if you do want to install a package using RPM that would need
another package that was installed manually, you would have to use the
--nodeps option to force the install?
For example, I had to install MySQL using the source. To do this, I had to
uninstall the older RPM installed version
The idea behind RPM is that you wrap the configure/make process with an RPM spec file,
and let RPM do it, then package up the resulting files. Of course, making the spec
file is a project in itself.
If you know all of the files that make up your package, you COULD make a skeleton spec
file
You don't.
Instead, you build an RPM from the sources that you have, and then
install the resulting binary RPM.
plug
For more details, attend Build Linux Packages with RPM, session 9239
at SHARE in Long Beach next Tuesday.
/plug
- Alex
Aria Bamdad wrote:
Hi,
If I install a package using the
Right, you can use nodeps to force an install, but if the original packages are
dependent on things like specific level shared libraries, you might find they don't
work quite right after.
You could have done rpm --erase --nodeps to remove mysql without removing the
dependent packages.
You
It becomes a quick decent into dependancy hell. The easiest in my view is
to either play the rpm game and let your vendor do all the heavy lifting.
Update a package when they do, etc. The other option is compile everything
from source and handle everything yourself.
-Original Message-
On Wed, 2004-02-18 at 05:07, Bob wrote:
I am new to Linux on 390 but not Linux. I was wondering if there is a
better file system to use when installing Linux on 390 on EMC DASD?
Better than what?
I tend to use ext3 for everything; the overhead versus ext2 is small,
and I like having a
My tsm client install seems to have worked; however, when attempting to
run dsmc and executing ldd dsmc I find that the libstdc++-libc6.2.2-2.so.3
not found.
Any idea where this library is or what package I might find it in and
where to get that package?
Thanks!
Eric Sammons
(804)697-3925
FRIT -
If you have SLES 8 the Media Kit will say
Linux for zSeries (this is the 64bit version) or
Linux for S/390 (this is the 32 bit version)
Be careful as many applications including DB2 UDB for Linux/390 do NOT
support 64 bit operation.
Even applications which may appear to work may not be
This is what I normally recommend for people who are not extremely familiar
with .spec files. It gives you a (hopefully) known working example to start
with. A lot of times, just tweaking the version numbers and removing
unnecessary patches are all that is needed. But, there is a lot more that
Unfortunately, I've found that a lot of the vendor packaged RPMS have local patches
and enhancements that complicate the spec files. Often the patches have to be
removed (or even worse, refitted)
to use a spec file with a higher level of the source tarball.
This is where the book comes in VERY
To All,
According to sources from the Boeblingen lab, 1k blocksizes have been
succesfully tested on SLES8 SP2 (at minimum) and are save to use in
production.
regards
Phil Tully
==
If you are not an intended recipient
On Wed, 2004-02-18 at 14:35, [EMAIL PROTECTED] wrote:
To All,
According to sources from the Boeblingen lab, 1k blocksizes have been
succesfully tested on SLES8 SP2 (at minimum) and are save to use in
production.
But obviously you would need to make sure that using 1k block size is
not going
You use the term inefficient to mean wasted space. Smaller block sizes tend to reduce
throughput, and use more CPU. This could also be called inefficient.
It is a trade off. I think the 4096 byte block size was chosen because the way the
Linux kernel works limits the block size to the page
Beware of the small blocks on ECKD images. In a 3390
image, there are 12 4K blocks/track or 49152 bytes.
There are 33 1K blocks/track or 33792 bytes! You could
lose up to 1/3 of your capacity using smaller block sizes!
=
Jim Sibley
RHCT, Implementor of Linux on zSeries
Computer are
Please see the What's New page at:
http://www10.software.ibm.com/developerworks/opensource/linux390/whatsnew.shtml
for a change summary of the 2004-02-18 additions and changes to the
Linux for zSeries and S/390 developerWorks Web pages.
Linux on zSeries Tuning Hits Tips pages
Happy reading!
There's a show stopper...
Why would it not fill the track?
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED]
Behalf Of Jim
Sibley
Sent: Wednesday, February 18, 2004 12:03 PM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] dasdfmt with a 1K block size - still not
RPM doesn't really do anything with source RPMs except unpack them when you
do an rpm -i command. It just dumps the contents into /SOURCES and
/SPECS, and quits. Once you do the rpmbuild command to create a new binary
rpm and install _that_, then RPM tracks the package.
Mark Post
Hence my comment that a lot more could be necessary. On the other hand,
if you're not up to doing that, then you shouldn't get started in the first
place. At that point, you are taking on the role of developer/packager,
which is a _bunch_ of work to do right. In a number of cases, those
Why would it not fill the track?
Ken,
at some point it gets down the electro-magneto-mechanical stuff.
Think of a mag tape. You write a block, maybe 8K. Then there's
a mag tape form of inter-record-gap. If you instead write a 1K block
the inter-record-gap is the same size. So on tape,
-Original Message-
From: Richard Troth [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 18, 2004 11:48 AM
To: [EMAIL PROTECTED]
Subject: Re: dasdfmt with a 1K block size - still not recommde d?
Why would it not fill the track?
snip
Real 3390 DASD are the same in this
Well, anyway, the original intent was to reclaim some of the space lost to file
tails by using a smaller blocksize, but it sounds like we'd lose more than we'd gain.
Mike was asking about this on our behalf. We had noticed that we weren't getting as
much space using ext3 as we had with reiser.
I'm not running Samba. Mine are RH AS 3.0. I've checked
/etc/sysconfig/network-scripts/ifcfg-eth0 and the output from ifconfig -a
and my netmasks look correct. I create my images by DDRing my disks, so
whatever the original problem was has been copied to a second server.
Betsie
- Original
-Original Message-
From: Hall, Ken (IDS ECCS) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 18, 2004 12:01 PM
To: [EMAIL PROTECTED]
Subject: Re: dasdfmt with a 1K block size - still not recommde d?
Well, anyway, the original intent was to reclaim some of the
space lost to
...
MVS and its successors know how 3390 track geometry is supposed
to work. So the emulated DASD controller must emulate the overhead
so that too much data does not go onto an emulated track.
Things like TRKCALC and other access methods depend on an
emulated track only getting x blocks
On my slackware (Intel) I always used the 'configure, make, make install'
process. It worked flawlessly everytime. This way I always got the latest
software. With RPMs I have had problems and then I had to go under the
hood. RPM's are usually behind since there is a process to build the RPM
and
Is this after you built Tomcat from source? Usually the configure,make
process detects the presence of Apache header files and links it in. I
have not done Tomcat myself but a similar one for Perl called mod_perl.
Rich Smrcina [EMAIL PROTECTED]
Sent by: Linux on 390 Port [EMAIL PROTECTED]
Ken, Mike, ...
Ask whoever is providing DASD to your systems
if they can offer anything FBA. Just ask. Can't hurt.
The worst you'll get is the deer-in-the-headlights response.
The physical blocksize for VDISK (which is emulated from
VM host memory) is 512 bytes. Should reduce your loss in
Unfortunately, we needed a quicker solution. We've been working on and off for about
a year trying to get fcp working with no luck. (The problems have all been on the
hardware side.)
The info about block sizes, etc. couldn't have come at a better time. We just had a
meeting to discuss how
What FCP problems have you been having? We've been working fine using:
1. McData Switch
2. ESS 2105-F20/ESS 2105-800
3. EMC-8730
-Original Message-
Unfortunately, we needed a quicker solution. We've been working on and off
for about a year trying to get fcp working with no luck. (The
Like I said, the problems have all been on the hardware side. The guys who manage it
haven't been able to get the port names, etc. properly defined so we can see them.
Our attempts have been
intermittent with long delays in between due to other priorities.
So by hardware, I guess I actually
On Wednesday, 02/18/2004 at 10:38 PST, Jim Sibley
[EMAIL PROTECTED] wrote:
I can see some other issues with 1k blocks. What would
happen if you make the swap (page) packs 1K? Would it
even work. With files over 4k, there would also be a
loss in I/O efficiency - 4 times as much I/O would be
As long as you have to use a 3390 track image with
ECKD mapping, the smaller tracksize will cost you
capacity on the image. Probably only the RVA will see
equivalent savings on the backend. Other devices do a
one to one mapping of the full ECKD image.
So, why not format the tracks with 1
Jim ...
Looking back over old presentations I found it.
Your logical blocksize can be greater than physical blocksize,
but the reverse is not true. Logical blocksize smaller than physical
doesn't work. Last I knew, this was a VFS issue in the kernel,
not specific to any filesystem type.
-Original Message-
From: Lucius, Leland [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 18, 2004 12:55 PM
To: [EMAIL PROTECTED]
Subject: Re: dasdfmt with a 1K block size - still not recommend?
As long as you have to use a 3390 track image with
ECKD mapping, the smaller
Rick wrote:
Another datapoint indicating that MVS should learn
FBA. But it's a losing battle. There seems to be
some unwritten law that says disk on channel must
be [E]CKD, so that while VM, VSE, Linux, and others
are happily embracing fixed block disk, the mainframe
channel-attached disk
On Wednesday 18 February 2004 19:54, Lucius, Leland wrote:
So, why not format the tracks with 1 full track block (rounded to next
lower 512-byte boundary) and have the driver logically divide the track
up into whatever 512-byte multiple blocks the user wants?
You can only write full blocks,
The main reason that I can think of is that the I/O must be a complete
block. By making the physical block == maximum block on the track (or
nearest multiple of the logical block), you must read and
write the entire
track in order to get / update any logical block contained
within that
Good summary and analogy, Jim.
Digging to the underlying *reason*, I believe that the
MVS mindset is that what's physically on disk must match the
logical odd or variable sizes (80 bytes and such). In the MVS world
the concept of disk and the concept of filesystem are blurred.
Along come new
On 2/18/2004 1:03 PM Jim Sibley wrote:
snip
When os/370 came out, it introduced a fixed block file
system (VSAM) now standardized at 4K blocks, eerily
similar to the block size of a page in memory and the
page size on disk. Also introduced were fixed block
devices that would handle both VSAM and
I've been trying to install Linux and use an OSA/Express set up in non
QDIO mode. When attempting to configure SLES 8 to use it with the OSA
Ethernet selection on the initial communications configuration menu, I
get the following:
Starting LCS module $Revision: 1.132 $ $Date: 2002/04/30
On 2/18/2004 1:45 PM Richard Troth wrote:
Good summary and analogy, Jim.
Digging to the underlying *reason*, I believe that the
MVS mindset is that what's physically on disk must match the
logical odd or variable sizes (80 bytes and such). In the MVS world
the concept of disk and the concept of
No that was when I tried using the Apache and Tomcat that are
distributed with SLES8.
On Wed, 2004-02-18 at 12:17, Ranga Nathan wrote:
Is this after you built Tomcat from source? Usually the configure,make
process detects the presence of Apache header files and links it in. I
have not done
On Mer, 2004-02-18 at 18:15, Ranga Nathan wrote:
On my slackware (Intel) I always used the 'configure, make, make install'
process. It worked flawlessly everytime. This way I always got the latest
software. With RPMs I have had problems and then I had to go under the
hood. RPM's are usually
I have seen this message before also. In most cases, I had defined the
addresses without the 0x prefix or somehow wrong.
Another situation where I saw this message is on a mult port OSA card where
you had to specify the adapter number (not always 0). So, if your OSA card
has more than one
On Wednesday, 02/18/2004 at 05:07 EST, Aria Bamdad
[EMAIL PROTECTED] wrote:
I have seen this message before also. In most cases, I had defined the
addresses without the 0x prefix or somehow wrong.
Another situation where I saw this message is on a mult port OSA card
where
you had to specify
OK, they do a POR weekly, but I'll check that the cable wasn't pulled
out and plugged in.
Thanks.
On Wed, 2004-02-18 at 16:21, Alan Altmark wrote:
On Wednesday, 02/18/2004 at 05:07 EST, Aria Bamdad
[EMAIL PROTECTED] wrote:
I have seen this message before also. In most cases, I had defined
Linux detected the devices properly. On one try I let it go with that
and on another try I keyed the addresses, I'm more than certain that I
used 0x.
This is an OSA Express and although it has two ports, I thought that
each port was a seperate CHPID (always identified as port 0).
On Wed,
On Wed, 18 Feb 2004 16:28:35 -0600 Rich Smrcina said:
This is an OSA Express and although it has two ports, I thought that
each port was a seperate CHPID (always identified as port 0).
True, but on my MP3K, I have 3 ethernet cards and I have defined each
one as it's own CHPID. But for some
IMHO, fibre attach (FCP) satisfies the need for fixed-block devices for
z/Linux. If you use SCSI/FC disk instead of DASD, you can have 512, 1K, or
whatever sector size you want as long as it is supported by the device and
the software. Removing the DASD emulation layer from the I/O in z/Linux
IMHO, fibre attach (FCP) satisfies the need for fixed-block devices
for z/Linux. ...
No, not quite.
Not until z/VM (both CMS and CP) and VSE can do SCSI/FP
from IPL to shut down. IF that happens, I figure it will be
another five years down the dusty road. I'm not yet sure
that it will
Actually, MVS benefitted from FBA devices, too. The
resistance is having a mix of devices to handle FBA
and ECKD.
If this is true, then why doesn't some enterprizing
vendor sell disk that emulates FBA devices, to be used
by Linux, VSE and VM?
enterprizing is an interesting word. SCSI is now
Does anyone on this list have any idea what the REAL licensing requirements are for
DB2/Connect on Linux/390 on an IFL?
We have a need to use DB2/Connect from Linux/390 to access DB2 databases on z/OS
platforms running on other machines in our data center. We don't need DB2/UDB, just
connect
John wrote:
I wouldn't say that VSAM is standardized at 4K
blocks.
In general:
A Control Interval can be any size from 512 to 8192
bytes in increments
of 512 bytes, and from 8 KB to 32 KB in increments of
2 KB.
The underlying physical record size is chosen by
VSAM, and depends on device
A long and twisted road indeed. You can pay for DB2 Connect in a number
of ways.
It is MSU (and maybe PSLC) priced so that you pay based on the size of
the processor for z/OS. Depending upon some factors this may be best.
The next is Application Server pricing. You pay for DB2 Connect based
As you found out, it depends...
If you have a client process on Linux/390 that needs access to data on
the mainframe (MVS, VM, VSE and/or AS400), you need a personel license
for DB2 Connect. DB2 Connect Personel license is about $250 depending
on whether you need the media and/or documentation.
On 2/18/2004 5:26 PM Jim Sibley wrote:
John wrote:
I wouldn't say that VSAM is standardized at 4K
blocks.
In general:
A Control Interval can be any size from 512 to 8192
bytes in increments
of 512 bytes, and from 8 KB to 32 KB in increments of
2 KB.
The underlying physical record size is chosen
I have a customer that is using DB2/Connect V8 (I think SP3) with
DB2/VSE 7.2.
On Wed, 2004-02-18 at 17:37, Tom Duerbusch wrote:
BTW, if you are connecting to DB2 for VM and VSE 7.x, you cannot use
DB2 Connect V8. You must use DB2 Connect 7.x with the later fixpacks.
Current fixpack level is
http://linuxtoday.com/developer/2004021801026OSDV
-- TWZ
signature.asc
Description: This is a digitally signed message part
On Wednesday 18 February 2004 18:45, Terrence W. Zellers wrote:
http://linuxtoday.com/developer/2004021801026OSDV
Hmph. When there's a source RPM for NetREXX and we can compile it for
Linux/390, then tell me about it.
Perl was SO avoidable
-- db
On Wed, 2004-02-18 at 22:13, David Boyes wrote:
On Wednesday 18 February 2004 18:45, Terrence W. Zellers wrote:
http://linuxtoday.com/developer/2004021801026OSDV
Hmph. When there's a source RPM for NetREXX and we can compile it for
Linux/390, then tell me about it.
Perl was SO
Hello from Gregg C Levine
How many here, run Slackware Linux, besides myself. (Both flavors) I
run Intel Linux, obviously. On that same web based magazine page that
Terence talks about, there are references to Slackware security
advisories. I'm right now downloading some of them. That is I am
Rich,
From what I can tell, apr_thread_mutex_trylock is a function from the Apache
Portable Runtime project. It's possible that the RPM builder missed a
dependency, and there's another package you need to install. What that
might be, I have no idea at the moment.
Mark Post
-Original
That sounds like a reasonable assessment. Thanks for the possible lead.
On Wed, 2004-02-18 at 23:18, Post, Mark K wrote:
Rich,
From what I can tell, apr_thread_mutex_trylock is a function from the Apache
Portable Runtime project. It's possible that the RPM builder missed a
dependency, and
Rich,
See if there's something like this on SLES8:
ftp://ftp.suse.com/pub/suse/i386/9.0/suse/i586/libapr0-2.0.48-9.i586.rpm
It looks like a likely candidate.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Rich Smrcina
Sent: Thursday, February
OK, I check for it. Thanks.
On Wed, 2004-02-18 at 23:32, Post, Mark K wrote:
Rich,
See if there's something like this on SLES8:
ftp://ftp.suse.com/pub/suse/i386/9.0/suse/i586/libapr0-2.0.48-9.i586.rpm
It looks like a likely candidate.
Mark Post
-Original Message-
From: Linux
Yes, I'm aware of them. I subscribe to the Slackware announcement lists,
along with the ones for SUSE and Red Hat. The packages Pat is updating are
pretty much the same ones everyone else is updating. It's interesting to
see which distribution gets the notices out first for any given
76 matches
Mail list logo
