In this case, however, a successfull, albeit very fast run BDLS job, resulted in the following error message when attempting to rename the logical system. Even SAP were unable to provide a timely solution to the problem.
This was, in retrospect ofcourse caused by the fact that the BDLS job only LOOKED successfull, but in fact stopped after only a few tables. One of the tables was ofcourse the T000 (which meant that the client would try to use a logical system name which didn't correspond to the technical name), aswell as the DBLS table(s). So everything looked to have finished ok. There also wasn't any error messages.
The trick was, how could I see that the job actually hadn't doen what it was supposed to ? BDLS runs for other logical systems ran just fine, and this had never been an issue in the past. I had to run a debugging of the BDLS transaction.
I had in the past had many discussions with a colleague about the BDLS functionality. I said there was a dynamic program containing the fields to be converted, he said that all fields defined as "logsys" would be converted. It turned out We were both only partly right. There IS a program, which creates a dynamic mapping of all the fields containing the logsys. And then the conversion starts based on this BDLSMAP. However, there apparently isn't any controls available to determine if this mapping fails. and in my case it did.
So I ended up finding a service program for the BDLSMAP that could clear the mapped data, After running that, the BDLS run finished fine, and all of our logical system problems went away. I'm seriously considering if this program, RBDLSMAP_RESET shouldn't ALWAYS be run prior to a BDLS run.
