Re: Today's episode - IDD seeing double . . .

Discussion created by ca.portal.admin on Aug 16, 2007
Are you running your compile in local mode?
If so, then it is likely a buffer problem.

Tommy Petersen
110 Cokesbury Rd
Room 542H
Lebanon, NJ 08833

Internal 200 - 3699
External (908) 236-3699
Fax: (908) 236-3692

Mike Champagne
Public Discussion cc
IUASSN.COM> Today's episode - IDD seeing double
. . .

08/16/2007 02:42

Please respond to
IDMS Public
Discussion Forum

Good afternoon fellow listees -

A colleague of mine added a source member to our application dictionary -
an 'ENVIRONMENT"" include module for a DC-CoBOL program - that included an
error. After discovering his error upon compiling the program that used
this module, he corrected the error in the dictionary (via IDD), but
subsequent compiles of the program still reflect the old include member. A
DISPLAY MOD *** in IDD would show the corrected source but the compiles
kept getting the old version.


My first inclination was to think that he must have initially added the
member with the error to another dictionary as well; one searched ahead of
the application dictionary (if the DML pre-compiler even does this),
however our compile proc invokes the pre-compiler thusly:


and this is the dictionary into which the member was first added, and then
later corrected.

I tried the *DMLIST directive with IDMSDMLC thinking that maybe it would
tell me where it was fetched from, but no such luck.

Using DMLO, I was able to CALC to the MODULE-067 record and cycle through
the TEXT-088 records in the MODULE-TEST set and it was the ""corrected""
module, not the one that's being fetched from IDMSDMLC, so DMLO behavior
was consistent with IDD.

So I deleted the ""corrected"" module altogether in IDD and the compiler
still picked up the old one. But then I went into DMLO and, lo and behold,
I was able to CALC to a MODULE-067 record and cycle through member TEST-088
records that reflected the (initial) ""error"" module.

So, apparently, we somehow ended up with two MODULE-067 records with the
same CALC key, each with their own separate set of TEXT-088 records hooked
up in the MODULE-TEST set. I did not make note of the DBkeys in DMLO, but
it's interesting to note that IDD and DMLO consistently returned the more
recently added of the two, whereas IDMSDMLC consistently returned the

We are running R15SP2 on zOS 1.4, in case this has been reported and fixed
in a later release. I wish I knew how we created this situation, but as
far as I can tell my colleague simply displayed the existing module in IDD
""AS SYN"", changed the ""ADD"" to ""MODIFY"", fixed the error in the module
text, and pressed enter.

Regardless, I figured that at least some of us on this list would enjoy the
story as well.

Michel J Champagne
Systems Analyst / DBA
<<Picture (Metafile)>>
Voice: 504-712-7589
FAX: 504-712-3589

Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
IDMS Public Discussion Forum


Re: Today's episode - IDD seeing double . . .
"I recall seeing this years ago where you have multi MODULE-067 (Dups
last) records with different languages.

In this case, I'd guess that one was added without a language, and
another with language COBOL. (I forget which order
DMLC looks at them.) In any case, DMLC was more than likely looking at
1 (COBOL) and the user modified the other (no language.) As I seem to
recall, in IDD when you display a module without specifying language,
you get the module without the language class if there is more than one.
If there is only one version of the mod, you'll get the COBOL version.



Richard Pierce
(617) 973-8911