![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Automated Archiving Topic Summary: Created On: 16-Oct-2003 17:42 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: Scheduling: you can use the variety of schedulers to schedule such DOORS tasks, including Windows Scheduler and the DOS "at" command. You write a non-interactive DXL script and invoke it in "batch" mode. Unfortunately, this requires that you enter the DOORS adminstrator's password and it gets displayed unencrypted. That's a big no-no and illegal on the projects I'm working on. This does NOT apply to Database's who have the "log on using system user name" option set. Anyway, such a command line may look like: ../bin/doors.exe -b Achive.dxl -u Administrator -P AdminsPassword. The remove all locks section can look like: Lock lockItem LockList llist = getLocksInDatabase(true) for lockItem in llist do { print "... removing: " BuildLockInfo(lockItem) "\n" ErrMess = remove (lockItem) if (!null ErrMess) print "... XXX RemoveError = " ErrMess "" } We use todays date as part of the archive file and folder names. - Louie | |
![]() |
|
Does anybody have a script for automated archiving for DOORS 5 and up?
We would like to use Window's Task Manager to run a DXL script to do the following:
Would appreciate any help. Our administrators are tied to their desks until the archiving is done every weeknight! ![]() |
|
![]() |
|
![]() |
|
Scheduling: you can use the variety of schedulers to schedule such DOORS tasks, including Windows Scheduler and the DOS "at" command. You write a non-interactive DXL script and invoke it in "batch" mode. Unfortunately, this requires that you enter the DOORS adminstrator's password and it gets displayed unencrypted. That's a big no-no and illegal on the projects I'm working on.
This does NOT apply to Database's who have the "log on using system user name" option set. Anyway, such a command line may look like: ../bin/doors.exe -b Achive.dxl -u Administrator -P AdminsPassword. The remove all locks section can look like: Lock lockItem LockList llist = getLocksInDatabase(true) for lockItem in llist do { print "... removing: " BuildLockInfo(lockItem) "\n" ErrMess = remove (lockItem) if (!null ErrMess) print "... XXX RemoveError = " ErrMess "" } We use todays date as part of the archive file and folder names. - Louie |
|
![]() |
|
![]() |
|
Hello Louie and Janet,
but what about the problem, that you are "stealing" locks for purpose of archiving. Ok, the archive process is fine, but the users who had documents open editing (even overnight, yes there are ...) will loose lock! The result: Somebody else could open the module, modify and save it. Did you think about? What will happen, if the owner of the lock - before backup was done - will save his module? Which of the contents will survive .... What we are doing is sending automated emails to notify, that the lock was removed and we want the user to close DOORS, but this is not optimal. This mess is only because, archive-command needs exclusive write access. I placed an ER on that to Telelogic, see what happens. Or do you have a nice method to wipe out users and make them regularly close their DOORS application remotely? That would be nice, if you would let me know... Regards Hubertus |
|
![]() |
|
![]() |
|
Hubertus,
I logged in as a test user and left a module open, with a minor unsaved change in my document overnight. The automated archiving script ran in the middle of the night which logged on as Administrator and remove all the database locks. This is a DOORS 7.1 server that is local on my machine. The archiving proceeded and logged in the locks that had been removed. However, as the test user, I was able to still save my changes to the module the next morning after the archivng was complete, even though I did get a warning message that my locks had been removed. --Janet |
|
![]() |
|
![]() |
|
Hi Janet,
what you were testing is the best case :-) because no collision occurs. One of the worse cases is, that you have user A with unsaved chages (and a removed lock) and user B opening the module exclusively - possible because of removed locks of user A - doing his work and soving the module. What happens if user A wants to save his module? Will you find a merge of changes from A and B, surely not?!
Only one scenario, others also possible...
From the server-side the official locked version was the one of user B, because he received the lock. User A should not be able to save his changes, because his session is persisting without having reobtained a lock.
Regards
Hubertus
|
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Automated Archiving
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.