Lookup Fixed
Solution Center came through again. Our /tmp partition was too small to hold the index rebuild files for our PERSON file. Tim moved it to a bigger area and we can look people up by partial names!
Now, testing, testing, testing!
Solution Center came through again. Our /tmp partition was too small to hold the index rebuild files for our PERSON file. Tim moved it to a bigger area and we can look people up by partial names!
Now, testing, testing, testing!
Building the training account has gone very smoothly. It took about six years to get the test account set up. OK, maybe 3 weeks, but it seemed like six years! The training account has taken less than 5 hours. OF course not there are over 300 patches to apply. Still, it is really nice to have things work as advertised.
There is still the issue of PERSON indexing in test. You can't look people up by name, just by ID number. Details. Datatel is looking into it.
I just finished the last of the Post Install instructions in the manual. It's official, we have a live R18 test environment. It only took two weeks to get it going. With a ittle practice, I should be able to get that down to, what, maybe 6 days. Think the users will mind being off the system for 6 days? Yeah, right!
Oh, by the way, sorry for flipping back and forth between R18 and R18 Install. Got to get this whole blog thing straightened out.
OK, just finished converting 3032 ST and several hundred CORE and CF Computed Columns. New we need to see if we can remember the new Computed Column language from class in January! Just one more challange.
Well, that didn't take any 8 hours! Patches are done, all 333 of them. Hmm, half of 666, significance there? We'll see. Turning the page in the Installation Procedures book and going on to the next step. Progress, progress, progress!
The last Software Update Group is installing right now. One of the Pre-Installs said that one of the patches may take 1-8 hours, "depending on your hardware and the size of your database." Ours is fast and big, so no idea how long we are looking at. The issue is that using the database while this patch is working its magic could cause corruption, so, now that we have a siren, please don't get into the R18 test account untill you hear the ALL CLEAR. Isn't it great when multiple technologies combine into such useful systems?
I'm sure these little things will be showing up all over the place. If you try to connect to an R18 environment without all the listeners running, it stops on a grey screen and asks for your database password. Then, no matter how many times you enter the correct password, it won't let you continue. You need to close the UI window, start the listeners and try again. Isn't this fun?
Sometime frustration can work to your advantage. I got fed up with waiting for Solution Center to call back. I know that lots of clients are going live over the weekend but still, I wanted help, too! Frustration took over and I deleted the test environment again, recreated it, updated DMI and tried to populate it. It worked! Now a mere 330 some patches to install and we're back where we were last week! Progress.
Now the Populate Application Environment won't start. Called Solution Center and they will call back as soon as I step away from my desk for a minute. Hopefully, a quick fix. Back soon, I hope!
Got the document, didn't help, called back. I now know how to run SA-Valet in debug mode. Eric from Datatel found the problem. One of the files in the LPR was corrupt, or at least the index was corrupt. He was able to fix it, although the dictionary was not rebuilt. We got that fixed this morning and I'm on my way - again.
First thing Monday morning, I started preparing for a rebuild of the test environment. By 9 the existing test envirnment was gone and I was on the road to building a new, improved test environment. Wall. Creating the test environment failed before any log records were written. Fought with it for most of the morning after calling Datatel. Stepped out for a minute and missed the return call. Soon after Answernet went down. Called back with more information. After lunch stepped out for a second (best way to get Datatel to call back) and missed Eric's call. But he did report that the power is out in Fairfax so all their servers are down. He told me a document to look at but, well, no power so, no document. Isn't this fun?
We've had a working R18 test environment for two days now. After installing over 300 patches with pre and post install processing, I can see that some things should be set up differently. So, first thing Monday morning, I'm going to delete the test environment and rebuild it better, I hope. Should be ready by Wednesday, God willing and the creek don't rise.
Well, what do you know? SA-Valet told me the popapp timed out. When I restarted it, it timed out at the same spot. Duncan from Solution Center pointed me to the INSTALL_PROGS directory and that verifiied that the popapp ran successfully, even though SA-Valet didn't know it.
We now have a working R18 test environment! Still some clean up to do, but this ia a major milestone!
Time to turn the page in the manual and continue.
Well, POPAPP ran for about 90 minutes yesterday, then timed out. It got to Step 102/140. I can restart POPAPP but it just hangs. Another call to my good buddy, Duncan, in Solution Center. (It's kind of sad that I don't even need to look up his phone number any more.) He has guided me through all the other problems and I'm sure this one will fall by the wayside also. Still, it's frustrating to have seen such progress, to have been so close to having a working R18 test environment, then to have it fail. Good news has to be coming soon - right?
So the last wall I ran into was in the POPAPP process. It turns out that part of the process requires a UniData SELECT against the install account. For this run, that would be /db12/COLL17A/INSTALL but UniData has a set of special strings. To quote from the AnswerNet document:
"The magic strings for UniData pattern matching are:
nX -- matches n characters of any kind
nA -- matches n alpha characters
nN -- matches n numeric characters
Also the tilde (~) character can proceed any of the above matching strings to negate the match. For example ~18N will match 18 non-numeric characters.
For example, path containing coll18xst would fail (as would COLL18XST)."
Therefore, COLL17A will not work. I changed the directory name to COLL17, changed all the VOC pointers (no small job when you can't select for COLL17A for the reason listed above) and tried it again.
Still having the same problem so I guess that fixed a different problem. Still, an interesting issue.
I feel like a rat in a maze. Every time I start moving forward there's a wall in front of me. Running POPAPP (populate application) on Friday turned up an error after 7 of 131 steps. Sent log files to Solution Center, missed one call (5:15 Friday) then another (Monday lunch,) called back both times and left voice mail. Tag, they're it.
Over night more than 250,000 items downloaded into the LPR. Right now I am updating DMI in the test environment to version 4.1 - 10 updates. Next comes populating the test environment, updating and loading our custom software and computed columns. We may be able to start playing with our own R18 account by Monday. Woo-hoo!
It took about 24 hours to connect with Solution Center but Duncan was able to get the repository_das listener going. I am now retrieving additional updates to the LPR and will update DMI next. The process is frustratingly slow, probably due to the number of clients going through the same process. I must say that when you get in touch with someone, the problem gets fixed. They are good. Now, to continue downloading...
Another day of fits and starts. The test application environment creation finally completed but now the repository_das listener won't start. The message doesn't make sense, so yet another call to solution center. I'm batting about .500 fixing things myself so we're getting our money's worth out of the ESSA this year! Once the repository_das listener starts working I need to update all the DMIs then the LPR and we can start working on the test environment. Maybe tomorrow...
The LPR has been populated. It took about 90 minutes. Not too bad! I copied collive to coltesta on admin5 so we have the most current data in the new coll18 test environment. Next step was to copy coltesta to /datatel/coll18/test/apphome. You should all add that database to your UI since, as soon as it is converted to R18 (hopefully tomorrow) terminal mode won't work! I'll be building MOVEINFO records for the foreseeable future.
After resolving a problem with the mount command, I have started to populate the LPR from the distribution DVD. Started at 15:06:48 on 04/24/07. Let's see how long it takes!
Making progress! The Datatel Daemon install took about a week. It was a setup issue on admin5. The Tru64 .profile which was copied from admin4 did not create a usable ksh environment under HP-UX. With that fixed, the daemon installed nicely as did SA-Valet 2.2.0. Creating the LPR was a bit more challanging but with the correct parameters is finally worked. Now, on to loading the DVD into the new LPR.
As we being the process of installing R18 on our new server, we face many challanges. Ther current server is running Tru64 and the new one is HP-UX and the difference iin Unix flavors is frustrating. For example, on prior servers, from Ultrix through Tru64, we used "ls -lag" to get a directory listing. The HP-UX equivalent seems to be "ls -la". ps is also different and I haven't found the combination of options to get the old Tru64 "ps aux" format.
On the Datatel front, the first step is to install the Datatel Daemon. I am stuck on that right now, with a call in to Solution Center. The install is logging in to the server, but is unable to execute ksh scripts. Patiently (!) awaiting a response from Datatel.