Is there any chance that you are loading a table in your load script with the fields A,B,C,D,X,Y,Z prior to this section of code running? If Qlik encounters a load for a table with the same columns as a previously loaded table, it will concatenate the subsequent table to the first table. You can prevent this with a Noconcatenate statement before loading TAB2.
Joins within a loop are very problematic and will mostly don't work - because already in the second iteration the join will be applied on the extra added fields from the first iteration. Further the new added fields change the table-structure and therefore the second iteration won't load the data within the origin defined table else Qlik creates a new one by appending a continuous number to the table-name.
I don't want to say that's impossible to use such an approach - you may apply a forced concatenation and/or renaming fields and tables for and back and/or using some intermediated steps with extra stored/loaded tables and similar measures but I wouldn't recommend this direction because nearly always are better and easier approaches possible - especially from a performance point of view are such outside-loops very slow if it comes to many iterations.
