ewilts%Ins.MRC.AdhocNet.CA@UNCAEDU.BITNET (05/25/88)
Recently, while testing a new print symbiont, all of our batch and print
queues were deleted and the queue manager stopped. The only thing we got
was a JOBCTL.DMP file in SYS$SYSTEM. Contains only a condition signaled
as "%SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged
image". This was a modification to an existing symbiont (LASER, for the
Apple LaserWriter). Since we obviously do not want to experience this
again (a lot of users were sure %^& mad at us!), does anyone have suggestions
as to what we can do? The basic symbiont was written in C, but we added
subroutines written in Fortran if this impacts anything.
Also, does anybody know how to debug a print symbiont? If it is compile/linked
in debug, it does seem to run. Suggestions?
We are new to symbionts but certainly not new to VMS...
.../Ed
p.s. we are running VMS4.6 on an 11/785."James_A._Gray.OsbuSouth"@XEROX.COM (05/27/88)
Query: Recently, while testing a new print symbiont, all of our batch and print queues were deleted and the queue manager stopped. The only thing we got was a JOBCTL.DMP file in SYS$SYSTEM. Contains only a condition signaled as "%SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image". This was a modification to an existing symbiont (LASER, for the Apple LaserWriter). Since we obviously do not want to experience this again (a lot of users were sure %^& mad at us!), does anyone have suggestions as to what we can do? The basic symbiont was written in C, but we added subroutines written in Fortran if this impacts anything. Also, does anybody know how to debug a print symbiont? If it is compile/linked in debug, it does seem to run. Suggestions? Some answers: 1) When analyzing an image dump file from a different directory than the image file you will always get the PRIVINSTALL message unless you specify the /IMAGE qualifier to point to the image file used to create the symbiont. For example, assume that your image file is MYSYMBIONT.EXE and that it resides (as it must) in SYS$SYSTEM, then either $ SET DEFAULT SYS$SYSTEM $ ANALYZE/PROCESS MYSYMBIONT or $ ANALYZE/PROCESS/IMAGE=SYS$SYSTEM:MYSYMBIONT - SYS$SYSTEM:MYSYMBIONT 2) To use the symbolic debugger with a user written symbiont, first compile with the /DEBUG qualifier, then link with the /DEBUG qualifier, redirect DBG$INPUT and DBG$OUTPUT to some real terminal and then finally start the symbiont. For example, $ CC MYSYMBIONT/DEBUG $ LINK MYSYMBIONT/DEBUG $ COPY MYSYMBIONT.EXE SYS$SYSTEM: $ DBG_TERM = "OPA0:" $ DEFINE/NOLOG/TABLE=LNM$GROUP_000001 DBG$INPUT - 'DBG_TERM' $ DEFINE/NOLOG/TABLE=LNM$GROUP_000001 DBG$OUTPUT - 'DBG_TERM' $ DEFINE/NOLOG/TABLE=LNM$GROUP_000001 DBG$INIT - my-debug-init-file $ START/QUEUE queue-name/PROCESS=MYSYMBIONT 3) The most likely cause of all of the queues being deleted (not really deleted but not visible with a SHOW QUEUE) and the queue manager stopping is a write to SYS$OUTPUT by the print symbiont. What actually happens is that JOBCTL takes a dive (usually you will get a JOBCTL.DMP in SYS$SYSTEM) which takes out the queue manager and all of the queues. Just restarting the queue manager (via START/MANAGER) will get all of the queues back; sometimes it will complain that the queue file (JOBSYSQUE.DAT usually in SYS$SYSTEM) is corrupted. If JBSSYSQUE is corrupted then you will need to do a START/MANAGER/NEW and redefine all of your queues. If you need to output some message during the course of running the symbiont you should use either SYS$SNDOPR or SYS$BRKTHRU to output the message. Never ever use SYS$OUTPUT, SYS$ERROR or SYS$INPUT in a symbiont. A somewhat subtle way that you could be using one of these files would be by a routine signaling an error that is not handled by a condition handler; FORTRAN will do this for floating over/underflow for example. You might want to set up a condition handler in the main that just exits with the error status; you'll get an OPCOM message that the symbiont exited but it will not affect other queues. 4) When debugging a symbiont using the symbolic debugger, you may encounter the case where the debugger is entered without any message being reported. This will be the case if the symbiont takes an access violation. Just look at the current instruction and do a SHOW CALLS to find out where you are. I hope that this is of some help. If you're still having trouble, feel to contact me directly. Jim Gray Gray.OSBUSouth@Xerox.COM
scott@stl.stc.co.uk (Mike Scott) (05/31/88)
Concerning writing print symbionts, Gray.OSBUSouth@Xerox.COM wrote: > If you need to output some message during the course of running > the symbiont you should use either SYS$SNDOPR or SYS$BRKTHRU > to output the message. Never ever use SYS$OUTPUT, SYS$ERROR > or SYS$INPUT in a symbiont. A somewhat subtle way that you could > be using one of these files would be by a routine signaling an error > that is not handled by a condition handler; FORTRAN will do this > I have just been writing a symbiont in C, and encountered this problem. C programs are all assumed to have a stdout, and this gets closed even if you don't use it - which actually crashes the job controller with an EOF written to its mailbox. Cure was to set an exit ast, close all needed files explictly and call sys$delprc before the C runtime system could do anything. Nasty, but it works. The problem is anything but obvious! Why do DEC assumed that anyone writing in C wants a u*x - like environment? It causes quite a few problems like this one. -- Regards. Mike Scott (scott@stl.stc.co.uk <or> ...uunet!mcvax!ukc!stl!scott) phone +44-279-29531 xtn 3133.
jdc@naucse.UUCP (John Campbell) (06/01/88)
In article <757@acer.stl.stc.co.uk>, scott@stl.stc.co.uk (Mike Scott) writes:
:
: I have just been writing a symbiont in C, and encountered this
: problem. C programs are all assumed to have a stdout, and this gets
: closed even if you don't use it - which actually crashes the job
: controller with an EOF written to its mailbox. Cure was to set an exit
: ast, close all needed files explictly and call sys$delprc before the C
: runtime system could do anything. Nasty, but it works. The problem is
: anything but obvious!
:
: Why do DEC assumed that anyone writing in C wants a u*x - like
: environment? It causes quite a few problems like this one.
I seem to remember that the run-time initiation is supressed if you
don't have a ``main'' entry point. At a company I worked for we tried
hard (and I think succeeded) in using 'C' strictly as a language without
including any of the run-time library. I don't have time to resurrect
some of my early experiments, but maybe someone else can verify that
VMS 'C' can be used as a "real" language--without bringing into play any
of the run-time stuff.
--
John Campbell ...!arizona!naucse!jdc
unix? Sure send me a dozen, all different colors.gregg@a.cs.okstate.edu (Gregg Wonderly) (06/02/88)
From article <757@acer.stl.stc.co.uk>, by scott@stl.stc.co.uk (Mike Scott): > > Concerning writing print symbionts, Gray.OSBUSouth@Xerox.COM wrote: > >> ... > > ... > > Why do DEC assumed that anyone writing in C wants a u*x - like > environment? It causes quite a few problems like this one. > > Regards. Mike Scott (scott@stl.stc.co.uk <or> ...uunet!mcvax!ukc!stl!scott) > phone +44-279-29531 xtn 3133. I think the more important question is why did DEC choose to make the interface to the symbiont (message passing between the JBC and the symbiont) through public I/O channels. This is VERY POOR design in my opinion. They already stole enough functionality by using $HIBER to put the PRTSMB symbiont to sleep while waiting for work. Making the entire PRTSMB symbiont processing into an AST driven machine, is hardly icing on the cake. Grrrrr...... ----- Gregg Wonderly Department of Mathematics Oklahoma State University UUCP: {cbosgd, ihnp4, rutgers}!okstate!nemo.math.okstate.edu!gregg Internet: gregg@NEMO.MATH.OKSTATE.EDU