Question: onbar and onstat -g ntu or onstat -g ntt

Hello, Are we suppose to see any of these "ontape" processes when we are not running any ontape or onbar backup? We start having some onbar failures (abort by client on some dbspaces...), and we haven't found the cause of the problem. Thanks onstat -g ntu | grep ontapec00000010d8536b8 soctcp ontape 39681 -2 6 1 0 0/ 1 0/ 0 0/ 0 c0000001549bebe0 soctcp ontape 39680 -2 5 6 5 0/ 1 0/ 1 0/ 0 c00000010f301400 soctcp ontape 39673 -2 7 15 14 0/ 1 0/ 1 0/ 0 c000000101ea9bd0 soctcp ontape 39672 -2 6 8 7 0/ 1 0/ 1 0/ 0 ... cut ... onstat -g ntt | grep ontapec00000010d8536b8 ontape 39681 03:27:14 c0000001549bebe0 ontape 39680 03:27:14 03:27:14 03:27:14 c00000010f301400 ontape 39673 03:27:08 03:27:12 03:27:12 c000000101ea9bd0 ontape 39672 03:27:08 03:27:11 03:27:11 c00000015b277a18 ontape 39670 03:26:53 03:27:07 03:27:07 ... cut ...

Hi, when there really is no onbar process running, then you should not see any of these threads. But for log backup you would also see an ontape thread. I.e. when a log backup is started (e.g. via the ALARMPROGRAM) then this will be starting an ontape thread in the server as well. Usually there will be only one log backup thread, as log backup is strictly serial. However, if logs fill quickly, it can happen that several "onbar-b -l" are started, each starting an ontape thread in the server - however, only one will prevail, the others will run only briefly as the server will reject multiple (concurrent) log backup activities. To get more information about the onbar backups look in the ON-Bar activity log file (BAR_ACT_LOG). It may give you more detail about when and why something apparently was aborted by the client. No such logging is done for any activities performed with the "ontape" utility. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management ids-bounces@iiug.org wrote on 16.02.2006 21:14:44: > > Hello, > Are we suppose to see any of these "ontape" processes when we are not running > any ontape or onbar backup? > We start having some onbar failures (abort by client on some dbspaces...), and > we haven't found the cause of the problem. > Thanks > > onstat -g ntu | grep ontape> c00000010d8536b8 soctcp ontape 39681 -2 6 1 0 0/ 1 0/ 0 0/ 0 > c0000001549bebe0 soctcp ontape 39680 -2 5 6 5 0/ 1 0/ 1 0/ 0 > c00000010f301400 soctcp ontape 39673 -2 7 15 14 0/ 1 0/ 1 0/ 0 > c000000101ea9bd0 soctcp ontape 39672 -2 6 8 7 0/ 1 0/ 1 0/ 0 > .... cut ... > > onstat -g ntt | grep ontape> c00000010d8536b8 ontape 39681 03:27:14 > c0000001549bebe0 ontape 39680 03:27:14 03:27:14 03:27:14 > c00000010f301400 ontape 39673 03:27:08 03:27:12 03:27:12 > c000000101ea9bd0 ontape 39672 03:27:08 03:27:11 03:27:11 > c00000015b277a18 ontape 39670 03:26:53 03:27:07 03:27:07 > .... cut ... > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >