Conference vaxuum::document_ft

    We encountered ACCVIO's under BL8, but only when user accounts had
    insufficient PGFLQUOTA. You may want to double check that quota
    in AUTHORIZE.
    
    --Andrew

    The recommended PGFLQUO is 15000, mine was 50000 ! Shouldn't it be
    enough ? 
    
    Marc.

    Yes, that should more than suffice! However, looking at your
    original note again I notice that you did use up the entire 50000
    pages. (See the logout report.) 

    Yes, I noticed that the log file shows that you did hit the
    50000 block limit on the PGFLQUOTA -- so that explains why it
    died, even if it did not die in a vary useful way.
    
    The problem is WHY did it need 50000 blocks  of page file
    when the normal DOCUMENT run seems to need around 10000 blocks.
    
    The question to ask is what was the usage fo the page file when
    you started?
    
    Assuming that there was about 10000 blocks of free space in the
    page file when you started, why did the tag translator use more
    than normal?   My guess is that there is a missing closing
    parenthesis which DOCUMENT failed to detect.  Instead of writing
    information out to the TEX file, it started storing it all in
    memory while it looked for that closing paren.  So more and more
    virtual memory was needed and more and more page file space was
    needed.
    
    But it is still hard to imagine how that would overflow the 50000
    page file quota.  The BL7, 8 and 9 versions of the tag translator
    won't look for a closing parenthesis beyond the end of any included
    file.  So, you should have gotten an error message (INCNOTARG)
    complaining that you cannot put an <include> tag in an argument.
    
    Perhaps you could try looking at or running the file that it seemed
    to be reading when it died.
    
    I'm sorry that I can't put my finger directly on the problem.
    
    bill
    

    We hit that problem on one of our machines. We did raise a bunch
    of quotas and did other things, without success. Then we found the
    solution:
    
    Rebooted the system
    
    
    Maybe this will help in your case.
    
    Marty

    RE .4
    
    Thanks for the answer. As a quick fix, I increased my pgflquo up
    to 80,000 (!) and rerun the bookbuild. I'll try to figure out what
    the problem is, and let you know.
    
    I don't think it is related to the file it was reading when it failed:
    I compiled the book again, and it failed at a different place.
    
    Maybe some problems with the way the system is set-up. Any hints?
    
    Thanks, Marc.

    Below is the log file of a new run, with a pgflquo of 80000. As
    you can see it, the batch crashed with a page faults of only 60000.
    
    I had also increased my process wsquota, just in case.
    
    Is there something else to look at. Is there sort of a "system max
    page faults" parameter, for example ?
    
    Thanks, Marc.
    
. . . . . . . 
. . . . . . . 
. . . . . . . 
%TAG-I-ENDPASS_1, End of first pass over the input
%TAG-I-FILEWRTOK, File ISA1PREFACE.TEX written
%TAG-I-FILEWRTOK, File ISA1INTRO.TEX written
%TAG-I-FILEWRTOK, File ISA1INSTAL.TEX written
%TAG-I-FILEWRTOK, File ISA1AVMI.TEX written
%TAG-I-FILEWRTOK, File ISA1CHVP.TEX written
%TAG-I-FILEWRTOK, File ISA1EDDM.TEX written
%TAG-I-FILEWRTOK, File ISA1EMCB.TEX written
%TAG-I-FILEWRTOK, File ISA1INDX.TEX written
%TAG-I-FILEWRTOK, File ISA1MENU.TEX written
%TAG-I-FILEWRTOK, File ISA1MLHD.TEX written
%TAG-I-FILEWRTOK, File ISA1PIAP.TEX written
%TAG-I-FILEWRTOK, File ISA1PRFL.TEX written
%TAG-I-FILEWRTOK, File ISA1RWEL.TEX written
%TAG-I-FILEWRTOK, File ISA1TWIF.TEX written
%TAG-I-FILEWRTOK, File ISA1VNIF.TEX written
%TAG-I-FILEWRTOK, File ISA1VTXI.TEX written
%SYSTEM-F-ACCVIO, access violation, reason mask=05, virtual address=024090C4, PC=00370AB9, PSL=03C00004

  Improperly handled condition, image exit forced.

	Signal arguments	      Stack contents

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=7FF0C400, PC=80018322, PSL=03C00004

  Improperly handled condition, image exit forced.

	Signal arguments	      Stack contents

	Number = 00000005		 8001831B
	Name   = 0000000C		 8001825F
		 00000000		 FFFFFFFC
		 7FF0C400		 00401488
		 80018322		 00147901
		 03C00004		 00401448
					 0048A5A0
					 00000000
					 7FF0BA00
					 00000020

	Register dump

	R0 = 00000000  R1 = 8001819C  R2 = 000000FC  R3 = 7FF0C2EC
	R4 = 00000000  R5 = 00000004  R6 = 7FF0C3EC  R7 = 7FF0C26D
	R8 = 7FF0C400  R9 = 7FF0C254  R10= 7FF0C2EC  R11= 7FF0C2A8
	AP = 7FF0C1CC  FP = 7FF0C18C  SP = 7FF0C208  PC = 80018322
	PSL= 03C00004

$ exit ($status + (0 * f$verify(verify_context))) ! SYS$SCRATCH:DOC$ISA1PRO.TMP - End
  BURESI       job terminated at  1-JUL-1987 10:19:13.55
  Accounting information:
  Buffered I/O count:          652      Peak working set size:  1500
  Direct I/O count:            859      Peak page file size:   61388
  Page faults:               60837      Mounted volumes:           0
  Charged CPU time:     0 00:13:09.10   Elapsed time:     0 00:30:29.93
    

    pgflquo is not page faults exactly, it is the amount of virtual
    address space your process is allowed to use. Yes there is a 
    SYSGEN parameter that overrides the PGFLQUO setting. Enter SYSGEN 
    and look at VIRTUALPAGECNT.
    
    However, 60,000 some pages seems extreme. I would really consider
    trying Marty's suggestion (rebooting) before experimenting with
    sysgen parameters. 
    
--Andrew

    And have you followed up Bill's suggestion that maybe everything
    is being read as an argument whose closing parenthesis has not been
    found?  Try splitting your source file, profile, whatever you've
    got into smaller chunks and see if you get some kind of diagnostic
    message.  That may help.
    
    Mark

    I rebooted the system this morning, and still have the problem. The
    (more or less) funny thing is that each book's elements compiled fine,
    separately. 
    
    I also looked at the open parenthesis, and checked that each of them is
    correctly matched by a closed one, and it seems fine (I may have
    missed one, though).
    
    I'll probably have to try .9's suggestion, ie. I'm going to compile
    several times the book, each time with only one element removed, so
    that I can identify the culprit :-) It's going to take me some time! 
    
    BTW, the only messages I have in the log are the warning messages for
    unknown tags (I use things like <ESC> and <VT100> in my book), and the
    informational messages for the conditions I set. It doesn't sound very
    devious ! 
    
    Any suggestions appreciated.
    
    Thanks for your help, Marc.

    We discovered a problem with condition setting (that will have to
    be in the release notes for V1.0, because the fix is too complicated
    to do at this late date).
    
    If you are turning conditions on and off in your input file, you
    must add some <set_condition>(name\REMOVE) tags AT THE VERY END
    OF YOUR INPUT (say, the end of the profile) so that all the conditions
    are turned off at the end of pass 1 of the tag translator.
    
    Otherwise, you will begin pass 2 over the input with certain of
    your conditions set, and that is probably different from the
    conditions that were set in pass 1.  This would totally foul
    up the numbering of sections, tables, etc, and might even be
    the cause of your problem.
    
    bill
    

    This might help. (Bill, hope you don't mind me posting this.)
    
    Marty
    
    
    
From:	VAXUUM::KOHLBRENNER  "The answer lies in the question." 14-MAY-1987 10:46
To:	AUTHOR::FRIEDMAN
Subj:	Marty, can you try this out on HELIX, etc?

;From:	NYFB::NOGRADY "John Nogrady, RTL Development  13-May-1987 1649" 13-MAY-1987 16:51
;To:	VAXUUM::KOHLBRENNER,ECAD::SYSTEM,ECAD::HALNON,TLE::CALATO_SCA,KEN_H,NOGRADY     
;Subj:	RE: VM problem on ECAD with DOCUMENT and SCA programs
;
;bill -
;
;After looking into the LIB$_BADBLOADR error (returned by LIB$GET_VM), I am
;convinced that it is not a software problem.  Another group reported the
;same problem  -- SCA.  Both DOCUMENT and SCA make legal use of virtual
;memory within their programs.  The SYSGEN parameter VIRTUALPAGECNT is set
;sufficiently high on ECAD, as are the user & process quotas; that is not
;the problem. 
;
;The action to be taken in this situation is to have the System Manager(s)
;on ECAD log a call with Field Service.  It should be reported as a machine
;problem; more percisely, the incorrect operation of the VAX instruction
;INSQHI under certain circumstances. I have included additional information
;about the actual error for the System Manager(s) and Field Service people,
;as well as a small program to demonstrate the error without calling
;Run-Time Library routines. 
;
;The error, LIB$_BADBLOADR, is returned by the routine LIB$GET_VM; but, the
;actual corruption ocurs during a call to LIB$FREE_VM.  A VM zone has a
;circular queue of addresses to available space...a "free list".  This is a
;self-relative queue which means that the value at the current address is
;added to the address to get to the next entry in the queue.  In this case,
;the address 11AD80 is to be free'd; it is inserted onto the queue in the
;correct position; but when updating the forward pointer to point at the
;previous entry on the queue, some corruption ocurs and ends up pointing to
;NEVER-NEVER land. When the back pointer of the previous entry is modified
;to point to the entry just added, some corruption occurs and points it to
;FANTASY land. Thus, you no longer have a valid or "linked" queue.  It looks
;something like: 
;
; 356240		11AD80		    11AD40	      11AD00           356240
;[header] <--> [new entry] -+  +- [prev. entry] <--> [last entry] <--> [header]
;                           |  |
; NEVER-NEVER land <--------+  +-----------------> FANTASY land
;
;		where the address, in hex, is above the brackets
;
;The next time LIB$GET_VM is called (for that zone), it will bomb when
;trying to update the queue pointers. 
;
;If you have further questions, please let me know of them. The test program
;will follow. 
;
;
;- John Nogrady, VAX/VMS Run-Time Library

; 
; The queue and registers are set to reflect their state prior to the failure
; of the insqhi instruction.  It will exercise the insqhi instruction 12
; times at the set location...it will bomb on the first!  This program
; should return SS$_NORMAL status if the insqhi works properly.
; 
; An already typed in and compiled program as well as a dump can be found in
; ECAD::USER:[TEMP] directory -- filename is TEST
;
; If you want to generate a DUMP then the program should be compiled and
; executed as follows:
;	$MAC  TEST
;	$LINK/NOTRACE TEST
;	$RUN/DUMP TEST		--> dump created only if it fails
;	$ANALYZE/PROCESS TEST	--> allows you to analyze the process
;
; I will be glad to offer any additional explanation -- if needed/wanted.
;
INADR1:	.long ^x356200, ^x356200	; virtual address of page to be
INADR2:	.long ^x11aD00, ^x11aD00	; created
RETADR1: .BLKL	2			; 
RETADR2: .BLKL	2			;
MSG_OK:	.long 1				; so that person will now if
	.long SS$_NORMAL		; this program executes normal
;
;
ACCVIO:	TSTL	0			; if error, then force ACCVIO
	.entry -
insqhi_test, 0
	MOVL	#^X356240, R8
	MOVL	#^X11AD80, R7
	$CRETVA_S inadr1, RETADR1
	$CRETVA_S inadr2, RETADR2
	clrq	(R8)
	MOVL	#^X11AD00, R6
	INSQHI	(R6), (R8)			; set up queue
	MOVL	#^X11AD40, R6
	INSQHI	(R6), (R8)
	MOVL	#^X1, R0			; set up registers
	MOVL	#^X35B000, R1
	MOVL	#^X0, R2
	MOVL	#^X11ADC0, R3
	CLRL	R4
	CLRL	R5
	MOVL	#^X2000, R6
	MOVL	#^X6C82, R9
	MOVL	#^X2C040, R10
	MOVL	#^X356A00, R11
TRY:	INSQHI	(R7), (R8)			; *** corruption ocurrs here
	CMPL	#^XFFDC4B40, (R8)		; now check all pointers
	BEQL	5$
	BRW	ACCVIO1
5$:	CMPL	#^XFFDC4AC0, 4(R8)
	BNEQ	ACCVIO1
	CMPL	#^XFFFFFFC0, ^X11AD40
	BNEQ	ACCVIO1
	CMPL	#^X40, ^X11AD44
	BNEQ	ACCVIO1
	CMPL	#^X23B540, ^X11AD00
	BNEQ	ACCVIO1
	CMPL	#^X40, ^X11AD04
	BNEQ	ACCVIO1
	CMPL	#^XFFFFFFC0, ^X11AD80
	BNEQ	ACCVIO1
	CMPL	#^X23B4C0, ^X11AD84
	BNEQ	ACCVIO1
	REMQHI	(R8), ^X35624C				; take off of queue 
	AOBLEQ  #12,^X356248,TRY			; loop thru 12 times
	$PUTMSG_S MSGVEC = MSG_OK			; successful completion
	$EXIT_S	#1					; exit
ACCVIO1:	TSTL 0					; if error, force ACCVIO
	.END INSQHI_TEST

    Bill got it, I fixed it as suggested in .11, ie I "closed" the
    conditions at the end of my profile, and it worked fine. 
    
    Thanks, Bill and Marty, and the others, for your help.
    
    Marc.

    Well it worked - once.
    
    The second time (I tried to produce an LN01 output) it crashed again.
    The conditions are removed at the end of the profile. There has been no
    changes in the book, from when the compilation ran ok. 
    
    I tried exactly the same copmilation as when it worked (ie. LN03)
    and it crashed again. Below is the log. 
        
    Any help ?
    
    
. . . <login.com executed here> . . . 
$ verify_context = 1 ! SYS$SCRATCH:DOC$ISA1PRO.TMP - Start
$ d = "document"
$ set = "set"
$ set noon
$ set default veis2:[is_allin1.doc]
$ D /BATCH=(KEEP,NOPRINT)/CONTENT/SYMBOL=GLOBALDEFS.GNC/NOPRINT ISA1PRO S.R LN03
%DOC-I-IDENT, VAX DOCUMENT T1.0-008
[ T a g   T r a n s l a t i o n ]...
%TAG-I-TAG_IDENT, T1.0-002
%TAG-I-DEFSLOADD, End of Loading of Tag Definitions
%TAG-W-TAGNOTDEF, at text on line 115 in file
   ISA1PREFACE.GNC
   Tag <CUSTOMIZATION_ID> is undefined
%TAG-W-TAGNOTDEF, at text on line 115 in file
   ISA1PREFACE.GNC
   Tag <FILE_DESCRIPTION> is undefined
%TAG-W-TAGNOTDEF, at text on line 115 in file
   ISA1PREFACE.GNC
   Tag <TYPE> is undefined
%TAG-I-SETCONDTN, Setting condition oaform
   on line 2 of file ISA1AVMI.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 3 of file ISA1AVMI.GNC
%TAG-I-SETCONDTN, Setting condition txl
   on line 4 of file ISA1AVMI.GNC
%TAG-I-SETCONDTN, Setting condition oaform
   on line 4 of file ISA1CHVP.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1CHVP.GNC
%TAG-I-RMVCONDTN, Removing condition txl
   on line 6 of file ISA1CHVP.GNC
%TAG-I-SETCONDTN, Setting condition oaform
   on line 4 of file ISA1EDDM.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1EDDM.GNC
%TAG-I-SETCONDTN, Setting condition txl
   on line 6 of file ISA1EDDM.GNC
%TAG-I-SETCONDTN, Setting condition oaform
   on line 4 of file ISA1EMCB.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1EMCB.GNC
%TAG-I-SETCONDTN, Setting condition txl
   on line 6 of file ISA1EMCB.GNC
%TAG-I-SETCONDTN, Setting condition oaform
   on line 4 of file ISA1INDX.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1INDX.GNC
%TAG-I-SETCONDTN, Setting condition txl
   on line 6 of file ISA1INDX.GNC
%TAG-I-SETCONDTN, Setting condition oaform
   on line 5 of file ISA1MENU.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 6 of file ISA1MENU.GNC
%TAG-I-RMVCONDTN, Removing condition txl
   on line 7 of file ISA1MENU.GNC
%TAG-I-RMVCONDTN, Removing condition oaform
   on line 4 of file ISA1MLHD.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1MLHD.GNC
%TAG-I-SETCONDTN, Setting condition txl
   on line 6 of file ISA1MLHD.GNC
%TAG-I-RMVCONDTN, Removing condition oaform
   on line 4 of file ISA1PIAP.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1PIAP.GNC
%TAG-I-SETCONDTN, Setting condition txl
   on line 6 of file ISA1PIAP.GNC
%TAG-W-TAGNOTDEF, at text on line 110 in file
   ISA1PIAP.GNC
   Tag <ESC> is undefined
%TAG-I-RMVCONDTN, Removing condition oaform
   on line 4 of file ISA1PRFL.GNC
%TAG-I-SETCONDTN, Setting condition memres
   on line 5 of file ISA1PRFL.GNC
%TAG-I-RMVCONDTN, Removing condition txl
   on line 6 of file ISA1PRFL.GNC
%TAG-I-SETCONDTN, Setting condition oaform
   on line 4 of file ISA1RWEL.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1RWEL.GNC
%TAG-I-RMVCONDTN, Removing condition txl
   on line 6 of file ISA1RWEL.GNC
%TAG-I-SETCONDTN, Setting condition oaform
   on line 4 of file ISA1SPTS.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1SPTS.GNC
%TAG-I-SETCONDTN, Setting condition txl
   on line 6 of file ISA1SPTS.GNC
%TAG-I-SETCONDTN, Setting condition oaform
   on line 4 of file ISA1TWIF.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1TWIF.GNC
%TAG-I-RMVCONDTN, Removing condition txl
   on line 6 of file ISA1TWIF.GNC
%TAG-W-TAGNOTDEF, at text on line 66 in file
   ISA1TWIF.GNC
   Tag <VT100> is undefined
%TAG-I-SETCONDTN, Setting condition oaform
   on line 4 of file ISA1VNIF.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1VNIF.GNC
%TAG-I-RMVCONDTN, Removing condition txl
   on line 6 of file ISA1VNIF.GNC
%TAG-I-SETCONDTN, Setting condition oaform
   on line 4 of file ISA1VTXI.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1VTXI.GNC
%TAG-I-RMVCONDTN, Removing condition txl
   on line 6 of file ISA1VTXI.GNC
%TAG-I-SETCONDTN, Setting condition oaform
   on line 4 of file ISA1WPAT.GNC
%TAG-I-RMVCONDTN, Removing condition memres
   on line 5 of file ISA1WPAT.GNC
%TAG-I-SETCONDTN, Setting condition txl
   on line 6 of file ISA1WPAT.GNC
%TAG-I-RMVCONDTN, Removing condition OAFORM
   on line 28 of file DISK$EIS2:[IS_ALLIN1.DOC]ISA1PRO.GNC;
%TAG-I-RMVCONDTN, Removing condition MEMRES
   on line 29 of file DISK$EIS2:[IS_ALLIN1.DOC]ISA1PRO.GNC;
%TAG-I-RMVCONDTN, Removing condition TXL
   on line 30 of file DISK$EIS2:[IS_ALLIN1.DOC]ISA1PRO.GNC;
%TAG-I-ENDPASS_1, End of first pass over the input
%TAG-I-FILEWRTOK, File ISA1PREFACE.TEX written
%TAG-I-FILEWRTOK, File ISA1INTRO.TEX written
%TAG-I-FILEWRTOK, File ISA1INSTAL.TEX written
%TAG-I-FILEWRTOK, File ISA1AVMI.TEX written
%TAG-I-FILEWRTOK, File ISA1CHVP.TEX written
%TAG-I-FILEWRTOK, File ISA1EDDM.TEX written
%TAG-I-FILEWRTOK, File ISA1EMCB.TEX written
%TAG-I-FILEWRTOK, File ISA1INDX.TEX written
%TAG-I-FILEWRTOK, File ISA1MENU.TEX written
%TAG-I-FILEWRTOK, File ISA1MLHD.TEX written
%TAG-I-FILEWRTOK, File ISA1PIAP.TEX written
%TAG-I-FILEWRTOK, File ISA1PRFL.TEX written
%TAG-I-FILEWRTOK, File ISA1RWEL.TEX written
%SYSTEM-F-ACCVIO, access violation, reason mask=05, virtual address=024093C4, PC=00370AB9, PSL=03C00004

  Improperly handled condition, image exit forced.

	Signal arguments	      Stack contents

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=7FF0BA00, PC=80018322, PSL=03C00004

  Improperly handled condition, image exit forced.

	Signal arguments	      Stack contents

	Number = 00000005		 8001831B
	Name   = 0000000C		 8001825F
		 00000000		 FFFFFFFC
		 7FF0BA00		 00401488
		 80018322		 00147201
		 03C00004		 00401448
					 00455680
					 00000000
					 7FF0B000
					 00000020

	Register dump

	R0 = 00000000  R1 = 8001819C  R2 = 000000FC  R3 = 7FF0B8EC
	R4 = 00000000  R5 = 00000004  R6 = 7FF0B9EC  R7 = 7FF0B86D
	R8 = 7FF0BA00  R9 = 7FF0B854  R10= 7FF0B8EC  R11= 7FF0B8A8
	AP = 7FF0B7CC  FP = 7FF0B78C  SP = 7FF0B808  PC = 80018322
	PSL= 03C00004

$ exit ($status + (0 * f$verify(verify_context))) ! SYS$SCRATCH:DOC$ISA1PRO.TMP - End
  BURESI       job terminated at  3-JUL-1987 13:01:27.18

  Accounting information:
  Buffered I/O count:          605      Peak working set size:  1500
  Direct I/O count:            814      Peak page file size:   97479
  Page faults:               96653      Mounted volumes:           0
  Charged CPU time:     0 00:14:26.00   Elapsed time:     0 00:23:38.66

    
    Does the ACCVIO always happen in the same file ? If so, could you
    please MAIL it to me? 
    
    Hoping to get to the bottom of this soon,
    
    patti

    Hi patti,
    
    No, the file on which it happens depends on my PFGLQUO, and the
    sytem parameter VIRTUAPAGECNT, as explained in one of the previous
    replies. The higher they are, the later the ACCVIO happens. 
    
    It looks like it depends also, more or less, on the system load.
    
    I tried several times, and it very often crashed on different files. 
    
    I send you a mail to tell you where you can copy all the files from,
    just in case you have some time to have a look. 
    
    Thanks,
    
    Marc.

    It looks to me as though the tag translator is not freeing
    virtual memory as it goes along.  So the image size keeps 
    growing.
    
    The tag translator does LIB$GET_VM and LIB$FREE_VM calls all
    the time -- it probably averages eight such calls for every
    tag in your source file.  The fact that virtual memory usage
    stays pretty constant all during tag translation indicates
    that tag translator always FREEs what it GETs.
    
    However, if the run time library is broken, such that the
    FREE call does not actually make the freed piece of virtual
    memory available for the next GET call, then the next GET has
    to reach beyond to a previously unused virtual memory address.
    
    I beleive you really do have to reboot the system.  Something
    is broken in the run time library.  (Which is not to say that
    the tag translator is not responsible for breaking it.)
    
    Please try a reboot before we spend more time on this.
    
    bill

    I've already rebooted the system (actually did an @AUTOGEN SAVPARAMS
    REBOOT) to increase the VIRTUALPAGECNT parameter. I should probably
    decrease it back to its original value, before re-executing AUTOGEN. 
    
    The first time after the reboot, the compilation went fine (so I posted
    a reply saying it was ok). The second time I tried, on the same book,
    it crashed again. This may mean that DOCUMENT corrupts the system the
    first time it compiles the book. There may also be a problem with
    *this* book, but there are no errors in the log. 
    
    I should probably try again to reboot the system, but the problem is
    that it is used by several persons, and I have to reboot it out of
    working hours, when everybody is out.     
    
    I've also compiled the book several times on another computer running
    BL7, and it worked fine each time. It would be smart if you could copy
    my book (I sent a mail to Patti), and just compile it on your BL8
    machine (don't forget to do it twice!) and see if it crashes.
    
    The system manager says he has no pbs with the run-time library.
    I've asked him to check, anyway.
    
    I'll be out next three weeks, but am asking another guy to check
    this ntoesfile and answer your questions.
    
    Thanks, Marc.

    DOCUMENT's tag translator uses virtual memory "zones."  That is,
    it creates a lot of virtual memory zones using LIB$CREATE_VM_ZONE,
    and then it uses LIB$GET_VM and LIB$FREE_VM calls within those zones.  
    
    On two other cpus (with the help of a developer who works on the 
    run-time library) we have discovered that the INSQHI instruction
    was failing.  It took field service to fix the machine before
    DOCUMENT would work (that is what one of the earlier replies to
    this topic was about -- the reply from Marty Friedman).  On one
    of those machines the only other software that was failing was the
    SCA part of LSE.  That leads me to believe that DOCUMENT, and perhaps
    SCA, call on the run-time library in unique ways, and that the INSQHI
    instruction can be failing (at least in certain circumstances)
    without the rest of the software knowing about it.
    
    I'll try to find out more about what field service did to fix those
    two machines, and if they have a way to diagnose the problem other
    than running DOCUMENT or SCA!
    
    -bill
    

    Well, the DOC V1.0 message was clearer and (cleaner), at least !
    I've posted part of the log below.
    
    Re .-1
    
    Thanks for your answer. Did you get anything from the field service?
    
    Regards,
    
    Marc.
    
    
    
%TAG-E-TAG_FAILS, The tag translator has detected a fatal error
-TAG-F-VMOVRFLOW, at tag <WHEN> on line 104 in file
   ISA12020.SDML
   Internal error. Failure to allocate additional space in virtual memory
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000C, PC=00000002, PSL=003F2A32
$ exit ($status + (0 * f$verify(verify_context))) ! SYS$SCRATCH:DOC$ISA1PRO.TMP - End

    I had a long talk with our head of in-house field service.
    
    There is a small "book" that documents the FCOs (field change
    orders) that occasionally get issued for each of the cpu types.
    (ECOs, Engineering Change Orders are what go to manufacturing,
    and get reflected in the cpus that are being built.  FCOs are
    the equivalent changes that go out to the customers or to the
    field service offices to "fix" or "improve" cpus that are already
    in service.  Not every ECO has an FCO, because some of the ECO
    changes are not considered to be serious enough to be FCOed.)
    
    So each CPU type has a revision level that represents which FCOs
    have been issued for it.  Note that the responsibility for installing
    the FCO on a given machine is sometimes the customer's responsibility
    and sometimes it is Field Service's responsibility.  Most external
    customers are eager to install the FCOs, but the internal sites
    may or may not get the FCOs installed depending on who is responsible
    and whether they think it is necessary.
    
    Furthermore, the cpus get "revised" in different ways.  For some, it means
    a new floppy for the console floppy device, others get their
    changes on tape, and still others actually require a board change
    and some FCOs have required wire changes.  
    
    The problems that DOCUMENT has had are with 11/745's.  The 11/745 comes
    in "old" and "new" versions.  The field service upgrade from old
    to new involves changing a number of boards and doing about 40
    wire changes and then using a new console floppy.  I think that
    takes you from rev level A or B to rev level C.  If you already have
    a new machine, then you probably should be at rev level D.
    
    One of the 11/745s that never successfully ran DOCUMENT had a
    power failure one weekend.  When operations came in they powered
    the machine back up and it now successfully runs DOCUMENT...
    I have still not been able to track down what changed as a result
    of the power up after the weekend.  (Note that it was not the
    VMS software, because the same machine was succesfully upgraded
    from VMS 4.5 to VMS 4.6 a few weeks before the power failure, and
    DOCUMENT failed  in an identical way on both VMS 4.5 and VMS 4.6.)
    But once it was powered back up after the power failure, it could
    run DOCUMENT successfully.
    
    A little spooky, huh?                                       
    
    bill