We're migrating our mail servers to Domino on Linux 390 ( zSeries).
Does anyone know a good antivirus for Domino?
TIA
...
: : :
: : Aristarc Diez : [EMAIL PROTECTED]:
: :
This one is good .
http://www.trendmicro.com/en/products/email/smln/evaluate/overview.htm
http://www.trendmicro.com/en/products/email/smln/evaluate/overview.htm
Eric Chang
-Original Message-
From: Linux on 390 Port Aristarc Diez
Sent: 2004/10/20 []
And it just works
Larry
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Adam Thornton
Sent: Tuesday, October 19, 2004 16:51 PM
To: [EMAIL PROTECTED]
Subject: Re: DASD configuration for SuSE SLES 8
On Oct 19, 2004, at 3:41 PM, John Kaba wrote:
I am
I was verifying that my tz stuff was set up correctly so that I don't get a
surprise for the time change, so I rolled my test server ahead to Nov 1
using the date command
When I did this, my clock setting was also shifted 12 hours ahead. This was
not catastrophic as I have an NTP server running
Barton,
All the Linux guests in this partition are individually connected to the network
through the OSA. From what I'm told, PTF UM30888 (CP4.3) addresses the QDIO Q3
issue but has no effect on direct OSA attachments, and I think thats why they are
sitting in Q3. As long as page stealing is not
Linux on 390 Port [EMAIL PROTECTED] wrote on 20.10.2004 15:09:42:
pequot:~ # date
Wed Oct 20 07:58:38 CDT 2004
pequot:~ # date 11012004
Mon Nov 1 20:04:00 CST 2004
pequot:~ # date 10202004
Wed Oct 20 20:04:00 CDT 2004
pequot:~ # ntpdate condor
20 Oct 07:59:06 ntpdate[4427]: step time
On Wed, Oct 20, 2004 at 03:44:15PM +0100, David Howells wrote:
The attached patch adds syscalls for almost all archs (everything barring
m68knommu which is in a real mess, and i386 which already has it).
It also adds 32-64 compatibility where appropriate.
---
Hi Linus, Andrew,
The attached patch adds syscalls for almost all archs (everything barring
m68knommu which is in a real mess, and i386 which already has it).
It also adds 32-64 compatibility where appropriate.
Umm, that patch added the damn multiplexer that had been vetoed multiple
times.
Why are your servers not dropping from queue? Looks like you
have 15 linux guests - all in Q3, none dropping from queue.
The main reasons for not dropping from queue are the Timer and real OSA
devices.
We found that you need to turn off the jiffy timer with an
echo 0 /proc/sys/kernel/hz_timer
Greetings,
We have an ESS Shark and we are trying to install SLES 9 onto a 5GB LUN, which we
accomplish, but when it comes back and you have to reipl so that you can finishup
the configuration with YAST, the system starts to come up, but does not properly
setup the network configuration
Um, no. Should be ENTRY_COMP() if there's compat syscalls.
Not all archs (of which PA-Risc is an example) seem to require the same fixups
on the same syscalls. In some instances, the upper half of the register is
implicitly zero on 32-bit syscall entry to a 64-bit kernel. In such cases,
none of
On Middeweken 20 Oktober 2004 16:44, David Howells wrote:
diff -uNrp linux-2.6.9-bk4/arch/s390/kernel/compat_wrapper.S
linux-2.6.9-bk4-keys/arch/s390/kernel/compat_wrapper.S
--- linux-2.6.9-bk4/arch/s390/kernel/compat_wrapper.S 2004-06-18 13:43:49.0
+0100
+++
i think i'm network jinxed.
i couldn't get the 2216 drivers working, possibly due to bugs in the lcs
drivers, so switched to using a ctc connection to another lpar running
z/os to get out on the network. i adjusted my redhat install tape to use
the ctc, and it worked (i'd get a few errors at
I asked SuSE about this long ago, after I had similar trouble. Apparently they
couldn't get it to work either, so they don't support it.
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Terry Spaulding
Sent: Wednesday, October 20, 2004 1:50 PM
To:
Christoph Hellwig [EMAIL PROTECTED] wrote:
Hi Linus, Andrew,
The attached patch adds syscalls for almost all archs (everything barring
m68knommu which is in a real mess, and i386 which already has it).
It also adds 32-64 compatibility where appropriate.
Umm, that patch added
7124 as the read device and 7123 as the write. mtu on both sides is set to
32760.
can anyone refer me to some verbiage on how to troubleshoot this type of
device? anyone have any suggestions?
The Red Hat installer sets the CTC MTU to 1500 as we've had similar problems
with larger
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:
:Grump.
I'm having a rotten day, so here's a small complaint about a
medium-sized annoyance to make me feel better.
7?25l1A
80C10D1;32mdonem8?25heth0
Dear Linux distributors:
Is it really so hard to check the terminal type before emitting ANSI
Robin,
What is the CTC protocol that is specified? 3 is what is recommended
for talking to MVS systems, not the default of 0.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Robin
Murray
Sent: Wednesday, October 20, 2004 1:47 PM
To: [EMAIL
thanks mark, that's probably it. i was going to try that next, but the
default worked from the tape so i didn't believe it would be a problem
later on. i'll also try the suggestion to make a smaller mtu size.
Robin Murray
Tel: (902) 453-7300 x4177
Cell: (902) 430-0637
Post, Mark K [EMAIL
Hi Mark, Yes, read this from the same doc. I did a search for this rpm on
SuSE and did not find it.
Mark responded:
---
If you saw the comment where I did
Is it really so hard to check the terminal type before emitting ANSI
escape codes for eye candy that don't mean squat on a non-ANSI terminal?
You might want to direct this at IBM too:
It would be an easy hack for the console drivers to eat the
ANSI X3.64 sequences, discarding their effects
On Mer, 2004-10-20 at 20:55, Gregg C Levine wrote:
Hello from Gregg C Levine
And I agree with you, David, regarding the terminal settings for the
different systems we use. Some sort of detection mechanism should be
created to prevent these guessing games.
It should always honour the setting
On Wed, 20 Oct 2004, Alan Altmark wrote:
Ew!!! I thought the whole point of exporting TERM was to advise
the system of the user experience environment, with the upper layers
adding device controls appropriate to the device.
Sure.
But it's perfectly reasonable for the driver in this
Once again, I have failed to communicate the complete concept. [sigh]
On Wed, 20 Oct 2004, David Boyes wrote:
You might want to direct this at IBM too:
...
IMHO, why should they? The application's been provided the information
that the terminal is *not* ANSI -- the app (in this case the
On Wednesday, 10/20/2004 at 03:42 EST, Richard Troth [EMAIL PROTECTED]
wrote:
Do we really
need/want to support the idea that we hack the device drivers every
time
some application writer is too lazy to look at the environment and do
the Right Thing (tm)?
Certainly not. I see that I
On Oct 20, 2004, at 3:42 PM, Richard Troth wrote:
Even for the line-mode drivers (HWC and 3215)
consuming ANSI sequences is a reasonable feecher.
(BUT AGAIN, THIS IS NOT TO IGNORE THE PROBLEM WITH THE INIT SCRIPTS.)
I disagree that it's reasonable.
Reasonable features like that are the reason
Hi, I am implementing a plan to connect a Linux lpar to our Windows
active directory domain. I figured after a ping to another server works
ok I need to be able to use DNS for address resolution. I am able to
ping my DNS server ok. However when I do an nslookup on the address it
cannot find
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
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
Is there more information in the kernel ring buffer? (dmesg will show you
that.)
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of John
Kaba
Sent: Wednesday, October 20, 2004 5:45 PM
To: [EMAIL PROTECTED]
Subject: Formatting and Partitioning on
On Wed, Oct 20, 2004 at 04:44:33PM -0500, John Kaba wrote:
SuSE Instsys zlinux:/root # dasdfmt -f /dev/dasda1 -b 4096 -d cdl
^^^
I don't think this is what you want.
If you've done dasdfmt and fdasd already on /dev/dasda, your next step is to
make
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.
On Wed, Oct 20, 2004 at 03:01:49PM -0700, David S. Miller wrote:
David, I applaud your effort to take care of this.
However, this patch will conflict with what I've
sent into Linus already for Sparc. I also had to
add the sys_altroot syscall entry as well.
I've mentioned several times that
On Wed, Oct 20, 2004 at 04:41:44PM -0700, 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
On Thu, 2004-10-21 at 09:04, David S. Miller wrote:
On Thu, 21 Oct 2004 00:56:25 +0200
Andi Kleen [EMAIL PROTECTED] wrote:
I don't think that's a good idea. Normally new system calls
are relatively obscure and the system works fine without them,
so urgent action is not needed.
And I
36 matches
Mail list logo
