# "ET" profile parameter - Doesn't work? **URL:** \ **Category:** Forum\ **Tags:** Adabas-Natural, Natural, Natural-News-and-General-Topics\ **Created:** [May 24, 2006, 1:29am UTC](https://techcommunity.softwareag.com/t/et-profile-parameter-doesnt-work/61031 "2006-05-24T01:29:08Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Paul\_Garner](https://avatars.discourse-cdn.com/v4/letter/p/7993a0/32.png) [@Paul\_Garner](https://techcommunity.softwareag.com/u/Paul_Garner)\ **Post date:** [May 24, 2006, 1:29am UTC](https://techcommunity.softwareag.com/t/et-profile-parameter-doesnt-work/61031/1 "2006-05-24T01:29:08Z")
I’d like to be able to: make an update in one database without issusing an ET, then switch to a second database using USR1040N, then make an update in the second database, then issue an ET against the second database only, then return to the first database using USR1040N again, then backout the update to the frist database if desired. The “ET” profile parameter supposedly provides this capability when set to “OFF”, but in my testing I find it has no effect. An end transaction issued against one database seems to always affects the other one regardless of the settting of the “ET” profile parameter. What could be wrong? I’m running Nat 4.1.3 and ADABAS 7.4.2 on a VSE mainframe platform; any info you can give me would be greatly appreciated. Paul G. ---
**Author:** ![Steve\_Robinson](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/steve_robinson/32/107_2.png) [@Steve\_Robinson](https://techcommunity.softwareag.com/u/Steve_Robinson)\ **Post date:** [May 24, 2006, 2:23am UTC](https://techcommunity.softwareag.com/t/et-profile-parameter-doesnt-work/61031/2 "2006-05-24T02:23:08Z")
You have misread the documentation: Possible settings ON END TRANSACTION and BACKOUT TRANSACTION statements are executed for all databases which have been referenced since the beginning of the Natural session or since the last execution of an END TRANSACTION and BACKOUT TRANSACTION statement. OFF END TRANSACTION and BACKOUT TRANSACTION statements are executed only for the databases affected by the transaction (and - if applicable - for the database to which transaction data are written). ET OFF does NOT mean that ETs are issued only for the current database. It means that “affected databases” have ETs issued. A database which has had a record updated (as in your example) is an “affected database”. This is more of a performance parameter than a functionality “thing”. If I read records from three databases, then update a record in one database. there is no need to issue four ET commands, one will suffice. steve ---
**Author:** ![Paul\_Garner](https://avatars.discourse-cdn.com/v4/letter/p/7993a0/32.png) [@Paul\_Garner](https://techcommunity.softwareag.com/u/Paul_Garner)\ **Post date:** [May 24, 2006, 2:47am UTC](https://techcommunity.softwareag.com/t/et-profile-parameter-doesnt-work/61031/3 "2006-05-24T02:47:07Z")
That’s bad news for us, but thanks. Is there another way of accomplishing the sort of selective commits that we’re looking for? Selective by file possibly? Paul G. ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [May 24, 2006, 11:05am UTC](https://techcommunity.softwareag.com/t/et-profile-parameter-doesnt-work/61031/4 "2006-05-24T11:05:53Z")
> [@Paul Garner](#): > > Is there another way of accomplishing the sort of selective commits that we’re looking for? Selective by file possibly Not in an official way, you would have to use USR1043N. ---
**Author:** ![Matthias1](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@Matthias1](https://techcommunity.softwareag.com/u/Matthias1)\ **Post date:** [May 24, 2006, 1:48pm UTC](https://techcommunity.softwareag.com/t/et-profile-parameter-doesnt-work/61031/5 "2006-05-24T13:48:47Z")
> [@Wolfgang Winter](#): > > Not in an official way, you would have to use USR1043N. Is that really possible? That would be interesting to know… You you please write down a draft of that method? ---
**Author:** ![Chad\_Scott](https://avatars.discourse-cdn.com/v4/letter/c/b3f665/32.png) [@Chad\_Scott](https://techcommunity.softwareag.com/u/Chad_Scott)\ **Post date:** [June 2, 2006, 11:02pm UTC](https://techcommunity.softwareag.com/t/et-profile-parameter-doesnt-work/61031/6 "2006-06-02T23:02:36Z")
I _think_ Wolfgang was eluding to the fact that many things can be done using direct calls that aren’t directly available from Natural, like doing the selective ET. If you take the example source for USR1043 from SYSEXT and modify it to have something like: ```auto /* Reset all binary fields and fill control block, ... /* RESET CB-DBID CB-FNR CB-RSP CB-ISN CB-ISL CB-ISQ CB-FBL CB-RBL CB-SBL CB-VBL CB-IBL CB-RESERVED /* CB-CMD := 'ET' /* ET Command CB-RSP := 999 /* This is where you specify the DBID /* CALLNAT 'USR1043N' CONTROL-BLOCK FORMAT-ADDR RECORD-ADDR SEARCH-ADDR VALUE-ADDR ISN-ADDR RESPONSE /* IF RESPONSE NE 0 WRITE 'ADABAS response code:' RESPONSE END-IF /* END ``` I didn’t try this so I can’t guarantee it, but the idea is there… hopefully it’s close. AFAIK file level ET can’t be done. ---
**Author:** ![Matthias1](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@Matthias1](https://techcommunity.softwareag.com/u/Matthias1)\ **Post date:** [June 8, 2006, 1:03pm UTC](https://techcommunity.softwareag.com/t/et-profile-parameter-doesnt-work/61031/7 "2006-06-08T13:03:15Z")
> [@Chad Scott](#): > > I didn’t try this so I can’t guarantee it, but the idea is there… hopefully it’s close. AFAIK file level ET can’t be done. Thanks for your code example. I think this should only be used in very special cases. But it is useful to know … ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [April 2, 2021, 2:40pm UTC](https://techcommunity.softwareag.com/t/et-profile-parameter-doesnt-work/61031/8 "2021-04-02T14:40:40Z")