ca.portal.admin

Re:Re: Convert Page

Discussion created by ca.portal.admin on Jan 4, 2008
On Thu, 3 Jan 2008 16:58:51 -0700, Mike Baker <mikebaker345@HOTMAIL.COM>
wrote:
Hi,

We have been doing some Convert Page's recently, and have some more to
do soon. In the Utility manual, it says;

""If an area that is being converted has a cross-area set or linked
constraint, then you must convert all areas touched by the set or link.
You must determine what files are affected, and therefore what files
must be converted.""

We got burnt by this in Test, as in one of our Convert Page jobs,
several Areas/Files were accidently omitted, and it was not noticed
until a User was trying to navigate the database, and it just said,
""Read Error'. It was subsequently backed out and re-done correctly.

What I want to know, and would appreciate feedback on, is if this
happened in production, and we (for eg.) converted Areas ""A"", ""B"", and
""C"". But only later (to late to back anything out) we discovered that
we should have also included Area ""D"" in the Convert Page job, how
would we fix this?? Would an OBTAIN, DELETE, and STORE (of the obtained
record) of all the records in Area ""D"" fix the problem??

Thank you.
Correction... I guess that we'd need to do an Unload/Reload.

Would this fix the corrupt Page Numbers/Database Keys??

Thanks.\
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Convert Page
"I did run a DBAN after getting the problem in test, and yep it showed
errors. Unlike IMS where I run Pointer Checkers regularly, our IDMS guy
only runs DBAN after a problem arises, which is okay (I guess) if you've
got more skills than me. I'll start treating IDMS the same as IMS regards
Pointer Checks.

I had wondered whether or not the Unload be useful in this regard, so
thanks for that tip.

We're shuffling our Areas around, to free up some big contiguous page
ranges for some upcoming Unload/Reloads. We currently only have one Page
Group.

Thanks to all for the feedback on this.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Convert Page caused 1153 error - HELP PLEASE
"Thanks guys, for the feedback on this problem.

I believe that we're on top of the problem now, I'll post the details
later just FYI to state what has transpired.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Convert Page caused 1153 error - HELP PLEASE
"are both the owner and member records in the same area? if not, did
you run the convert page utility against both areas?

if they are in the same area, is it possible you were using symbolics
(referencing IBC,etc) on the DMCL that referenced the original page
layout, but that those got dropped along the way (or vice versa?)

chris



At 07:13 PM 1/6/2008, you wrote:
Hi all,

I have used the Convert Page in production on an Area that has a Set that
is an Index Set sorted on DB Key, and now we get 1153 errors when trying
to store a new record in this Index.

There is no problem when either reading the record, OR modifying the
record in this Index.

Thanks very much.

Mike.
This is Chris Hoelscher and I approved this email
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Convert Page caused 1153 error - HELP PLEASE
"Mike,

I have gotten this ABEND and 1253 in the past. In all most all cases I found something had changed with the index definition, as stated below, after the data was initially loaded. However, I have encountered this when I could find nothing had changed. In all cases, I rebuilt the index from members, and this resolved the problem.

Are you sure this error did not occur prior to the CONVERT PAGE utility being used? Also, I have never used this utility. If the index is sorted on DB-KEY, as you stated, the only way this utility could correct this index, is to rebuild the index behind the scenes, or zap each of the DB-KEYS in the SR7/SR8 structure.

If you cannot rebuild from members; because, duplicates are allowed, and order within the duplicates is important. This would mean you would need logical offload/load programs.

Best of Luck,
John Collins
SAIC

¦
-----------------------------------------------------------
¦ 53 ¦ ¦ The subschema definition of an indexed ¦
¦ ¦ ¦ set does not match the indexed set's ¦
¦ ¦ ¦ physical structure in the database. ¦
¦ ¦ ¦ ¦
¦ ¦ ¦ The most probable cause for the return ¦
¦ ¦ ¦ of this minor code is that the subschema ¦
¦ ¦ ¦ definition of an indexed set has been ¦
¦ ¦ ¦ changed to conflict with the indexed ¦
¦ ¦ ¦ set's physical structure in the ¦
¦ ¦ ¦ database. Specifically, any of the ¦
¦ ¦ ¦ following definitional changes result in ¦
¦ ¦ ¦ the return of this minor code: ¦
¦ ¦ ¦ ¦
¦ ¦ ¦
Changing the set order of an indexed ¦
¦ ¦ ¦ set from unsorted to sorted, or ¦
¦ ¦ ¦ changing the set order from sorted ¦
¦ ¦ ¦ to unsorted. ¦
¦ ¦ ¦ ¦
¦ ¦ ¦
Changing the indexed set's symbolic ¦
¦ ¦ ¦ key COMPRESSION option. ¦
¦ ¦ ¦ ¦
¦ ¦ ¦
Changing the sorted set order of an ¦
¦ ¦ ¦ indexed set from sorted by symbolic ¦
¦ ¦ ¦ key to sorted by db-key, or from ¦
¦ ¦ ¦ sorted by db-key to sorted by ¦
¦ ¦ ¦ symbolic key. ¦
¦ ¦ ¦ ¦
¦ ¦ ¦
Changing the sorted set order of an ¦
¦ ¦ ¦ indexed set from ascending to ¦
¦ ¦ ¦ descending sequence, or from ¦
¦ ¦ ¦ descending to ascending sequence. ¦
¦ ¦ ¦ ¦
¦ ¦ ¦ The minor code can be returned if a ¦
¦ ¦ ¦ record on the database has been found to ¦
¦ ¦ ¦ have a different length than defined ¦
¦ ¦ ¦ within the subschema. ¦
¦ ¦ ¦ ¦
¦ ¦ ¦ When processing an SQL-defined database, ¦
¦ ¦ ¦ the date-timestamp does not match the ¦
¦

Outcomes