ca.portal.admin

Calling IDMSCOM

Discussion created by ca.portal.admin on Aug 16, 2007
Hi all,

In preparation for our Data Warehouse project, I'm using the Journal
analyzer to re-assemble my records of interest into non-spanned records.
(Thank you DBMS and CA!).

Now for my problem - Compressed records. Compressed records show up in
the journal as, well, compressed records. Because we're not using IDMS
to get the record, IDMSDCOM is not being called - naturally.

Has anyone written COBOL code to call IDMSDCOM to de-compress compressed
records? If so, are you willing to share? Please?

Thanks much,

Dick

Richard Pierce
(617) 973-8911
richard.pierce@state.ma.us
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: [IDMSVENDOR-L] Calling IDMSCOM
"have you considered CULPRIT to get the journal records? i believe that
CULPRIT, when called with the appropriate input module, will uncompress
journal records (i would be wrong though)


Chris Hoelscher
Senior IDMS & DB2 Database Administrator
Humana Inc
502-476-2538
choelscher@humana.com



The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Today's episode - IDD seeing double . . .
"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=IDMSDMLC,REGION=4M,PARM='DICTNAME=CASPDICT'

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)>>
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 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 . . .
"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

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




Mike Champagne
<mchampagne@MILNO
R.COM> To
Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
Public Discussion cc
Forum
<IDMS-L@LISTSERV. Subject
IUASSN.COM> Today's episode - IDD seeing double
. . .

08/16/2007 02:42
PM


Please respond to
IDMS Public
Discussion Forum
<IDMS-L@LISTSERV.
IUASSN.COM>







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=IDMSDMLC,REGION=4M,PARM='DICTNAME=CASPDICT'

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)>>
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
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: [IDMSVENDOR-L] Calling IDMSCOM
"Questionable, I don't believe CULPRIT handles spanned records properly.

Dick

Richard Pierce
(617) 973-8911
richard.pierce@state.ma.us

Outcomes