Conference iosg::all-in-1_v30

1740.0. "Controller error on running ALL-IN-1" by KERNEL::OTHENJ () Mon Nov 09 1992 13:30

Hi,

	A customer has a very strange problem using ALL-IN-1 v3.0 on a 
non-DEC contoller. The controller is a DILOG DQ696, and I cannot really get 
a definite statement from anyone as to whether this controller is 
supported. This problem did not occur using ALL-IN-1 v2.4.

	When the users call up ALL-IN-1, they do not see any errors, but an 
error is logged in the error logger for the controller each time. This 
makes the performance of the controller very bad for the customer. The only 
way that you can see the error is by using set watch file/class=major 
before calling ALL-IN-1. Below is the output;

GRFH4 3.0> alli
%XQP-I-FUNCTION, Lookup  (1699,42,0) Status: 00000001
%XQP-I-FUNCTION, Access SITEMEMRES.FLB;18 (1699,42,0) Status: 00000001
%XQP-I-FUNCTION, Physical read  (1699,42,0) Status: 00000054
%XQP-I-FUNCTION, Deaccess (1699,42,0) Reads: 1, Writes: 0, Status: 00000001
%XQP-I-FUNCTION, Access SITEMEMRES.FLB;18 (1699,42,0) Status: 00000001
%XQP-I-FUNCTION, Lookup  (1723,82,0) Status: 00000001
%XQP-I-FUNCTION, Access MEMRES.FLB;2 (1723,82,0) Status: 00000001
%XQP-I-FUNCTION, Physical read  (1723,82,0) Status: 00000054
%XQP-I-FUNCTION, Deaccess (1723,82,0) Reads: 1, Writes: 0, Status: 00000001
%XQP-I-FUNCTION, Access MEMRES.FLB;2 (1723,82,0) Status: 00000001
%XQP-I-FUNCTION, Access PROFILE.DAT;1 (2346,3,0) Status: 00000001
%XQP-I-FUNCTION, Lookup PROFILE.DAT;1 (2346,3,0) Status: 00000001
Username ALLIN1 is not in the user profile
Enter your username:
GRFH4 3.0> exit %x00000054
%SYSTEM-F-CTRLERR, fatal controller error

	The VMS group have found that this error is due to an 'odd byte 
count on physical read'. They have written a program odd_io which does the 
same, and causes the same error.

GRFH4 3.0> run odd_io
%SYSTEM-S-NORMAL, normal successful completion
%SYSTEM-S-NORMAL, normal successful completion
Iosb 54, 0, 0, 0

	Has the code been changed so that odd byte counts on physical read 
are used, as this particular controller does not recommend this (don't ask 
me why!!). If the code has been changed, has it been changed in only 
certain situations, and for what reason was it changed?

	This problem is causing the customer a lot of grief at the moment, 
so a prompt reply would be much appreciated.

	Thanks,
			Julie
    

This is a known problem.  Unfortunately (for you) the required fix is in
uncustomisable base code.

To quote the immortal words, it "may be considered for inclusion in a possible
future release or patch".

The moderation policy of this conference does not allow me to say any more...

Scott

Hi Julie,
	  There has been a problem with running ALL-IN-1 3.0 on some third party
controllers.  Disk errors are sometimes logged when a user initializes ALL-IN-1.
Iain Voller in all of his greatness has devised a workaround for this problem. 
The fix involves putting a module in OALIBR and relinking ALL-IN-1.  We had the
same symptoms on a customer site.  After relinking with the new module, the 
errors stopped.  Contact the Atlanta CSC or myself through VMSmail if you 
would like to obtain this module.  

Paul

    Julie,
    
    Yes this is the well known disk-controller problem as was found
    diagnosed and fixed by the Atlanta CSC - It is encouraging to see that 
    an Engineer (.1) is now showing interest in the problem (:==:) and the
    fix may therefore be considered for inclusion in a PFR.
    
    I believe also that my colleague Mr Morabito meant to ask you to
    contact us using ALL-IN-1 mail and not VMSmail as he appears to have
    mistakenly typed in reply .2!.
    
    The code-level fix that we have available has already been deployed
    successfully at a number of sites - see note 1601 for more info.
    
    Regards,
    
    Andrew.D.Wicks