VAST improvements: Navigation in Config Maps

I’ve spent quite some time merging code recently, releasing Applications into Maps and Changing Required Map versions in other maps in an effort of porting a significant amount of existing VA Smalltalk code from Version 7 to the latest version 8.5.2.

There is a lot to say about how you should or should not structure your code and the fact that merging code and releasing lots and lots of open editions can be a hard job. You need to be fully awake and always be careful not to make mistakes that only adds to the pile of tiresome and demanding work to do. But there are a few ideas for small improvements to the configuration map browser that would make life so much easier and I thought I’d start with a little collection here and ask people to comment on them or add their own. Hopefully this will lead to a list that Instantiations considers as an inspiration for improvements in the tool…

  • First of all, I painfully missed a back/forward button. Really. You jump between maps and map editions all the time and loose a lot of context without the ability to just jump back.
  • A cheap alternative would be the option to spawn a new config map browser for certain lookups. My most painfully missed ones was the “find” menu item on the required maps list and the “Dependents” family of menu items on the maps list. Let me elaborate a lttle on the dependents thing: You are in process of releasing new apps or app editions to a config map and now need to find out which other maps need to be updated because this new edition needs to be released as a required map to these. All that VAST offers right now is that it selects all dependent maps in the same list. This is really stupid, because as soon as you click on one of them to change the required maps there, the other selected dependent maps are deselected. Bummer. So you after releasing into the first of the dependent maps, you have to navigate back to the one you came from (which sometimes is hard to remember if you’ve been doing this for hours now), search for dependents again and go to the second hit just to start the whole cycle again. So how did I help myself here? I did the search for dependent maps, went to the Transcript, opened a new Config Maps browser and navigated  to all the hits marked in the first browser one after the other. Was that a good experience? No. Because you need to dig down deeper on each of them, so you end up with 5 or more config maps browsers open and get lost very easily. So a first and cheap improvement would be to let the search for dependent maps open a new config map browser with only the found dependent maps in it. The window title could be “Maps dependent on MyConfigMap (Immediate)”. This wouldn’t really keep me from loosing track from time to time, but it would help me stay much more focussed on my job than the existing tool chain.
  • The MED Required Maps browser is of great help when it comes to understanding what maps and editions thereof are going to be loaded when you load a map. Such a tree is a great way to visualize what you’re dealing with. But it is a read-only tool You always have to have a normal config map browser open next to it in order to act on what you see.
  • When you load a map with required maps, and one of the maps in that graph is referenced/used in more than one edition, VAST warns you about it before it loads the code. But it doesn’t really support you in finding where these ambiguous references are. I may miss some existing menu item in the config maps browser, but I wished for an option to find all occurrences of editions of a certain config map in a given graph of required maps of one particular map edition. It can be very hard to resolve the issue at hand without it. The same of course applies to application editions/versions. Two maps in a graph can load an app in separate editions, but there is no way that I’m aware of that you could search for these occurrences. It is hard enough to decide if that may or may not be a wanted constellation (like “I want to load this feature, but there is a fix to a class in that particular application that I need to load a newer version of on top of that”), but as VAST stands today it is already hard to find out that there is such an issue at hand. Or maybe I am just missing some menu item and someone can shed some light on it for me…
  • In the real world, projects tend to build up code structures over the years where there are lots of ambiguous references, circular and conflicting required maps associations and there’s a lot of stuff that can go terribly wrong in such code bases. One case where such problems show their ugly face is migrations of code between VAST releases. You typically open up all maps during the process and produce lots of open map and application editions. Every time I try to resolve such issues, I start doing the very same thing: take a sheet of paper and draw boxes (for map editions) and connecting lines (for req. map relationships), just to understand the graph of code artefacts at hand. In this particular project, I simply gave up on it after a few hours, because 3 sheets of paper simply didn’t suffice. I knew there are lots of unnecessary req. map relationships but without a visual way of understanding the whole graph, it is almost impossible to decide which relationships may or may not be superfluous. So what would really help a lot would be a tool that visualizes the required maps graph of a map. This graph should at least show all relationships between maps, but it would best also include version numbers / edition timestamps.

So I am eager to learn what other VAST users think of these suggestions, where they see potential for improvements, what kind of tools they wrote (we do use a little box of utilities of our own as well), or what tricks people use to solve the kinds of problems i describe here. Feel free to comment and let’s start some discussion that could help Instantiations improve VAST and Envy tooling in future releases…

Little addendum for db2move

A few days ago I posted a link to a tiny tutorial on how to use db2move to transfer db2 databases from Linux to Windows. This works very nicely, apart from the fact that I had a problem with some tables that were created but not filled with data. The data is in the .ixf files but will not be imported into the tables. db2move even tells me it was successful.

I stumbled across a few more or less helpful discussion threads that covered some problems, ob f which seemed to be related to mine. It turns out that the .lst file that gets written on export only contains tables that were successfully exported without any errors or warnings. Hmm. There were some warnings on export of tables. There were lots of .msg files. And they all contained warnings that I thought can be ignored without any harm. The warnings I got on export were all of this kind:

SQL3132W The character data in column "INRPAN" will be truncated to size "5".

The “affected” columns were either of type CHAR or VARCHAR, so I thought there’s no deal here. Especially because  the msg files all ended with this line:

SQL3105N The Export utility has finished exporting "4113" rows.

So you might think all is good and fine. But for DB2 it’s not.
It turns out there is an “accept warnings” switch “-aw” that, if appended to the export command, leads to all tables that had warnings will be included in the .lst file and thus will be imported to the target db.

So I guess it is a good idea to export data using this call in most cases:

db2move YOUR_DB_NAME export -aw

And here finally is something I found to be extremely helpful when it comes to changing the schema of tables, sequences and such (a job that sounds easy, but isn’t):

db2 "call ADMIN_COPY_SCHEMA('OldSchema','NewSchma', 'COPY', NULL,NULL,NULL,'TEST','ERR_TAB')"

How-To: Transfer a DB2 database from a Linux machine to a Windows PC

For debugging reasons I needed to extract a DB2 database from a Linux DB2 server to a development machine running Windows XP. DB2 export database and import database didn’t work in this scenario due to some differences between Linux 64 bits and Windows 32 bits. So I was out of luck with this endeavor (which initially looked like a sunday afternoon walk).

But today I found this jewel that explains all of what needs to be done in just a few lines. Thanks so much, TeknoMagus, you’ve helped me a lot! I knew it must be not only feasible, but also not too hard. But this was exactly what I needed. If we ever meet in person, pleas remind me I owe you a drink.