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 *