All:
Just a little FYI --
To those of you who may think of trying to use the DBX procedures across
multiple data bases I will give one word of caution.
A couple of years ago I tried this and caused a system failure when
the DBXBEGIN began across multiple base ID's.
Seems that there was a slight little buggy in TurboIMAGE that HP fixed
with patch (TIXMX31B).
(Pasted from my HPSWINFO file) --
AUTOPAT - Patches below installed by PCH12466-01 MON, FEB 25, 2002 3:04
Patch ID SR Number - Module Identity Timestamp
======== =========== ============================= =========
TIXMX31B 8606-226030 - XL SOM HP30391_03 MON, FEB 25, 2002 3:05 PM
SA1458 from nmdbclose+$29c, DBUX contains stale entries
TIXMX31B 8606-226030 - XL SOM HP30391_04 MON, FEB 25, 2002 3:05 PM
TIXMX31B 8606-226030 - XL SOM HP30391_01 MON, FEB 25, 2002 3:06 PM
TIXMX31B 8606-226030 - SL seg TIMAGE MON, FEB 25, 2002 3:06 PM
TIXMX31B 8606-226030 - SL seg CORONA2 MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - IMAGEDMP.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - SYTI0308.TI.TELESUP MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBDRIVER.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBUTILB.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBCONV.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - I7DB8CNV.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBDUMP.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBDRIVCM.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBRECOV.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBRCVCM.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBUTIL.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBLOAD.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBUNLOAD.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBRESTOR.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBSTORE.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBSCHEMA.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - UTIINIT1.TI.TELESUP MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - MXTI0308.TI.TELESUP MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - UTIINIT.TI.TELESUP MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - TICAT000.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - IMAGECAT.PUB.SYS MON, FEB 25, 2002 3:07 PM
TIXMX31B 8606-226030 - DBBIGSET.PUB.SYS MON, FEB 25, 2002 3:07 PM
-----------------------------------
I was running under MPEiX 6.5 PP2 and the version of TurboIMAGE was
HP30391C.09.08 TurboIMAGE/XL
Just an FYI for one and all...
Brian.
On Mon, 16 Aug 2004 15:59:39 -0400, Brian Donaldson <[log in to unmask]>
wrote:
>There are no such procedures in the TurboIMAGE manual as DBXON and DBXOFF.
>
>However, I think you are referring to the DBXBEGIN/DBXEND/DBXUNDO
>procedures?
>
>If so, YES, there is a limit to the size of data held in limbo before the
>data is posted back to the data base. These procedures were not designed
for
>holding millions of entries before writing the data back to the base,
>but for the processing of much smaller amounts of logical transactions.
>
>Scenario, for example, might be: DBXBEGIN, DBLOCK (of course), three data
>sets get updated by a single incoming transaction which would do a DBPUT to
>setA, DBDELETE from setB, and a DBUPDATE from setC. The DBPUT is
>successful, as is the DBDELETE but the DBUPDATE failed (for any reason).
>You now have an incomplete, inconsistent transaction. Your program would
>call DBXUNDO and then DBUNLOCK. The idea is that everything in the logical
>transaction gets updated or nothing gets updated.
>
>
>I am not certain on what these limits are but you won't be able to process
>millions of entries inside a DBXBEGIN/DBXEND structure. Once the internal
>file gets full up an automatic DBXUNDO will take place and your Image
>procedure will return an error code (can't remember which error code).
>
>An alternative solution is to do DBOPEN mode 3 (exclusive access),
>DBCONTROL mode 1 (output deferred) before processing your mega amounts of
>data. However, AUTODEFER has to be enabled via DBUTIL first. Don't forget
>to backup your data base first as the DB will be toast if the program
>aborts for ANY reason. The program abort will leave your data base in an
>inconsistent state and a restore will be your only form of recovery.
>
>
>HTH,
>Brian Donaldson.
>
>On Mon, 16 Aug 2004 09:42:34 -0500, Baker, Mike L. <[log in to unmask]>
>wrote:
>
>>Forgive me for asking something that is probably listed in the manual. Is
>there a limit to the amount of transactions you can "hold" when using the
>DBXON - DBXOFF commands in Image? We have a detail data set with capacity
>of 16 million, would DBXON DBXOFF blow with that size if you did not do the
>commit and wanted to back out after all that?
>>
>>Mike Baker
>>
>>* To join/leave the list, search archives, change list settings, *
>>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
