Thank you very much for your quick reply. Let me specify further:
1) I changed the "bankfmt" calls to a call to txt2bos.
This did not change anything.
2) I turned off most of the other banks. (I'm left with "head" and "SC"
"SCH" and the oroginal "MCEV" and "MCTK" banks that were already in the
input data stream. I'll try to turn those off also.
What causes a "corrupted" BOS common ?
-- Maurik
P.S. The more I hear, the less I like it.
On Fri, 10 Apr 1998, Joseph Manak wrote:
>
> Is the new bank being written out? if not did you add it to the E list?
> Another thing to check is that you
> should be sure when you are making the bank that it is
> the right size....
> Did you define the bank in configure_banks.c or if you
> use txt2bos in the ddl file you use?
>
> Also, in my experience, sometimes when this happens when some other
> bank that is being created is messing up the bos common
> (as you alluded to ) - so if you can switch
> off other bank producing parts of the code you can
> isolate the problem. More often I get situations
> (like the one I a suffering with today in the tracking
> code preventing me from getting a prodcution dec97 recsis AAHHH)
> in which recsis/a1 dies deep inside the fwbos call because
> of a corrupted bos bank, the only way I know how to get out of this
> is to start switching packages off until I find the
> culprit. If I can digress into philosophy a bit - this is
> why we need modular code - so pieces can be built and
> tested completely independantly from eachother.
>
> - Joe
>