(Reposted by request from Chris Mason) Sorry, I've no idea regarding whether the first duplicatly named entry is taken, the last duplicatly named entry is taken or some random selection. If my arm were twisted, I'd say the first. I don't believe VTAM expects to handle that many mode table entries so I don't expect a complex technique such as a hash table is used and I can't see why VTAM should deliberately suspect duplicates and make sure it used the last. I expect you are already aware that IBM *always* considers the ISTINCLM mode table in SYS1.VTAMLIB to be concatenated after any private mode table (MODETAB=). This would tend to suggest that VTAM simply takes the first mode table entry having a particular name so that you can respecify a mode table entry from ISTINCLM in a private table if you want to. I think I've always simply assumed that and I can't recall ever having checked that. Incidentally, this use of ISTINCLM concatenated after the MODETAB name means that ISTINCLM is not a default for the MODETAB operand as is usually - and quite incorrectly - stated. I expect you are also aware that the DYNMODTB start option was designed for the specific purpose of having a private mode table which could be used by any secondary LU or representation of a secondary LU especially when the representation of a secondary LU is a dynamic CDRSC. I'm not sure whether or not that may be relevant to the original problem you were trying to solve. Prior to the availability of the DYNMODTB start option - with great reluctance - VTAM gurus were obliged to suggest modifying ISTINCLM - shock, horror! With the availability of the DYNMODTB start option, they could all forget that they had ever had such an heretical[1] thought! You might like actually to explain the original problem which led you down this perilous path. There has to be a better solution to whatever it is. If you want a definitive answer about how VTAM handles duplicate mode table entries in the object module, I expect you are going to have to sweet-talk your IBM VTAM support into activating a request to development - and hope for the best! Incidentally, I discovered that I needed to create Unformatted System Services (the real USS) tables with assembler errors in the sections where I coded complex 3270 data streams. As you did, I checked the object code and found everything was there I wanted to be there even though I had to swallow some insulting messages from the assembler!
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
