We have a table that has been deleted from BaaN, so there is no corresponding unix file. Yet when we reconfigure, it fails because there is "No definition in definition file for sopen(...)". Where is it getting the information that this none existent table needs reconfiguring?

The system has been moved from 1 server and the path for the table was changed after BaaN was started. Would this be something to do with the old path being retained in shared memory? How do I check?

Check and see which table definition it might be trying to use.

If you are in a UNIX environment, log into Baan as the user who is getting the error and then from the Menu Browser click “File” and then “Run”. Once “Run Program” (ttdsk2080m000) opens up, type in ksh as the Program/Session, check the box labeled “Run External Program” and click “OK”.

Once the terminal emulator opens up (do not close this window), type explode6.1 d<package><module><table>. This will show at the operating system level which table definition is being used.

For example:
explode6.1 dtfgld410
/usr2/baan4/dict/ddOPER_001/dtfgld/dtfgld410

Thanks, but this just confirms what I found the long way, the unix file does not exist!

$ explode6.1 dtisfc973
explode6.1:
No definition in definition file for explode6.1(F_BRDD:dtisfc973, dtisfc973)
First exploded '/baanivc/softdevc/bse/dict/ddDEVT_008/dtisfc/dtisfc973'
errno 2
Last exploded 'dtisfc973' errno 2

:eek:

Maybe you're reconfig failed because you had a reference to the table.

Hope I didn't made a stupid remark...

Dick

I hope that remark was tongue in cheek!

You may be right, how do I check?

Go on UNIX level to the place where the DD's are stored and grep for the table in the files.

Also check with general table maint. some tools tables called "reconfig restart data" and "runtime indicators".

you might have in there some indicator, that Baan still needs to reconfigure the ghost table!

Good Luck,

markus

We resolved the problem by copying the BaaN table and manually creating the corresponding unix file. The convert to runtime then completed OK. Smiles all round until...

The developer created a new table. The corresponding unix file is not created. When I (as bsp) create a different table, the unix file is created! When I modify and convert to runtime the developers table, the unix file is not created.

This user worked fine on the old Solaris system, only when we migrated to AIX has this problem occurred. Any ideas?

[QUOTE=Alick Wilson]

The developer created a new table. The corresponding unix file is not created. When I (as bsp) create a different table, the unix file is created! When I modify and convert to runtime the developers table, the unix file is not created.

QUOTE]

Sounds to me like a trivial unix authorization issue. Check your directories and sub directories to be owned by bsp, but to be writable also by the group!

Having been caught out by this so many times (and still not learning) I checked this when we first hit the problem.

All the directories bar the top one are set to write enabled for the bsp and bsp group. So of /baanivc/softdevc/bse/dict/ddDEVT_008/dtisfc, only /baanivc is owned by root, group system.

But you're probably right, it will be something so simple.

:(

When the user was created, he was in the wrong group. So when he created a test table, the unix permissions caused the job to fail and put some records in ttaad504.

When the user had been corrected, the records still existed, hence the reconfigure. New it was simple once you know how.

:)