Conference help::decnet-osi_for_vms

$ set message sys$message:dns$msg
$ exit %x01DE864A
%DNS-E-RESOURCEERROR, Insufficient resources to process request


John Saunders
DECdns Engineering

Thanks for doing what I should have done!

What could the system be out of?  Keep in mind that HUMANE has recently added a
lot of Notes conferences and so has increased activity.

Paul

Do you have a local name database?  The corporate nameserver structure isn't
the most robust because the servers that handle the synonym and backtranslation
directories get hit pretty hard by even those nodes with a local name directory
because of the requirement to verify the node's towersets in those directories.

There's no local database, just DECDNS and DOMAIN for node name translation.

I ran NET$SHUTDOWN last night and the system crashed but came right back up.

Running CDI$TRACE this morning shows none of the "resource" errors from
yesterday.

I had to flush the entry for node FUNYET or notes I entered still showed up
numerically.  So, unless I flush the whole cache, people who didn't have their
node names translated yesterday will wind up with numeric addresses until, when?

If I'm running out of threads, what would I do about that?

Paul

I'm still checking to see how many different things RESOURCEERROR could be (I'm
new here).

In the meantime, do I understand you to be saying that your system CRASHED when
you ran NET$SHUTDOWN?

That is not a feature.

Could you please save the dump and let someone here look at it?

Thanks,
John Saunders
DECdns Engineering

John,

> I'm still checking to see how many different things RESOURCEERROR could be
> (I'm new here).

Thank you.  If it happened once, it will probably happen again, so I'd like to
know how to solve the resource problem.

> In the meantime, do I understand you to be saying that your system CRASHED
> when you ran NET$SHUTDOWN?

Yes it did.  I was at home, and it was shutting down transports when I lost the
connection to the system.

> That is not a feature.

Well, it provided a quick reboot, didn't it?

> Could you please save the dump and let someone here look at it?

The dump file is at HUMANE::DISK$KAKA:[DUMPS]SYSDUMP.DMP.

Paul

Directory USER$62:[SAUNDERS.DUMPS]

HUMANE_CRASH.DMP;1    141485  27-FEB-1997 14:40:22.86

Total of 1 file, 141485 blocks.


However,

$ ana/crash HUMANE_CRASH.DMP
VAX/VMS System dump analyzer

%SDA-E-DUMPEMPTY, dump file contains no valid dump


Sorry, but are you sure the system rebooted? Were the SYSGEN parameters set to
create a dump? Please check DUMPSTYLE, SAVEDUMP, and DUMPBUG. Also, make sure
you have a SYS$SYSTEM:SYSDUMP.DMP and confirm that it is large enough to hold
all of your memory plus ERLBUFFERPAGES*ERRORLOGBUFFERS.

John Saunders
DECdns Engineering

Here's what I get from the dump.

Paul


$ analyze /crash disk$kaka:[dumps]sysdump.dmp

OpenVMS (TM) Alpha system dump analyzer
...analyzing a compressed selective memory dump...

Dump taken on 26-FEB-1997 22:10:25.93
UNXSIGNAL, Unexpected signal name in ACP

SDA> show crash

System crash information
------------------------
Time of system crash: 26-FEB-1997 22:10:25.93

Version of system: OpenVMS (TM) Alpha Operating System, Version V7.1

System Version Major ID/Minor ID: 3/0

System type: DEC 4000 Model 610

Crash CPU ID/Primary CPU ID:  00/00

Bitmask of CPUs active/available:  00000001/00000001

CPU bugcheck codes:
	CPU 00 -- UNXSIGNAL, Unexpected signal name in ACP

System crash information
------------------------
System State at Time of Exception
---------------------------------

Saved Scratch Registers in Mechanism Array
------------------------------------------
Mechanism array inaccessible.

CPU 00 Processor crash information
----------------------------------

CPU 00 reason for Bugcheck: UNXSIGNAL, Unexpected signal name in ACP

Process currently executing on this CPU: SYSTEM

Current image file: $1$DIA0:[SYS0.SYSCOMMON.][SYSEXE]NCL.EXE;1

Current IPL: 8  (decimal)

CPU database address:  80C10000

CPUs Capabilities:    PRIMARY,QUORUM,RUN

General registers:

R0   = 00000000.00000004  R1   = 00000000.00000003  R2   = FFFFFFFF.8147EC58
R3   = 00000000.00000003  R4   = 00000000.00000003  R5   = FFFFFFFF.8147ECA8
R6   = FFFFFFFF.83D05B90  R7   = FFFFFFFF.852FFE18  R8   = FFFFFFFF.80EA6D40
R9   = 00000000.00000002  R10  = 00000000.00000000  R11  = 00000000.00000000
R12  = 00000000.11030010  R13  = FFFFFFFF.852FFEE0  R14  = 00000000.00000418
R15  = FFFFFFFF.83D05000  R16  = 00000000.0000041C  R17  = 0000FE00.00007E04
R18  = 00000000.00000000  R19  = 00000000.00001DA4  R20  = 00000000.0000000D
R21  = 00000000.3A750040  R22  = FFFFFFFF.83D06AC8  R23  = 00000000.00000008
R24  = FFFFFFFF.83D05828  AI   = 00000000.00000001  RA   = FFFFFFFF.852F51D4
PV   = FFFFFFFF.852FFEE0  R28  = 00000000.00000001  FP   = 00000000.7FFA1F20
PC   = FFFFFFFF.852F16CC  PS   = 10000000.00000804

Processor Internal Registers:

ASN  = 00000000.0000003E                     ASTSR/ASTEN =          0000000F
IPL  =          00000008  PCBB = 00000000.06E56080  PRBR = FFFFFFFF.80C10000
PTBR = 00000000.0000051D  SCBB = 00000000.000001A4  SISR = 00000000.00000008
VPTB = FFFFFFFC.00000000  FPCR = 00000000.00000000  MCES = 00000000.00000000

CPU 00 Processor crash information
----------------------------------
	KSP    = 00000000.7FFA1C10
	ESP    = 00000000.7FFA6000
	SSP    = 00000000.7FFAC100
	USP    = 00000000.7AFB3570

                No spinlocks currently owned by CPU 00

>$ ana/crash HUMANE_CRASH.DMP
>VAX/VMS System dump analyzer

versus

>$ analyze /crash disk$kaka:[dumps]sysdump.dmp
>
>OpenVMS (TM) Alpha system dump analyzer

I don't think anyone ever mentioned what type of system this was.

--Scott

Thanks, Scott! I didn't realize OpenVMS VAX would react that way to an Alpha
dump, so I took the message at face value.

I've got it now...

John Saunders
DECdns Engineering

P.S. This required a V7.1 system.

Well, I finally found the answer to the question, "what does RESOURCEERROR
mean"? It seems to imply that a memory allocation failed.

Now, as to the crash, you're running SSB OpenVMS V7.1 and SSB DECnet-Plus V7.1,
so please submit an IPMT case on this as soon as you get a chance. In the
meantime, I'll make the dump available to people over here.

Thanks,
John Saunders
DECdns Engineering

> Well, I finally found the answer to the question, "what does RESOURCEERROR
> mean"? It seems to imply that a memory allocation failed.

What process is having this problem?  Is there something I can change to avoid
the problem?

> Now, as to the crash, you're running SSB OpenVMS V7.1 and SSB DECnet-Plus
> V7.1, so please submit an IPMT case on this as soon as you get a chance.

Will do.

Paul

I've looked in this conference for a half hour and can't find how to submit a
QAR.  Could someone post the node/username/password and proper database for
DECnet-Plus V7.1?

Paul

Since the QAR database is no longer on QAR1, this is a problem!  I have heard
that the database moved to BULEAN but have never seen any directions.

	David

Please submit this as an IPMT. If you do not already have an account, please
contact MSE1::KCARROLL to get one.

Thanks,
John Saunders
DECdns Engineering

Just so you know.  You cannot submit a QAR against a version which is shipping;
only FT versions can have stuff QAR'd.  At least that's how it now works with
DECnet.

now, this doesn't stop engineering from migrating level 3 IPMT's into the
QAR database; but we can only do that after agreement with the IPMT submittor.

Node name translations on HUMANE have started failing again with the

   DECdns returned "Message number 01DE864A"

messages.  I will gladly IPMT this problem, but perhaps someone would like
access to HUMANE to look around before I reboot it to solve the problem tonight?

Paul