Re:Re: Replacing an element in a record

[ca.portal.admin]

Well,

I think you can do it.
Create a new version of the record - same layout, then add that version to
the schema.
Change version 1 to the new layout, that is the one used by the programs,
but no longer by the schema.
Then change the schema once again to use version 1 and recompile the
subschemas.

You lose control of which programs recognize the new layout, but I guess
that is what you were looking for.

I have not tested this, but in theory it should work.

As Yogi Berra said, ""In theory there is no difference between theory and
practice. In practice there is.""

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

Phone:
Internal 200 - 3699
External [phone]
Fax: [phone]




Petra LaFrese
<[e-mail]
NA.EDU> To
Sent by: IDMS [e-mail]
Public Discussion cc
Forum
<IDMS-L@LISTSERV. Subject
IUASSN.COM> Replacing an element in a record


05/07/2009 08:23
PM


Please respond to
[e-mail]
a.edu






I have a simple question and I know all you experts can help me.

I have a record that is composed of 3 main data elements each consisting
of subordinate elements. A subordinate element is being changed in one
of the main data elements.

Normally, I change the record to a higher version number, create a new
version 1 record, recompile the schema with the new record version 1,
and then recompile all the programs that use this record so they are all
using the same record definition. It is a lot of work but then I know
every program is using the same record definition.

In the interest of speed, it was decided not to recompile all the
programs since they will not use the new fields (the system is being
replaced in the next 2-3 years, unfortunately not using IDMS :-( ) The
part of the record being changed is defined as filler and is all spaces.
The new elements are all alphanumeric so I do not have to initialize
them. But how do I get the record to recognize the changed subordinate
element without going through schema and program compiles? I cannot
simply replace the record as it is in a schema and so is owned by the
schema compiler. Is there a way to get around this?

We are running V16.0 SP7.

Thanks for your help.
Petra

------------------------------ IMPORTANT NOTICE ------------------------------
This email transmission and any accompanying attachments contain confidential
information intended only for the use of the individual or entity named above.
Any dissemination, distribution, copying or action taken in reliance on the
contents of this email by anyone other than the intended recipient is strictly
prohibited. If you have received this email in error please immediately delete
it and notify sender at the above email address.
------------------------------ IMPORTANT NOTICE ------------------------------
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Replacing an element in a record
"Thank you all for your responses - on and off list. I used Tommy's
advice and it worked like a charm! I knew you all would come through -
you are great!

Regards,
Petra


>
"
IDMS 3rd-party providers forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Replacing an element in a record
"Thank you all for your responses - on and off list. I used Tommy's
advice and it worked like a charm! I knew you all would come through -
you are great!

Regards,
Petra


>
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
R17 upgrade FYI's
"We have an R17 test CV up now. Here are my first lessons learned:

1) The first time you generate a DMCL after upgrading, the dynamic new cop=
y does not work. It gets the error message below. You must bring in the r=
egenerated DMCL with a CV outage. Maybe this was documented somewhere, but=
I don't remember seeing it. I do see in my R16 upgrade notes that we sche=
duled outages to regenerate all the DMCL's shortly after the R16 upgrade, s=
o maybe you are just supposed to know to do this every time.

ERROR AUDITING/BUILDING THE NEW DMCL. BLDR RETURNED A STATUS OF 04. SEE LOG=
.
RELEASE NUMBER OR OPSYS ID. CHANGED BETWEEN CURRENT DMCL AND NEW DMCL.

2) Optional APAR bit #135, which was withdrawn, has been reinstated via PT=
F T5B0194 (soon to be a published APAR).

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: [phone] Fax: [phone]
Email: [e-mail]
"
IDMS 3rd-party providers forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
R17 upgrade FYI's
"We have an R17 test CV up now. Here are my first lessons learned:

1) The first time you generate a DMCL after upgrading, the dynamic new copy does not work. It gets the error message below. You must bring in the regenerated DMCL with a CV outage. Maybe this was documented somewhere, but I don't remember seeing it. I do see in my R16 upgrade notes that we scheduled outages to regenerate all the DMCL's shortly after the R16 upgrade, so maybe you are just supposed to know to do this every time.

ERROR AUDITING/BUILDING THE NEW DMCL. BLDR RETURNED A STATUS OF 04. SEE LOG.
RELEASE NUMBER OR OPSYS ID. CHANGED BETWEEN CURRENT DMCL AND NEW DMCL.

2) Optional APAR bit #135, which was withdrawn, has been reinstated via PTF T5B0194 (soon to be a published APAR).

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: [phone] Fax: [phone]
Email: [e-mail]
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
IDMS is EVERYWHERE
"as i navigate my sessions at (dare I say) IDUG - I run in to more and more
IDMS every day ...

and i heard that in release 10 of DB2 is inventing ,..... a CALC KEY!!!!!
(sorry - its called a ""hashing key"") (a ""hashing index"" was introduced in
version 9 - and it was hinted that they will move from a hashing index to
direct hash retrieval in version 10)

a CALC key - what a GREAT idea .......






Chris Hoelscher
Senior IDMS & DB2 Database Administrator
Humana Inc
502-476-2538
[e-mail]

you only need to test the programs that you want to work correctly




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 3rd-party providers forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
IDMS is EVERYWHERE
"as i navigate my sessions at (dare I say) IDUG - I run in to more and more
IDMS every day ...

and i heard that in release 10 of DB2 is inventing ,..... a CALC KEY!!!!!
(sorry - its called a ""hashing key"") (a ""hashing index"" was introduced in
version 9 - and it was hinted that they will move from a hashing index to
direct hash retrieval in version 10)

a CALC key - what a GREAT idea .......






Chris Hoelscher
Senior IDMS & DB2 Database Administrator
Humana Inc
502-476-2538
[e-mail]

you only need to test the programs that you want to work correctly




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
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: IDMS is EVERYWHERE
"Hi Chris,
I remember going on a course of IDMS internals. How can they be internal
if they are everywhere?=20
One of the things on the course was how to write your own calc
algorithm. Why one would want to do that was more interesting to me than
how to actually do it! =20

Now back to this MS sqirrell server stuff which will replace my beloved
IDMS, and is keeping me much more busy. I suppose I should be grateful
for that, but I'd sooner be messing with hex!
Cheers,
Geoff =20