Is there any way to research the sequence of lock/unlock request for a particular structure? I do not think this is captured in the audit, looking at the audit record types in "Record Type Mnemonics" in the "Enterprise Database Server Utilities
Operations Guide".
By the way, is a more detailed explanation of those record types available anywhere else?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

-------- Original Message --------
Subject: How to research DMSII lock/unlock requests
From: Luke Numrych <[email protected]>
To:
Date: Thu Jun 24 2021 09:31:26 GMT-0700 (Pacific Daylight Time)

Is there any way to research the sequence of lock/unlock request for a particular structure? I do not think this is captured in the audit, looking at the audit record types in "Record Type Mnemonics" in the "Enterprise Database Server Utilities

Operations Guide".

By the way, is a more detailed explanation of those record types available anywhere else?

Record lock and unlock requests are not audited. The purpose of audit
files is to restore the data base to a consistent state after a
transaction abort, a DMSII or system restart, or reloading one or more structures from backups. Locking does not participate in any of that.

By "Record Type Mnemonics" I assume you are referring to the table in
the section of that manual on PRINTAUDIT, "Selecting Records by Record
Type". I don't know of a better reference. Most of the record types have
to do with internal DMSII structure manipulations that would not
normally be of interest at the application program level. The record
types you would normally be most interested in (especially for Standard
Data Sets) are:

BIO
BTR
CCD
DSC
DSD
DSM (note this has both before and after images)
ETR
LGRR
STRDC

You might want to take a look at the sections in the same manual on
"Database Events Management" and "Logging Data Access". I've never used
these, but it appears to you can monitor most DM verbs, including LOCK
and FREE. I don't see ENDTRANSACTION or ABORTTRANSACTION listed, though,
noting that if your data base has INDEPENDENTTRANS set, all locked
records are implicitly freed when a transaction terminates. Transaction boundaries (BTR, ETR) are written to the audit trail, however, so you
may be able to merge those entries with the event log entries.

You didn't mention your purpose in researching lock/unlock requests. We
might be able to give you better answers if you could describe what the
problem is or what you're really trying to do.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, June 27, 2021 at 4:57:29 PM UTC-5, Paul Kimpel wrote:

-------- Original Message --------
Subject: How to research DMSII lock/unlock requests
From: Luke Numrych <[email protected]>
To:
Date: Thu Jun 24 2021 09:31:26 GMT-0700 (Pacific Daylight Time)

Is there any way to research the sequence of lock/unlock request for a particular structure? I do not think this is captured in the audit, looking at the audit record types in "Record Type Mnemonics" in the "Enterprise Database Server Utilities

Operations Guide".

By the way, is a more detailed explanation of those record types available anywhere else?

Record lock and unlock requests are not audited. The purpose of audit
files is to restore the data base to a consistent state after a
transaction abort, a DMSII or system restart, or reloading one or more structures from backups. Locking does not participate in any of that.

By "Record Type Mnemonics" I assume you are referring to the table in
the section of that manual on PRINTAUDIT, "Selecting Records by Record Type". I don't know of a better reference. Most of the record types have
to do with internal DMSII structure manipulations that would not
normally be of interest at the application program level. The record
types you would normally be most interested in (especially for Standard
Data Sets) are:

BIO
BTR
CCD
DSC
DSD
DSM (note this has both before and after images)
ETR
LGRR
STRDC

You might want to take a look at the sections in the same manual on "Database Events Management" and "Logging Data Access". I've never used these, but it appears to you can monitor most DM verbs, including LOCK
and FREE. I don't see ENDTRANSACTION or ABORTTRANSACTION listed, though, noting that if your data base has INDEPENDENTTRANS set, all locked
records are implicitly freed when a transaction terminates. Transaction boundaries (BTR, ETR) are written to the audit trail, however, so you
may be able to merge those entries with the event log entries.

You didn't mention your purpose in researching lock/unlock requests. We might be able to give you better answers if you could describe what the problem is or what you're really trying to do.

Paul

Hi Paul - thanks for your reply.
I did not think lock/unlock request were part of the audit - as you pointed out, they would be meaningless for recovery, and that is what AUDITs are for. As I am new to DMSII; however, I felt the need to verify.
By the way - most database management systems call such mechanisms "transaction logs". Is there a story behind why DMSII calls them AUDITs? Just curious - I find that knowing the reasons "why" helps me become familiar with a system.

Thank you for pointing me at the other sections in the manual, I will definitely go through them.

As far as the reason why I was looking for lock/unlock requests: we had a database access failure that manifested itself as program receiving a NOTLOCKED 1 exception. It happened to existing code that has been running for ages (and properly locking/
unlocking structures); therefore, the database had to be at fault ;). We just installed a new DMSII release on the system, so that could potentially have been the problem... I was asked by the development team to investigate. Since I could not figure
a way to track lock/unlock requests, I decided to use the proven RTFM method. Through application of it, I developed a theory that the most likely cause was not that DMSII was suddenly losing locks put on structures by programs, and that the NOTLOCKED
exception was in fact a secondary failure, the primary failure being a DEADLOCK. Which then caused DMSII to free all locks owned by the victim process. Because the victim process was ignoring the DEADLOCK exception (well, "eating" is more like it - it
did not display the exception or give any other hint that it was happening), it didn't bother re-locking structures before attempting to retry the original transaction - which was causing the NOTLOCKED 1 exception.

My theory was proven true once code was added to the application to notify of the DEADLOCK exception and the development team has now updated the application to handle the DEADLOCK exception properly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

LS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAgLS0tLS0tLS0NClN1YmplY3Q6IFJlOiBIb3cg dG8gcmVzZWFyY2ggRE1TSUkgbG9jay91bmxvY2sgcmVxdWVzdHMNCkZyb206IEx1a2UgTnVt cnljaCA8bC5udW1yeWNoQGdtYWlsLmNvbT4NClRvOg0KRGF0ZTogV2VkIEp1biAzMCAyMDIx IDIyOjE2OjMzIEdNVC0wNzAwIChQYWNpZmljIERheWxpZ2h0IFRpbWUpDQoNCj4gT24gU3Vu ZGF5LCBKdW5lIDI3LCAyMDIxIGF0IDQ6NTc6MjkgUE0gVVRDLTUsIFBhdWwgS2ltcGVsIHdy b3RlOg0KPj4gLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KPj4gU3ViamVj dDogSG93IHRvIHJlc2VhcmNoIERNU0lJIGxvY2svdW5sb2NrIHJlcXVlc3RzDQo+PiBGcm9t OiBMdWtlIE51bXJ5Y2ggPGwubnUuLi5AZ21haWwuY29tPg0KPj4gVG86DQo+PiBEYXRlOiBU aHUgSnVuIDI0IDIwMjEgMDk6MzE6MjYgR01ULTA3MDAgKFBhY2lmaWMgRGF5bGlnaHQgVGlt ZSkNCj4+DQo+Pj4gSXMgdGhlcmUgYW55IHdheSB0byByZXNlYXJjaCB0aGUgc2VxdWVuY2Ug b2YgbG9jay91bmxvY2sgcmVxdWVzdCBmb3IgYSBwYXJ0aWN1bGFyIHN0cnVjdHVyZT8gSSBk byBub3QgdGhpbmsgdGhpcyBpcyBjYXB0dXJlZCBpbiB0aGUgYXVkaXQsIGxvb2tpbmcgYXQg dGhlIGF1ZGl0IHJlY29yZCB0eXBlcyBpbiAiUmVjb3JkIFR5cGUgTW5lbW9uaWNzIiBpbiB0 aGUgIkVudGVycHJpc2UgRGF0YWJhc2UgU2VydmVyIFV0aWxpdGllcyBPcGVyYXRpb25zIEd1 aWRlIi4NCj4+PiBCeSB0aGUgd2F5LCBpcyBhIG1vcmUgZGV0YWlsZWQgZXhwbGFuYXRpb24g b2YgdGhvc2UgcmVjb3JkIHR5cGVzIGF2YWlsYWJsZSBhbnl3aGVyZSBlbHNlPw0KPj4+DQo+ PiBSZWNvcmQgbG9jayBhbmQgdW5sb2NrIHJlcXVlc3RzIGFyZSBub3QgYXVkaXRlZC4gVGhl IHB1cnBvc2Ugb2YgYXVkaXQNCj4+IGZpbGVzIGlzIHRvIHJlc3RvcmUgdGhlIGRhdGEgYmFz ZSB0byBhIGNvbnNpc3RlbnQgc3RhdGUgYWZ0ZXIgYQ0KPj4gdHJhbnNhY3Rpb24gYWJvcnQs IGEgRE1TSUkgb3Igc3lzdGVtIHJlc3RhcnQsIG9yIHJlbG9hZGluZyBvbmUgb3IgbW9yZQ0K Pj4gc3RydWN0dXJlcyBmcm9tIGJhY2t1cHMuIExvY2tpbmcgZG9lcyBub3QgcGFydGljaXBh dGUgaW4gYW55IG9mIHRoYXQuDQo+Pg0KPj4gQnkgIlJlY29yZCBUeXBlIE1uZW1vbmljcyIg SSBhc3N1bWUgeW91IGFyZSByZWZlcnJpbmcgdG8gdGhlIHRhYmxlIGluDQo+PiB0aGUgc2Vj dGlvbiBvZiB0aGF0IG1hbnVhbCBvbiBQUklOVEFVRElULCAiU2VsZWN0aW5nIFJlY29yZHMg YnkgUmVjb3JkDQo+PiBUeXBlIi4gSSBkb24ndCBrbm93IG9mIGEgYmV0dGVyIHJlZmVyZW5j ZS4gTW9zdCBvZiB0aGUgcmVjb3JkIHR5cGVzIGhhdmUNCj4+IHRvIGRvIHdpdGggaW50ZXJu YWwgRE1TSUkgc3RydWN0dXJlIG1hbmlwdWxhdGlvbnMgdGhhdCB3b3VsZCBub3QNCj4+IG5v cm1hbGx5IGJlIG9mIGludGVyZXN0IGF0IHRoZSBhcHBsaWNhdGlvbiBwcm9ncmFtIGxldmVs LiBUaGUgcmVjb3JkDQo+PiB0eXBlcyB5b3Ugd291bGQgbm9ybWFsbHkgYmUgbW9zdCBpbnRl cmVzdGVkIGluIChlc3BlY2lhbGx5IGZvciBTdGFuZGFyZA0KPj4gRGF0YSBTZXRzKSBhcmU6 DQo+Pg0KPj4gQklPDQo+PiBCVFINCj4+IENDRA0KPj4gRFNDDQo+PiBEU0QNCj4+IERTTSAo bm90ZSB0aGlzIGhhcyBib3RoIGJlZm9yZSBhbmQgYWZ0ZXIgaW1hZ2VzKQ0KPj4gRVRSDQo+ PiBMR1JSDQo+PiBTVFJEQw0KPj4NCj4+IFlvdSBtaWdodCB3YW50IHRvIHRha2UgYSBsb29r IGF0IHRoZSBzZWN0aW9ucyBpbiB0aGUgc2FtZSBtYW51YWwgb24NCj4+ICJEYXRhYmFzZSBF dmVudHMgTWFuYWdlbWVudCIgYW5kICJMb2dnaW5nIERhdGEgQWNjZXNzIi4gSSd2ZSBuZXZl ciB1c2VkDQo+PiB0aGVzZSwgYnV0IGl0IGFwcGVhcnMgdG8geW91IGNhbiBtb25pdG9yIG1v c3QgRE0gdmVyYnMsIGluY2x1ZGluZyBMT0NLDQo+PiBhbmQgRlJFRS4gSSBkb24ndCBzZWUg RU5EVFJBTlNBQ1RJT04gb3IgQUJPUlRUUkFOU0FDVElPTiBsaXN0ZWQsIHRob3VnaCwNCj4+ IG5vdGluZyB0aGF0IGlmIHlvdXIgZGF0YSBiYXNlIGhhcyBJTkRFUEVOREVOVFRSQU5TIHNl dCwgYWxsIGxvY2tlZA0KPj4gcmVjb3JkcyBhcmUgaW1wbGljaXRseSBmcmVlZCB3aGVuIGEg dHJhbnNhY3Rpb24gdGVybWluYXRlcy4gVHJhbnNhY3Rpb24NCj4+IGJvdW5kYXJpZXMgKEJU UiwgRVRSKSBhcmUgd3JpdHRlbiB0byB0aGUgYXVkaXQgdHJhaWwsIGhvd2V2ZXIsIHNvIHlv dQ0KPj4gbWF5IGJlIGFibGUgdG8gbWVyZ2UgdGhvc2UgZW50cmllcyB3aXRoIHRoZSBldmVu dCBsb2cgZW50cmllcy4NCj4+DQo+PiBZb3UgZGlkbid0IG1lbnRpb24geW91ciBwdXJwb3Nl IGluIHJlc2VhcmNoaW5nIGxvY2svdW5sb2NrIHJlcXVlc3RzLiBXZQ0KPj4gbWlnaHQgYmUg YWJsZSB0byBnaXZlIHlvdSBiZXR0ZXIgYW5zd2VycyBpZiB5b3UgY291bGQgZGVzY3JpYmUg d2hhdCB0aGUNCj4+IHByb2JsZW0gaXMgb3Igd2hhdCB5b3UncmUgcmVhbGx5IHRyeWluZyB0 byBkby4NCj4+DQo+PiBQYXVsDQoNCj4gSGkgUGF1bCAtIHRoYW5rcyBmb3IgeW91ciByZXBs eS4NCj4gSSBkaWQgbm90IHRoaW5rIGxvY2svdW5sb2NrIHJlcXVlc3Qgd2VyZSBwYXJ0IG9m IHRoZSBhdWRpdCAtIGFzIHlvdSBwb2ludGVkIG91dCwgdGhleSB3b3VsZCBiZSBtZWFuaW5n bGVzcyBmb3IgcmVjb3ZlcnksIGFuZCB0aGF0IGlzIHdoYXQgQVVESVRzIGFyZSBmb3IuICBB cyBJIGFtIG5ldyB0byBETVNJSTsgaG93ZXZlciwgIEkgZmVsdCB0aGUgbmVlZCB0byB2ZXJp ZnkuDQo+IEJ5IHRoZSB3YXkgLSBtb3N0IGRhdGFiYXNlIG1hbmFnZW1lbnQgc3lzdGVtcyBj YWxsIHN1Y2ggbWVjaGFuaXNtcyAidHJhbnNhY3Rpb24gbG9ncyIuICBJcyB0aGVyZSBhIHN0 b3J5IGJlaGluZCB3aHkgRE1TSUkgY2FsbHMgdGhlbSBBVURJVHM/ICAgSnVzdCBjdXJpb3Vz IC0gSSBmaW5kIHRoYXQga25vd2luZyB0aGUgcmVhc29ucyAid2h5IiBoZWxwcyBtZSBiZWNv bWUgZmFtaWxpYXIgd2l0aCBhIHN5c3RlbS4NCj4gDQo+IFRoYW5rIHlvdSBmb3IgcG9pbnRp bmcgbWUgYXQgdGhlIG90aGVyIHNlY3Rpb25zIGluIHRoZSBtYW51YWwsIEkgd2lsbCBkZWZp bml0ZWx5IGdvIHRocm91Z2ggdGhlbS4NCj4gDQo+IEFzIGZhciBhcyB0aGUgcmVhc29uIHdo eSBJIHdhcyBsb29raW5nIGZvciBsb2NrL3VubG9jayByZXF1ZXN0czogIHdlIGhhZCBhIGRh dGFiYXNlIGFjY2VzcyBmYWlsdXJlIHRoYXQgbWFuaWZlc3RlZCBpdHNlbGYgYXMgcHJvZ3Jh bSByZWNlaXZpbmcgYSBOT1RMT0NLRUQgMSBleGNlcHRpb24uICBJdCBoYXBwZW5lZCB0byBl eGlzdGluZyBjb2RlIHRoYXQgaGFzIGJlZW4gcnVubmluZyBmb3IgYWdlcyAoYW5kIHByb3Bl cmx5IGxvY2tpbmcvdW5sb2NraW5nIHN0cnVjdHVyZXMpOyB0aGVyZWZvcmUsIHRoZSBkYXRh YmFzZSBoYWQgdG8gYmUgYXQgZmF1bHQgOykuICBXZSBqdXN0IGluc3RhbGxlZCBhIG5ldyBE TVNJSSByZWxlYXNlIG9uIHRoZSBzeXN0ZW0sIHNvIHRoYXQgY291bGQgcG90ZW50aWFsbHkg aGF2ZSBiZWVuIHRoZSBwcm9ibGVtLi4uICBJIHdhcyBhc2tlZCBieSB0aGUgZGV2ZWxvcG1l bnQgdGVhbSB0byBpbnZlc3RpZ2F0ZS4gIFNpbmNlIEkgY291bGQgbm90IGZpZ3VyZSBhIHdh eSB0byB0cmFjayBsb2NrL3VubG9jayByZXF1ZXN0cywgSSBkZWNpZGVkIHRvIHVzZSB0aGUg cHJvdmVuIFJURk0gbWV0aG9kLiAgVGhyb3VnaCBhcHBsaWNhdGlvbiBvZiBpdCwgSSBkZXZl bG9wZWQgYSB0aGVvcnkgdGhhdCB0aGUgbW9zdCBsaWtlbHkgY2F1c2Ugd2FzIG5vdCB0aGF0 IERNU0lJIHdhcyBzdWRkZW5seSBsb3NpbmcgbG9ja3MgcHV0IG9uIHN0cnVjdHVyZXMgYnkg cHJvZ3JhbXMsIGFuZCB0aGF0IHRoZSBOT1RMT0NLRUQgZXhjZXB0aW9uIHdhcyBpbiBmYWN0 IGEgc2Vjb25kYXJ5IGZhaWx1cmUsIHRoZSBwcmltYXJ5IGZhaWx1cmUgYmVpbmcgYSBERUFE TE9DSy4gIFdoaWNoIHRoZW4gY2F1c2VkIERNU0lJIHRvIGZyZWUgYWxsIGxvY2tzIG93bmVk IGJ5IHRoZSB2aWN0aW0gcHJvY2Vzcy4gIEJlY2F1c2UgdGhlIHZpY3RpbSBwcm9jZXNzIHdh cyBpZ25vcmluZyB0aGUgREVBRExPQ0sgZXhjZXB0aW9uICh3ZWxsLCAiZWF0aW5nIiBpcyBt b3JlIGxpa2UgaXQgLSBpdCBkaWQgbm90IGRpc3BsYXkgdGhlIGV4Y2VwdGlvbiBvciBnaXZl IGFueSBvdGhlciBoaW50IHRoYXQgaXQgd2FzIGhhcHBlbmluZyksIGl0IGRpZG4ndCBib3Ro ZXIgcmUtbG9ja2luZyBzdHJ1Y3R1cmVzIGJlZm9yZSBhdHRlbXB0aW5nIHRvIHJldHJ5IHRo ZSBvcmlnaW5hbCB0cmFuc2FjdGlvbiAtIHdoaWNoIHdhcyBjYXVzaW5nIHRoZSBOT1RMT0NL RUQgMSBleGNlcHRpb24uDQo+IA0KPiBNeSB0aGVvcnkgd2FzIHByb3ZlbiB0cnVlIG9uY2Ug Y29kZSB3YXMgYWRkZWQgdG8gdGhlIGFwcGxpY2F0aW9uIHRvIG5vdGlmeSBvZiB0aGUgREVB RExPQ0sgZXhjZXB0aW9uIGFuZCB0aGUgZGV2ZWxvcG1lbnQgdGVhbSBoYXMgbm93IHVwZGF0 ZWQgdGhlIGFwcGxpY2F0aW9uIHRvIGhhbmRsZSB0aGUgREVBRExPQ0sgZXhjZXB0aW9uIHBy b3Blcmx5Lg0KDQpBcyB0byAiQVVESVRzIiwgdGhlIHRlcm0gaXMgYWN0dWFsbHkgImF1ZGl0 IHRyYWlsIi4gSGlzdG9yaWNhbGx5LCB0byANCiJtYWludGFpbiBhbiBhdWRpdCB0cmFpbCIg aXMgdG8gcmVjb3JkIGFsbCBvZiB0aGUgYWN0aXZpdGllcyB0aGF0IGFwcGx5IA0KY2hhbmdl cyB0byBhIHJlY29yZCBzeXN0ZW0uIFRoZSB0ZXJtIHByb2JhYmx5IGNvbWVzIGZyb20gYWNj b3VudGluZywgDQp3aGljaCBoYXMgb2JzZXNzZWQgb3ZlciBtYWludGFpbmluZyByZWxpYWJs ZSwgdmVyaWZpYWJsZSByZWNvcmRzIGZvciANCmNlbnR1cmllcy4NCg0KQmVmb3JlIGNlbnRy YWxpemVkIGRhdGEgYmFzZSBzeXN0ZW1zIHdlcmUgdXNlZCwgImF1ZGl0IHRyYWlsIiB3YXMg YSANCmNvbW1vbiB0ZXJtIGZvciBhIGZpbGUgb3IgYSBzZXQgb2YgZmlsZXMgYW4gYXBwbGlj YXRpb24gd291bGQgY3JlYXRlIHRvIA0KcmVjb3JkIGFjdGl2aXRpZXMgYWdhaW5zdCB0aGUg KG9mdGVuIHRhcGUtYmFzZWQpIG1hc3RlciBmaWxlcyBmb3IgdGhlIA0KYXBwbGljYXRpb24u IEl0J3Mgbm90IGEgVW5pc3lzL0J1cnJvdWdocy1zcGVjaWZpYyB0ZXJtIGF0IGFsbC4gIkF1 ZGl0IA0KdHJhaWwiLCAiam91cm5hbCIsIGFuZCAidHJhbnNhY3Rpb24gbG9nIiBhbGwgbWVh biB0aGUgc2FtZSB0aGluZyBpbiB0aGUgDQpjb250ZXh0IG9mIGRhdGEgYmFzZSBzeXN0ZW1z Lg0KDQpUaGUgcHJlZGVjZXNzb3IgdG8gRE1TSUksIERNNjcwMCAoZWFybHkgMTk3MHMpLCB1 c2VkIHRoZSB0ZXJtICJhdWRpdCANCnRyYWlsIiBmb3IgaXRzIHJlY292ZXJ5IGZpbGUsIGFu ZCBJJ20gY2VydGFpbiB0aGF0IHNpbXBseSBnb3QgY2FycmllZCANCmZvcndhcmQgaW50byBE TVNJSS4NCg0KR2xhZCB0byBrbm93IHlvdSBnb3QgeW91ciBOT1RMT0NLRUQgcHJvYmxlbSBy ZXNvbHZlZC4gSXQncyBqdXN0IG9uZSBtb3JlIA0KZXhhbXBsZSBvZiB3aHkgeW91IG5lZWQg dG8gaGFuZGxlIChvciBhdCBsZWFzdCByZXBvcnQpIGFsbCBETVNJSSBleGNlcHRpb25zLg0K DQpQYXVsDQo=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 9, 2021 at 7:05:31 AM UTC-7, Paul Kimpel wrote:

As to "AUDITs", the term is actually "audit trail". Historically, to "maintain an audit trail" is to record all of the activities that apply changes to a record system. The term probably comes from accounting,
which has obsessed over maintaining reliable, verifiable records for centuries.

Modern financial compliance auditing and security auditing also wants to know about access, not just change. There is a case for the DMSII audit files to be expanded to include LOCK and FIND verbs, too. Yes, the database open is recorded in the sumlog (
if the correct logging options are set), but that does not show what records were accessed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

-------- Original Message --------
Subject: Re: How to research DMSII lock/unlock requests
From: [email protected] <[email protected]>
To:
Date: Fri Jul 09 2021 08:43:21 GMT-0700 (Pacific Daylight Time)

On Friday, July 9, 2021 at 7:05:31 AM UTC-7, Paul Kimpel wrote:

As to "AUDITs", the term is actually "audit trail". Historically, to
"maintain an audit trail" is to record all of the activities that apply
changes to a record system. The term probably comes from accounting,
which has obsessed over maintaining reliable, verifiable records for
centuries.

Modern financial compliance auditing and security auditing also wants to know about access, not just change. There is a case for the DMSII audit files to be expanded to include LOCK and FIND verbs, too. Yes, the database open is recorded in the

sumlog (if the correct logging options are set), but that does not show what records were accessed.


I agree that there is a need for DMSII to support tracking of read
access, but recording user access for either read or write is not the
function of the audit trail. Its purpose is to restore the data base to
a consistent state after a crash, a data rebuild, or a rollback. People certainly use it for application-level issues like monitoring or
auditing updates, but that's not what it's for.

Another concern with adding read access logging to the audit trail would
be performance and resource consumption. Bandwidth to the audit trail is already an issue for high-throughput data bases, or else we wouldn't
have partitioned audits. Read access logging would compound that issue
many times over.

A third concern is that even if you added read access logging to the
audit trail, in the general case that wouldn't tell you anything about
the user or device doing the read. In a COMS environment, for example,
the user that DMSII sees is that of the COMS TP, not the user submitting
the transaction. That information is normally available to the TP, but presently there isn't any interface that passes that to DMSII.

A fourth, perhaps lesser, concern is that the audit trail is not a
linear record. There are times that it backs up and erases data that was previously written. That could be a small number of records in the case
of an abort or halt/load recovery, or a whole lot of records in the case
of a rebuild or a rollback.

So while there's a real need for low-level access logging, I don't think
the audit trail is the place to record it. I suggest that there needs to
be an entirely separate mechanism, perhaps integrated with statistics gathering, that could be optimized for time-linear recording of both
read and write access, and include the necessary task and end-user
identifiers.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)