FileMan enhancement: ^DD("STRING_LIMIT")

[George Timson]

Let's start a new post, in response to some FileMan "fixes" that Jim
Self posted elsewhere here on the hardhats list.

Jim, I agree that we need to make FileMan more flexible about
enforcing (what was) the 255-character limit on the length of MUMPS
strings, I will take your suggestion in MSC FileMan of storing an
alternative length in the (as yet nonexistent) node
^DD("STRING_LIMIT").

In a presentation I made to WorldVistA in January, I actually talked
about this needed enhancement. There are places other than the
routines you cite where this will be useful.

But I have always been worried about users who would run FileMan with
an "extended" limit on string size, and then try to transport the
definitions they have created back (via KIDS) to a site where the
limit was tighter. That's why I hestitate to make some of the changes
you suggest.

Also, why did you default the maximum length to 1024 bytes, in the
FileMan lines you changed, if ^DD("STRING_LIMIT") does not exist? Is
the VA SAC Standard that liberal? In fact, where _is_ the VA SAC? If
we at hardhats do not have the currently-official VA Standard (at
http://www.hardhats.org/tools/sac96.html) could someone PLEASE provide
it to me?

Thanks.

--George Timson

[Jim Self]

George Timson wrote:

Let's start a new post, in response to some FileMan "fixes" that Jim
Self posted elsewhere here on the hardhats list.
  

Thanks. I intended to start a new thread for this myself, but I made the mistake of clicking the reply button to a previous post. It seems that in my email client (Thunderbird) the data that links one message to another is uneditable.

Jim, I agree that we need to make FileMan more flexible about
enforcing (what was) the 255-character limit on the length of MUMPS
strings,  I will take your suggestion in MSC FileMan of storing an
alternative length in the (as yet nonexistent) node
^DD("STRING_LIMIT").

In a presentation I made to WorldVistA in January, I actually talked
about this needed enhancement.  There are places other than the
routines you cite where this will be useful.

But I have always been worried about users who would run FileMan with
an "extended" limit on string size, and then try to transport the
definitions they have created back (via KIDS) to a site where the
limit was tighter.  That's why I hestitate to make some of the changes
you suggest.
  

The 255-character limit has not reflected the actual limits of M implementations for many years. Enforcing an obsolete limit like that is a policy choice for a sysadmin. That shouldn't be determined by hardcoded limits in a general utility like Fileman.

Also, why did you default the maximum length to 1024 bytes, in the
FileMan lines you changed, if ^DD("STRING_LIMIT") does not exist?

I made the string length changes some years ago so I don't recall clearly. It seemed the minimum usable number at the time. It might have been that the oldest VistA distributions for GT.M on source forge were configured with only 1KB data blocks. Any other current implementation of M I have heard of that is capable of running Fileman has had a much higher actual string length limit for many years.

-- 

---------------------------------------
Jim Self
Systems Architect, Lead Developer
VMTH Information Technology Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
---------------------------------------
M2Web Demonstration with VistA
(http://vista.vmth.ucdavis.edu/)
---------------------------------------

[K.S. Bhaskar]

On 04/14/2008 11:29 AM, Jim Self wrote:

[KSB] <...snip...>

> The 255-character limit has not reflected the actual limits of M
> implementations for many years. Enforcing an obsolete limit like that is
> a policy choice for a sysadmin. That shouldn't be determined by
> hardcoded limits in a general utility like Fileman.
>> Also, why did you default the maximum length to 1024 bytes, in the
>> FileMan lines you changed, if ^DD("STRING_LIMIT") does not exist?
> I made the string length changes some years ago so I don't recall
> clearly. It seemed the minimum usable number at the time. It might have
> been that the oldest VistA distributions for GT.M on source forge were
> configured with only 1KB data blocks. Any other current implementation
> of M I have heard of that is capable of running Fileman has had a much
> higher actual string length limit for many years.

[KSB] For the record, the string size limit in GT.M is 1MB for local
variables.

For global variables, the requirement is that the global node must fit
in one database block, so the limit is determined by the database block
size (and less than 1MB).

Regards
-- Bhaskar

______________

The information contained in this message is proprietary and/or confidential. If you are not the
intended recipient, please: (i) delete the message and all copies; (ii) do not disclose,
distribute or use the message in any manner; and (iii) notify the sender immediately. In addition,
please be aware that any message addressed to our domain is subject to archiving and review by
persons other than the intended recipient. Thank you.
_____________

[Jim Self]

K.S. Bhaskar wrote:

On 04/14/2008 11:29 AM, Jim Self wrote:

[KSB] <...snip...>

  

The 255-character limit has not reflected the actual limits of M
implementations for many years. Enforcing an obsolete limit like that is
a policy choice for a sysadmin. That shouldn't be determined by
hardcoded limits in a general utility like Fileman.
    

Also, why did you default the maximum length to 1024 bytes, in the
FileMan lines you changed, if ^DD("STRING_LIMIT") does not exist?
      

I made the string length changes some years ago so I don't recall
clearly. It seemed the minimum usable number at the time. It might have
been that the oldest VistA distributions for GT.M on source forge were
configured with only 1KB data blocks. Any other current implementation
of M I have heard of that is capable of running Fileman has had a much
higher actual string length limit for many years.
    

[KSB] For the record, the string size limit in GT.M is 1MB for local
variables.

For global variables, the requirement is that the global node must fit
in one database block, so the limit is determined by the database block
size (and less than 1MB).
  

The issue of string size limits in M is more complicated than can be fully reflected by a single number.

Local string size in GT.M seems effectively unlimited and the actual limit for global strings depends on the dataset in which a particular global is stored.

Other current M implementations also have different local and global string limits, both much larger than 1K.

^DD("STRING_LIMIT") may be just a starting point that could be replaced ultimately with a function that depends on the target variable name.

[Steven McPhelan]

What is the recommended data block size for GT.M for VistA?  In Cache, we use 8K data blocks.  I can store up to 32K bytes on a single global node.  Clearly, somehow, Cache allows the spanning of data on a single global node across multiple database blocks.  But you said that GT.M does not do that.  Therefore it is incumbent upon the system manager to know how his database will be used and what is the range of string lengths that will be generated by the GT.M application in deciding the database block size.  What is the range for database block size on GT.M.

[K.S. Bhaskar]

Maximum block size with GT.M is 65024 bytes. Most VistA/GT.M
implementations that I know of use a 4KB block size. I think a 1KB or
2KB block size suffices for globals that VistA/GT.M implementations
actually have in production, but a 4KB block size makes IO slightly more
efficient on an x86 GNU/Linux system.

I am curious what the biggest single global nodes are in production
VistA implementations. Anyone know?

Regards
-- Bhaskar

[Steven McPhelan]

As mentioned in this message thread, FM is not suppose to allow an individual node to exceed 255 characters.  But then we have those temp globals, ^UTILITY, ^TMP, ^XTMP.  The VA's Infrastructure team recommended a maximum size of 512 characters per global node.  This was a setting to accommodate DSM on VMS as 512 was the maximum limit for DSM.  I believe that is still the defacto setting if possible.  I would have to re review the Cache configuration parameters to see if there is even a parameter for limiting the string length of a global node.  Us old timers, we just have it burnt into our brains, 512 bytes because of the old days.  You then program more by habit that by system capabilities.

 

The current VA programming SAC states that variable names shall not exceed 200 characters per their compute formula.  I did not see any statement about the length of the value a variable name may contain.

[George Timson]

On Apr 14, 2:03 pm, "Steven McPhelan" <smcphe...@alumni.uci.edu>
wrote:
...

> The current VA programming SAC states that variable names shall not exceed
> 200 characters per their compute formula. I did not see any statement about
> the length of the value a variable name may contain.

...

I agree Steve. (Thank you by the way, for sending me the new SACC!)

I do not believe that either the old or the new SACC ever changed the
MUMPS Standard string length of 255 characters. But I am in favor of
relaxing the limitation
when it can be parameterized by ^DD("STRING_LIMIT") and when it
doesn't jeopardize
true portability of data structures via KIDS.