From: grv9020@aw2.fsl.ca.boeing.com (Jerry Vanden Heuvel)
Newsgroups: comp.sys.apollo
Subject: Fed up with Support Center, help requested from net
Date: 20 Jul 92 23:47:51 GMT
Organization: none

I've made several calls to the Support Center in the last week with Domain/OS
specific information requests or problems, each time getting the same person
who has been less than helpful and almost surly in attitude.  Lacking any
place else to turn to, I'd appreciate any help from anyone on the net with
the two problems below.

The first problem involves an application conversion from BSD to SysV.  We
are using the BSD gettimeofday function to get a system clock value with the
highest resolution value possible (gettimeofday is 4 microseconds, supposedly).
Gettimeofday returns the timeval structure of two ints in seconds and
microseconds.  There is no analogous System V function (that I know of) which
returns anything with finer resolution than seconds (time(2)).  This is a
general System V problem from the checks I made on other System V implement-
ations I have access to.  There is a structure definition in the Apollo
base.h header file which maps directly into the BSD timeval structure, if
you believe the definition and comments in the header file.  Unfortunately,
I can't find any reference to this structure in the Apollo system call man
pages.  Does anyone know if there is an Apollo specific system call which
returns the time_$timeval_t structure defined in base.h or, even better, a
System V function with seconds and microseconds resolution?

The second problem is again part of our conversion from BSD to System V.  We
are switching from BSD signals with sigblock/sigmask usage to System V
semaphores.  Periodically a startup of the initial process will hang creating
the second of two semaphore sets, each with a maximum of 34 numbers, after
the creation of a shared memory region.  If we try to execute any command
which attempts to access the shared memory region (our own applications) or
use the System V ipcs and/or ipcrm commands, these commands also hang.  After
several minutes, the hung commands return after completing successfully, and
the initial process terminates with a segmentation fault with the following
traceback:

Process        6660 (parent 5738, group 6660)
Time           92/07/20.15:07(PDT)
Program        //aw308/u6/psim/ver_g00/psim/g00/startup
Status         00040004: reference to illegal address (OS/MST manager)
In routine     "baf_$alloc" line 279
Called from    "unix_sem_$get" line 561
Called from    "semget" line 40
Called from    "psim_semcreate" line 788
Called from    "main" line 773
Called from    "unix_$main" line 114
Called from    "_start" line 132
Called from    "PM_$CALL" line 176
Called from    "pgm_$load_run" line 903
Called from    "pgm_$invoke_uid_pn" line 1124

The shared memory region can't be removed with ipcrm (it gets marked with a
"D" for deletion), there are no user processes still attached to it and any
attempts to run the application again result in "too many files open" from
the shget(2) call.  The only recourse is to reboot the node.  The Support
Center always wants a reproduceable example of a problem which is not always
possible, as in this case.  The same application runs fine at times and will
only hang periodically.

We are currently building this application under BSD, accessing the System V
IPC header files via "-I/sys5.3/usr/include".  We've been using System V
shared memory on the Apollo this way since SR9.5 with Domain/IX with no
problems.  We just switched to System V semaphores at SR10.3.5.

Any information about the two problems above will be helpful.  Please email
to the address below, if you can.  I'll try to keep up with the articles in
this newsgroup for a couple weeks for posted help.  Thanks.
-- 
Jerry Vanden Heuvel		 | Voice: (206) 237-3834
Boeing Commercial Airplane Group | Internet:   grv9020@aw300.fsl.ca.boeing.com
P.O. Box 3707, M/S 66-04	 | Boeing net: grv9020@aw300
Seattle, WA  98124-2207		 | UUCP: ..!uunet!bcstec!aw300!grv9020
Newsgroups: comp.sys.apollo