INFO-UNIX Digest V2#055

Info-Unix-Request at BRL.ARPA Info-Unix-Request at BRL.ARPA
Sat Jan 25 22:21:29 AEST 1986


INFO-UNIX Digest          Sat, 25 Jan 1986              V2#055

Today's Topics:
      Adding a Fujitsu 2361 (Eagle-2) disk to VAX 750 under 4.2Bsd
                    Re: emulating ".ascii" with Awk
                         Re: venix versus xenix
                   Help needed in selecting terminals
     Re: Need Non-Blocking Terminal Input Function For Berkeley 4.2
                 Mailing articles to oneself for saving
                        Looking for Real Time OS
                      Re: "Idenification Keywords"
                   Calling f77 routines from C: HELP!
                 Wanted: TU81 device driver for 4.2 BSD
-----------------------------------------------------------------

From: Andrew Findlay <andyf%brueer.uucp at BRL.ARPA>
Subject: Adding a Fujitsu 2361 (Eagle-2) disk to VAX 750 under 4.2Bsd
Date: 23 Jan 86 11:02:46 GMT
Keywords: VAX 750 disk Eagle Fujitsu 2361 Emulex SC7002
To:       info-unix at BRL-SEM.ARPA



Adding an Eagle-2 (Fujitsu 2361) to a 4.2Bsd system
===================================================

I have just put an Eagle-2 onto a VAX 750 under 4.2Bsd.
This article describes how it was done so you need not repeat
my mistakes. The software preparation and debugging took
about 40 man-hours, but with the information presented here
it should be possible in less than 8.

The initial configuration was: 2MB, TU80, RA80 on UDA50, DMF-32
The expanded configuration is: 5MB, TU80, RA80 on UDA50, 2*DMF-32
                               Eagle-2 on SC7002

The Fujitsu 2361 Eagle-2 is an expanded version of the well
known 2351A Eagle. It has an unformatted capacity of 689MB
against the Eagle's 474MB.

The first thing to note is that the disk transfer rate has
gone up from 1.859 MB/s to 2.458 MB/s. This means that the
Emulex SC7000 is not fast enough to handle the new drive. You
will need an SC7002, which is just a faster version of the
SC7000.

Another hardware point is that the Eagle-2 is in a bigger box
than the Eagle - 770mm long rather than 700mm. In our case this
means that it sticks out at the front of the cabinet.

Since the Eagle-2 was designed after the 4.2Bsd release, it
does not appear in /etc/disktab or in the hp.c drivers. You
will need to put it in. A quick-and-dirty workaround is to set
up the SC7002 to treat the disk as an old-style Eagle - you
lose storage capacity, but get up and running very easily. I
have not tried this.

Setting up the SC7002
=====================

Set up for an 'expanded RM02' emulation with 64 sectors/track.
This is code 30 on SW1-4. The hp.c drivers use 'RM02' as a flag
indicating that the disk type should be determined by asking
for the number of tracks, cylinders, and sectors. You need at
least revision F of PROM 994.

Preparing the drivers
=====================

(1)   Use diskpart(8) to generate entries for /etc/disktab and
      for the hp.c drivers. Put the result in files for use later.
      Call the disk 'eagle2'.

The parameters are as follows:

Type:                winchester
Sector size:         512
# Sectors/track:     64
# Tracks/cylinder:   20
# Cylinders:         842
Revs per minute:     3600

You should end up with a 'c' partition of 1077760 blocks.

(2)   Install the 'eagle2' entry in /etc/disktab

(3)   Put entries into your configuration file in /sys/conf,
      something like this:

controller     mba0     at nexus ?
disk           hp0      at mba0 drive 0

This assumes the SC7002 will be the only massbus device - if
you already have massbus devices, the 0's above will change.
The SC7002 actually emulates a massbus controller AND up to
eight massbus disks on one board. (It can split a physical
drive into two logical devices)

(4)   Before modifying the system source code, generate a
      system from the new config file to check all is ok. If
      the controller is installed at this stage, the system
      should note the existence of an
      'RM02 with 64 sectors/track?'
      but should not try to use the device.

(5)   Go into /sys/vaxmba to modify the main hp driver.

First take a copy of hp.c for safety, then make changes to hp.c
as follows:

Add the eagle2_sizes entry generated in stage (1) - put it after
eagle_sizes. It should look like this:

 }, eagle2_sizes[8] = {
       15884,  0,              /* A=cyl 0 thru 12 */
       66880,  13,             /* B=cyl 13 thru 65 */
       1077760, 0,             /* C=cyl 0 thru 841 */
       15884,  294,            /* D=cyl 294 thru 306 */
       307200, 307,            /* E=cyl 307 thru 546 */
       377408, 547,            /* F=cyl 547 thru 841 */
       701248, 294,            /* G=cyl 294 thru 841 */
       291346, 66,             /* H=cyl 66 thru 293 */

Add two lines to hptypes[], just before the final 0:

#define HPDT_EAGLE2     15
        -1,

These go just after the line that says 'beware, actually
capricorn or eagle'

Add TWO lines to the hpst[] array, as follows:

{ 64, 20, 64*20, 842, eagle2_sizes, 7, 8 }, /* DUMMY (place holder) */
{ 64, 20, 64*20, 842, eagle2_sizes, 7, 8 }, /* EAGLE-2 */

The dummy line is needed because hptypes[] has a dummy element
14, representing the RM02, whereas hpst[] does not. This one
held me up for a couple of days - the system panics when trying
to reference the disk if you miss the dummy entry.

In the section headed 'EMULEX SC750 or SC780', add code to
recognise the disk at boot time. Put it after the bit that
recognises an eagle:

               if (ntracks == 20 && nsectors == 64) {
                       type = HPDT_EAGLE2;
                       printf("hp%d: eagle-II\n", mi->mi_unit);
                       goto done;
               }

(6)   Re-generate the system with the modified driver.

(7)   Use /dev/MAKEDEV to make device entries for hp0

(8)   Go into /sys/stand to modify the stand-alone hp driver.

In hp.c add a line to the end of hptypes[], so it looks like this:

        .
        .
        .
        MBDT_RM02,      /* actually something else */
        -1,             /* 9300 */
        -1,             /* Eagle-II */
        0
};

In hpmaptype.c add a line to describe the eagle2 and its disk
partitions. Be particularly careful if you did not use diskpart
in stage (1).

short   eagle_off[8] =  { 0, 17, 0, 391, 408, 728, 391, 87 };
short   eagle2_off[8] = { 0, 13, 0, 294, 307, 547, 294, 66 };


Now add two lines in hpst[] so it looks like this:

     .
     .
     .
#define HPDT_9300       13
        32,     19,     32*19,  815,    rm05_off,       /* Ampex 9300 */
#define HPDT_EAGLE2     14
        64,     20,     64*20,  842,    eagle2_off,     /* Fuji Eagle-II */
};


Now add the code to recognise the eagle2:

                if (ntracks == 48) {
                        newtype = HPDT_EAGLE;   /* 48 sector Eagle */
                        goto done;
                }
                if (ntracks == 64) {
                        newtype = HPDT_EAGLE2;   /* 64 sector Eagle */
                        goto done;
                }
                printf("RM02 with %d sectors/track?\n", ntracks);
        done:


(9)   Reconstruct the standalone utilities with make, and copy
      what you need into the root filesystem. This will
      probably be:

      format
      copy
      boot
      drtest

      On a 780, these should go onto the console floppy (?)

(10)  Dump the ENTIRE system onto tape and then get the hardware
      installed!

(11)  The Emulex formatter does not seem to get the bad block
      info in the right place for the hp driver, so use the
      newly generated version of format(8) to sort that out (in
      standalone mode of course). It is then worth using drtest(8)
      to check that all the bad blocks have been found.

(12)  When you boot up the new system, the lines:

mba0 at tr4
hp0 at mba0 drive 0
hp0: Eagle-II

      (or something very similar) should appear on the console.

(13)  You should now have a working 540MB disk. Create
      filesystems with newfs(8) and put it to work.
      To get the best possible performance out of the
      filesystems, the rotational delay parameter needs to be
      set appropriately with tunefs. I used Don Speck's test
      program and found 8ms to be good, so the command is:

tunefs -d 8 /dev/hp0h

      Remember to do this for each filesystem after creating it.

      Perhaps surprisingly, I can find no significant difference
      in performance between a filesystem on an RA80 and one on
      an Eagle-2. These tests were done with a load factor of
      about 1.4 - one active user with a cpu-bound process:

% time dd if=<big file on RA80> of=/dev/null bs=1024 count=1024
1024+0 records in
1024+0 records out
0.4u 4.8s 0:09 57% 13+9k 129+2io 2pf+0w
% time dd if=<big file on Eagle-II> of=/dev/null bs=1024 count=1024
1024+0 records in
1024+0 records out
0.3u 5.0s 0:09 59% 13+9k 263+2io 2pf+0w



Good luck, and please let me know if I have missed out anything
vital....

Andrew Findlay

 ... ukc!reading!brueer!andyf
 ... andyf at uk.ac.bru.ee
-- 

 ------------------------------------------------------------
UUCP:            ...ukc!reading!brueer!andyf
JANET:           andyf%brueer at uk.ac.reading
ARPANET, CSNET:  andyf%brueer at ucl-cs.arpa
 ------------------------------------------------------------

-----------------------------

From: "Charles C. Bennett" <ccb%decvax.uucp at BRL.ARPA>
Subject: Re: emulating ".ascii" with Awk
Date: 24 Jan 86 00:54:05 GMT
To:       info-unix at BRL-SEM.ARPA


Tricky, I don't think awk will do it.
Write a little shell script.

use "od -b" to break the string into bytes in octal
use "sed 's/^.......[ ]*//' to strip addresses from the od output
use tr to convert the spaces in the od output to newlines
prepend the string "ibase=8" to the stuff you have so far
feed the works to the stdin of "bc"
use tr to convert the newlines to commas
use sed to strip the telltale trailing comma

something like:

bc $TMPFILE <<!
ibase=8
`echo $STRING|od -b|sed 's/^.......[ ]*//'|tr ' ' '\012'`
!
echo `cat $TMPFILE|tr '\012' ','`|sed 's/,$//'

the final pipeline leaving the result on stdout.

A 'C' program to do this is trivial.

decvax!ccb

-----------------------------

From: Chuck Forsberg WA7KGX <caf%omen.uucp at BRL.ARPA>
Subject: Re: venix versus xenix
Date: 22 Jan 86 21:50:47 GMT
To:       info-unix at BRL-SEM.ARPA

In article <209 at maynard.UUCP> campbell at maynard.UUCP (Larry Campbell) writes:
>> 	I am getting ready to purchase a pc version of Unix and would
>> to like to know which is the best between xenix and venix. Has anyone
>> had experience with both and can make a recommendation. Compatibility
>> with Sys V is important. Thanks!
>> -- 
>> Signed by: 
>>   aplvax!cp1!hart - aplcen!cp1!hart - umcp-cs!cp1!hart - gamma!cp1!hart
>>   umcp-cs!aplvax!cp1!hart at SEISMO.CSS.GOV
>
>I have used VENIX v2.0 (V7-based) a lot, VENIX 5.0 a little (Sys V
>based), and XENIX 3.0 (Sys III based) a little.  The choice would not
>be clear cut, except for one thing.  It's IMPOSSIBLE to find anything
>in the XENIX manuals because they're unbundled.  That means there are
	SCO SYS V Xenix has the manuals arranged the same way, but
	the man pages do not print different programs on one sheet,
	so they could be rearranged / added to / etc.  I don't like
	the Microsoft arrangement, but I've gotten used to it.
>
>Documentation aside, they're very similar.  The XENIX C compiler is
>somewhat better -- VENIX's allows only one 64K data segment (but
>unlimited code).  Last I looked, VENIX didn't come with troff (nroff
>only) while XENIX did.  VENIX has some real-time features (preemptive
>process priorities) you might find useful.  And the installation
>procedure for VENIX is much easier than for XENIX.
>
>Basically it's a wash, but if you want to have usable manuals, get VENIX.
	Not having a true blue SYS V Unix, I can't comment on the
	extent of compatibility.  I have heard that some tests in 
	the AT&T SYS V Suite cannot be run on 16 bitters hostile to
	Unix, which includes the 80286.

	Large/huge model is still rather buggy, but it is often possible
	to get a particular program to run given sufficient hacking
	time to outwit the Microsoft Cmerge compiler.  There is a possibility
	the large/huge model will be corrected before the 286 it totally
	obsolete.

	The main thing missing from SYS III/V are graphics and the ability
	to specify an arbitrary program instead of getty.

	The Xenix installation is quite straightforward.  There are
	options to control which sub-packages to install, which
	makes life easier on 20 meg systems.  Installation of the
	IBM Xenix was easy also.

	Bottom line: Xenix does work on the AT.  Is doesn't have anything
	to do with IBM's description of the AT as a "4 gigabyte virtual
	memory" system, but it is an improvement on PDP-11's assuming
	one doesn't need graphics or PDP-11 specific software.

-- 
   Chuck Forsberg WA7KGX  ...!tektronix!reed!omen!caf   CIS:70715,131
   Author of Professional-YAM communications Tools for PCDOS and Unix
 Omen Technology Inc     17505-V NW Sauvie Island Road Portland OR 97231
Voice: 503-621-3406 TeleGodzilla: 621-3746 300/1200 L.sys entry for omen:
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp

-----------------------------

From: warren <warren%aloha1.uucp at BRL.ARPA>
Subject: Help needed in selecting terminals
Date: 23 Jan 86 16:01:56 GMT
Keywords: terminals
To:       info-unix at BRL-SEM.ARPA


	Can anyone recommend an inexpensive terminal that works without
any problem with a HP9000 series 550 running HP-UX 5.01.
	Please reply by e-mail to me.
Thanks

Warren Yamauchi
 ...{ihnp4,dual,vortex}!islenet!aloha1!warren

-----------------------------

From: Thomas Scott Christiansen <tom at puff.wisc.edu>
Subject: Re: Need Non-Blocking Terminal Input Function For Berkeley 4.2
Date: 24 Jan 86 13:26:56 GMT
Sender: tom%puff.uucp at BRL.ARPA
Followup-To: net.unix
To:       info-unix at BRL-SEM.ARPA

> Does anyone know of a way to do read from a terminal under Berkeley 4.2 UNIX
> so that after a specified number of seconds control is returned to the
> program if there is no response?  Right now I'm forking off of the main
> program, and having the child process do the read, with the parent setting
> an alarm to interrupt the child after a certain number of seconds.  This
> works, but it's devilishly difficult to debug using dbx.  Alternate 
> techniques would be appreciated.

Yes the read will restart, *IF* you return to it.  The trick is not
to return to it.  You should use setjmp() to remember where you were.
The following module should do what you want.  It contains the function
readt() which works just as read does except that it accepts a fourth
argument indicating the number of seconds at which a timeout is to be
triggered.  If this does occur, errno will contain EINTR.

A sample main() is included to test the function.   I have tested it
on a Gould under 4.2, a Pyramid under 4.2/SYSV, and a Vax 780 under 4.3.
 -----------------------------------------------------------------------

#include <setjmp.h>
#include <signal.h>
#include <errno.h>

#define reg     register
#define global
#define local   static
#define ERROR   (-1)

local  jmp_buf  Context;
local  int      timetrap();
extern int      alarm();
extern int      errno;

/*
 *  readt(): a read function that accepts a
 *           fourth parm indicating the number of seconds 
 *           at which to trigger the timeout.  other parms are 
 *           the same as read.
 *  
 *           returns number of bytes read or -1 on error.
 *           a timeout causes errno to be set to EINTR.
 */
global int
readt ( channel, buffer, count, timeout )
    reg int channel, count;
    reg unsigned timeout;
    reg char *buffer;
{
    reg int retval;
    reg int (*alrm_vec)();

    alrm_vec = signal (SIGALRM, timetrap);
    (void) alarm ( timeout );
    retval   = setjmp (Context)
                ? (errno = EINTR, ERROR)
                : read ( channel, buffer, count );
    (void) alarm ( 0 );
    (void) signal (SIGALRM, alrm_vec);
    return retval;
}

local int
timetrap() {
    longjmp ( Context, 1 );
}

#include <stdio.h>
#define TIMEOUT 3
main() {
    char line[100];

    printf ("string (no timeout): ");
    fflush (stdout);
    if ( read (fileno(stdin), line, sizeof(line)) < 0)
        perror("read");
    else
        printf ( "The string was %s",line);

    printf ("string (timeout == %d): ",TIMEOUT);
    fflush (stdout);

    if ( readt (fileno(stdin), line, sizeof(line), TIMEOUT) < 0)
        perror("readt");
    else
        printf ( "The string was %s",line);
}

/* lint output:
/usr/staff/tom/src/readt.c:
fflush returns value which is always ignored
*/

-----------------------------

From: B A Siegel <sieg%bocar.uucp at BRL.ARPA>
Subject: Mailing articles to oneself for saving
Date: 22 Jan 86 19:31:28 GMT
To:       info-unix at BRL-SEM.ARPA

I would like to after reading an article and wanting to save it ..
 - mail it to myself and retain the SUBJECT line and more importantly
   retain the original path .

I guess i'm saying is there a way I can mail the article to myself yet
make it seem that the article is a "simple piece of mail" mailed directly
to me?
   
In this manner I can then use MAILX (or whatever mailer) and scan which 
messages I want to later. I can simply use the mailers reply feature to 
send mail back to the poster later.

Note: when using the "write to file" feature of VNEWS it does not write 
the header info to the file.

Does anyone have any alternatives or suggestions to accomplish this?

Thanks

Barry Siegel
 ..ihnp4!bocar!sieg

-----------------------------

From: tomas <tomas%myab.uucp at BRL.ARPA>
Subject: Looking for Real Time OS
Date: 24 Jan 86 03:37:12 GMT
To:       info-unix at BRL-SEM.ARPA



	Looking for Real Time Operating Systems.
	----------------------------------------

	Does anyone have any information (or know how/where to obtain
	info. on) real time operating systems for a VME based system.
	I would prefer a UNIX based product, but also information
	about systems like OS9, etc are valuable.

	The basic requirements are:

	    * VME-bus based with 32-bit processor: 680x0 or NS32xxx

	    * Several processes must be able to run at a time, it must
	      support a hard disk (with a file system) and a terminal 
	      interface (for generating statistics etc) [It is intended
	      to be an alternative for an existing RSX-11 system!]

	    * If possible, a cross compiler (Pascal ?) for VAX/VMS generating
	      object modules for this system.

	    * The product should be reliable (used in the industry for a time)

	Anyone had any experience with such a product? If so, I would like
	some answers on the following questions:

	    * What the system really IS (Facts!)

	    * What the system guarantees (response/process switching times, etc)

	    * What it is based on (compatibility with UNIX versions)

	    * Special hardware requirements, limits, etc

	    * Where to obtain it, price, etc

	    * EXPERIENCES WITH THE SYSTEM!!!
	      
	Please answer by mail, and if enough interest, I will make a 
	summary to the net.  Thanks in advance,

		Tomas Olovsson @ MYAB

-----------------------------

From: "Joseph S. D. Yao" <jsdy%hadron.uucp at BRL.ARPA>
Subject: Re: "Idenification Keywords"
Date: 24 Jan 86 06:12:11 GMT
To:       info-unix at BRL-SEM.ARPA

In article <722 at abic.UUCP> crc at abic.UUCP (Clive Charlwood) writes:
>Unfortunately it is incorrect, the section headed
>"Identification Keywords" has a table thus:
>          Keyword   Value
>          get.1     Module name: either the value of the m flag in the
>It Should Read:
>          Keyword   Value
>          %M%       Module name: either the value of the m flag in the

The %M% module keyword worked exactly as advertised.  When get.1
was extracted from s.get.1, the %M% keyword (a relatively late
addition, i think, to the document) was not protected and thus
expanded to the module name "get.1".

Try %\&M\&%, or %\&M% (or %M\&%).

Note that there is a similar problem when archiving C programs
that use multiple printf long-int formats together, as: "%D%O%X%s".
The solution here is to use the l-formats: "%ld%lo%lx%s".
-- 

	Joe Yao		hadron!jsdy at seismo.{CSS.GOV,ARPA,UUCP}

-----------------------------

From: Jeffrey W Percival <jwp%uwmacc.uucp at BRL.ARPA>
Subject: Calling f77 routines from C: HELP!
Date: 24 Jan 86 23:55:22 GMT
To:       info-unix at BRL-SEM.ARPA

This applies to 4.2BSD and Ultrix-32M v1.1:

I am trying to call a f77 subroutine from a C program,
and I find that the supposedly "preconnected" i/o units 5 and 6
are not connected.  That is, when I do a simple print in the
Fortran subroutine, like:

	print *, 'hi!'

I get an entry in a file called fort.6.  What makes this especially
unfortunate, is that this works fine in 2.8BSD, and we have found that
the C/f77 programs that we wrote under 2.8BSD are failing to run
as expected under Ultrix (for the reason just described).

Is there a way to preserve the "preconnections" advertised in the
f77 documentation?

I would very much appreciate any comments you can make on this.  Thanks!
-- 
	Jeff Percival ...!uwvax!uwmacc!jwp

-----------------------------

From: strong%milano.uucp at BRL.ARPA
Subject: Wanted: TU81 device driver for 4.2 BSD
Date: 24 Jan 86 21:23:06 GMT
Sender: strong%milano.uucp at BRL.ARPA
Keywords: DEC TU81 6250 BPI Tape Drive Device Driver 4.2 BSD UNIX
To:       info-unix at BRL-SEM.ARPA


	When I posted a request for info about any extant 4.2 BSD device
	driver for a TU81, my UUCP return address was horribly innacurate.
	The new one is corrected per the admonision of my colleages.

	Please let me know if you are developing/have developed this
	driver.

	Thanks.

	Mike Strong

@ MCC VLSI-CAD Program, Austin TX.  [512] 339-3621 
ARPA: strong at mcc.arpa
UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!strong
-- 
@ MCC VLSI CAD Program, Austin TX.  [512] 339-3621 
ARPA: strong at mcc.arpa
UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!strong

-----------------------------


End of INFO-UNIX Digest
***********************



More information about the Comp.unix mailing list