ca.portal.admin

Re: Transaction ID overflowing

Discussion created by ca.portal.admin on Jun 6, 2008
Steve,

Segment numbers were in the 22000 + region ( our journals are fairly
big; 198,000 blocks, 10K blocksize).

Iain Robertson
BT Operate, Senior DBA

Email: iain.dk.robertson@bt.com

-----Original Message-----
From: IDMS Public Discussion Forum
[mailTo:IDMS-L@LISTSERV.IUASSN.COM] On Behalf Of Harmeson, Steve
(Newport News)
Sent: 05 June 2008 16:20
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: [IDMS-L] Transaction ID overflowing

Iain,

Do you recall what your segment number was in your journal reports
offloads?
JOURNAL DISK FILES STATUS REPORT



FILENAME SEGMENT LORBN HIRBN FULL ACTIVE STATUS CV
ACTIVE


J1JRNL NXT AV 19 12958 NO NO NON-AJNL
YES
16393 8 18



J2JRNL NXT AV 21 12958 NO NO NON-AJNL
YES
16394 8 20


Thanks,
Steve
-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Chris Wood
Sent: Thursday, June 05, 2008 10:44 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: Transaction ID overflowing

Iain,

Looks like a fix is being prepared for you but shouldn't the CV maybe
issue some sort of warning message before the transaction does gets to
2,147,000,000? I am sure this would warn people that a format is
needed.

Chris Wood
Alberta Department of Energy
CANADA

-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of iain.dk.robertson@BT.COM
Sent: June 4, 2008 3:09 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Transaction ID overflowing


Probably not an issue that will affect many sites, but it caught us
out.

A very active CV, whose journals haven't been formatted for about 2
1/2 years. Transaction ID eventually reached and exceeded
2,147,483,647 (x'7FFFFFFF').No indication at this point of any
problem; no warning messages issued.

About a week later, CV issued DC203006 - Unable to find BGIN/COMT
Ckpts for all active Transactions

Further examination showed no condensed segments on the disk journals,
and that the rununit the CV was trying to recover spanned two
journals.
The condense phase of archive journal seems to have got confused by
the decreasing transaction ID (this is our belief), and didn't create
any condensed segments on the journal being offloaded. Anything which
tries to rollback, and goes to an older journal than the current one
is going to have a real problem. Obviously, anything rolling back and
using only the currently active journal will be OK.

Side effect of this is that CV won't shutdown, as it's waiting for a
transaction to recover. Obviously warmstart will fail too.

We got lucky - the transaction that had the problem was updating an
area used for holding information about DMLO sessions. Had it been a
real database area, we'd have had problems.

CA are investigating the problem at the moment.

Iain Robertson
BT Operate, Senior DBA
Email: iain.dk.robertson@bt.com
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Transaction ID overflowing
"Yes, we have a fix, which seems to fix the problem.

We didn't see any warning that the ID had gone over the x'7FFFFFFF'
mark.

Iain Robertson
BT Operate, Senior DBA
Telephone: +44 (0)20 8456 7108
Email: iain.dk.robertson@bt.com

-----Original Message-----
From: IDMS Public Discussion Forum
[mailTo:IDMS-L@LISTSERV.IUASSN.COM] On Behalf Of Chris Wood
Sent: 05 June 2008 15:44
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: [IDMS-L] Transaction ID overflowing

Iain,

Looks like a fix is being prepared for you but shouldn't the
CV maybe issue some sort of warning message before the
transaction does gets to 2,147,000,000? I am sure this would
warn people that a format is needed.

Chris Wood
Alberta Department of Energy
CANADA

-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of iain.dk.robertson@BT.COM
Sent: June 4, 2008 3:09 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Transaction ID overflowing


Probably not an issue that will affect many sites, but it
caught us out.

A very active CV, whose journals haven't been formatted for
about 2 1/2 years. Transaction ID eventually reached and
exceeded 2,147,483,647 (x'7FFFFFFF').No indication at this
point of any problem; no warning messages issued.

About a week later, CV issued DC203006 - Unable to find
BGIN/COMT Ckpts for all active Transactions

Further examination showed no condensed segments on the disk
journals, and that the rununit the CV was trying to recover
spanned two journals.
The condense phase of archive journal seems to have got
confused by the decreasing transaction ID (this is our
belief), and didn't create any condensed segments on the
journal being offloaded. Anything which tries to rollback,
and goes to an older journal than the current one is going to
have a real problem. Obviously, anything rolling back and
using only the currently active journal will be OK.

Side effect of this is that CV won't shutdown, as it's
waiting for a transaction to recover. Obviously warmstart
will fail too.

We got lucky - the transaction that had the problem was
updating an area used for holding information about DMLO
sessions. Had it been a real database area, we'd have had problems.

CA are investigating the problem at the moment.

Iain Robertson
BT Operate, Senior DBA
Email: iain.dk.robertson@bt.com
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Transaction ID overflowing
"Steve,

Segment numbers were in the 22000 + region ( our journals are fairly
big; 198,000 blocks, 10K blocksize).

Iain Robertson
BT Operate, Senior DBA

Email: iain.dk.robertson@bt.com

-----Original Message-----
From: IDMS Public Discussion Forum
[mailTo:IDMS-L@LISTSERV.IUASSN.COM] On Behalf Of Harmeson,
Steve (Newport News)
Sent: 05 June 2008 16:20
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: [IDMS-L] Transaction ID overflowing

Iain,

Do you recall what your segment number was in your journal
reports offloads?
JOURNAL DISK FILES STATUS REPORT



FILENAME SEGMENT LORBN HIRBN FULL ACTIVE STATUS CV
ACTIVE


J1JRNL NXT AV 19 12958 NO NO NON-AJNL
YES
16393 8 18



J2JRNL NXT AV 21 12958 NO NO NON-AJNL
YES
16394 8 20


Thanks,
Steve
-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Chris Wood
Sent: Thursday, June 05, 2008 10:44 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: Transaction ID overflowing

Iain,

Looks like a fix is being prepared for you but shouldn't the
CV maybe issue some sort of warning message before the
transaction does gets to 2,147,000,000? I am sure this would
warn people that a format is needed.

Chris Wood
Alberta Department of Energy
CANADA

-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of iain.dk.robertson@BT.COM
Sent: June 4, 2008 3:09 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Transaction ID overflowing


Probably not an issue that will affect many sites, but it
caught us out.

A very active CV, whose journals haven't been formatted for
about 2 1/2 years. Transaction ID eventually reached and
exceeded 2,147,483,647 (x'7FFFFFFF').No indication at this
point of any problem; no warning messages issued.

About a week later, CV issued DC203006 - Unable to find
BGIN/COMT Ckpts for all active Transactions

Further examination showed no condensed segments on the disk
journals, and that the rununit the CV was trying to recover
spanned two journals.
The condense phase of archive journal seems to have got
confused by the decreasing transaction ID (this is our
belief), and didn't create any condensed segments on the
journal being offloaded. Anything which tries to rollback,
and goes to an older journal than the current one is going to
have a real problem. Obviously, anything rolling back and
using only the currently active journal will be OK.

Side effect of this is that CV won't shutdown, as it's
waiting for a transaction to recover. Obviously warmstart
will fail too.

We got lucky - the transaction that had the problem was
updating an area used for holding information about DMLO
sessions. Had it been a real database area, we'd have had problems.

CA are investigating the problem at the moment.

Iain Robertson
BT Operate, Senior DBA
Email: iain.dk.robertson@bt.com
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: [IDMSVENDOR-L] Transaction ID overflowing
"you dont even need to take down time to format journals - format a clone
DSN(s) and you need be down only long enough for renames



Chris Hoelscher
Senior IDMS & DB2 Database Administrator
Humana Inc
502-476-2538
choelscher@humana.com



The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
New Apars
"Hi,



Seems that CA are now up to RO for apars after using up QO.



Chris Wood

Alberta Department of Energy

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








Normal

Normal
ACCEPT DML VERB in COBOL not working
"Hello All:



I am trying to get the system version by issuing an accept sysversion and it
is NOT working.



Here is the code: ACCEPT SYSVERSION INTO WS-TEST1.



Here is the Working Storage area: 01 WS-TEST1 PIC
S9(4) COMP.



The accept DML verb is issued immediately after the bind run unit, bind
records and ready of the areas.



What we get is 0000, the system version number that we should get is 33.



Here is the enter next task code prompt: V33 ENTER NEXT TASK CODE:
CA-IDMS release 16.0 node SYST0033



We are running 16.0 SP2 on a Z/OS 1.7 Operating System.



Any help would be appreciated.



William M. Allen, Jr.

ARCH Consulting Associates, Ltd.

(704) 641-0296
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Orphans in unlinked indexes?
"We have heard many times that we don't need to be concerned about orphans for unlinked indexes (INDEX DBKEY POSITION IS OMITTED). But when I do index prints for busy unlinked indexes, I see orphans galore at the L1 level. Are these real orphans? Should we be concerned?

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: ACCEPT DML VERB in COBOL not working
"These are DC only commands, I believe....


----- Original message -----
From: ""William M. Allen, Jr."" <archcons@BELLSOUTH.NET>
To: IDMS-L@LISTSERV.IUASSN.COM
Date: Fri, 6 Jun 2008 17:39:40 -0400
Subject: Re: ACCEPT DML VERB in COBOL not working

Hello Terry:

They are trying to do this from a batch COBOL program.

Sorry, I missed providing that information; here is the IDMS-CONTROL:

002500 IDMS-CONTROL SECTION.
002600 PROTOCOL. MODE IS BATCH DEBUG
002700 IDMS-RECORDS MANUAL.

William M. Allen, Jr.
ARCH Consulting Associates, Ltd.
(704) 641-0296

Outcomes