Changing record id
Michel Lamoureux
record id of occurrences of records.
Michel Lamoureux, dba
Québec Police Force
Miley, Dan L , N-Dan Miley & Associates, Inc.
1) Write a program that reads each page as a record in a QSAM file.
Walk backwards from the footer modifying each line index for the affected
record changing the record id to the one desired. Then write the page to
the output file. A caveat: if there is a possibility of SR2/3 records, you
will have to account for that by doing checking for SR3's. That is, if a
record is an SR3, then you will have to use the offset in line index to get
to the actual record on the page, if the actual record is the one you want,
then you will have to change that as well. I know that this sounds
confusing, but it really is not. Just take a look at the IDMS/DB internals
class chapter 2 for more info.
2) Write programs (or use ISP's DEMI product) to extract all the
affected records. Then reload them with the new name. This could be more
time-consuming then option one if there are a lot of set connections to
worry about.
The above should give you some ideas.
Dan Miley
D. L. Miley & Associates, Inc.
Consultant at Lockheed-Martin
Lorenzen, David C
If you looking for a time consuming effort, with a large chance of
disaster, then this is it.
Simple solution. Unload/Reload the data area. The reloaded view
will of course indicate the new record id's.
David Lorenzen
EDS
Bob_W...@tiburontech.com
Manual section 32.2:
"During UNLOAD and RELOAD processing, record formats are preserved that is,
the layout of data within a record and record positions within sets. This
limits the modifications that you can make during an unload/reload
operation. For example, you cannot use an unload/reload operation to:
.......
Change or delete record IDs"
The safe way is to create a program to extract and delete the record id's and all subordinate sets and then create a program to recreate the record
and subordinate
sets with a new schema/subschema and record-id.
Reading the page to modify Line Indexes is also possible, but you have to know your DB-Internals pretty well.
Bob Wiklund
Tiburon Technologies
Lorenzen, David C
Like I just told Michael offline, I know I have done this in the
past. This is not something we all accomplish on a regular basis,
but it can be accomplished using Unload/Reload. Maybe we modified
the intermediate files, but my memory slips me for the moment.
David Lorenzen
EDS
-----Original Message-----
From: Bob_W...@TIBURONTECH.COM [mailto:Bob_W...@TIBURONTECH.COM]
Sent: Monday, July 24, 2000 1:27 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: Changing record id
SEA...@pillsbury.com
David: accrding to the R14.0 Utilities manual:
During UNLOAD and RELOAD processing, record formats are preserved that is,
the layout of data within a record and record positions within sets. This
limits the modifications that you can make during an unload/reload
operation. For example, you cannot use an unload/reload operation to:
Remove a set
Remove a record type
Insert new data fields into a record
Change the order of a sorted set
Connect records to new sets
* Change or delete record IDs
Change the size, location, or data type of sort or index keys
Change a set from unordered to ordered
These type of changes require other utilities, such as RESTRUCTURE, and
possibly user-written programs.
I think the user-writen program is the only way to do this. That is, after
making an identical copy of <reca> and identifying the copy <recb> to the schema
and subschema, OBTAIN <reca>;MOVE <reca> to <recb>;STORE <recb> (and
possibly) ERASE <reca>, This could be done with a simple COBOL or Easytrieve
program.
"Lorenzen, David C" <david.l...@EDS.COM> on 07/24/2000 01:12:40 PM
Please respond to IDMS Public Discussion Forum <IDM...@LISTSERV.IUASSN.COM>
To: IDM...@LISTSERV.IUASSN.COM
cc: (bcc: Stephen V Earle/USA/Pillsbury)
Miley, Dan L , N-Dan Miley & Associates, Inc.
from the manual. The others have stated it quite well. You cannot use
unload/reload to change record IDs!
Both of the methods will work (I have done both!). Modifying a database
page is NOT the end of the world if you understand how it is formatted. The
program can even be written in COBOL using
reference modification.
As for extracting and reloading the records, there is the caveat of having
to store and reconnect records, so option 1 may be better if there is a lot
of set connections to worry about.
Dan Miley
D. L. Miley & Associates, Inc.
Consultant to Lockheed-Martin
-----Original Message-----
From: Lorenzen, David C [mailto:david.l...@EDS.COM]
Sent: Monday, July 24, 2000 2:13 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: Changing record id
Michael,
If you looking for a time consuming effort, with a large chance of
disaster, then this is it.
Simple solution. Unload/Reload the data area. The reloaded view
will of course indicate the new record id's.
David Lorenzen
EDS
-----Original Message-----
From: Miley, Dan L (N-Dan Miley & Associates, Inc.)
[mailto:dan.l...@LMCO.COM]
Sent: Monday, July 24, 2000 12:52 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: Changing record id
Miley, Dan L , N-Dan Miley & Associates, Inc.
program is still required. End of discussion, I hope. I guess it is
gratifying that there are still people interested in IDMS!
Dan Miley
-----Original Message-----
From: Lorenzen, David C [mailto:david.l...@EDS.COM]
Sent: Monday, July 24, 2000 2:41 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: Changing record id
Bob,
Like I just told Michael offline, I know I have done this in the
past. This is not something we all accomplish on a regular basis,
but it can be accomplished using Unload/Reload. Maybe we modified
the intermediate files, but my memory slips me for the moment.
David Lorenzen
EDS
-----Original Message-----
From: Bob_W...@TIBURONTECH.COM [mailto:Bob_W...@TIBURONTECH.COM]
Sent: Monday, July 24, 2000 1:27 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: Changing record id
You cannot use Unload/Reload to change Record IDs. Per the Utilities
Manual section 32.2:
"During UNLOAD and RELOAD processing, record formats are preserved that is,
the layout of data within a record and record positions within sets. This
limits the modifications that you can make during an unload/reload
operation. For example, you cannot use an unload/reload operation to:
.......
Change or delete record IDs"
The safe way is to create a program to extract and delete the record id's
conl...@ix.netcom.com
I lobbied for a long time to combine them all into one large schema and finally, I was given the green light to do it. One of the biggest obstacles to overcome was the fact that over the years, in the different schemas they had "reused" record-ids.
That is, the "CUSTOMER" record was record-id 200 in "Schema A" but the "OBSCURE-REC" was record-id 200 in "Schema X". Bad.
The only saving grace was that most records in the database were simple records stored via indexes or Calc mode with few set connections.
In my case, I had to determine which record truly should be assigned the record-id of 200. I went with the path of least resistance. In other words, which "200" record would be easiest to offload and reload with a program.
I did it with a semi-disposable parm driven COBOL program that both unloaded and reloaded with old/new subschema parmed-in.
Jim Moore
IDMS Public Discussion Forum <IDM...@LISTSERV.IUASSN.COM> wrote:
> I have 15 years experience with IDMS, so I didn't bother stating the obviousfrom the manual. The others have stated it quite well. You cannot use
unload/reload to change record IDs!
Both of the methods will work (I have done both!). Modifying a database
page is NOT the end of the world if you understand how it is formatted. The
program can even be written in COBOL using
reference modification.
As for extracting and reloading the records, there is the caveat of having
to store and reconnect records, so option 1 may be better if there is a lot
of set connections to worry about.
Dan Miley
D. L. Miley & Associates, Inc.
Consultant to Lockheed-Martin
-----Original Message-----
From: Lorenzen, David C [mailto:david.l...@EDS.COM]
Sent: Monday, July 24, 2000 2:13 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: Changing record id
Michael,
If you looking for a time consuming effort, with a large chance of
disaster, then this is it.
Simple solution. Unload/Reload the data area. The reloaded view
will of course indicate the new record id's.
David Lorenzen
EDS
-----Original Message-----
From: Miley, Dan L (N-Dan Miley & Associates, Inc.)
[mailto:dan.l...@LMCO.COM]
Sent: Monday, July 24, 2000 12:52 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: Changing record id
hoel...@us.ibm.com
Otherwise, imagine a subsequent DASD failure requiring a
restore/rollforward ... you would need to change the schema back to reflect
the OLD record ids (or does rollforward look at record NAMES, not record
IDs?)
Chris Hoelscher
IDMS System Software Support
Sophisticated Business Systems
Dallas Texas
On Assignment to IBM Global Services
Outsourcers for GE Capital Corporation
(972)-561-6406
Jim Phillips
names in the journal file.
Ages ago I wrote a program to insert missing owner pointers into IDMS
records using the method Dan describes (PCON takes forever for long sets).
This could easily be simplified to meet the record id requirement. It was
published in Boxes and Arrows and I have a copy at home somewhere, I'll post
it when next there (note, if this is an urgent requirement it'd be quicker
to find the old B & A).
BTW, the reuse of record id's as described by Jim Moore is actually very
common, sometimes as a result of duplicating record id's used in packages,
sometimes because originally IDMS record id's below 100 were for the
dictionary and higher ones for applications, and sometimes because the shop
employed two DBA's.
Jim Phillips
Programmer
ISP
on assignment somewhere else this week.
(800) 295-7608 x23
>From: hoel...@US.IBM.COM
>Reply-To: IDMS Public Discussion Forum <IDM...@LISTSERV.IUASSN.COM>
>To: IDM...@LISTSERV.IUASSN.COM
>Subject: Re: Changing record id
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Michel Lamoureux
IDMS allow duplicate record id in the same schema but different area. Last
year, an dba work for me and use a duplicate record id in the same schema. I
don't like it but it is done and the software allow it and i know there is
an optiannal apar for come back in the old days for uniqueness of record id
by schema.
But when you want to do unload reload or an area reorg with the two areas,
it don't work. The problem is know and the solutions is addressed in 15.0.
That is why i prefered do a change record id for having the possibility of
using tools after that.
Michel Lamoureux, dba
Québec Police Force
-----Message d'origine-----
De: IDMS Public Discussion Forum [mailto:IDM...@LISTSERV.IUASSN.COM]De
la part de JB Moore
Date: 25 juillet, 2000 11:39
À: IDM...@LISTSERV.IUASSN.COM
Objet: Re: Changing record id
Good point Bob, I wondered the same thing myself. In my 20-into-1 schema
conversion, it had to be done. Whenever people ask me: "How could that even
happen, getting duplicate record-ids in the same database?" Simple. Multiple
schemas. A good analogy would be having a large, complex program to
maintain. Then, copying it 20 times and trying to manually keep every single
line identical. Good luck.
The site that I referred to had many other problems due to their plethora of
schemas. For example:
1) Records that were compressed in one schema but uncompressed everywhere
else. Every so often a compressed version of the record would get stored and
it would wreak havoc.
2) An index set defined in 2 different places. In one schema, it was
commingled in with the data. In all others it was in its own area. And yes,
two discrete SR7s existed for it.
3) Different page ranges for various records, including CALC page ranges.
Ouch!
4) Different record versions in different schemas.
And so on.
The case that I made for the combination of 20 schemas into one centered
around all the duplicate maintenance that had to be done. My point was that
they were treating schemas like subschemas. In fact, within the 20 schemas,
about 75-80% of all metadata was the same. Some had more areas, records and
sets than others. Some had less. Frankly, it was a mess.
I'll never forget when their DBA, in all seriousness, asked me: "Do you know
how much machine time it's going to take to generate such a monster, Jim?"
I answered him, in all seriousness: "Oh, about the same time it takes to
generate 20. Probably less."
Jim Moore
----- Original Message -----
From: <bob.n...@EDWARDJONES.COM>
To: <IDM...@LISTSERV.IUASSN.COM>
Sent: Tuesday, July 25, 2000 5:40 AM
Subject: Re: Changing record id
I don't recall this being asked, but why do you need to convert the
record-id?
Per Book Mangler 14.0 CA-IDMS Database Administration.
record-id-number
Specifies an absolute record ID; it must be an unsigned integer in the
range 10 through 9999. Record IDs can be duplicated across areas in
the schema, however, record IDs must be unique for all records within
one area
We keep all of our record-ids unique but duplicates can exist as long as
they are in different areas.
Bob Nardin
Edward Jones
> To: IDM...@LISTSERV.IUASSN.COM
> Subject: Re: Changing record id
>
>
> Michael,
> If you looking for a time consuming effort, with a large chance of
> disaster, then this is it.
>
> Simple solution. Unload/Reload the data area. The reloaded view
> will of course indicate the new record id's.
>
> David Lorenzen
> EDS
>
> -----Original Message-----
> From: Miley, Dan L (N-Dan Miley & Associates, Inc.)
> [mailto:dan.l...@LMCO.COM]
> Sent: Monday, July 24, 2000 12:52 PM
> To: IDM...@LISTSERV.IUASSN.COM
> Subject: Re: Changing record id
>
>
JB Moore
Robert_...@ao.uscourts.gov
IDMS came along as the IBM-compatible implementation of the report of
the Database Task Group of the Conference on Data Systems Languages,
circa 1974.
The concept motivating the report, as it was explained to me, was that
data belongs to the enterprise, and that the enterprise has one universe
of data, hence one schema.
Would life be simpler if that concept had never vanished? Where
feasible, it might be a good idea to continue to honor it.
JB Moore
10.2, back in 1993-94. The record-id had to be unique back then. I would
still attempt to keep the record-id unique though. It is one of the last
"physical" things left in the schema. It becomes one of the halfwords in the
line-index for heaven sake.