jeff1@SEISMO.CSS.GOV (Jeff Sparkes) (11/01/85)
This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP Posting-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP Path: garfield!info-vax@ucbvax.ARPA From: info-vax@ucbvax.ARPA Newsgroups: mod.computers.vax Subject: Re: VMS4-EDT and VT52 Message-ID: <4049@garfield.UUCP> Date: 1 Nov 85 03:30:00 GMT Sender: news@garfield.UUCP Distribution: local Organization: Memorial U. of Nfld. C.S. Dept., St. John's Lines: 32
jeff1@SEISMO.CSS.GOV (Jeff Sparkes) (11/01/85)
This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP Posting-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP Path: garfield!info-vax@ucbvax.ARPA From: info-vax@ucbvax.ARPA Newsgroups: mod.computers.vax Subject: Re: VMS4-EDT and VT52 Message-ID: <4050@garfield.UUCP> Date: 1 Nov 85 03:30:00 GMT Sender: news@garfield.UUCP Distribution: local Organization: Memorial U. of Nfld. C.S. Dept., St. John's Lines: 32
jeff1@SEISMO.CSS.GOV (Jeff Sparkes) (11/01/85)
This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP Posting-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP Path: garfield!info-vax@ucbvax.ARPA From: info-vax@ucbvax.ARPA Newsgroups: mod.computers.vax Subject: Re: VMS4-EDT and VT52 Message-ID: <4051@garfield.UUCP> Date: 1 Nov 85 03:30:00 GMT Sender: news@garfield.UUCP Distribution: local Organization: Memorial U. of Nfld. C.S. Dept., St. John's Lines: 32
daemon@WISDOM.BITNET (The devil himself) (11/05/85)
This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10.1 6/24/83; site wisdom.BITNET Posting-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP Path: wisdom!garfield!info-vax@ucbvax.ARPA From: info-vax@ucbvax.ARPA Newsgroups: mod.computers.vax Subject: Re: VMS4-EDT and VT52 Message-ID: <4051@garfield.UUCP> Date: Fri, 1-Nov-85 05:30:00 EET Sender: news@garfield.UUCP Distribution: local Organization: Memorial U. of Nfld. C.S. Dept., St. John's Lines: 32
daemon@WISDOM.BITNET (The devil himself) (11/05/85)
This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10.1 6/24/83; site wisdom.BITNET Posting-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP Path: wisdom!garfield!info-vax@ucbvax.ARPA From: info-vax@ucbvax.ARPA Newsgroups: mod.computers.vax Subject: Re: VMS4-EDT and VT52 Message-ID: <4049@garfield.UUCP> Date: Fri, 1-Nov-85 05:30:00 EET Sender: news@garfield.UUCP Distribution: local Organization: Memorial U. of Nfld. C.S. Dept., St. John's Lines: 32
daemon@WISDOM.BITNET (The devil himself) (11/05/85)
This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10.1 6/24/83; site wisdom.BITNET Posting-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP Path: wisdom!garfield!info-vax@ucbvax.ARPA From: info-vax@ucbvax.ARPA Newsgroups: mod.computers.vax Subject: Re: VMS4-EDT and VT52 Message-ID: <4050@garfield.UUCP> Date: Fri, 1-Nov-85 05:30:00 EET Sender: news@garfield.UUCP Distribution: local Organization: Memorial U. of Nfld. C.S. Dept., St. John's Lines: 32
info-vax@ucbvax.UUCP (12/16/85)
This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10.2 9/18/84; site epson.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: epson!spar!decwrl!pyramid!pesnta!amd!amdcad!lll-crg!ucdavis!ucbvax!info-vax Newsgroups: mod.computers.vax Subject: Re: Need system with 180 users accessing 1 database Message-ID: <8512142009.AA07920@lasspvax.tn.cornell.edu> Date: 14 Dec 85 20:09:31 GMT References: <8512092136.AA09248@sivax.UUCP> Sender: uucp@ucbvax.BERKELEY.EDU Reply-To: garry%geology@cu-arpa.cornell.edu.arpa Lines: 0
info-vax@ucbvax.UUCP (01/17/86)
This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10 5/3/83; site solar.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!info-vax From: info-vax@ucbvax.UUCP Newsgroups: mod.computers.vax Subject: Re: VT-220 clones Message-ID: <8601110300.AA06043@deneb.DAVIS> Date: Fri, 10-Jan-86 22:00:45 EST Article-I.D.: deneb.8601110300.AA06043 Posted: Fri Jan 10 22:00:45 1986 References: <8601092331.AA17460@dual.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: info-vax@sri-kl.arpa At U.C. Davis, we use something called a Microterm Ergo 320. Many people here call them the Ogre 320. They're a close immitation of a 220, with a few added features, such as a couple additions to the setup mode. The keyboards feel "cheap", and there is a distinct difference in monitor resolution. I find the green screen 320's simply unusable and almost unreadable. The amber monitors aren't too bad though. Reliablity wise, they aren't spectacular. Lots of little failures, like video boards. Probably better than 10% of the units have failed in one year. We paid $760 or so for each. At those prices, I'd look around at the mail order places for low prices on a REAL 220. They don't run much more, and the better monitors are SO much easier to work with. Also, if you're looking for a cheap VMS terminal, I'd go with a Wyse 75. It is only vt100/102, but it works really well with EDT if you set term/nowrap, has a better monitor than the Ergo, and the old fashioned keyboard, and only runs around $500.
info-vax@ucbvax.UUCP (01/17/86)
This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10 5/3/83; site solar.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!info-vax From: DAG%SBPHY@LBL.ARPA Newsgroups: mod.computers.vax Subject: RE: DECnet questions Message-ID: <8601150848.AA06389@ucbvax.berkeley.edu> Date: Tue, 14-Jan-86 15:34:00 EST Article-I.D.: ucbvax.8601150848.AA06389 Posted: Tue Jan 14 15:34:00 1986 Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 55 Approved: info-vax@sri-kl.arpa Mike, I have DECnet running between a number of VAXen on 9600 baud terminal lines. There are a number of things you should take into consideration when you set up the network. If you assume that you don't have the nodes defined in the permanent database you should be able to use the following procedure to get the network up and running. You use the same procedure on both systems, obviously make changes for device names etc. $ MCR SYSGEN SYSGEN> CONNECT NOA0/NOADA SYSGEN> *EXIT* $ SET TERMINAL/PROTO=DDCMP/SPEED=9600 TTxx $ MCR NCP NCP> DEFINE LINE TT-a-b STATE ON NCP> DEFINE CIRCUIT TT-a-b STATE ON NCP> DEFINE NODE 63.1 NAME VMSA NCP> *EXIT* $ @SYS$MANAGER:STARTNET Make sure you do the same things on both systems, and make sure you do it in the correct order. It is very important that you specify the speed in the 'SET TERMINAL' command. Particularly if the previous speed of the terminal line is different than the DECnet speed. Also NCP uses a different format for TERMINAL names than regularly VMS (I think DEC just wanted it to be a little more confusing). The NCP format is TT-number-number. The last number is the same as the normal port number. The middle number is simply the controller - A=0, B=1, C=2 (of-course, real programmers start counting at zero, keep this in mind). An example would be TTB4 = TT-1-4. I had terrible trouble using asynchronous DECnet on non-DEC multiplexors, if you have an Able or Emulex board that doesn't use a standard DEC driver you probably shouldn't bother. One of my systems always went down when everytime I tried an Emulex board with an Emulex supplied UHDRIVER. One last hint. I wouldn't try testing the circuit at 1200 baud. Do it at 9600 or at least 4800. DDCMP is not the most effcient protocol in the world and DECnet may be timing out before a complete packet is sent at a low baud rate. I hope this helps, if you have any more questions let me know. Oh, if you want to get a hold of the Software Tools it should be on the Spring and Fall DECus symposium tapes. == DAG == UUCP - ucbvax!ucsbcsl!darren BITNET - DAG@SBHEP ARPA - dag%sbphy@LBL.ARPA PHYSNET - SBPHY::DAG
info-vax@ucbvax.UUCP (01/18/86)
This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10 5/3/83; site solar.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!info-vax
From: RAY@SRI-VAX.ARPA (RAY)
Newsgroups: mod.computers.vax
Subject: (none)
Message-ID: <8601160904.AA02080@ucbvax.berkeley.edu>
Date: Thu, 16-Jan-86 04:04:53 EST
Article-I.D.: ucbvax.8601160904.AA02080
Posted: Thu Jan 16 04:04:53 1986
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 72
Approved: info-vax@sri-kl.arpa
From: MAILER 14-JAN-1986 20:17
To: RAY
Subj: [Netmail From: G.ROODE@SU-SCORE.ARPA] [David Roode <ROODE@IC2060>: DEC announcement]
Return-Path: <G.ROODE@SU-SCORE.ARPA>
Received: from SU-SCORE.ARPA by CRVAX.ARPA with TCP; Tue Jan 14 20:17-PST
Date: Tue 14 Jan 86 20:14:29-PST
From: David Roode <G.ROODE@SU-SCORE.ARPA>
Subject: [David Roode <ROODE@IC2060>: DEC announcement]
To: Ray@SRI-VAX.ARPA, Kashtan@SRI-IU.ARPA, Vivian@SRI-NIC.ARPA,
Bosack@SU-SCORE.ARPA, Cower@SU-CSLI.ARPA, BillW@SU-SCORE.ARPA
Message-ID: <12175324407.8.G.ROODE@SU-SCORE.ARPA>
DEC plop (splash?) at Berkeley today.
---------------
Mail-From: ROODE created at 14-Jan-86 20:09:15
Date: Tue 14 Jan 86 20:09:15-PST
From: David Roode <ROODE@IC2060>
Subject: DEC announcement
To: Biotech@IC2060, Fine@GENIE, Moore@GENIE, Pattermann@GENIE
DEC announced a new workstation today at Berkeley. They were very
proud of the fact that it will be supported under Unix before
VMS (by about 3 months). It is the Vaxstation II/GPX,
where GPX stands for Graphics Performance Extended. For
$35,000 list price you get a 2mb MicroVax with RD53 and TK50,
that also includes 4 plane color with a 1024 by 864 raster.
A new chip using the same technology as the MicroVax II chip
is the heart of the GPX option, and it offloads most of
the graphics processing from the CPU, compared to the
original VaxStation II in which the graphics loaded the
processor considerably. They claim graphics performance
on the order of 3 to 5 times better than Sun and Apollo,
with a lower price.
There is also a gray-scale version for $2,000 less,
and for more money you can get 8 plane color. Informally
they admitted that the design accomodates the potential
of additional planes, and that they had placed
2 of the GPX options on a single microVax.
They expect to set a new industry standard for window management
with X-windows done for them by MIT. Formally, the new
software is Ultrix-32W which is layered on top of Ultrix-32M.
They also proudly promised several more product announcements in
the near future. The GPX modules should be available as an upgrade
for existing microVaxes as well, if they can work out the marketing
considerations.
They were also loudly trumpeting the availability of TCP/IP
under Ultrix, the fact that all their products talk to all industry
standard products of other vendors, and said they were willing
to talk about needs for TCP/IP under VMS. Internally, they
use Wollongong TCP/IP extensively for VMS systems apparently.
They consider this possibly sufficient as a TCP/IP product offering
for VMS, since they have cooperative marketing with Wollongong.
The GPX is a base module plus an additional module for each 4 planes
of color. In the BA123 with standard configuration, there is room
for 3 4-plan GPX's or 2 8-planes, i.e. 6 slots are left for GPX
modules after all the others that are needed are installed.
They also announced VAX FORTRAN/ULTRIX which is billed as 3
times faster than the regular BSD FORTRAN.
Under Ultrix, the X-windows can each access a different CPU
over TCP/IP transparently. It seems you might want to buy an 8600
as the computer engine for your network of VAXstation-II GPX's.
-------
-------info-vax@ucbvax.UUCP (01/21/86)
This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10 5/3/83; site solar.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: solar!orion!mtunf!mtuni!mtunh!ariel!vax135!houxm!mhuxt!mhuxr!ulysses!ucbvax!info-vax
From: GKN%OAK.SAINET.MFENET@LLL-MFE.ARPA
Newsgroups: mod.computers.vax
Subject: Micom/DHU-11 problem
Message-ID: <8601110745.AA11283@ucbvax.berkeley.edu>
Date: Fri, 10-Jan-86 08:08:00 EST
Article-I.D.: ucbvax.8601110745.AA11283
Posted: Fri Jan 10 08:08:00 1986
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 52
Approved: info-vax@sri-kl.arpa
Date: Fri, 10-JAN-1986 08:09 EST
To: Info-VAX@SRI-KL.Arpa
Message-ID: <[OAK.SAINET.MFENET].59401E00.008E8CFA.GKN>
US-Mail: Science Applications; P.O. Box 2501; Oak Ridge, TN 37831
Telephone: (615) 482-9031
X-VMS-Mail-To: ARPA%"Info-VAX@SRI-KL.Arpa"
We have a VAX 785 running VMS. It has two DHU11's. Terminal
access is at 9600 baud and goes through a MICOM 600 port
...
The user sees the Username: prompt, but after
the first character of their username is echoed back, it appears
as if everything is hung.
...
Once a line exhibits the problem, it remains that way
until a system boot. The problem does not hit one particular
line, it seems relatively random.
Anybody every see this before? Any ideas? It's getting to be a
pain to disable the ports at the port selector. DEC has pretty
much given up, although they suspect it is something the MICOM is
doing.
I asked our resident Micom wizard about this, and this is what he had to
say:
Sounds like an interesting/fun problem. My gutt feel is that something
is causing the Character SILO or Buffer on the DHU-11 to think it's full, or
that the Processor has gone to lunch when in actuality this hasn't occured
because character echoing still goes on.
I have had no experience with the DHU-11, but quite a bit of exposure
to the Micom 600's. I have never known the Micom to generate data at all on it's
own. Since you're running at 9600 baud, The Micom quad modules uart is actually
communicating to the interface hardware. You say the problem moves around to
different ports, thus eliminating one particular Micom interface module.
Might the problem manefest in more ways also? ie; dropping ctrl leads, RTS, CTS,
DTR.
One thing we experienced here when we connected the Micom to a CS-11 emulating
DMF-32 was pins 4&5 had to be jumpered, otherwise the Vax would drop DTR in
the middle of a user session (which was less than 2 minutes typically) which
at that time killed their process because the micom would immediately force
a disconnect.
I'ld be happy do discuss things with you if you think it might help.
My Name is Mike Brough , SAIC, (619-458-2538)..
Mike can also be reached as: Brough%LAJ.SAInet@LLL-MFE.Arpa
gkninfo-vax@ucbvax.berkeley.edu.UUCP (01/22/86)
This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10 5/3/83; site solar.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: solar!orion!mtunf!mtung!mtunh!akguc!codas!peora!pesnta!hplabs!ucbvax!info-vax
Newsgroups: mod.computers.vax
Subject: Re: Raxco, etc (really BACKUP)
Message-ID: <8601191839.AA21717@decwrl.DEC.COM>
Date: Sun, 19-Jan-86 13:40:15 EST
Article-I.D.: decwrl.8601191839.AA21717
Posted: Sun Jan 19 13:40:15 1986
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26
Approved: info-vax@sri-kl.arpa
One way to make backups run faster is simply to blast the source files onto the
target medium with lots of buffering and no error-checking. This is true in
general, of course. VMS BACKUP, using its default settings, calculates lots of
error-recovery, and does lots of error-checking; there's a story (apocryphal)
that BACKUP's ability to recover from errors was demonstrated by clipping a
2-inch section from the middle of a taped saveset, splicing the tape, then re-
storing the saveset. BACKUP noted the anomaly and restored the saveset
properly.
I don't know how Raxco's product achieves its performance. But I do know that
you can improve VMS BACKUP's timing by
-- using lots of buffers (/BUFFER=5)
-- using large physical blocksizes for taped savesets
-- turning off error-recovery
If you do that last, as far as I can tell you're throwing away a major reason
for making backups at all. That's up to you. My point is that questions of
"performance" can sensibly be asked only in the context of other important
requirements of the application.
---Pete
Kaiser%BELKER.DEC@decwrl.arpa
{allegra|decvax|ihnp4|ucbvax}!decwrl!dec-rhea!dec-belker!kaiser
DEC, 77 Reed Road (HLO2-1/N10), Hudson MA 01749 617-568-5441info-vax@ucbvax.berkeley.edu.UUCP (01/22/86)
This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10 5/3/83; site solar.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: solar!orion!mtunf!mtung!mtunh!akguc!codas!peora!pesnta!hplabs!ucbvax!info-vax Newsgroups: mod.computers.vax Subject: Re: Open remote network files from VAX-C Message-ID: <8601200026.AA28766@ucbvax.berkeley.edu> Date: Sun, 19-Jan-86 19:26:16 EST Article-I.D.: ucbvax.8601200026.AA28766 Posted: Sun Jan 19 19:26:16 1986 References: <12175039249.53.EC0N@TE.CC.CMU.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: info-vax@sri-kl.arpa I thought that there's a blurb in the VAX/C version 2 manual that remote network files aren't accessible to the "UNIX" I/O calls that DEC has so bizarrely (word?) implemented. I suppose you could always (ACK! GACK! CHOKE!) use VMS system services, but that is generally a pain worth avoiding. Have you noticed what a poor cousin VAX C is to the other VMS languages? It really burns me up not to find all the system service variable definitions in VAX C include files while they are distributed with more "favored" languages like VAX Fortran. DEC's reply is to submit an SPR! What gall! Good luck. I'd be interested in finding out if you get it to work...
info-vax@ucbvax.UUCP (01/22/86)
This newsgroup is moderated, and cannot be posted to directly. Please mail your article to the moderator for posting. Relay-Version: version B 2.10 5/3/83; site solar.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: solar!orion!mtunf!mtuni!mtunh!akguc!akgua!mhuxv!mhuxt!houxm!ihnp4!ucbvax!info-vax From: MIGLESIAS@UCIVMS.BITNET Newsgroups: mod.computers.vax Subject: Async DECnet results Message-ID: <8601200826.AA04760@ucbvax.berkeley.edu> Date: Mon, 20-Jan-86 03:27:19 EST Article-I.D.: ucbvax.8601200826.AA04760 Posted: Mon Jan 20 03:27:19 1986 Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: info-vax@sri-kl.arpa Well, it's true that you can't have more than one area on an async DECnet link. When we changed the other system to be in area 63, the systems still would not talk to each other. Our system would ACK the other's START, but they wouldn't ACK ours. I went over to their system, and noticed that we were connecting into an Able multiplexor (I'm not sure what flavor). I moved the link over to an unused DMF-32 port (non-modem), and DECnet came up right away. We're running the link at 4800 baud, because at 9600 baud they just will not start up the link, and 7200 baud got too many errors. But it's not too bad, considering the buildings are about a quarter of a mile apart. Thanks to everyone who offered advice/suggestions/etc. Mike Iglesias University of California, Irvine
news@ENTROPY.UUCP (News group) (02/21/86)
This newsgroup is moderated, and cannot be posted to directly.
Please mail your article to the moderator for posting.
Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site entropy.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: entropy!uw-june!uw-beaver!tektronix!hplabs!pesnta!pyramid!decwrl!decvax!ittatc!dcdwest!sdcsvax!ucbvax!info-vax
From: McGuire_Ed@GRINNELL.MAILNET
Newsgroups: mod.computers.vax
Subject: DISKQUOTA protections on VMS 4.n
Message-ID: <8602191119.AA04430@ucbvax.berkeley.edu>
Date: 17 Feb 86 19:34:00 GMT
Sender: daemon@unRelay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site uw-june
Distribution: net
Organization: UCSF Computer Center
Lines: 17
Sometimes people have problems with shellscripts to be run by cron.
Often this seems to be some detail or other about the environment
in which cron runs things. My question is: would these problems
all (or mostly) disappear if the shellscript began with
rlogin <this machine>
and ended with
logout
? This seems to provide the missing home directory etc. that people
forget about when developing a script for cron use.
Dick
--
Dick Karpinski Manager of Unix Services, UCSF Computer Center
UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 666-4529 (12-7)
BITNET: dick@ucsfcca Compuserve: 70215,1277 Telemail: RKarpinski
USPS: U-76 UCSF, San Francisco, CA 94143