Conference clusta::acms

    
    ACMPAR is the parameter file used by ACMSGEN.  It sounds like you
    have an invalid one that ACMS is attempting to use.  During the
    installation, the procedure asks whether you want to convert
    any old ones.
    
    You can always create a new one by invoking ACMSGEN and then do
    a WRITE CURRENT.  Then, exit ACMSGEN and start it up again and
    you should have a current one, setup with all the DEFAULT values.
    
    	Bill
    

    Thanks Bill, that can explain a symptom we meat: acmsgen showing all 
    values as 0.

    Note that this command doesn't report any error. User receive that error
    while trying to sign in. E.g. using ACMS/ENTER (new from today). 

    So I wonder how the ACMS can start without error and suddenly generates it.
    And once it starts, it only does so.

    I suspect they perform strange things with their environment. So just a
    small question: while trying to access the ACMS parameters file, does it
    read the sys$system:acmpar.acm or does it read something else (e.g. a 
    global section).

  Mich�le.

    
    	When ACMS starts up, it creates a global section and reads in
    ACMPAR.ACM.  This assumes that the global section does not already
    exist (which it can if someone is using the task debugger).
    
    Bill
    

  

   It doesn't make it simpler. So let me imagine the scenario:

   - at ACMS startup (no debugging session on that system), the ACC creates the 
     ACMS$PARAMETERS global section and fill it with with the data of 
     ACMSPAR.ACM.

   - all other images accessing ACMS, i.e. ACMS/SHOW commands, process signing  
     in, ... map to that global section to load the data (then unmap ?)

   - for any reason, at a given moment, this global section is being corrupted 
     Or deleted, as I start to suspect it ?! Or not mappable for any reason !

   - any process that try to map to the global section gets an error and
     returns the INVACMPAR (?). Unless ACMSGEN, that can run without ACMS and 
     that simply displays null values if the global section is not there (???).

   Does this make sense ? Best,
   Mich�le.

    
    	The global section (ACMS$PARAMETERS) is actually created by ACMSOPR
    when the ACMS/START SYSTEM command is issued.  OPR creates this global
    section as a temporary global section.  ACC is then created using the
    ACC_USERNAME from this global section.  ACC maps the global section
    and uses the information contained in it to startup the rest of the
    system.  Id the command is ACMS/START SYSTEM, then ACC creates the TSC,
    the TSC maps the global section and uses information in it to create
    the CP processes.
    
    	As the ACMS system comes down, the global section remains mapped
    until the last process exists, this is the ACC.  VMS then deletes the
    global section because of the 'temporary' flag and the fact that the
    reference count is now 0.
    
    	The only other program that can write to this global section is
    ACMSGEN and it can only modify the active parameters.
    
    	Bill
    

>> The only other program that can write to this global section is
>> ACMSGEN and it can only modify the active parameters.
    
This surprises me given what we saw on the system: we put a security audit on
the ACMS$PARAMETERS in order to check what gain write access to it, and it
appeared that ALL processes of the ACMS sub-system map to it in WRITE. So, the
problem is generally first descovered by a starting server process which then
aborts with one or another error code.

Finally, this attempt doesn't help me very much, because 1�) it doesn't generate
an alarm while writing to it, 2�) it only controls access to the
SYSTEM_GLOBAL_SECTION object, and not to the effective memory zone. 

Last time the problem happened, we saw other strange things, like ridiculous
refcount. Looking further for this, I'd like to write a small program looking to
the values in the global section. Can you provide me with its description or
some hints about its structure, so that the program can check it is still valid?

Thanksin advance,
Mich�le.

    
    
    	While the global section may be mapped for write, the only writer
    	is ACMSGEN.
    
    	What platform/version info are we talking about here?  I'd
    	rather not give out the specifics of what the global section
    	looks like.  If this problem just started to occur, I'd start
    	looking at any new code put into production.  Since the global
    	section is mapped as system, any code with enough privs can
    	map to it also.  The name of it can be found pretty easily
    	by someone with privs.
    
    	This problem is not going to be solved in the notesfile.
    
    	Bill
    

Thanks Bill for your answer.

I'm still trying to clean this environment up as I effectively suspect an
accidental write to the global section (their server processes are written in C!)

Once I've something cleaner, I'll escalate the problem.

In any case, thank you once more,
Mich�le.