Conference cookie::sls

OK. So, its been 2 months. After .4's reply I told the customer that we
wouldn'ty look into it any further unless they upgraded from V2.5b to V2.8. Its
taken them this long to to get around to it but it seems as thought the problem
still exists.

To recap...

SYSBAK summary listing  Page      1   6-FEB-1997 20:08:03.23  Volume 520303
$ BACK/STOR=V2SLS/LIST=_MBA2075:/FULL HBV033$APP_500:[*...]*.*;*/SINCE=BACKUP/IG
NORE=(LABE,INTER)/BLOCK=32768/MEDIA_COMPACTION=COMP _$1$MKA0:APP_500_06FEB.97/PR
OT=(S:RW,O:RW,G:R,W:R)/NOASSI

Listing of save set(s)

Save set:          APP_500_06FEB.97
Written by:        SLS         
UIC:               [000075,000001]
Date:               6-FEB-1997 20:08:03.11
Command:           BACK/STOR=V2SLS/LIST=_MBA2075:/FULL HBV033$APP_500:[*...]*.*;
*/SINCE=BACKUP/IGNORE=(LABE,INTER)/BLOCK=32768/MEDIA_COMPACTION=COMP _$1$MKA0:AP
P_500_06FEB.97/PROT=(S:RW,O:RW,G:R,W:R)/NOASSI
Operating system:  OpenVMS AXP version V6.2
BACKUP version:    V6.2
CPU ID register:   80000000
Node name:         _HBV033::
Written on:        _$1$MKA0:
Block size:        32768
Group size:        10
Buffer count:      238

[000000]000000.DIR;1                     1  26-JUN-1996 13:04
[000000]DBDEV.DIR;1                      1  11-DEC-1996 23:48
[000000]MASS11.DIR;1                     1  14-AUG-1996 18:35
[000000]MEDCHEMDBS.DIR;1                 1  12-DEC-1996 17:49
[000000]MOLDBS.DIR;1                     1   7-AUG-1996 17:47
[MOLDBS]ACD3D952A.DIR;1                  7  12-AUG-1996 22:40
[MOLDBS.ACD3D952A]SUPPLIER.DIR;1         2  12-AUG-1996 22:54 <--- ***
[MOLDBS.ACD3D952A]SUPPLIER.DIR;1         7   7-SEP-1996 00:15 <--- ***
[MOLDBS.ACD3D961A]CONTRL.DAT;1          16  24-MAR-1996 09:47
[MOLDBS.ACD3D961A]SUPPLIER.DIR;1         2   9-SEP-1996 15:20
[MOLDBS.ACD3D961A.SUPPLIER]CONTRL.DAT;1 16  27-APR-1995 13:43
[MOLDBS]DD.DIR;1                         1   9-OCT-1996 16:17
etc............

From the relisting from tape, this should be:-

[000000]MEDCHEMDBS.DIR;1                 1  12-DEC-1996 17:49
[000000]MOLDBS.DIR;1                     1   7-AUG-1996 17:47
[MOLDBS]ACD3D952A.DIR;1                  7  12-AUG-1996 22:40
[MOLDBS.ACD3D952A]SUPPLIER.DIR;1         2  12-AUG-1996 22:54 <--- ***
[MOLDBS]ACD3D961A.DIR;1                  7   7-SEP-1996 00:15 <--- ***
[MOLDBS.ACD3D961A]CONTRL.DAT;1          16  24-MAR-1996 09:47
[MOLDBS.ACD3D961A]SUPPLIER.DIR;1         2   9-SEP-1996 15:20
[MOLDBS.ACD3D961A.SUPPLIER]CONTRL.DAT;1 16  27-APR-1995 13:43

I don't believe this is BACKUP issue, per se, its more to do with the way SLS
uses mailboxes to capture the output from the /LIST=_MBA2075 qualifier.

Any more thoughts or suggestions before I have to IPMT this ?

Many thanks,

Simon R. Mills
OpenVMS Group, UK CSC

Simon,

The content of the .LIS file should be the same as the output from
BACKUP/LIST of the saveset.  Since they are not and it's reproducible,
you should submit an ipmt case.  Please include the the SBK.LOG file
(or a pointer to it) and extracts from the .LIS file and BACKUP/LIST.

Thanks,
Marty
SLS/MDMS Engineering

Thanks, Marty. I'm on it. Expect an IPMT in the very near future...

Regards,

Simon.

    Hi Marty,
    
    Did Simon IPMT this case.  I have a customer who is expeiencing the
    same behavior and they fell this is a critical issue for them.  They
    need a resolution.  They have a home grown application that depends 
    upon data from the backup lisitng.  Because the listing is incorrect,
    the output of their application is unusable.
    
    Thanks,
    
    Victoria

    Hello:
    	The listing display problem has been evident on several clusters
    for some time (see .0). After our customer was able to schedule the
    upgrade of SLS (a very time-consuming process because of their internal
    verification procedures) and perform the upgrade on one of their sites,
    the problem still existed. The problem was not actively pursued by the
    customer until they verified that an existing application which
    depended upon the output of the SLS listing for its input was providing
    erroneous data. This has become a matter of very much concern by people
    at high levels on the customer side.
    	At first the problem was known to occur on every image backup,
    multiple times. We have since verified that it occurs on every backup,
    including incrementals.
    	The CFS.50216 will be closed out and the ownership of the problem
    resolution transferred to the US side (yours truly). SLS engineering
    has requested that our customer run an SLS backup, then a corresponding
    VMS backup, as in reply .2. They also want the customer to check the
    SLS history file to verify that the file missing in the SLS listing did
    in fact get backed up by SLS. There is a new IPMT number for the
    escalation.
    	Our customer has committed to running the tests tomorrow morning,
    and I will get the listings and results to engineering asap. Our
    customer has expressed unease that engineering has not been able to, or
    not tried to, reproduce the problem on their own systems.
    	I shall update this note when there is more info.
    
    		Alex Krywoshia, Digital Service Management Office, US
      	

Alex, Victoria,,

We received your IPMT case, CFS.50517/HPAQ40UBF and we have requested
closure of CFS.50216 which still hasn't happened.  We're still waiting
for the information requested.

Marty