Sun-Spots Digest, v6n22

William LeFebvre Sun-Spots-Request at RICE.EDU
Mon Feb 29 13:11:11 AEST 1988


SUN-SPOTS DIGEST         Sunday, 28 February 1988      Volume 6 : Issue 22

Today's Topics:
        Sun User Group is forming a Finance Special Interest Group
                Re: Need info on PostScript Laser Printers
                      Re: :? fucntion returning void
            Re: Using 3rd and 4th serial port on Sun CPU board
                 dial in / dial out on same tty line (2)
            Bogosity in SunView Programmer's Reference Manual
                   Artecon - Not a Clone but a real Sun
                               UREP on SUN
                          problem with "pr_load"
              Question about Hardware flow control on SUN 3
                      Installing Racal-Vadic modems?
                       importing and exporting NFS?
                   "Dragon" icon for Chinese New Year!

Send contributions to:  sun-spots at rice.edu
Send subscription add/delete requests to:  sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
    TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are stored on "titan.rice.edu".  For volume X, issue Y,
"get sun-spots/vXnY".  They are also accessible through the archive
server:  mail the word "help" to "archive-server at rice.edu".

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

Date:    Wed, 17 Feb 88 10:03:05 PST
From:    Brent Chapman <capmkt!brent at cogsci.berkeley.edu>
Subject: Sun User Group is forming a Finance Special Interest Group

Suns are quickly becoming commonplace tools in high-tech finance
applications on Wall Street, throughout the United States, and around the
world.  Recognizing this, the Sun User Group is forming a Finance Special
Interest Group to address the special concerns of Sun users in this field,
including (but not limited to) reliability, availability, security,
performance, data acquisition, management, storage, and retrieval, legal
issues, tools, and anything else concerned with the design, creation, or
operation of Finance applications using Sun systems. 

I'm the coordinator of the SUG Finance SIG.  I'm a Senior
Programmer/Analyst for a Berkeley, CA, financial services company that
uses Sun systems in its business of managing foreign exchange risk. 

I encourage all interested parties to join the Finance SIG mailing list by
sending Email to capmkt!sug-finance-request at cogsci.berkeley.edu or
sun!ucbvax!cogsci!capmkt!sug-finance-request, or by contacting me
directly:

    D. Brent Chapman
    SUG Finance SIG Coordinator
    c/o Capital Market Technology, Inc.
    1995 University Ave., Suite 390
    Berkeley, CA  94704

    Phone:  415/540-6400


-Brent

Brent Chapman					Capital Market Technology, Inc.
Senior Programmer/Analyst			1995 University Ave., Suite 390
{lll-tis,ucbvax!cogsci}!capmkt!brent		Berkeley, CA  94704
capmkt!brent@{tis.llnl.gov,cogsci.berkeley.edu}	Phone:  415/540-6400

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

Date:    Wed, 17 Feb 88 18:02:52 PST
From:    Alan Stebbens (aks at hub.ucsb.edu) <aks%mondas at hub.ucsb.edu>
Subject: Re: Need info on PostScript Laser Printers

>> From:    (Jeffrey A. Edelheit) <edelheit at community-chest.mitre.org>
>> 
>> In the past, we have purchased Imagen printers.  However, it
>> has been suggested that we now start using PostScript printers.

Imagen is now beta-testing their PostScript-like language (called
UltraScript) printers, which is available as an upgrade to existing 3320,
5320, 6320, 7320 printers, at a reasonable price.

We are part of the beta-test, and cannot [legally] say much about it,
except that with one printer, we now support imPRESS, Tektronix, and
PostScript output.  This is important, as we have many people with various
existing graphics tools producing plots, which print just fine on the
Imagen using the Tektronix language feature.  We have run the Transcript
cookbook against both a LaserWriter Plus and the Imagen, and the output is
pretty much identical.  Imagen seems pretty serious about supporting
UltraScript, as they are doing this beta-test pretty intensively.  We are
completely happy with the reliability and multi-language support that our
5320 gives us.  Moreover, since we have the Ethernet interface, our
printer's bottleneck is NOT the communications channel.

The Apple LaserWriter Plus works very well also, but its paper volume is
less than the Imagen 5320, and its serial port interface (to a Vax 780) is
a little slow at 9600 baud, as compared with the Imagen's Ethernet
interface.  It may be possible to spool to the LaserWriter faster with a
Kinetics FastPath box, by putting the FastPath on the Ethernet, and the
LaserWriter on AppleTalk (which it already is).  We will find this out
pretty soon, as we are getting a FastPath.  Of course, with the
LaserWriter, only PostScript documents are supported.

After our beta-test committment is over, I'll be more specific in
comparisons.

Alan Stebbens   System Manager
		Center for Computational Sciences and Engineering.
		University of California, Santa Barbara
		3111 Engineering
		Santa Barbara, CA 93106

ARPA:   aks at hub.ucsb.edu
BITNET: aks at sbitp.bitnet
CSNET:  aks%ucsb at relay.cs.net
UUCP:   ...{ucbvax,sdcsvax,cepu}!ucsbcsl!aks
VOICE:  (805) 961-3221

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

Date:    Thu, 18 Feb 88 2:56:55 EST
From:    aja at i.cc.purdue.edu (Miek Rowan)
Subject: Re: :? fucntion returning void

It isnt just the Sun compiler that chokes on this.  I had trouble on a
number of C compilers (and with cdecl) when I wanted an array of pointers
to funtions returning void.  

Anyone know why?

miek

[[ I think this is a long-recognized bug in the portable C compiler that
Berkeley (and many others) used.  Did Sun develop their C compiler by
starting with pcc, or did they start from scratch?  The former wopuld
explain (at least in part) the origin of the bug.  --wnl ]]

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

Date:    Thu, 18 Feb 88 11:18:39 PST
From:    Sandy Wells <swells at cowell.ai.sri.com>
Subject: Re: Using 3rd and 4th serial port on Sun CPU board

We have used the 3rd and 4th serial ports on some sun3's (a sun3/160
release 3.4 and a euroboard sun3) The basic story is that the mouse and
keyboard ports are asynchronous serial ports much like the 1st and 2nd
ports, EXCEPT that they are TTL level signals instead of EIA levels.  They
can by accessed by creating /dev/ttyc and /dev/ttyd using mknod.  They
should have the same major device numbers as ttya and ttyb and minor
device numbers which follow those of ttya and ttyb:

mknod ttyc c 12 2
mknod ttyd c 12 3

We found a nice TTL <-> EIA level translator chip which will translate all
four lines, and only needs +5 volts to run (and a few capacitors).  Since
+5 is available at the keyboard/mouse connector on the CPU we were able to
make an electrical adaptor which just connects in line.  The IC is a Maxim
dual RS232 receiver/transmitter, sold by Jameco Electronics, 1355 Shoreway
Road, Belmont, CA 94002.  Note that all 4 ttl signals need to be inverted
to have the proper EIA polarity in this scheme (we used a 74LS04).

The serial signals in and out of the mouse connector are spec'ed in the
sun hardware installation manual (for our sun-3/160).  Note that modem
control lines are not available!

Since SUN does not feature this use of the mouse/keyboard port, there is
probably no guarantee that this hack will continue to work forever.

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

Date:    Wed, 17 Feb 88 22:49:42 EST
From:    perry at sambation.bellcore.com (Perry Metzger)
Subject: dial in / dial out on same tty line (1)

Most of the answers I have recieved have been of the form "use the cua
device drivers documented in so and so a place."

I knew about cua already; it doesn't quite do the trick. The problem is
that I want dialback, not dialout. I want to be able to call someone to
let them log in, not to dial another machine to log in to it.

I am guessing at this point that one solution might be to send the command
to the modem through the cua port and then either somehow get out and tell
getty it can open the line or start login on the line I have just dialed
out on. I am going to see if I can use the latter solution (because I know
how do it and I don't want to fool with what can and can't be opened at
any given time given the state of the carrier). If that works, I will let
everyone know. If anyone else has a yet better solution, please let me
know. And if anyone can figure out how to use this scheme so that the
users processes will properly get sighup if the modem carrier dies, that
would be doubly useful, but I suspect I need a non-cua (i.e. a line that
dies when carrier drops) line to do this. Any additional comments?

Perry

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

Date:    Wed, 17 Feb 88 16:22:59 PST
From:    roode at pisa.orc.olivetti.com (David Roode)
Subject: dial in / dial out on same tty line (2)

See the Sun Installing Unix manual in the section on communications.
Basically you mknod a device special file which has the same major number
and a minor number that is 128 more than the port you are interested in,
calling it say cua2.  You then configure your kernel to not have software
carrier on the port in question. At that point you can enable in /etc/ttys
getty for the line in question but it will only come up when the modem on
the line provides carrier, ie. when a call comes in.  Meanwhile you can go
out the line by refering to it as /dev/cua2, which locks out getty on the
corresponding device for incoming use.  The device with the 128-plus minor
number no longer requires carrier detect in order to send characters out
the line.

Sun's documentation on this is good, but it fails to give a little bit of
extra motivation and explanation which makes the information much more
useful.  It is easy to read the section and not realize what you can do
with it.

	David Roode

	roode%orc.uucp at unix.sri.com
	roode at orc.olivetti.com

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

Date:    Wed, 17 Feb 88 18:14:51 EST
From:    Matt Landau <mlandau at diamond.bbn.com>
Subject: Bogosity in SunView Programmer's Reference Manual

One-Line description:

	SunView system programmer's manual lies about wmgr_figureiconrect.

Elaboration and examples:

	If you're programming at the Suntools/Sunwindows level instead
	of going through the SunView library interface, you still want
	to be able to position windows and icons in a way that obeys
	the SunView icon gravity policies.  

	According to the SunView System Programmer's Manual (pg 172), 
	you can use wmgr_figureiconrect to compute the next available
	icon slot, then use win_setsavedrect to bind it to the window.

	This is a lie.  Examining the source for wmgr_rect.c and
	wmgr_policy.c reveals that wmgr_figureiconrect turns out to be 
	nothing more than a call to wmgr_acquire_next_icon_rect, which 
	is a NO-OP!  The same is true for wmgr_figuretoolrect, by the way.

	The right way to do this is to use the (undocumented?) function
	wmgr_set_icon_rect(int rootfd, int windowfd, rect *r), which
	both computes the icon slot and binds it to the window.  The
	documentation should be updated to reflect this fact.

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

Date:    18 Feb 88 08:38:36 GMT
From:    munnari!ditmela.oz.au!worsley at uunet.uu.net (Andrew Worsley)
Subject: Artecon - Not a Clone but a real Sun

I posted a query a week or two ago about Artecon workstations and here is
the conclusion, slightly delayed because of uunet not being available for
4-5 days, Australia's link to US. Artecon's use Sun boards and OS but
provide their own ESDI disks, cabinets and fans etc. They provide simple
"User friendly" interface on top of SunOS  which is just like some sort of
shell. They are really a VAR (Value Added Reseller) which "provide Sun
components in configurations you cannot get from Sun." I have been assured
by various people that you can apply Sun patches/upgrades with no
problems.

In particular they are rumored to be quieter, have wood grained panel, up
to a Gigabyte of disk and only use one pedestal. I would like to thank
those who responded with info:

weiser.pa at xerox.com, darin at lll-lcc.llnl.gov, jim at boeing.com, tony at artecon
(Works at Artecon for those who want more info).

PS: I am afraid I cannot comment on price as we are in the middle of a
Request for Quotes, which is like a small tender and the rules forbid any
such comments.

				Andrew Worsley

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

Date:    Thu, 18 Feb 88 17:39:35 +0200
From:    leonid at TAURUS.BITNET
Subject: UREP on SUN

Concerning my previous message on this subject:

1. I was wrong claiming the code is Public Domain. The zs_bisync.c pseudo
device  driver is based on the old UREP dup.c device driver written by
Robert M. Owens, thus the code is Copyright by the Penn-State University.
Please accept my apologies.

2. There has been a bug in the driver which caused occasional system
crashes.  This bug has been fixed, if you need the patch, please drop me a
line.

Leonid

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

Date:    Wed, 17 Feb 88 18:44:30 EST
From:    warsaw at cme-durer.arpa (Barry A. Warsaw)
Subject: problem with "pr_load"

I'm having some trouble with the "pr_load" function when the colormap
argument is not NULL.  For background I'm using sunOS 3.2 on a 3/160C.

I have a sun raster file called "rasterfile.im8" which is a 1150x900x8
image.  I can preview the image using sun's screenload program.  Looks
great, full 8 bit image with colormap.  I'm trying to write my own program
that will read this rasterfile into memory, complete with colormap.  In
example 1 below, if I call 'my_read_raster_func' with filename =
"rasterfile.im8", it works as documented.  Note that here I'm setting the
colormap argument to NULL in pr_load so it will ignore any colormap header
info.

Example 1:

my_read_raster_func(filename)
char	*filename;
	{
	FILE	*input;
	struct	pixrect *tpr;

	if ((input = fopen(filename, "r")) == (FILE *) NULL) {
		/* do error handling */
		}

	if ((tpr = pr_load(file, NULL)) == (struct pixrect *) NULL) {
		/* do more error handling */
		}

	/* no error reading pixrect from file so continue as normal */
	}

Now, in example 2, I've modified the colormap argument so that pr_load
should stuff the colormap info into the 'colormap' structure. However,
pr_load bombs out and returns NULL.

Example 2:

my_read_raster_func(filename)
char	*filename;
	{
	FILE	*input;
	struct	pixrect *tpr;
	colormap_t	colormap;

	if ((input = fopen(filename, "r")) == (FILE *) NULL) {
		/* do error handling */
		}

	if ((tpr = pr_load(file, &colormap)) == (struct pixrect *) NULL) {
		/* do more error handling */
		}

	/* no error reading pixrect from file so continue as normal */
	}


Now, I'm sure that the rasterfile has a colormap header on it since
screenload works perfectly.  I'm also sure that it's not just using the
default colormap or < 8 bit image.

I guess I should also mention that this effect is observed without regard
to whether the rasterfile was created by screendump or by pr_dump with a
non-NULL colormap.  I can dump the colormap header but never read it back,
though it pr_dump-ed pixrects DO work with screenload also.

Has anyone else seen this happen?  What am I doing wrong?  What does
screenload do differently to load the colormap from file?  Is there a bug
in pr_load and if so what function does screenload use?  Any help would be
appreciated.  Any actual working examples would also be great.

Thanks in advance.

NAME:   Barry A. Warsaw                 TELE: (301) 975-3460
USMAIL: National Bureau of Standards    ARPA: warsaw at cme-durer.arpa
        Rm. B-124, Bldg. 220            UUCP: uunet!cme-durer!warsaw
        Gaithersburg, MD  20899

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

Date:    Wed, 17 Feb 88 13:41:29 PST
From:    Alex Kreis ("Thypton Coore") <alex at hub.ucsb.edu>
Subject: Question about Hardware flow control on SUN 3

We have a Printronix P300 line printer which we are trying to interface to
a SUN 3/260.  The printer uses an rs232 interface, but we are having
problems getting the two to handle flow control correctly.

The printer only supports hardware flow control -- when its buffer is
full, it changes the state of pin 20 (DTR) of the rs232 connector from
high to low, which is requesting the SUN to stop sending data until its
buffer has emptied a bit.  Attaching this line to CTS/RTS has no effect.
I have also tried the kernel modification mentioned in the manual of
changing the flags from 0x3 to 0x0, and that enabled CD/DTR but did not
effect actual CTS/RTS flow control.

Thus far we have only been able to get the SUN to recognize software flow
control (ctrl-S, ctrl-Q).  We have temporarily used a terminal with a
printer port to act as a "buffer", converting the hardware control signals
to software, but we are running into this problem more and more and need a
more permanent solution.

I have not been able to find anything in the manual sections on how to
enable flow control so that the actual data will stop when an rs232 line
goes low.  If anyone has any experience in this area and/or knows how to
get this working on a SUN, I would appreciate the help.

-Alex Kreis (alex at hub.ucsb.edu)

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

Date:    Thu, 18 Feb 88 14:24:50 est
From:    mlijews at nswc-wo.arpa
Subject: Installing Racal-Vadic modems?

Has anyone installed a Racal-Vadic VA3450?  If so I would appreciate a
copy of the relevant /etc/ttys and /etc/remote entries as well as any
other helpful hints.  I am running SunOS 3.3 on various Sun-3 machines.
Thanks in advance.

Mike Lijewski (mlijews at nswc-wo.arpa)
Code R44
NSWC
Silver Spring, MD 20903-5000

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

Date:    Thu, 18 Feb 88 14:16:05 PST
From:    conrad at cgl.ucsf.edu
Subject: importing and exporting NFS?

I heard a rumor that if you both import and export NFS on a single host,
the performance of the host may decrease significantly.  Is there any
truth to this?  If so, what are possible solutions, given that not all
data may be stored on a single host?  Thanks,

Conrad
conrad at cgl.ucsf.edu

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

Date:    Wed, 17 Feb 88 11:58:42 PST
From:    simran at sun.com (Simran Singh Khalsa)
Subject: "Dragon" icon for Chinese New Year!

/* Je shr "Long" tze  (This is the  Chinese character for "Dragon")
  -- Shen Lan
*/
/* Format_version=1, Width=64, Height=64, Depth=1, Valid_bits_per_item=16
 */
        0x0000,0x0000,0x0000,0x0000,0x0003,0x8000,0xF000,0x0000,
        0x0003,0xC000,0xF003,0x0000,0x0003,0xC000,0xF03F,0x8000,
        0x0003,0xC000,0x70FF,0x8000,0x0003,0x8000,0x71FF,0x0000,
        0x0003,0x0000,0x73C0,0x0000,0x0000,0x77E0,0x7E00,0x0000,
        0x1FFF,0xFFE0,0x7800,0x0000,0x3FFF,0xFFC0,0x7000,0x0000,
        0x1F00,0x0000,0x7000,0x0000,0x0000,0x0000,0x7000,0x0000,
        0x0060,0x0600,0xE00F,0xE000,0x00F0,0x0700,0xFFFF,0xF000,
        0x00F0,0x0600,0x7FFE,0xF800,0x0070,0x0E00,0x7C00,0x3800,
        0x0030,0x0C00,0x0000,0x3800,0x0030,0x0C00,0x0000,0x3800,
        0x0018,0x1C00,0x0000,0x3800,0x0018,0x3800,0x0000,0x3800,
        0x001C,0x30F0,0x0000,0x3800,0x000C,0x7FF0,0x77FF,0xF000,
        0x0F3F,0xFFF0,0xFFFF,0xE000,0x1FFF,0xF800,0xFFFE,0x0000,
        0x1FE0,0x0001,0xFC00,0x0000,0x0000,0x1E01,0xE000,0x0000,
        0x0001,0xFF00,0xC000,0x0000,0x001F,0xF700,0xC003,0xC000,
        0x001E,0x0700,0xE01F,0xE000,0x0030,0x0700,0xE0FF,0x0000,
        0x0030,0x0700,0xE1F0,0x0000,0x0030,0x1F01,0xEFC0,0x0000,
        0x0030,0x7F00,0xFF00,0x0000,0x0033,0xFF00,0xFC00,0x0000,
        0x0037,0xC700,0xE001,0xE000,0x003C,0x0700,0xE007,0xF000,
        0x0030,0x0700,0xE07F,0x8000,0x0030,0x0F00,0xE0FE,0x0000,
        0x0030,0x3F00,0xE3F0,0x0000,0x0030,0xFF00,0xEF80,0x0000,
        0x0077,0xE700,0xFC00,0x0000,0x007F,0x0700,0xF001,0xF000,
        0x0078,0x0700,0xC00F,0xF000,0x0060,0x0600,0xE01F,0x8000,
        0x0060,0x0700,0xE07C,0x0000,0x0060,0x0700,0xE1F0,0x0000,
        0x0060,0x0700,0xE7C0,0x0000,0x00C0,0x0700,0xFF00,0x0200,
        0x00C0,0x0700,0xFC00,0x0600,0x00C0,0x0300,0xE000,0x0700,
        0x00C0,0x0700,0xE000,0x0700,0x00C0,0x0700,0xE000,0x0F80,
        0x0080,0x0700,0xE000,0x1F80,0x0180,0x3F00,0x7000,0x7F00,
        0x0180,0x1F00,0x7FFF,0xFF00,0x0300,0x0F00,0x3FFF,0xFC00,
        0x0600,0x0700,0x0F9E,0x8000,0x0C00,0x0200,0x0000,0x0000,
        0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
        0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
        0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000

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

End of SUN-Spots Digest
***********************



More information about the Comp.sys.sun mailing list