One thing fast is better than many things slower.

Yes, it been a while but I'm going to make up for it right now. Not only did we move our production account from 772 to 405 we switched CPU's we're now running on RedHat. Why? Money and performance, mostly for performance.

Before:

7.7.2
Sun V880 - 8 x 1.2 GHz
RAM - 16GB
Hosting: Database, webserver, DGW test and prod.
Performance: 15-20 second audits.


After:

4.0.5

2 x Dell T100 - Intel Quad 3.0 GHz
RAM - 4 GB
Hosting: Prod account only
Performance: 1-3 second audits.

Yes, that is a HUGE jump. My final grade batches went form 3 days to less than one day.
I could run it faster but 405 has some DGWCPUCOUNT issues that prevent me from running
simultaneous batches. I've got a SR for it.

The best part of this migrations is that my new Dell servers only cost me $1000 EACH!!

What happened to the Sun T5220's? I was pretty disappointed. I was hoping to take advantage of it's award winning multi-threading but the problem was that Degreeworks is not a multi-threaded app. I tried EVERYTHING to make the T5220 to work for us. (that's why I hadn't posted in a while.) The ONLY advantage of the T5220 at 1.6 Ghz is that you can batch faster by setting the DGWCPUCOUNT to like 10 and have 10 batch jobs running at the same time.

Listen closely now because this is a proven theory.

CPU speed is the key to increasing performance.

There. I said it. Yes, throw money at it but not a lot. Since DW is single threaded it will never take advantage of multi-threaded processors when it comes to dynamic web audits. So why have a server that does multi-threading at a slow speed (Sparc 1.6 GHz) when the app will never take advantage of it? So I bought a server that does one thread really really fast (Intel 3.0 GHz).

*(Note: Sungard also recommends a processor with at 3.0 Ghz and higher)*

I know about the WEB09M03 and, in my opinion, it does absolutly nothing. In fact, I think it makes things worst. It basically uses one thread and to jump between several requests. This is an old configuration which helped with managing cobol licenses in the old versions (772 and earlier).

Those T5220's didn't go to waste. One is used as a primary database for Degreeworks and the other is used for our test environment.

Note that separating the database from the app also made a huge difference. There is a lot of I/O going on. Now Oracle (a major resource hog) and DW don't have to compete for resources any more. This is one thing every site should do.

This layout is perfect for us right now. I'm on the verge of releasing what-if to students because it's performing so well. We never could give it to the students because 20,000 students hitting what-if at a rate of 20-second audits on a single thread would give me nightmares.

I could go on and on about this but this is enough to chew on for a while. More posts to come. I promise.

DW4.0.2 - On the way!!

I just closed a Service Request and it mentioned that DW4.0.2 is going to be delivered at the end of the month. So start planning your upgrade implementation!!

We notified SGE about a month ago that we wanted to move production in DW4.0.x in March and they have been very responsive to our needs. Most of our problems and defects have been answered.

I have a lot of confidence that we will have some sort of mirrored production version of DW402 and 772 at the end of the month. That way our users can use both versions and ease into the DW40x. I did this setup a couple of years ago and it worked out fine.

DW4.0.1 Testing (Update)

Recommendation: Wait til the release of DW4.0.2. Sungard didn't tell us when it would be released.

In DW401, 2 out of 4 critical SR's went to defect. Here's how it went down:

1) Program Block not being pulled in. - Defect - we got an updated dap32s.c. It works well. The SR states that the fix won't be delivered until 4.0.2. No date yet.

2) Exceptions un-hooked - Defect - Major show stopper. I go into more details here. Sungard decided to modify the old 772 database entries with a sql script and continue with the new DW401 format. I don't know how they are going to deliver this. I just got the fix Friday. I assume it will be in 4.0.2.

3) "Apply here" applies something else - head scratcher - We couldn't reproduce it.

4) Custom Dtls - ucx table correction - Back in 772, we could be lazy and not specify element numbers. Now in DW401 you have to specify the element numbers. I put in R323 for the data element and R322 for the Edit Element 1. This is stated on page 81 on the DGW Technical Guide UCX.

Again, we are all different clients. We're old clients moving from 772 to DW401. If you are a new client starting in DW401, these may not be issues.

We have other Service Request open but are fairly minor. I'll post them if they make it to Defectville.

Nancy: kerfuffle with wildcard

I'm excited that Nancy would like to post stuff on this blog. I'll tag these with her name so that all the scribers can easily find her entries.

Kerfuffle with Wildcards by Nancy

When testing 4.0.1 (we are on 7.7.2 in production) I noticed that wildcards used in scribing course numbers were not behaving correctly. I filed a service request with my example. After some discussion of what should be happening, I was told to try changing a new flag in D20 DAP13. The new flag is named "Wildcard Character Match". The flag had been set to "0" as a default, meaning a wildcard matches 0 or more characters. A wildcard has always matched 1 or more characters.

It seems to me that the default for a new flag should be the way the product has always behaved. A user wanting the new functionality should be the one to go in and set it.

After I changed the flag to "1", the audits were OK. So, make sure this flag is set to 1 if a wildcard means 1 or more characters for your scribing.

DW4.0.1 Testing

DW4.0.1's new interface is great. I love it. The fact that I don't have to use shpentry to customize the interface is GREAT! Shpentry drove me crazy to the point that I didn't customize any more and created my own interface all together. I've done some hacking and I've created a new shpkey which creates a new tab for UCI degree customizing.

One of the best breakthrough with DW4.0.1 is the removal of Microfocus Cobol. No more license errors!!

Another great break through for us older clients is Linux is now an option. I'll post an entry about my Solaris vs. Linux experience.

BUT, we do have problems as of today. I remember at the DW symposium endorsing DW4.0.0 but today I wave a yellow caution flag. Nancy and I have identified and resolved some problems but we are currently working with major deal breakers. Of course, these may not affect other clients because we all use DW differently.

1) The auditor isn't pulling PROGRAM blocks. It's identified as a defect and we are awaiting it's resolve.

2) Exceptions are un-hooked. Courses Disciplines names have been corrupted somewhere during the install and so the auditor drops these exceptions. Not good for move to production.

3) Apply Here Exceptions applies a different course than the original intended course.
Same student, previous audit.

4) Custom Dtls not working. We have on average 8-10 custom-dtls per student and the auditor chooses to use only half of them. This screws up the layout of all the students. Weird.


Our next window to update our production account is in late March and we hope to these get resolved by then. We've reported all these and the response times from the help desk have been very good.

Patch DW4.0.1

Easy. No complications. Just do it.

I had one problem and submitted at Service Request for it and it was immediately resolved. Sungard didn't deliver a set of files.