ca.portal.admin

Release 17.1 Implementation Issue

Discussion created by ca.portal.admin on Jan 12, 2010
Latest reply on Jan 12, 2010 by ca.portal.admin
Just in case any of you run into this problem I thought I would toss this o=
ne out........

So we were rolling IDMS version 17 SP1 into one of our version 16 SP7 test =
systems last Sunday and
run into an interesting problem. We followed the standard install procedure=
and formated the journals
before bringing up the CV like we have for years. However we got a 3964 ab=
end on startup.
The odd part is there are no messages to indicate a problem, just an abend=
.

18.32.34 JOB06894 ASGVDB 018I Live area VDB8.ACCOUNT-AREA was =
not
18.32.41 JOB06894 IEA794I SVC DUMP HAS CAPTURED: 788
788 DUMPID=3D002 REQUESTED BY JOB (CV05STRT)
788 DUMP TITLE=3DIDMSSYS# 0005 ABEND: USER(3964)
18.32.49 JOB06894 IEA995I SYMPTOM DUMP OUTPUT 789
789 USER COMPLETION CODE=3D3964

After several interations of failed startups we tried a startup without re-=
formatting the
version 17 journals and get ....

+IDMS DC205023 V5 JHDA/JHD2 Counts are not the same in all journals
+IDMS DC202026 V5  JOURNALS not from same run of IDMS - Check JCL
+IDMS DC391008 V5 WARMSTART Failure - IOSTATUS=3D3025
IEA995I SYMPTOM DUMP OUTPUT 789
USER COMPLETION CODE=3D3962
TIME=3D19.19.05 SEQ=3D00165 CPU=3D0000 ASID=3D002F

Although the number of areas in this CV did not change we do have multiple =
VDB shadow
segments and a total of about 2500 areas. So on a hunch we added the MAX AR=
EA
parameter to the 4 format journal command

FORMAT JOURNAL J1JRNL MAX AREA 32767;

And presto our CV comes up like a champ.

Today we found RO12605 (has prereq of RO11419) which is not on the SP1 tape=
.
In a nut shell it says;

A 3024 or 3964 abend during CV startup may occur after the
journals have been formatted without the MAX AREA clause or after
specifying the MAX AREA clause with a number that is too low.
When there are more areas to be opened during startup than all
the JHDA blocks can hold, a 3024 or 3964 error can occur.
APAR QO76466 addressed this problem for IDMS R16.0 by
writing additional JHDA blocks to the current disk journal
and copying them to the other disk journals that are defined in
the DMCL. By doing so, startup could proceed and the headers
of all disk journals were back in sync.
APAR QO76466 was correctly sourced in IDMS R17.0, but due to
the source implementation of other R17.0 features, the effect
of APAR QO76466 was lost.

CIRCUMVENTION:
Specify the 'MAX AREA nnn' clause during FORMAT JOURNAL
processing where nnn is the maximum number of areas to be opened
at startup.
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
"Another reason to use ""max area"""
"Another reason to use ""max area"" when formatting journals is to allow for growth. Otherwise you can get into trouble when adding a large number of new areas. This is true even if you do have the fix below applied.

Outcomes