[Info-vax] problem with LSE installation

[Paul Sture]

On 2015-05-16, Phillip Helbig (undress to reply) <helbig at asclothestro.multivax.de>
wrote:

> from the official hobbyist ZIP archive.  This is with 8.4 on ALPHA with 
> the UPDATE5 patch installed.
>
>> Fatal LSEDIT internal error, please submit an SPR including:
>> 
>>      1.  A description of the actions that revealed the bug
>>      2.  The versions of LSE and the operating system you are running
>>      3.  Machine-readable media containing:
>>         a. The source files of your LSE section, command,
>>            initialization, and environment files
>>         b. Copies of the data files used during the session
>>         c. The journal file if one exists
>>         d. The LSE_ERROR.LOG and SCA_ERROR.LOG files if they exist
>>      4.  Your terminal characteristics, if applicable
>>      5.  A description of the command line used to invoke LSE
>> 
>> %TPU-F-ACCVIO, access violation, reason mask=00, virtual address=00000002, PC=00
>> 1E8140, PSL=0000001B
>> -TPU-I-FROMBUILTIN, called from built-in GET_INFO
>> -TPU-I-FROMPROCLINE, called from line 19 of procedure EVE$$INIT_VARIABLES
>> -TPU-I-FROMPROCLINE, called from line 45 of procedure TPU$INIT_PROCEDURE
>> -TPU-I-FROMBUILTIN, called from built-in GET_INFO
>> -TPU-I-FROMPROCLINE, called from line 19 of procedure EVE$$INIT_VARIABLES
>> -TPU-I-FROMPROCLINE, called from line 45 of procedure TPU$INIT_PROCEDURE
>> %TRACE-F-TRACEBACK, symbolic stack dump follows
>>   image    module    routine             line      rel PC           abs PC
>>  LSESHR  BLI$CALLG  BLI$CALLG            9251 00000000000000BC 0000000000344D8C
>>  LSESHR  INTERP  TPU$$INTERP_SIGNAL_HANDLER
>>                                          2665 0000000000002264 000000000022A674
>>  LSESHR                                     0 00000000003033A4 00000000003453A4
>> 
>> Any ideas?

Do you have any EVE or TPU logicals set or EVE/TPU initialisation
files lying around which could be interfering here?

Logging onto SYSTEM with /NOCOMMAND might help.

It's always worth checking that you have plenty of GBLPAGES and GBLSECTIONS
free, since a shortage of either can cause the INSTALL of a shared image
to barf.  GBLPAGES is now a dynamic SYSGEN parameter so you no longer
need a reboot to adjust it.

-- 
Nobody has demonstrated a HTTP/2.0 implementation that approached
contemporary wire speeds.                    -- Poul-Henning Kamp
                     <http://queue.acm.org/detail.cfm?id=2716278>