ca.portal.admin

DMCL change causes CV abend?

Discussion created by ca.portal.admin on Mar 11, 2007
Latest reply on Mar 13, 2007 by ca.portal.admin
Hi All:

Apologies extended in advance if this gets posted twice...operator
finger fumble of the recipient :))

I have a client running 14.x with a need to expand some database areas.
The last DBA retired 4 or 5 years ago. They ran an XPAG that
subsequently caused the CV to crash.

The DBA left an 'xpag' procedure with the following steps:

1. Existing file has prefix 'P'.
BR14 alloc new file, prefix 'T'.
2. BCF Expand Page into new file
3. Alter Segment;
Alter Physical Area Page size;
Alter DMCL;
Alter Buffer bigger-buffer increase #pages;
Alter DMCL
include file
buffer bigger-buffer;
Generate DMCL;
Punch DMCL;
4. Link DMCL
5. IDMSLOOK.
6. IDCAMS rename prod DSN from 'P' to 'Z'
7. IDCAMS rename 'new' DSN from 'T' to 'P'

They have used this successfully in the past.

User ran the above on one area, recycled CV, all OK.
User ran the above on a second area, recycled CV and the system tanked:
normal startup messages, bypassing warmstart, etc.
attaching dbrc
log mgr init complete
line drivers up
opening system run units
task master program system number of bytes needed negative or
larger than storage pool

Backing off the 2nd xpag changes did not resolve the problem. Backing
off ALL xpag changes and renaming the saved 'prod' datasets back to 'P'
appears to have resolved the problem. CV is back up with no problems.

So, the 'culprit' ;-}} appears to have been the DMCL load module, as
NOTHING else changed.

Has anyone seen this type of error after an XPAG? I don't see anything
wrong (procedurally) with the steps taken. I'm truly stumped that the
1st XPAG and DMCL change worked but the 2nd caused the CV problems. Old
and new page sizes are multiples of 4.

One other note...had the user punch the ENTIRE DMCL...changed the 'alter
dmcl' syntax noted above to alter EVERY segment, buffer, area, file,
etc. in the DMCL, including the areas that were XPAG'd. We were able to
XPAG all areas successfully. XPAGing a file at at time and modifying
the DMCL one area/file at a time caused a CV abend?

Thanks extended in advance for any and all input,

Tom Schoenborn
TA Schoenborn & Associates LLC
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
DMCL change causes CV abend?
"Hi All:

Apologies extended in advance if this gets posted twice...operator finger fumble of the recipient :))

I have a client running 14.x with a need to expand some database areas. The last DBA retired 4 or 5 years ago. They ran an XPAG that subsequently caused the CV to crash.

The DBA left an 'xpag' procedure with the following steps:

1. Existing file has prefix 'P'.
BR14 alloc new file, prefix 'T'.
2. BCF Expand Page into new file
3. Alter Segment;
Alter Physical Area Page size;
Alter DMCL;
Alter Buffer bigger-buffer increase #pages;
Alter DMCL
include file
buffer bigger-buffer;
Generate DMCL;
Punch DMCL;
4. Link DMCL
5. IDMSLOOK.
6. IDCAMS rename prod DSN from 'P' to 'Z'
7. IDCAMS rename 'new' DSN from 'T' to 'P'

They have used this successfully in the past.

User ran the above on one area, recycled CV, all OK.
User ran the above on a second area, recycled CV and the system tanked:
normal startup messages, bypassing warmstart, etc.
attaching dbrc
log mgr init complete
line drivers up
opening system run units
task master program system number of bytes needed negative or larger than storage pool

Backing off the 2nd xpag changes did not resolve the problem. Backing off ALL xpag changes and renaming the saved 'prod' datasets back to 'P' appears to have resolved the problem. CV is back up with no problems.

So, the 'culprit' ;-}} appears to have been the DMCL load module, as NOTHING else changed.

Has anyone seen this type of error after an XPAG? I don't see anything wrong (procedurally) with the steps taken. I'm truly stumped that the 1st XPAG and DMCL change worked but the 2nd caused the CV problems. Old and new page sizes are multiples of 4.

One other note...had the user punch the ENTIRE DMCL...changed the 'alter dmcl' syntax noted above to alter EVERY segment, buffer, area, file, etc. in the DMCL, including the areas that were XPAG'd. We were able to XPAG all areas successfully. XPAGing a file at at time and modifying the DMCL one area/file at a time caused a CV abend?

Thanks extended in advance for any and all input,

Tom Schoenborn
TA Schoenborn & Associates LLC
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: CAS/DATA
"Jon,

I just spoke with Infor this afternoon. There is a version for 16.0.
Caveat is that to get the new release you have to have current maintenance
for the product. Hope you're current with that.

Hi Gene! This is like old home week for CAS/DATA.

Linda

Outcomes