The only thing constant is change.

Sorry I haven't posted much in the last couple of weeks. I was a little swamped with DW4.0.1 fixing and debugging.

DW4.02 is here and it is packed with new stuff. I consider it more of a mini release instead of a patch because it's got a lot of cool new things. I'm having minor issues with the installation package right now but I will give a full report soon which will include time line and adoption considerations.

For standalone users: The BRIDGE has changed once again. (I think twice in just this release of DW4) RAD-DEGREE-DTL and RAD-SCHOOL-DTL has been phased out (although it is backwards compatible). The replacement is RAD-GOAL-DTL and RAD-GOALDATA-DTL. It allows for unlimited calling of major/minor/program blocks.

I've only glanced at it and it a little confusing. I'll have to experiment.

Stay tuned. I'll give my review soon.

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.

Database indexing

Problem: Audits getting slower over time but nothing has changed.
Solution: Re-index your database audit tables.

At UCI, we use In-progress classes and update them on a daily basis. With 30,000 students in DW, a lot of database records get changed, thus database indexing becomes overwhelming.

DW and Oracle doesn't know when or how to re index the audit tables so it would be wise to add this to your quarterly maintenance. If I don't re index, our audits take twice as long to process.

The tables - dap_audit_dtl, dap_audtree_dtl

The indexes - for dap_audit_dtl: (via xsql, select index_name from dba_ind_columns where table_name='DAP_AUDIT_DTL';)

for dap_audtree_dtl: (via xsql, select index_name from dba_ind_columns where table_name='DAP_AUDTREE_DTL';)

Two options in re indexing:

A) Simply rebuild the index in xsql:

1. login to the account.
2. login to xsql.
3. type the rebuild index command for each of the indexes: "alter index DAP_AUDIT_DTL_A rebuild unrecoverable;"
4. Do this for each index. (DAP_AUDIT_DTL_A, DAP_AUDIT_DTL_B... etc.)

B) Rebuild the index in a new tablespace (recommended for very large FTE's):

1. Same as above but add the tablespace command: "alter index DAP_AUDIT_DTL_A rebuild tablespace (tablespace name) unrecoverable;"

Option B recommended by Oracle DBA for very large tables because instead of using temp space to create the new indexes, it just builds them in the new tablespace. Plus this is a much faster process.

Our I alternate between two tablespaces that are 6 GB large just for dap audit indexes. Yes, that is very large. Our tablespaces just for audits are 20 GB.

** Please consult with your IT staff at your site before experimenting with this. ***

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.

Exceptions falling with 772 to DW401 migration.

Our #2 show stopper for going live with DW4.0.1 is showing to be a major problem. Identified and confirmed by us and DW development, all exceptions will fall off if a site migrates from 7.7.2 to DW4.0.1.

Explanation:
The dap_exc_buffer is database field that holds the course info that the exceptions is using. In 7.7.2 it looks like this:
After the database conversion step in the upgrade the field and data stays the same. But when you run a new audit, the auditor will read it starting two bytes off. It's now looking for, "OG 13" as the discipline and "0" as the number. I confirmed this by entering a exception in the new DW4.0.1 account exactly like the previous one and queried the database table and compared:
Very different from before. A possible COBOL to C conversion problem.

As of right now, we haven't received a solution or a way to proceed. Here's my guess solutions: 1)Change the database entry for ALL the 772 to read old entries. 2) Release a hot fix to go back to the way the buffer is made. 3) Write code to have the two different layouts be valid.

I'll let you know if I get the fix before you do.

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.

Sun versus Red Hat

versus

7.72DW2.0 was the first release of Degreeworks with the Red Hat as an option. Before I bought my hardware I had the opportunity to test both environments. My Review:

Red Hat:

Pros: Cheaper. Much Faster CPU's (up to 3.0 Ghz), thus faster audits.
Cons: Limited to only Intel processors. NO AMD's! Less cores.

Sun:
Pros: Sun hardware allows for more core/multi-thread processing, thus more batches/simultaneous audits.
Cons: Expensive. Slower CPU's (1.0 - 1.66 GHz).

That's basically what it boils down to. They both run DW exactly the same. Obviously the RH server ran the audit 2-3 times faster but only has a 4 core limitation. Sun processors go up to 8 cores.

I tried to run a Sun server and a RH server connected to the same database account (hybrid server) and it didn't work because of steno. Eventually this will be a option once steno has been phased out of DW. 1-2 years?

I chose the Sun because eventually we are going to need to run more batches for the Curriculum Planning Assistant. I will blog about this soon. It's has some costly needs.

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.

Nancy

She's the genius Scriber and Audit Engine Expert. I honestly think the success of DW at UCI is mainly because of her.

Many of the DW community knows her but I just wanted to formally introduce her. She was very active in the past as the DW module rep.

She's made her mark on DW in many ways. Especially in the way the audit engine works and some of the way scribe is created. Here is some of her influences on the product.:

- Exceptions "With DW___"
- StandAlone Block
- Proxy Advice

Lately she did a testing for the In-Progress Revision. (The biggest problem with DW, in my opinion. IP classes pushed completed courses out of a rule making the audit inaccurate.) I'm glad to report that it went well and we might see this resolved in the next patch.

I hope for her to chime in on this blog from time to time.

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.

Installing 4.0.0

Back in October, I was the first standalone client to upgrade from 7.7.2 account to DW4.0.0. (And the fastest.)

The install is fairly painless. Since I was the first, I obviously ran into problems. But they were mostly from my end.

If you properly read the doc all should go well. I am pretty satisfied with the process. The resulting software after the install is a different story. I'll post that later.

Only piece of advice:

Copy the database schema to a new space. Use the default dwschema for the name of the user/schema. It is recommended in the instructions but I think it's a must for two reasons: a) It cleans up the tablespaces and indexes. b) It cuts out any problems during the conversion.

I'm going to try the multiple-entity site db setup soon. It was explained to me at the user conference and found many advantages from my prospective. I'm putting this one on the list to try out.

If all goes well, one could install this in one day of work. I thought the database conversion would take the longest but it didn't. The database export/import to the new schema will take the longest depending how large the schema is. It took me about 3 hours to load the new schema from backup.

Upgrade times:
New account: 30-40 minutes.
Existing account: approximately 2 hours.

Not bad. Thumbs up to the Sungard Install Team.