Conference iosg::all-in-1_v30

4051.0. "OA$SCRIPT keeps stopping" by GIDDAY::JOYCE (Burn me kangaroo down sport) Wed Apr 06 1994 09:17

    
    
    
    
    
Folks,
    
I have a customer with the following problem.
    
    OA$SCRIPT_BRITISH queue appears to always stopped

When you start it with START/QUEUE starts ok but when it attempts to process a 
script it goes back into stopped.  Job remains on queue in Pending state.

According to customer it hasn't ever worked since they upgraded to V3.0 
They Did have a co-existant system and it worked then (they think).

I have checked;

i) 	the images IMP$IMPSHR and/or IMP$IMPSHRP are installed correctly.
	They are.
ii)	if a OA$SMB.COM still exists in SYS$LIBRARY (for co-existence). 
	It shouldn't and doesn't.
iii)	the queue set-up.
	It is;

Server queue OA$SCRIPT_BRITISH, stopped, on KAKADU::, mounted form DEFAULT
  /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) /NOENABLE_GENERIC
  /LIBRARY=BRITISH /OWNER=[SYSTEM] /PROCESSOR=OA$SCRIPT_SYMBIONT
  /PROTECTION=(S:E,O:D,G:R,W:W) /RETAIN=ERROR /SCHEDULE=(NOSIZE)
  	(IDENTIFIER=OA$G_ZUXX1H1GL,ACCESS=READ+EXECUTE)

iv)	the Id in the ACL is an ALL-IN-1 group with no members. I removed it
	but this made no difference.

v)	the A1$SCRIPT UAF record.
	LGICMD is a captive procedure.  I removed this.  No difference.
	JTQUOTA was 1024.  I increased it to 1800.  No difference.
	FLAGS=RESTRICTED.  I removed this.  No difference.

vii)	(getting desperate!) the operator console;
	The following messages appear;


%%%%%%%%%%%%% OPCOM 22-MAR-1994 10:05:58.13 %%%%%%%%%%%%
Message from user QUEUE_MANAGE on KAKADU
%QMAN-E-SYMDEL, unexpected symbiont process termination

%%%%%%%%%%%%% OPCOM 22-MAR-1994 10:05:58.13 %%%%%%%%%%%%
MESSAGE FROM USER QUEUE_MANAGE ON KAKADU
-SYSTEM-F-ACCVIO, Access violation, reason mask=00, virtual address=00000000,
PC=0001A540, psl=03c00000


Next, I talked the customer thru doing the following;

1) Create a file called OA$SMB.COM and place it in SYS$SYSTEM                 
   containing the following commands:                                         
                                                                              
   $ define sys$output sys$system:oa$smb.log                                  
   $ set verify                                                               
   $ !                                                                        
   $ ! Starting script slave                                                  
   $ !                                                                        
   $ allin1                                                                   
                                                                              
2) Now do the following to the script queue:                                  
                                                                              
   $ stop/queue/reset OA$SCRIPT                                               
   $ init/queue/dev=server/sep=res=oa$smb OA$SCRIPT                           
   $ start/queue OA$SCRIPT                                                    
   $ submit/queue=OA$SCRIPT <a test script>                                   
                                                                              
  The test can do something simple like:  
	
	.PAUSE 10
                                                                        
3) After the queue hangs you can look at the log file                         
   created in SYS$SYSTEM:OA$SMB.LOG. Have to STOP/QUE/NEXT first.

The tests result in an error something like;

	"Unknown error message number 80004BA4"

I cannot message number 80004BA4 in any of the msg files on the system, or in 
STARS or this conference.

Does anyone know what this error is?
Any other tests I can do?

Thanks,

Andy
CSC Sydney


    

    
    It seems that the culprit is the old "too many VMS indentifiers" problem.
    
    BUT...
    
    The STARS article (reproduced in part below) says the magic number is
    120 but my customer only (ONLY!?) has 86 ids granted to the ALLIN1
    account.  I tested from another account with no ids and the script
    symbiont did not spit the dummy.
    
    On my system, I did some extensive testing and found the MY magic
    number was 38, and it didn't matter if the ids were resource or not,
    and the length of the id names also did not appear to make any
    difference.
    
    So...
    
    1)	How come neither I nor my customer can get the magic 120?
    
    	and
    
    2)	Is there ANY sensible workaround (other than removing ids?)
    
    Thanks, 
    
    Andy 
    CSC Sydney 
    
    =========================================================================
    PROBLEM:                                                                      
                                                                                  
    When a user, whose VMS account has 120 or more rights                         
    identifiers associated, submits an ALL-IN-1 script to the                     
    script symbiont, the symbiont crashes.                                        
                                                                                  
    This causes the symbiont queue to stop and prevents any other                 
    user from submitting a script to the script symbiont.                         
                                                                                  
    CAUSE:                                                                        
                                                                                  
    The internal memory buffer used to hold the VMS rights                        
    identifiers of the submitter of a job to the ALL-IN-1 script                  
    symbiont is only large enough to hold 120 entries. More than 120              
    entries will cause the symbiont to crash and hence stop the VMS               
    queue that is serviced by that symbiont.