@Brian Cram; under the umbrella  "It is common knowledge (or most D3 Linux people know)  that…";

I've been baffled by this, but gracefully, I have a solution.

My client has a General Ledger (let's call it Database – I don't wish to call it a D3 account) that strangely has a file called – ACCOUNTS.

This ledger file (ACCOUNTS) is used on other D3 databases (accounts) via a Q-pointer.

Now the "problem"; assuming one wishes to use the 'a' option in attribute 9 of the USERS file to start the accounting (logon logoff etc. etc.) – this file is referred to in most D3 accounts as … yep you guessed it ACCOUNTS!

So, combined with the TIMEOUT option, you can experience an ITEM-LOCK (or GROUP-LOCK) very often.

So, tip – DON'T have a file called ACCOUNTS (or a Q pointer for that matter to another D3 account) – or remove the 'a' option in the USERS file.

Rocket - please be aware of this - unless otherwise OR can anyone out there offer a better solution?

(yes, rename the ACCOUNTS file used in the Ledger Database to another name like
LEDGER_ACCOUNTS)

p.s. this is D3 v 10.3x Linux)

 Warm Regards

Stefano

Yes, just like when we have shortcuts like gl for get-list and you have a file named GL somewhere. The users' developers need to be aware of these things. No better solution than that. 

My developer used accounts and gl as file names in the accounting module

 @Brian Cram; under the umbrella  "It is common knowledge (or most D3 Linux people know)  that…";

I've been baffled by this, but gracefully, I have a solution.

My client has a General Ledger (let's call it Database – I don't wish to call it a D3 account) that strangely has a file called – ACCOUNTS.

This ledger file (ACCOUNTS) is used on other D3 databases (accounts) via a Q-pointer.

Now the "problem"; assuming one wishes to use the 'a' option in attribute 9 of the USERS file to start the accounting (logon logoff etc. etc.) – this file is referred to in most D3 accounts as … yep you guessed it ACCOUNTS!

So, combined with the TIMEOUT option, you can experience an ITEM-LOCK (or GROUP-LOCK) very often.

So, tip – DON'T have a file called ACCOUNTS (or a Q pointer for that matter to another D3 account) – or remove the 'a' option in the USERS file.

Rocket - please be aware of this - unless otherwise OR can anyone out there offer a better solution?

(yes, rename the ACCOUNTS file used in the Ledger Database to another name like
LEDGER_ACCOUNTS)

p.s. this is D3 v 10.3x Linux)

 Warm Regards

Stefano

Hi Brian,

To begin, I have to admit that before reading this email I have had no experience with the ACCOUNTS file in D3, so I decided to investigate.

I looked at the MD file for a few accounts in our system and found that each instance of the "accounts" file was a q-pointer to the DM account.

Ok - that makes sense.

My next thought was, were those q-pointers created by the system during the create-account or were they created after?

A little investigation shows that the accounts file is in the "newac" file and I found that when an account is created, all the files in the "newac" file are applied to the new account.

This means that when a new account is created, the "accounts" file q-pointer is automatically created, leading back to my discovery that there is an "accounts" q-pointer in all of accounts in our system.

Next, I tried to create a file called "accounts" and got this message:

(I also checked if there was an overwrite option on the create-file command - there isn't one listed.)

:create-file accounts 1 3

[413] the file name already exists in the master dictionary.

Based on all of this information, it seems to me that the only way an "accounts" file could be created would be:

1. For the user to delete the current accounts file prior to creating a new one.
2. Someone editing the "newac" file and removing the "accounts" item.

So, it would seem that there is, in essence, a protection of the "accounts" file built-in to the system.

Brian - your thoughts.

Lance

Very well investigated and articulated, Lance. So the original description (and I quote) "The ACCOUNTS file (this should be a reserved file name)", turns out it IS a reserved file name. Based on its functionality, I'd be willing to bet it's been there for a long time. Someone would have to do what you said to overwrite ours...

OR

they restored an account from a REALLY old Pick system (maybe pre-D3) and the ACCOUNTS file was already in their account. In that case UPDATE-MD would NOT overwrite or delete the file but would rather make an entry in the DM,CLASHES, file stating that it couldn't overwrite.

So, Stefano, how old is that original system, and on what Pick flavor did it originate?

 @Brian Cram; under the umbrella  "It is common knowledge (or most D3 Linux people know)  that…";

I've been baffled by this, but gracefully, I have a solution.

My client has a General Ledger (let's call it Database – I don't wish to call it a D3 account) that strangely has a file called – ACCOUNTS.

This ledger file (ACCOUNTS) is used on other D3 databases (accounts) via a Q-pointer.

Now the "problem"; assuming one wishes to use the 'a' option in attribute 9 of the USERS file to start the accounting (logon logoff etc. etc.) – this file is referred to in most D3 accounts as … yep you guessed it ACCOUNTS!

So, combined with the TIMEOUT option, you can experience an ITEM-LOCK (or GROUP-LOCK) very often.

So, tip – DON'T have a file called ACCOUNTS (or a Q pointer for that matter to another D3 account) – or remove the 'a' option in the USERS file.

Rocket - please be aware of this - unless otherwise OR can anyone out there offer a better solution?

(yes, rename the ACCOUNTS file used in the Ledger Database to another name like
LEDGER_ACCOUNTS)

p.s. this is D3 v 10.3x Linux)

 Warm Regards

Stefano

Stefano: I just chatted with an Engineering resource who's been in D3 Engineering since AP became D3. He says the ACCOUNTS file and USERS A option thing has been there for as long as he can remember. It was in AP (Advanced Pick) as well. So I'm guessing that this was user-overwritten a long time ago or they were migrated from another flavor of Pick that didn't have a USERS file.

Hi @Brian Cram

Yeah, probably so. I remember installing the client way back in 1990 with a 3-user R83 system. And so it developed.

Stefano: I just chatted with an Engineering resource who's been in D3 Engineering since AP became D3. He says the ACCOUNTS file and USERS A option thing has been there for as long as he can remember. It was in AP (Advanced Pick) as well. So I'm guessing that this was user-overwritten a long time ago or they were migrated from another flavor of Pick that didn't have a USERS file.

Brian,

How does the ACCOUNTS file get pruned? Do I have to do it periodically or is there a system function to do it?