From Lirvin@accdvm.accd.edu Thu Jun 1 10:20:21 2006 Received: with ECARTIS (v1.0.0; list encore); Thu, 01 Jun 2006 10:20:21 -0500 (CDT) Return-Path: X-Original-To: encore@nobel.utdallas.edu Delivered-To: encore@nobel.utdallas.edu Received: from iq1.utdallas.edu (iq1-pmn.utdallas.edu [192.168.1.7]) by nobel.utdallas.edu (Postfix) with ESMTP id B4B465BAD for ; Thu, 1 Jun 2006 10:20:21 -0500 (CDT) Received: from localhost (mf2-pmn.utdallas.edu [192.168.1.14]) by iq1.utdallas.edu (Postfix) with ESMTP id AA94158CE for ; Thu, 1 Jun 2006 10:20:21 -0500 (CDT) Received: from mx2.utdallas.edu ([129.110.10.17]) by localhost (mf2.utdallas.edu [10.110.10.14]) (amavisd-new, port 10024) with LMTP id 12461-01-33 for ; Thu, 1 Jun 2006 10:20:08 -0500 (CDT) Received: from mx3.lsn.net (mx3.lsn.net [66.90.130.75]) by mx2.utdallas.edu (Postfix) with ESMTP id 235FB3507 for ; Thu, 1 Jun 2006 10:18:06 -0500 (CDT) Received: from Gilgamesh.accdvm.accd.edu (24-155-46-7.dyn.grandenetworks.net [24.155.46.7]) by mx3.lsn.net (8.13.5/8.13.5) with ESMTP id k51FI4OX030613 for ; Thu, 1 Jun 2006 10:18:09 -0500 Message-Id: <6.2.5.6.0.20060601092239.029b4d70@accdvm.accd.edu> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Jun 2006 10:18:05 -0500 To: encore@utdallas.edu From: Lennie Irvin Subject: [encore] High 5 Fever! Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_16441421==.ALT" X-Virus-Scanned: ClamAV 0.88.2/1504/Wed May 31 14:59:14 2006 on mx0.lsn.net X-Virus-Status: Clean X-Virus-Scanned: amavisd-new at utdallas.edu X-archive-position: 1665 X-ecartis-version: Ecartis v1.0.0 Sender: encore-bounce@utdallas.edu Errors-to: encore-bounce@utdallas.edu X-original-sender: Lirvin@accdvm.accd.edu Precedence: bulk Reply-to: Lirvin@accdvm.accd.edu List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: X-list: encore --=====================_16441421==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hey Everyone, The new version of enCore v5 (High 5) is out in beta form at http://lingo.uib.no:6002/. Check it out! You can set up a new user account from the login screen or contact me for an account. Information about High 5 (including a changelog) can be seen at http://lingo.uib.no/v5/ HOW TO RALLY AROUND HIGH FIVE DEVELOPMENT AND HELP IT REACH OFFICIAL RELEASE AS SOON AS POSSIBLE Explore and test drive the High Five site. As you see and find thing, please post them in the Forum called "High Five." Click on the menu bar item "Mail/Forum," subscribe to the High Five forum, and then post your observations and suggestions. As you encounter errors, please fill out the error reporting form. THINK DIFFERENT! The old model of moo development (which enCore followed) was for individual sites to customize their site and create coding and features that fit its individual needs. I can think of many enCore sites (I can think specifically of three, but I'm sure there are more) who's customizations have lived and died only there. We need to think different (I know is should be differently...). Different how? I propose that we within the enCore community think more about centralized development rather than decentralized. What I mean is that individual enCore sites should share their individual customizations with the "core" or central development site (at Univ. of Bergen). That these sites should collaborate with other enCore sites working or wanting to work on similar things and collaborate with the Univ. of Bergen. What I am proposing is that we "co-develop" rather than develop in isolation. I can think of at least three enCore sites who have programmers actively working to make modifications to their individual enCore site to meet the needs of that site: Matthew Coupe for NCC Educational Robert Rozema and Allen Web for Secondary Worlds (soon to be Literary Worlds) Jean-Marc Giffin at Acadia University There are probably more. My hope is that via the enCore Consortium that the work done at these individual sites can feed into the main release and that the lead programmers like Daniel Jung at Univ. of Bergen can assist the individual sites in doing what they want to do. This symbiotic development model is what the enCore Consortium is all about fostering. Network with other enCore sites Check out the other enCore Consortium members and their sites at http://www.encore-consortium.org/members/members.php. See who else is doing what you are doing and contact them. You can email right out of the member list. Post ideas and questions to this encore user's list. Take the initiative! I strongly urge you to take the initiative on things you think need to get done. Jump right in and share your ideas. I have a number of areas listed below where you could start doing something now. Consortium Projects First, I strongly recommend that you join the enCore Consortium if you haven't joined already. http://www.encore-consortium.org/ Twist the arms of other people involved with enCore at your local site to join too. The more the merrier. It costs nothing to join. Below is a list of various projects currently in the works: 1) Of course, v5 beta development is ongoing. Daniel may have specific tasks he needs help on. 2) enCore v5 Documentation Project--lots to do --See details of this single-source documentation solution: http://www.encore-consortium.org/Generalv5Proposal.pdf --Contribute funds to the v5 Doc Project!!! We need money to complete this work. Even a small amount helps us look better as we request funds from larger potential sponsors. See the proposal and the consortium website for details on contributing. --Subject Content Experts needed: As the writers begin working on writing up the help for enCore v5, they may need assistance understanding certain functions or they may need a version of the help task written out. I want to assemble a team of content experts to be on call to receive and respond to these requests from the writers. Let me know if you want to be on this team. 3) Grants for enCore--specifically NEH Grant for Oct. 2006 submission If you are interested in helping the effort to secure an NEH Grant and perhaps some other large grant support for enCore (particularly in the area of language learning enCore sites), please let me know. We are beginning to develop a vision for a collaborative grant entitled "Learning Spaces." This grant would bring together constituent groups of enCore users: literature learning enCore sites, language learning enCore sites, composition/writing learning sites, and perhaps online classroom sites. Each constituent group would pull together like-minded enCore sites and craft specific project to bring together under the umbrela of the entire NEH Grant proposal. At least that is the idea right now. We need people to network these constituent groups, develop a website, and work on the grant application. If you want to find a way to leverage more money for projects you are pursuing at your local school, this is an excellent way to do it. The grant is for $200,000. If done properly, and we show adequate promise, then this grant could leverage even more support from other foundations or corporations. 4) Usability Test The usability test for v5 was done at Texas Tech May 15-25th. The report from this test should be out by June 9th. When the report comes out, I urge you to take a look at it and offer your own responses and interpretation. Most of all, we will need creative solutions to identified problems. Catch the fever! Check out High 5 and contribute to its development. Yours, Lennie P.S. Cynthia Haynes, the list owner, has taken a position at Clemson University. (Congratulations to Cynthia and Jan!!!) That means this list's days are numbers (at least as hosted from utdallas). Some sort of change is in the works. We will let you know when this change to the list happens. P.P.S. One last plug to contribute $$ to the enCore Documentation Project. --=====================_16441421==.ALT Content-Type: text/html; charset="us-ascii" Hey Everyone,

The new version of enCore v5 (High 5) is out in beta form at http://lingo.uib.no:6002/.  Check it out!  You can set up a new user account from the login screen or contact me for an account. 

Information about High 5 (including a changelog) can be seen at http://lingo.uib.no/v5/

HOW TO RALLY AROUND HIGH FIVE DEVELOPMENT AND HELP IT REACH OFFICIAL RELEASE AS SOON AS POSSIBLE

Explore and test drive the High Five site. 
As you see and find thing, please post them in the Forum called "High Five."  Click on the menu bar item "Mail/Forum," subscribe to the High Five forum, and then post your observations and suggestions.  As you encounter errors, please fill out the error reporting form. 


THINK DIFFERENT!
The old model of moo development (which enCore followed) was for individual sites to customize their site and create coding and features that fit its individual needs.  I can think of many enCore sites (I can think specifically of three, but I'm sure there are more) who's customizations have lived and died only there. 

We need to think different (I know is should be differently...).  Different how?

I propose that we within the enCore community think more about centralized development rather than decentralized.  What I mean is that individual enCore sites should share their individual customizations with the "core" or central development site (at Univ. of Bergen).  That these sites should collaborate with other enCore sites working or wanting to work on similar things and collaborate with the Univ. of Bergen. What I am proposing is that we "co-develop" rather than develop in isolation. 

I can think of at least three enCore sites who have programmers actively working to make modifications to their individual enCore site to meet the needs of that site:

Matthew Coupe for NCC Educational
Robert Rozema and Allen Web for Secondary Worlds (soon to be Literary Worlds)
Jean-Marc Giffin at Acadia University

There are probably more.  My hope is that via the enCore Consortium that the work done at these individual sites can feed into the main release and that the lead programmers like Daniel Jung at Univ. of Bergen can assist the individual sites in doing what they want to do. This symbiotic development model is what the enCore Consortium is all about fostering. 


Network with other enCore sites
Check out the other enCore Consortium members and their sites at http://www.encore-consortium.org/members/members.php.  See who else is doing what you are doing and contact them.  You can email right out of the member list.  Post ideas and questions to this encore user's list.


Take the initiative!
I strongly urge you to take the initiative on things you think need to get done.  Jump right in and share your ideas.  I have a number of areas listed below where you could start doing something now.


Consortium Projects
First, I strongly recommend that you join the enCore Consortium if you haven't joined already.  http://www.encore-consortium.org/  Twist the arms of other people involved with enCore at your local site to join too.  The more the merrier.  It costs nothing to join. 

Below is a list of various projects currently in the works:
1) Of course, v5 beta development is ongoing. Daniel may have specific tasks he needs help on.

2) enCore v5 Documentation Project--lots to do
--See details of this single-source documentation solution: http://www.encore-consortium.org/Generalv5Proposal.pdf
--Contribute funds to the v5 Doc Project!!! We need money to complete this work.  Even a small amount helps us look better as we request funds from larger potential sponsors.  See the proposal and the consortium website for details on contributing.
--Subject Content Experts needed:  As the writers begin working on writing up the help for enCore v5, they may need assistance understanding certain functions or they may need a version of the help task written out.  I want to assemble a team of content experts to be on call to receive and respond to these requests from the writers.  Let me know if you want to be on this team. 

3) Grants for enCore--specifically NEH Grant for Oct. 2006 submission
If you are interested in helping the effort to secure an NEH Grant and perhaps some other large grant support for enCore (particularly in the area of language learning enCore sites), please let me know.  We are beginning to develop a vision for a collaborative grant entitled "Learning Spaces."  This grant would bring together constituent groups of enCore users: literature learning enCore sites, language learning enCore sites, composition/writing learning sites, and perhaps online classroom sites.  Each constituent group would pull together like-minded enCore sites and craft specific project to bring together under the umbrela of the entire NEH Grant proposal.  At least that is the idea right now.

We need people to network these constituent groups, develop a website, and work on the grant application.  If you want to find a way to leverage more money for projects you are pursuing at your local school, this is an excellent way to do it.  The grant is for $200,000.  If done properly, and we show adequate promise, then this grant could leverage even more support from other foundations or corporations. 

4) Usability Test
The usability test for v5 was done at Texas Tech May 15-25th.  The report from this test should be out by June 9th.  When the report comes out, I urge you to take a look at it and offer your own responses and interpretation.  Most of all, we will need creative solutions to identified problems. 


Catch the fever! Check out High 5 and contribute to its development.

Yours,

Lennie

P.S.  Cynthia Haynes, the list owner, has taken a position at Clemson University.  (Congratulations to Cynthia and Jan!!!)  That means this list's days are numbers (at least as hosted from utdallas).  Some sort of change is in the works.  We will let you know when this change to the list happens. 

P.P.S.  One last plug to contribute $$ to the enCore Documentation Project.



--=====================_16441421==.ALT-- From jean-marc.giffin@acadiau.ca Fri Jun 2 08:03:06 2006 Received: with ECARTIS (v1.0.0; list encore); Fri, 02 Jun 2006 08:03:07 -0500 (CDT) Return-Path: X-Original-To: encore@nobel.utdallas.edu Delivered-To: encore@nobel.utdallas.edu Received: from iq1.utdallas.edu (iq1-pmn.utdallas.edu [192.168.1.7]) by nobel.utdallas.edu (Postfix) with ESMTP id B10E75BBB for ; Fri, 2 Jun 2006 08:03:06 -0500 (CDT) Received: from localhost (mf2-pmn.utdallas.edu [192.168.1.14]) by iq1.utdallas.edu (Postfix) with ESMTP id 922564C8C for ; Fri, 2 Jun 2006 08:03:06 -0500 (CDT) Received: from mx2.utdallas.edu ([129.110.10.17]) by localhost (mf2.utdallas.edu [10.110.10.14]) (amavisd-new, port 10024) with LMTP id 12624-01-2 for ; Fri, 2 Jun 2006 08:03:00 -0500 (CDT) Received: from stanley.acadiau.ca (stanley.acadiau.ca [131.162.201.38]) by mx2.utdallas.edu (Postfix) with ESMTP id 8F3053434 for ; Fri, 2 Jun 2006 08:02:33 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by stanley.acadiau.ca (Postfix) with ESMTP id 7803619BB53 for ; Fri, 2 Jun 2006 10:02:32 -0300 (ADT) Received: from stanley.acadiau.ca ([127.0.0.1]) by localhost (helios.acadiau.ca [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 51284-02-10 for ; Fri, 2 Jun 2006 10:02:30 -0300 (ADT) Received: from exchange.ad.acadiau.ca (exchange.acadiau.ca [131.162.200.60]) by stanley.acadiau.ca (Postfix) with ESMTP id 1F27519ADAE for ; Fri, 2 Jun 2006 10:02:22 -0300 (ADT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68644.9FD45539" Subject: [encore] New To MOO Date: Fri, 2 Jun 2006 10:01:23 -0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New To MOO Thread-Index: AcaGRKZGZdrpuqOITDu076kt28Ddnw== From: "Jean-Marc Giffin" To: X-Virus-Scanned: by amavisd-new at acadiau.ca X-Virus-Scanned: amavisd-new at utdallas.edu X-archive-position: 1666 X-ecartis-version: Ecartis v1.0.0 Sender: encore-bounce@utdallas.edu Errors-to: encore-bounce@utdallas.edu X-original-sender: jean-marc.giffin@acadiau.ca Precedence: bulk Reply-to: jean-marc.giffin@acadiau.ca List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: X-list: encore This is a multi-part message in MIME format. ------_=_NextPart_001_01C68644.9FD45539 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 This is a quick test e-mail to check how active this mailing list is. I am building a MOO this summer as part of a job, and would like to be in contact with as many resources as possible. =20 How active is this MOO mailing list? Are there many programmers out there? =20 Thanks, =20 Jean Of mArc =20 ------_=_NextPart_001_01C68644.9FD45539 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

This is a quick test e-mail to check how active this = mailing list is. I am building a MOO this summer as part of a job, and would = like to be in contact with as many resources as = possible.

 

How active is this MOO mailing list? Are there many programmers out there?

 

Thanks,

 

Jean Of mArc

 

------_=_NextPart_001_01C68644.9FD45539-- From jean-marc.giffin@acadiau.ca Fri Jun 2 09:28:58 2006 Received: with ECARTIS (v1.0.0; list encore); Fri, 02 Jun 2006 09:28:58 -0500 (CDT) Return-Path: X-Original-To: encore@nobel.utdallas.edu Delivered-To: encore@nobel.utdallas.edu Received: from iq1.utdallas.edu (iq1-pmn.utdallas.edu [192.168.1.7]) by nobel.utdallas.edu (Postfix) with ESMTP id 4A31F5C9B for ; Fri, 2 Jun 2006 09:28:58 -0500 (CDT) Received: from localhost (mf2-pmn.utdallas.edu [192.168.1.14]) by iq1.utdallas.edu (Postfix) with ESMTP id 265045B5A for ; Fri, 2 Jun 2006 09:28:58 -0500 (CDT) Received: from mx2.utdallas.edu ([129.110.10.17]) by localhost (mf2.utdallas.edu [10.110.10.14]) (amavisd-new, port 10024) with LMTP id 20283-01-51 for ; Fri, 2 Jun 2006 09:28:42 -0500 (CDT) Received: from stanley.acadiau.ca (stanley.acadiau.ca [131.162.201.38]) by mx2.utdallas.edu (Postfix) with ESMTP id 592CD350D for ; Fri, 2 Jun 2006 09:25:28 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by stanley.acadiau.ca (Postfix) with ESMTP id 948F319AC03 for ; Fri, 2 Jun 2006 11:25:27 -0300 (ADT) Received: from stanley.acadiau.ca ([127.0.0.1]) by localhost (helios.acadiau.ca [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 66011-01-4 for ; Fri, 2 Jun 2006 11:25:26 -0300 (ADT) Received: from exchange.ad.acadiau.ca (exchange.acadiau.ca [131.162.200.60]) by stanley.acadiau.ca (Postfix) with ESMTP id 75DFA19A5F1 for ; Fri, 2 Jun 2006 11:25:26 -0300 (ADT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68650.54CE8D55" Subject: [encore] enCoring Date: Fri, 2 Jun 2006 11:25:12 -0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: enCoring Thread-Index: AcaGUFu5rN1FW204TdigHqoiWfj8lA== From: "Jean-Marc Giffin" To: X-Virus-Scanned: by amavisd-new at acadiau.ca X-Virus-Scanned: amavisd-new at utdallas.edu X-archive-position: 1667 X-ecartis-version: Ecartis v1.0.0 Sender: encore-bounce@utdallas.edu Errors-to: encore-bounce@utdallas.edu X-original-sender: jean-marc.giffin@acadiau.ca Precedence: bulk Reply-to: jean-marc.giffin@acadiau.ca List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: X-list: encore This is a multi-part message in MIME format. ------_=_NextPart_001_01C68650.54CE8D55 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wow, there have been a lot of replies to this mailing list, I'm quite happy to see there is so much support out there! I sent an e-mail to Lennie Irvin and Daniel Jung on details as to what it is I am doing, and I figure I may as well copy & paste what I sent to them, since it contains all the information about my project: =20 =3D=3D=3D =20 I work for the Acadia Institute for Teaching & Technology which is located in Nova Scotia, Canada. I've gotten a job here as the title of "Web Developer", but during my interview I mentioned that I had created a MOO system as a software engineering project. It just so happened that one of the English professors at the university here was interested in making a MOO based around literature from his English courses, which would include material such as "Natural Daughter", a novel about how difficult it was to be a woman in the late 18th Century. So they put me on this project. He introduced me to the encore Xpress system, but he wasn't a programmer or a designer, so he wanted me to implement this thing. =20 I took a while getting familiar with the system and other systems I would be needing. Here's a quick overview of what I'm expected to do: =20 1. Redesign the front-end. This is everything as small as adding in extra fields to the Character Creation page, to a complete graphical overhaul of the user-interface to reflect the material. 2. Add in content, as well as program it so you are treated a certain way. For example, bots of men who talk to each other, but treat you unkindly, or that you have success points that can increase your stature as a woman. 3. Extra features, such as a user list and logging of student activities. 4. Write detailed instructions on how to use a MOO, and (more importantly), why it has anything to do with English majors. 5. I have exactly 2 and a half months to have this up-and-running (as of today). The content does not have to be COMPLETELY ready by then, since I'm allowed to work into the school year, but it must be presentable enough that students can go in and use it by then. =20 While trying to edit the front-end, I've already seen that the project is going to be a little more difficult than I initially expected. I am used to certain languages and technologies, such as JAVA, C and PHP, but this one works a little differently, sort of like a mix between the object-oriented aspects of JAVA and the dynamic webpage/database creation of PHP. However, resources for MOO programming and database are not nearly as numerous, and I will need help/documentation on the way to make the adjustment. I've tried adjusting the user creation to include a list that allows you to select which course you are in, for example, and have been reasonably successful... but my first attempt caused the Objects list to cease working correctly, and I was not familiar enough with the system to understand what the exception was. =20 I basically had to reverse engineer it to figure out how to do it. I searched the database to where the character creation took place, then located the fields. I added an extra field, and passed it as a parameter to $wiz_utils:make_player(), and then in $wiz_utils I edited the make_player() verb to accept four arguments, and then added a line "new.course =3D course;". I then changed the "generic player" object to contain a "course" property.=20 =20 Although this worked out reasonably well, it still involved more scouring than would have been necessary if the front-end had a solid documentation. =20 I've figured out more or less how the html files are produced; that is, that there's usually a variable called "html" that appends all the data using some special functions, like: =20 html =3D $list_utils:append(login, $encore_web_utils:p($encore_web_utils:a(tostr($core_homepage, "xpress_system_requirements.html"), "System Requirements", "_blank"))); =20 But what I don't understand are things like: =20 When I connect to the website (say "mooserver.website.com:7000" ), how does it know to load up object #162:login_page() ? Is there a way to get it to load up #132:login() instead? (for example) Also, the header of the output html (Title) are loaded in somewhere along the way, but aren't part of #162 itself. Where is this information loaded? Can it be overridden for #162 without affecting the other pages? What if for the login screen I'd like to use a custom stylesheet, so that the default inline is NOT loaded into the header? I tried setting "use_external_stylesheet" to "1", but it didn't seem to change anything. =20 These are the kinds of things that, as far as I've found, aren't clearly documented anywhere. If they are, I'd love to know what I've been missing! =20 =3D=3D=3D=3D =20 I know that this e-mail is quite long, but thanks for taking the time to read it. Hopefully I can get a lot of answers around here, because there's not that much else I have to find this stuff out! =20 Thanks, =20 Jean-Marc Giffin ------_=_NextPart_001_01C68650.54CE8D55 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wow, there have = been a lot of replies to this mailing list, I’m quite happy to see there is = so much support out there!

I sent an e-mail to = Lennie Irvin and Daniel Jung on details as to what it is I am doing, and I = figure I may as well copy & paste what I sent to them, since it contains all = the information about my project:

 

=3D=3D=3D

 

I work for the = Acadia Institute for Teaching & Technology which is located in Nova Scotia, Canada. I've gotten a job here as the title of "Web Developer", but = during my interview I mentioned that I had created a MOO system as a software = engineering project. It just so happened that one of the English professors at the university here was interested in making a MOO based around literature = from his English courses, which would include material such as "Natural Daughter", a novel about how difficult it was to be a woman in the = late 18th Century. So they put me on this project. He introduced me to the = encore Xpress system, but he wasn't a programmer or a designer, so he wanted me = to implement this thing.

 

I took a while = getting familiar with the system and other systems I would be needing. Here's a = quick overview of what I'm expected to do:

 

1. Redesign the = front-end. This is everything as small as adding in extra fields to the Character = Creation page, to a complete graphical overhaul of the user-interface to reflect = the material.

2. Add in content, = as well as program it so you are treated a certain way. For example, bots of men = who talk to each other, but treat you unkindly, or that you have success = points that can increase your stature as a woman.

3. Extra features, = such as a user list and logging of student = activities.

4. Write detailed instructions on how to use a MOO, and (more importantly), why it has = anything to do with English majors.

5. I have exactly 2 = and a half months to have this up-and-running (as of today). The content does = not have to be COMPLETELY ready by then, since I'm allowed to work into the = school year, but it must be presentable enough that students can go in and use = it by then.

 

While trying to = edit the front-end, I've already seen that the project is going to be a little = more difficult than I initially expected. I am used to certain languages and technologies, such as JAVA, C and PHP, but this one works a little = differently, sort of like a mix between the object-oriented aspects of JAVA and the = dynamic webpage/database creation of PHP. However, resources for MOO programming = and database are not nearly as numerous, and I will need help/documentation = on the way to make the adjustment. I've tried adjusting the user creation to = include a list that allows you to select which course you are in, for example, and = have been reasonably successful... but my first attempt caused the Objects = list to cease working correctly, and I was not familiar enough with the system = to understand what the exception was.

 

I basically had to = reverse engineer it to figure out how to do it. I searched the database to where = the character creation took place, then located the fields. I added an extra = field, and passed it as a parameter to $wiz_utils:make_player(), and then in $wiz_utils I edited the make_player() verb to accept four arguments, and = then added a line "new.course =3D course;". I then changed the = "generic player" object to contain a "course" property. =

 

Although this = worked out reasonably well, it still involved more scouring than would have been = necessary if the front-end had a solid documentation.

 

I've figured out = more or less how the html files are produced; that is, that there's usually a = variable called "html" that appends all the data using some special = functions, like:

 

html =3D $list_utils:append(login, $encore_web_utils:p($encore_web_utils:a(tostr($core_homepage, "xpress_system_requirements.html"), "System = Requirements", "_blank")));

 

But what I don't = understand are things like:

 

When I connect to = the website (say "mooserver.website.com:7000" ), how does it know = to load up object #162:login_page() ?

Is there a way to = get it to load up #132:login() instead? (for example) Also, the header of the = output html (<head><title>Title</title></head>) are loaded = in somewhere along the way, but aren't part of #162 itself. Where is this information loaded? Can it be overridden for #162 without affecting the = other pages? What if for the login screen I'd like to use a custom stylesheet, = so that the default inline <style> <!-- --> </style> is = NOT loaded into the header? I tried setting = “use_external_stylesheet” to “1”, but it didn’t seem to change = anything.

 

These are the kinds = of things that, as far as I've found, aren't clearly documented anywhere. = If they are, I'd love to know what I've been = missing!

 

=3D=3D=3D=3D

 

I know that this e-mail is quite long, but thanks for = taking the time to read it. Hopefully I can get a lot of answers around here, = because there’s not that much else I have to find this stuff = out!

 

Thanks,

 

Jean-Marc Giffin

------_=_NextPart_001_01C68650.54CE8D55-- From Lirvin@accdvm.accd.edu Sat Jun 3 08:03:42 2006 Received: with ECARTIS (v1.0.0; list encore); Sat, 03 Jun 2006 08:03:42 -0500 (CDT) Return-Path: X-Original-To: encore@nobel.utdallas.edu Delivered-To: encore@nobel.utdallas.edu Received: from iq1.utdallas.edu (iq1-pmn.utdallas.edu [192.168.1.7]) by nobel.utdallas.edu (Postfix) with ESMTP id 5D2C05E61 for ; Sat, 3 Jun 2006 08:03:42 -0500 (CDT) Received: from localhost (mf2-pmn.utdallas.edu [192.168.1.14]) by iq1.utdallas.edu (Postfix) with ESMTP id 2E00F48E0 for ; Sat, 3 Jun 2006 08:03:42 -0500 (CDT) Received: from mx2.utdallas.edu ([129.110.10.17]) by localhost (mf2.utdallas.edu [10.110.10.14]) (amavisd-new, port 10024) with LMTP id 04170-01-46 for ; Sat, 3 Jun 2006 08:03:38 -0500 (CDT) Received: from mx3.lsn.net (mx3.lsn.net [66.90.130.75]) by mx2.utdallas.edu (Postfix) with ESMTP id 636AE345C for ; Sat, 3 Jun 2006 08:03:38 -0500 (CDT) Received: from Gilgamesh.accdvm.accd.edu (72-48-64-55.dyn.grandenetworks.net [72.48.64.55]) by mx3.lsn.net (8.13.5/8.13.5) with ESMTP id k53D3ZH3003521; Sat, 3 Jun 2006 08:03:39 -0500 Message-Id: <6.2.5.6.0.20060603075725.029a4c98@accdvm.accd.edu> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 03 Jun 2006 08:03:42 -0500 To: encore@utdallas.edu From: Lennie Irvin Subject: [encore] NEH Grant Opportunities Cc: steering@encore-consortium.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1510/Sat Jun 3 07:07:20 2006 on mx0.lsn.net X-Virus-Status: Clean X-Virus-Scanned: amavisd-new at utdallas.edu X-archive-position: 1668 X-ecartis-version: Ecartis v1.0.0 Sender: encore-bounce@utdallas.edu Errors-to: encore-bounce@utdallas.edu X-original-sender: Lirvin@accdvm.accd.edu Precedence: bulk Reply-to: Lirvin@accdvm.accd.edu List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: X-list: encore Hi Everyone, I just corresponded with Paul Shovlin at Ohio University about some ideas about a possible NEH Grant application next Fall, and I thought I would share the description of the grant that I sent him. If you are interested in having your local site participate in this grant, I urge you respond to this email. Here's the description I sent Paul: First off, I would get your site and you associated with the enCore Consortium. http://www.encore-consortium.org/members/register.php I would have you and as many key interested faculty who use your enCore site sign up. The overall grant I think will have this structure: enCore Learning Spaces NEH Grant (Overall lead institution) / | \ / | \ Language Spaces Literary Spaces Writing Spaces (perhaps Online Spaces too)-- Lead institution for each main component of the grant | | | / | | \ / | | \ / | | \ Local institutions involved in the main goals of each component group--minimum of two schools needed for each component I don't know if this diagram helps, but it shows you where you might fit in. We would have an overall grant, but each specific local site would have some project that they would be working on related to the larger grant. The grant, hopefully, would funnel funds to your local site for that project as well as funnel funds to Univ. of Bergen or other schools for particular programming goals. There are three possible levels for you to fit in (pardon my names for the levels :)): 1) Big Cheese Level Lobby your school to take the lead and be the overall lead institution for the grant. This would mean having a good and experienced grants administration office that you have a pretty good working knowledge of and relationship with. This institution would be the official grant applicant. Also, you would need a committed faculty member to be the overseer for the grant. 2) Den Leader Level The grant works because we pull together enCore sites with similar learning goals and activities. These sites use enCore for a unique function and with a unique population. I propose calling each one a "Project" and each of the schools that join these projects will work together to define their own group's collaborative goals and objectives. For example, right now what Allen Webb is doing with Literary Worlds and what Jean-Marc is working on with his site at Acadia U. are very similar. Can these sites come together and define some common development goals that would benefit each of them and then think of ways to achieve these goals? We need a person to be the lead coordinator and instigator or each group who can get these enCore sites with similar goals working and communicating together. 3) Ground Level--local sites Each local site joining in the grant would need to have some local effort which this grant would help support and fund. It would mean having a local faculty person or group of faculty who work on and define projects or other activities for the grant. For instance, I plan on fitting within the "Writing Spaces" grant and want to use enCore with my online developmental English class (with the extended goal of opening up the space for other writing classes at my school to use if they wish). I also want to create and start using enCore with two local National Writing Project sites, so I might propose a week-long Open Institute about teaching writing via enCore that could be used by local public school teachers. It would probably also mean working with your local grant's administrator to make sure your portion of the grant application is kosher. Also, for the NEH Grant to work it would have to involve some kind of matching commitment from each school either in some funds or in in-kind contributions. Not every site may be able to come up with a match, though. I know one thing we will need is a website that works as "Grant central" with information about each constituent group and its particular goals. My hope is that starting from local sites we can sort of funnel up as we come together with our various projects and particular needs, and as we come together clear development goals will emerge. Maybe this grant effort will help you justify some continued funding for your site. I suppose the key thing is if people are using the site or have particular plans for it. In the meantime, you can check out High Five and show other people what it is like and hopefully get them excited about it. I think the key is to start locally. ********************************************************************* If you are interested in working on this NEH Grant and getting your local site on board, please let me know. ~Lennie From Lirvin@accdvm.accd.edu Sat Jun 3 08:35:20 2006 Received: with ECARTIS (v1.0.0; list encore); Sat, 03 Jun 2006 08:35:20 -0500 (CDT) Return-Path: X-Original-To: encore@nobel.utdallas.edu Delivered-To: encore@nobel.utdallas.edu Received: from iq1.utdallas.edu (iq1-pmn.utdallas.edu [192.168.1.7]) by nobel.utdallas.edu (Postfix) with ESMTP id 79FC05F40 for ; Sat, 3 Jun 2006 08:35:20 -0500 (CDT) Received: from localhost (mf2-pmn.utdallas.edu [192.168.1.14]) by iq1.utdallas.edu (Postfix) with ESMTP id 58B86496E for ; Sat, 3 Jun 2006 08:35:20 -0500 (CDT) Received: from mx2.utdallas.edu ([129.110.10.17]) by localhost (mf2.utdallas.edu [10.110.10.14]) (amavisd-new, port 10024) with LMTP id 04427-01-74 for ; Sat, 3 Jun 2006 08:35:15 -0500 (CDT) Received: from mx3.lsn.net (mx3.lsn.net [66.90.130.75]) by mx2.utdallas.edu (Postfix) with ESMTP id 8E8DE2CA1 for ; Sat, 3 Jun 2006 08:35:15 -0500 (CDT) Received: from Gilgamesh.accdvm.accd.edu (72-48-64-55.dyn.grandenetworks.net [72.48.64.55]) by mx3.lsn.net (8.13.5/8.13.5) with ESMTP id k53DZFMI022860; Sat, 3 Jun 2006 08:35:17 -0500 Message-Id: <6.2.5.6.0.20060603080351.029c7b18@accdvm.accd.edu> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 03 Jun 2006 08:35:14 -0500 To: encore@utdallas.edu From: Lennie Irvin Subject: [encore] MOO down--help needed!!! Cc: timothy.miley@wmich.edu Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10393625==.ALT" X-Virus-Scanned: ClamAV 0.88.2/1510/Sat Jun 3 07:07:20 2006 on mx0.lsn.net X-Virus-Status: Clean X-Virus-Scanned: amavisd-new at utdallas.edu X-archive-position: 1669 X-ecartis-version: Ecartis v1.0.0 Sender: encore-bounce@utdallas.edu Errors-to: encore-bounce@utdallas.edu X-original-sender: Lirvin@accdvm.accd.edu Precedence: bulk Reply-to: Lirvin@accdvm.accd.edu List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: X-list: encore --=====================_10393625==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I've been in correspondence with Tim Miley and Allen Webb at Secondary Worlds about some problems they have had transferring their moo from one server box to another. Right now, they are encountering some pretty major problems. They specifically are having trouble loading a backed up version of the database. I had a couple of questions to ask that could help them: 1) Are there any particular problems with moving a moo from a UNIX box to a Mac OS X box? 2) Question about restoring a backed up version of the database: Currently, they have a good copy of the database as a dbnew.db version (file name has "new" in it). Can someone confirm this as the proper restore sequence? Restoring a db from a dbnew.db version: 1) Save a copy of your backup dbnew.db file. 2) Rename this file db.db 3) Shut down moo 4) Physically replace the db.db file with the backup copy you just made. 5) Restart the moo Am I missing anything with this restore sequence? Here is a description of what they have currently been doing and the error they have been receiving: *************** The standard restart script was used. The moo read from the enCore.db file and wrote to enCore.db.new. A person off site copied the enCore.db.new file (I believe) while the MOO was running, so although we have an newer version archived by the offsite user, his version would not load. It gives the following error: >> May 26 14:54:38: VALIDATE: Phase 1: Check for invalid objects ... >> May 26 14:54:38: VALIDATE: Phase 2: Check for cycles ... >> May 26 14:54:38: VALIDATE: Phase 3: Check for inconsistencies ... >> May 26 14:54:38: VALIDATING the object hierarchies ... finished. >> May 26 14:54:38: LOADING: Reading 2666 MOO verb programs... >> May 26 14:54:40: LOADING: Done reading 2666 verb programs... >> May 26 14:54:40: LOADING: Reading forked and suspended tasks... >> May 26 14:54:40: *** DBIO_READ_NUM: Bad number: "" at file pos. 11526144 I would imagine that the problem results from attempting to copy a database file from a moo that is currently live, and thus constantly changing. *************************** If you have any answers, please reply to the encore list and cc: it to timothy.miley@wmich.edu Thanks for your help! Lennie \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ WHAT WE NEED DEVELOPED-- (Lennie dreams) A simple command for backing up and restoring the database. 1) Lennie clicks the Admin menu bar item 2) Lennie selects "Backup" button A dialogue box comes up asking me where I want to save the back up and gives me the opportunity to rename it (though it has a dated name by default) 3) Lennie clicks "Save" and a backup version of the database is put on his flash disk (The file could even be zipped if the db is large.) Restore-- 1) Lennie clicks the Admin menu bar item 2) Lennie selects the "Restore" button A dialogue box appears asking where the file to use for the restore is located. 3) Lennie selects the file and clicks OK. db restored! Automatic Scheduled Backup 1) Lennie clicks Admin menu bar item 2) Lennie clicks "Auto Backup" button A dialogue box appears asking how often auto back up should be done and where the file should be saved. I imagine the auto back up system would be a rolling series of files from five days. 3) Lennie makes his selections and clicks "Engage" to start the auto backup. (In fact, the autoback up should be set as a default for the program.) Autobackup Restore-- 1) Lennie clicks the Admin menu bar item 2) Lennie selects the "Restore from auto-back up" button. 3) Lennie selects the file to use and clicks "OK." db restored. I suppose the key for the scheduled auto-back ups is how to have copies made off the server in case the server explodes. But most servers these days have tape back ups, so once the whole server was backed up the particular backups for the moo could be done (I think?). I'm just dreaming here, but we need to make this process SIMPLE and RELIABLE. I suppose the "restore" function could be used when moving an enCore site from one server to another server too. Caught up in all this is the moo server restart script which I think works fine on a Unix box but is no existent for a Windows box. Anyone familiar with the way Moodle handles its backups and restores will see what I am after here. ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// --=====================_10393625==.ALT Content-Type: text/html; charset="us-ascii" I've been in correspondence with Tim Miley and Allen Webb at Secondary Worlds about some problems they have had transferring their moo from one server box to another.  Right now, they are encountering some pretty major problems.  They specifically are having trouble loading a backed up version of the database.  I had a couple of questions to ask that could help them:

1) Are there any particular problems with moving a moo from a UNIX box to a Mac OS X box? 

2) Question about restoring a backed up version of the database:  Currently, they have a good copy of the database as a dbnew.db version  (file name has "new" in it).
Can someone confirm this as the proper restore sequence?

Restoring a db from a dbnew.db version:

1) Save a copy of your backup dbnew.db file.
2) Rename this file db.db
3) Shut down moo
4) Physically replace the db.db file with the backup copy you just made.
5) Restart the moo

Am I missing anything with this restore sequence?  Here is a description of what they have currently been doing and the error they have been receiving:

***************
The standard restart script was used.  The moo read from the enCore.db file and wrote to enCore.db.new.  A person off site copied the enCore.db.new file (I believe) while the MOO was running, so although we have an newer version archived by the offsite user, his version would not load.  It gives the following error:

>> May 26 14:54:38: VALIDATE: Phase 1: Check for invalid objects ...
>> May 26 14:54:38: VALIDATE: Phase 2: Check for cycles ...
>> May 26 14:54:38: VALIDATE: Phase 3: Check for inconsistencies ...
>> May 26 14:54:38: VALIDATING the object hierarchies ... finished.
>> May 26 14:54:38: LOADING: Reading 2666 MOO verb programs...
>> May 26 14:54:40: LOADING: Done reading 2666 verb programs...
>> May 26 14:54:40: LOADING: Reading forked and suspended tasks...
>> May 26 14:54:40: *** DBIO_READ_NUM: Bad number: "" at file pos. 11526144

I would imagine that the problem results from attempting to copy a database file from a moo that is currently live, and thus constantly changing.
***************************

If you have any answers, please reply to the encore list and cc: it to timothy.miley@wmich.edu

Thanks for your help!

Lennie


\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
WHAT WE NEED DEVELOPED-- (Lennie dreams)

A simple command for backing up and restoring the database.

1) Lennie clicks the Admin menu bar item
2) Lennie selects "Backup" button
A dialogue box comes up asking me where I want to save the back up and gives me the opportunity to rename it (though it has a dated name by default)
3) Lennie clicks "Save" and a backup version of the database is put on his flash disk
(The file could even be zipped if the db is large.)

Restore--
1) Lennie clicks the Admin menu bar item
2) Lennie selects the "Restore" button
A dialogue box appears asking where the file to use for the restore is located.
3) Lennie selects the file and clicks OK.  db restored!

Automatic Scheduled Backup
1) Lennie clicks Admin menu bar item
2) Lennie clicks "Auto Backup" button
A dialogue box appears asking how often auto back up should be done and where the file should be saved.  I imagine the auto back up system would be a rolling series of files from five days.
3) Lennie makes his selections and clicks "Engage" to start the auto backup.
(In fact, the autoback up should be set as a default for the program.)

Autobackup Restore--
1) Lennie clicks the Admin menu bar item
2) Lennie selects the "Restore from auto-back up" button.
3) Lennie selects the file to use and clicks "OK."  db restored.

I suppose the key for the scheduled auto-back ups is how to have copies made off the server in case the server explodes.  But most servers these days have tape back ups, so once the whole server was backed up the particular backups for the moo could be done (I think?).

I'm just dreaming here, but we need to make this process SIMPLE and RELIABLE.  I suppose the "restore" function could be used when moving an enCore site from one server to another server too.  Caught up in all this is the moo server restart script which I think works fine on a Unix box but is no existent for a Windows box. 

Anyone familiar with the way Moodle handles its backups and restores will see what I am after here. 

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////



--=====================_10393625==.ALT-- From kevijeps@telusplanet.net Sat Jun 3 09:53:22 2006 Received: with ECARTIS (v1.0.0; list encore); Sat, 03 Jun 2006 09:53:23 -0500 (CDT) Return-Path: X-Original-To: encore@nobel.utdallas.edu Delivered-To: encore@nobel.utdallas.edu Received: from iq1.utdallas.edu (iq1-pmn.utdallas.edu [192.168.1.7]) by nobel.utdallas.edu (Postfix) with ESMTP id B58D3605F for ; Sat, 3 Jun 2006 09:53:22 -0500 (CDT) Received: from localhost (mf2-pmn.utdallas.edu [192.168.1.14]) by iq1.utdallas.edu (Postfix) with ESMTP id 80E7E4D6B for ; Sat, 3 Jun 2006 09:53:22 -0500 (CDT) Received: from mx2.utdallas.edu ([129.110.10.17]) by localhost (mf2.utdallas.edu [10.110.10.14]) (amavisd-new, port 10024) with LMTP id 08784-01-26 for ; Sat, 3 Jun 2006 09:53:14 -0500 (CDT) Received: from priv-edtnes16.telusplanet.net (outbound04.telus.net [199.185.220.223]) by mx2.utdallas.edu (Postfix) with ESMTP id 185CE3452 for ; Sat, 3 Jun 2006 09:53:13 -0500 (CDT) Received: from priv-edtnaa05.telusplanet.net ([199.126.223.252]) by priv-edtnes16.telusplanet.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20060603145312.CUSM4642.priv-edtnes16.telusplanet.net@priv-edtnaa05.telusplanet.net>; Sat, 3 Jun 2006 08:53:12 -0600 Received: from lilith (d199-126-223-252.abhsia.telus.net [199.126.223.252]) by priv-edtnaa05.telusplanet.net (BorderWare MXtreme Infinity Mail Firewall) with ESMTP id 25XQ3SGDVH; Sat, 3 Jun 2006 08:53:11 -0600 (MDT) From: "Kevin Jepson" To: , Cc: Subject: [encore] Re: MOO down--help needed!!! Date: Sat, 3 Jun 2006 08:52:36 -0600 Message-ID: <002001c6871d$5c4e3b30$5a0119ac@lilith> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C686EB.11B3CB30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal In-Reply-To: <6.2.5.6.0.20060603080351.029c7b18@accdvm.accd.edu> X-Virus-Scanned: amavisd-new at utdallas.edu X-archive-position: 1670 X-ecartis-version: Ecartis v1.0.0 Sender: encore-bounce@utdallas.edu Errors-to: encore-bounce@utdallas.edu X-original-sender: kevijeps@telusplanet.net Precedence: bulk Reply-to: kevijeps@telusplanet.net List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: X-list: encore This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C686EB.11B3CB30 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Lennie =20 It looks to me like the backup copy of the database is corrupted = somehow. =20 The standard checkpoint copy is the "encore.db.new" file and it is = always made when the MOO is running so that shouldn't cause a problem.. =20 Did this restart error come up when the old MOO was restarted or was it = on the new system? =20 As for the procedure to move it (assuming no OS problems with OS X) I = would do this: =20 If the old MOO is still running copy encore.db.new from old server.=20 =20 On the new server load the encore.db.new file and rename it encore.db. =20 Start the new MOO using the standard script. =20 Ciao KJ=20 -----Original Message----- From: encore-bounce@utdallas.edu [mailto:encore-bounce@utdallas.edu] On Behalf Of Lennie Irvin Sent: June 3, 2006 7:35 AM To: encore@utdallas.edu Cc: timothy.miley@wmich.edu Subject: [encore] MOO down--help needed!!! I've been in correspondence with Tim Miley and Allen Webb at Secondary Worlds about some problems they have had transferring their moo from one server box to another. Right now, they are encountering some pretty = major problems. They specifically are having trouble loading a backed up = version of the database. I had a couple of questions to ask that could help = them: 1) Are there any particular problems with moving a moo from a UNIX box = to a Mac OS X box? =20 2) Question about restoring a backed up version of the database: = Currently, they have a good copy of the database as a dbnew.db version (file name = has "new" in it). Can someone confirm this as the proper restore sequence? Restoring a db from a dbnew.db version: 1) Save a copy of your backup dbnew.db file. 2) Rename this file db.db 3) Shut down moo 4) Physically replace the db.db file with the backup copy you just made. 5) Restart the moo Am I missing anything with this restore sequence? Here is a description = of what they have currently been doing and the error they have been = receiving: *************** The standard restart script was used. The moo read from the enCore.db = file and wrote to enCore.db.new. A person off site copied the enCore.db.new = file (I believe) while the MOO was running, so although we have an newer = version archived by the offsite user, his version would not load. It gives the following error: >> May 26 14:54:38: VALIDATE: Phase 1: Check for invalid objects ... >> May 26 14:54:38: VALIDATE: Phase 2: Check for cycles ... >> May 26 14:54:38: VALIDATE: Phase 3: Check for inconsistencies ... >> May 26 14:54:38: VALIDATING the object hierarchies ... finished. >> May 26 14:54:38: LOADING: Reading 2666 MOO verb programs... >> May 26 14:54:40: LOADING: Done reading 2666 verb programs... >> May 26 14:54:40: LOADING: Reading forked and suspended tasks... >> May 26 14:54:40: *** DBIO_READ_NUM: Bad number: "" at file pos. = 11526144 I would imagine that the problem results from attempting to copy a = database file from a moo that is currently live, and thus constantly changing. *************************** If you have any answers, please reply to the encore list and cc: it to timothy.miley@wmich.edu=20 Thanks for your help! Lennie =20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: = 02/06/2006 =20 ------=_NextPart_000_0021_01C686EB.11B3CB30 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Message
Lennie
 
It=20 looks to me like the backup copy of the database is corrupted=20 somehow.
 
The=20 standard checkpoint copy is the "encore.db.new" file and it is always = made when=20 the MOO is running so that shouldn't cause a = problem..
 
Did=20 this restart error come up when the old MOO was restarted or was it = on the=20 new system?
 
As for=20 the procedure to move it (assuming no OS problems with OS X) I would do=20 this:
 
If the=20 old MOO is still running copy encore.db.new from old server.=20
 
On the=20 new server load the encore.db.new file and rename it=20 encore.db.
 
Start=20 the new MOO using the standard script.
 
Ciao
KJ 
-----Original Message-----
From:=20 encore-bounce@utdallas.edu [mailto:encore-bounce@utdallas.edu] On = Behalf Of=20 Lennie Irvin
Sent: June 3, 2006 7:35 AM
To:=20 encore@utdallas.edu
Cc: = timothy.miley@wmich.edu
Subject:=20 [encore] MOO down--help needed!!!

I've been in=20 correspondence with Tim Miley and Allen Webb at Secondary Worlds about = some=20 problems they have had transferring their moo from one server box to=20 another.  Right now, they are encountering some pretty major=20 problems.  They specifically are having trouble loading a backed = up=20 version of the database.  I had a couple of questions to ask that = could=20 help them:

1) Are there any particular problems with moving a = moo from=20 a UNIX box to a Mac OS X box? 

2) Question about = restoring a=20 backed up version of the database:  Currently, they have a good = copy of=20 the database as a dbnew.db version  (file name has "new" in = it).
Can=20 someone confirm this as the proper restore sequence?

Restoring = a db=20 from a dbnew.db version:

1) Save a copy of your backup dbnew.db = file.
2) Rename this file db.db
3) Shut down moo
4) = Physically=20 replace the db.db file with the backup copy you just made.
5) = Restart the=20 moo

Am I missing anything with this restore sequence?  = Here is a=20 description of what they have currently been doing and the error they = have=20 been receiving:

***************
The standard restart script = was=20 used.  The moo read from the enCore.db file and wrote to=20 enCore.db.new.  A person off site copied the enCore.db.new file = (I=20 believe) while the MOO was running, so although we have an newer = version=20 archived by the offsite user, his version would not load.  It = gives the=20 following error:

>> May 26 14:54:38: VALIDATE: Phase 1: = Check for=20 invalid objects ...
>> May 26 14:54:38: VALIDATE: Phase 2: = Check for=20 cycles ...
>> May 26 14:54:38: VALIDATE: Phase 3: Check for=20 inconsistencies ...
>> May 26 14:54:38: VALIDATING the object = hierarchies ... finished.
>> May 26 14:54:38: LOADING: = Reading 2666=20 MOO verb programs...
>> May 26 14:54:40: LOADING: Done = reading 2666=20 verb programs...
>> May 26 14:54:40: LOADING: Reading forked = and=20 suspended tasks...
>> May 26 14:54:40: *** DBIO_READ_NUM: Bad = number:=20 "" at file pos. 11526144

I would imagine that the problem = results from=20 attempting to copy a database file from a moo that is currently live, = and thus=20 constantly changing.
***************************

If you have = any=20 answers, please reply to the encore list and cc: it to = timothy.miley@wmich.edu=20

Thanks for your help!

Lennie

 


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: = 02/06/2006

------=_NextPart_000_0021_01C686EB.11B3CB30-- From kevijeps@telusplanet.net Sat Jun 3 21:08:12 2006 Received: with ECARTIS (v1.0.0; list encore); Sat, 03 Jun 2006 21:08:12 -0500 (CDT) Return-Path: X-Original-To: encore@nobel.utdallas.edu Delivered-To: encore@nobel.utdallas.edu Received: from iq1.utdallas.edu (iq1-pmn.utdallas.edu [192.168.1.7]) by nobel.utdallas.edu (Postfix) with ESMTP id 7CE535BB3 for ; Sat, 3 Jun 2006 21:08:12 -0500 (CDT) Received: from localhost (mf2-pmn.utdallas.edu [192.168.1.14]) by iq1.utdallas.edu (Postfix) with ESMTP id 2973C472E for ; Sat, 3 Jun 2006 21:08:12 -0500 (CDT) Received: from mx2.utdallas.edu ([129.110.10.17]) by localhost (mf2.utdallas.edu [10.110.10.14]) (amavisd-new, port 10024) with LMTP id 11083-01-30 for ; Sat, 3 Jun 2006 21:08:08 -0500 (CDT) Received: from priv-edtnes90.telusplanet.net (defout.telus.net [199.185.220.240]) by mx2.utdallas.edu (Postfix) with ESMTP id 451713452 for ; Sat, 3 Jun 2006 21:08:07 -0500 (CDT) Received: from priv-edtnaa05.telusplanet.net ([199.126.223.252]) by priv-edtnes90.telusplanet.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20060604020806.ZJEQ11335.priv-edtnes90.telusplanet.net@priv-edtnaa05.telusplanet.net>; Sat, 3 Jun 2006 20:08:06 -0600 Received: from lilith (d199-126-223-252.abhsia.telus.net [199.126.223.252]) by priv-edtnaa05.telusplanet.net (BorderWare MXtreme Infinity Mail Firewall) with ESMTP id CCST2PJFGJ; Sat, 3 Jun 2006 20:08:05 -0600 (MDT) From: "Kevin Jepson" To: , Subject: [encore] Re: enCoring Date: Sat, 3 Jun 2006 20:07:33 -0600 Message-ID: <002c01c6877b$a543d0d0$5a0119ac@lilith> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C68749.5AA960D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal In-Reply-To: X-Virus-Scanned: amavisd-new at utdallas.edu X-archive-position: 1671 X-ecartis-version: Ecartis v1.0.0 Sender: encore-bounce@utdallas.edu Errors-to: encore-bounce@utdallas.edu X-original-sender: kevijeps@telusplanet.net Precedence: bulk Reply-to: kevijeps@telusplanet.net List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: X-list: encore This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C68749.5AA960D0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi Jean-Marc =20 Your project sounds really interesting. =20 Do you really need to change the default WEB behaviour so extensively? =20 EnCore is a superb "out of the box" system, however the compromises that have been made to help it be so make it pretty difficult to modify, = IMHO. =20 What follows is a bit lengthy but may be of some use in letting you know what you are getting into :-) =20 The problem here is that the WEB side isn't really generated by the MOO = per se. It is generated by MOO code that runs in parallel to the traditional LambdaMoo (which is text and command line based). According to typical = MOO methodology the objects themselves, as children of generic objects, = should do all the output generation OR let the code on their parents do it if = the standard procedure is fine. In EnCore that is not the case. The _html = verb on objects allows some (minor) modifications of the WEB display = behaviour but the main WEB display is generated by the $httpd webserver itself = (using the $encore_web_utils). =20 The basic WEB page layout, styles, link behaviours etc, are NOT under = the control of the object hierarchy. This means that making big = functionality changes, like a new class of room/environment for example, become very tricky. Making such changes in a text based traditional MOO is almost trivial once the programmer understands the language syntax and the = object oriented system. =20 Before the hounds are unleashed to chide me for my heresy :-) let me say that EnCore is a good system precisely because it does not require a lot = of coding to get a functional education and learning environment up and running. =20 We pay for that ease of use in a lack of configurability however. This = can be readily seen when one looks at EnCore MOOs in general...THEY ALL LOOK PRETTY MUCH THE SAME. This is not simply because there is a common user interface, the Xpress system, but because changing the WEB display is complex enough to make most non-tech non-programmer Wizards think twice about making major changes. =20 As an example of how this non-standard style gets in the way, let me = briefly describe a problem I've been fighting with. =20 I've been trying for several years now to integrate a more complex room class into my EnCore v4.1 MOO. The room class I want to use is a "multi-room", that is a single object that has integrated features like containers and furniture and an internal virtual Room/Exit structure. = This class is used in my MOO to represent vehicles, like sailing ships, submarines and airships, as well as traditional buildings/spaces. As a single object, moving them as ships or vehicles within the containment hierarchy, to represent movement through the world, is very easy. Once ported to my MOO they worked flawlessly on the TEXT side! =20 =20 As you have already found out, trying to hunt down where the various WEB display elements come from has been quite a challenge. A simple example = is how the WEB side of the Xpress interface displays these objects. =20 =20 In short it doesn't! =20 =20 They appear in the WEB display as room objects. If the user clicks on = them, which with a normal non-room object shows the user the objects = description, they are summarily moved INTO the object! Since the internal room/exit structure is not standard the EnCore WEB server has no clue how to = display it and defaults to the entrance room's description and the contents of = the room only. Both these behaviours seriously break the result the users expected and is confusing. =20 So, what to do? =20 I started rummaging around in the WEB generating code looking for verbs = that I could recreate/modify etc to get Xpress to display the multi-room as = the user would expect. (Reverse engineering as you so aptly put it)=20 =20 It does not appear to be possible to do that and here is why, the verbs which generate all this display DO NOT USE THE OBJECT'S VERBS for their input. So instead of calling the objects version of the "look" and "look_self" verbs to get the description it tries to read the Objects description property! This class has to replace the standard look and look_self verbs to handle the virtual room structure and to make sure objects that are in/under features or in other virtual rooms aren't displayed. Consequently the description property is never really = correct. EnCore does not follow the rules and tries to bypass the MOO object hierarchy to make it's display thus making such "on the fly" changes = almost impossible to achieve. =20 There is no mechanism to recreate this display process because the = enCore verbs are 1) WIZ owned, 2) not really aware of the user in MOO space, 3) stuck trying to both generate an interactive display AND generate a WEB display where no user is really present at all (browsing from the WEB), = 4) scattered across several objects and utilities such that trying to = customize them has potentially bad effects on the system as a whole. =20 End result for me was to actually turn OFF the display of the WEB side entirely while keeping the rest of the Xpress interface. =20 Certainly not an optimal solution but better than the immersion breaking that results from Xpress trying to deal with this new class of objects. =20 So, after all that... =20 You seem to have a fairly short time in which to get your system up so I would recommend that if you don't really need to modify the base EnCore system you might want to leave it alone and concentrate on working = within the limitations. =20 =20 Unless you really like the challenge of course. :-) =20 I'd be happy to describe/discuss these problems in more detail if you = like on list or off, either way. Maybe there is a better way and I've just = can't see the "forest for the trees". =20 Ciao KJ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Kevin Jepson R.E.T. President 4K Consulting Inc. =20 An't nanum hearm deth, doth hwaet ye willath. Email: kevijeps@telusplanet.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: = 02/06/2006 =20 ------=_NextPart_000_002D_01C68749.5AA960D0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Jean-Marc
 
Your=20 project sounds really interesting.
 
Do you=20 really need to change the default WEB behaviour so=20 extensively?
 
EnCore=20 is a superb "out of the box" system, however the compromises that have = been made=20 to help it be so make it pretty difficult to modify, = IMHO.
 
What=20 follows is a bit lengthy but may be of some use in letting you know what = you are=20 getting into :-)
 
The=20 problem here is that the WEB side isn't really generated by the MOO per = se. It=20 is generated by MOO code that runs in parallel to the = traditional LambdaMoo=20 (which is text and command line based).  According to typical MOO=20 methodology the objects themselves, as children of generic objects, = should=20 do all the output generation OR let the code on their parents do it = if the=20 standard procedure is fine.  In EnCore that is not the case. The = _html verb=20 on objects allows some (minor) modifications of the WEB display = behaviour but=20 the main WEB display is generated by the $httpd webserver itself (using = the=20 $encore_web_utils).
 
The=20 basic WEB page layout, styles, link behaviours etc, are NOT under the = control of=20 the object hierarchy.  This means that making big functionality = changes,=20 like a new class of room/environment for example, become very = tricky. =20 Making such changes in a text based traditional MOO is almost = trivial=20 once the programmer understands the language syntax and the object = oriented=20 system.
 
Before=20 the hounds are unleashed to chide me for my heresy :-) let me say that = EnCore is=20 a good system precisely because it does not require a lot of coding to = get a=20 functional education and learning environment up and=20 running.
 
We pay=20 for that ease of use in a lack of configurability however.  This = can be=20 readily seen when one looks at EnCore MOOs in general...THEY ALL = LOOK=20 PRETTY MUCH THE SAME.  This is not simply because there is a = common=20 user interface, the Xpress system, but because changing the WEB display = is=20 complex enough to make most non-tech non-programmer Wizards think = twice=20 about making major changes.
 
As an=20 example of how this non-standard style gets in the way, let me briefly = describe=20 a problem I've been fighting with.
 
 I've been trying for several years now to integrate a = more=20 complex room class into my = EnCore v4.1=20 MOO.  The room class I want to use is a "multi-room", that is = a single=20 object that has integrated features like containers and furniture = and an=20 internal virtual Room/Exit structure.  This class is used in my MOO = to=20 represent vehicles, like sailing ships, submarines and airships, as = well as=20 traditional buildings/spaces. As a single object, moving them as ships = or=20 vehicles within the containment hierarchy, to represent movement = through=20 the world, is very easy. Once ported to my MOO they worked flawlessly on = the=20 TEXT side!  
 
As you=20 have already found out, trying to hunt down where the various WEB = display=20 elements come from has been quite a challenge.  A simple example=20 is how the WEB side of the Xpress interface displays these = objects. =20
 
In=20 short it doesn't! 
 
They=20 appear in the WEB display as room objects.  If the user clicks = on=20 them, which with a normal non-room object shows the user the = objects=20 description, they are summarily moved INTO the object!  Since = the=20 internal room/exit structure is not standard the EnCore WEB server has = no clue=20 how to display it and defaults to the entrance room's = description and=20 the contents of the room only. Both these behaviours seriously break the = result=20 the users expected and is confusing.
 
So,=20 what to do?
 
I=20 started rummaging around in the WEB generating code looking for verbs = that I=20 could recreate/modify etc to get Xpress to display the multi-room = as the=20 user would expect. (Reverse engineering as you so aptly put=20 it) 
 
It=20 does not appear to be possible to do that and here is why, the verbs = which=20 generate all this display DO NOT USE THE OBJECT'S VERBS for their = input. =20 So instead of calling the objects version of the "look" and=20 "look_self" verbs to get the description it tries to read the = Objects=20 description property!  This class has to replace the standard look=20 and look_self verbs to handle the virtual room structure and to = make sure=20 objects that are in/under features or in other virtual rooms aren't = displayed. Consequently the description property is never really=20 correct. EnCore does not follow the rules and tries to bypass = the MOO=20 object hierarchy to make it's display thus making such "on the fly" = changes=20 almost impossible to achieve.
 
There=20 is no mechanism to recreate this display process because the enCore = verbs are=20 1) WIZ owned, 2) not really aware of the user in MOO space, 3) = stuck trying to = both generate=20 an interactive display AND generate a WEB display where no user is = really=20 present at all (browsing from the WEB), 4) scattered across several = objects and=20 utilities such that trying to customize them has potentially bad effects = on the=20 system as a whole.
 
End=20 result for me was to actually turn OFF the display of the WEB side = entirely=20 while keeping the rest of the Xpress interface.
 
Certainly not an optimal solution but better than the immersion = breaking=20 that results from Xpress trying to deal with this new class of=20 objects.
 
So,=20 after all that...
 
You=20 seem to have a fairly short time in which to get your system up = so I would=20 recommend that if you don't really need to modify the base EnCore = system=20 you might want to leave it alone and concentrate on working within the=20 limitations. 
 
Unless=20 you really like the challenge of course. :-)
 
I'd be=20 happy to describe/discuss these problems in more detail if you = like on=20 list or off, either way. Maybe there is a better way and I've just = can't=20 see the "forest for the trees".
 
Ciao
KJ
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Kevin=20 Jepson R.E.T.
President
4K Consulting=20 Inc.           &nb= sp;        
An't=20 nanum hearm deth, doth hwaet ye willath.

Email:=20 kevijeps@telusplanet.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: = 02/06/2006

------=_NextPart_000_002D_01C68749.5AA960D0-- From Lirvin@accdvm.accd.edu Sun Jun 4 08:24:10 2006 Received: with ECARTIS (v1.0.0; list encore); Sun, 04 Jun 2006 08:24:10 -0500 (CDT) Return-Path: X-Original-To: encore@nobel.utdallas.edu Delivered-To: encore@nobel.utdallas.edu Received: from iq1.utdallas.edu (iq1-pmn.utdallas.edu [192.168.1.7]) by nobel.utdallas.edu (Postfix) with ESMTP id 0D7285BB3 for ; Sun, 4 Jun 2006 08:24:09 -0500 (CDT) Received: from localhost (mf2-pmn.utdallas.edu [192.168.1.14]) by iq1.utdallas.edu (Postfix) with ESMTP id BB4EE2D00 for ; Sun, 4 Jun 2006 08:24:09 -0500 (CDT) Received: from mx2.utdallas.edu ([129.110.10.17]) by localhost (mf2.utdallas.edu [10.110.10.14]) (amavisd-new, port 10024) with LMTP id 01226-01-23 for ; Sun, 4 Jun 2006 08:24:06 -0500 (CDT) Received: from mx3.lsn.net (mx3.lsn.net [66.90.130.75]) by mx2.utdallas.edu (Postfix) with ESMTP id 3692D3452 for ; Sun, 4 Jun 2006 08:24:06 -0500 (CDT) Received: from Gilgamesh.accdvm.accd.edu (72-48-64-55.dyn.grandenetworks.net [72.48.64.55]) by mx3.lsn.net (8.13.5/8.13.5) with ESMTP id k54DO3Qd009150; Sun, 4 Jun 2006 08:24:05 -0500 Message-Id: <6.2.5.6.0.20060604081206.029a7d70@accdvm.accd.edu> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 04 Jun 2006 08:23:56 -0500 To: "Kevin Jepson" , From: Lennie Irvin Subject: [encore] Re: MOO down--help needed!!! Cc: In-Reply-To: <002001c6871d$5c4e3b30$5a0119ac@lilith> References: <6.2.5.6.0.20060603080351.029c7b18@accdvm.accd.edu> <002001c6871d$5c4e3b30$5a0119ac@lilith> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_96123781==.ALT" X-Virus-Scanned: ClamAV 0.88.2/1512/Sun Jun 4 04:58:49 2006 on mx0.lsn.net X-Virus-Status: Clean X-Virus-Scanned: amavisd-new at utdallas.edu X-archive-position: 1672 X-ecartis-version: Ecartis v1.0.0 Sender: encore-bounce@utdallas.edu Errors-to: encore-bounce@utdallas.edu X-original-sender: Lirvin@accdvm.accd.edu Precedence: bulk Reply-to: Lirvin@accdvm.accd.edu List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: X-list: encore --=====================_96123781==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed From what I understand of their situation, they had run out of memory on the previous server. Would that account for the corruption to the backup copy of the database? Tell me if this scenario could be what happened: Every time the moo checkpointed, it backed itself up to the encore.db.new file, but the server said wait a minute, you don't have room and denied the writing of the new version of the file? I don't know? It seems that if they had memory problems on that server it would also have limited their ability to create ANY new objects in the moo. I believe they were active in the moo creating things during this period when the server was supposed to be out of memory. It seems like there would have been an error message even when they created a single object in the moo in this case? It seems like it might be important to pin down the dates for when the server ran out of memory. If you get the exact date, you could find the encore.db.new from the day before the server ran out of memory and see if that version worked. As another option, I presume that the server was having tape backups made of it? If somehow the encore.db.new was not copying but the encore.db.db was able to take new data, then perhaps the tape backup of just the encore.db.db might work? Tim--I hope you are able to get you moo back up and running. Keep us informed! Lennie At 09:52 AM 6/3/2006, Kevin Jepson wrote: >Lennie > >It looks to me like the backup copy of the database is corrupted somehow. > >The standard checkpoint copy is the "encore.db.new" file and it is >always made when the MOO is running so that shouldn't cause a problem.. > >Did this restart error come up when the old MOO was restarted or was >it on the new system? > >As for the procedure to move it (assuming no OS problems with OS X) >I would do this: > >If the old MOO is still running copy encore.db.new from old server. > >On the new server load the encore.db.new file and rename it encore.db. > >Start the new MOO using the standard script. > >Ciao >KJ >-----Original Message----- >From: encore-bounce@utdallas.edu [mailto:encore-bounce@utdallas.edu] >On Behalf Of Lennie Irvin >Sent: June 3, 2006 7:35 AM >To: encore@utdallas.edu >Cc: timothy.miley@wmich.edu >Subject: [encore] MOO down--help needed!!! > >I've been in correspondence with Tim Miley and Allen Webb at >Secondary Worlds about some problems they have had transferring >their moo from one server box to another. Right now, they are >encountering some pretty major problems. They specifically are >having trouble loading a backed up version of the database. I had a >couple of questions to ask that could help them: > >1) Are there any particular problems with moving a moo from a UNIX >box to a Mac OS X box? > >2) Question about restoring a backed up version of the >database: Currently, they have a good copy of the database as a >dbnew.db version (file name has "new" in it). >Can someone confirm this as the proper restore sequence? > >Restoring a db from a dbnew.db version: > >1) Save a copy of your backup dbnew.db file. >2) Rename this file db.db >3) Shut down moo >4) Physically replace the db.db file with the backup copy you just made. >5) Restart the moo > >Am I missing anything with this restore sequence? Here is a >description of what they have currently been doing and the error >they have been receiving: > >*************** >The standard restart script was used. The moo read from the >enCore.db file and wrote to enCore.db.new. A person off site copied >the enCore.db.new file (I believe) while the MOO was running, so >although we have an newer version archived by the offsite user, his >version would not load. It gives the following error: > > >> May 26 14:54:38: VALIDATE: Phase 1: Check for invalid objects ... > >> May 26 14:54:38: VALIDATE: Phase 2: Check for cycles ... > >> May 26 14:54:38: VALIDATE: Phase 3: Check for inconsistencies ... > >> May 26 14:54:38: VALIDATING the object hierarchies ... finished. > >> May 26 14:54:38: LOADING: Reading 2666 MOO verb programs... > >> May 26 14:54:40: LOADING: Done reading 2666 verb programs... > >> May 26 14:54:40: LOADING: Reading forked and suspended tasks... > >> May 26 14:54:40: *** DBIO_READ_NUM: Bad number: "" at file pos. 11526144 > >I would imagine that the problem results from attempting to copy a >database file from a moo that is currently live, and thus constantly changing. >*************************** > >If you have any answers, please reply to the encore list and cc: it >to timothy.miley@wmich.edu > >Thanks for your help! > >Lennie > > > > >-- >No virus found in this outgoing message. >Checked by AVG Free Edition. >Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 02/06/2006 --=====================_96123781==.ALT Content-Type: text/html; charset="us-ascii" From what I understand of their situation, they had run out of memory on the previous server.  Would that account for the corruption to the backup copy of the database?

Tell me if this scenario could be what happened:  Every time the moo checkpointed, it backed itself up to the encore.db.new file, but the server said wait a minute, you don't have room and denied the writing of the new version of the file?  I don't know?  It seems that if they had memory problems on that server it would also have limited their ability to create ANY new objects in the moo.  I believe they were active in the moo creating things during this period when the server was supposed to be out of memory.  It seems like there would have been an error message even when they created a single object in the moo in this case?

It seems like it might be important to pin down the dates for when the server ran out of memory.  If you get the exact date, you could find the encore.db.new from the day before the server ran out of memory and see if that version worked.

As another option, I presume that the server was having tape backups made of it? If somehow the encore.db.new was not copying but the encore.db.db was able to take new data, then perhaps the tape backup of just the encore.db.db might work? 

Tim--I hope you are able to get you moo back up and running.  Keep us informed!

Lennie


At 09:52 AM 6/3/2006, Kevin Jepson wrote:
Lennie
 
It looks to me like the backup copy of the database is corrupted somehow.
 
The standard checkpoint copy is the "encore.db.new" file and it is always made when the MOO is running so that shouldn't cause a problem..
 
Did this restart error come up when the old MOO was restarted or was it on the new system?
 
As for the procedure to move it (assuming no OS problems with OS X) I would do this:
 
If the old MOO is still running copy encore.db.new from old server.
 
On the new server load the encore.db.new file and rename it encore.db.
 
Start the new MOO using the standard script.
 
Ciao
KJ
-----Original Message-----
From: encore-bounce@utdallas.edu [ mailto:encore-bounce@utdallas.edu] On Behalf Of Lennie Irvin
Sent: June 3, 2006 7:35 AM
To: encore@utdallas.edu
Cc: timothy.miley@wmich.edu
Subject: [encore] MOO down--help needed!!!
I've been in correspondence with Tim Miley and Allen Webb at Secondary Worlds about some problems they have had transferring their moo from one server box to another.  Right now, they are encountering some pretty major problems.  They specifically are having trouble loading a backed up version of the database.  I had a couple of questions to ask that could help them:

1) Are there any particular problems with moving a moo from a UNIX box to a Mac OS X box? 

2) Question about restoring a backed up version of the database:  Currently, they have a good copy of the database as a dbnew.db version  (file name has "new" in it).
Can someone confirm this as the proper restore sequence?

Restoring a db from a dbnew.db version:

1) Save a copy of your backup dbnew.db file.
2) Rename this file db.db
3) Shut down moo
4) Physically replace the db.db file with the backup copy you just made.
5) Restart the moo

Am I missing anything with this restore sequence?  Here is a description of what they have currently been doing and the error they have been receiving:

***************
The standard restart script was used.  The moo read from the enCore.db file and wrote to enCore.db.new.  A person off site copied the enCore.db.new file (I believe) while the MOO was running, so although we have an newer version archived by the offsite user, his version would not load.  It gives the following error:

>> May 26 14:54:38: VALIDATE: Phase 1: Check for invalid objects ...
>> May 26 14:54:38: VALIDATE: Phase 2: Check for cycles ...
>> May 26 14:54:38: VALIDATE: Phase 3: Check for inconsistencies ...
>> May 26 14:54:38: VALIDATING the object hierarchies ... finished.
>> May 26 14:54:38: LOADING: Reading 2666 MOO verb programs...
>> May 26 14:54:40: LOADING: Done reading 2666 verb programs...
>> May 26 14:54:40: LOADING: Reading forked and suspended tasks...
>> May 26 14:54:40: *** DBIO_READ_NUM: Bad number: "" at file pos. 11526144

I would imagine that the problem results from attempting to copy a database file from a moo that is currently live, and thus constantly changing.
***************************

If you have any answers, please reply to the encore list and cc: it to timothy.miley@wmich.edu

Thanks for your help!

Lennie

 


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 02/06/2006
--=====================_96123781==.ALT-- From kevijeps@telusplanet.net Sun Jun 4 12:35:22 2006 Received: with ECARTIS (v1.0.0; list encore); Sun, 04 Jun 2006 12:35:22 -0500 (CDT) Return-Path: X-Original-To: encore@nobel.utdallas.edu Delivered-To: encore@nobel.utdallas.edu Received: from iq1.utdallas.edu (iq1-pmn.utdallas.edu [192.168.1.7]) by nobel.utdallas.edu (Postfix) with ESMTP id 001175BB3 for ; Sun, 4 Jun 2006 12:35:21 -0500 (CDT) Received: from localhost (mf2-pmn.utdallas.edu [192.168.1.14]) by iq1.utdallas.edu (Postfix) with ESMTP id A5DCC4518 for ; Sun, 4 Jun 2006 12:35:21 -0500 (CDT) Received: from mx2.utdallas.edu ([129.110.10.17]) by localhost (mf2.utdallas.edu [10.110.10.14]) (amavisd-new, port 10024) with LMTP id 13021-01-74 for ; Sun, 4 Jun 2006 12:35:19 -0500 (CDT) Received: from priv-edtnes10.telusplanet.net (outbound02.telus.net [199.185.220.221]) by mx2.utdallas.edu (Postfix) with ESMTP id A46353456 for ; Sun, 4 Jun 2006 12:35:19 -0500 (CDT) Received: from priv-edtnaa06.telusplanet.net ([199.126.223.252]) by priv-edtnes10.telusplanet.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20060604173518.JOGF8031.priv-edtnes10.telusplanet.net@priv-edtnaa06.telusplanet.net>; Sun, 4 Jun 2006 11:35:18 -0600 Received: from lilith (d199-126-223-252.abhsia.telus.net [199.126.223.252]) by priv-edtnaa06.telusplanet.net (BorderWare MXtreme Infinity Mail Firewall) with ESMTP id 8EF5MSLRFU; Sun, 4 Jun 2006 11:35:17 -0600 (MDT) From: "Kevin Jepson" To: "'Timothy H Miley'" , "'Lennie Irvin'" Cc: Subject: [encore] Re: MOO down--help needed!!! Date: Sun, 4 Jun 2006 11:34:45 -0600 Message-ID: <003901c687fd$2c200750$5a0119ac@lilith> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal In-Reply-To: X-Virus-Scanned: amavisd-new at utdallas.edu X-archive-position: 1673 X-ecartis-version: Ecartis v1.0.0 Sender: encore-bounce@utdallas.edu Errors-to: encore-bounce@utdallas.edu X-original-sender: kevijeps@telusplanet.net Precedence: bulk Reply-to: kevijeps@telusplanet.net List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: X-list: encore Timothy Is the original MOO still up and running? If it is try forcing a checkpoint with @dump then copy that checkpoint = to another server running lambdamoo and see if it starts up. =20 Or, which would be easier, just grab the current .new file and try it. I remember that your MOO had big problems with a failed server back in October and we (Robert Rozema, Michael Stilson and I) were unable to recover/find the backups.=20 I hope you are able to get a copy of the DB that works. Ciao KJ -----Original Message----- From: Timothy H Miley [mailto:timothy.miley@wmich.edu]=20 Sent: June 4, 2006 11:21 AM To: Lennie Irvin Cc: Kevin Jepson; encore@utdallas.edu Subject: Re: RE: [encore] MOO down--help needed!!! From what I saw on the logs, the MOO started reporting errors rather recently, however the backup version that I have from the 25th of April appears truncated. It has an email that ends mid sentence with end of = file. So it's certainly possible that we might try the next oldest copy of the = MOO and be ok. * Timothy H. Miley -- timothy.miley@wmich.edu=20 "Si tuviera que elegir entre pan y libertad, elegir=EDa libertad para = luchar por el pan." -- Written on a wall in Santiago, Chile (Translation: If I had to choose between bread and freedom, I would = choose freedom in order to=20 fight for the bread.) --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: = 02/06/2006 =20 From cynthia.haynes@gmail.com Sun Jun 4 12:44:11 2006 Received: with ECARTIS (v1.0.0; list encore); Sun, 04 Jun 2006 12:44:11 -0500 (CDT) Return-Path: X-Original-To: encore@nobel.utdallas.edu Delivered-To: encore@nobel.utdallas.edu Received: from iq1.utdallas.edu (iq1-pmn.utdallas.edu [192.168.1.7]) by nobel.utdallas.edu (Postfix) with ESMTP id 87F1C5BB3 for ; Sun, 4 Jun 2006 12:44:11 -0500 (CDT) Received: from localhost (mf2-pmn.utdallas.edu [192.168.1.14]) by iq1.utdallas.edu (Postfix) with ESMTP id 4335A4547 for ; Sun, 4 Jun 2006 12:44:11 -0500 (CDT) Received: from mx2.utdallas.edu ([129.110.10.17]) by localhost (mf2.utdallas.edu [10.110.10.14]) (amavisd-new, port 10024) with LMTP id 14002-01-92 for ; Sun, 4 Jun 2006 12:44:05 -0500 (CDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx2.utdallas.edu (Postfix) with ESMTP id 703A8346A for ; Sun, 4 Jun 2006 12:44:05 -0500 (CDT) Received: by nf-out-0910.google.com with SMTP id h2so1378506nfe for ; Sun, 04 Jun 2006 10:44:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:user-agent:date:subject:from:to:message-id:thread-topic:thread-index:in-reply-to:mime-version:content-type; b=GUuPhXRjuCgz6veqTMa9rREjMsKB68ggic1vmM4b6gYEBbZdtHx2wqd1SeaGEqRDHV3fCDMyNySlP7WTGNrPj2rs0iPk1HXfBw4vb/WHa3KjPmS8apH2OKhxHr6+EG7eZF6XHDMcRBzZtEMfWFGLnkk0VQ3l+B51AX1IzSBbQl8= Received: by 10.48.210.19 with SMTP id i19mr2505419nfg; Sun, 04 Jun 2006 10:44:04 -0700 (PDT) Received: from ?10.0.1.4? ( [80.163.18.182]) by mx.gmail.com with ESMTP id x27sm4561246nfb.2006.06.04.10.44.02; Sun, 04 Jun 2006 10:44:03 -0700 (PDT) User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Sun, 04 Jun 2006 19:42:53 +0200 Subject: [encore] FW: encore: timothy.miley@wmich.edu post From: Cynthia Haynes To: Message-ID: Thread-Topic: encore: timothy.miley@wmich.edu post Thread-Index: AcaH/k4yjORjPPPxEdqwJQAWy5Ijwg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3232294980_18448049" X-Virus-Scanned: amavisd-new at utdallas.edu X-archive-position: 1674 X-ecartis-version: Ecartis v1.0.0 Sender: encore-bounce@utdallas.edu Errors-to: encore-bounce@utdallas.edu X-original-sender: cynthia.haynes@gmail.com Precedence: bulk Reply-to: cynthia.haynes@gmail.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: X-List-ID: X-list: encore > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3232294980_18448049 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From what I saw on the logs=2C the MOO started reporting errors rather r= ecently=2C however the backup version that I have from the 25th of April= appears truncated=2E It has an email that ends mid sentence with end o= f file=2E So it=27s certainly possible that we might try the next oldest copy of t= he MOO and be ok=2E * Timothy H=2E Miley -- timothy=2Emiley=40wmich=2Eedu = =22Si tuviera que elegir entre pan y libertad=2C elegir=EDa libertad par= a luchar por el pan=2E=22 -- Written on a wall in Santiago=2C Chile (Translation=3A If I had to choose between bread and freedom=2C I would = choose freedom in order to = fight for the bread=2E) ----- Original Message ----- From=3A Lennie Irvin =3CLirvin=40accdvm=2Eaccd=2Eedu=3E Date=3A Sunday=2C June 4=2C 2006 9=3A23 am Subject=3A RE=3A =5Bencore=5D MOO down--help needed!!! =3E From what I understand of their situation=2C they had run out of = =3E memory on the previous server=2E Would that account for the = =3E corruption = =3E to the backup copy of the database=3F =3E = =3E Tell me if this scenario could be what happened=3A Every time the = =3E moo = =3E checkpointed=2C it backed itself up to the encore=2Edb=2Enew file=2C= but = =3E the = =3E server said wait a minute=2C you don=27t have room and denied the = =3E writing = =3E of the new version of the file=3F I don=27t know=3F It seems that = if = =3E they = =3E had memory problems on that server it would also have limited their = =3E ability to create ANY new objects in the moo=2E I believe they were= = =3E active in the moo creating things during this period when the = =3E server = =3E was supposed to be out of memory=2E It seems like there would have = =3E been an error message even when they created a single object in the = =3E moo in this case=3F =3E = =3E It seems like it might be important to pin down the dates for when = =3E the server ran out of memory=2E If you get the exact date=2C you co= uld = =3E find the encore=2Edb=2Enew from the day before the server ran out of= = =3E memory and see if that version worked=2E =3E = =3E As another option=2C I presume that the server was having tape = =3E backups = =3E made of it=3F If somehow the encore=2Edb=2Enew was not copying but t= he = =3E encore=2Edb=2Edb was able to take new data=2C then perhaps the tape = =3E backup = =3E of just the encore=2Edb=2Edb might work=3F =3E = =3E Tim--I hope you are able to get you moo back up and running=2E Keep= = =3E us informed! =3E = =3E Lennie =3E = =3E = =3E At 09=3A52 AM 6/3/2006=2C Kevin Jepson wrote=3A =3E =3ELennie =3E =3E =3E =3EIt looks to me like the backup copy of the database is corrupted = =3E somehow=2E=3E =3E =3EThe standard checkpoint copy is the =22encore=2Edb=2Enew=22 file = and it is = =3E =3Ealways made when the MOO is running so that shouldn=27t cause a = =3E problem=2E=2E=3E =3E =3EDid this restart error come up when the old MOO was restarted or = =3E was = =3E =3Eit on the new system=3F =3E =3E =3E =3EAs for the procedure to move it (assuming no OS problems with OS = =3E X) = =3E =3EI would do this=3A =3E =3E =3E =3EIf the old MOO is still running copy encore=2Edb=2Enew from old s= erver=2E =3E =3E =3E =3EOn the new server load the encore=2Edb=2Enew file and rename it = =3E encore=2Edb=2E=3E =3E =3EStart the new MOO using the standard script=2E =3E =3E =3E =3ECiao =3E =3EKJ =3E =3E-----Original Message----- =3E =3EFrom=3A encore-bounce=40utdallas=2Eedu =5Bencore-bounce=40utdalla= s=2Eedu=5D = =3E =3EOn Behalf Of Lennie Irvin =3E =3ESent=3A June 3=2C 2006 7=3A35 AM =3E =3ETo=3A encore=40utdallas=2Eedu =3E =3ECc=3A timothy=2Emiley=40wmich=2Eedu =3E =3ESubject=3A =5Bencore=5D MOO down--help needed!!! =3E =3E =3E =3EI=27ve been in correspondence with Tim Miley and Allen Webb at = =3E =3ESecondary Worlds about some problems they have had transferring = =3E =3Etheir moo from one server box to another=2E Right now=2C they ar= e = =3E =3Eencountering some pretty major problems=2E They specifically are= = =3E =3Ehaving trouble loading a backed up version of the database=2E I = had = =3E a = =3E =3Ecouple of questions to ask that could help them=3A =3E =3E =3E =3E1) Are there any particular problems with moving a moo from a UNI= X = =3E =3Ebox to a Mac OS X box=3F =3E =3E =3E =3E2) Question about restoring a backed up version of the = =3E =3Edatabase=3A Currently=2C they have a good copy of the database a= s a = =3E =3Edbnew=2Edb version (file name has =22new=22 in it)=2E =3E =3ECan someone confirm this as the proper restore sequence=3F =3E =3E =3E =3ERestoring a db from a dbnew=2Edb version=3A =3E =3E =3E =3E1) Save a copy of your backup dbnew=2Edb file=2E =3E =3E2) Rename this file db=2Edb =3E =3E3) Shut down moo =3E =3E4) Physically replace the db=2Edb file with the backup copy you j= ust = =3E made=2E=3E5) Restart the moo =3E =3E =3E =3EAm I missing anything with this restore sequence=3F Here is a = =3E =3Edescription of what they have currently been doing and the error = =3E =3Ethey have been receiving=3A =3E =3E =3E =3E*************** =3E =3EThe standard restart script was used=2E The moo read from the = =3E =3EenCore=2Edb file and wrote to enCore=2Edb=2Enew=2E A person off = site = =3E copied = =3E =3Ethe enCore=2Edb=2Enew file (I believe) while the MOO was running=2C= so = =3E =3Ealthough we have an newer version archived by the offsite user=2C= = =3E his = =3E =3Eversion would not load=2E It gives the following error=3A =3E =3E =3E =3E =3E=3E May 26 14=3A54=3A38=3A VALIDATE=3A Phase 1=3A Check for i= nvalid objects =2E=2E=2E =3E =3E =3E=3E May 26 14=3A54=3A38=3A VALIDATE=3A Phase 2=3A Check for c= ycles =2E=2E=2E =3E =3E =3E=3E May 26 14=3A54=3A38=3A VALIDATE=3A Phase 3=3A Check for i= nconsistencies =2E=2E=2E =3E =3E =3E=3E May 26 14=3A54=3A38=3A VALIDATING the object hierarchies = =2E=2E=2E finished=2E =3E =3E =3E=3E May 26 14=3A54=3A38=3A LOADING=3A Reading 2666 MOO verb p= rograms=2E=2E=2E =3E =3E =3E=3E May 26 14=3A54=3A40=3A LOADING=3A Done reading 2666 verb = programs=2E=2E=2E =3E =3E =3E=3E May 26 14=3A54=3A40=3A LOADING=3A Reading forked and susp= ended tasks=2E=2E=2E =3E =3E =3E=3E May 26 14=3A54=3A40=3A *** DBIO=5FREAD=5FNUM=3A Bad numbe= r=3A =22=22 at file = =3E pos=2E 11526144 =3E =3E =3E =3EI would imagine that the problem results from attempting to copy = a = =3E =3Edatabase file from a moo that is currently live=2C and thus = =3E constantly changing=2E =3E =3E*************************** =3E =3E =3E =3EIf you have any answers=2C please reply to the encore list and cc= =3A = =3E it = =3E =3Eto timothy=2Emiley=40wmich=2Eedu =3E =3E =3E =3EThanks for your help! =3E =3E =3E =3ELennie =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E-- =3E =3ENo virus found in this outgoing message=2E =3E =3EChecked by AVG Free Edition=2E =3E =3EVersion=3A 7=2E1=2E394 / Virus Database=3A 268=2E8=2E1/355 - Rele= ase Date=3A = =3E 02/06/2006 // eompost 448316A0:1222.1:rapber ------ End of Forwarded Message --B_3232294980_18448049 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable FW: encore: timothy.miley@wmich.edu post
From what I saw on the logs=3D2C the MOO started reporting errors rather r=3D ecently=3D2C however the backup version that I have from the 25th of April=3D  appears truncated=3D2E  It has an email that ends mid sentence wit= h end o=3D
f file=3D2E

So it=3D27s certainly possible that we might try the next oldest copy of t=3D he MOO and be ok=3D2E

* Timothy H=3D2E Miley   -- timothy=3D2Emiley=3D40wmich=3D2Eedu =3D

=3D22Si tuviera que elegir entre pan y libertad=3D2C elegir=3DEDa libertad par=3D a luchar por el pan=3D2E=3D22
 -- Written on a wall in Santiago=3D2C Chile
(Translation=3D3A If I had to choose between bread and freedom=3D2C I would =3D choose freedom in order to =3D

fight for the bread=3D2E)

----- Original Message -----
From=3D3A Lennie Irvin =3D3CLirvin=3D40accdvm=3D2Eaccd=3D2Eedu=3D3E
Date=3D3A Sunday=3D2C June 4=3D2C 2006 9=3D3A23 am
Subject=3D3A RE=3D3A =3D5Bencore=3D5D MOO down--help needed!!!

=3D3E From what I understand of their situation=3D2C they had run out of =3D

=3D3E memory on the previous server=3D2E  Would that account for the =3D

=3D3E corruption =3D

=3D3E to the backup copy of the database=3D3F
=3D3E =3D

=3D3E Tell me if this scenario could be what happened=3D3A  Every time the= =3D

=3D3E moo =3D

=3D3E checkpointed=3D2C it backed itself up to the encore=3D2Edb=3D2Enew file=3D2C=3D  but =3D

=3D3E the =3D

=3D3E server said wait a minute=3D2C you don=3D27t have room and denied the =3D

=3D3E writing =3D

=3D3E of the new version of the file=3D3F  I don=3D27t know=3D3F  It seem= s that =3D
if =3D

=3D3E they =3D

=3D3E had memory problems on that server it would also have limited their =3D
=3D3E ability to create ANY new objects in the moo=3D2E  I believe they we= re=3D
 =3D

=3D3E active in the moo creating things during this period when the =3D

=3D3E server =3D

=3D3E was supposed to be out of memory=3D2E  It seems like there would hav= e =3D

=3D3E been an error message even when they created a single object in the =3D
=3D3E moo in this case=3D3F
=3D3E =3D

=3D3E It seems like it might be important to pin down the dates for when =3D
=3D3E the server ran out of memory=3D2E  If you get the exact date=3D2C you = co=3D
uld =3D

=3D3E find the encore=3D2Edb=3D2Enew from the day before the server ran out of=3D  =3D

=3D3E memory and see if that version worked=3D2E
=3D3E =3D

=3D3E As another option=3D2C I presume that the server was having tape =3D

=3D3E backups =3D