I am posting this here for the benefit of others who are thinking of upgrading to Predict v441. Maybe this will also drive some changes.
We upgraded from v422 to v441, but it was painful. Since we were jumping 2 releases, we did not attempt the inplace conversion but rather did an unload and load. Even though the data passed consistency check, it died on the load’s consistency check, and this was over objects loaded for other SAG products (i.e., Natural Process DB object, SAG-** DDMs, etc.). Why??? When we were able to load everything in, we lost DDMs that pointed to databases other than DBID=0.
Here’s my advice… if you jump from v42 or lower to v44, order all the intermediary releases and do (multiple if necessary) inplace conversions! These went smoothly in comparison and we had no problems afterward. At least none relating to conversion.
Which leads me to my next point. Predict v44 is bad! Any files with D or T format fields generates a change when you do GEN AF! The fields are already 4 or 7 bytes long, but Predict thinks it must issue the ADADBS CHANGE for them. This is painful when the field is fixed width and Adabas says “no way Jose”. Is there a fix coming for this??
Predict v44 also has other problems. A mismatch between SYSDIC & FDT for type A, SYSDIC-EL has 2 different groups with same group name but with different elements. This shouldn’t be.
Rant off…
Brian, i am sorry that you had problems to migrate your data from PRD 4.2 to PRD 4.4. Did you contact SAG support when your were unable to load the data ? We have not heard about problems loading documentation data delivered with other SAG products here in Darmstadt. Please report the problems you had in detail to SAG support.
The load process does not drop DDMs unless you maintain or administrate the data on the coordinator FDIC manually.
Concerning the data and time fields there is a bug in the generate Adabas file function. A solution already exists and will be delivered with service pack 4 coming end of this month.
I don’t know why you consider a difference of a field length in the FDT( which is only a default length) and in the file description to be a problem. When accessing these fields, Natural provides the format and length specification so that the default length in the FDT is never used. Adapting the default field length in the FDT would be an extra step during installation, that is totally unnecessary.
That SYSDIC-EL contains two groups with the same short name is nothing new. They exist within SYSDIC-EL since version 3.1. Because Natural does not use group names to access Adabas files, there is also no problem.
We tried to get help from support. They wanted to know also what was in the coordinator, but this since we started with a newly created coordinator and a newly created fdic (loaded from PRD441.SYSF), I didn’t see how this could be the problem. If it’s in Predict, and is unloaded from Predict, it should be able to be loaded into Predict, yes? Especially if it passes the consistency check ahead of time.
Because we were on such a time crunch, we couldn’t spend any more time trying to resolve the problem than we devoted to it. Once we had the PRD432 software, we completed the upgrades in all other environments yet to be done with two inplace conversions (42 to 43 and 43 to 44).
Once we did that, support couldn’t help us any further. I was just pleased that the inplace conversions worked exactly as I wanted it to… nothing errored out, nothing was lost.
The sad thing is that this upgrade was performed by a SAG PS person, so that should rule out that we just didn’t know what we were doing, yes?
The other things I mentioned are because they are things we wouldn’t do in our own files. Sure, they don’t cause problems if the programmers using them understand the way the files are laid out, but it doesn’t seem like the best practice. The irony of this is that it’s for the tool we use to apply best practices to metadata management.