DDP (DSM) question
John Mitchell
available?
We have database "AAA" local and "BBB" remote -linked via DECnet
accessed by DDP. We want to update both databases if both are
available or neither if one or both are unavailable.
What's the best way to keep my databases in synch?
John.
John Mitchell
J...@yakuza.stanford.edu
About checking on availabiltiy of databases, I think that the Lock command
with timeout will work:
L ^["AAA"]SOURCE1(NODE,WHAT,EVER):5 Q:'$T
L ^["BBB"]BACKUP2(NODE,WHAT,ELSE):5 Q:'$T
D UPDATE
L ;Unlock everything
The Lock will impact any other routines which are attempting to lock the
same nodes, so depending on your environment you will have to be more or
less careful about when the update process occurs.
But this is one of the primary uses of the Lock command.
Hope I didn't miss anything in your request.
Joe Bayus
Michael McIntyre
>
>What's the preferred way to determine if a remote database is
>available?
>
access fails and take appropriate action. This could also be used to
detect if the database is available. For example:
chknode(uci,vol) ;
S $ZT="chknode1^znetdsm" ; $ETRAP is standard... but you
; may have older version
IF $DATA(^[uci,vol]x) ; please do not depend on naked later...
QUIT 1 ; success
chknode1 ;
;
QUIT 0 ; failure
You might want to check for the actual errors that you expect to
occur and then ZQUIT if something unexpected happens. That will allow
a error handler above you on the stack take care of the problem.
There might be a function call specific to an implementation that
would give you the information. The MDC is working on some standard
networking proposals that might help here as well.
A caution. This code might just hang on some implemtations instead of
giving you an error. It might also just hang on DSM under some
circumstances.
>We have database "AAA" local and "BBB" remote -linked via DECnet
>accessed by DDP. We want to update both databases if both are
>available or neither if one or both are unavailable.
>
>What's the best way to keep my databases in synch?
>
I would use some sort of transaction monitor. We wrote a simple one
to do registration updates to another vendor's lab system. We used DDP
to connect the MSM-PC system to our VAX-DSM system. Our system wrote
to a global define like this:
^xfer(0,"W")=written
^xfer(0,"R")=read
^xfer(n,"NAME")=name
^xfer(n,"DOB")=dob
...etc...
Since we did not want to have a problem if the other system was down,
the xfer global is located on our system. We write to it whenever we
update registration data. The remote system (when it is up) looks at
^xfer(0,"W") periodically to see if there is any work for it. When it
is done reading a record, it updates ^xfer(0,"R") which tells us that
we can purge the data.
This system works pretty well, but the other system is the one that is
responsible for handling the condition of our system being down. I
suspect that the daemon (on their system) will just continue to check
periodically, and handle the error by looping. Of course you might
want to build in conditions for excessive errors...
I know that some people in the VA were using replication on some
volumes, but found that the problem of missing updates to be quite
painful. Both MSM and DTM allow you to build systems that shadow a
database at the system level, using after image journals that are read
by the backup system. Depending on your application, that might work
more reliably than coding everything in M. If you do code it all in
M, I would suggest isolating the system specific code.
>
>John.
>
J...@YAKUZA.STANFORD.EDU replied to the original post:
>
>John,
>About checking on availabiltiy of databases, I think that the Lock command
>with timeout will work:
>
> L ^["AAA"]SOURCE1(NODE,WHAT,EVER):5 Q:'$T
> L ^["BBB"]BACKUP2(NODE,WHAT,ELSE):5 Q:'$T
> D UPDATE
> L ;Unlock everything
>
This code suggests that the two locks will both be active at the same
time, when in fact, the second lock command will release the first
lock. In order to lock two nodes at the same time, you need to either
put both of them in ( ) like:
LOCK (^foo,^bar):5
or use the incremental lock like:
LOCK +^foo:5 IF '$TEST WRITE "yawn." QUIT
LOCK +^bar:5 IF '$TEST WRITE "hmm." LOCK -^foo QUIT
DO update
LOCK -^foo,-^bar
>The Lock will impact any other routines which are attempting to lock the
>same nodes, so depending on your environment you will have to be more or
>less careful about when the update process occurs.
>
You will want to use the lock command when you write to the transfer
file, to insure that two processes on the source system will not write
to the same transfer record. [Ed. Note: quick change of topic...]
>But this is one of the primary uses of the Lock command.
>
>Hope I didn't miss anything in your request.
>
>Joe Bayus
By the way... If you want to get a frustrated look from your M vendor,
ask them when they are going to have the MDC Transaction Processing
proposal implemented on networked systems. 8^%
-mike 8^)
--
Michael McIntyre | McIntyre Consulting, Inc. | Tel: 508-371-1935
m...@mcinc.com | 336 Baker Ave.; Concord,MA 01742 | Fax: 508-369-6693
Cormac Mc Gaughey
: What's the preferred way to determine if a remote database is
: available?
: We have database "AAA" local and "BBB" remote -linked via DECnet
: accessed by DDP. We want to update both databases if both are
: available or neither if one or both are unavailable.
: What's the best way to keep my databases in synch?
It depends on how your version of M works. An error trap in right place
could work as long as M reports an error when trying to set data across a
link thats down eg,
S $ZT="ERR"
S ^["UCI","BBB"]DATA(1)="Test"
S ^["UCI","AAA"]DATA(1)="Test"
ERR W "Neither Database Updated",!
Q
This has the effect that an error condition will be set when writeing to
the remote database. The error trap will skip past the local database
write, hence neither database gets set if DDP is down, but both are set
if it's up.
Regards,
Cormac
--
I was a free thinker; then I discovered you could charge money for it.