Pathworks server exiting

[Paul Taylor_6]

Running OpenVMS v7.2 cluster and Pathworks/AS v6.0-320C.

Having problems with Pathworks process PWRK$LMSRV crashing and logging a DMP file. VMS reports the message below to the console. Unfortunately the original LMSRV LOG file has been overwritten and only info I've been given is that it MAY have been reporting an ACCESS VIOLATION message of some kind. Apologies for being so vague, but would appreciate any assistance anyone can bring to bear and any suggestions as to what the cause may be.

%%%%%%%%%%% OPCOM 6-JAN-2005 12:42:14.27 %%%%%%%%%%% (from node cccccc at 6-JAN-2005 12:42:15.72)
Message from user SYSTEM on cccccc
Server exiting because of fatal error,See audit log and process log files for details

[Paul Taylor_6]

LMSRV just crashed again on me.

I've attached a copy of the relevant log file.

I could really do with some ideas...

[Ian Miller.]

could be a quota probem. I see in the log file PCS_xfr_open2: unexpected VMS status error! (00000294) and
exit 294
%SYSTEM-?-INSFMEM, insufficient dynamic memory

[Ian Miller.]

unless thats hex 294 which is
%SYSTEM-F-REJECT, connect to network object rejected

[Ian Miller.]

Parhaps the SAM is corrupt - try

$ @sys$startup:pwrk$define_commands
$ samcheck -s

[Paul Taylor_6]

Thanks.

Tried running a samcheck and it doesn't look overly healthy (see attachment). Any further suggestions based on this?

The VMS nodes are running as BDCs within a domain with a Win 2000 PDC

Also picking up on your initial responses, would you suggest taking a look at any specific quota parameter?

[Uwe Zessin]

I wouldn't play with quotas but fix the SAM and then look if the process keeps crashing. Honestly, I beleive that anything else is a waste of time.

[Paul Taylor_6]

Apologies for my ignorance, but how do you go about fixing the SAM?

[Uwe Zessin]

I apologize, but I have no idea, too. I just wanted to point out that I think it does not make sense trying to work around a corrupted system.

You have choosen a meaningful subject - I hope this triggers the attention of somebody from HP if nobody else has an idea.

[John Gillings]

Paul,

samcheck -s should repair corruption - try repeating the command.

There should be a backup SAM somewhere in PWRK$ROOT:[LANMAN.SAMSAVE]. If the samcheck doesn't work, try restoring the backup.

If all else fails, you may need to reconfigure Advanced Server from scratch, creating a new SAM and redefining all your shares.

[Paul Taylor_6]

I've retried SAMCHECK -S but it hasn't changed matters.

What precise file(s) are verified with the SAMCHECK utility?

Most likely solution I've seen suggests the following steps:

1. Take copies of the following files from PWRK$ROOT:[LANMAN.DATFILES]
ACL.
SHAREDB.
LSA.

2. Perform PWRK$CONFIG and opt to put servers into new domain as PDCS & restart.
(this creates clean config including new SAM)

3. Shutdown PWorks

4. Perform another PWRK$CONFIG and opt to put servers back into original domain as BDCs BUT DO NOT RESTART.

5. Restore copies of 3 files above and then restart PWorks

6. When next automatic replication from WIN 2000 PDC takes place, it takes place successfully to empty, but non-corrupt SAM

This way, all original shares info - and presumably other important stuff - is preserved as it's contained in a combination of SHAREDB, LSA & ACL.

SAM info is presumably contained in another file - whose name I can't be sure of - but which must be re-created when step 2 above is executed.

It all sounds sensible, but as I say, I'd very much appreciate further confirmation in case I'm missing something...

[Edwin Gersbach_2]

SHAREDB. = Share database
ACL. = Share permissions
LSA. = Explicit hostmaps

The file name of the actual SAM is the same as your domain name and is located in the directory PWRK$LMDOMAINS:

The script you show above matches the one I used in those situations. Since we run 7.3A in our W2K environment we never had any problems. The backdraw is that knowledge begins to vanish ;-)

[Antoniov.]

Paul,
you can use ADMIN/CONFIG command to check system quotas needing before rebuild sam database.

Antonio Vigliotti

[Paul Taylor_6]

Thank you to all contributors.

Rebuild of SAM using the above script seems to have stopped the crashes for now. However even after rebuild, SAMCHECK still reports inconsistencies with new SAM, though far fewer than beforehand. Looks as though we'll not be able to avoid an upgrade - and new license costs - for much longer...

[Paul Taylor_6]

See previous reply for final status