Hello,
I'm able to obtain a running VMS session with my VAX (simh). All but
keyboard run fine. I only have an error in 'host'_1.log file:
Executing run sys$system:decw$wsinit
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=1211100F, PC
=80000010, PSL=03C00004
I don't know which image returns this access violation.
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=1211100F, PC =80000010, PSL=03C00004
On 2025-06-10, JKB <JKB@hilbert.invalid> wrote:
Hello,
I'm able to obtain a running VMS session with my VAX (simh). All but
keyboard run fine. I only have an error in 'host'_1.log file:
Executing run sys$system:decw$wsinit
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=1211100F, PC
=80000010, PSL=03C00004
I don't know which image returns this access violation.
Would turning on image accounting for a short time give you this information if you look at the image exit status in the accounting logs ?
on image accounting and repeated the above procedure. Look at the exit
status of the images until you find the ACCVIO one. That should tell you which image is exiting with an ACCVIO status.
Don't forget to turn off image accounting when you are finished to avoid filling up your disk with accounting logs. :-)
Le 10-06-2025, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> a crit:
On 2025-06-10, JKB <JKB@hilbert.invalid> wrote:
Hello,
I'm able to obtain a running VMS session with my VAX (simh). All but >>> keyboard run fine. I only have an error in 'host'_1.log file:
Executing run sys$system:decw$wsinit
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=1211100F, PC
=80000010, PSL=03C00004
I don't know which image returns this access violation.
Would turning on image accounting for a short time give you this information >> if you look at the image exit status in the accounting logs ?
I only have in log:
Executing run sys$system:decw$wsinit
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=1211100F, PC
=80000010, PSL=03C00004
Improperly handled condition, image exit forced.
Signal arguments Stack contents
Number = 00000005 9E41CE63
Name = 0000000C 00000002
00000001 7FE95EF0
1211100F 7FE95ED8
80000010 00000004
03C00004 7FE95F10
00000000
00000000
9FD17880
03000001
Register dump
R0 = 03C00000 R1 = 1211100F R2 = 00000020 R3 = 00000000
R4 = 002EA6C0 R5 = 00000000 R6 = 000034E0 R7 = 00000210
R8 = 00000210 R9 = 00000001 R10= 7FFED7D4 R11= 7FFE2BDC
AP = 7FE95E8C FP = 7FE95E4C SP = 7FE95EC8 PC = 80000010
PSL= 03C00004
Executing run sys$system:decw$session
On 6/13/2025 13:56, Simon Clubley wrote:
No, it's the accounting logs you need to look at, after you have turned
on image accounting and repeated the above procedure. Look at the exit
status of the images until you find the ACCVIO one. That should tell you
which image is exiting with an ACCVIO status.
Don't forget to turn off image accounting when you are finished to avoid
filling up your disk with accounting logs. :-)
To be clear, there is no clear-text accounting log file on the system.
The output you need is generated by the ACCOUNTING utility, which will
read the binary file SYS$MANAGER:ACCOUNTNG.DAT
$ HELP ACCOUNTING
An example using the /FULL qualifier is here
On 6/13/2025 2:08 PM, Robert A. Brooks wrote:
On 6/13/2025 13:56, Simon Clubley wrote:
No, it's the accounting logs you need to look at, after you have turned
on image accounting and repeated the above procedure. Look at the exit
status of the images until you find the ACCVIO one. That should tell you >>> which image is exiting with an ACCVIO status.
Don't forget to turn off image accounting when you are finished to avoid >>> filling up your disk with accounting logs. :-)
To be clear, there is no clear-text accounting log file on the system.
The output you need is generated by the ACCOUNTING utility, which will
read the binary file SYS$MANAGER:ACCOUNTNG.DAT
$ HELP ACCOUNTING
An example using the /FULL qualifier is here
/SINCE and /BEFORE can be used to select time interval.
/TYPE=IMAGE can select only image records.
If it is an older busy system, then no selection will result in
a huge output.
if(acctrec.type.type == AcctRecType.ACR$K_IMGDEL) {
tim = acctrec.systime
for(pack in acctrec.packs) {
if(pack.type.type == AcctPackType.ACR$K_RESOURCE) {
stat = pack.status
}
if(pack.type.type == AcctPackType.ACR$K_IMAGENAME) {
img = pack.imagename
}
}
println("$tim : $img status=$stat")
On Fri, 13 Jun 2025 22:31:37 -0400, Arne Vajhøj wrote:
if(acctrec.type.type == AcctRecType.ACR$K_IMGDEL) {
tim = acctrec.systime
for(pack in acctrec.packs) {
if(pack.type.type == AcctPackType.ACR$K_RESOURCE) {
stat = pack.status
}
if(pack.type.type == AcctPackType.ACR$K_IMAGENAME) {
img = pack.imagename
}
}
println("$tim : $img status=$stat")
Shouldn’t “stat” and “img” be initialized to something like “null” or
“undef” (or whatever the Groovy equivalent is)? Unless you’re assuming they’ll always be defined for that record type.
No, it's the accounting logs you need to look at, after you have turned
on image accounting and repeated the above procedure. Look at the exit
status of the images until you find the ACCVIO one. That should tell you which image is exiting with an ACCVIO status.
Le 13-06-2025, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> a écrit :
No, it's the accounting logs you need to look at, after you have turned
on image accounting and repeated the above procedure. Look at the exit
status of the images until you find the ACCVIO one. That should tell you
which image is exiting with an ACCVIO status.
I have tried
$ accounting /image=sys$manager:decw$wsinit
before logout/login again.
$ accounting /since=14-JUN-2025 returns:
14-JUN-2025 14:46:53 PROCESS INTERACTIVE BERTRAND 0000011B MBA40: 00000001
14-JUN-2025 14:46:54 PROCESS NETWORK BERTRAND 0000011A 00000001
14-JUN-2025 14:46:56 PROCESS SUBPROCESS TCPIP$XDM 00000119 00000001
14-JUN-2025 14:47:03 PROCESS SUBPROCESS TCPIP$XDM 0000011D 00000003
14-JUN-2025 14:51:57 PROCESS DETACHED SYSTEM 0000011C 02DB8204
14-JUN-2025 14:54:30 PROCESS INTERACTIVE BERTRAND 00000124 FTA5: 0001C0F4
14-JUN-2025 14:54:47 PROCESS INTERACTIVE BERTRAND 00000122 MBA57: 00000001
14-JUN-2025 14:54:48 PROCESS INTERACTIVE BERTRAND 00000121 MBA55: 00000001
14-JUN-2025 14:54:48 PROCESS INTERACTIVE BERTRAND 00000120 MBA53: 00000001
14-JUN-2025 14:54:49 PROCESS INTERACTIVE BERTRAND 00000125 FTA6: 0001C0F4
14-JUN-2025 14:54:50 PROCESS INTERACTIVE BERTRAND 00000123 MBA59: 10778088
14-JUN-2025 14:54:50 PROCESS NETWORK BERTRAND 0000011F 00000001
14-JUN-2025 14:54:52 PROCESS SUBPROCESS TCPIP$XDM 0000011E 00000001
14-JUN-2025 14:59:52 PROCESS DETACHED SYSTEM 00000126 02DB8204
$ accounting /full doesn't return any access violation error. Only a
file read error:
INTERACTIVE Process Termination
-------------------------------
Username: BERTRAND UIC: [BERTRAND]
Account: Finish time: 14-JUN-2025 14:54:30.30
Process ID: 00000124 Start time: 14-JUN-2025 14:48:26.55
Owner ID: Elapsed time: 0 00:06:03.74
Terminal name: FTA5: Processor time: 0 00:01:17.79
Remote node addr: Priority: 4
Remote node name: Privilege <31-00>: FFFFFFFF
Remote ID: Privilege <63-32>: FFFFFFFF
Remote full name:
Queue entry: Final status code: 0001C0F4
Queue name:
Job name:
Final status text: %RMS-F-RER, file read error
Page faults: 1915 Direct IO: 717
Page fault reads: 188 Buffered IO: 535
Peak working set: 789 Volumes mounted: 0
Peak page file: 4438 Images executed: 11
and a few others with strange final status codes:
INTERACTIVE Process Termination
-------------------------------
Username: BERTRAND UIC: [BERTRAND]
Account: Finish time: 14-JUN-2025 14:54:50.46
Process ID: 00000123 Start time: 14-JUN-2025 14:48:16.48
Owner ID: Elapsed time: 0 00:06:33.97
Terminal name: MBA59: Processor time: 0 00:00:21.71
Remote node addr: Priority: 4
Remote node name: Privilege <31-00>: 00108000
Remote ID: Privilege <63-32>: 00000000
Remote full name:
Queue entry: Final status code: 10778088
Queue name:
Job name:
Final status text: <no text>
Page faults: 6491 Direct IO: 64
Page fault reads: 114 Buffered IO: 3208
Peak working set: 5558 Volumes mounted: 0
Peak page file: 14179 Images executed: 3
DETACHED Process Termination
----------------------------
Username: SYSTEM UIC: [SYSTEM]
Account: <start> Finish time: 14-JUN-2025 14:59:52.83
Process ID: 00000126 Start time: 14-JUN-2025 14:54:47.21
Owner ID: Elapsed time: 0 00:05:05.62
Terminal name: Processor time: 0 00:00:01.25
Remote node addr: Priority: 4
Remote node name: Privilege <31-00>: 0010C000
Remote ID: Privilege <63-32>: 00000000
Remote full name:
Queue entry: Final status code: 02DB8204
Queue name:
Job name:
Final status text: <no text>
Page faults: 735 Direct IO: 2
Page fault reads: 64 Buffered IO: 46
Peak working set: 1065 Volumes mounted: 0
Peak page file: 9351 Images executed: 1
Any idea for alt-gr key ?
Best regard,
JB
I have tried
$ accounting /image=sys$manager:decw$wsinit
before logout/login again.
And yes, sys$system:decw$wsinit (at least on Eisner) is linked with /notraceback so you only get a register dump and no information on the
call frames.
On 6/13/2025 10:49 PM, Lawrence D'Oliveiro wrote:
On Fri, 13 Jun 2025 22:31:37 -0400, Arne Vajhøj wrote:
if(acctrec.type.type == AcctRecType.ACR$K_IMGDEL) {
tim = acctrec.systime
for(pack in acctrec.packs) {
if(pack.type.type == AcctPackType.ACR$K_RESOURCE) {
stat = pack.status
}
if(pack.type.type == AcctPackType.ACR$K_IMAGENAME) {
img = pack.imagename
}
}
println("$tim : $img status=$stat")
Shouldn’t “stat” and “img” be initialized to something like “null” or
“undef” (or whatever the Groovy equivalent is)? Unless you’re assuming >> they’ll always be defined for that record type.
They should (Groovy uses null).
An image activation record should always have a resource
and imagename pack. But good defensive programming style
say to initialize anyway.
Sorry, pressed snd too soon ...
On 6/14/25 15:18, JKB wrote:
I have tried
$ accounting /image=sys$manager:decw$wsinit
before logout/login again.
You need
$ SET ACCOUNTING /ENABLE=IMAGE
But you can also (I don't have access to a VAX, n Eisner, an Alpha system):
$ sea sys$startup:decw*.com decw$wsinit
%SEARCH-W-OPENIN, error opening ...
-RMS-E-PRV, insufficient privilege or file protection violation
******************************
SYS$COMMON:[SYSMGR]DECW$STARTAPPS.COM;1
"sys$system:decw$wsinit.exe" "/OPEN/HEAD/SHARE"
$ decw$sessioninit == "run sys$system:decw$wsinit"
$
$ sea sys$startup:decw*.com decw$sessioninit
%SEARCH-W-OPENIN, error opening ...
-RMS-E-PRV, insufficient privilege or file protection violation
******************************
SYS$COMMON:[SYSMGR]DECW$STARTAPPS.COM;1
$ decw$sessioninit == "run sys$system:decw$wsinit"
$ define/system/exec/nolog DECW$SESSIONINIT "''decw$sessioninit'"
******************************
SYS$COMMON:[SYSMGR]DECW$STARTSM.COM;1
$sessioninit = F$TRNLNM("DECW$SESSIONINIT")
$
$ sea sys$startup:decw*.com sessioninit
%SEARCH-W-OPENIN, error opening ...
-RMS-E-PRV, insufficient privilege or file protection violation
******************************
SYS$COMMON:[SYSMGR]DECW$STARTAPPS.COM;1
$ decw$sessioninit == "run sys$system:decw$wsinit"
$ define/system/exec/nolog DECW$SESSIONINIT "''decw$sessioninit'"
******************************
SYS$COMMON:[SYSMGR]DECW$STARTSM.COM;1
$if name .EQS. "LOGIN" then goto do_sessioninit
$if name .EQS. "SESSIONINIT" then goto do_decw_sylogin
$if comnegated .EQS. "TRUE" then GOTO do_sessioninit
$if lgicmd .EQS. "" then GOTO do_sessioninit
$ if F$SEARCH(lgicmd) .eqs. "" then goto do_sessioninit
$do_sessioninit:
$define/nolog decw$doing_session SESSIONINIT
$sessioninit = F$TRNLNM("DECW$SESSIONINIT")
$if sessioninit .EQS. "" then goto do_decw_sylogin
$write sys$output "Executing ''sessioninit'"
$'sessioninit
$
Here's your "Executing run sys$system:decw$wsinit". Assuming the command procedures on VAX are similar: edit DECW$STARTSM.COM and add a "$ set process/dump" before the "write".
Le 14-06-2025, hb0815 <mw40171@mucweb.de> a écrit :
Here's your "Executing run sys$system:decw$wsinit". Assuming the command
procedures on VAX are similar: edit DECW$STARTSM.COM and add a "$ set
process/dump" before the "write".
Done:
No dump file is created.
On 6/16/25 2:34 AM, JKB wrote:
Le 14-06-2025, hb0815 <mw40171@mucweb.de> a écrit :
Here's your "Executing run sys$system:decw$wsinit". Assuming the command >>> procedures on VAX are similar: edit DECW$STARTSM.COM and add a "$ set
process/dump" before the "write".
Done:
No dump file is created.
I'm pretty sure process dumps are for post-VAX platforms only. Maybe someone else remembers what version first had them.
Now, I'm trying to connect to xdm.
$ show def
DUA0:[000000]
$ dir [...]*.dmp/time
Directory DUA0:[SYS0.SYSEXE]
ERRORLOG.DMP;1 23-OCT-2018 23:48:48.86
SYSDUMP.DMP;1 23-OCT-2018 23:00:32.62
Total of 2 files.
No dump file is created.
On 6/16/25 07:34, JKB wrote:
...
Now, I'm trying to connect to xdm.
$ show def
DUA0:[000000]
$ dir [...]*.dmp/time
Directory DUA0:[SYS0.SYSEXE]
ERRORLOG.DMP;1 23-OCT-2018 23:48:48.86
SYSDUMP.DMP;1 23-OCT-2018 23:00:32.62
Total of 2 files.
No dump file is created.
In the log file, is there any message about not being able to create a process dump?
Am 17.06.2025 um 09:23 schrieb JKB:
...
Executing run sys$system:decw$wsinit
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=1211100F, PC
=80000010, PSL=03C00004
...
Can you run DECW$WSINIT standalone interactively ? Would it fail in the
same way ?
clock displayed to Xephyr$ run sys$system:decw$wsinit
...
Executing run sys$system:decw$wsinit
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=1211100F, PC
=80000010, PSL=03C00004
...
Am 17.06.2025 um 13:52 schrieb JKB:
$ analyze /process_dump DECW$WSINIT.DMP
...
%DEBUG-I-NOSOURCE, No source for address: 800000101
Now try:
EXA/INS 80000010
This is a system space address and will show (you can also use SDA to
examine the insturction at this address):
exa/ins 80000010EXE$QIOW_3: CALLG 04(SP),(R1)
And R1 contains an invalid address value, so the ACCVIO happens.
examine/instruction 21474836642147483664: CALLG B^4(SP),(R1)
display reg
$ analyze /process_dump DECW$WSINIT.DMP
...
%DEBUG-I-NOSOURCE, No source for address: 800000101
exa/ins 80000010EXE$QIOW_3: CALLG 04(SP),(R1)
CHARON $ mc decw$wsinit
Can't open display
CHARON $ set watch file/class=major
CHARON $ mc decw$wsinit
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Access (0,0,0) Status: 00000910
Can't open display
I get these messages with or without SET DISPLAY/CREATE
You turn off the XQP messages with $ SET WATCH FILE/CLASS=NOMAJOR
%SET-W-NOTSET, error modifying DUA0:
-CLI-E-IVDEVTYPE, invalid device type - specify a mailbox device
p1 = HILBERT:1
p2 =
On Tue, 17 Jun 2025 07:23:44 -0000 (UTC), JKB wrote:
%SET-W-NOTSET, error modifying DUA0:
-CLI-E-IVDEVTYPE, invalid device type - specify a mailbox device
p1 = HILBERT:1
p2 =
That looks like a clue. Why is it expecting a mailbox device and
getting a disk instead? Is there some confusion over logical names, perchance?
Le 17-06-2025, Lawrence D'Oliveiro <ldo@nz.invalid> a écrit :
On Tue, 17 Jun 2025 07:23:44 -0000 (UTC), JKB wrote:
%SET-W-NOTSET, error modifying DUA0:
-CLI-E-IVDEVTYPE, invalid device type - specify a mailbox device
Am 18.06.2025 um 10:04 schrieb JKB:
Le 17-06-2025, Lawrence D'Oliveiro <ldo@nz.invalid> a écrit :
On Tue, 17 Jun 2025 07:23:44 -0000 (UTC), JKB wrote:
%SET-W-NOTSET, error modifying DUA0:
-CLI-E-IVDEVTYPE, invalid device type - specify a mailbox device
There is probaly a SET TERM/INQUIRE in SYLOGIN.COM or LOGIN.COM, which
does NOT check, whether it's being executed in INTERACTIVE mode.
If run in BATCH oder NETWORK mode, SYS$INPUT points to the disk, on
which your login directory is located and you get the above error.
Try this:
$ IF F$MODE().EQS."INTERACTIVE" THEN $ SET TERM/INQUIRE
...
Thanks, I have set term/inquire in sys$login:login.com. Modification
done, but doesn't fix access violation error.
...
$ analyze /process_dump DECW$WSINIT.DMP
Condition signalled to take dump:
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=1211100F, PC
=80000010, PSL=03C00004
OpenVMS VAX Debug Version V7.3-017
examine/instruction 21474836642147483664: CALLG B^4(SP),(R1)
display reg
How can I display registers ?
set rad hex
ex %r0:r15
In the log file, is there any message about not being able to create a
process dump?
Nope 🙁
I have set accounting before posting. Strangely, all ACCVIO are
not loggued.
DECW$WSINIT Image Termination
-----------------------------
Username: BERTRAND UIC: [BERTRAND]
Account: Finish time: 14-JUN-2025 15:23:09.75
Process ID: 00000131 Start time: 14-JUN-2025 15:23:07.67
Owner ID: Elapsed time: 0 00:00:02.08
Terminal name: Processor time: 0 00:00:01.52
Remote node addr: Priority: 4
Remote node name: Privilege <31-00>: 00108000
Remote ID: Privilege <63-32>: 00000000
Remote full name:
Queue entry: Final status code: 1000000C
Queue name:
Job name:
Final status text: %SYSTEM-F-ACCVIO, access violation, reason mask=!XB, virtual
Page faults: 939 Direct IO: 8
Page fault reads: 42 Buffered IO: 121
Peak working set: 1482 Volumes mounted: 0
Peak page file: 2578 Images executed: 3
Image name: FERMAT$DUA0:[SYS0.SYSCOMMON.][SYSEXE]DECW$WSINIT.EXE
On 6/18/25 12:33, JKB wrote:
...
Thanks, I have set term/inquire in sys$login:login.com. Modification
done, but doesn't fix access violation error.
...
I didn't expect this to fix the ACCVIO. To me, it only proves that your login.com is being executed here.
$ analyze /process_dump DECW$WSINIT.DMP
Condition signalled to take dump:
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=1211100F, PC
=80000010, PSL=03C00004
OpenVMS VAX Debug Version V7.3-017
examine/instruction 21474836642147483664: CALLG B^4(SP),(R1)
display reg
How can I display registers ?
You already know their exact contents from the register dump.
To match with the register dump and/or the above ACCVIO message:
set rad hex
To see all register contents
ex %r0:r15
ex %r0:r150\%R0: 03C00000
The CALLG uses an argument list, which is on the stack. Maybe you can
find something useful on the stack.
show stack%DEBUG-W-BADSTACK, WARNING: stack corrupted; session integrity not guaranteed
In the log file, is there any message about not being able to create a
process dump?
Nope 🙁
You connect to XDM on the VAX, correct?
That is, DECW$WSINIT runs in the
context of the TCPIP$XDM user. In case there is a resource problem, it
may not be possible to write a process dump, just because doing so
requires resources, too. It's not obvious whether that is the case or
not. The fact that you get a process dump for the same ACCVIO when
running DECW$WSINIT interactively, indicates that the underlying problem
for the ACCVIO is not a resources problem.
I have set accounting before posting. Strangely, all ACCVIO are
not loggued.
I'm not sure I understand what you mean.
DECW$WSINIT Image Termination
-----------------------------
Username: BERTRAND UIC: [BERTRAND]
Account: Finish time: 14-JUN-2025 15:23:09.75
Process ID: 00000131 Start time: 14-JUN-2025 15:23:07.67
Owner ID: Elapsed time: 0 00:00:02.08
Terminal name: Processor time: 0 00:00:01.52
Remote node addr: Priority: 4
Remote node name: Privilege <31-00>: 00108000
Remote ID: Privilege <63-32>: 00000000
Remote full name:
Queue entry: Final status code: 1000000C
Queue name:
Job name:
Final status text: %SYSTEM-F-ACCVIO, access violation, reason mask=!XB, virtual
Page faults: 939 Direct IO: 8
Page fault reads: 42 Buffered IO: 121
Peak working set: 1482 Volumes mounted: 0
Peak page file: 2578 Images executed: 3
Image name: FERMAT$DUA0:[SYS0.SYSCOMMON.][SYSEXE]DECW$WSINIT.EXE
The ACCVIO is logged - as well as it can be logged by the accounting facility. The “Final status code” is translaated to “%SYSTEM-F-ACCVIO”,
but information about the PC etc. is not available at the time the
program terminates.
Thanks, I have set term/inquire in sys$login:login.com. Modification
done, but doesn't fix access violation error.
On 2025-06-18, JKB <JKB@hilbert.invalid> wrote:
Thanks, I have set term/inquire in sys$login:login.com. Modification
done, but doesn't fix access violation error.
Are you running on physical VAX hardware, or on an emulator ?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 508 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 238:20:01 |
| Calls: | 9,985 |
| Calls today: | 3 |
| Files: | 13,836 |
| Messages: | 6,358,233 |