Info-Vax-REQUEST@KL.SRI.COM (Ramon Curiel) (05/13/87)
Info-Vax Digest Wednesday, 13 May 1987 Volume 0 : Issue 21
Today's Topics:
RE: VMS TAR reader -- Thanks for the responses
Trendata Corporation
Problems with TPU
Setup libraries and <FF>s on the QMS Lasergraphics
laserwriter on a VMS microVAX
ADD
Re: Turning off <CANCEL> without turning off Cntl-C AST's
C Compiler Kills Processes
RA81 and operating temperature.
----------------------------------------------------------------------
Date: 12 May 87 14:03:41 GMT
From: sundc!hadron!klr@seismo.css.gov (Kurt L. Reisler)
Subject: RE: VMS TAR reader -- Thanks for the responses
Many thanks to all of you who responded with either pointers to or
actual routines that would permit a VMS system to read a UNIX tar
format tape. Yet another example of the community in action.
"Usenet--we make it what it is"
Kurt Reisler (703) 359-6100
============================================================================
UNISIG Chairman, DECUS US Chapter | Hadron, Inc.
..{seismo|sundc|rlgvax|dtix|decuac}!hadron!klr | 9990 Lee Highway
Sysop, Fido 109/74 The Bear's Den (703) 671-0598 | Suite 481
Sysop, Fido 109/483 The Pot of Gold (703) 359-6549 | Fairfax, VA 22030
============================================================================
------------------------------
Date: Tue, 12 May 87 10:37:11 PDT
From: ken@Hamlet.Caltech.Edu (Kenneth Adelman)
Reply-to: Ken@Hamlet.Caltech.Edu (Kenneth Adelman)
Subject: Trendata Corporation
We purchased some 11/750 memory from Trendata over a year
ago and have a very sick board we'd like to have fixed under
warrantee. I tried to call there Santa Ana number, (714) 540-3605,
and I get a recording saying the number has been disconnected.
714 information has no listing for this company.
Can anyone refer me to a new address or phone number, or
confirm that they've gone under?
Kenneth Adelman
Caltech
------------------------------
Date: Tue, 12 May 87 13:38 CST
From: <MCGUIRE%GRIN2.BITNET@wiscvm.wisc.edu>
Subject:
Subject: RE: Vax cluster emulation software
> Date: Tue, 12 May 1987 10:57 PDT
> From: CAFY002@CALSTATE
> Subject: Vax cluster emulation software
>
> I hear that Digital may be coming out with a package that will allow a
> Vax network (using a Delni Ethernet system) to emulate many cluster
> operations.
>
> Does anyone know anything about this package, and if so, does it appear to
> have many security and file I/O problems? I know the Star Cluster has quite
> a few bugs in it, and I would like some serious advise from anyone out there
> familiar with it before we too seriously concider purchasing it.
>
> Chris
> cafy002@calstate.bitnet
I know I'm not exactly addressing your question. I am addressing your
statement that the CI cluster has `quite a few bugs.' We are running a CI
cluster with 5 members. We are not encountering down time or other
problems that are attributable to cluster bugs. The cluster meets our
expectations for reliability. We are currently running VAX/VMS V4.4.
In the INFO-VAX forum, I have heard much more about problems with the newly
announced LAVC (Local Area VAXcluster) than I have heard about problems
with CI clusters.
There is one serious bug that cropped up recently in CI clusters, that can
trash a disk that is mounted by more than one member. This problem was
encountered under VMS version 4.5. There is a patch available. (DEC: `The
patch is in the mail. . .' :-} )
Hope this helps.
Ed <MCGUIRE@GRIN2.BITNET>
------------------------------
Date: Tue, 12 May 87 13:25:56 PDT
From: carl@CitHex.Caltech.Edu
Subject: Problems with TPU
I've noticed that TPU has severe problems with its memory management when
you do something that repeatedly { erases a range; inserts text into where
the range was }. Since this is the method used by EVE to do a global search
and replace, I thought others among you might like to see some statistics
I collected. The command procedure below, when executed from a batch job
repeatedly performs the above series of operations on each character in a
buffer containing 512 bytes. After each pass, it records accumulated CPU
time, physical memory in use, and total page faults for the process running
TPU. The statistics follow the procedure. To summarize the results, physical
memory varies approximately linearly with the number of erase/insert operations;
total CPU time varies approximately as a quadratic function of the number
of operations. Further, the 10th set of 512 operations takes >16 times as long
as the first set, and the 50th set >86 times as long. This means that to
do a global search and replace of a single (relatively common) character
in a large file can take a LONG time. Does anybody have an explanation
for this behavior? The only 'fix' that I know of is to save the buffer
in question, delete it, and copy the text back into it periodically. At
times, when a buffer has become VERY fragmented, I've found that deleting
the buffer can take more than 2 CPU MINUTES. Is there a user-written EVE
interface that addresses this problem?
The procedure:
$ set noon !'f$verify(0)'
$ set proc/priv=altpri
$ procedure = f$environment("PROCEDURE")
$ if f$getjpi("","PID") .nes. f$getjpi("","MASTER_PID") then goto log
$ define my_procedure 'procedure'
$ edit:==edit/tpu/nosec/comm=SYS$INPUT:/nodisplay
$ edit
PROCEDURE GROW
MY_PROCESS:=CREATE_PROCESS(CREATE_BUFFER("?"),"@MY_PROCEDURE:");
POSITION(CREATE_BUFFER("HOG_MEMORY"));
COPY_TEXT(FAO("!512* "));
N:=0;
LOOP M:=0;
LOOP SEND(FAO("!UL",N),MY_PROCESS);
N:=N+1;
EXITIF M=256;
S:=ASCII(M);
M:=M+1;
POSITION(BEGINNING_OF(CURRENT_BUFFER));
L:=0;
LOOP EXITIF L=512;
L:=L+1;
ERASE(CREATE_RANGE(MARK(NONE),MARK(NONE),NONE));
COPY_TEXT(S);
ENDLOOP;
ENDLOOP;
ENDLOOP;
ENDPROCEDURE;
GROW
$ exit
$ log: set proc/prio=5
$ log_file=f$element(0,";",procedure)-f$parse(procedure,,,"TYPE")+".OUT"
$ TPU_PROCESS = F$GETJPI("","MASTER_PID")
$ create 'log_file'
Date and Time Iterations I/O CPU Page flts Ph.Mem
$ loop: read sys$COMMAND iterations
$ iterations = 'iterations'
$ if iterations .gt. 50 then stop/id='tpu_process'
$ SHOW SYS/B/OUTPUT=SYS$SCRATCH:'TPU_PROCESS'.TMP
$ TIME=F$TIME()
$ SEARCH/OUTPUT=SYS$SCRATCH:'TPU_PROCESS'.TMP -
SYS$SCRATCH:'TPU_PROCESS'.TMP;-1 'TPU_PROCESS'
$ OPEN/READ TMP_FILE SYS$SCRATCH:'TPU_PROCESS'.TMP
$ READ TMP_FILE RECORD
$ CLOSE TMP_FILE
$ DELETE SYS$SCRATCH:'TPU_PROCESS'.TMP;,;*
$ RECORD = F$FAO("!23AS!12UL!AS",TIME,ITERATIONS,F$EXTRACT(35,42,RECORD))
$ OPEN/APPEND LOG_FILE 'LOG_FILE'
$ WRITE LOG_FILE RECORD
$ CLOSE LOG_FILE
$ GOTO LOOP
The statistics (the batch job was running at priority 3):
Date and Time Iterations I/O CPU Page flts Ph.Mem
12-MAY-1987 00:09:10.69 0 75 0 00:00:02.15 649 534
12-MAY-1987 00:09:42.07 1 77 0 00:00:15.25 751 636
12-MAY-1987 00:11:08.92 2 82 0 00:00:51.64 840 713
12-MAY-1987 00:13:24.95 3 84 0 00:01:50.71 939 766
12-MAY-1987 00:16:27.16 4 86 0 00:03:12.68 1028 855
12-MAY-1987 00:20:07.07 5 88 0 00:04:57.53 1117 944
12-MAY-1987 00:24:47.35 6 90 0 00:07:05.74 1206 1033
12-MAY-1987 00:30:33.22 7 92 0 00:09:35.98 1294 1121
12-MAY-1987 00:36:57.45 8 94 0 00:12:29.56 1383 1210
12-MAY-1987 00:44:10.16 9 96 0 00:15:45.81 1471 1298
12-MAY-1987 00:52:59.77 10 98 0 00:19:25.27 1583 1387
12-MAY-1987 01:04:27.17 11 100 0 00:23:27.60 1672 1476
12-MAY-1987 01:21:45.31 12 102 0 00:27:54.20 1760 1564
12-MAY-1987 01:34:18.88 13 104 0 00:32:41.92 1849 1653
12-MAY-1987 01:45:26.11 14 106 0 00:37:52.69 1938 1742
12-MAY-1987 01:58:26.44 15 108 0 00:43:26.39 2027 1831
12-MAY-1987 02:11:27.95 16 110 0 00:49:22.02 2131 1924
12-MAY-1987 02:25:07.11 17 112 0 00:55:40.22 2219 2012
12-MAY-1987 02:34:53.27 18 114 0 01:02:23.60 2308 2101
12-MAY-1987 02:42:45.36 19 116 0 01:09:28.96 2397 2190
12-MAY-1987 02:50:58.45 20 118 0 01:16:55.68 2487 2280
12-MAY-1987 02:59:34.30 21 120 0 01:24:45.94 2581 2374
12-MAY-1987 03:10:12.94 22 122 0 01:32:59.44 2670 2463
12-MAY-1987 03:20:08.96 23 124 0 01:41:33.82 2758 2551
12-MAY-1987 03:30:14.05 24 126 0 01:50:31.64 2847 2640
12-MAY-1987 03:40:38.19 25 128 0 01:59:50.87 2935 2728
12-MAY-1987 03:51:23.44 26 130 0 02:09:33.54 3024 2817
12-MAY-1987 04:02:43.86 27 132 0 02:19:38.74 3113 2906
12-MAY-1987 04:14:41.13 28 134 0 02:30:06.99 3219 3003
12-MAY-1987 04:26:50.99 29 136 0 02:40:57.17 3308 3092
12-MAY-1987 04:39:41.28 30 138 0 02:52:11.73 3397 3181
12-MAY-1987 04:52:57.24 31 140 0 03:03:48.03 3486 3270
12-MAY-1987 05:06:47.58 32 142 0 03:15:47.42 3575 3359
12-MAY-1987 05:21:03.72 33 144 0 03:28:10.32 3663 3447
12-MAY-1987 05:36:56.74 34 146 0 03:40:59.49 3767 3541
12-MAY-1987 05:52:14.74 35 148 0 03:54:07.22 3856 3630
12-MAY-1987 06:09:04.92 36 150 0 04:07:40.07 3945 3719
12-MAY-1987 06:26:08.46 37 152 0 04:21:36.48 4034 3808
12-MAY-1987 06:42:58.75 38 154 0 04:35:55.45 4123 3897
12-MAY-1987 06:59:54.93 39 156 0 04:50:33.75 4211 3985
12-MAY-1987 07:17:53.39 40 158 0 05:05:36.12 4305 4079
12-MAY-1987 07:36:24.81 41 160 0 05:21:05.51 4394 4168
12-MAY-1987 07:54:37.23 42 162 0 05:36:55.38 4483 4257
12-MAY-1987 08:25:39.99 43 164 0 05:53:15.92 4572 4346
12-MAY-1987 08:57:35.26 44 166 0 06:09:58.67 4660 4434
12-MAY-1987 09:20:24.04 45 168 0 06:27:07.11 4749 4523
12-MAY-1987 10:31:08.48 46 170 0 06:45:15.91 4838 4612
12-MAY-1987 11:03:21.85 47 172 0 07:03:39.25 4947 4705
12-MAY-1987 11:26:38.57 48 174 0 07:21:45.39 5036 4794
12-MAY-1987 11:49:34.74 49 176 0 07:40:16.40 5124 4882
12-MAY-1987 12:11:42.01 50 178 0 07:59:06.30 5213 4971
------------------------------
Date: 12 May 87 16:11:00 PDT
From: "Oberman, Kevin" <oberman@lll-icdc.arpa>
Reply-to: "Oberman, Kevin" <oberman@lll-icdc.arpa>
Subject: Setup libraries and <FF>s on the QMS Lasergraphics
>Earlier someone called the print symbiont brain dead since it insisted on
>sending a <FF> to the printer after configuring the printer using specified
>modules in the control library. It is merely paranoid. The print symbiont has
>no idea how the modules in the control library will affect the printer. By
>performing a <FF> the printer is in a known state (upper left hand
>edge...whereever it may be).
>
>We have a QMS Lasergrafix with the QUIC command controller. Any QUIC command
>(configuration command) causes the printer to advance one line. I can reset the
>print position to (0,0) by sending more commands or by performing a <FF>. The
>symbiont developers apparently decided to take the safe route and always put a
><FF>. Even though I think I understand why the <FF> was added I believe it
>should be a qualifier to a queue's setup to perform a <FF> or not when using
>control libraries.
>
>I am currently living with the blank pages. I can sleep at night since the
>extra scrap generated goes to the Boy Scout's paper drive and is not totally
>wasted.
DEC did err on the side of safety. (If it is to be called an error.) The <FF>
is inserted after any device control library setup module which contains
printable characters. But on a QMS Lasergraphics, this does not have to
waste paper (or help out the Boy Scouts).
I have a set of modules, that will do a few `standard' setups without the
dread blank page. Because of the filtering effect of many gateways on special
characters I have replaced car. returns with `<CR>'s. Because the symbiont
does not insert them, it is critical that they be explicitly placed in the
file via a QUOTE for EVE or a SPECIAL INSERT for EDT.
DEFAULT setup module for QMS2400
Landscape, small margins,font 10 (EDP), 8 lpi.
^PY^-<CR>
^IOL<CR>
^ISYNTAX00000<CR>
^IJ00200<CR>
^IC00<CR>
^IMH0020010830<CR>
^IS10<CR>
^IL081<CR>
^IF2T00<CR>
^-^PN
Same as above, but in portrait mode for more lines/page.
^PY^-<CR>
^IOP<CR>
^ISYNTAX00000<CR>
^IJ00200<CR>
^IC00<CR>
^IS10<CR>
^IMH0025008250<CR>
^IL081<CR>
^IF2T00<CR>
^-^PN
Portrait mode, 6lpi, Font 24(special) fixed width font (12 pitch)
^PY^-<CR>
^IOP<CR>
^ISYNTAX00000<CR>
^IJ00100<CR>
^IS74<CR>
^IC12<CR>
^IMH0010008300<CR>
^IL06<CR>
^-^PN
Setup for legal size paper
<CR>
^PY^-<CR>
^IFXX1X<CR>
^-^PN
Setup to use paper from tray 2
<CR>
^PY^-<CR>
^IF0XXX<CR>
^-^PN
Setup for tray3
<CR>
^PY^-<CR>
^IF1XXX<CR>
^-^PN
Reset module
ReSeTrEsEtReSeT
R. Kevin Oberman
Lawrence Livermore National Laboratory
arpa: oberman@lll-icdc.arpa
(415) 422-6955
------------------------------
Date: Tue, 12 May 87 16:51:31 PDT
From: SERAFINI%RAL@ames-io.ARPA
Subject: laserwriter on a VMS microVAX
Hello there,
Anybody out there have a LaserWriter hooked up to a microVAX running
VMS? I assume it can be done using a terminal queue and setup files.
Also, can anyone tell me about TeX dvi to laserwriter software?
Thanks in advance,
-Dave Serafini
NASA/Ames Research Center
serafini%ral@ames-io.ARPA
------------------------------
Date: 12 May 87 21:02 EDT
From: INFO-VAX@CICGJ.RPI.EDU
Subject: ADD
Please add me to mailing list INFO-VAX.
Thank you.
(Refer questions/comments to madison@cicgj.rpi.edu)
------------------------------
Date: 12 May 87 15:16:44 GMT
From: tedcrane@tcgould.tn.cornell.edu (Ted Crane)
Subject: Re: Turning off <CANCEL> without turning off Cntl-C AST's
In article <2655@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes:
>I want to turn off the printing of CANCEL and INTERRUPT when
>the user types Control-C and Control-Y without loosing any
>of the function of these characters.
Well, it may not be the ONLY way to do it, but you might try working
with the file:
SYS$EXAMPLES:SYSGTTSTR.MSG
It contains instructions and sample text that allows you to customize
the echoes from ^C, ^Y, ^O, and the like.
I won't go into great detail on how to use it: the file is VERY well
documented (just read it), even for a novice.
------------------------------
Date: Wed, 13 May 87 00:34:28 EDT
From: sasaki@harvard.harvard.edu (Marty Sasaki)
Subject: C Compiler Kills Processes
This isn't a problem with the C compiler, but a problem with RMS. If
you check your error log file, you will find that an RMS bug check is
hapening and killing the process. We found the problem using PL/1 and
GNU Emacs. The default configuration wasn't putting out a line feed at
the end of the file.
----------------
Marty Sasaki uucp: harvard!sasaki
Ziff Davis Technical Information Co. arpa: sasaki@harvard.harvard.edu
80 Blanchard Road bitnet: sasaki@harvunxh
Burlington, MA 01803 phone: 617-273-5500
------------------------------
Date: 13-MAY-1987 08:15:42
From: MACALLSTR%vax1.physics.oxford.ac.uk@Cs.Ucl.AC.UK
Subject: RA81 and operating temperature.
For various reasons ( ancient air-conditioning units, etc ) our computer
room sits at 75-80 degrees F! We've had 2 RA81's running for 3-4 years
with only one HDA replacement. There are also RM03's and RP07's in the
same room. There would appear to be quite a large operating range.
One of the important factors is to keep the temperature steady and to
avoid large temperature changes ( e.g. if you switch off equipment overnight
or at week-ends - probably best to leave it running ).
John
------------------------------
End of Info-Vax Digest
**********************