AnsweredAssumed Answered

Subschema New Copy Immediate

Question asked by Gary_Cherlet on Feb 16, 2011
Latest reply on Feb 17, 2011 by Gary_Cherlet
CV51 is production, CV53 is for emergency production fixes, both IDMS 17.0 GJH01B. These two CVs share the production application dictionary (PRODDICT). Both CVs have a PRODDICT segment in page group 1, but they share the same underlying datasets for DDLDML and DDLDCLOD. PRODDICT in CV51 is in update mode, and PRODDICT in CV53 is in retrieval. Because of this shared setup, we used to have regular problems trying to new copy subschemas in CV53. We overcame those problems by issuing these commands in CV51 and CV53 after modifying and generating the subschemas in CV51:

DCMT V AREA PRODDICT.DDLDCLOD PURGE
DCMT V BUFF DSS_DDLDML_BUFF CLOSE
DCMT V BUFF DSS_DDLDCLOD_BUFF CLOSE
DCUF SET DICTNAME PRODDICT
DCMT V PRO FMSP2U00 NCI
DCMT V PRO FMSP2R00 NCI
LOOK PROGRAM=FMSP2U00
LOOK PROGRAM=FMSP2R00
DCUF SET DICTNAME ''
DCMT V PRO FMSP2U00 NCI
DCMT V PRO FMSP2R00 NCI
LOOK PROGRAM=FMSP2U00
LOOK PROGRAM=FMSP2R00
BYE

This process has worked very well for several years. However, there have been a couple of times when we've run into a strange occurrence. I made a change to the FMSP2SCH schema a week ago-a simple filler rename-followed by the above commands. No problem. Programmers/users were using the new subschema in CV53 without encountering any issues. CV51 and CV53 are both cycled weekly, and after the recycle yesterday (CV51 comes up before CV53), subschema FMSP2U00 in CV53 was unusable. So far, the strange occurrence has involved this particular subschema, but that might be just a coincidence?? Batch jobs would hang and eventually abend with a 0077, although the CV log shows an abend with code 1117 (1117=When trying to delete a record fragment of a variable-length record, the DBMS was unable to adjust the space on a database page. The possible causes are a broken fragment chain or corrupt page). DBAN of PRODDICT is clean. DBAN of the FMSP2S00 database is clean. Repeated the commands above, but the vary of FMSP2U00 would not work (although after several tries, DCMT D MEM PRO FMSP2U00 200 finally showed the correct date and time). The LOOK would just hang and had to be cancelled. The problem was fixed by bouncing CV53. If the subschema was somehow corrupted, I don't see how bouncing CV53 would fix that. Can anyone help me understand what's causing this problem and how to fix it? Any help would be greatly appreciated.

Christine A. Laughlin
CIT Specialist I
Office of Administration ITSD
Database Administration
(573) 751-2056
Christine.A.Laughlin@oa.mo.gov

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
From Board Monitor: I have added in this "clarification" from Christine after some IDMS-L replies seemed to miss the specifics of her problem.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[color=#210488]Either I'm missing something or I need to make myself a little clearer (could easily be either one!). After the schema was modified and subschemas (2) modified and regenerated, I issued the DDLDCLOD purge and closed both dictionary buffers, first in CV51 and then again in CV53. I know the subschemas were new copied successfully, because the programmer ran batch and onlines that used the newly added fields (this was in CV53). The problem with the update subschema didn't occur until AFTER the CVs were shut down a week later. The morning that the CVs cycled, another programmer tried to run a batch program with the same update subschema, only to eventually time out with a 0077 error code on the DML sequence for the first record bind (his program uses COPY IDMS SUBSCHEMA-BINDS). The CV53 log showed a 1117 abend, but the batch job produced the 0077 error. When several attempts to repeat the subschema modify, generate, and new copy, along with the DDLDCLOD purge and buffer closings, had failed, CV53 was bounced and that fixed the problem. I know that the process I use for bringing in a new copy of the subschema works, but can't figure out why the CV shutdown broke it and the CV53 recycle fixed it. I can easily see that some of the suggestions from the list could be quite valid under the circumstances, but if those possible conditions had caused the problem, how could the programmer have used the new version of the subschema the week before the CVs were shut down??

Unfortunately there wasn't any additional information with the 1117 abend. It was just the standard abend message similar to the sample below, except the ABRU was replaced with 1117:

V53 T2572 TASK:RHDCNP3S PROG:FMSCS810 ABENDED WITH CODE ABRU
V53 T1 CV-Status BE-TaskID Pri FE - ID1 FE - ID2 FE TaskCD FE USERID
V53 T1 ABRT CKUR 2572 100 BATCBULK FMSCS5MT FMSCS810 SCHLACC


Christine A. Laughlin[color]

Outcomes