[Info-vax] problem with COBOL installation
mcleanjoh at gmail.com
mcleanjoh at gmail.com
Sun May 17 18:36:00 EDT 2015
On Sunday, May 17, 2015 at 1:33:20 AM UTC+10, Phillip Helbig (undress to reply) wrote:
> In article <84792e9b-f128-4166-9ea6-6ba21dac7e3c at googlegroups.com>, John
> Reagan <xyzzy1959 at gmail.com> writes:
>
> > You can use /OPTIONS=NOVALIDATE if you just want to skip the
> > validation.
>
> I'll give it a try.
>
> > For the error itself, wasn't that part of some prior update
> > to PCSI itself? (Yeah, I know, how does a hobbyist get access to
> > patches? Above my paygrade.)
>
> I have:
>
> DEC AXPVMS VMS84A_UPDATE V5.0 Patch Install Val 22-MAR-2015
> DEC AXPVMS VMS84A_PCSI V2.0 Patch Install Val 22-MAR-2015
>
> My hope is that the PCSI patch provided with the hobbyist stuff would
> allow one to install the hobbyist stuff.
>
> New problem with VMSINSTAL with DECSET:
>
> 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
> ----- above condition handler called with exception 03F2EE1C:
> %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
> ----- end of exception message
> 0 FFFFFFFF800AF15C FFFFFFFF800AF15C
> LSESHR BLI$CALLG BLI$CALLG 9251 00000000000000BC 0000000000344D8C
> LSESHR INTERP TPU$$INTERP_SIGNAL_HANDLER
> 2665 0000000000002264 000000000022A674
> LSESHR 0 00000000003033A4 00000000003453A4
> ----- above condition handler called with exception 0000000C:
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
> 0002, PC=00000000001E8140, PS=0000001B
> ----- end of exception message
> 0 FFFFFFFF800AF15C FFFFFFFF800AF15C
> LSESHR GETINFO TPU$BI_GET_INFO 485 0000000000000140 00000000001E8140
> LSESHR INTERPLOOP TPU$$INTERP_LOOP 1711 0000000000001EB8 00000000002325C4
> LSESHR INTERPLOOP TPU$$INTERP_LOOP 1699 0000000000000998 00000000002310A4
> LSESHR INTERP TPU$$INTERPRETER 1648 000000000000006C 000000000022847C
> LSESHR VMS_STRTEXIT TPU$$EXECUTE_INIFILE
> 862 0000000000001154 00000000001B9FA4
> LSESHR BLI$CALLG BLI$CALLG 9251 00000000000000BC 0000000000344D8C
> LSESHR LSE$SHARE LSE$EXECUTE_INIFILE
> 1611 00000000000006A0 00000000000BEB78
> LSEDIT LSE$LSEDIT MAIN 646 00000000000002C8 00000000000303D0
> 0 FFFFFFFF8037FC44 FFFFFFFF8037FC44
> %TRACE-I-END, end of TRACE stack dump
>
> *****************************************************
> The question phase for component LSE has failed.
> LSE will not be installed.
> *****************************************************
>
> Any ideas?
You report:
%TPU-F-ACCVIO, access violation, reason mask=00, virtual address=00000002, PC=00 1E8140, PSL=0000001B
Virtual address = 2?
That's either a coding error, in which case surely there's enough other customers to have raised complaints, or it's crud that's left over from failing to set something (e.g. on a stack).
You move cluster files around? That's not unusual if you run with separate system disks on cluster members so that you can upgrade without cluster downtime but at the same time you need various files and resources shared across the cluster.
You say that you moved things "back", which I take to mean back to their "standard" locations. Did you reboot that machine in order to have the newly moved files accessed from this "standard" location? Perhaps the installation is using logical names to reach some directories and then relative or absolute paths to access others.
More information about the Info-vax
mailing list