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

Conference ucrow::desktop_acms

Title:DECtp Desktop for ACMS
Moderator:UCROW::GIBSON
Created:Mon Sep 24 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:859
Total number of notes:3034

821.0. "acmsdi server accvio - v2.0/alpha" by CSC32::J_HENSON (Don't get even, get ahead!) Wed Feb 12 1997 12:01

acmsdi v2.0, openvms for Alpha v6.1, acms v4.0a

A customer (McCaw Messaging) is reporting an access violation in
the acmsdi server.  They are seeing this occur every 3-6 days.
This problem only began occurring AFTER they installed eco
ALPSHAD12_061, and increased the size of the virtual i/o cache limit.

The swlup log for the accvio can be found at csc32::sys$public:acmsdi.txt.

If you need more information, please let me know.  I can provided
the eco summary of the above mentioned eco if you need it.

Please advise,

Thanks,

Jerry
T.RTitleUserPersonal
Name
DateLines
821.1more information neededUCROW::KNEELANDThu Feb 13 1997 11:2621
Jerry,

Please provide ECO summary.  

Have they been running on OpenVMS Alpha right along?   
How many users are typically signed in? 

We'll also need an image dump on there system to determine 
where in the code the problem occured as shown below:

SDA> set process acmsdi$server
SDA> show process/image
SDA>

Realize that this isn't an official support channel, and
that you should probably submit an IPMT case (p3) on this
one.

Colette


821.2CSC32::J_HENSONDon't get even, get ahead!Fri Feb 14 1997 09:4434
>>                      <<< Note 821.1 by UCROW::KNEELAND >>>
>>                          -< more information needed >-



>>Please provide ECO summary.  

See next reply.

>>Have they been running on OpenVMS Alpha right along?   
>>How many users are typically signed in? 

>>We'll also need an image dump on there system to determine 
>>where in the code the problem occured as shown below:

>>SDA> set process acmsdi$server
>>SDA> show process/image
>>SDA>

I'll get this information asap and post it when I have it.

>>Realize that this isn't an official support channel, and
>>that you should probably submit an IPMT case (p3) on this
>>one.

I'm aware of that, but find that using the notes conference for the
initial query on a product issue can often save a lot of time, grief and
expense.  I was hoping it might be a known issue that has already been 
addressed.  I can ipmt this if you wish, but should we ask/require
that they upgrade to the current version first?

Thanks,

Jerry
821.3alpshad12_061 eco summaryCSC32::J_HENSONDon&#039;t get even, get ahead!Fri Feb 14 1997 09:45158
*OpenVMS, STORAGE] ALPSHAD12_061 Alpha V6.1 Shadowing ECO Summary

     Any party granted access to the following copyrighted information
     (protected under Federal Copyright Laws), pursuant to a duly executed
     Digital Service Agreement may, under the terms of such agreement copy
     all or selected portions of this information for internal use and
     distribution only. No other copying or distribution for any other
     purpose is authorized.

 
Copyright (c) Digital Equipment Corporation 1996.  All rights reserved.

PRODUCT:    Volume Shadowing for OpenVMS Alpha

OP/SYS:     OpenVMS Alpha 

COMPONENT:  Shadow Driver 

SOURCE:     Digital Equipment Corporation

ECO INFORMATION:

     ECO Kit Name:  ALPSHAD12_061
     ECO Kits Superseded by This ECO Kit:  ALPSHAD11_061
                                           ALPSHAD10_061 
     ECO Kit Approximate Size:  1062 Blocks
     Kit Applies To:  OpenVMS Alpha V6.1, V6.1-1H1, V6.1-1H2
     System/Cluster Reboot Necessary:  Yes
     Installation Rating:  2 -  To be installed on all systems running
                                the listed version of OpenVMS and
                                using the following feature:
                                Volume Shadowing.

     NOTE:  In order to receive the full fixes listed in this kit,
            the following remedial kits also need to be installed:

                 ALPSHAD09_061


ECO KIT SUMMARY:

An ECO kit exists for Volume Shadowing on Alpha V6.1 through 
V6.1-1H2.  This kit addresses the following problems: 

Problems Addressed in ALPSHAD12_061:

  o  During a Bad Block Recovery operation, if the source member of
     the shadow set cannot be found by the SHDRIVER, a SHADDETINCON
     system crash will occur.


Problems Addressed in ALPSHAD11_061:

  o  An application I/O doing either a read or a write may fail.
     This can occur even though only one member of a multiple 
     member shadow set is unable to complete the requested I/O.  
     This results in the shadow set members being removed from the 
     set.  The I/O will be returned to the application with the 
     appropriate read or write error.

  o  Due to an incorrect recorded MSCP flag field, segmented I/Os 
     fail with invalid MSCP modifiers errors.

  o  Due to various code problems ,queue corruption, IRPs on 
     inappropriate queues, ACCVIOs, SHADDETINCON bugchecks, 
     and incorrect/inconsistent queue_fl and queue_bl pointers 
     in elements may occur.

  o  Excessive but allowable system process quota limits (PQL
     parameters) can cause a shadow server process to be created
     that is not able to perform the task for which it is intended,
     specifically, shadow set copies and merges.  Depending on 
     the system parameters, the process may exit or it may enter a
     resource wait state and never transition to a useful state.

  o  Many I/Os that complete with errors have extraneous information 
     in the second longword of the IOST/IOSB.  If the I/O is a data 
     transfer I/O, this may be interpreted as a transfer count.  
     Most products investigated see the error and ignore the transfer 
     count.  However, there may be applications that interpret the  
     transfer count as "this many bytes processed before the error 
     occurred" which is incorrect.

  o  A system may crash with a REFCNTNEG bugcheck during shadow set
     copy/merge operations.

  o  A system may crashes with an INVEXCEPTN bugcheck if a shadow set
     member is write-protected and a write to that member is attempted.

  o  A node may hang due to no quorum after losing its connection to
     the quorum disk.

  o  Layered drivers (e.g., Host-Based Raid) error recovery mechanisms   
     require the DUDRIVER interface to allow improved reliability.

  o  If a system disk is mounted in the cluster as a data disk and
     a system is booted from a non-master member, the system will
     crash with a SHADDETINCON crash in SHSB$READ_SCB.

  o  A SHADZEROMBR bugcheck may occur during an attempt to determine  
     if there is a valid source member of the shadow set that could 
     become the master.

  o  If an Alpha system disk is mounted on a different Alpha system  
     as a data disk and the first Alpha crashes and reboots more 
     than once, the Virtual Unit UCB$L_RWAITCNT field on the second
     Alpha system will go negative.  This will hang access to the
     second Alpha's device.

  o  The system will crash with an ACCVIO in SHSB$CANCEL_IRP_CHEC
     if a 'STOP PROCESS/ID=' command is issued to a process that 
     has IO outstanding to a shadow set.

  o  A shadowing crash may occur with the VCB address used as the
     UCB address, when the shadow set has no member with the master 
     bit set in SHAD$B_MBR_STATUS.

  o  A system crash may occur when an attempt is made to mount 
     a write-protected source member.


Problems Addressed in ALPSHAD10_061:

  o  Sometimes a multiple member system disk shadow set does 
     not correctly complete a merge operation.  The merge
     is aborted but the shadow set is marked as though the 
     merge had completed.  If the virtual unit does not exist 
     when the system is booted, this problem will not be 
     encountered.

  o  A SHADZEROMBR bugcheck can occur even though there are
     valid source members in the shadow set.


RELATED ARTICLES:

Detailed articles describing the problems listed above may exist in
the STORAGE or OPENVMS database.  To view these articles, open
the appropriate product database and perform a query using either of
the following search strings: 'ALPSHAD12_061' or 'ALPSHAD'. 
 

ECO KIT ORDERING INSTRUCTIONS:

If after an evaluation you wish to obtain this kit, request it
electronically using the appropriate Advanced Electronic Services
(AES) Service Tool.  If you are not familiar with how to request
kits electronically, open the DIA, WIS or DSNLINK database and
review the article entitled: 

     [AES] How To Electronically Request ECO Kits Using Service Tools


INSTALLATION NOTES:

In order for the corrections in this kit to take effect, the system
must be rebooted.  If the system is a member of a VMScluster, the 
entire cluster should be rebooted. 
821.4problem unknownUCROW::KNEELANDSun Feb 16 1997 17:397
    
    Unfortunately I can't tell if this is a known problem without
    the image information.  However, we would advise keeping current
    whenever possible, especially given V2.3 release is just around
    the corner.  
    
    Colette
821.5upgrade to V2.2-1 requested...UCROW::KNEELANDTue Feb 18 1997 15:5469
Jerry,

Please have them upgrade to V2.2-1.  I enclosed
the ECO1 location and release notes.

Thanks,

Colette

V2.2 ECO1 location:  UCROW::acms_desktop$pubdir:[v22.eco1.alpha_v6]

Release notes for ACMS Desktop V2.2 - ECO1 kit
----------------------------------------------

New file added:

    ACMSDI_ECO_LEVEL.dat is now placed in sys$system. This file
    contains information on the current ECO level applied to the 
    installed version of ACMS Desktop.

ACMS Desktop V2.2 ECO1 kit was issued to correct a number of problems in the
ACMS Desktop server.

Bugfix 1
--------

Corrects a possible ACMS Desktop server access violation that occured while
incorrectly attempting to access protected memory. It could happen on an 
initial task call after user sign or while processing an exchange step. 
It appears to be infrequently encountered and dependent upon memory allocation
patterns. It was due to a procedure using a descriptor string as a C string. 

The following procedures, from inner to outer, are involved and the module 
names might be visible in the dump file.

    Image		module		    procedure
    -----		------		    ---------
    CRTL image		-		    sscanf
         "		user_devices	    acmsdi$$device_find_owner
    acmsdi$server_shr	server_io_path	    acmsdi$$io_path_create

Bugfix 2
--------

A number of consistency checks have been added to protect against access
violations that could occur when converting an internal object handle into a 
structure reference when the handle or structure was inconsistent. A possible  
cause of an inconsistent handle is a the unexpected termination of a client.

Bugfix 3
--------

A change to the RPC marshalling code to correct a sign extension problem that
resulted in a memory leak on the server side when using large optimized 
workspaces. The memory leak could result in the failure and termination of the
ACMS Desktop server process. 

Bugfix 4
--------

The Alpha version of the kit places an updated acmsdi$msg.exe file in the
sys$message directory to correct some low level server log messages. 

Install:

    @sys$update:vmsinstal ACMSDI_VAX5_ECO01  kit-dir: ! VAX/OpenVMS V5.n
    @sys$update:vmsinstal ACMSDI_VAX6_ECO01  kit-dir: ! VAX/OpenVMS V6.n
    @sys$update:vmsinstal ACMSDI_ALPHA_ECO01 kit-dir: ! Alpha/OpenVMS V6.n