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.