HDTenEightyP/NetNews huggingface dataset:
From: bolson@carson.u.washington.edu (Edward Bolson)
Newsgroups: comp.sys.dec
Subject: (resolved) Re: 4000/90 > Fuji SCSI 2 drive problems
Date: 25 Jan 1993 18:12:14 GMT
Organization: University of Washington, Seattle
NNTP-Posting-Host: carson.u.washington.edu

Fujitsu suggested not only removing the terminator on the drive (not indicated
in the documentation that comes with it), the strap for synchronous SCSI, 
and a the strap on CNH1 pins 23-24, which has something to do with terminator
power source.  Whichever of these was most important, I don't know, but
the drive now is recognized, and is in use without errors logged.

I did get a few responses, mostly about SCSI itself, rather than the
particular drive.  Each was responded to individually.  I have left the
drive strapped to SCSI-1, also - after all of the changes, I don't know
if setting to SCSI-2 would also work.  As long as the drive is smaller than
1 GB, I believe there is no problem - I think SCSI-1 doesn't address higher
block numbers.


In article <1jp4j7INNbal@shelley.u.washington.edu> bolson@carson.u.washington.edu (Edward Bolson) writes:
>I also have a new 4000/90, and bought a Fujitsu drive recommended by R-squared
>as a replacement for an RZ-25. Am home at the moment, but believe it is a 2624FA.
>Anyway, it was intended to be mounted internally, and I have been waiting for
>the mounting plate, which they seem unable to supply.  However, I tried leaving the device "loose" and attaching the cables, and it won't pass the SCSI self 
>test in the 4000/90, nor will the system boot (remote boot) with the drive 
>attached.  I have tried this with and without terminators attached.  None of
>DEC's documentation indicates whether or not to leave terminators on an internal
>drive.  
>
>I am talking to one tech support person, and I am beginning to feel like I
>need to call in DEC.  Maybe the disk is faulty.  Any advice?
>
>Ed
>
>-- 
>Ed Bolson
>University of Washington  Cardiovascular Research               (206)543-4535
>bolson@u.washington.edu (preferred)
>bolson@max.bitnet                bolson@milton.u.washington.edu (if you must)


-- 
Ed Bolson
University of Washington  Cardiovascular Research               (206)543-4535
bolson@u.washington.edu (preferred)
bolson@max.bitnet                bolson@milton.u.washington.edu (if you must)
Newsgroups: comp.sys.dec
Subject: Re: Need alloca which allocates storage IN the stack frame (Ultrix)
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 21 Jan 93 11:16:47 GMT
Distribution: world
Organization: The Wolery

timv@ccad.uiowa.edu (Timothy VanFosson) writes:
> Does anyone have an implementation of alloca() which actually
> sets aside storage in the stack frame?  I'm trying to port
> the NIH Class Library and have everything working except the
> process classes, and I've narrowed it down to the DEC implementation
> of alloca() not being what NIH expects.

You don't say what system you want this for.  It kinda matters, since you
can't really do an alloca() in C.

Anyway, since it's short, here's a VAX MACRO alloca() (code filched from GCC,
comments by me):

	.title ALLOCA	allocate dynamic storage on stack

	.psect $CODE, long,pic,rel,shr,exe,rd,nowrt
	.entry ALLOCA, ^M<>	; Entry point, save no general registers.

	subl2 4(AP), SP		; Allocate stack space
	movl 16(FP), R1		; Get return address from soon to be redundant
				; stack frame (used for returning)
	movq 8(FP), AP		; Restore AP & FP from stack frame
	bicl #3, SP		; Longword-align stack
	addl2 #28, SP		; Deallocate now-redundant frame from stack
				; (This is not done until we are finished with
				; the frame, since the size of the block
				; alloca()ed could be smaller than 28 bytes
				; and it would be bad if we were interrupted.)
	movl SP, R0		; Return address of bottom of stack
	jmp (R1)		; Return without unwinding stack.

	.end

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
Newsgroups: comp.sys.dec
From: jfc@athena.mit.edu (John F Carr)
Subject: Re: Unix Review review of Alpha/OSF
Organization: Massachusetts Institute of Technology
Date: Thu, 21 Jan 1993 05:24:25 GMT

In article <1993Jan20.234854.1@cc.curtin.edu.au>
	zrepachol@cc.curtin.edu.au writes:

>The one that will get some vendor one day is: X reports a bug, next day, Y
>buys system, bug blows his data away. Y sues for damage, loss of income,
>and on finding out that the vendor knew the system was faulty, punative
>damages. When this happens, we may see the brain-dead marketroids and
>legal-sleazels given the shove and a sensable aproack taken.

The likely reaction, and the reaction I would have if I ran a software
company subject to such a lawsuit, would be to make sure all customers sign
a license acknowledging that there are likely to be bugs in the software
product, those bugs may cause loss of revenue, and fixing bugs may take a
long time.  Then I would raise the price of the software and charge for
support to cover my liability insurance and the increased manpower needed to
fix bugs faster.  I would certainly not fire the lawyers just when I need
them the most.

--
    John Carr (jfc@athena.mit.edu)
Newsgroups: comp.sys.dec
From: venaas@swix.nvg.unit.no (Stig Venaas)
Subject: MicroVax II, VaxStation 3200 disk question
Organization: Nettverksgruppa - UNIT
Date: Mon, 25 Jan 93 08:54:06 GMT

We've got a MicroVax II and two VaxStation 3200 which
are in terrible need of more diskspace.

What kind of disks can they use?

We have some SCSI and some standard PC MFM disks. Is it
possible to connect any of those? I guess not though.

Also, has anyone got manuals for MV II and VS 3200 for sale?

Stig
Newsgroups: comp.sys.dec
From: reece@eco.twg.com (Reece R. Pollack)
Subject: Re: VMS on ALPHA PC's
Reply-To: reece@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Wed, 27 Jan 93 20:32:13 GMT


In article <1993Jan27.121405.27694@infodev.cam.ac.uk>, rf@cl.cam.ac.uk (Robin Fairbairns) writes:
|>
|>It's obviously difficult for DEC to find the resources for the work.
|>Perhaps we out here could help them along a bit?  I for one would be
|>quite happy to write a driver or two in exchange for a bit of Alpha
|>hardware for my home (though I would also, of course, need oodles of
|>documentation, and so forth).
|>
|>This is not an idle offer - I _have_ written VMS drivers, though not
|>for some time, and not on Alpha.
|>
|>Somehow, however, I can't see it being taken up     :-(

I, too, would trade the effort required to write VMS drivers for Alpha PC
hardware in exchange for an Alpha PC. And I have written drivers for Alpha/VMS.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.
From: bolson@carson.u.washington.edu (Edward Bolson)
Newsgroups: comp.sys.dec
Subject: Re: 4000/90 > Fuji SCSI 2 drive problems
Date: 22 Jan 1993 15:41:27 GMT
Organization: University of Washington, Seattle
NNTP-Posting-Host: carson.u.washington.edu

I also have a new 4000/90, and bought a Fujitsu drive recommended by R-squared
as a replacement for an RZ-25. Am home at the moment, but believe it is a 2624FA.
Anyway, it was intended to be mounted internally, and I have been waiting for
the mounting plate, which they seem unable to supply.  However, I tried leaving the device "loose" and attaching the cables, and it won't pass the SCSI self 
test in the 4000/90, nor will the system boot (remote boot) with the drive 
attached.  I have tried this with and without terminators attached.  None of
DEC's documentation indicates whether or not to leave terminators on an internal
drive.  

I am talking to one tech support person, and I am beginning to feel like I
need to call in DEC.  Maybe the disk is faulty.  Any advice?

Ed

-- 
Ed Bolson
University of Washington  Cardiovascular Research               (206)543-4535
bolson@u.washington.edu (preferred)
bolson@max.bitnet                bolson@milton.u.washington.edu (if you must)
Newsgroups: comp.sys.dec
Subject: Display PostScript
From: dayne@cache.declab.usu.edu
Date: 22 Jan 93 14:23:44 MDT
Reply-To: dayne@cache.declab.usu.edu
Distribution: world
Organization: Utah State University
Keywords: display postscript, DPS, postscript

I would like to look into using display postscript on the DEC Station 5000 running Ultrix v.4.2.  I have located the include files and the libraries.  I own a NeXT and am used to making wraps of PostScript code, generating C files to use in my graphics programs.  Is there some way to do the same sort of thing on the DEC Stations.

Dayne Medlyn
dayne@cc.usu.edu
Newsgroups: comp.sys.dec,comp.unix.ultrix
From: maklinm@cognos.com (Max Maklin)
Subject: Re: Cache parity error count for cpu
Keywords: cache
Organization: Cognos Incorporated, Ottawa CANADA
Date: Fri, 29 Jan 1993 03:17:17 GMT

In article <1993Jan27.055647.25873@cs.aukuni.ac.nz> rob@cs.aukuni.ac.nz (Rob Burrowes ) writes:
:^()  I just installed ULTRIX 4.3 on a DECStation 5000/200. I am now getting
:^()  a large number of messages in the system log which state
:^()  "Cache parity error count for cpu 0 is _581"
:^()  next message changes the _581 to something else. The OS Event type is 250,
:^()  which the manual says is informational. The hardware self checks ok and
:^()  everything seems to be running fine. I am just getting a very large syserr log.
:^()  
:^()  Is this 4.3 or has the cache taken a dive and it is just a coincidence. A
:^()  5000/120 running 4.3 doesn't do this (it just logs the odd message with
:^()  cryptic numbers in the "MESSAGE" field) so I guess the hardware may be at fault.
:^()  
:^()  What is the "Cache parity error count" , which cache is it refering too, and
:^()  why is this not reported as a Hardware error rather than an informational
:^()  message?
:^()  
:^()  

Wow 581 is quite a bit.  When was the last time you rebooted this machine?
I will assume it has been a while.  I already posted about this about 6
months.  I had it escalated through support.  The story goes something
like this.

Some code that had been monitoring this for a while was enabled to write
error log records starting with Ultrix 4.2A.  This still happens to me
on my 5500 and 5000/200.  I get between 10-20/week depending how busy.
Should you be worried?  That depends on the first question.  If you
have rebooted in the last week, I would probably have DEC come take 
a look and maybe request a new CPU boards.  Ensure that you are at the
most recent FCO for the 200.  I think it is F03, but this is just from
memory.  Note, the error log is correct in informing you it as 250, since
it is a self-correcting event.  Performance-wise you do not want to
be getting too many in a short time.

The reason you probably do not see it on the newer models is that the
motherboard contains different chipsets (read no flaky Siemens chips).

Note: Please everyone refrain from requesting new boards (read never
      should have enables this message).  They are for the large
      majority harmless.  Besides given that there is less and less
      people around we need them concentrating their efforts on
      providing us Internet access to patches, right! :)

Max
-- 
Max Maklin                                                P.O. Box 9707 
Technical Analyst	                           3755 Riverside Drive
Cognos Incorporated                              Ottawa, Ontario CANADA
Internet: maklinm@cognos.COM                 UUNet: maklinm@cognos.UUCP
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.sys.dec
Subject: Re: VMS on ALPHA PC's
Keywords: Alpha PC, VMS
Date: 27 Jan 93 06:19:15 GMT
Followup-To: vmsnet.alpha,comp.sys.dec
Organization: Canisius College, Buffalo NY. 14208

In article <1k1itrINNat3@usenet.INS.CWRU.Edu>, muswick@vs2.uh.cwru.edu (Gary James Muswick) writes:
> 
> ....  On top of this, microsoft has 
> again slipped the into date for NT till at least March and from some inside 
> info, NT won't be ready till June!  My DEC rep says the pc boxes are waiting 
> to ship, they just need NT.  --- All of this has me bummed.
> 
  NT will ship sooner or later and will become stable sooner or later and,
  no doubt, will become a major os platform.  But planning around an antic-
  ipated ship date and making corollary purchasing decisions is foolish:
  MS has never been very good at meeting its own projections, the hype around
  NT is fierce, and it IS a new operating system....



  greg pavlov
  pavlov@fstrf.org
From: gezelter@rlgsc.com
Newsgroups: comp.sys.dec
Subject: Re: UNIBUS and/or QBUS interface description?
Date: 26 Jan 93 10:10:46 EST
Organization: Robert Gezelter Software Consultant, Flushing, NY

In article <1993Jan25.175802.13830@bernina.ethz.ch>, merz@ips.id.ethz.ch (Andreas Merz) writes:
> I am looking for documentation for the UNIBUS and the QBUS interfaces.
> Where can i find something? (books, files, etc.)
> 
> Any help is much appreciated!
> -- 
>  ---------------> Andreas Merz  /  Internet: merz@ips.ethz.ch <----------------
>  ------> Interdisciplinary  Project  Center  for  Supercomputing  (IPS) <------
>  <-------- *THE* ultimate computer virus:  MSDOS - even with updates! -------->
-- 
Andreas,
 
The specifications for the UNIBUS and the QBUS used to be 
published by Digital in the handbooks for the different product 
lines. There was also a little handbook which contained both 
specifications, called the "Bus Handbook". However, all of these 
books have not been printed in years (I keep my copies under 
"lock and key" because I need them).
 
Some information on the bus structures was published in "Computer 
Engineering: A Digital View of Hardware Design", by Bell, Mudge 
and McNamara, but the handbooks (particular the Bus Handbook and 
the Microcomputer Processor and Interfaces Handbooks for the 
LSI-11 series) went into the extremely low level details of the 
bus structure and implementation.
 
I hope that the above information is helpful. If I have been 
unclear, or if I can be of further assistance, please feel free 
to contact me via Email.
 
- Bob
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
| Robert Gezelter Software Consultant         Voice:   +1 718 463 1079     |
| 35-20 167th Street, Suite 215               Fax:       (on Request)      |
| Flushing, New York  11358-1731                                           |
| United States of America                                                 |
+--------------------------------------------------------------------------+
Xref: sparky comp.sys.dec:7085 comp.unix.ultrix:9450
From: kaiser@mammal.vbo.dec.com (Peter Kaiser)
Subject: Re: Unix Review review of Alpha/OSF
Reply-To: kaiser@uniriv.vbo.dec.com
Organization: DEC Technology Integration Group
Date: Thu, 21 Jan 1993 07:55:40 GMT


In article <1jhjvkINNd33@sol.tis.com>, mjr@tis.com (Marcus J Ranum) writes:

> ... digitally signed by the vendor for certification*) ...

This technology is export-controlled.

___Pete

kaiser@uniriv.vbo.dec.com
+33 92.95.62.97, FAX +33 92.95.52.00
Newsgroups: comp.sys.dec,comp.unix.ultrix
From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Subject: Re: "gnode: table is full" and "File table overflow"
Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Organization: Digital Equipment Corporation
Date: Wed, 27 Jan 1993 20:55:01 GMT


In article <1993Jan27.144336.14130@cs.hw.ac.uk>, raz@cs.hw.ac.uk (Ross A Macintyre) writes:
>
>Recently errors like these have been reported on our 5000/200.
>These errors are reported by users and don't seem to appear in the error logger.
>This was the output after "ls -l":
>
>*bug.chk.sgi: File table overflow
>*yp_pass.chk: File table overflow
>*extra_src: File table overflow
>*total 546
>*getsvc: stat of /etc/svc.conf failed
> [ etc, etc, etc, ]

The command of interest is pstat(8) with the option -T.  This prints
the sizes of some of the kernel tables.  I'll include sample:

% pstat -T
 171/ 609       files
 138/ 444       gnodes
  48/ 288       processes
  34/  42/  76  active/reclaimable/total texts
 253/1843       00k swap

You seem to be running of entires in both the "files" and "gnodes" table
and probably need to make both larger.  The simplest way is to simply
raise "maxusers" in the configuration, rebuild and reboot.  The sizes
of these tables are calculated based on the value of maxusers.  This
will also increase the size of some of the other tables.  Now most of
the entires are pretty small and it would a large increase of maxusers
to use signifncantly more memory for the tables.  Still, if this is a
concern, the sizes are set in param.c and you could modify the algorithm
that calculates the sizes.

>
>Thanks in advance,
>
>Ross
>
>PS The only real change to the system in the last few days is that I added 
>automount maps to Yellow Pages.
>
--
Alan Rollow				alan@nabeth.cxo.dec.com

Newsgroups: comp.sys.dec
From: tihor@acf3.NYU.EDU (Stephen Tihor)
Subject: Re: What is an ESAR chip
Organization: New York University
Date: Tue, 26 Jan 1993 06:09:00 GMT

The ESAR chip labeled ENET ADRS is the Ethernet Address chip and for the benefit
of network software, databases, or hardware that may have an attachment to a 
particular address associated with yoru machine was originally required to be 
socketed and movable so that servicing a system did not change its Ethernet 
address.   A less critical issue in pure IP space
From: lee@hsh.com (Lee Havemann)
Newsgroups: comp.sys.dec
Subject: Re: MicroVax II, VaxStation 3200 disk question
Date: 27 Jan 93 20:09:50 GMT
Organization: HSH Associates

In article <1993Jan25.085406.23877@ugle.unit.no>, venaas@swix.nvg.unit.no (Stig Venaas) writes:
> We've got a MicroVax II and two VaxStation 3200 which
> are in terrible need of more diskspace.
> 
> What kind of disks can they use?
> 
> We have some SCSI and some standard PC MFM disks. Is it
> possible to connect any of those? I guess not though.
> 
> Also, has anyone got manuals for MV II and VS 3200 for sale?
> 
> Stig

You can put a KDA50 and 4 RA style drives on the MVII - 4 RA81's will give 
you almost 2 gigs, and can be had relatively inexpensively. 

-- 

 Lee Havemann, Comp Ops Dir.    HSH Associates      (201) 838-3330 
 Internet: lee@hsh.com    Compuserve: 70410,3507    AOL: HSH Assoc
 "Any opinions expressed are not necessarily those of anyone else, 
  including myself."
From: benoy@alpha.aosg.gsf.dec.com (Benoy Desouza AOSG)
Newsgroups: comp.sys.dec
Subject: Re: ALPHA OSF1 xdr problem
Date: 25 Jan 93 15:50:39 GMT
Organization: AOSG

In article <WARREN.93Jan20172646@stormy.atmos.washington.edu>,
warren@atmos.washington.edu (David Warren) writes:
|> Has anyone successfully used xdr routines on an alpha for reading or
|> writing longs. The ALPHA doesn't seem to know that a long by xdr
|> definition is only 32 bits. I am trying to build the UNIDATA netcdf
|> library (scientific data format) which uses xdr format. It is trying
|> to use the xdr library that comes with the ALPHA and the tests fail
|> because the ALPHA can't get longs correct.
|> --

xdr_long() on OSF/1 Alpha DOES adhere to the internet RFC 1014 (XDR)
and is really xdr_int() (just like ntohl() on OSF/1 Alpha is really a
network-to-host-int). Beware that if you declare a variable as a long
on OSF/1 Alpha, you will be getting a 64 bit integer. Hence if you try
to xdr_long() this 64 bit quantity, you would not get the same results
as on a 32 bit OS. You should really be applying xdr_long() ONLY to
"ints" on OSF/1 Alpha.

-------------------------------------------------------------------
Benoy DeSouza				AOSG (OSF/1 Alpha)
Mailstop: GSF1-1/K13                    (dtn) 264-5877
Digital Equipment Corp.                 (external) (603) 884-5877
5 Wentworth Drive                       enet: benoy@aosg.gsf.dec.com
Hudson, NH 03051                        decnet: alpha::benoy
Newsgroups: comp.sys.dec
From: dent@cwis.unomaha.edu (Dave Caplinger)
Subject: Re: What's an RC25 please??
Organization: University of Nebraska at Omaha
Date: Fri, 29 Jan 1993 00:39:18 GMT

gary@minster.york.ac.uk writes:
>The title says it all.

The RC25 is a half-fixed half-removable drive that was used (at least)
in the VAX-11/725 (deskside version).  I believe that each portion was
25MB (or very close) so the whole drive had a capacity of 50 or so MB.
I believe that DEC marketed "external" versions of these as well,
presumedly for the VAX/11-7xx family, but they may have also had them
for the DEC Professionals or whatever that PC-ish thing before the
Rainbow was.  :-)  I don't really remember for sure...

Say... do you happen to have one you want to get rid of? :-)  The local
University ACM chapter has a VAX-11/725 with the internal RC25 drive but
the power supply for the RC25 doesn't work (the rest of the 11/725 seems
OK), so I know they're in the market for one cheap (they're students after
all :-).  If so, please reply email...

--
- Dave Caplinger           "Freedom's so hard when we all are bound by laws
  dent@loria.omahug.org    etched in the scheme of Nature's own hand, unseen
  dent@cwis.unomaha.edu    by all those who fail in their pursuit of faith."
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: comp.sys.dec
Subject: Re: UNIBUS and/or QBUS interface description?
Date: 26 Jan 93 12:05:47 GMT
Article-I.D.: spcvxb.1993Jan26.070547.5020
Organization: St. Peter's College, US

In article <1993Jan25.175802.13830@bernina.ethz.ch>, merz@ips.id.ethz.ch (Andreas Merz) writes:
> I am looking for documentation for the UNIBUS and the QBUS interfaces.
> Where can i find something? (books, files, etc.)

  Your best bet would be the "PDP-11 Bus Handbook", a blue paperback-sized
manual which is unfortunately out of print. I have seen copies at various
used book sales, though.

  For the Q-bus, many of the handbooks DEC still gives away contain a pass-
able description of the bus. Additionally, if you purchase a PDP-11 processor
manual for a recent CPU (11/83, 11/93) the same info is repeated in there.

  For Unibus it's a bit harder. Many of the Unibus CPU manuals contain a
summary of the bus signals, but don't really describe them in detail. You'd
need either the Bus Handbook or the guide that came with the "ChipKit" of
Unibus interface IC's (also discontinued).

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381
Newsgroups: comp.sys.dec,comp.os.vms
From: Jim-Miller@suite.com
Subject: DEC Time Services
Reply-To: Jim-Miller@suite.com
Organization: Suite Software, Dallas, Anaheim, La Mesa.
Date: Thu, 21 Jan 1993 17:27:33 GMT

I'm looking for information about DEC Time Services.  Does anyone know if there  
is an FTP site somewhere that contains documents describing DEC Time Services?

Thanks,

Jim-Miller@suite.com
Newsgroups: comp.sys.dec,comp.unix.ultrix,comp.os.vms
From: rye@scmbrd.dco.dec.com (Bill Rye)
Subject: Re: Patches online, was Re: Unix Review review of Alpha/OSF
Organization: Digital Equipment Corp., Digital Services, COL
Date: Thu, 28 Jan 1993 21:30:15 GMT

I have exchanged email with Gail.  If you have already responded to Gail's
previous posting/request, then ignore mine.  If you missed it the first time
around or just want to state your opinion again, feel free to send it to me
and I'll see that it goes on to support Gail in her never ending quest.


Bill Rye	 | DISCLAIMER - Digital may own my thoughts and ideas,
DEC Columbia, MD | but all opinions are my own, no matter how stupid they might
rye@dco.dec.com  | seem.
Newsgroups: comp.sys.dec,comp.unix.ultrix
From: mvw@kub.nl (Maarten van Wijk)
Subject: RF73 in DECsystem 5500
Date: Fri, 22 Jan 93 12:30:13 GMT
Organization: Tilburg University, Tilburg, The Netherlands
Reply-To: Maarten.vanWijk@kub.nl
Keywords: RF73, DECsystem 5500

Hi,

Does anyone know if it is possible to use a RF73 (2 GB) disk in a
DECsystem 5500.

-- 
****--*--* Maarten van Wijk --- Tilburg University --- The Netherlands -+
***  *  *  P.O. Box 90153       5000 LE Tilburg                         |
**  *  *   Tel:(+31) 13 662080  Fax:(+31) 13 663189    <mvw@kub.nl>     |
+--*--*-----------------------------------------------------------------+