I'm getting error 598:
<file-name> is a copy of <file-name>. Database cannot be opened. (598)
PROGRESS tried to open a multi-volume database, identified by the first
pathname. This structure file, however, is a copy of the structure file
identified by the second pathname.
I'm getting this b/c we're moving to a new server and i'm forced to use a new filesystem: /apps, whereas before all my stuff was in /u2/appl. So, hoping to avoid issues related to no longer being in /u2/appl, I did a symbolic link (ln -s /apps/u2 /u2). Smooth sailing until I tried to open the database /u2/appl/mydb, when I got error 598.
Is there an easy workaround to tell progress not to care that my database isn't where it thinks it is?
To explain the answer above a bit better - fix the .st file of the database you've copied, so that it points to the actual locations of the components you've copied, and then run 'prostrct repair {dbname}'. This will fix the links in the .db to point to the proper files. You can leave the .st as relative paths so long as you have it in the same directory as the database.
to elaborate further,
the database's ".db" file contains a list of the pathnames of all the other files that belong to the database (data extents, transaction log extents, etc). each of those other files has a header that contains the pathname of the ".db" file. when you try to open a database and the two don't match, then you get error 598. when you make a copy of a database using operating system copy tools, the .db file and the extent headers do not get updated to reflect the new location of the copy -- the copy's extent headers point back to the original .db file. this is easy to fix using the ".st" file.
the .st file contains a human readable form of the .db file contents. it is optional and not used during normal database operation. as james explained, you edit the .st file to have the new path names and then run the repair tool to fixe the database.=