If you have DX'd an FSI account, the QS pointer probably still exists in the VME's MDS. This can cause a problem with RESTORE-ACCOUNTS as it will create the DX'd account, restore the data from the account following it on the tape, then not restore that following account as itself.

Example: you have an account called test followed immediately by an account called orders. You DX the test account and do a file save. You delete the accounts and do a RESTORE-ACCOUNTS. test will exist with the orders account's content and the orders account will not exist.

Note that this affects RESTORE-ACCOUNTS but does NOT affect ACCOUNT-RESTORE, so if you stumble on this, you can delete any erroneous accounts and ACCOUNT-RESTORE FSI:<missing account> and you'll be good. Doing a d3vme /fileload is not affected either.

Please note that Engineering is aware of this issue and currently working on a resolution.

For those of you who need a little more detail on what I mean by "DX'ing an account", I'm referring to "SET-DPTR +X accountname (A" and "CHANGE-FILE M/DICT accountname (X", or account creation with the X option ("CREATE-ACCOUNT accountname (X"), as well as simply editing the account's D-pointer and changing attribute 1 from "D" to "DX". Until we get this resolved, it's recommended that you also change the account's QS-pointer to a Q-pointer as follows:

ED MDS acctname
top
.1
001 QS
.R/S//
001 Q
.FI
[221] 'acctname' filed.

Is this only Windows or is D3 Linux 10.4.0 also affected ?