Kevin;
The point I was making was that there are a lot of assumptions being made
about the environment, MUMPS has been abstraction which avoids a lot of the
assumptions. A character can be 8, 16 or 32 bits. To MUMPS, they are just
characters. The standard was written to try to avoid the bit count and be
beyond the implementation platform. There actually is a DSM-Japan which is
16 bit. There was also a Latvian MUMPS-like implementation which worked
with Cyrilic. As this model goes farther out, there will be more need for
the larger byte assignments.
As for the 6 bit character sets, you are correct. But I wanted folks to
stretch out beyond the simple assumptions to think about the other systems
which are currently out there and that are being used. But the bottom line
is that MUMPS programs could work just fine in an environment which does
support 6, 8, 9, 16, or even 32-bit characters (probably the next level of
technology).
Best wishes; Chris
----- Original Message -----
From: "Kevin Toppenberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 21, 2005 5:24 PM
Subject: Re: [Hardhats-members] more M read questions
Let's be practical. There seem to be only a few M environments. Are
any of them using 6 bit bytes etc? Do any of the underlying file
systems server other than an 8 bit byte when asked to read one unit
(byte) from a file?
Yes, there are widecharacter strings, but the underlying filesystem
still deals with them as 8-bit bytes, doesn't it?
Kevin
On 8/21/05, Chris Richardson <[EMAIL PROTECTED]> wrote:
> Ah, but how big is a character? MUMPS deals in characters reguardless of
> the number of octets required to represent it.
>
> 1Octet = 8 bits
>
> Ascii - 1 octet/character
> Unicode, Kanji,Katakana,etc - 2 octets/character
> ISO-10646 - 4octets/character
>
> Then there were 36 bit words (6 (6-bit) characters per word (Univac
> FIELDDATA), or 10 6-bit characters/word, but each of these are mapping
> systems for characters.
>
> ----- Original Message -----
> From: "Ruben Safir" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, August 21, 2005 12:46 PM
> Subject: Re: [Hardhats-members] more M read questions
>
>
> > On Sun, 2005-08-21 at 15:13 -0400, smcphelan wrote:
> > > Here, here. Chris also stated this. ANSI standard M is not really
> designed
> > > to handle binary data. This is one reason Intersystems added
extensions
> (if
> > > you wish to call it that). But then you are bound to a specific M
> vendor's
> > > implementation, in this case, Cache.
> > >
> >
> > This is all beyond me because all data is just data. ASCI, Binary, all
> > the same thing.
> >
> > No matter how you look at it, a byte can only have one of 256
> > representations. The rest is all interpretation.
> >
> > Ruben
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
> > Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Hardhats-members mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/hardhats-members
> >
> >
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Hardhats-members mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/hardhats-members
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
