Sorry this took so long... my Internet link has been on the fritz
[actually my service provider's modem pool]. {:-(
If anyone responded but did not get listed below, PLEASE re-transmit!
Anyway, the original posting:
[which I include here hoping to get new responses, hint, hint...]
>
> Hello Sun-Managers:
>
>
> We are migrating our Engineering users from DOS PC's to SPARCstations,
> and are having difficulty with one Engineering application they depend
> on. The vendor does not expect to port to UNIX any time soon, if ever,
> so we are hoping to make do with SunPC for this necessary application.
>
> Now, comes the problem. The application makes use of a "Hardware Key"
> attached to the serial port for license protection. I have been
> attempting to run this application on Sun workstations for a number of
> years (while our system and application design and development was in
> progress), and have never gotten it to "find" the hardware key. I have
> tried on Sun 386i's, and on SPARCstations (1+, IPX, 10mod20), using
> DOSWindows and SunPC, with no success.
>
> Sun had many different theories about the problem ( interrupt latency,
> etc. ), all of which seemed reasonable, until I recently tried the
> application on an IPX with an Artecon ArtePort SBUS serial port. IT
> WORKS!!!!
>
> I can move the hardware key from the motherboard serial port to the
> SBUS serial port in the middle of running the application, and, without
> making ANY configuration changes, the application is happy with the key
> on the Artecon serial port, and unhappy with it on Sun's serial port.
> The software vendor says all they do is tell DOS to shift to 9600 baud,
> send a few bytes to the key, listen for the correct response, and shift
> the port back to its previous baud rate (if other than 9600).
>
>
> What could be the reason? Are there any tests I could perform to get
> the answer? Is there any way to get Sun's serial ports to work??? (We
> do not want to buy an SBUS serial card for every workstation!)
>
>
>
> Thanks in Advance, (I will summarize!)
>
>
> Bob Cronin
> (RJCronin@uop.com)
>
>
>
I got several good suggestions, most of which sounded like good ideas/possibilities:
> It may not help, but there is a jumper on the motherboard of most Suns to shift
> between RS422 and RS232, the default is 422, might be worth changing it over?
I tried this on an IPC. No apparent difference.
> Is there a way to use serial port of other machine on the same
> network as a local serial port?
Possibly when SunPC 3.1 arrives... apparently this will allow network
communications to/from applications running within SunPC. The
application does also have a "network key" hanging off of a Novell file
server. I think this is a long shot, but my fingers are crossed.
> 1) try to put an "analyser" on the serial port (you can fake with a PC
> with 2 serial ports, 1 to tee's of pin 2, one from pin 3 and an fast
> program to watch). See if sun actually stays at the right serial settings,
> etc.
>
> Keep in mind that the Sun's serial ports are driven by the local CPU,
> Artecon's (and Puzzle, etc) have local I/O processors. This may cause
> differences.
>
> 2) If you can, ask the vendor to provide a workaround the key using (god forbid)
> hostid or even a license server that uses ONE hardware key/network.
>
> What engineering App is available on PC but has no equivalent (or
> better) on a Workstation?
Well, our local Sun office is considering bringing in an analyzer.
This may shed some light on what is different between when it works and
when it doesn't.
As for the software vendor, the product is called HYSIM, and is a
simulator for hydrocarbon processing (e.g., oil refining and
petrochemical processing). Although there are several major packages
available for this purpose, each one has different areas in which they
excel.
> Not a solution as such but: Have you considered a couple dedicated PC's running
> DesqView/X? It does a pretty good job running DOS that you can see in an Xserver
> and, since it's running on an actual PC, most things seem to work.
Certainly a possibility, but only as a last resort!
> You might ask what other RS232 functions may be required--or "activated"--
> by the box. Sun's serial ports will function on Tx, Rx and Ground (2,3,7)
> alone; however, the keybox may not. Moreover, if you feed some of the other
> "handshake" signals (varies slightly with Sun model)--like CTS, CD, DSR--
> to the Sun, some of them expect that complimentary set to work, and won't
> send characters through the port without the proper handshake.
> If the keybox functions OK on just 2,3,7, you might try connecting it to the
> serial port using a cable with just those lines in it. Ain't serial lines
> more fun than networks!? Whereis our etherfind for serial lines, anyway? ;^)
Okay, sounds plausible. I talked to the vendor, they said they need
DTR, too. Of course I then tried it without DTR, and it didn't work.
It will work with 2,3,7, and 20. (Tx,Rx,GND,DTR)
Saving the best for last: thus spake Hal Stern...
>
> it's quite possible that this is an issue of buffering in
> hardware. the sbus port expander has some on-board buffer
> space to handle bursts of input, while the sparcstation
> on-board serial ports do not.
>
> what is *probably* happening is that any queued input is
> being flushed when the sun tty driver opens the port,
> but not when you go through the artecon driver. the input
> is probably arriving before something can read the data.
>
> solution (my suggestion): write a simple daemon that always
> reads the port, and slurps the data off as soon as it
> comes in. then provide this data, when requested, over
> a pseudo-tty port. then hook up COM1: (or whatever)
> in your SunPC file to the ptty port used by your daemon.
> cheesy, but it might work
>
> --hal
>
Gosh, sounds easy for you! In fact, I have tried doing something
similar with scripts and a simple C program, but I'm sure not quite
professionally enough. The difficulty here is that this is a 2-way
conversation, and apparently requires some line signalling, too. I was
able to listen in on the conversation (but only one side at a time)
using Artecon's ttytool, and can offer further clues:
The key listens for varying length sequences of 0x00 and 0x01 bytes, with
possibly some 0xFE and 0xFF 's thrown in, and it responds with varying
length sequences of "UOP08" 's , with possibly some 0x00, 0x01, 0xFE,
and 0xFF.
The key can be in the middle of a serial link to a printer, so there
may be some way that the key recognizes when the data is intended for
it, instead of for some other device on the serial line. If so, I
don't know how.
The slowness or rapidity with which the sequences are transmitted does
not affect HYSIM's operation (other than the fact that HYSIM pauses
until the correct corresponding sequence is received from the key).
Anybody want to offer me some further advice or condolences? I'm
always willing to listen! (As long as my link stays up!!!)
Thanks to everyone out there,
Bob Cronin
(RJCronin@uop.com)
Kudos to:
cyerkes@jpmorgan.com (Chuck Yerkes)
Ian Daniel <Daniel@europarc.xerox.com>
sunoct!ktp@Singapore.Sun.COM (Khantipol Kasamsant)
David Fetrow <fetrow@biostat.washington.edu>
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
vasey@issi.com
means@sage.cc.purdue.edu
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:30 CDT