I wanted a 100GB disk (using SIMH) under OpenVMS VAX V7.2.

That seems to be fine until I try to create a file. Admittedly I've only tried to create a file either using FTP or BACKUP, but as they're so disconnected, I assume that it's actually XQP (or something in the file system) that gets upset.

I backed off my disk size and even 20GB triggers the crash. 16GB seems to be OK.

Now OpenVMS beyond V5.5-2 supports single volumes of 1TB, so I'm surprised that a 16GB volume causes a crash.

Does anyone have a real VAX with a real disk (> 16GB) successfully hanging off it? I do have some SCA-80 36GB disks but I've never successfully got them working on either a VS4000-96 or a VS4000-60, so I'm not in a position to try this out myself.

The crash is below for those who enjoy that sort of thing!

Antonio

**** Fatal BUG CHECK, version = V7.2 UNXSIGNAL, Unexpected signal name in ACP

Crash CPU: 00 Primary CPU: 00

Active/available CPU masks: 00000001/00000001

Current process = UCX$FTPC_1

Register dump

R0 = 7FF6E0D8
R1 = 7FF6EAFC
R2 = 7FF6E4C0
R3 = 7FF6E4AC
R4 = 7FF6E4D0
R5 = 7FF6E4A8
R6 = 7FF6E588
R7 = 00000000
R8 = 00000001
R9 = 7FF6E4C0
R10= 7FF6E564
R11= 00000357
AP = 7FF6E088
FP = 7FF6E060
SP = 7FF6E050
PC = 833CAABC
PSL= 00000000

Kernel/interrupt/boot stack

7FF6E058 7FF6E684
7FF6E05C 7FF6E630
7FF6E060 00000000
7FF6E064 243C0000
7FF6E068 7FF6E0B4
7FF6E06C 7FF6E09C
7FF6E070 833CAA59
7FF6E074 83ABE9BC
7FF6E078 83ABE880
7FF6E07C 00000000
7FF6E080 000000C0
7FF6E084 7FF6E564
7FF6E088 00000003
7FF6E08C 7FF6E0D8
7FF6E090 7FF6E0C0
7FF6E094 7FF6E098
7FF6E098 00000000

On 2021-05-25 23:37:55 +0000, arca...@gmail.com said:

> I wanted a 100GB disk (using SIMH) under OpenVMS VAX V7.2.
>
> That seems to be fine until I try to create a file. Admittedly I've
> only tried to create a file either using FTP or BACKUP, but as they're
> so disconnected, I assume that it's actually XQP (or something in the
> file system) that gets upset.
>
> I backed off my disk size and even 20GB triggers the crash. 16GB seems
> to be OK.
>
> Now OpenVMS beyond V5.5-2 supports single volumes of 1TB, so I'm
> surprised that a 16GB volume causes a crash.
>
> Does anyone have a real VAX with a real disk (> 16GB) successfully
> hanging off it? I do have some SCA-80 36GB disks but I've never
> successfully got them working on either a VS4000-96 or a VS4000-60, so
> I'm not in a position to try this out myself.

You're retro-computing. For this case, you're trying more recent sizes
and limits than were typical ~three architectures back.

Theoretical limit for ODS-2 is 2 TB and was effectively 1 TB prior to
V8.4 due to some signed usage and that's all still ~busted in DCL to
this day.

Driver-permitted and console-permitted addressing was less, depending
on the hardware.

Old SCSI-2 was slightly past 8 GB up until V6.2 IIRC when IBM decided
to use an adjacent field to allow larger capacity addressing and that
then got standardized into SCSI-2, and PATA was limited to 24-bit on
OpenVMS, and VAXstation 3100 consoles do stupid things with storage on
boot devices larger than 1.073 GB.

Limits? 100 GB was ~ginormous in the era of OpenVMS VAX V7.2. SCSI was
flaky back then too, and you're on an emulated server just to add a
little more hardware complexity.

Somewhere back in this same V7.x range of versions, patches became
available only to support customers, too. Wouldn't surprise me that
you're missing a TCP/IP Services patch or three, as well as mandatory
OpenVMS VAX patches.

I'd suggest smaller devices and contemporary capacities, or the use of
rather newer OpenVMS versions if you want to work with OpenVMS and not
chase older hardware limits and older bugs, depending on your
retro-computing goals.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/25/2021 4:37 PM, arca...--- via Info-vax wrote:
> I wanted a 100GB disk (using SIMH) under OpenVMS VAX V7.2.
>
> That seems to be fine until I try to create a file. Admittedly I've only tried to create a file either using FTP or BACKUP, but as they're so disconnected, I assume that it's actually XQP (or something in the file system) that gets upset.
>
> I backed off my disk size and even 20GB triggers the crash. 16GB seems to be OK.
>
> Now OpenVMS beyond V5.5-2 supports single volumes of 1TB, so I'm surprised that a 16GB volume causes a crash.
>
> Does anyone have a real VAX with a real disk (> 16GB) successfully hanging off it? I do have some SCA-80 36GB disks but I've never successfully got them working on either a VS4000-96 or a VS4000-60, so I'm not in a position to try this out myself.

Get the latest SIMH and use the MicroVAX 3900 emulation. I boot my V7.3
from a 1.5 GB disk and have about a 22 GB data disk and another 4 GB
disk. I'm sure I've had simulations with larger drives. This was just
one I put together to stick on a flash drive to show some coworkers.

I seem to recall a customer running V7.1 on a VAX 4000-105 with a bit
larger boot drive and certainly a 20 GB data drive.

Antonio,

does this OpenVMS VAX V7.2 system have a SYSDUMP.DMP file ? If so, is there a CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS file ? Could you post the contents of that file - at least the CANASTA parameters section, the first 30 lines of the kernel stack and the insturction stream ?

If the CLUE file does not contain the crash footprint anymore, you can re-create it using:

$ CLUE:==$CLUE
$ CLUE/OUT=SYS$DISK:[]clue.lis SYS$SYSTEM:SYSDUMP.DMP

Volker.

On Wednesday, 26 May 2021 at 03:55:55 UTC+1, Stephen Hoffman wrote:
> You're retro-computing. For this case, you're trying more recent sizes and limits than were typical ~three architectures back.

The system from which I'm recovering data would have had RZ29 disks (4GB) back then, so I do realise that I'm going slightly beyond the original hardware :-) But the documented limits were much higher and I would have though that they would have been tested. Naturally there were precisely zero 100GB+ drives in the days of V6 but a hacked version of LDDRIVER that did sparse allocation and claimed to be a 32GB disk would have found this pretty quickly. Assuming it's an OpenVMS issue and not a SIMH issue.

> Somewhere back in this same V7.x range of versions, patches became available only to support customers, too. Wouldn't surprise me that you're missing a TCP/IP Services patch or three, as well as mandatory OpenVMS VAX patches.

FTP was where I hit this first. So then I FTP'd the first saveset to a smaller disk (and also having misread UNXSIGNAL as UCXSIGNAL in my head :-)) I then decided to expand the first saveset onto the 100GB drive ... it blew up in exactly the same way. So I can't blame UCX :-(

> I'd suggest smaller devices and contemporary capacities, or the use of rather newer OpenVMS versions if you want to work with OpenVMS and not chase older hardware limits and older bugs, depending on your retro-computing goals.

Turns out that the savesets are all /IMAGE backups so, unless I want to see more "invalid related NAM block", I'm better off with a series of 2GB-4GB volumes anyway, at least for the targets when I expand the savesets.

Thanks

Antonio

--
Antonio Carlini

On Wednesday, 26 May 2021 at 06:39:29 UTC+1, Volker Halle wrote:
> Antonio,
>
> does this OpenVMS VAX V7.2 system have a SYSDUMP.DMP file ? If so, is there a CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS file ?

There is a CLUE$LAST_VAX072.LIS in SYS$MANAGER but it just records the last shutdown. I can (I think) recreate the crash at will so I can do that once I've finished the current FTP session (although that will probably take most of today ... 30GB is a lot to transfer on an emulated VAX!).

I can probably scrounge up a listings CD and BUGCHECK.MEM and see if I can remember how to walk a VAX stack, but I'm not sure where to go from there. I don't think HP will be interested and they almost certainly don't have anyone left who remembers how to generate an ECO for OpenVMS VAX. Even if they did, they wouldn't let me have it for free :-)

Antonio

Antonio,

you could also use the CLUE history file to obtain the CLUE crash footprint - while waiting for the FTP copy to finish ;-)

$ CLUE:==$CLUE ! define CLUE as foreign command
$ CLUE/DISPLAY ! display list of crashes
CLUE> SHOW n ! n = crash number from column 1 (#)
CLUE> EXTRACT/OUT=crash.lis n

Volker.

On 2021-05-26 08:40:50 +0000, arca...@gmail.com said:

> On Wednesday, 26 May 2021 at 03:55:55 UTC+1, Stephen Hoffman wrote:
>> You're retro-computing. For this case, you're trying more recent sizes
>> and limits than were typical ~three architectures back.
> The system from which I'm recovering data would have had RZ29 disks
> (4GB) back then, so I do realise that I'm going slightly beyond the
> original hardware :-) But the documented limits were much higher and I
> would have though that they would have been tested. Naturally there
> were precisely zero 100GB+ drives in the days of V6 but a hacked
> version of LDDRIVER that did sparse allocation and claimed to be a 32GB
> disk would have found this pretty quickly. Assuming it's an OpenVMS
> issue and not a SIMH issue.

If this is a production project, stop looking for other issues, ~mirror
the existing hardware environment for the existing code, and get the
source code ported to Linux, BSD, Windows, or OpenVMS V8.4+; with
wherever you're going with this app or this data.

As for your testing assumptions, ~nobody back then was looking for
these sorts of issues, as you're off in what was then unavailable or
unsupported territories, and—more problematically—you're also working
with a veritable dearth of patches installed.

There have been a number of retro-computing folks posting around here
that wanted "the experience", of course. Many have subsequently gotten
clobbered by their more modern assumptions, and/or by the lack of
patches, and/or by emulator or flaky hardware bugs.

This isn't new. OpenVMS has serious gaps now—not the least of which is
the now-less-than-theoretical though rather-better-tested 2 TiB
addressing limit, and a file system itself designed for hard disk
drives—and which will be even more striking given the benefit of ten or
twenty years' hindsight, and hardware and software advances. I'm
loading now-small 10 TB HDD spindles into NAS arrays. One of these
HDDs is as much or more than many VAX configurations had in aggregate.
A shelf of these now-small HDDs is more array storage than many
production AlphaServer configurations featured. With your data-access
project, you're back nearly a quarter century. That's a long time in
the IT business.

If this is a hobbyist data-recovery project, have at. I'd still
recommend Alpha or Alpha emulation here (reports here that AXPbox works
reasonably well, IDE bugs aside), as Alpha has the advantage of a
couple of decades of updates that your OpenVMS VAX configuration lacks.

And here, I'd wonder if this is a TCP/IP Services bug. TCP/IP Services
prior to V5 (UCX$) wasn't entirely stable, and V5 (TCPIP$) and later
has had and has its issues. DEC sought OSI, and OpenVMS IP support
never recovered.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-05-26 09:07:49 +0000, arca...@gmail.com said:

> ... 30GB is a lot to transfer on an emulated VAX!...

Transfer it to the host via scp or sftp or ftp or whatever, and mount
the image from the emulation? IIRC, there are virtual tape bits for
simh, too. And for unpacking savesets, vmsbackup (usually) works on
macOS and Linux.

--
Pure Personal Opinion | HoffmanLabs LLC

On Wednesday, 26 May 2021 at 16:33:54 UTC+1, Stephen Hoffman wrote:
> If this is a production project,

If this is production, then I'm doing something illegal ... or maybe OpenVMS licensing has moved on. I'm not aware of any way to legally run OpenVMS on SIMH. I guess HP *could* issue a commercial licence for SIMH, but I'd be pretty surprised if they ever had!

>
> As for your testing assumptions, ~nobody back then was looking for
> these sorts of issues,

I'm just surprised that the size was supported without any testing at all. 4GB was common back then and 8GB existed. Just one further doubling would have come close to hitting this issue (assuming it is real and not just something sent to try me).

> production AlphaServer configurations featured. With your data-access
> project, you're back nearly a quarter century. That's a long time in
> the IT business.
I know.

> If this is a hobbyist data-recovery project, have at.
It is, and rest assured I will :-)

> recommend Alpha or Alpha emulation here (reports here that AXPbox works
> reasonably well, IDE bugs aside), as Alpha has the advantage of a
> couple of decades of updates that your OpenVMS VAX configuration lacks.

I will have to give AXPbox a spin some time. However, my set of Alpha OS releases is even more limited (only V6.2 ... donations gratefully accepted :-)) so I'd actually be going backwards in time.

> And here, I'd wonder if this is a TCP/IP Services bug. TCP/IP Services
> prior to V5 (UCX$) wasn't entirely stable,
Sadly the crashes have dropped off my my terminal's scrollback buffer so I can't currently offer any evidence. My first assumption was to blame UCX's FTP too. But then I did the equivalent of:

$ BACKUP DUA2:[000000]FOO.BCK/SAV DUA1:[FOO...] ! DUA1 is ~100GB at this point

and instantly hit exactly the same crash.

I rather suspect that:
$ copy tt: dua1:[000000]test.txt
hi
^Z

will do exactly the same ...

> and V5 (TCPIP$) and later
> has had and has its issues. DEC sought OSI, and OpenVMS IP support
> never recovered.

True. But DECnet VAX Extensions/DECnet OSI/DECnet Plus (or at least the PSI/WANDD bits thereof) kept me in REO for a while and that would probably never have happened if IP had ruled the roost in DEC. So I'm not complaining :-)

Antonio

> %CLUE_F_FATAL CLUE$OUTPUT:CLUE$HISTORY.DATA, Illegal format: @ 1:0B4

Antonio,

There is a CLUE history problem in V7.2 !

I may not be able of offer a patch, but maybe a workaround...

Volker.

On 2021-05-26, arca...@gmail.com <arcarlini@gmail.com> wrote:
> On Wednesday, 26 May 2021 at 16:33:54 UTC+1, Stephen Hoffman wrote:
>> If this is a production project,
>
> If this is production, then I'm doing something illegal ... or maybe OpenVMS licensing has moved on. I'm not aware of any way to legally run OpenVMS on SIMH. I guess HP *could* issue a commercial licence for SIMH, but I'd be pretty surprised if they ever had!
>

You can legally transfer a normal commercial licence from a physical
system to one of the commercial emulators for a fee. I don't know if
SimH is covered by that however.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-05-26 18:38:06 +0000, arca...@gmail.com said:

> On Wednesday, 26 May 2021 at 16:33:54 UTC+1, Stephen Hoffman wrote:
>> If this is a production project,
> If this is production, then I'm doing something illegal ... or maybe
> OpenVMS licensing has moved on. I'm not aware of any way to legally run
> OpenVMS on SIMH. I guess HP *could* issue a commercial licence for
> SIMH, but I'd be pretty surprised if they ever had!

OpenVMS licensing moved on most of twenty years ago, and emulators can
be licensed for production, and have been. I'm aware of both VAX and
Alpha emulators in production, fully licensed.

For an early announcement of this:
https://groups.google.com/g/comp.os.vms/c/hjBdPuum290/m/mTre9M-FO1oJ

>> As for your testing assumptions, ~nobody back then was looking for
>> these sorts of issues,
> I'm just surprised that the size was supported without any testing at
> all. 4GB was common back then and 8GB existed. Just one further
> doubling would have come close to hitting this issue (assuming it is
> real and not just something sent to try me).

I'm just surprised you think the 100 GB size was supported back then.
It's certainly within the theoretical range for the ODS-2 design, but
the HDD device support back then was a whole lot less than 100 GB.

IDE/ATAPI/PATA device support hasn't gotten anywhere near 1 TiB or 2
TiB, either. DQDRIVER—other than a test driver I'd reworked and
prototyped—was still using 24-bit addressing when last I checked.

--
Pure Personal Opinion | HoffmanLabs LLC

On Wednesday, 26 May 2021 at 21:59:52 UTC+1, Stephen Hoffman wrote:

> I'm just surprised you think the 100 GB size was supported back then.
> It's certainly within the theoretical range for the ODS-2 design, but
> the HDD device support back then was a whole lot less than 100 GB.
>
> IDE/ATAPI/PATA device support hasn't gotten anywhere near 1 TiB or 2
> TiB, either. DQDRIVER—other than a test driver I'd reworked and
> prototyped—was still using 24-bit addressing when last I checked.
> --
The nearest I can find to a statement is the FAQ: https://www.digiater.nl/openvms/freeware/v70/vmsfaq/vmsfaq_012.html.

I can't find a V6.0 SPD/New features/Release Notes anywhere (either on the web or here). The last time I looked they were still up at HP but right now I can't find them. I'm sure they're somwhere in archive.org but without even a dead link to follow, I'm not able to get any further. Oh well.

Antonio

On 2021-05-27 10:35:45 +0000, arca...@gmail.com said:

> On Wednesday, 26 May 2021 at 21:59:52 UTC+1, Stephen Hoffman wrote:
>
>> I'm just surprised you think the 100 GB size was supported back then.
>> It's certainly within the theoretical range for the ODS-2 design, but
>> the HDD device support back then was a whole lot less than 100 GB.
>> IDE/ATAPI/PATA device support hasn't gotten anywhere near 1 TiB or 2
>> TiB, either. DQDRIVER—other than a test driver I'd reworked and
>> prototyped—was still using 24-bit addressing when last I checked.
>>
> The nearest I can find to a statement is the FAQ:
> https://www.digiater.nl/openvms/freeware/v70/vmsfaq/vmsfaq_012.html.

That FAQ entry was a result of trying to stave off the questions, and
the problems when folks hit one of the limits.

Also check "the fine print" section at the top of the OpenVMS FAQ.

Most device drivers can now support 2 TiB, as quaint as that limit has
become. AFAIK, IDE/ATAPI/PATA/DQ and the (undocumented) FAT file system
implementation for the console are among the remaining exceptions to
storage addressing, if not the only.

> I can't find a V6.0 SPD/New features/Release Notes anywhere (either on
> the web or here). The last time I looked they were still up at HP but
> right now I can't find them. I'm sure they're somwhere in archive.org
> but without even a dead link to follow, I'm not able to get any
> further. Oh well.

Had a number of discussions with the product managers about the
contents of the SPDs. The PMs (and eventually, in the hardware support
database—trying to keep this list on paper is ~doomed) listed supported
devices. The various PMs weren't big on listing theoretical limits.
Limits that they didn't (at the time) have a good way of testing. I'm
also the "guilty party" that caused a number of VAX boxes to marked as
officially unsupported, with most of those retirements due to
required-memory increases, or due to bootable media deprecations.

I know this is c.o.v. and we're not supposed to discuss search engines,
but a DDG or Chocolate Factory search for the following might get you
closer to your quest: openvms vax software product description
site:archive.org

--
Pure Personal Opinion | HoffmanLabs LLC

On Thursday, 27 May 2021 at 17:31:08 UTC+1, Stephen Hoffman wrote:

> That FAQ entry was a result of trying to stave off the questions, and
> the problems when folks hit one of the limits.

Sorry :-)

> I know this is c.o.v. and we're not supposed to discuss search engines,
> but a DDG or Chocolate Factory search for the following might get you
> closer to your quest: openvms vax software product description
> site:archive.org

I'm already trawling through archive.org, this time I'm picking up the manuals that I can find ... I can get back to V7.2 without too much hassle, although some bits are missing. I suspect that the V6 stuff that used to be up was under the digital.com domain and that, sadly, is blocked.

Antonio

On Wednesday, 26 May 2021 at 19:56:48 UTC+1, Volker Halle wrote:
> > %CLUE_F_FATAL CLUE$OUTPUT:CLUE$HISTORY.DATA, Illegal format: @ 1:0B4
> Antonio,
>
> There is a CLUE history problem in V7.2 !
>
> I may not be able of offer a patch, but maybe a workaround...

I think the workaround is either "don't do that" or "use V7.3"!

The bug is just the XQP getting upset. COPY is enough to make it happen, so I expect that anything that creates a file (and maybe writes to it) is enough to trigger the bug.
I have the V7.1 listings but not the V7.2 listings. Things have changed enough between the two that I can't find the DIVL3 (which looked rare enough that there wouldn't be a huge number of hits, or at least fewer than UNXSIGNAL!).
I don't really feel like going through the process of installing V7.1 just to pin this one down, so that's as far as I'm going to go.

I've included the crash and the CLUE output for posterity :-)

(Apologies for the length ...)

Antonio

$ sh dev dud3

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
VAX072$DUD3: Mounted 0 TEST 59999144 1 1
$ set def dud3:[000000]
$ copy tt: test.txt
test

**** Fatal BUG CHECK, version = V7.2 UNXSIGNAL, Unexpected signal name in ACP

Crash CPU: 00 Primary CPU: 00

Active/available CPU masks: 00000001/00000001

Current process = SYSTEM

Register dump

R0 = 7FF6E0D8
R1 = 7FF6EAFC
R2 = 7FF6E4C0
R3 = 7FF6E4AC
R4 = 7FF6E4D0
R5 = 7FF6E4A8
R6 = 7FF6E588
R7 = 00000000
R8 = 00000003
R9 = 7FF6E4C0
R10= 7FF6E564
R11= 00000357
AP = 7FF6E088
FP = 7FF6E060
SP = 7FF6E050
PC = 833CAABC
PSL= 00000000

Then more with CLUE:

$ ty SYS$MANAGER:clue.lis
CLUE Version: V1.9 Date: 27-MAY-2021 21:43:33.37

CLUE /OUT=SYS$MANAGER:CLUE.LIS SYS$SYSTEM:SYSDUMP.DMP

Dump File: SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;1

Full Memory Dump: Dump Flags = 020400C0
Current Process Name = SYSTEM
Current IPL = 0
Dump file version = 0530
# memory pages in dump = 130944 Physical memory = 64 MB
SID = 0A000006
Crash time = 27-MAY-2021 21:35:53.61
Current Access mode = KERNEL
Node Name = VAX072 Clustered
Crash CPU/Primary CPU = 0 / 0
CPU 0 Crash Code 41C,Crash Type = UNXSIGNAL
Bitmask of CPUs available = 1
Bitmask of CPUs active = 1
CPU Bitmask completing bugcheck = 1
Current image: = VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]COPY.EXE
CPU Type = VAXserver 3900 Series
VMS Version = V7.2

Symbol Value Contents

EXE$GL_MCHKERRS -> 800044F0 = 00000000
EXE$GL_MEMERRS -> 800044F4 = 00000000
EXE$GL_STATE -> 80008490 = 00003FFE
EXE$GQ_BOOTTIME -> 80004460 = 27-MAY-2021 21:30:03.46
EXE$GL_FLAGS -> 800042F0 = 02416865
IO$GL_UBA_INT0 -> 800044F8 = 00000000
MPW$GB_IOLIM -> 800080AA = 00040404
PMS$GL_NPAGDYNEXPF -> 80004700 = 00000000
PMS$GL_NPAGDYNF -> 8000491C = 00000000
PMS$GL_NPAGDYNFPAGES -> 80004920 = 00000000
PMS$GL_NPAGDYNREQF -> 8000492C = 00000000
PMS$GL_PAGDYNF -> 80004704 = 00000000
PMS$GL_PAGDYNFPAGES -> 80004924 = 00000000
PMS$GL_PAGDYNREQF -> 80004934 = 00000000
SCH$GL_FREECNT -> 80004018 = 00017AF9
SCH$GL_PFRATL -> 800080C4 = 00000000

SBR 03E98400 SLR 00055F00

Processor Information for Crash CPU 0 (Hex)

R0 7FF6E0D8 R1 7FF6EAFC R2 7FF6E4C0 R3 7FF6E4AC R4 7FF6E4D0
R5 7FF6E4A8 R6 7FF6E588 R7 00000000 R8 00000003 R9 7FF6E4C0
R10 7FF6E564 R11 00000357 AP 7FF6E088 FP 7FF6E060 SP 7FF6E058
PC 833CAABC PSL 00000000 KSP 7FF6E058 ESP 7FFE971C SSP 7FFECA44
USP 7FEC70F8 ISP 8464F600 P0BR 84734A00 P1BR 83F84A00 P0LR 000005BD
P1LR 001FF625 PCBB 037CDA20 SCBB 03E91800 SISR 00000000
ASTLVL = 00000001
ICCS = 00000040

CPU Dependent Registers:

# Regs = 0D (Hex)
5BA6B25E
000000FC
00000000
00000000
00000001
00000000
00000020
00000000
00001000
00FFFFFF
80000017
00000050
00000004

Spinlocks owned by CPU 00 (Hex) (CRASH CPU) NONE

Summary of System at time of Crash:

PCB State CPU Process Name Username EPID Pri PHD Wkset

8347DBA0 HIB SWAPPER 20200201 16 8347DA00 0
83AC4440 HIB CLUSTER_SERVER SYSTEM 20200206 12 847EB600 311
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]CSP.EXE;1
83AC4640 HIB CONFIGURE SYSTEM 20200207 10 84784A00 180
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]CONFIGURE.EXE;1
83AC4840 HIB LANACP SYSTEM 20200208 13 84852200 516
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]LANACP.EXE;1
83AC4C40 HIB IPCACP SYSTEM 2020020A 10 84650600 177
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]IPCACP.EXE;1
83AC4E40 HIB ERRFMT SYSTEM 2020020B 8 848B8E00 211
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]ERRFMT.EXE;1
83AC5040 HIB CACHE_SERVER SYSTEM 2020020C 16 8491FA00 134
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]FILESERV.EXE;1
83AC5240 HIB OPCOM SYSTEM 2020020D 9 84986600 257
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]OPCOM.EXE;1
83AC5440 HIB AUDIT_SERVER AUDIT$SERVER 2020020E 9 849ED200 516
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]AUDIT_SERVER.EXE;1
83AC5640 HIB JOB_CONTROL SYSTEM 2020020F 10 84A53E00 403
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]JBC$JOB_CONTROL.EXE;1
83AC5840 HIB QUEUE_MANAGER SYSTEM 20200210 9 84ABAA00 1020
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]QMAN$QUEUE_MANAGER.EXE;1
83AC5A40 HIB SECURITY_SERVER SYSTEM 20200211 10 84B21600 1370
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SECURITY_SERVER.EXE;1
83AC5C40 HIB SMISERVER SYSTEM 20200212 9 84B88200 592
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SMISERVER.EXE;1
83AC5E40 HIB TP_SERVER SYSTEM 20200213 9 84BEEE00 317
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]TPSERV.EXE;1
83AC6240 HIB NETACP DECNET 20200215 10 84C55A00 377
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]NETACP.EXE;1
83AC6440 HIB EVL DECNET 20200216 6 84CBC600 554
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]EVL.EXE
83AC4240 HIB REMACP SYSTEM 20200217 8 84D23200 56
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]REMACP.EXE;1
839DC140 HIB UCX$INET_ACP INTERnet 20200218 10 846B7200 175
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]UCX$INETACP.EXE;1
83AC79C0 LEF UCX$INET_ROUTED INTERnet 20200219 6 84D89E00 504
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]UCX$INET_ROUTING.EXE;1
83AC4040 CUR 0 SYSTEM SYSTEM 2020021A 9 8471DE00 542
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]COPY.EXE

Code Modules:

Module Name Address Length

UCX$INTERNET_SERVICES 82F4D000 00015800
SYSMSG 832C5200 00045200
SYSLDR_DYN 834FA200 00002000
DDIF$RMS_EXTENSION 834FC600 00001200
RECOVERY_UNIT_SERVICES 834FDA00 00000800
RMS 8330A600 0002C400
SYS$NTA 8337F600 00000200
VAXCLUSTER_CACHE 8337FC00 00004A00
SYS$NETWORK_SERVICES 83384C00 00000200
SYS$UTC_SERVICES 83385400 00000E00
SYS$TRANSACTION_SERVICES 83386800 0000DE00
SYS$IPC_SERVICES 83394A00 0001DC00
CPULOA 833B2800 00005400
LMF$GROUP_TABLE 833BA000 00001A00
SYSLICENSE 833BBE00 00003200
F11BXQP 833BF400 0001F600
SNAPSHOT_SERVICES 833DF200 00000C00
SYSGETSYI 833E0400 00002000
SYSDEVICE 833E2800 00002A00
MESSAGE_ROUTINES 833E5800 00006200
EXCEPTION 833FC000 0000A800
LOGICAL_NAMES 83407000 00023800
SECURITY 8342B200 00009A00
LOCKING 83435400 00006C00
PAGE_MANAGEMENT 8343CA00 00009E00
WORKING_SET_MANAGEMENT 8345B600 00005E00
IMAGE_MANAGEMENT 83461E00 00003600
EVENT_FLAGS_AND_ASTS 83465A00 00002200
IO_ROUTINES 83468600 0000CA00
PROCESS_MANAGEMENT 83476A00 0000C400
ERRORLOG 834EC400 00000C00
PRIMITIVE_IO 834ED600 00001200
SYSTEM_SYNCHRONIZATION_UNI 834EEC00 00004400
SYSTEM_PRIMITIVES_MIN 834F3600 00003E00
BUGCHECK_CODE_OVERLAY 82F4D000 00003964
TNDRIVER 83B21200 000034C0
UCX$BGDRIVE 83AC6640 00000240
RTTDRIVER 83AEE5C0 00000B80
CTDRIVER 83B1D7C0 00002980
NDDRIVER 83AEAEC0 00000AC0
NETDRIVER 83B0F2C0 00005140
PIPEDRIVER 83AD10C0 00000580
FTDRIVER 83AE7280 000009C0
YFDRIVER 83B01800 00001140
DZDRIVER 83AF3A80 00000D40
PEDRIVER 839F0B00 0000B2C0
XQDRIVER 839DE340 000091C0
DUDRIVER 83C33700 00005F90
PUDRIVER 83C30240 0000349A
TTDRIVER 83C2A4C0 00005D7D
OPERATOR 834F5C00 0000056C
NLDRIVER 833E2883 0000019B
MBDRIVER 833E2800 000019A0
CLIMAGE 7FF50400 0001CDFF
CLUSTRLOA 83C125C0 0000F8FF
SYSLOA 83C22EC0 000047C8
F11BXQP 00000000 00000000
F11BXQP_IMPURE 7FF6D200 80092E00
CTL$GQ_DBGAREA 7FFF0000 0000FFFF
P1SYSVECTORS 7FFEDE00 000009FF
FPEMUL 83C0C480 00002ABC
VAXEMUL 83C0EF40 0000367F
MSCP 83A17780 00003FA0
SCSLOA 83C276C0 00002DEF
PAGED_POOL 8377CE00 002415FF
NONPAGED_POOL 839BE400 00283000
ALLOCATABLE_S0 8000AF84 034F867B
COPY 00000200 0000DDFF

On Tuesday, May 25, 2021 at 4:37:56 PM UTC-7, arca...@gmail.com wrote:
> I wanted a 100GB disk (using SIMH) under OpenVMS VAX V7.2.
>
> That seems to be fine until I try to create a file.
>Admittedly I've only tried to create a file either using FTP or BACKUP,
> but as they're so disconnected, I assume that it's actually XQP
> (or something in the file system) that gets upset.

Just wondering, does it know about NFS?

I think NFS mostly gets around disk size problems, as the client OS doesn't really
need to know about it. I do find that disk available reports sometimes do 32 bit
math, and get the wrong value, but that doesn't affect actual disk use.

A few years ago, I had a Sun3 NFS boot off a 3TB disk, which it didn't
mind at all. The last release of SunOS 4.1.1 was in 1991, so I am pretty
sure didn't know about 3TB disks.

Also, and this might apply to VMS, NFS disks tend to remove file name length
restrictions of the client OS. Years ago, we had a version of HP-UX that had
a short (I believe 17 character) restriction on its native file system, but
not for NFS.

Antonio,

this was a 'known problem' at it's time - mostly V6.2.

There even was/is a CANASTA rule describing this problem and a workaround....

CANASTA was the automatic Crashdump Analysis Tool, which I maintained for about a decade while at Digital/Compaq/HP. I still claim to be the person, which has seen more OpenVMS crash footprints than anyone else ;-)

The problem itself seems to be in MOUNT, when setting up the geometry of the disk. Solutions i.e. patches may exist in the V7.2 remedial stream or higher.

WORKAROUND:

Configure a smaller disk on the controller. After configuring the smaller
disk, mount the disk and do a $ SHOW DEVICE/FULL. Perform the following
calculation using the numbers from the $ SHOW DEVICE/FULL output.

sectors per track * tracks per cylinder * total cylinders = total blocks.

If the calculation works, the disk is OK to use.

With ANALYZE/SYSTEM:

SDA> READ SYS$SYSTEM:SYSDEF
SDA> SHOW DEV DKcnnn
....
SDA> exa ucb+ucb$l_maxblock
UCB+000C4: 021EB1B0 "°±.."
SDA> eva (@(ucb+ucb$b_sectors)&FF)*(@(ucb+ucb$b_tracks)&FF)*(@(ucb+ucb$w_cylinders)&FFFF)
Hex = 0020B32C Decimal = 2143020

This crash has also been seen on a CHARON-VAX (Stromasys commercial VAX emulator) and could be prevented by using the geometry statement to set a 'valid' geometry, e.g.

SET DKA geometry[200] = "125/16/17783" ! s=sectors t=tracks c=cylinders (disk size about 18 GB)

Don't know if simh supports setting the disk geometry.

Volker.

On Friday, 28 May 2021 at 12:07:57 UTC+1, Volker Halle wrote:
>
> CANASTA was the automatic Crashdump Analysis Tool, which I maintained for about a decade while at Digital/Compaq/HP. I still claim to be the person, which has seen more OpenVMS crash footprints than anyone else ;-)

Ah, now I see why you wanted the CLU output :-)

> The problem itself seems to be in MOUNT, when setting up the geometry of the disk. Solutions i.e. patches may exist in the V7.2 remedial stream or higher.

OK, thanks for that.

>
> Don't know if simh supports setting the disk geometry.

Not that I can see.

But I'm OK with configuring a bunch of smaller disks. Then I can archive "clean" copies of the original SIMH .dsk containers somewhere and work through the data on the emulated system.

Antonio

On 2021-05-28 11:07:55 +0000, Volker Halle said:

> The problem itself seems to be in MOUNT, when setting up the geometry
> of the disk. Solutions i.e. patches may exist in the V7.2 remedial
> stream or higher.

There was an easily-reproduceable bug in a related area of MOUNT.

Load a blank CD into an optical drive, and MOUNT it.

Kernel loop.

Using MOUNT with a blank CD (unsurprisingly) got somewhat odd responses
from the device, and the drivers and MOUNT then mis-handled it, leading
to an un-deletable process looping in kernel mode.

Only fix was a reboot, after dropping the process priority of the
looping process to let it tussle with null until the reboot was
feasible.

IIRC, both MOUNT and the related device drivers got fixes as a result
of that particular case. And IIRC, it was a bug in the MOUNT code
intended to find the home block / alternate home block.

ps: CANASTA/CCAT/etc was handy to have around. Unfortunately, it
usually just left me with a pile of gnarly crashes, after having used
it to eliminate all the known crashes.

--
Pure Personal Opinion | HoffmanLabs LLC

On 05/28/21 09:04, gah4 wrote:
> On Tuesday, May 25, 2021 at 4:37:56 PM UTC-7, arca...@gmail.com wrote:
>> I wanted a 100GB disk (using SIMH) under OpenVMS VAX V7.2.
>>
>> That seems to be fine until I try to create a file.
>> Admittedly I've only tried to create a file either using FTP or BACKUP,
>> but as they're so disconnected, I assume that it's actually XQP
>> (or something in the file system) that gets upset.
>
> Just wondering, does it know about NFS?
>
> I think NFS mostly gets around disk size problems, as the client OS doesn't really
> need to know about it. I do find that disk available reports sometimes do 32 bit
> math, and get the wrong value, but that doesn't affect actual disk use.
>
> A few years ago, I had a Sun3 NFS boot off a 3TB disk, which it didn't
> mind at all. The last release of SunOS 4.1.1 was in 1991, so I am pretty
> sure didn't know about 3TB disks.
>
> Also, and this might apply to VMS, NFS disks tend to remove file name length
> restrictions of the client OS. Years ago, we had a version of HP-UX that had
> a short (I believe 17 character) restriction on its native file system, but
> not for NFS.
>

Sun 3 SunOs was 32 bit and a signed number described the partition
block count. For a boot partition, the limit was 1 Gbyte, from
memory.

The way we used to get round disk sizes for RT11, was to declare a
set of logical drives across a single drive, which worked very well.
I would think vms would have similar facilities...

of logical drives, which

On 2021-06-01 16:48:44 +0000, chris said:

> The way we used to get round disk sizes for RT11, was to declare a
> set of logical drives across a single drive, which worked very well.
> I would think vms would have similar facilities...
>
> of logical drives, which

OpenVMS Development never prioritized the addition of partitioning
support. That, and this case involves a very old and under-patched and
buggy OpenVMS VAX version. Retro-computing almost inherently involves
revisiting old bugs.

More recent OpenVMS has a hideously ugly partitioning hack commonly
found on OpenVMS I64 and specifically for Itanium EFI support, and that
hack is solely intended to present what OpenVMS expects (one big
volume) and what EFI expects (GPT partitioning) and without allowing
partition-aware tools to easily corrupt the OpenVMS one-big-volume view
of the storage. Silent console-triggered corruptions were once
possible here with older EFI firmware too, when the expectations of the
firmware and of OpenVMS diverged.

Back closer to the same era as the OpenVMS VAX version that started off
this discussion, VAXstation 3100 had 6-byte SCSI commands which limited
volume capacity support, so some folks took to placing the boot files
and crash files within the first ~gigabyte, which worked great right up
until an upgrade moved a file above the address of doom, or the dump
file got re-sized above the address of doom. Wrappage-triggered badness
often then ensued. Some folks placed a big file at the end of the
volume, which blocked upgrades from accessing that storage. I'd expect
some later used that as an LD device, though LD wasn't nearly as
commonly used back in the era when vast herds of VAXstation 3100 roamed
the earth. Yes, I'm here ignoring VD driver, and whatever that
pseudo-device latent in STABACKIT was named.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-06-01, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> OpenVMS Development never prioritized the addition of partitioning
> support. That, and this case involves a very old and under-patched and
> buggy OpenVMS VAX version. Retro-computing almost inherently involves
> revisiting old bugs.
>

It would be nice to have proper partition support on VMS, with multiple
bootable partitions as well.

> More recent OpenVMS has a hideously ugly partitioning hack commonly
> found on OpenVMS I64 and specifically for Itanium EFI support, and that
> hack is solely intended to present what OpenVMS expects (one big
> volume) and what EFI expects (GPT partitioning) and without allowing
> partition-aware tools to easily corrupt the OpenVMS one-big-volume view
> of the storage. Silent console-triggered corruptions were once
> possible here with older EFI firmware too, when the expectations of the
> firmware and of OpenVMS diverged.
>

I wonder if we are heading towards a modern version of the various
WRITEBOOT issues and "fun" that sometimes happened in the old days... :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

I find these discussions interesting. Why would anyone expect software written 20 or more years ago to support (without change) hardware that wasn't even a concept at the time? Saying that this may result in similar issues to the "writeboot" issues of the past seems a bit much too. Take a snapshot of the state of the software today and come back in 30 years with new hardware and see what happens. I would expect to see similar "problems".