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

Conference movies::decdtm-vms

Title:	DECDTM-VMS
Notice:	DECdtm Conference. 260.* for docs & kits. Digital Confidential
Moderator:	MOVIES::PLAYFORD

Created:	Fri Aug 12 1988
Last Modified:	Fri May 30 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	353
Total number of notes:	1278

349.0. "GETDTI, 2 questions" by DMARK::LEHTO () Tue Mar 11 1997 09:43

    Doing recovery processing of a remote DECdtm journal:
    
    The DECdtm journal had 2 prepared records and processed the 1st 
    without incident.
    
    The 2nd call to SYS$GETDTIW got:
     
      IOSB[0]     = 9052   = SS$_NOSUCHTID
      dti$b_state = 10     = DDTM$K_RECOVER_ERROR ?
      TID[0] had the same value as the previous call. TID[1-3] are 0.
    
    ----------------
    
    Per Paragraph 2, App. E.3 of the 1/1995 Func Spec; was this transaction
    ABORTED ? Is the state field information dependable with this IOSB
    status ?
    
    To terminate a recovery loop of calls to GETDTI, is any return status
    other than SS$_NORMAL or SS$_SYNCH indicative of end of file/done ?
    
    Thanks for your reply.
    Jon Lehto

T.R Title User Personal
Name Date Lines

349.1 halt::POTTER http://www.vmse.edo.dec.com/~potter/ Tue Mar 11 1997 12:04 23

T.R	Title	User	Personal Name	Date	Lines
349.1		halt::POTTER	http://www.vmse.edo.dec.com/~potter/	`Tue Mar 11 1997 12:04`	23
	Jon, The contents of the DTIB are only defined if the low-order word of the IOSB contains SS$_NORMAL or SS$_SYNCH. If the IOSB contains SS$_NOSUCHTID, that means that the transaction did indeed abort. Recovery processing is described in the draft tutorial on DECdtm in AVOLUB::DISK$PUBLIC:[DECDTM.SPECS]DRAFT_TUTORIAL.PS. Basically, there are two things that should happen: 1. The RM should ask about transactions about which it is in doubt (this is done on a per-tid basis) 2. The RM should then do a wildcard scan (the RM name set up, the TID wildcarded) to clear up any transaction records for which the RM was able to harden its commit record on disk (hence the RM is not in doubt) but had not yet acknoweledged back to DECdtm before the system failure. The _latter_ scan is indicated as complete by an IOSB status of SS$_NOSUCHTID. Hope this helps, regards, //alan

Jon,

The contents of the DTIB are only defined if the low-order word of the IOSB
contains SS$_NORMAL or SS$_SYNCH.  If the IOSB contains SS$_NOSUCHTID, that
means that the transaction did indeed abort.

Recovery processing is described in the draft tutorial on DECdtm in 
AVOLUB::DISK$PUBLIC:[DECDTM.SPECS]DRAFT_TUTORIAL.PS.  Basically, there are 
two things that should happen:

1. The RM should ask about transactions about which it is in doubt (this is
   done on a per-tid basis)
2. The RM should then do a wildcard scan (the RM name set up, the TID
   wildcarded) to clear up any transaction records for which the RM was able 
   to harden its commit record on disk (hence the RM is not in doubt) but
   had not yet acknoweledged back to DECdtm before the system failure.

The _latter_ scan is indicated as complete by an IOSB status of SS$_NOSUCHTID.

Hope this helps,

regards,
//alan