Jump to page titleUNITED STATES
hp.com home products and services support and drivers solutions how to buy
» contact hp


more options
 
hp.com home
End of Jump to page title
HP Services Software Patches
Jump to content


» software & drivers
» ask Compaq
» reference library
» forums & communities
» support tools
» warranty information
» contact support
» parts
» give us feedback

patches by topic
» DOS
» OpenVMS
» Security
» Tru64 Unix
» Ultrix 32
» Windows
» Windows NT

associated links
» what's new
» contract access
» browse patch tree
» search patch tree
» join mailing list

connection tools
» nameserver lookup
» traceroute
» ping


Find Support Information and Customer Communities for Presario.
Content starts here
OpenVMS ALPF11X06_071 Alpha V7.1 - V7.1-1H2 F11BXQP ECO Summary
TITLE: OpenVMS ALPF11X06_071 Alpha V7.1 - V7.1-1H2 F11BXQP ECO Summary
 
Modification Date:  07-OCT-1999
Modification Type:  Updated Kit:  Supersedes ALPF11X05_071

NOTE:  An OpenVMS saveset or PCSI installation file is stored
       on the Internet in a self-expanding compressed file.
       The name of the compressed file will be kit_name-dcx_vaxexe
       for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha.
 
       Once the file is copied to your system, it can be expanded
       by typing RUN compressed_file.  The resultant file will
       be the OpenVMS saveset or PCSI installation file which
       can be used to install the ECO.
 
Copyright (c) Compaq Computer Corporation 1998, 1999.  All rights reserved.

OP/SYS:     OpenVMS Alpha 

COMPONENTS: F11BXQP 
            FILESERV
            VMS$CONFIG-050_CACHE_SERVER.COM

SOURCE:     Compaq Computer Corporation

ECO INFORMATION:

     ECO Kit Name:  ALPF11X06_071 
     ECO Kits Superseded by This ECO Kit:  ALPF11X05_071 
                                           ALPF11X04_071 
                                           ALPF11X03_071 
     ECO Kit Approximate Size:  990 Blocks
     Kit Applies To:  OpenVMS Alpha V7.1, V7.1-1H1, V7.1-1H2 
     System/Cluster Reboot Necessary:  Yes
     Rolling Re-boot Supported:  Yes
     Installation Rating:  INSTALL_1
                           1 - To be installed on all systems running
                               the listed version(s) of OpenVMS.

     Kit Dependencies:

       The following remedial kit(s) must be installed BEFORE
       installation of this kit:

         ALPBASE02_071 or later 

       In order to receive all the corrections listed in this
       kit, the following remedial kits should also be installed:

         ALPSYSA03_071 or later


ECO KIT SUMMARY:

An ECO kit exists for F11BXQP on OpenVMS Alpha V7.1 through V7.1-1H2.
This kit addresses the following problems: 

Problems addressed in ALPF11X06_071:

  o  The ALPF11X05_071 installation checks to see if both the
     ALPY2K01_071 and ALPBASE02_071 kits are installed.  If not,
     the installation fails.  The ALPBASE02_071 remedial kit
     includes the ALPY2K01_071 functionality.  Therefore, the 
     check for the ALPY2K01_071 kit is redundant and unnecessary.

     This kit corrects this problem by only checking for the
     ALPBASE02_071 kit.  There are no functional changes in this
     kit.  If you have installed the ALPF11X05_071 kit, you do 
     not need to install this kit.

Problems addressed in APF11X05_071:

  o  When two processes access a file via the MOVEFILE and
     READATTR/FID_TO_SPEC mechanism, both processes try to delete
     the 'primary_fcb' used to get the information in question.
     This causes a NOTFCBFCB bugcheck to occur.

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  If a process attempts to mount a bound volume set (BVS)  
     and all the members of the BVS are not present, an attempt 
     to lock the volume for REBUILDing the meta-data on the volume 
     will fail.  However, the blocking lock (F11B$b) is left 
     with the process.

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  An XQPERR bugcheck in LOCKERS can occur when the retry  
     limit on the F11B$x lock is reached.

     This problem can occur when:

       1.  The owner of the $x lock is running at a high process
           priority; and

       2.  A number of processes are in a clustered system are also
           trying to validate this lock, but at a lower process
           priority.

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  After releasing the current process' IPL/Fork lock, a system 
     can crash with a SPLACQERR bugcheck

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  A directory file becomes "corrupt" and DUMP/DIRECTORY
     displays a block similar to the following:

       Virtual block number 3574 (00000DF6), 512 (0200) bytes
       0000  Directory Entry:
       0000    Size:             508

         0002    Version limit:    32767
         0004    Type:             0  (FID)
         0005    Name count:       24
         0006    Name:             COSLR1201_01_JUPICC2.LIS
         001E    Version:  7859    FID:  (40993,5,0)
         0026    Version:  7858    FID:  (40990,1,0)
         002E    Version:  7857    FID:  (40988,3,0)
         ...
         01E6    Version:  7802    FID:  (40455,1,0)
         01EE    Version:  7801    FID:  (40454,1,0)
         01F6    Version: 32767    FID:  (16744447,65535,0)
         01FE  End of records (-1)

       The directory shuffle code creates the above  erroneous
       directory entry for a couple of reasons:

         1.  So that a new directory buffer will have a valid structure
             (this allows VALIDATE_DIRBLK to write the block to disk)

         2.  So that the entry will be spotted as bogus (via VERIFY) if
             we crash in the middle of this shuffle.

       After the directory block (with the eroneous directory entry)
       is written to disk, the bad entry is removed.  A subsequent
       call to READ_BLOCK assumes that the block comes from the
       buffer cache and not from disk.  Under heavy load, this
       assumption may not be true as the directory block may have
       been kicked out of the cache.

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  Update the conversion of the ODS-1 date field to comply  
     with the RSX-11 version of date handling.  Note that this 
     change is for the obsolete string format dates of DDMMMYY 
     of RSX and do not affect the 64 bit binary date stored on disk.

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  Under the following circumstances:

       1.  A directory with multiple headers (from a large ACL for
           example) is deleted on one node (A) in a cluster and

       2.  the directory had been previously accessed on another node
           (B) in the cluster

     The files created with the previously deleted headers in step
     1 would show up on node B with the error:

       %SYSTEM-F-NOSUCHFILE, no such file

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE


Problems addressed in APF11X04_071:

  o  A reserved operand fault bugcheck occurs on a $QIO exit.

     During the mounting of the system disk, the error message that
     the disk is mounted with a reduced cache is suppressed.  Hence, 
     the System Manager may be unaware that the performance of the 
     system disk and all others attached to the same cache block is 
     questionable.

     Image Affected:  [SYSEXE]FILESERV.EXE
 
  o  When deleting a large file (such as a system dump file), a
     UNXSIGNAL Bugcheck may occur.  This particular bugcheck occurs
     because a variable in the code causes a reference to memory
     data that the file system does not own and an internal access
     violation occurs (ACCVIO).

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  On some systems with higher rates of system paging or with
     WSDEC set to a non-standard value, a system can crash with a
     PGFLIPLHI (Page Fault IPL too High) bugcheck.  This problem
     happened when the system returns from a SMP$ACQUIRE call.

     Image Affected:  [SYS$LDR]F11BXQP.EXE  

  o  An XQPERR can occur in the RDBLOK module during disk cleanup
     using DCL.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  When storing the value of a directory index buffer, the system
     may crash with a PGFLIPLHI, SSRVEXCPTN error.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  A dismount on a shadowded device results in an unnecessary
     copy.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  An XQPERR bugcheck (crash) in the RETURN_CREDITS module can
     occur during DISMOUNT.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  An XQPERR Bugcheck (crash) in XQP can occur during a SET ACL
     (SET FILE/ACL) operation.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  When two processes are competing to dismount a volume, one
     process may be just a bit faster than the other and delete the
     VCB and other structures before the second process has time to
     finish up its processing.  The result is a UNXSIGNAL/ACCVIO 
     crash.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  A device reporting a read error (SS$_PARITY) during read/write
     processing in the XQP will attempt to record the bad blocks
     and FID in the BADLOG.SYS file.  When the internal close
     operation occurs (on BADLOG), the system XQPERR bugchecks 
     when it finds the process's dirty buffers have not been 
     written out.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  A UNXSIGNAL/ACCVIO error can occur at module F11BXQP.  This
     problem occurs during mount, when the primary volume is not
     yet mounted.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  Processes can hang (deadlock) when dismounting a device.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  A 'no such file' error can occur on directory extension FCBs.

     This problem can occur in at least two ways:

       1.  A file appears normal on one node but has an 'no such
           file' error from another node.

       2.  BACKUP or DUMP /HEADER encounters a read attributes  
           error of NOSUCHFILE.  This error occurs when an attempt 
           is made to read a file header, for which the FCB for the 
           old header is still in memory.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  Occasional false end-of-file (EOF) errors can occur on a read
     operation.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  The XQP fails after an IO$_DEACCESS call with an SS$_BADPARAM
     error.  One cannot determine whether a file is still open or
     not due to the failed IO$_DEACCESS call.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  Non-privileged users can change the revision date (and count)
     of a file for which they should have only READ access.  For
     example, if a non-privileged user with READ-only file access
     tries to set the file protection, a failure occurs with an
     SS$_NOPRIV error as expected.  However, the revision date (and
     count) are modified.

     Image Affected:  [SYS$LDR]F11BXQP.EXE


Problems addressed in APF11X03_071:

  o  An XQPERR bugcheck error, "all the index buffers are active",
     occurs when running with a reduced cache or during a backup.

  o  An XQPERR bugcheck error, "wrong lock basis with FCB present",
     occurs when files with ACLs are created on a full volume.

  o  It is possible to serialize on the wrong volume in a volume set.

  o  If more than one process queues for a volume's activity
     blocking lock, the XQP can deadlock.

  o  Various XQPERR bugchecks occur in directory scanning/shuffling.

  o  A crash may occur during creation of a file with a version
     limit of 1 if SYSTEM_CHECK is on or bit 5 or 6 of ACP_DATACHECK 
     is 1.  An XQPERR  bugcheck occurs due to a corrupted directory.

  o  The NOTIFY_USER for final status of an XQP request occurs too
     early in XQP request completion to report any errors produced
     in cleanup or auditing.  This normally does not cause a problem 
     since USER_STATUS is not expected to change during cleanup.
     However, if it does change, then the output of SET WATCH FILE
     is misleading.

  o  XQP requests to create a new file with version limits set can
     fail with an SS$_NOSUCHFILE error.

  o  Deleting a stale alias on a directory with extension headers
     can bugcheck with an XQPERR "lock index has shifted" error.  
     This problem occurs when:

          1.  An alias to an existing file is created;

          2.  The original file is deleted; and

          3.  The original file's file header is reused as an 
              extension header of the alias's parent directory 
              (when ACEs are added to the directory).

  o  Prevent access to file headers beyond index file highwater-marking 
     (HWM).

     It is possible to ACCESS by FID a file header beyond the
     current end of the index file on a freshly-initialized volume.
     Creating a new file accessed in this way can bugcheck the
     system with the XQPERR error.

 o   Fix a reserved operand fault bugcheck on $QIO exit.  The 
     $QIO failed on return because the IPL was set to zero but
     was entered at IPL 2.

  o  $GET_SECURITY was reading the ORB on a file without any
     synchronization with the file system.  In the best case, 
     this problem can lead to bad information being returned.   
     In the worst case, if the filesystem was rebuilding the 
     ORB's ACL chain at the time, a kernel mode ACCVIO can occur.

     *** Note:  In order to get this fix, ALPSYSA01_071 must also
                be installed on the system.  


INSTALLATION NOTES:

The images in this kit will not take effect until the system is
rebooted.  If there are other nodes in the VMScluster, they must 
also be rebooted in order to make use of the new image(s).  

If it is not possible or convenient to reboot the entire cluster at 
this time, a rolling re-boot may be performed.
All trademarks are the property of their respective owners.



 
Copyright (c) Compaq Computer Corporation 1998, 1999.  All rights reserved.

Modification Date:  07-OCT-1999
Modification Type:  ARCHIVED

OP/SYS:     OpenVMS Alpha 

COMPONENTS: F11BXQP 
            FILESERV
            VMS$CONFIG-050_CACHE_SERVER.COM

SOURCE:     Compaq Computer Corporation

ECO INFORMATION:

     ECO Kit Name:  ALPF11X05_071 
     ECO Kits Superseded by This ECO Kit:  ALPF11X04_071 
                                           ALPF11X03_071 
     ECO Kit Approximate Size:  990 Blocks
     Kit Applies To:  OpenVMS Alpha V7.1, V7.1-1H1, V7.1-1H2 
     System/Cluster Reboot Necessary:  Yes
     Rolling Re-boot Supported:  Yes
     Installation Rating:  INSTALL_1
                           1 - To be installed on all systems running
                               the listed version(s) of OpenVMS.

     Kit Dependencies:

       The following remedial kit(s) must be installed BEFORE
       installation of this kit:

         ALPBASE02_071
         ALPY2K01_071

       In order to receive all the corrections listed in this
       kit, the following remedial kits should also be installed:

         ALPSYSA03_071 


ECO KIT SUMMARY:

An ECO kit exists for F11BXQP on OpenVMS Alpha V7.1 through V7.1-1H2.
This kit addresses the following problems: 

Problems addressed in APF11X05_071:

  o  When two processes access a file via the MOVEFILE and
     READATTR/FID_TO_SPEC mechanism, both processes try to delete
     the 'primary_fcb' used to get the information in question.
     This causes a NOTFCBFCB bugcheck to occur.

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  If a process attempts to mount a bound volume set (BVS)  
     and all the members of the BVS are not present, an attempt 
     to lock the volume for REBUILDing the meta-data on the volume 
     will fail.  However, the blocking lock (F11B$b) is left 
     with the process.

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  An XQPERR bugcheck in LOCKERS can occur when the retry  
     limit on the F11B$x lock is reached.

     This problem can occur when:

       1.  The owner of the $x lock is running at a high process
           priority; and

       2.  A number of processes are in a clustered system are also
           trying to validate this lock, but at a lower process
           priority.

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  After releasing the current process' IPL/Fork lock, a system 
     can crash with a SPLACQERR bugcheck

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  A directory file becomes "corrupt" and DUMP/DIRECTORY
     displays a block similar to the following:

       Virtual block number 3574 (00000DF6), 512 (0200) bytes
       0000  Directory Entry:
       0000    Size:             508

         0002    Version limit:    32767
         0004    Type:             0  (FID)
         0005    Name count:       24
         0006    Name:             COSLR1201_01_JUPICC2.LIS
         001E    Version:  7859    FID:  (40993,5,0)
         0026    Version:  7858    FID:  (40990,1,0)
         002E    Version:  7857    FID:  (40988,3,0)
         ...
         01E6    Version:  7802    FID:  (40455,1,0)
         01EE    Version:  7801    FID:  (40454,1,0)
         01F6    Version: 32767    FID:  (16744447,65535,0)
         01FE  End of records (-1)

       The directory shuffle code creates the above  erroneous
       directory entry for a couple of reasons:

         1.  So that a new directory buffer will have a valid structure
             (this allows VALIDATE_DIRBLK to write the block to disk)

         2.  So that the entry will be spotted as bogus (via VERIFY) if
             we crash in the middle of this shuffle.

       After the directory block (with the eroneous directory entry)
       is written to disk, the bad entry is removed.  A subsequent
       call to READ_BLOCK assumes that the block comes from the
       buffer cache and not from disk.  Under heavy load, this
       assumption may not be true as the directory block may have
       been kicked out of the cache.

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  Update the conversion of the ODS-1 date field to comply  
     with the RSX-11 version of date handling.  Note that this 
     change is for the obsolete string format dates of DDMMMYY 
     of RSX and do not affect the 64 bit binary date stored on disk.

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE

  o  Under the following circumstances:

       1.  A directory with multiple headers (from a large ACL for
           example) is deleted on one node (A) in a cluster and

       2.  the directory had been previously accessed on another node
           (B) in the cluster

     The files created with the previously deleted headers in step
     1 would show up on node B with the error:

       %SYSTEM-F-NOSUCHFILE, no such file

     Image(s) Affected:  [SYS$LDR]F11BXQP.EXE


Problems addressed in APF11X04_071:

  o  A reserved operand fault bugcheck occurs on a $QIO exit.

     During the mounting of the system disk, the error message that
     the disk is mounted with a reduced cache is suppressed.  Hence, 
     the System Manager may be unaware that the performance of the 
     system disk and all others attached to the same cache block is 
     questionable.

     Image Affected:  [SYSEXE]FILESERV.EXE
 
  o  When deleting a large file (such as a system dump file), a
     UNXSIGNAL Bugcheck may occur.  This particular bugcheck occurs
     because a variable in the code causes a reference to memory
     data that the file system does not own and an internal access
     violation occurs (ACCVIO).

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  On some systems with higher rates of system paging or with
     WSDEC set to a non-standard value, a system can crash with a
     PGFLIPLHI (Page Fault IPL too High) bugcheck.  This problem
     happened when the system returns from a SMP$ACQUIRE call.

     Image Affected:  [SYS$LDR]F11BXQP.EXE  

  o  An XQPERR can occur in the RDBLOK module during disk cleanup
     using DCL.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  When storing the value of a directory index buffer, the system
     may crash with a PGFLIPLHI, SSRVEXCPTN error.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  A dismount on a shadowded device results in an unnecessary
     copy.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  An XQPERR bugcheck (crash) in the RETURN_CREDITS module can
     occur during DISMOUNT.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  An XQPERR Bugcheck (crash) in XQP can occur during a SET ACL
     (SET FILE/ACL) operation.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  When two processes are competing to dismount a volume, one
     process may be just a bit faster than the other and delete the
     VCB and other structures before the second process has time to
     finish up its processing.  The result is a UNXSIGNAL/ACCVIO 
     crash.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  A device reporting a read error (SS$_PARITY) during read/write
     processing in the XQP will attempt to record the bad blocks
     and FID in the BADLOG.SYS file.  When the internal close
     operation occurs (on BADLOG), the system XQPERR bugchecks 
     when it finds the process's dirty buffers have not been 
     written out.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  A UNXSIGNAL/ACCVIO error can occur at module F11BXQP.  This
     problem occurs during mount, when the primary volume is not
     yet mounted.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  Processes can hang (deadlock) when dismounting a device.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  A 'no such file' error can occur on directory extension FCBs.

     This problem can occur in at least two ways:

       1.  A file appears normal on one node but has an 'no such
           file' error from another node.

       2.  BACKUP or DUMP /HEADER encounters a read attributes  
           error of NOSUCHFILE.  This error occurs when an attempt 
           is made to read a file header, for which the FCB for the 
           old header is still in memory.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  Occasional false end-of-file (EOF) errors can occur on a read
     operation.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  The XQP fails after an IO$_DEACCESS call with an SS$_BADPARAM
     error.  One cannot determine whether a file is still open or
     not due to the failed IO$_DEACCESS call.

     Image Affected:  [SYS$LDR]F11BXQP.EXE

  o  Non-privileged users can change the revision date (and count)
     of a file for which they should have only READ access.  For
     example, if a non-privileged user with READ-only file access
     tries to set the file protection, a failure occurs with an
     SS$_NOPRIV error as expected.  However, the revision date (and
     count) are modified.

     Image Affected:  [SYS$LDR]F11BXQP.EXE


Problems addressed in APF11X03_071:

  o  An XQPERR bugcheck error, "all the index buffers are active",
     occurs when running with a reduced cache or during a backup.

  o  An XQPERR bugcheck error, "wrong lock basis with FCB present",
     occurs when files with ACLs are created on a full volume.

  o  It is possible to serialize on the wrong volume in a volume set.

  o  If more than one process queues for a volume's activity
     blocking lock, the XQP can deadlock.

  o  Various XQPERR bugchecks occur in directory scanning/shuffling.

  o  A crash may occur during creation of a file with a version
     limit of 1 if SYSTEM_CHECK is on or bit 5 or 6 of ACP_DATACHECK 
     is 1.  An XQPERR  bugcheck occurs due to a corrupted directory.

  o  The NOTIFY_USER for final status of an XQP request occurs too
     early in XQP request completion to report any errors produced
     in cleanup or auditing.  This normally does not cause a problem 
     since USER_STATUS is not expected to change during cleanup.
     However, if it does change, then the output of SET WATCH FILE
     is misleading.

  o  XQP requests to create a new file with version limits set can
     fail with an SS$_NOSUCHFILE error.

  o  Deleting a stale alias on a directory with extension headers
     can bugcheck with an XQPERR "lock index has shifted" error.  
     This problem occurs when:

          1.  An alias to an existing file is created;

          2.  The original file is deleted; and

          3.  The original file's file header is reused as an 
              extension header of the alias's parent directory 
              (when ACEs are added to the directory).

  o  Prevent access to file headers beyond index file highwater-marking 
     (HWM).

     It is possible to ACCESS by FID a file header beyond the
     current end of the index file on a freshly-initialized volume.
     Creating a new file accessed in this way can bugcheck the
     system with the XQPERR error.

 o   Fix a reserved operand fault bugcheck on $QIO exit.  The 
     $QIO failed on return because the IPL was set to zero but
     was entered at IPL 2.

  o  $GET_SECURITY was reading the ORB on a file without any
     synchronization with the file system.  In the best case, 
     this problem can lead to bad information being returned.   
     In the worst case, if the filesystem was rebuilding the 
     ORB's ACL chain at the time, a kernel mode ACCVIO can occur.

     *** Note:  In order to get this fix, ALPSYSA01_071 must also
                be installed on the system.  


INSTALLATION NOTES:

The images in this kit will not take effect until the system is
rebooted.  If there are other nodes in the VMScluster, they must 
also be rebooted in order to make use of the new image(s).  

If it is not possible or convenient to reboot the entire cluster at 
this time, a rolling re-boot may be performed.
All trademarks are the property of their respective owners.


Files on this server are as follows:
»alpf11x06_071.README
»alpf11x06_071.CHKSUM
»alpf11x06_071.CVRLET_TXT
»alpf11x06_071.a-dcx_axpexe
»alpf11x06_071.CVRLET_TXT
privacy statement using this site means you accept its terms