| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 470.1 | hmmmm | WRONGO::PARMENTER | Venusian or Venerean? | Fri Jun 05 1987 15:29 | 8 |
| Hmmmm. I couldn't reproduce that error on BL7, BL8, or V1.0.
Moreover, we've never had a problem of that sort at all. Was there
anything unusual about what you were doing? I gather since you
were able to SET HOST/LOG that <emphasis>(you) can reproduce it.
Has this happened under any other circumstances?
David Parmenter
|
| 470.2 | Mostly reproducible | COOKIE::WITHERS | Le plus ca change... | Fri Jun 05 1987 16:36 | 12 |
| I am able to reproduce this most of the time (there seems to be
a window where this occurs). The window occurs right after it says
T1.1 and can happen in the text formatting on either the LN01 or
LN03. I havn't tried it at other points in my com file. I actually
suspect that this is really a VMS problem - especially since my
COM file does control-y trapping. I can't be sure though because
the system is not logging errors at the time I do this.
As they say, additional info: VMS V4.5, VAX 8800 (I think - I could
have been on our 8700 or our 8650).
BobW
|
| 470.3 | Not likely DOCUMENT's problem | BUNSUP::LITTLE | Todd Little NJCD SWS 323-4475 | Fri Jun 05 1987 16:44 | 7 |
| Unless DOCUMENT runs in SUPERVISOR mode, its highly unlikely this
is DOCUMENT's problem. The PSL on the stack listed there indicates
both CURRENT and PREVIOUS mode as being SUPERVISOR mode, i.e. DCL.
Maybe there is something funny in the way you've set up your CONTROL-Y
handler in your command procedure.
-tl
|
| 470.4 | reproducible | COOKIE::WITHERS | Le plus ca change... | Fri Jun 05 1987 17:30 | 12 |
| Well, I've reproduced the problem on an 8700 and a 785. Havn't
gotten the job to crash on an 8650 or an 8800. I'll keep tring.
A couple'a things you may want to know: This is a rather long file
(8 pages to the LN03) and I'm using a com file that you can find
in COOKIE""::DISK$CSSE_DISK:[WITHERS.PUBLIC]DODOC.COM.
Any help would be apreciated - or tell me that it is VMS's problem
and I'll go ask in VMSNOTES.
Thanks!
BobW
|
| 470.5 | Yes, it is probably VMS's problem | BUNSUP::LITTLE | Todd Little NJCD SWS 323-4475 | Fri Jun 05 1987 22:35 | 8 |
| I essentially said it was VMS's problem?. I can't imagine that
DOCUMENT runs in SUPERVISOR mode. As such, it should not be possible
for ANY non-priv USER mode code to cause an error in an inner mode
(like SUPERVISOR mode), i.e. meaning the problem is in SUPERVISOR mode
or inner mode, all of which are in the domain of VMS, unless you are
running some priv code or inner mode code.
-tl
|
| 470.6 | | VAXUUM::ADLER | | Fri Jun 12 1987 17:25 | 3 |
| Can you reproduce the problem outside of your command procedure?
--Brian
|
| 470.7 | its reproducible. | WRONGO::PARMENTER | Venusian or Venerean? | Fri Jun 12 1987 18:12 | 10 |
|
Well I dug a little deeper, and I can in fact reproduce the problem
in BL9 of Document. As a matter of fact, my process gets logged
out(!!!) at the same time.
This is in all likelihood a bug in Document and not VMS. I'll post a
note here when the problem is fixed. Thanks for your patience,
David Parmenter
|
| 470.8 | Fixed for V1.0 | WRONGO::PARMENTER | Venusian or Venerean? | Mon Jun 15 1987 18:10 | 6 |
| This may turn out to be a VMS bug, but we don't have time to find
out right now. It is fixed for V1.0 .
David Parmenter
|
| 470.9 | How can this not be a VMS bug? | BUNSUP::LITTLE | Todd Little NJCD SWS 323-4475 | Wed Jun 17 1987 00:20 | 11 |
| Its been a long time since I did any serious VMS support, but I'm
pretty certain I can look at a stack and see a PSL that says current
mode SUPERVISOR and previous mode SUPERVISOR. VMS protection scheme
is such that a user running a non-privileged USER mode image is
NOT supposed to be able to cause exceptions in inner modes. I can't
see any possible way it is a DOCUMENT bug other than to say that
DOCUMENT exacerbates the underlying problem. I'm sure VMS development
would love to know how a non-privileged USER mode image can force
a SUPERVISOR mode exception.
-tl
|