ca.portal.admin

Today's episode - IDD seeing double . . .

Discussion created by ca.portal.admin on Aug 16, 2007
Latest reply on Aug 16, 2007 by ca.portal.admin
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:

//IDMSDMLC EXEC PGM=3DIDMSDMLC,REGION=3D4M,PARM=3D'DICTNAME=3DCASPDICT'

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 older.

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.

PELLERIN MILNOR CORPORATION
Michel J Champagne
Systems Analyst / DBA
<<Picture (Metafile)>>=20
Voice: 504-712-7589
FAX: 504-712-3589
=20
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 message.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Today's episode - IDD seeing double . . .
"Modules come with three qualifiers, only one of which is part of the CALC
key (name). Language and version # are used differently by the IDD compiler
and the preprocessors.

Unless you specify a version number, you may be defaulting to version 1,
lowest, highest or something else; and the default is probably set up
differently in IDD vs. DMLC.

The DMLC compiler wants to use modules with language ""COBOL"", after that he
gets interested in version numbers.

Did you check to see if the corrected module actually got added as a higher
version #?

Looking at the behavior (and not the dictionary Bachman), I would guess the
MODULE-066 is defined as ""duplicates first"".

* DQC

Outcomes