[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference clusta::acms

Title:	ACMS comments and questions
Notice:	This is not an official software support channel. Kits 5.*
Moderator:	CLUSTA::HALLAN

Created:	Mon Feb 17 1986
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4179
Total number of notes:	15091

4136.0. "BAD_PACKAGE_VER, package version does not match" by EWBV05::OHSHIMA (Yuichi Ohshima, System Support Tokyo) Mon Mar 31 1997 04:36

	Our customer had a following "%ACMS-E-BAD_PACKAGE_VER" error at  
	user written agent on submitter node when the logical name that 
	specify the ACMS application directory was changed on application node.
	The transaction is submitted from submitter node to application node
	by user written agent. This error only occurred on specific 
	application.

	In this case, ACMS application was not changed at all and the 
	application .ADB file that located at acms$adb_cache on submitter 
	node is same one(date/time stamp is same) that located on application 
	node. 

	The submitter node is one member of cluster(3 members) that have same 
	acms$adb_cache, and application node is also one member of cluster 
	(3 members) that have same acms$directory. The one submitter node
	did not encounter this bad package version error.
	
	This symptom seem to be disappeared after the agent program was 
	restarted. 

	We have following question.

	1) In case of issue "%ACMS-E-BAD_PACKAGE_VER, Package version does 
	   not match", is ACMS check only .ADB date/time stamp ?
	   Is there any other check item ?

        2) If the .ADB data/time stamp on the remote database differ s from 
	   the copy in the cache directory, ACMS will automatically copy it.
	   Is this automatic copy always executed if an up-to-date version of 
	   the .ADB file does not exsist ?

	   In this case, the remote all .adb files are accessible, if an 
	   up-to-date version of .ADB file does not exsist, ACMS can 
	   automatically copy the remote application .ADB to the submitter 
	   node subdirectory. Therefore, this bad package version error 
	   could not be appeared. Why this error appeared ?

	3) Is there any case that user agent program must be restarted 
	   even if the application was not changed at all ?

	Thank you,
	regards,
	Yuichi Ohshima.


SWLUP>list/sin=17-mar-1997
SWLUP           SWLUP Event Log Output Listing                  31-MAR-1997
15:24:36    ACMS SWLUP V4.1-0                   Page 1


--------------------------------------------------------------------------------

Event logged at: 17-MAR-1997 08:28:01.04

PID = 21400477    PC = 806D391C    PSL = 0000001B

Process UIC  : [202,010]
Process name : BG_LSC09302
Username     : BG09302
Image file   : DSA5:[BGV11_SYSROOT.][EXE]BG_LSC.EXE;4

%ACMS-E-BAD_PACKAGE_VER, Package version does not match

--------------------------------------------------------------------------------

Event logged at: 17-MAR-1997 08:28:01.04

PID = 21400477    PC = 806D391C    PSL = 0000001B

Process UIC  : [202,010]
Process name : BG_LSC09302
Username     : BG09302
Image file   : DSA5:[BGV11_SYSROOT.][EXE]BG_LSC.EXE;4

Hand = 003B7260  ENT MASK = 20001FFC
PSL = 0000001B  AP = 00000001  FP = 7F87F6E0  PC = 806D391C

SR2 = 003A7AE0
SR3 = 02916B50
SR4 = 02CBEFC4
SR5 = 02E729F0
SR6 = 02916B60
SR7 = 00000001
SR8 = 00FDA30A
SR9 = 0000003A
SR10 = 00000000
SR11 = 02CBEFBC
SR12 = 00000004
SR29 = 7F87F6E0

--------------------------------------------------------------------------------

Event logged at: 17-MAR-1997 08:28:01.04

PID = 21400477    PC = 806D391C    PSL = 0000001B

Process UIC  : [202,010]
Process name : BG_LSC09302
Username     : BG09302
Image file   : DSA5:[BGV11_SYSROOT.][EXE]BG_LSC.EXE;4

Hand = 003B7260  ENT MASK = 20003FFC
PSL = 0000001B  AP = 00000001  FP = 7F87F780  PC = 806C7914

SR2 = 00000003
SR3 = 00000000
SR4 = 7F87F9F0
SR5 = 009001F0
SR6 = 0006BE48
SR7 = 92C80620
SR8 = 00000001
SR9 = 00000000
SR10 = 00CE8010
SR11 = 00CE8004
SR12 = 00000000
SR13 = 92CC03D8
SR29 = 7F87F780

--------------------------------------------------------------------------------

Event logged at: 17-MAR-1997 08:28:01.04

PID = 21400477    PC = 806D391C    PSL = 0000001B

Process UIC  : [202,010]
Process name : BG_LSC09302
Username     : BG09302
Image file   : DSA5:[BGV11_SYSROOT.][EXE]BG_LSC.EXE;4

Hand = 00000000  ENT MASK = 20002008
PSL = 0000001B  AP = 00000001  FP = 7F87F960  PC = 8008A664

SR3 = 92CC04D8
SR13 = 008FE180
SR29 = 7F87F960

--------------------------------------------------------------------------------

Event logged at: 17-MAR-1997 08:28:01.04

PID = 21400477    PC = 806D391C    PSL = 0000001B

Process UIC  : [202,010]
Process name : BG_LSC09302
Username     : BG09302
Image file   : DSA5:[BGV11_SYSROOT.][EXE]BG_LSC.EXE;4

Hand = 00000000  ENT MASK = 20002000
PSL = 0000001B  AP = 00000000  FP = 7F87F980  PC = 80000304

SR13 = 087C8009
SR29 = 7F87F980

--------------------------------------------------------------------------------

Event logged at: 17-MAR-1997 08:28:01.04

PID = 21400477    PC = 806D391C    PSL = 0000001B

Process UIC  : [202,010]
Process name : BG_LSC09302
Username     : BG09302
Image file   : DSA5:[BGV11_SYSROOT.][EXE]BG_LSC.EXE;4

Hand = 00000000  ENT MASK = 200007FC
PSL = 0000001B  AP = 00000000  FP = 7F87FA00  PC = 008EE734

SR2 = 00016C98
SR3 = 00D0FBC4
SR4 = 7FFBF818
SR5 = 7FFBF938
SR6 = 00CE81B4
SR7 = 00CE8648
SR8 = 00000001
SR9 = 00CE81B4
SR10 = 00CE8010
SR29 = 7F87FA00

--------------------------------------------------------------------------------

Event logged at: 17-MAR-1997 08:28:01.04

PID = 21400477    PC = 806D391C    PSL = 0000001B

Process UIC  : [202,010]
Process name : BG_LSC09302
Username     : BG09302
Image file   : DSA5:[BGV11_SYSROOT.][EXE]BG_LSC.EXE;4

Hand = 00000000  ENT MASK = 20000000
PSL = 0000001B  AP = 00000000  FP = 7F87FA20  PC = 008EF194

SR29 = 7F87FA20

--------------------------------------------------------------------------------

Event logged at: 17-MAR-1997 08:28:01.04

PID = 21400477    PC = 806D391C    PSL = 0000001B

Process UIC  : [202,010]
Process name : BG_LSC09302
Username     : BG09302
Image file   : DSA5:[BGV11_SYSROOT.][EXE]BG_LSC.EXE;4

Hand = 00000000  ENT MASK = 2000FFFC
PSL = 0000001B  AP = 00000000  FP = 7F87FAC0  PC = 0006BE48

SR2 = 00010000
SR3 = 7F9A1DD7
SR4 = 7FFBF818
SR5 = 7FFBF938
SR6 = 7FF9C9E0
SR7 = 7FF9C9E0
SR8 = 7FF9C1F8
SR9 = 7FF9C400
SR10 = 7FF9D228
SR11 = 7FFBE3E0
SR12 = 00000000
SR13 = D50C9910
SR14 = 00000000
SR15 = 7F955DA0
SR29 = 7F87FAC0

T.R Title User Personal
Name Date Lines

4136.1 CLUSTA::HALL Bill Hall - ACMS Engineering - ZKO2-2 Mon Mar 31 1997 20:55 32

T.R	Title	User	Personal Name	Date	Lines
4136.1		CLUSTA::HALL	Bill Hall - ACMS Engineering - ZKO2-2	`Mon Mar 31 1997 20:55`	32
	This is not an easy set of questions to answer so I'll attempt to answer what I can. In a clustered environment, where all systems have access to all the disks, as long as ACMS$DIRECTORY points to a directory and disk that is accessible by all systems, then no caching will occur. The BAD_PACKAGE_VER refers to an internal check that is made on the ADB. As a result of an RPC call, the major and minor versions of the ADB are returned. ACMS checks to make sure that are the correct ones (I don't know exactly what they are). Is your customer changing the value of ACMS$DIRECTORY? If they are, they shouldn't be. When a new application is brought on-line, ACC is aware of this. When a ACMS$GET_PROCEDURE_INFO is sent to a remote ACC, the remote ACC will send the file spec and date/time of creation of the ADB. The local ACC will check to see if it already has a copy, either by looking in it's cache directory or accessing it remotely (if it can). If a mis-match occurs, then a copy will occur. If the problem you are encountering can be reproduced, then I can test it out here (you also have the sources locally). It may also be possible that the agent is corrupting it's local memory and may be causing this problem. Bill

    
    	This is not an easy set of questions to answer so I'll attempt
    	to answer what I can.
    
    	In a clustered environment, where all systems have access
    	to all the disks, as long as ACMS$DIRECTORY points to a
    	directory and disk that is accessible by all systems, then
    	no caching will occur. 
    
    	The BAD_PACKAGE_VER refers to an internal check that is made
    	on the ADB.  As a result of an RPC call, the major and
    	minor versions of the ADB are returned.  ACMS checks to make
    	sure that are the correct ones (I don't know exactly what
    	they are).
    
    	Is your customer changing the value of ACMS$DIRECTORY?  If they
    	are, they shouldn't be.  When a new application is brought on-line,
    	ACC is aware of this.  When a ACMS$GET_PROCEDURE_INFO is sent
    	to a remote ACC, the remote ACC will send the file spec and
    	date/time of creation of the ADB.  The local ACC will check
    	to see if it already has a copy, either by looking in it's
    	cache directory or accessing it remotely (if it can).  If
    	 a mis-match occurs, then a copy will occur.
    
    	If the problem you are encountering can be reproduced, then
    	I can test it out here (you also have the sources locally).
    
    	It may also be possible that the agent is corrupting it's
    	local memory and may be causing this problem.  
    
    	Bill