uucp) (06/20/88)
We have been unable to contact machine 'novavax' since you queued your job.
novavax!mail proxftl!rafael (Date 06/18)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:
uustat -knovavaxN4e8d
Sincerely,
codas!uucp
#############################################
##### Data File: ############################
From moss!arpa!brl.arpa!INFO-UNIX Sat Jun 18 18:35:15 1988 remote from codas
Received: by codas.att.com (smail2.5)
id AA25179; 18 Jun 88 18:35:15 EDT (Sat)
Received: by moss.ATT.COM (smail2.5)
id AA25082; 18 Jun 88 18:33:11 EDT (Sat)
Received: by rutgers.edu (5.54/1.15)
id AA24991; Sat, 18 Jun 88 16:00:30 EDT
Received: from SEM.BRL.MIL by SEM.brl.ARPA id ad16154; 11 Jun 88 3:10 EDT
Received: from sem.brl.mil by SEM.BRL.ARPA id aa16117; 11 Jun 88 2:46 EDT
Date: Sat, 11 Jun 88 02:46:30 EST
From: The Moderator (Mike Muuss) <Info-Unix-Request@brl.arpa>
To: INFO-UNIX@brl.arpa
Reply-To: INFO-UNIX@brl.arpa
Subject: INFO-UNIX Digest V5#065
Message-Id: <8806110246.aa16117@SEM.BRL.ARPA>
INFO-UNIX Digest Sat, 11 Jun 1988 V5#065
Today's Topics:
Re: Problems with crontab
Re: More categories for aliases (was Re: something or other)
Re: How do I use ksh TMOUT on 5.2
Re: -since option for ls -lt
Re: Network (ftp) access to ms-dos hard disks ??
Did I find a bug in egrep or am I misreading the man page?
-----------------------------------------------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: Problems with crontab
Date: 10 Jun 88 05:25:59 GMT
To: info-unix@brl-sem.arpa
In article <138@scotty.UUCP> root@scotty.UUCP (Don Cox) writes:
[SunOS 3.x, but applies to all systems with V7 backup/restor[e] and
derivatives]
>30 22 * * 1-5 su root < /usr/local/bin/backup_daily
where `backup_daily' runs dump.
>... if for some reason someone has taken the tape drive off line
>the script builds up all kinds of dump commands when I do a ps -aux.
Dump is an interactive program. As such, it will complain about
problems and demand help from an operator. It is not well suited to
unattended backups. (There is no such thing as a cheap, reliable,
unattended 9 track tape backup system, incidentally---there are too
many things that can go wrong [consider the missing EOT marker and the
tape that winds off the source reel, e.g.]. A fancy system might have
robotic recovery, but that is far out of reach of most small
installations.)
Some versions of dump (4.3BSD included) will note that /dev/tty is not
available, and will abort relatively cleanly; this could be used as
part of a semi-automatic system that simply bombs out if anything goes
wrong. This only works if dump is run without a controlling terminal,
but that should be true for cron jobs.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Michael Morrell <morrell@hpsal2.hp.com>
Subject: Re: More categories for aliases (was Re: something or other)
Date: 9 Jun 88 21:23:51 GMT
To: info-unix@brl-sem.arpa
/ hpsal2:comp.unix.questions / rml@hpfcdc.HP.COM (Bob Lenk) / 5:37 pm Jun 6, 1988 /
> % rm nosuch
> rm: nosuch nonexistent
>
> In 4.2/4.3BSD, at least, there is a line like
>
> if (!isatty(0)) fflag = 1;
Just another BSD/SysV difference, which explains the differing opinions
(apparently the hyphen in "non-existent" is another):
% rm nosuch
rm: nosuch non-existent
----------
Of course, according to my Webster's 9th Collegiate, "nonexistent" is not
hyphenated. so, in this case, BSD is correct.
-----------------------------
From: Ian Kluft <kluft@hpcupt1.hp.com>
Subject: Re: How do I use ksh TMOUT on 5.2
Date: 9 Jun 88 19:03:54 GMT
To: info-unix@brl-sem.arpa
> / txr98@wash08.UUCP (Timothy Reed) / 3:29 pm Jun 7, 1988 /
> hopefully easy question: how do I access the TMOUT variable to zap an
> idle user. Ideally I'd like to trap it in a user's login shell. MKS
> doc indicates that TMOUT's sends a SIGALRM, but ksh does not seem
> recognize such a signal on the unix 5.2 system I am running ksh on. I
> manually set TMOUT to '1', and got a 'shell timeout in 60 seconds' with
> every tap of the return key!
> Thanks in advance...
> +-------------------------------------------------------+
> | Timothy Reed - American Chemical Society |
> | UUCP: ..uunet!wash08!txr98 |
> ... etc.
If you want everyone on your system to have their KSH time out after, say,
5 minutes, set TMOUT in the /etc/profile to 5*60 seconds or 300. This
would be the line you'd add to /etc/profile:
TMOUT=300; export TMOUT; readonly TMOUT
With the readonly on there, the users cannot change or unset it in their
login shell.
Ian Kluft HP Network Systems Group
hplabs!hprasor!kluft Cupertino, CA
-----------------------------
From: Leslie Mikesell <les@chinet.uucp>
Subject: Re: -since option for ls -lt
Date: 10 Jun 88 03:37:51 GMT
Keywords: options ls find
To: info-unix@brl-sem.arpa
In article <355@conexch.UUCP> root@conexch.UUCP (Larry Dighera) writes:
>simple matter to get a listing of the files that have been changed within
>n days. Try this:
>
> find . -ctime -n -exec ls -l {} \;
I would like to have a listing that shows only directory names (without
showing subdirectories) with the date of the last change to any non-directory
file contained in that tree. Comparing this to a similar listing of
archive files would show which ones need to be updated. The date of
a directory itself is pretty useless for this purpose, since compressing
files, compiling, deleting *.o files, etc. will affect the dir date
even though no real changes have happened. I have almost resorted
to running zoo on all the directories where I am not actively working
just to get this effect...
Can it be done with any of the usual tools? Hmm.. might be a good job
for perl when the version with filename globbing is released.
Les Mikesell
-----------------------------
From: "Jack F. Vogel" <jack@turnkey.tcc.com>
Subject: Re: Network (ftp) access to ms-dos hard disks ??
Date: 9 Jun 88 18:26:56 GMT
Keywords: remote access to msdos disk, ethernet, polling
To: info-unix@SEM.BRL.MIL
In article <179@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes:
>
> I need to know if it is possible to access the hard disks on a
>ms-dos machine that is on a network of Unix and msdos machines. The
>dos disk is to be accessed while the dos machine is busy with other
>work. The dos machine is running a dedicated application (that we
>wrote).
[...details omitted....]
First off you do not say just what sort of network it is you are using.
Assuming it is ethernet I have a few suggestions. If you use something
like Desqview or DoubleDos on the Dos machine you should be able to
both run your dedicated application and a tcp/ip package concurrently.
You might consider looking into the KA9Q tcp package, it is limited but
is functional and public domain, it has support for ethernet (3com), point
to point async. or various packet radio setups (which I don't think would
be relevant here). The source and pc-dos objects are available on turnkey.
The source has a makefile for SysV and BSD as well. We have successfully
compiled and used it between an SCO Xenix system and DOS system using
point-to-point async.
What I would suggest as a scenario is this. You run one of the above-mentioned
so-called DOS multitasking packages, then with the KA9Q package running as
one task the system would accept ftp put's of data whenever you desired. On
the UNIX side you could have cron set up to check for data and then do an
automatic ftp to the DOS system whenever necessary. I suspect this would work
out nicely for you, as well as being very inexpensive. Send me some email if
you have further questions or need more detail.
turnkey has an anonymous uucp account if you wish to obtain the archive
mentioned. Login as nuucp, no password; ph# (714)662-7450 request the file:
/usr/spool/uucppublic/files
and you should be on your way. Let me know of your success.
Best of luck,
--
Jack F. Vogel
Turnkey Computer Consultants, Costa Mesa, CA
UUCP: ...{nosc|uunet}!turnkey!jack
Internet: jack@turnkey.TCC.COM
-----------------------------
From: Adam Moskowitz <adamm@necis.uucp>
Subject: Did I find a bug in egrep or am I misreading the man page?
Date: 10 Jun 88 21:10:40 GMT
Keywords: bug, egrep, regular expressions, ed
To: info-unix@SEM.BRL.MIL
While hacking /usr/lib/calendar to get it to understand about "10-Jun-88"-
style dates, I found what I think is a bug in egrep. I generated the RE:
'(0*10)([ -]*)([Ju][Uu][Nn][^ ]* *)'
^^^^^
However, when I did 'egrep RE calendar' I got nothing. Just for yucks, I
changed '[ -]*' to '[- ]*' and PRESTO - it worked.
Now, the manual page for ed(1) sez: "The following one-character REs match a
single character: . . . 1.4 A non-empty string of characters enclosed in
square brackets ([]) is a one-character RE that matches any single character
in that string. . . . The minus (-) may be used to indicate a range of . . .
The - loses this special meaning if it occurs first . . . or last in the
string."
Seems to me that either the manual page is wrong or egrep doesn't work "as
advertised". Can anybody out there either confirm this or tell me what I'm
missing? Oh yes, I've tried this on both a Sun w/s (Sun-2 I think) running
Interleaf and the gods alone know what under that as well as System V.2 on
my NEC XL. Same results, of course.
--
Adam S. Moskowitz ...!(backbone)!{necntc,encore}!necis!adamm
"How long, Dear Savior, oh how long, will this damn 'cc' take?
Fly swift around ye idle bits and bring the promised a.out"
-----------------------------
End of INFO-UNIX Digest
***********************uucp) (06/21/88)
We have been unable to contact machine 'novavax' since you queued your job.
novavax!mail proxftl!rafael (Date 06/19)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:
uustat -knovavaxN4e9c
Sincerely,
codas!uucp
#############################################
##### Data File: ############################
From moss!arpa!brl.arpa!INFO-UNIX Sun Jun 19 02:56:05 1988 remote from codas
Received: by codas.att.com (smail2.5)
id AA28861; 19 Jun 88 02:56:05 EDT (Sun)
Received: by moss.ATT.COM (smail2.5)
id AA00984; 19 Jun 88 02:36:03 EDT (Sun)
Received: by rutgers.edu (5.54/1.15)
id AA10228; Sun, 19 Jun 88 00:57:44 EDT
Received: from SEM.BRL.MIL by SEM.brl.ARPA id aa08024; 17 Jun 88 2:57 EDT
Received: from sem.brl.mil by SEM.BRL.ARPA id aa08020; 17 Jun 88 2:45 EDT
Date: Fri, 17 Jun 88 02:45:38 EST
From: The Moderator (Mike Muuss) <Info-Unix-Request@brl.arpa>
To: INFO-UNIX@brl.arpa
Reply-To: INFO-UNIX@brl.arpa
Subject: INFO-UNIX Digest V5#071
Message-Id: <8806170245.aa08020@SEM.BRL.ARPA>
INFO-UNIX Digest Fri, 17 Jun 1988 V5#071
Today's Topics:
Re: afio
Re: C/IBM
Re: Rename bug?
Curses & Color
X.400 mail
Re: .mailrc
Re: Rename bug?
Re: "cd path" strangeness
Microport S/386 and Appropriate Hardware
Need decoder/encoder source to transfer binaries
DEC hardware manuals
troff -- bold italics
which shell does shell scripts
-----------------------------------------------------------------
From: Norman Yarvin <ins_anmy@jhunix.hcf.jhu.edu>
Subject: Re: afio
Date: 16 Jun 88 00:31:56 GMT
To: info-unix@SEM.BRL.MIL
In article <4449@killer.UUCP> jlg@killer.UUCP (J L Gomez) writes:
>I've compiled the afio program but do not how to use it with the
>UNIX-PC's floppy disk drive. I know how to use cpio but using the same
>syntax with afio doesn't work. I need to know how to use the -i, -o, and
>-t options of afio. The floppy disk drive name is /dev/rfp021.
>Thanks for the help and info!
The floppy disk is /dev/rfp021 for the raw device (cpio/afio) and /dev/fp021
for the mountable device (mount with "/etc/mount <directory> /dev/fp021";
dismount with "/etc/dismount".)
Afio works out of the box and supports multiple floppies. It can read
multiple floppies made with cpio (although it complains something is wrong
at the start of each new floppy.) Its biggest feature (for me) is that it
recovers from errors, instead of dying cpio-style. As to how to operate it,
the basic options are -i for input, -o for output, and -t for a listing; the
rest of the instructions are in the man page (format with "nroff -man
<man_page> | more").
Good luck!
------------------------------------------------------------------------------
| Norman Yarvin |
| (seismo!umcp-cs | ihnp4!whuxcc | allegra!hopkins) !jhunix!ins_anmy |
| |
| Disclaimer: Johns Hopkins is massively responsible for everything I say. |
------------------------------------------------------------------------------
-----------------------------
From: Richard Hoffman <ubiquity@cs.utexas.edu>
Subject: Re: C/IBM
Date: 16 Jun 88 04:52:09 GMT
To: info-unix@SEM.BRL.MIL
In article <768@altger.UUCP>, doit@altger.UUCP (Christian Rohrmueller) writes:
> In article <10565@agate.BERKELEY.EDU> arnold2@violet.berkeley.edu (mchawi) writes:
> >now that there are c compilers on big ibms, is there a rush of COBOL->C?...
>
> Yes. It's from RAPITECH SYSTEMS INC. in Suffern , NY 10901
> Montebello Corporate Park.
I think he meant "are a lot of shops trying to convert from COBOL to C?"
rather than "are there COBOL->C conversion tools?". If so, from what I
have seen in the Oil Industry, the answer is Zip. The big conversion
contraversy is whether to go from COBOL to PL/I. Not only are there a lot
of COBOL programs out there, there are a lot of COBOL programmers out
there, who have little interest in learning C and whose managers have
little interest in paying them to do it.
Another problem is that most COBOL programs depend on data types such
as zoned and packed decimal, which are not typically available in C.
As far as automatic conversion goes, I would think that, with the addition
of some packed decimal typedefs and conversion routines, COBOL->C could
be completely automated. The results would make pretty awful reading,
though.
--
Richard Hoffman / 5751 Valkeith / Houston, TX 77096 / (713) 729-5716
+- / 12166 Metric Blvd., #122 / Austin, TX 78757 / (512) 823-1822
"Malt does more than Milton can / To justify God's ways to Man." -- ??
-----------------------------
From: "Michael I. Bushnell" <mike@turing.unm.edu>
Subject: Re: Rename bug?
Date: 15 Jun 88 18:03:36 GMT
Sender: news@unmvax.unm.edu
Keywords: strange rename errno
To: info-unix@brl-sem.arpa
In article <55239@sun.uucp> limes@sun.UUCP (Greg Limes) writes:
>In article <1128@mcgill-vision.UUCP> der Mouse writes:
>>... I trust one written by a company out to make money even less.
>
>Funny, I would expect exactly the reverse. If the operating system does
>not work properly, the company gets bug reports and has to fix them
>(this costs bucks), and if the bugs are bad enough, the company starts
>to lose customers to competitors who can provide better functionality.
>Thus is it in the best interests of the for-profit corporation to
>provide software that is as reliable and bug-free as possible.
OK...here's the 10,000,000 question: who competes with SUN to provide
software for SUNs? No one. There is, therefore, no impulse on the
part of sun to provide the best functionality. Once someone's bought
the box, sun is a power to stick-it-to-em. DEC has a competitor for
Ultrix, but the response has not been to improve Ultrix, it has been
to keep hardware manuals secret to UCB can't write drivers.
--
N u m q u a m G l o r i a D e o
Michael I. Bushnell
HASA - "A" division
mike@turing.unm.edu
{ucbvax,gatech}!unmvax!turing.unm.edu!mike
-----------------------------
From: "Michael I. Bushnell" <mike@turing.unm.edu>
Subject: Re: Rename bug?
Date: 15 Jun 88 18:09:56 GMT
Sender: news@unmvax.unm.edu
To: info-unix@brl-sem.arpa
In article <55437@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
>> I consider the whole vfs-based filesystem as an NFS thing, since it
>> exists only to support NFS.
>
>Which demonstrates that you *don't* know why the VFS mechanism
>exists. IT does not "exist only to support NFS." It exists to
>support *multiple* file systems; in other words, to permit several
>different file system types to share the same system call interface,
>and to permit new file system types to be added without rewhacking
>the system call interface.
And thus, fails. The discussion is about a manner in which those
different file systems do NOT provide the same system call interface.
Some of them give an error for rename("foo","foo"), some delete "foo",
some do nothing. flock(...) works on some, not on others. And then
there's the celebrated mkdir bug. If I do
open(fname, O_RDWR | O_CREAT | O_EXCL, mode), NFS doesn't guarantee
exclusive creation.
NFS and VFS do not guarantee the same semantics for different file
systems.
--
N u m q u a m G l o r i a D e o
Michael I. Bushnell
HASA - "A" division
mike@turing.unm.edu
{ucbvax,gatech}!unmvax!turing.unm.edu!mike
-----------------------------
From: davej@uicsrd.csrd.uiuc.edu
Subject: Curses & Color
Date: 14 Jun 88 12:18:00 GMT
Nf-ID: #N:uicsrd.csrd.uiuc.edu:45000015:000:990
Nf-From: uicsrd.csrd.uiuc.edu!davej Jun 14 07:18:00 1988
To: info-unix@SEM.BRL.MIL
I need to do colors with curses. Color is done by writing an escape
sequence to the display adapter which puts the display in the mode
for a particular color used for subsequently written chars.
The problem is the way curses trys to efficiently update the display.
It seems that 'cursrc' contains the current image of the actual display.
Assume the window I'm using is 'stdsrc'. If I write chars to 'stdscr' that
are intended to be in a new color, on a 'refresh' a char is actually
written to the display only if its char. value is different from that
in 'curscr'. So old chars may remain on the display in the incorrect
color.
I thought 'touchwin' was the answer to my problems, but all this
call seems to do is set some parameters so that the entire 'strdscr'
is compared against 'curscr' for differences; 'curscr' still acts as
a filter.
I'm sure somebody must have done colors with curses and has gotten
around this problem.
Any advice is greatly appreciated.
-----------------------------
From: James Harvey <jbh@mibte.uucp>
Subject: X.400 mail
Date: 15 Jun 88 13:04:58 GMT
Keywords: X.400, Unix, LAN, Help
To: info-unix@brl-sem.arpa
We are considering solutions for company wide E-Mail. There is a wide
variety of Local Area Networks (Apple, Novell Ethernet, ARCNet etc.)
and several NCR Unix boxes to be connected. Our Corporate Communica-
tions wants to buy Softswitch on an IBM mainframe or a DEC All-In-One
system to convert E-Mail formats but we are having problems with the
Towers. It looks like TCP/IP or X.25 communications may be available
for the NCR machines but I would like to use X.400 mailers or prefer-
ably a Unix to X.400 converter. My GREPping around the news directo-
rys has produced only two news items that even mention X.400.
Is there a Newsgroup that discusses X.400?
Does anyone know of an X.400 package for Unix?
Are we wasting our time looking at X.400?
Side issue unrelated to Unix... Has anyone ever connected a Novell
ARCNet to a Dec All-In-One for direct E-Mail?
--
Jim Harvey | "Ask not for whom the bell
Michigan Bell Telephone | tolls and you will only pay
29777 Telegraph | Station-to-Station rates."
Southfield, Mich. 48034 |
ihnp4!mibte!jbh or try ulysses!gamma!mibte!jbh
-----------------------------
From: King Ables <ables@hi3.aca.mcc.com.uucp>
Subject: Re: .mailrc
Date: 16 Jun 88 14:54:43 GMT
Posted: Thu Jun 16 09:54:43 1988
To: info-unix@SEM.BRL.MIL
in article <697@fxgrp.UUCP>, ljz@fxgrp.UUCP (Lloyd Zusman) says:
>
> If you really need this feature and you aren't totally sold on
> [mM]ail, you might wish to investigate the following alternative
> mailers: 'elm', 'mush', and 'mh'.
There's also MM from Columbia University which is a Unix version
of the Tops-20 MM mail manager. It's a very good port (rewrite)
of MM, as well. It has an option to do the exact thing he's asking
for, to be put directly into an editor to compose a message.
It comes in source form and is available via anonymous ftp from
cunixc.cc.columbia.edu. You can send mail to bug-mm@columbia.edu
if you can't get it via the internet, I imagine they can work out
a uucp transfer method.
I have nothing to do with MM or Columbia University except being
a very satisfied user of MM.
-king
ARPA: ables@mcc.com
UUCP: {gatech,ihnp4,nbires,seismo,ucb-vax}!ut-sally!im4u!milano!ables
-----------------------------
From: Guy Harris <guy@gorodish.sun.com>
Subject: Re: Rename bug?
Date: 16 Jun 88 17:59:56 GMT
Sender: news@sun.uucp
To: info-unix@brl-sem.arpa
> And thus, fails. The discussion is about a manner in which those
> different file systems do NOT provide the same system call interface.
> Some of them give an error for rename("foo","foo"), some delete "foo",
> some do nothing.
Geez, talk about "people unclear on the concept...." The discussion is about a
bug in some UFS implementations! This does NOT mean that there is some
inherent flaw in the VFS mechanism. This means that there is a flaw in some
UFS implementations; that particular flaw is fixed in SunOS 4.0.
> NFS and VFS do not guarantee the same semantics for different file
> systems.
No shit, Sherlock! VFS was *NEVER INTENDED* to support the exact same
semantics on all file systems; in some sense, that's the *point* of it! If,
as, and when "/proc" is implemented under VFS, for example, try doing a
"rename" on it; you're likely to be rudely surprised if you expect it to work -
UNIX generally considers it impolite to change process IDs of processes on the
fly. It might be amusing to consider having "unlink" do a "kill(pid,
SIGKILL)", but that wouldn't conform to UNIX semantics either, unless you made
the "/proc" directory sticky.
Making a particular file system fully or partially support the same semantics
as a UNIX on-disk file system is the responsibility of the author of the file
system code; it is NOT the responsibility of the VFS mechanism. NFS was not
designed to fully support UNIX file system semantics; some design compromises
were made in order to achieve goals other than full UNIX file system semantics.
You can debate whether these design compromises were correct or not (I don't
plan to do so; it's not germane to this discussion), but that's a different
matter.
-----------------------------
From: Lloyd Zusman <ljz@fxgrp.uucp>
Subject: Re: "cd path" strangeness
Date: 16 Jun 88 20:16:36 GMT
Keywords: csh cd xenix sysv
To: info-unix@SEM.BRL.MIL
In article <922@.UUCP> jbush@ficc.UUCP (james bush) writes:
In article <337@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes:
> Here is a wierd one. In csh, move to some directory which doesn't have
> a "path" subdirectory. Then type either "cd path" or "chdir path".
> ...
This is even more wierd. I tried it on our Intel Xenix system, and it worked
as you said when I did it under my login. However, when I tried to show it
to my friend under his id, it came up with the "expected" error message! I
am not sure what the difference is.
The wierd behavior described by Mr. Rosenthal is due to a little
known feature of the C shell:
If a shell variable is set to a value whose first character is a "/",
it can be used with cd without the leading dollar sign. For example,
suppose you have done the following:
set foo = /a/b/c/d/e
Then, the next two lines will have the exact same behavior:
cd $foo
cd foo
Here's the description in our csh man page:
cd [dir]
chdir [dir]
Change the shell's working directory to directory
dir. ...
... If dir is the name of a shell variable
whose value starts with a /, change to the direc-
tory named by that value.
Note that this works only with shell variables, not environment variables.
The wierd behavior described by Mr. Bush might be due to the fact that
his 'path' variable's first entry begins with a "/", while his friend's
'path' variable doesn't.
--
Lloyd Zusman UUCP: ...!ames!fxgrp!ljz
Master Byte Software Internet: ljz%fx.com@ames.arc.nasa.gov
Los Gatos, California or try: fxgrp!ljz@ames.arc.nasa.gov
"We take things well in hand."
-----------------------------
From: Burt Janz <bhj@bhjat.uucp>
Subject: Microport S/386 and Appropriate Hardware
Date: 16 Jun 88 18:58:21 GMT
Followup-To: myself or this group (flames to /dev/null)
Keywords: Microport, Rose Hill, service, support
To: info-unix@brl-sem.arpa
Hello, world! |-)
I've been watching the net for some time now, and I've seen the complaints
about Microport's 386 UNIX, and about miscellaneous hardware combinations,
and some general commentary. I shot my mouth off before, and got shot back
at. I must be a glutton for punishment... 'cuz
it's my turn, again. |-) |-)
This is actually a very pleasant story. Grab some coffee, and relax.
It's also a bit long... sorry about that...
In April, I purchased a 386 system from Rose Hill Systems. They are in
Scotts Valley, just "down the road a'piece" from Microport. The support
fellas at Microport had good things to say about Rose Hill machines, and Rose
Hill was VERY cooperative when I called them up. A fella named Curt Meyer
spent LOTS of time with me describing the system, both in hardware and
in software terms. I expressed some hesitation about the way they did some
things (like running an 80386-16 at 20mhz), and they did their best to
allay my concerns.
Well, I purchased their System 81 in the tower configuration. I added a
Maxtor 1065 (drive type 12) and a Quantum Q540 (drive type 7) from my old
SV/AT system, brought over the 2mb BocaRam card (16-bit extended memory
running at 8mhz), and shoved in the Everex Stream-60 controller card.
Installation of S/386 went perfectly, first time. (I had pre-formatted the
drives with Vfeature Deluxe which, by the way, didn't find any defects.)
So, I'm running happily along (although I can't run the serial ports over
4800 baud... and I'm STILL having problems with the lp driver!), and the
system DIES!! My trusty dvm tells me that I have power, but it won't boot,
and the keyboard lights don't extinguish at POST. The drives run up and
synchronize, but... no joy at boot time.
I called Rose Hill, was given an RMA, and shipped my system on Friday,
June 11. I called on the 15th (I sent it 2 day overnight Emery), and was
told that the power supply was bad, and that they'd replace it, test the
system, and get it right back to me.
Today is the 17th. I'm typing this on my Rose Hill Model 81 tower.
NOW, THAT'S SERVICE!!!!!
(Oh, by the way, the system warrantee was 1 year, so there was no charge
on service. And they paid shipping back to me.)
Many people out there are complaining about the state of their hardware,
that they have problems using two drives (I don't...), that they have
problems using the compiler (I don't...), that they see too many bad points
about Microport to keep using it (I don't...), and that they're going to
buy Xenix and run it (I won't...). Having used Xenix, I'm MUCH happier with
Microport, both in the software itself (my needs REQUIRE SVID compatibility)
and in the support (they actually seem to know what's wrong, and how to patch
around it). Having been intimately familiar with how DEC does its support,
I'm much happer with Microport. Not having a SUN, I have nothing to compare
it to... but too many changes too quickly does not a stable release make!
I am also extremely satisfied with my choice of Rose Hill for my hardware.
Granted, things shouldn't break. But they do, or some engineer would never
have invented the term MTBF. Therefore, hardware service should play into
the purchase decision of any equipment. I happen to feel that, as far as
Rose Hill is concerned, the price/performance ratio was fine.
If you are still looking for a system, consider Rose Hill. If you are
still looking for UNIX, consider Microport.
If you are still unsatisfied, please... buy a source licence, and market
your OWN version of UNIX!!!! |-)
Disclaimer: The usual about not being employed by either Microport or
Rose Hill, and about just being a very satisfied customer of both.
PLEASE, if you want to flame, do it elsewhere. I'm trying to give some
constructive commentary on an unfortunate circumstance. Yes, I WAS down
for almost a week, but it could have been much longer, and much more
expensive!!!
---------
Burt Janz
..decvax!bhjat!bhj
-----------------------------
From: Andrew Lue <andrew@nsc.nsc.com>
Subject: Need decoder/encoder source to transfer binaries
Date: 16 Jun 88 19:44:32 GMT
Keywords: decode encode
To: info-unix@SEM.BRL.MIL
Does anyone know of programs which can encode and decode binaries?
If you do, please tell me where I can retrieve the source.
UUDECODE and UUENCODE won't help because I need to transfer binaries
between VMS and UNIX systems. FTP doesn't work well. We've had problems
with Kermit, too.
Why am I transfering binaries between these systems, you query?
I'm cross-compiling for a Series 32000-based target, and I have the
cross development tools on both hosts. Sometimes the load on one machine
is just too heavy, so I want to transfer some of the work to the other machine.
Thanks in advance for any assistance.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andrew H. Lue {decwrl|sun}!nsc!andrew
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: DEC hardware manuals
Date: 16 Jun 88 14:37:32 GMT
To: info-unix@brl-sem.arpa
In article <1105@unmvax.unm.edu> mike@turing.unm.edu (Michael I. Bushnell)
writes:
>... DEC has a competitor for Ultrix, but the response has not been to
>improve Ultrix, it has been to keep hardware manuals secret so UCB
>can't write drivers.
Unless there is a conspiracy of which I am unaware (which is of course
possible), this is not why DEC clings to their hardware documentation
so tightly. Rather, it is in a (laughably ineffective) attempt to keep
hardware vendors like Emulex from gleaning some of `their' market share.
From my vantage point, the only thing this policy gets DEC is lost
sales, because I recommend against products for which detailed manuals
are not available.
(Ah well: we already have our revenge :-) , as the RISC machines sweep
past DEC while DEC's marketing dithers. If they had brought out their
RISC [nicknamed Titan, I believe] four years ago, they might have the
lead.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Michael Ryan <miker@wjvax.uucp>
Subject: troff -- bold italics
Date: 16 Jun 88 19:20:49 GMT
Keywords: bold italics lost
To: info-unix@brl-sem.arpa
the swank , but viciously terse, troff and -ms
documentation available to me has me at a loss. the problem ? bold italics.
at the beginning of paragraphs in the -ms document the key phrase is in
bold italics. at the tops of columns in the nroff/troff user's manual
voila! bold italics. they explain these are created using '.bd.'
to obtain bold italics one must use a construct '.bd I N' , N being the
level of enboldening. '.bd I' should turn off enboldening. the caveat ?
yes, 'The mode must be still or again in effect when the characters are
physically printed.' what ? oh I get it , but I can't get it to work.
I either get all bold italics, even after I believe I have stopped enboldening,
or I get no bold italics at all.
frustrated and tired , I am asking for some examples of working
bold italics.
I will gladly post a summary to comp.unix.wizards.
thanks,
michael
--
==== *michael j ryan
*{..!pyramid,..!decwrl!qubix}!wjvax!miker
*Watkins-Johnson Co., San Jose CA : (408) 435 1400 x3079
* above views are not necessarily those of Watkins-Johnson Co.
-----------------------------
From: David Goodenough <dg@lakart.uucp>
Subject: which shell does shell scripts
Date: 15 Jun 88 17:27:47 GMT
Followup-To: mail,dg@lakart.UUCP
To: info-unix@SEM.BRL.MIL
Flame me if this is old hat.
I've doctored the Followup-To to encourage ( :-) mail responses.
I use /bin/csh as my normal shell.
Hence if I execute a file whose mode is 755, and whose contents is ascii
text, my c-shell should exec(2) a sub-c-shell, and tell it to take the file
as normal input.
Why, then, is a '#! /bin/csh' needed in the following shell script?
--- cut here --- beginning of shell script ---
#! /bin/csh
foreach i (*.c)
cc -E -X23 -I/u1/vw/h/ -I../h/ -DCPU=MC68000 -DNOT_GENERIC $i >>&! typeds
end
grep typedef typeds | sort -u >&! typeds1
--- cut here --- end of shell script ---
MAIL - DON'T POST - responses
--
dg@lakart.UUCP - David Goodenough +---+
| +-+-+
....... !harvard!cca!lakart!dg +-+-+ |
+---+
-----------------------------
End of INFO-UNIX Digest
***********************uucp) (06/21/88)
We have been unable to contact machine 'novavax' since you queued your job.
novavax!mail proxftl!rafael (Date 06/19)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:
uustat -knovavaxN4ea9
Sincerely,
codas!uucp
#############################################
##### Data File: ############################
From moss!arpa!brl.arpa!INFO-UNIX Sun Jun 19 11:26:07 1988 remote from codas
Received: by codas.att.com (smail2.5)
id AA05296; 19 Jun 88 11:26:07 EDT (Sun)
Received: by moss.ATT.COM (smail2.5)
id AA07118; 19 Jun 88 11:23:11 EDT (Sun)
Received: by rutgers.edu (5.54/1.15)
id AA01804; Sun, 19 Jun 88 09:31:08 EDT
Received: from SEM.BRL.MIL by SEM.brl.ARPA id ab00152; 16 Jun 88 3:01 EDT
Received: from sem.brl.mil by SEM.BRL.ARPA id aa00117; 16 Jun 88 2:45 EDT
Date: Thu, 16 Jun 88 02:45:44 EST
From: The Moderator (Mike Muuss) <Info-Unix-Request@brl.arpa>
To: INFO-UNIX@brl.arpa
Reply-To: INFO-UNIX@brl.arpa
Subject: INFO-UNIX Digest V5#070
Message-Id: <8806160245.aa00117@SEM.BRL.ARPA>
INFO-UNIX Digest Thu, 16 Jun 1988 V5#070
Today's Topics:
Re: afio
Re: .mailrc
Re: AT&T vs. CSS (PC/Tools)
Re: SYS V sigset(2)
Re: .mailrc
Re: utility to determine rlogin?
Re: C/IBM
QIC-xx tape standards
Re: a "trivial" sed question
A warning about read(2)/write(2)
Re: "cd path" strangeness
-----------------------------------------------------------------
From: John Gennari <gennari@bonnie.ics.uci.edu>
Subject: Re: afio
Date: 14 Jun 88 22:47:35 GMT
Sender: news@orion.cf.uci.edu
Keywords: how to use afio
To: info-unix@SEM.BRL.MIL
In article <4449@killer.UUCP> jlg@killer.UUCP (J L Gomez) writes:
>I've compiled the afio program but do not how to use it with the
>UNIX-PC's floppy disk drive. I know how to use cpio but using the same
>syntax with afio doesn't work. I need to know how to use the -i, -o, and
>-t options of afio. The floppy disk drive name is /dev/rfp021.
The syntax of the two programs is very different. The -i -o options are
similar but some of the options have reverse meaning from cpio (Mark "fixed"
them). In particular, the option for creating directories is backwards.
I think you're probably having probs because you are used to
$ find / -print | cpio > /dev/rfp021
Afio does not default to stdout, you specify the file.....
# create an archive of /:
$ find / -print | afio -o /dev/rfp021
# read back that archive (N.B.: afio does *not* include the leading "/",
# i.e., "/tmp/foo" is resoted as "tmp/foo", you must be in "/" if that's
# where you want things w/ absolute paths to go. This is a big win.):
$ cd /
$ afio -i /dev/rfp021
Larry Mcvoy (lm@arizona.edu, ...!sun!laidbak!lm)
John Gennari
-----------------------------
From: "Randall W. Robinson" <rrobinson@ames.arc.nasa.gov>
Subject: Re: .mailrc
Date: 15 Jun 88 14:28:13 GMT
To: info-unix@SEM.BRL.MIL
in article <4097@fluke.COM>, strong@tc.fluke.COM (Norm Strong) says:
>
> I would like to put something in my .mailrc file, so that I will automatically
> be in the vi editor when I invoke the mail program. Currently, I have to type
> ~v every time. Is there a way to do this?
> --
>
> Norm (strong@tc.fluke.com)
Try putting a 'setenv EDITOR=/usr/bin/vi' (or whatever the path
is) in your .login. This should do it.
Randy
rrobinson@ames.arc.nasa.gov
-----------------------------
From: "Wolf N. Paul" <wnp@dcs.uucp>
Subject: Re: AT&T vs. CSS (PC/Tools)
Date: 15 Jun 88 12:18:44 GMT
Keywords: AT&T, lawsuit, CSS, PC/Tools
To: info-unix@brl-sem.arpa
In article <308@marob.MASA.COM> samperi@marob.UUCP (Dominick Samperi) writes:
>I started this discussion, and I'm not sure that the original question is
>being addressed: the article said that AT&T won a settlement against CSS
>because CSS "used ideas from UNIX." Source code copying may not have been
>the issue. The question is: if I develop tools that have the same (or more)
>functionality as some of the standard UNIX tools (ls, rm, cpio, tar, etc.),
>then can I use the same program names? And if not, can I use the word "UNIX"
>in describing the functionality of the tools? Does MKS have a license from
>AT&T?
If they did, I am sure AT&T would require them to display a copyright notice
to that effect somewhere. However, all their disks, manuals, etc, only show
a MKS copyright.
There are also numerous other examples of people developing functional clones
of UNIX -- including the same names for commands -- without AT&T taking any
action: Regulus, Coherent, Minix, etc.
There are numerous PD programs which duplicate UNIX functionality, and which
AT&T is surely aware of because they are distributed over this network:
PD Tar, AFIO (a cpio clone), GNU AWK, etc. No action was taken against any
of these by AT&T. In fact, John Gilmore had a letter from AT&T's legal dept.
stating that UUSLAVE, which is functionally equivalent to uucico, did not
contain any AT&T code and did not infringe on their rights.
That's why I am not sure that the CSS case has the impact Dominick hints at
above.
And finally, as I said in my original reply, I heard from someone in the orbit
of the CSS principals that they were almost certain that CSS had had access to
VI source code, and that was right after PC-VI first appeared.
Since ATT&T and CSS settled out of court, there is no knowing what AT&T would
have ended up showing and arguing in court, unless CSS violates the terms of
the settlement and the thing comes to trial after all.
--
Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101
UUCP: ihnp4!killer!dcs!wnp ESL: 62832882
DOMAIN: wnp@dcs.UUCP TLX: 910-280-0585 EES PLANO UD
-----------------------------
From: Jeff Bowles <bowles@lll-crg.llnl.gov>
Subject: Re: SYS V sigset(2)
Date: 15 Jun 88 14:36:44 GMT
Sender: usenet@lll-winken.llnl.gov
Keywords: sigset(2) signal(2) SYSV.3.0
To: info-unix@SEM.BRL.MIL
In article <507@micropen> dave@micropen (David F. Carlson) writes:
>
>I have a program in which it is "useful" to have reliable signals,
>and therefore I must use sigset(2) (under System Vr3.0).
>
Now, before going any further, repeat after me: "System V Release N+1
must not change functionality of programs compiled to run under System V
Release N."
The reason that there are new system calls to support things you'd expect
are two-line mods to existing system calls (like sigpause(2) springing up)
boil down to the above compatibility goal. We can argue about whether
SVR3 is incompatible with previous releases, but this is why.
>Problem is that the man pages tell me that when I am in a handler the
>signal is automatically set to SIG_HOLD. (Goes on to describe a troubled
>stack in a dying program.)
>Of course, the exclusive resource assumed by the signal handler is
>locked by a previous entry and deadlock results.
(Red light goes on.) If you need to exclusively lock something, why not
use the file-record locking calls or semaphores?
> How does sigpause(2) differ from pause(2) for waiting? The man pages
> detail dire consequences for mixing signal(2) and sigset(2) but I see
> little relation between pause(2) and sigset(2). Is there a hidden hazard
> or is this only a problem of wating within a signal handler itself?
Remember that pause(2) doesn't check for held signals - you could sleep on a
signal that's currently held....
Jeff
-----------------------------
From: Lloyd Zusman <ljz@fxgrp.uucp>
Subject: Re: .mailrc
Date: 15 Jun 88 19:07:30 GMT
To: info-unix@SEM.BRL.MIL
In article <10371@ames.arc.nasa.gov> rrobinson@ames.arc.nasa.gov (Randall W. Robinson) writes:
in article <4097@fluke.COM>, strong@tc.fluke.COM (Norm Strong) says:
>
> I would like to put something in my .mailrc file, so that I will automatically
> be in the vi editor when I invoke the mail program. Currently, I have to type
> ~v every time. Is there a way to do this?
> ...
Try putting a 'setenv EDITOR=/usr/bin/vi' (or whatever the path
is) in your .login. This should do it.
Nope. Sorry, but this does *not* do it in any of the [mM]ail programs
I've ever run. All that does is tell the mail program that when you
type "~e", you should get put into /usr/bin/vi to edit your mail message.
Upon closer reading of the original question, you can see that Mr.
Robinson was asking how he can automatically get put into 'vi' WITHOUT
having to type "~v" (or "~e", I presume). As far as I know, there is
no way to do this in any of the [mM]ail programs I've seen. I once
hacked up a private version of Mail to do this exact thing, but I was
at a site that had a BSD source license and I unfortunately was not
allowed to take my source code with me when I left.
If you really need this feature and you aren't totally sold on
[mM]ail, you might wish to investigate the following alternative
mailers: 'elm', 'mush', and 'mh'.
--
Lloyd Zusman UUCP: ...!ames!fxgrp!ljz
Master Byte Software Internet: ljz%fx.com@ames.arc.nasa.gov
Los Gatos, California or try: fxgrp!ljz@ames.arc.nasa.gov
"We take things well in hand."
-----------------------------
From: "Randall W. Robinson" <rrobinson@ames.arc.nasa.gov>
Subject: Re: .mailrc
Date: 15 Jun 88 22:54:08 GMT
To: info-unix@SEM.BRL.MIL
in article <697@fxgrp.UUCP>, ljz@fxgrp.UUCP (Lloyd Zusman) says:
>
> In article <10371@ames.arc.nasa.gov> rrobinson@ames.arc.nasa.gov (Randall W. Robinson) writes:
> in article <4097@fluke.COM>, strong@tc.fluke.COM (Norm Strong) says:
> >
... and so on ad infinitum
> Nope. Sorry, but this does *not* do it in any of the [mM]ail programs
> I've ever run. All that does is tell the mail program that when you
> type "~e", you should get put into /usr/bin/vi to edit your mail message.
>
> Upon closer reading of the original question, you can see that Mr.
> Robinson was asking how he can automatically get put into 'vi' WITHOUT
> having to type "~v" (or "~e", I presume). As far as I know, there is
> no way to do this in any of the [mM]ail programs I've seen. I once
> hacked up a private version of Mail to do this exact thing, but I was
> at a site that had a BSD source license and I unfortunately was not
> allowed to take my source code with me when I left.
> Lloyd Zusman UUCP: ...!ames!fxgrp!ljz
Hmmmm.... Ok, on both the system here at work and my system at
home the EDITOR var sets the default editor for most of the
operations on these systems. This may not be the case for all
systems or programs. The standard mailers on systems really is
one of the exceptions. If there is another mailer added to the
system (ie. elm) then it would be picked up by the mailer going
in.
- Lloyd, you might want to reread the the posting. I, "Mr.
Robinson", did not post the question, I only responed to Norm
Strong's posting.
-- Randy
rrobinson@ames.arc.nasa.gov
-----------------------------
From: Lloyd Zusman <ljz@fxgrp.uucp>
Subject: 'shartools' patch02 wanted.
Date: 15 Jun 88 23:33:22 GMT
To: info-unix@SEM.BRL.MIL
Can anyone direct me to patch02 for Rich Salz's recent 'shartools'
posting in comp.sources.*? I have patch01 and patch03, but somehow
I lost patch02.
Please reply via email.
Thanks in advance.
--
Lloyd Zusman UUCP: ...!ames!fxgrp!ljz
Master Byte Software Internet: ljz%fx.com@ames.arc.nasa.gov
Los Gatos, California or try: fxgrp!ljz@ames.arc.nasa.gov
"We take things well in hand."
-----------------------------
From: Rick Lindsley <richl@penguin.uss.tek.com>
Subject: Re: utility to determine rlogin?
Date: 15 Jun 88 22:49:12 GMT
Sender: news@puffin.uss.tek.com
To: info-unix@SEM.BRL.MIL
Jerry Peek <jerryp@cmx.npac.syr.edu> writes:
So, setting up my .login was easy. I put a test like this one in it:
switch ("`ttykind`")
case network:
# do stuff for network login
case xxx:
# do stuff for xxx login
default:
In article <16109@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes:
Why not just do `switch ($term)'? You don't need ttykind, except for
finding out *other* peoples terminal types.
Because rlogin will pass the terminal type across for you. $term may not
provide the information you want.
Rick
-----------------------------
From: Christian Rohrmueller <doit@altger.uucp>
Subject: Re: C/IBM
Date: 14 Jun 88 12:11:04 GMT
Posted: Tue Jun 14 13:11:04 1988
To: info-unix@brl-sem.arpa
In article <10565@agate.BERKELEY.EDU> arnold2@violet.berkeley.edu (mchawi) writes:
>now that there are c compilers on big ibms, is there a rush of COBOL->C?...
Yes. It's from RAPITECH SYSTEMS INC. in Suffern , NY 10901
Montebello Corporate Park.
I've never worked with it. Just got some information materials.
Hope that helps,
Christian
-----------------------------
From: Dominick Samperi <samperi@marob.masa.com>
Subject: QIC-xx tape standards
Date: 16 Jun 88 02:54:53 GMT
Keywords: magtape standards, QIC
To: info-unix@brl-sem.arpa
Where can one find the QIC-xx streaming tape standards documented? In
particular, QIC-02 describes the command set, and QIC-24 describes one
of the more common formats. These standards are referred to everywhere,
yet I've never seen them described. Thanks.
--
Dominick Samperi, NYC
samperi@acf8.NYU.EDU samperi@marob.MASA.COM
cmcl2!phri!marob uunet!hombre!samperi
(^ ell)
-----------------------------
From: Leo de Wit <leo@philmds.uucp>
Subject: Re: a "trivial" sed question
Date: 13 Jun 88 05:09:19 GMT
To: info-unix@brl-sem.arpa
In article <512@cogen.UUCP> alen@cogen.UUCP (Alen Shapiro) writes:
>I know the answer is 'use tr -d "\012"' but here is the question;
>
>Is there a way USING SED to remove all <NL> chars from a file. This is
[40 lines deleted]
From an sed addict:
I don't think this can be done for any size of file. I'll explain:
Whenever sed outputs a line, it has a trailing newline. The best you can
do is thus create one big line containing all lines of the file and remove
newlines from it (all but the last). You already indicated that you can use
N to add to the pattern space. The problem is: this pattern space has of
course a limited size (don't know if it is malloc'ed or just a big buffer)
unless sed swaps this space to the disk (don't think so). Think your core
dump was due to running out of buffer space. If your file is small enough,
you could do:
sed -n -e '
1h
2,$H
${
x
s/\n//g
p
}' your_file
This doesn't need labels (look Ma, no GOTO's! 8-).
Leo.
-----------------------------
From: ok@quintus
Subject: A warning about read(2)/write(2)
Date: 16 Jun 88 02:18:31 GMT
Sender: news@quintus.uucp
To: info-unix@SEM.BRL.MIL
Amongst the goodies recently posted to comp.sources.unix was one whose
README file said that it was a rewrite of a public domain version, and
that one of the changes that had been made was to use read(2)/write(2)/
lseek(2)/open(2)/close(2) for I/O instead of using stdio.
THAT WAS A BAD IDEA.
If you want to make your program's I/O more efficient, simply replacing
stdio calls by low-level UNIX calls is not a good idea. If you use
stdio, that package will do I/O a buffer at a time, so you only get a
system call (and a disc access) when a buffer is filled or emptied.
The package I am talking about was reading and writing 56 byte chunks,
so it was doing a system call and a disc access for every 56 bytes.
(And since 56 does not divide 8192 evenly, some of these transfers
could cost two disc accesses.)
To make your disc I/O more efficient, do as few transfers as possible,
and do as much useful work as you can in each transfer. For example,
in this balanced tree package, it would have been a good idea to keep
the tree as a tree of 8k "pages", each page containing a set of keys
(128 64-byte nodes would fit into a page, reducing the number of
disc accesses required by a factor of 7).
[This isn't a question, but it is the answer to a question that _should_
have been asked before the package was written.]
-----------------------------
From: james bush <jbush@ficc.uucp>
Subject: Re: "cd path" strangeness
Date: 15 Jun 88 20:46:54 GMT
Keywords: csh cd xenix sysv
To: info-unix@brl-sem.arpa
In article <337@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes:
> Here is a wierd one. In csh, move to some directory which doesn't have
> a "path" subdirectory. Then type either "cd path" or "chdir path".
>
> The expected response would be "path: No such file or directory." Instead,
> no message is issued, and either you stay where you were or you move to
> $path[1]...
This is even more wierd. I tried it on our Intel Xenix system, and it worked
as you said when I did it under my login. However, when I tried to show it
to my friend under his id, it came up with the "expected" error message! I
am not sure what the difference is.
--
James Bush, Ferranti, Houston Praise the Lord
Internal address: jbush extension 5230, mail stop A/3204, room A/3602
External address: ..!uunet!nuchat!sugar!ficc!jbush
-----------------------------
End of INFO-UNIX Digest
***********************uucp) (06/21/88)
We have been unable to contact machine 'novavax' since you queued your job.
novavax!mail proxftl!rafael (Date 06/19)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:
uustat -knovavaxN4eab
Sincerely,
codas!uucp
#############################################
##### Data File: ############################
From moss!arpa!brl.arpa!INFO-UNIX Sun Jun 19 12:26:56 1988 remote from codas
Received: by codas.att.com (smail2.5)
id AA05672; 19 Jun 88 12:26:56 EDT (Sun)
Received: by moss.ATT.COM (smail2.5)
id AA08368; 19 Jun 88 12:24:10 EDT (Sun)
Received: by rutgers.edu (5.54/1.15)
id AA04223; Sun, 19 Jun 88 10:38:27 EDT
Received: by SEM.BRL.ARPA id aa22764; 19 Jun 88 3:11 EDT
Received: from SEM.BRL.MIL by SEM.brl.ARPA id aa22697; 19 Jun 88 2:57 EDT
Received: from sem.brl.mil by SEM.BRL.ARPA id aa22685; 19 Jun 88 2:46 EDT
Date: Sun, 19 Jun 88 02:46:10 EST
From: The Moderator (Mike Muuss) <Info-Unix-Request@brl.arpa>
To: INFO-UNIX@brl.arpa
Reply-To: INFO-UNIX@brl.arpa
Subject: INFO-UNIX Digest V5#073
Message-Id: <8806190246.aa22685@SEM.BRL.ARPA>
INFO-UNIX Digest Sun, 19 Jun 1988 V5#073
Today's Topics:
Re: Electronic Conferencing Systems -- Who makes 'em?
basic
Re: C/IBM
Re: QIC-xx tape standards
Re: make
Re: TeX->nroff Conversion Package
How many others use Virtual Device Interface?
-----------------------------------------------------------------
From: Rusty Hodge <rusty@hodge.uucp>
Subject: Re: Electronic Conferencing Systems -- Who makes 'em?
Date: 16 Jun 88 21:07:10 GMT
Keywords: BBS, CONFERENCING
To: info-unix@SEM.BRL.MIL
In article <15719@sgi.SGI.COM>, hargrove@olympus.SGI.COM (Mark Hargrove) writes:
>
> I would actually appreciate the names of any vendors of Electronic
> Conferencing systems that run on *either* UNIX or VMS.
Here is the poop on People-Net (P-Net) (edited for Television):
What Is P-Net?
P-Net is the finest computer-based conferencing and electronic mail
software system available today. It operates in most Unix/Xenix
environments. Users, however, need not be aware of or have any
familiarity with the operating environment, or computers in general for
that matter, as P-Net is effectively self-contained and does not depend
on Unix from the user's perspective. Those familiar with Unix can be
allowed 'shell access' from P-Net, if desired.
P-Net is easy to operate and non-obtrusive to the communications
environment. It is fully command driven, and there is plenty of help at
any prompt or level if it is requested. Letters and messages are free-
form, with no line limits or other constraints. Wordwrap is in effect
during all composition, so it is very easy to produce clear, readable
text, while concentrating only on the thoughts you wish to get across to
a reader.
P-Net's can be networked together via phone lines with various
conference topics running in parallel on each system. That is, each
P-Net in the network would receive each other's conference messages and
post them in the proper order, maintaining topical 'threads' of
conversation. This is a very effective way to provide low cost
teleconferencing between points physically very far apart. Private
electronic mail can be directed to a user on any P-Net in the network.
Traffic can be 'queued' for immediate delivery to a target site, left
for later delivery when the phone rates are low, or routed through other
sites to the ultimate destination. P-Net can also take advantage of
other networks as its communications transport.
P-Net has been under development for over three years, being continually
tested, expanded and improved during that time. Of course, expansions
and improvements are a continuing effort based on our ideas and feedback
from current users and customers.
P-NET FUNDAMENTALS
Host Computer
P-Net software can be installed on a wide variety of Unix or Xenix
machines. Its file system is located in a secure directory structure
and is not accessible by regular Unix users. Only the system operator
(or those given security clearance) have access to any of P-Net's file
system.
Any number of public and private conversations can be created as needed.
Each conversation and topic within a conversation can be assigned a
moderator who will be in charge of that particular discussion. The
moderator has the power to add or delete participants (if the topic is
private), delete or move messages that may not be appropriate to the
current discussion, etc. A wide variety of topic types may be
configured.
A conversation may have any number of topics within it, and each topic
may have its own moderator. A topic is a division, or separate subject,
each within the domain of the conversation it is a part of. Each topic
may have any number of messages and comments.
Text is typed in by users in response, or comment, to any other message
in that topic. Or, a new thread of messages may be started. Each
message is marked with the user's name, date and time, message subject
and number. Whether that message is a comment or has comments to it is
also indicated. When read, messages and comments are displayed in the
conversation order (comments to messages are read immediately following
the original message) rather than sequentially by date (though
sequential operation is an option).
Because comments can be typed in at the user's convenience, and the
parent (original) message is always referenced, more thought can be
given to one's comments than is typical in face-to-face communication,
yet information is exchanged much more rapidly than with correspondence
using regular mail. Since the conversational thread is maintained, it
is also possible for one who has just joined the proceedings to quickly
come up to speed on the discussions thus far.
P-Net allows many individuals at a variety of locations to carry on
discussions asyncronously, that is, without having to connect to the
computer at the same time.
P-Net participants can join any topics to which they are permitted
access, to read existing messages, and enter new messages and comments.
P-Net uses its own built-in mail system for all private mail traffic.
It allows multiple recipients, Carbon-Copies, Blind-Carbon-Copies and
many other features. Incoming mail can be saved to disk (in your own
private directory), forwarded to another user or users, or replied to.
Private mail being sent can be composed online, loaded from disk, or
both. A line editor is included for editing convenience.
P-Net can communicate directly with other P-Net's or the Unix 'host'
machine on which it is running. By providing the Unix gateway, P-Net's
private mail system can exchange mail and files with other P-Net's, as
well as with the world-wide uucp-net, Usenet, and other networks which
gateway to those. It also understands pass-through traffic and site
aliasing.
Other Features
- News Items can be posted for one-time display to each account
holder when they log in.
- Users are automatically notified when new private mail has been
delivered to their mailbox.
- A 'lounge' area provides a place for real-time chatting. Ideal for
coordinated meetings when all parties needed are online at the same
time.
- Messages originating on another mail site can be delivered to an
assigned topic just as if that person posted directly.
- Private re-distribution lists can be maintained where mail sent to
a particular P-Net account will be re-sent to all recipients in a
list.
- A file utilities section allows each user access to their personal
and private file directory, and also provides uploading and
downloading of files using a variety of protocols. Users may
'attach' to other user's directory (by permission only, of course)
to share files and other information.
- Files may be 'included' in mail to another P-Net account, causing
that included file to be saved in the directory of the recipient.
- A complete database of local users is maintained on each P-Net. A
sorted list may be produced, or the list can be searched for
various criteria.
- Each user can have a 'resume' file which is displayed when
information is requested by another account holder. It is free-
form information voluntarily supplied at each account holder's
discretion.
- P-Net's command prompt changes according to which section you are
in currently, and which section(s) from which you came. This
display keeps you informed as to your 'position' within P-Net at
all times.
- Each account has a set of ID 'parameters' that tailors P-Net's
operation to the requirements of that user. Such parameters are
automatically placed into effect at log-on.
Operating System
Most versions of Unix and Xenix are supported, including BSD 4.2/4.3,
SCO Xenix 286 and 386, MicroPort System V, and AT&T System V for the 3B1
(others coming).
Storage Requirements
Anywhere from 5mb to 20mb or more depending on number of accounts,
topics, amount of traffic, etc. P-Net may be operated on a separate
mounted file system, or as part of any other mount.
Number of Users
The number of users on any given system is limited only by the number of
physical ports on the machine. It can be run as a login process, or
invoked manually from a shell.
Accounting and size control
Full account usage accounting and inactive account expiring. Topic
messages can be expired based on total topic size or number of messages.
These are all done as background processes and need little or no
intervention from the system operator.
License Types
A standard commercial single-site object code license is $2250. There
is no extra cost regardless of the number of users on that site.
Systems for which we do not currently provide object code versions of
P-Net will require a source code license at $4500.
There is a special pricing consideration of $550 for private non-
commercial uses of P-Net, such as privately owned and operated Public
BBS or Conferencing operations.
All licensing is based on a single-site usage. Special multiple-site
license pricing is available upon request.
5.2 Who To Contact For More Information
For further information or inquiries, contact Robert Williamson:
United Software Industries, Incorporated
8399 Topanga Canyon Blvd., Ste. #200
Canoga Park, CA 91304
818-887-5800
Email information and inquiries to Bill Blue:
P-Net: pnet01!bblue
ProLine:pro-sol!pnet01!bblue
UUCP: {cbosgd, hplabs!hp-sdd, ucsd, nosc}!crash!pnet01!bblue
INET: bblue@pnet01.cts.com
ARPA: crash!pnet01!bblue@nosc.mil
------------------
Sorry if that was too long. But you asked. :->
> Does anybody actually have (and use) such a system?
Yes. MouseHole is a Macintosh users group (sponsored by MacTutor
magazine) which you are welcome to call and try out. We've been
running on P-net for about 2 months now. (714) 921-2252 12/2400.
Login as 'pnet' and type 'none' for the BBS login. P-net can (of
course) also be called as a standard program from a Unix login.
Hope that helps.
--
Rusty Hodge, HCR Inc, 1588 N. Batavia St. Orange, CA 92667 (714) 974-6300
rusty@hodge.cts.com [uunet vdelta crash]!hodge!rusty FAX (714) 921-8038
-----------------------------
From: lester <lester@ka3adu.uucp>
Subject: basic
Date: 17 Jun 88 23:49:28 GMT
Keywords: basic basmark
To: info-unix@brl-sem.arpa
Is anyone running basmark basic on microport???
We just got it and am trying to get the printer and com ports to work under
it and thought someone may be able to give us some pointers.
Am trying to get a term program to run with no luck. I tried to port
PC-TALK but I get an out of memory error after about line 658 during the
compile. Aslo does anyone have some sources they could post to try out.
Thanks, bob
uunet!wa3wbu!ka3adu!lester
-----------------------------
From: Chuck_M_Grandgent@cup.portal.com
Subject: Re: C/IBM
Date: 17 Jun 88 01:39:25 GMT
XPortal-User-Id: 1.1001.3636
To: info-unix@SEM.BRL.MIL
Having been a manager presiding over a group of software development
folk used to COBOL for years, who were somewhat suddently thrown onto
a UNIX-based development platform, I'd like to throw my two cents in.
My first exposure to COBOL was 12 years ago in college. I hated COBOL
so much I flunked it the first time. However over many years I grew
to appreciate its strengths in several areas: 1) excellent file handling
capabilities, unmatched by any other language I've encountered
2) excellent self-documenting characteristics due to its English-like
verbosity. On a System-V platform, we went for Microfocus COBOL, which
I would recommend. What we DID do, was to port a couple MSDOS "C"
libraries to UNIX and then call them from the COBOL. This was seen
to be a nice situation. The libraries did handy data and date/time
conversion stuff, and would've been a pain in COBOL. The consensus
grew to be that a nice combination of "C" and COBOL got along real
well together.
-----------------------------
From: mslater@cup.portal.com
Subject: Re: QIC-xx tape standards
Date: 17 Jun 88 04:05:58 GMT
XPortal-User-Id: 1.1001.4222
To: info-unix@brl-sem.arpa
Freeman Associates in Santa Barbara was the keeper of the QIC standards,
last I checked.
-----------------------------
From: Leo de Wit <leo@philmds.uucp>
Subject: Re: make
Date: 17 Jun 88 11:16:31 GMT
To: info-unix@brl-sem.arpa
In article <16104@brl-adm.ARPA> PAAAAAR%CALSTATE.BITNET@cunyvm.cuny.edu writes:
>I have been having a long battle with the 'make' on our 2.9BSD PDP Unix
>The documentation is dated August 1978 and most of the files haven't changed
>since 1982. The Makefile is full of commands look as if the predate UNIX as
>we know it today...
>
>Qn 1. Can anyone describe the later versions of 'make'
See the man pages. Too much to insert here. If you want copies please mail.
>Qn 2. Has anyone come up with a better way to do it?
The Sys5 make is more elaborate; the Sun make also knows of header dependencies
but still I think the standard make is quite adequate.
>Qn 3. What I need to do is keep between 10 and 20 nrofd'ed files uptodate.
[stuff deleted...]
I think your problem isn't that hard, but you shouldn't try to solve it
using make only. You have hinted to use sed yourself. What about this one:
1) Call your nroff files something like xxxxx.nrf, i.e. give them an extension.
And also for the formatted files, e.g. xxxxx.txt.
Now put in your makefile the following lines:
.SUFFIXES: .txt .nrf
.nrf.txt:
nroff -ms $< >$@; chmod 664 $@
rm -f /usr/class/$@; ln $@ /usr/class/$@
Now if you say: make week20.txt and it is not up to date, it will be made
(note the somewhat clumsy ln is needed because make expects files to reside
in the same directory for the suffix rules. You could also put the .nrf files
in the /usr/class directory).
But I assume you want to let make decide even what targets to be made?
Even this is possible: Have a first entry all in the makefile:
all:
$(MAKE) dummy `ls *.nrf|sed 's/\.nrf/.txt/'`
dummy:
The dummy entry is needed to avoid problems when there are no .nrf files
(see for yourself what happens if you omit it!).
Hope this solves your problem - like to hear about it.
>Dick Botting
>PAAAAAR@CCS.CSUSCC.CALSTATE(doc-dick)
>paaaaar@calstate.bitnet
>PAAAAAR%CALSTATE.BITNET@{depends on the phase of the moon}.EDU
>Dept Comp Sci., CSUSB, 5500 State Univ Pkway, San Bernardino CA 92407
>Disclaimer: I am an only an egg
egg: chicken
lay <$? >$@
chicken: egg
brood <$? >$@
$ make egg
Make:$! nulled; predecessor circle.
Even make doesn't know which one was older 8-).
Leo.
-----------------------------
From: Dan Trottier <dan@maccs.uucp>
Subject: Re: TeX->nroff Conversion Package
Date: 18 Jun 88 01:03:32 GMT
Followup-To: comp.unix.questions
To: info-unix@SEM.BRL.MIL
In article <11945@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <16150@brl-adm.ARPA> JPLILER@simtel20.arpa (John R. Pliler) writes:
>>... I am looking for a conversion package to convert TeX documents into
>>nroff format.
>
>I would say that it cannot be done, except that nroff and TeX both
>contain programming languages. Certainly it is not easy (even the
>other direction is quite difficult).
Actually it can be done and has been done. Someone at the University of
Toronto has done an excellent job. This is a sample of the README file.
Hopefully it will be available in the near future to everyone.
--- README ---
texi2roff - texinfo to troff translator
Alpha Version 1 February 1988
Copyright 1988 Beverly A. Erlebacher All Rights Reserved
Some notes on this program
--------------------------
texi2roff is a program to convert documents written using the texinfo
macro package for TeX to be printable with nroff and troff. All
texinfo commands are supported to some extent, even if by carefully
discarding them. Since texinfo allows the use of arbitrary TeX
commands provided their leading \ is converted to a @, many common
TeX commands not explicitly in texinfo are supported as well. To
see which commands are supported, and how thoroughly, examine the
table.h file. Any command whose type in the table is DISCARD will
disappear with all contained text.
[A couple of lines about updates deleted ...] I would
like to post it to comp.sources.unix and/or donate it to the GNU project
for undying fame and glory, or perhaps transient notoriety, when it is in
better shape, so please don't spread it around yet.
[So please don't send me mail asking for it! ]
[This is the amazing thing...]
Before I took this thing on a few weeks ago, I knew almost nothing about
either TeX or troff. I think some of the discarded commands could be
implemented fairly easily by someone more conversant with troff. I am
embarrassed to be hand-formatting this readme.
[More lines deleted about how to use the utility and some of the limitations
of the software. ]
--- END OF README ---
Of course it would be nice if TeX and Ditroff produced the same DVI format.
I hate having to remember which device driver is for which formatter. Maybe
Larry Wall will come out with a text formatter and we can all say goodbye
to what we currently use :-)
dan
--
A.I. - is a three toed sloth! | ...!uunet!mnetor!maccs!dan
-- Official scrabble players dictionary -- | dan@mcmaster.BITNET
-----------------------------
From: j eric townsend <erict@flatline.uucp>
Subject: How many others use Virtual Device Interface?
Date: 19 Jun 88 00:14:51 GMT
Keywords: UNIX-PC, VDI, unix, graphics
To: info-unix@SEM.BRL.MIL
I've got the Virtual Device Interface package for the 3b1 running
rel 3.0 UNIX.
What I'm wondering, is, does anybody else use this?
I'm about to start fiddling with graphics stuff on the 3b1. I'd
like to be able to ship anything I write to other people. I know
curses is the supposed standard of unix, but I don't have a full
implementation, and the stuff I'm writing will be "real" bit-map
graphics.
The package I have (claims to) support:
(among other things)
AT&T 470, 455, UNIX-PC;
CIT101, 161;
Diablo C150;
Epson MX100, 80;
HP 7470-A, 7475-A;
Okidata 92/93;
Strobe 100,200,260;
Tektronix 4105;
and VT100 with "Retro-Graphics Card (tm)".
So what's the verdict? If I write using VDI, will only UNIX-PC users
ever be able to use it, or do other UNIXes support this?
It also talks about making things "METAFONT" compatible.. What's
that? (I seem to remember seeing a Metafont book near a TeX book in the
bookstore. Any relation?)
thx in advance.
--
"It was men made her that way, Skate UNIX or go home, boogie boy...
it was us made her that way." -- from "Airhead" by Thomas Dolby
J. Eric Townsend ->uunet!nuchat!flatline!erict smail:511Parker#2,Hstn,Tx,77007
..!bellcore!tness1!/
-----------------------------
End of INFO-UNIX Digest
***********************uucp@att.att.com (01/12/90)
We have been unable to contact machine 'mwood' since you queued your job.
The following file have not been delivered.
mwood!mail attcc!hpn (Date 01/10)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:
Note: this command can only be executed on machine (att):
uustat -kmwoodZ2928
Sincerely,
att!uucp
#############################################
##### Data File: ############################
From arpa!VM.TCS.Tulane.EDU!INFO-UNIX%BRL.ARPA Wed Jan 10 16:33:06 EST 1990 remote from att
Received: from TCSVM.BITNET by VM.TCS.Tulane.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 5992; Wed, 10 Jan 90 17:05:58 CST
Received: from TCSVM.BITNET by TCSVM.BITNET (Mailer R2.05) with BSMTP id 7456;
Wed, 10 Jan 90 17:05:57 CST
Date: Wed, 10 Jan 90 16:33:06 EST
Reply-To: INFO-UNIX%BRL.ARPA@VM.TCS.Tulane.EDU
Sender: Info-Unix distribution list <I-UNIX@VM.TCS.Tulane.EDU>
From: "Michael J. Chinni, SMCAR-CCS-E" <mchinni%PICA.ARMY.MIL@VM.TCS.Tulane.EDU>
Subject: duplicate fildes for open file
Comments: To: info-c@research.att.com
Comments: cc: info-unix@BRL.MIL, masscomp@soma.neuro.bcm.tmc.edu
To: Multiple recipients of list I-UNIX <I-UNIX@TCSVM>
Help,
Situation is the following:
I need to read data in a C routine from a file opened by a FORTRAN main
routine. When the program is run:
the file is guaranteed to exist
the file is guaranteed to have been opened
the FORTRAN unit number for this open file is known
the name of the file is known
Question:
Is there any way to get a valid "FILE *ptr" for my C routine for this currently
open file ?
Any help will be very much appreciated.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Michael J. Chinni
Chief Scientist, Simulation Techniques and Workplace Automation Team
US Army Armament Research, Development, and Engineering Center
User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey
and dust covered workstation () ARPA: mchinni@pica.army.mil
"System been down long?" () UUCP: ...!uunet!pica.army.mil!mchinni
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/uucp@att.att.com (01/14/90)
We have been unable to contact machine 'mwood' since you queued your job.
The following file have not been delivered.
mwood!mail attcc!hpn (Date 01/11)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:
Note: this command can only be executed on machine (att):
uustat -kmwoodZ2932
Sincerely,
att!uucp
#############################################
##### Data File: ############################
From arpa!VM.TCS.Tulane.EDU!INFO-UNIX%BRL.ARPA Thu Jan 11 08:56:20 EST 1990 remote from att
Received: from TCSVM.BITNET by VM.TCS.Tulane.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 6243; Thu, 11 Jan 90 09:30:29 CST
Received: from TCSVM.BITNET by TCSVM.BITNET (Mailer R2.05) with BSMTP id 8872;
Thu, 11 Jan 90 09:30:28 CST
Date: Thu, 11 Jan 90 08:56:20 EST
Reply-To: INFO-UNIX%BRL.ARPA@VM.TCS.Tulane.EDU
Sender: Info-Unix distribution list <I-UNIX@VM.TCS.Tulane.EDU>
From: Marshall Feldman <RLN101%URIACC.BITNET%BROWNVM.BROWN.EDU@VM.TCS.Tulane.EDU>
Subject: Re: UNIX or XENIX??
Comments: To: INFO-UNIX@BRL.MIL
To: Multiple recipients of list I-UNIX <I-UNIX@TCSVM>
In-Reply-To: Message of Wed, 10 Jan 90 17:50:52 CST from <C183423@UMCVMB>
Regarding VP/IX.
I haven't used VP/IX, but from what I've read it's similar to MERGE/386
from Locus. The question on running "DOS tasks in the background" seems
confused. First, Merge let's you run *several* (as many as memory and
other machine resources permit) DOS sessions in the foreground. For example,
you can start LOTUS as one session and WordPerfect as another *at the same
time*. You move from session to session by using a hot-key sequence.
In UNIX parlance, running a task in the background usually means running
the task in noninteractive mode. This is possible with MERGE/386, and again
the restrictions are the same as for any other UNIX tasks: memory size
and other resources limit the number of tasks that can be run simultaneously.
However, relatively few DOS applications are designed to be run in a
noninteractive mode, so I'm not sure this is really what you want.
Beyond this, there are several other advantages of running DOS under UNIX:
1) Files are protected by UNIX file security (this is important in a
university environment where relatively few PC's are truly personal).
I have no qualms about letting my eleven-year-old (or even worse, his
Luddite mother) play around with their files on my hard disk at home.
2) All of UNIX's utilities (cron, uucp, etc.) are available. Some of these
(e.g. cron) do things that are impossible under DOS (like automatically
have your machine call another at a preassigned time on a regular basis).
3) Commercial software is *much* cheaper for DOS, particularly as a
university. Note that the degradation under MERGE is not that bad (at least
when only one DOS session is running). A 16 or 20MHz '386 runs about as
fast as a 10 or so MHz 286 DOS-only machine.
4) Shell scripts, etc. can be used to manage DOS in ways Bill Gates
never dreamed of.
From what I've read, VP/IX and MERGE/386 are pretty similar. VP/IX seems
more oriented towards the DOS user coming over to UNIX, while MERGE works
the other way around. Yet they seem to have fundamentally the same
capabilities. Also note that SCO sells VP/IX for XENIX, but is using
MERGE in its new Open Desktop (ODT) package. That may or may not influence
your decision. Also *be absolutely sure* your graphics board is compatible
with the package you buy. Otherwise you may find you can only run CGA
or text applications.
Contact me directly if you have any questions.uucp@att.att.com (01/14/90)
We have been unable to contact machine 'mwood' since you queued your job. The following file have not been delivered. mwood!mail attcc!hpn (Date 01/11) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: Note: this command can only be executed on machine (att): uustat -kmwoodZ2933 Sincerely, att!uucp ############################################# ##### Data File: ############################ From arpa!VM.TCS.Tulane.EDU!INFO-UNIX%BRL.ARPA Thu Jan 11 11:04:02 EST 1990 remote from att Received: from TCSVM.BITNET by VM.TCS.Tulane.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 6325; Thu, 11 Jan 90 11:48:19 CST Received: from TCSVM.BITNET by TCSVM.BITNET (Mailer R2.05) with BSMTP id 9332; Thu, 11 Jan 90 11:48:17 CST Date: Thu, 11 Jan 90 11:04:02 EST Reply-To: INFO-UNIX%BRL.ARPA@VM.TCS.Tulane.EDU Sender: Info-Unix distribution list <I-UNIX@VM.TCS.Tulane.EDU> From: David L Jarvis <DLJARVIS%SUVM.BITNET%CORNELLC.CIT.CORNELL.EDU@VM.TCS.Tulane.EDU> Comments: To: Info-Unix List <INFO-UNIX@sem.brl.mil> To: Multiple recipients of list I-UNIX <I-UNIX@TCSVM> Regarding VP/ix and Merge: I currently have SCO's Xenix/386 and VP/ix on an 80386/20 ... all the things that were in the recent posting about Merge also apply to VP/ix ... I tend to suspect they are possibly a bit more than similiar :-) I've run multiple (as many as 4) Dos sessions concurrently with as many as 8 normal Xenix application sessions ... no prob and not much degradation ... I particulary like the combining of Xenix/Dos that happens ... it's nice to have both :-) The warning about the graphics card should be underlined and blinking! Be more than careful, leave no room for surprises! Sadly enough tho, I get the distinct impression that BOTH Xenix and VP/ix are being abandoned by SCO and many others. (in favor of Unix and Merge etc..etc..) Does anyone know if this "new" Unix from SCO will accomodate a Dos partition on the same hard drive with the capability of accessing the file system from within Unix &| Merge-VP/ix ???? (yes I know about having both reside on the same hd, and I do have that, but I'd like to be able to have VP/ix or whatever access my Dos partition directly, is this possible?) ___david___
uucp@att.att.com (01/14/90)
We have been unable to contact machine 'mwood' since you queued your job.
The following file have not been delivered.
mwood!mail attcc!hpn (Date 01/11)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:
Note: this command can only be executed on machine (att):
uustat -kmwoodZ2934
Sincerely,
att!uucp
#############################################
##### Data File: ############################
From arpa!VM.TCS.Tulane.EDU!INFO-UNIX%BRL.ARPA Thu Jan 11 11:55:23 EST 1990 remote from att
Received: from TCSVM.BITNET by VM.TCS.Tulane.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 6330; Thu, 11 Jan 90 12:27:17 CST
Received: from TCSVM.BITNET by TCSVM.BITNET (Mailer R2.05) with BSMTP id 9380;
Thu, 11 Jan 90 12:27:16 CST
Date: Thu, 11 Jan 90 11:55:23 EST
Reply-To: INFO-UNIX%BRL.ARPA@VM.TCS.Tulane.EDU
Sender: Info-Unix distribution list <I-UNIX@VM.TCS.Tulane.EDU>
From: "M. Smith" <mlsmith%NADC.ARPA@VM.TCS.Tulane.EDU>
Subject: Re: Wanted CD-ROM Info
Comments: To: info-unix@sem.brl.mil
To: Multiple recipients of list I-UNIX <I-UNIX@TCSVM>
Page -1-
>We have some questions regarding CD-ROMs:
>
>1- Who makes CD-ROM mastering software ? Is there any under UNIX ?
>
Meridian Data Systems and Reference Technology sell turnkey sys-
tems (MS-DOS based) which will produce nine track tapes. CD-ROM
is system independent so if you can get your tar tapes read on
the nine track drive you can make disks.
>1a - What format do CD-makers want as input for the mastering of
> the CD-ROMs ?
> Can I give them a tar/cpio tape and they will make High
> Sierra out of it ?
> Which are the relevant standards ?
> Do the de facto standards differ ?
>
ANSI labeled tapes in ISO 9660 format should be accepted by ever-
ybody but PDO (Phillips) who require some kind of additional
header as well as the CD-ROM image. Disktronix would even make a
tape from an ANSI file tape if proper documentation was provided
(I don't know about tar tapes). The easiest way to made a disk is
to get a Yamaha WORM drive that makes CD-ROM compatible media and
interface it to your UNIX machine.
>2- where can we find a list of *all* currently available CD-ROMS?
> (i.e. is there something analogous to "Books in Print" ?)
>
There will never be a total list because probably a majority of
disks being made are limited distribution. A good way to receive
information on all upcoming CD-ROM products is to join SIGCAT by
contacting E. J. "Jerry" McFaul at the U.S. Geological Survey,
Reston, VA.
>3- A lot of the CD-ROMs come out of the MS-DOS
>world...consequently a lot of files are kept in the ARC format.
>Is there any PD implementation of a program able to understand
>the .arc files and unpack them under UNIX ?
>
Someone already answered this, but note that this is one of the
confusions of CD-ROM. Some disks have been produced that can be
played on both MacIntosh and IBM-PC computers, but as always a
Mac executable is gibberish on a PC and vice versa. To get a PC
software module to work under *NIX a compatibility window (or
equivalent) must be used.
>4- Which are good CD-ROM readers ? We have heard the Toshiba one
>is meant to be the fastest (whatever that means). Is this true ?
>Can you recommend one ?
>
For the drives we have, my preference is Hitachi, then Sony, and
lastly Phillips. Since you have said you want SCSI, I recommend
that you get a driver that caches at least one full track of the
CD-ROM.
>4a- Are there any CD-ROM jukeboxes ? (We need a SCSI interface
>for all devices).
I have talked to several WORM jukebox manufacturers and they say
that the CD-ROM drives that use a disk carrier can be installed
in their equipment. However, since the profile of the CD-ROM car-
rier and the WORM cartridges are different, some modification of
the existing hardware is required.uucp@att-in.att.com (01/18/90)
We have been unable to contact machine 'mwood' since you queued your job. The following file have not been delivered. mwood!mail attcc!hpn (Date 01/16) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: Note: this command can only be executed on machine (att): uustat -kmwoodZ298c Sincerely, att!uucp ############################################# ##### Data File: ############################ From att-in!VM.TCS.Tulane.EDU!INFO-UNIX%BRL.ARPA Tue Jan 16 20:44:29 CET 1990 remote from att Received: from TCSVM.BITNET by VM.TCS.Tulane.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 8588; Tue, 16 Jan 90 18:29:48 CST Received: from TCSVM.BITNET by TCSVM.BITNET (Mailer R2.05) with BSMTP id 1631; Tue, 16 Jan 90 18:29:46 CST Date: Tue, 16 Jan 90 20:44:29 CET Reply-To: INFO-UNIX%BRL.ARPA@VM.TCS.Tulane.EDU Sender: Info-Unix distribution list <I-UNIX@VM.TCS.Tulane.EDU> From: Klaus Koehler <KOEHLER%DMRHRZ11.BITNET%CUNYVM.CUNY.EDU@VM.TCS.Tulane.EDU> Subject: help Comments: To: info-unix@BRL.MIL To: Multiple recipients of list I-UNIX <I-UNIX@TCSVM> help
uucp@att-in.att.com (01/18/90)
We have been unable to contact machine 'mwood' since you queued your job. The following file have not been delivered. mwood!mail attcc!hpn (Date 01/16) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: Note: this command can only be executed on machine (att): uustat -kmwoodZ297b Sincerely, att!uucp ############################################# ##### Data File: ############################ From VM.TCS.Tulane.EDU!INFO-UNIX%BRL.ARPA Tue Jan 16 07:29:08 CST 1990 remote from att Received: from TCSVM.BITNET by VM.TCS.Tulane.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 8230; Tue, 16 Jan 90 07:29:14 CST Received: from TCSVM.BITNET by TCSVM.BITNET (Mailer R2.05) with BSMTP id 9322; Tue, 16 Jan 90 07:29:14 CST Date: Tue, 16 Jan 90 07:29:08 CST Reply-To: INFO-UNIX%BRL.ARPA@VM.TCS.Tulane.EDU Sender: Info-Unix distribution list <I-UNIX@VM.TCS.Tulane.EDU> From: cctal!andrew%RELAY.EU.NET@VM.TCS.Tulane.EDU Subject: Unisoft System VII Comments: To: info-unix@sem.brl.mil To: Multiple recipients of list I-UNIX <I-UNIX@TCSVM> Dear all, I am new to UNIX et al (Don't panic, I *have* read FAQ and I'm *not* going to ask "How do I ...?") and, to save destroying someone else's system, I am learning (blundering about) on an old Bleasdale (68000 chip) running Unisoft's port of Version VII which I acquired very cheap. I would be grateful if anyone out there who has software configured to run in this (e.g. GNU or comp.sources), and who would be willing to share it, would contact me. I am particularly interested in comms, mail, etc., these seeming to be rather weak in VII, but would be grateful for anything. I would also be grateful for a termcap to suit Cifer 1800 or 2600 series terminals. Lastly, if anyone has any old Bleasdale bits and pieces they no longer want, could we talk? (The last two are intended for UK readers, as Cifer and Bleasdale are both British manufacturers.) Thanks Andrew Hardie ...!ukc!cctal!andrew London, England
uucp@att-in.att.com (01/18/90)
We have been unable to contact machine 'mwood' since you queued your job. The following file have not been delivered. mwood!mail attcc!hpn (Date 01/16) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: Note: this command can only be executed on machine (att): uustat -kmwoodZ2983 Sincerely, att!uucp ############################################# ##### Data File: ############################ From arpa!VM.TCS.Tulane.EDU!INFO-UNIX%BRL.ARPA Mon Jan 15 07:43:12 PST 1990 remote from att Received: from TCSVM.BITNET by VM.TCS.Tulane.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 8021; Mon, 15 Jan 90 11:42:42 CST Received: from TCSVM.BITNET by TCSVM.BITNET (Mailer R2.05) with BSMTP id 7876; Mon, 15 Jan 90 11:42:41 CST Date: Mon, 15 Jan 90 07:43:12 pst Reply-To: INFO-UNIX%BRL.ARPA@VM.TCS.Tulane.EDU Sender: Info-Unix distribution list <I-UNIX@VM.TCS.Tulane.EDU> From: merrell%DATA.MRC.UIDAHO.EDU@VM.TCS.Tulane.EDU Subject: second request Comments: To: info-unix%brl.arpa@cunyvm.cuny.edu To: Multiple recipients of list I-UNIX <I-UNIX@TCSVM> Please drop me from the mailing list. rmerrell@groucho.mrc.uidaho.edu Thanks Randy Merrell Microelectronics Research Center "Rejoice in the Lord always; College of Engineering again I say, rejoice!" University of Idaho -- Phil. 4:4 Moscow, ID 83843 ----------------------------------- UUCP: ucdavis!egg-id!ui3!rmerrell BITNET: rmerrell@groucho.mrc.uidaho.edu INTERNET: rmerrell@groucho.mrc.uidaho.edu
uucp@att-in.att.com (01/18/90)
We have been unable to contact machine 'mwood' since you queued your job. The following file have not been delivered. mwood!mail attcc!hpn (Date 01/16) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: Note: this command can only be executed on machine (att): uustat -kmwoodZ2984 Sincerely, att!uucp ############################################# ##### Data File: ############################ From att-in!VM.TCS.Tulane.EDU!INFO-UNIX%BRL.ARPA Tue Jan 16 09:14:22 CST 1990 remote from att Received: from TCSVM.BITNET by VM.TCS.Tulane.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 8455; Tue, 16 Jan 90 14:41:03 CST Received: from TCSVM.BITNET by TCSVM.BITNET (Mailer R2.05) with BSMTP id 0822; Tue, 16 Jan 90 14:41:01 CST Date: Tue, 16 Jan 90 09:14:22 CST Reply-To: INFO-UNIX%BRL.ARPA@VM.TCS.Tulane.EDU Sender: Info-Unix distribution list <I-UNIX@VM.TCS.Tulane.EDU> From: "David R. Linn" <drl%VUSE.VANDERBILT.EDU@VM.TCS.Tulane.EDU> Subject: sendmail questions Comments: To: info-unix@BRL.MIL To: Multiple recipients of list I-UNIX <I-UNIX@TCSVM> I would like to hear from folks who feel they have understand how sendmail works. I have a couple of different needs/wants for use of context in the address rewriting rules. By "context", I mean that the recipient address depends on the senders address. 1) Policy around here is that there should be two classes of users: those that have access to off campus resources and those that don't. In terms of mail, this means that the class B users should be able to send mail to anyone on campus but should not be able to send mail to off-campus sites. It is not clear what should be done with mail from off-campus to a class B user, but I suspect my superiors would like to discourage that as well. 2) For the ease of identifying a message as local (and therefore probably of higher priority), I would like to internal mail to have no domain part (i.e., "user" instead of "user@vuse.vanderbilt.edu") *BUT* I would like mail from mailing lists that happens to originate locally to be treated as external mail and keep the domain part intact. Can these (probably irrational) criteria be met with sendmail, and if so, how? Please reply directly to me, and if there is sufficient interest, I will post a summary. David David Linn, System Manager/Postmaster/GII* |INET: drl@vuse.vanderbilt.edu Vanderbilt University School of Engineering|Phone: [+1] 615-343-6164 Post Office Box 3241, Station B |Disclaimer: Nashville, TN, USA 37235 | I speak only for myself. *Generally Incompetent Idiot - "I may be stupid, but I'm not d**n stupid!"