How to restart NET$ACP process

[Toine_1]

Hello,

How can I restart net$acp process on I64 without rebooting?

VMS version 8.1-1H1

NVR$ mc ncl sho impl

Node 0
at 2009-10-18-12:34:58.166+02:00Iinf

Characteristics

Implementation =
{
[
Name = OpenVMS I64 ,
Version = "V8.3-1H1"
] ,
[
Name = HP DECnet-Plus for OpenVMS ,
Version = "V8.3-1H1 ECO01 25-NOV-2008 14:31:42.62"
]
}

NET$ACP is using the latest DECC$SHR (used for SAMBA) but other gives problems to other applications.

Regards,

/Toine

[Volker Halle]

Toine,

to shutdown NET$ACP, you would have to completely shut down DECnet-Plus. This should work with the generic '$ STOP/NETWORK DECnet' command, but I would recommend a reboot, because some processes may still be using DECnet and will cause the DECnet shutdown to not complete.

What is the real problem ?

Volker.

[Toine_1]

Hi,

I will do a reboot.

The problem is that I installed SAMBA on a I64 server with the latest DECC$SHR.EXE
(9-apr-2009).

I have an other application on the same server that communicate via its DecNet address to PLC's.
This application is crashing.

The only thing that was changed was this Samba installation on this server.

Only NET$ACP is using this latest DECC$SHR.EXE

I can't force this process to use the old one.


Dump of the Application.

Improperly handled condition, image exit forced by last chance handler.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
00000000017B8000
000000000158B4E0
000000000000001B

Register dump:
R0 = 0000000000000000 R1 = 00000000017B8000 R2 = 0000000000001837
R3 = 00000000015CA920 R4 = 000000007FFCF818 R5 = 000000007FFCF8B0
R6 = 0000000010000001 R7 = 0000000000000001 R8 = 000000000F778009
R9 = 0000000000000000 R10 = 0000000000000003 R11 = 00000000000004C4
SP = 000000007ACB1590 TP = 00000000016E01C8 R14 = 4000000000000000
R15 = 0000000001518F80 R16 = 000000000176C004 R17 = 00000000017B8000
R18 = 0000000000000000 R19 = 0000000000000001 R20 = 0000000000000000
R21 = 00000000014225B0 R22 = 0000000001422630 R23 = 0000000000000000
R24 = 0000000001582BC0 R25 = 0000000000000001 R26 = 000000007ACB1598
R27 = 000000007ACB15A0 R28 = 000000007ACB15A8 R29 = 0000000001752160
R30 = 00000000015CF090 R31 = 00000000017BC400 PC = 000000000158B4E0
BSP/STORE = 000007FDBFFD42C8 / 000007FDBFFD42C8 PSR = 0000101308026030
IIPA = 000000000158B4D0
B0 = 00000000017BC400 B6 = 000000000158B440 B7 = 000000000158B450
Interrupted Frame RSE Backing Store, Size = 96 registers
R32 = 0000000000055920 R33 = 0000000000000001 R34 = 00000000000

/Toine

[Volker Halle]

Toine,

if you still have the 'old' DECC$SHR.EXE, you can copy it as a new version and INSTALL/REPLACE it. This will cause running processes to still use version ;-1, but newly created processes will use the highest version.

Volker.

[Volker Halle]

Toine,

maybe I misunderstand you: do you really believe, that your PLC communcation process is crashing, because NET$ACP is using the new DECC$SHR.EXE ?

Can you create a process dump of your PLC process (SET PROC/DUMP before running the image) and try to look at the stack and where/why it is getting this ACCVIO ?

Volker.

[Toine_1]

Hi,

I renamed the latest (included in the SAMBA patch) DECC$SHR.EXE rebooted the I64 server and now the my application process using a DecNet address is starting OK.

I was able to create a dump file of this process but can' analyze it.

NVR$ ana/proc mmscom.dmp/full

OpenVMS I64 Debug64 Version X8.3-015


%DEBUG-I-NODSTS, no Debugger Symbol Table: no DSF file found and
-DEBUG-I-NODSTIMG, no symbols in DISK$APPLDISK:[PRSYSDISK.SYS.EXE]MMSCOM.EXE;33
%DEBUG-W-IMAGENF, target image not found on host system
%DEBUG-E-INTERR, debugger error in DBGOPSYS\READ_LDRIMG: failed to read LDRIMG o
r session corruption

Logging enabled to file: DBGERR.LOG

If you wish to log a Debug problem report please include:

o This file.
o The operating system version number.
o The system type or types if using Client/Server mode.
o The program being debugged, both source and image.
o The last, if not all, debug commands entered.
o Any other information which you think would be helpful.

Debugger Version: OpenVMS I64 Debug64 Version X8.3-015

module name routine name line rel PC abs PC

Due to this internal error this debug session may be unreliable.

%DEBUG-E-INTERR, debugger error in DBGMAIN\SUB_CALL_KERNEL_RPC - error in kernel
routine GET_IMAGE_ENTRY or session corruption
%DEBUG-E-NOPROCESSES, the current command is targetted at an empty process set
DBG>

/Toine

[Volker Halle]

Toine,

I hope you're going to raise a couple of calls to HP on this one !

Shipping a DECC$SHR.EXE outside of an OpenVMS ACRTL patch is absolutely against all rules (at least those of the past) !

If SAMBA needs a specific DECC$SHR.EXE, one could still define some local logical name pointing to a SAMBA-specific DECC$SHR.EXE, but only in the context of the SAMBA process.

Please also report the ANAL/PROC problem.

Volker.

[Volker Halle]

Toine,

could you please document, exactly WHICH SAMBA version and patch you had installed and also the link date/time of the problematic DECC$SHR.EXE ?

Thanks,

Volker.

[Toine_1]

Hi Volker,

Thank you for your help.

I will report this to HP.

Process dump
============

The application that dumps is an AEST image. Perhaps it is not possible to do a ana/process on these dump files.

Version of SAMBA and DECC$SHR:
==============================

We are using this SAMBA version:
HP I64VMS SAMBA V1.1-1
With eco CIFSV11ECO1-PS009.

Version of DECC$SHR made for SAMBA.
===================================

$ ana/image decc$shr.exe/inter
This is an OpenVMS IA64 (Elf format) shareable image file

Image Identification Information, in section 8.

Image name: "DECC$SHR"
Global Symbol Table name: "DECC$SHR"
Image file identification: "V8.3-01"
Image build identification: "0080070034"
Link identification: "Linker T02-28"
Link Date/Time: 13-MAR-2009 06:21:41.30


Below you can find the CRTL kit info from CIFS engineering.

DECC_RELEASE_NOTES.TXT

This file contains the information for installing the CRTL image on top of the
latest available CRTL ECO kits. Note that this document is intended only as a
reference and is not an official document for the CRTL patch.

Before installing the necessary CRTL patch, you must ensure that the latest
CRTL ECO kit is installed on the system. The latest CRTL ECO for each of the
supported OpenVMS version is given below:

Kit Name OpenVMS Version Architecture
HP-I64VMS-VMS831H1I_ACRTL-V0300--4.PCSI$COMPRESSED 8.3-1H1 Integrity Servers
HP-I64VMS-VMS83I_ACRTL-V0700--4.PCSI$COMPRESSED 8.3 Integrity Servers
HP-I64VMS-VMS821I_ACRTL-V0400--4.PCSI$COMPRESSED 8.2-1 Integrity Servers
DEC-AXPVMS-VMS83A_ACRTL-V0500--4.PCSI$COMPRESSED 8.3 Alpha
DEC-AXPVMS-VMS82A_ACRTL-V0500--4.PCSI$COMPRESSED 8.2 Alpha

Note that, with one exception, the above CRTL ECO kits are present in the MASTER UPDATE ECO
kits released in March 2009. The only exception is the MASTER UPDATE ECO kit for OpenVMS
Alpha V8.3 - the CRTL kit DEC-AXPVMS-VMS83A_ACRTL-V0500--4.PCSI$COMPRESSED must be
installed separately.

After installing the latest MASTER UPDATE kit and/or the latest CRTL ECO kit, please follow
these instructions for installing the patch:

Execute:

$ copy DECC$SHR.EXE SYS$COMMON:[SYSLIB]DECC$SHR.EXE;/prot=(s:rwed,o:rwed,g:re,w:re)/log

$ install replace SYS$COMMON:[SYSLIB]DECC$SHR.EXE;

Verify that the correct version is installed by executing:

$ install list SYS$COMMON:[SYSLIB]DECC$SHR.EXE

CIFS Engineering

/Toine

[Volker Halle]

Toine,

thanks for the info. So you are talking about the decc_ia64_v831h1.zip file in the cifsvms-dependency sub-directory of the CIFS download directory.

Please also raise a call on the ANAL/PROC problem, beccause understanding that failure may be a key to understanding what seems to fail in NET$ACP with that DECC$SHR.EXE.

Volker.