From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 22-JUN-1990 08:01:36.47
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	VMS 5.3

Received:  by crdgw1.ge.com (5.57/GE 1.70)
	 id AA07201; Fri, 22 Jun 90 07:30:55 EDT
Received: From CUNYVM.CUNY.EDU by CRVAX.SRI.COM with TCP; Fri, 22 JUN 90 01:05:10 PDT
Received: from HEARN.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5985; Fri, 22 Jun 90 04:03:31 EDT
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Received: from KUB.NL (S211KENO) by HEARN.BITNET (Mailer R2.03B) with BSMTP id
 7270; Fri, 22 Jun 90 10:02:11 MET
Date: Fri, 22 Jun 90 09:59 N
From: Kees Noyens - KUB/DRC <S211KENO%KUB.NL@CUNYVM.CUNY.EDU>
Subject: VMS 5.3
To: info-vax@kl.sri.com
Message-Id: <76D13BB0AE1FA052F3@KUB.NL>
X-Envelope-To: info-vax@kl.sri.com
X-Vms-To: IN%"info-vax@kl.sri.com"
Comments: This message was sent with PMDF 3.1

We have been using VMS 5.3-1 for a few weeks now, and our experiences are
as follows:

o the system is slower compared to VMS 5.1-1
  Our cluster is a VAX 8700, 6310, 11/785 and about 20 workstations.

  The VAX 8700 has poor response times due to an overloaded CPU and
  (PCSA server, Boot node, UNIBUS on VAXBI, Decnet Area Router, batchjobs,
   users, etc.)
  Since VMS 5.3-1 it became worse:

  Due to some changes in the scheduler, batch jobs running at priority 2-3
  now get more CPU time. I changed the queue base
  priorities from 3 to 1 and interactive response time seems to have
  improved somewhat. Lowering SYSGEN parameter QUANTUM could help as well
  (I have not tried it yet).
  In order to have two different priority batch-queue's, I'm going to
  experiment with base-priority ZERO as well.
  According to $ help init/queue/base this IS allowed.

  The swapper now does selective writes on the modified page list. It
  uses much more CPU than the 5.1 swapper (on our system, SIX times more).
  but has less I/O to the pagefile. If you are CPU-bound and
  not disk-bound, consider lowering sysgen parameter MPW_HILIMIT, so
  the swapper computes less at the expense of more pagefile I/O.
  Also, leave PFRATL at 0.

  In DSIN, I've read about some bugs in the swapper-code. When the number
  of processes exceeds BALSETCNT, the swapper might loop and the
  system hangs (cured at VMS 5.4).
  In the meantime: make BALSETCNT equal to MAXPROCESSCNT.

  I wished they would have left it as it was in VMS 4.x.
  A lot of changes were made in the area of scheduling/modified page writing,
  but so far they only brought us bugs and bad response times.

o there are a lot of bugs in the new BACKUP. One of them is the
  poor performance on 11/7xx and 86xx machines, due to inefficient
  CRC calculations. There is a patch avaliable, which solves some of
  the VMS 5.3-1 backup-problems: CSCPAT_0101

o if you have a DHU11 or some other YFDRIVER device, you might see hangups
  on login. At times, the system does not respond after the first
  character of your username. This is a very old bug, solved in VMS 4.5,
  but it re-occurred in VMS 5.0 - 5.3-1.
  There is a patch for it: PATCH03_530

o there is also a minor bug in LCDRIVER.EXE. It doesn't tell OPCOM
  when the printer goes offline. Patch: LCDRIVER011_05X.A

o The new OPC$LOGFILE_CLASSES and OPC$OPA0_CLASSES do not work as stated
  in the VMS 5.2 release-notes. Their behaviour is correctly described
  in the comment-lines in the SYLOGICALS.COM command procedure.

  The logicals have only effect during VMS startup. After that, if you
  do $ reply/enable or $ reply/log, ALL classes are enabled regardless of
  the OPC$ logicals settings.
  In the meantime, I switch the operator-logfile with

  reply/log/enable=('f$trnlnm("OPC$LOGFILE_CLASSES")')

  where OPC$LOGFILE_CLASSES is defined as:

  $ define/system/exec opc$logfile_classes -
    "central,cluster,devices,disks,license,printer,tapes"

  Lots of people have complained about this. TSC Holland expects it to
  be a feature in VMS version Future.

o Some DECwindows remarks:
  To prevent DECwindows from wasting a lot of CPU, you might consider
  editing the files
  - sys$common:[decw$defaults.system]decw$session.dat

    add the line:
    *blinkRate:0
    at the top of the file and save it in directory
    sys$common:[decw$defaults.user]

    it prevents the cursor blinking in the pause screen, which seems to use
    some CPU.

  - decw$login.dat
    in DECwindows 1.0 I used to specify blinkRate:0 as well, but
    DECwindows 2.0 isn't happy with it.
    At times, your workstation HANGS and you've got to reboot.

    So... I decided to specify some very large value
    *blinkRate:5000
    at the top of the file sys$common:[decw$defaults.system]decw$login.dat
    and I saved it in sys$common:[decw$defaults.user]decw$login.dat.

    Now it blinks every 5 seconds and uses less CPU

  - we experienced some crashes of the DECwindows terminal emulator when
    specifying a font in $ create/term/big_font/window=(font=...)
    we still can't get fonts other than the defaults to work with DECterm.

  - users of PMDF in DECwindows MAIL:
    To get DECwindows mail to work, you should add the command
    $ install add /open/header sys$share:decw$ailshr
    to your systartup_v5 command file.        v
    No, it's not a typo, also  sys$share:decw$Mailshr should be installed

o Now the good news of VMS 5.3:
  All our layered products, third party hardware/software, programs etc.
  still work !

  The only thing I had to do was re-install:
  VAXimage Application Services 1.0
  VAXimage Scanning Application 1.0
  Decwrite 1.0

=========================================================================

Kees Noyens
Tilburg University
The Netherlands

Surfnet : KUBVX1::S211KENO
Bitnet  : S211KENO@HTIKUB5.BITNET