cobol data format!!! urgent!!!

Can anybody please let me know the internal representation of comp-1
and comp-2 data format. for example like what bytes will be stored for
data like +1234,-1234.

On 23 Aug 2004 22:10:40 -0700, deepakhbti@rediffmail.com (Stella)
wrote:

>Can anybody please let me know the internal representation of comp-1
>and comp-2 data format. for example like what bytes will be stored for
>data like +1234,-1234.

That depends on whether the format is IEEE-754, IBM or another
proprietary format. See:

http://www.wordiq.com/definition/IB...nt_Architecture
http://www.wordiq.com/definition/IE..._Point_Standard

deepakhbti@rediffmail.com (Stella) wrote in message news:<455feb1d.0408232110.50e690ee@post
ing.google.com>...
> Can anybody please let me know the internal representation of comp-1
> and comp-2 data format. for example like what bytes will be stored for
> data like +1234,-1234.

Comp-1 in single word floating point and comp-2 is double word
floating point, see the principles of operation manual for an
explanation of how the numbers are held: http://tinyurl.com/6p3qs

GA

Stella wrote:
> Can anybody please let me know the internal representation of comp-1
> and comp-2 data format. for example like what bytes will be stored for
> data like +1234,-1234.

These are compiler dependent, but I can get you started from my old days on
IBM.

A full-word, floating point number is represented by exponent (1st byte) and
mantissa (next three bytes). The exponent is biased by 40 with the implied
hexidecimal point immediately in front of the mantissa. So, zero is
(hexidecimal point, in brackets, is imaginary):

40 [.]00 00 00

The exponent tells you where the hexadecimal point is located (biased by
40). So "1" is represented by:

41 1[.]0 00 00

"1.5" is 41 1[.]8 00 00
"2048" is 43 80 0[.]0 00
"32768" is 44 80 00[.] 00
"0.5" is 39 [.0]80 00 00  <== 39 = 40 - 1, moving hexpoint to left

The sign is carried as the leading bit

"-1" = C1 1[.]0 00 00 00

In double-word floating point, the mantissa is expanded by 4 bytes:

"1" = 41 1[.]0 00 00 00 00 00 00 00

So, to deduce a number like 44 12 34 00,
1. write down the mantissa
12 34 00 00
2. Count off hexidecimal places (44 - 40 = 4)
12 34 [.]00 00
3. Convert 1234 to decimal (4304)

It's not easy to do this by hand, but what's art without suffering.

On Tue, 24 Aug 2004 07:54:32 -0500, "JerryMouse" <nospam@bisusa.com>
wrote:

>Stella wrote: 
>
>These are compiler dependent, but I can get you started from my old days on
>IBM.

ESA/390 supports IEEE in hardware. Enterprise Cobol does not support
IEEE for most uses (yet), but its JNI does.

The question did not specify IBM mainframe. Comp-1 means IEEE in many
Cobol compilers, including some from IBM, such as AS/400, Visual Age,
AIX.

"IEEE Binary Floating-Point is an industry-standard architecture. The
IBM System/360™ hexadecimal floating-point architecture predates the
IEEE standard and has been carried forward through the System/370™ to
current System/390® processors. The growing importance of industry
standards and floating-point combined to produce a need for IEEE
Floating-Point on System/390. At the same time, customer investment in
IBM floating-point had to be preserved. This paper describes the
architecture, hardware, and software efforts that combined to produce
a conforming implementation of IEEE Floating-Point on System/390 while
retaining compatibility with the original IBM architecture. "

http://www.research.ibm.com/journal/rd/435/abbott.html

http://www-1.ibm.com/support/docvie...g27004196&aid=1

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
 news:7ugmi0p0h3r77ukbgki9i08k4k3ioe6pbu@
4ax.com...

> The question did not specify IBM mainframe.

Indeed, nor did it specify the compiler being used.

> Comp-1 means IEEE in many
> Cobol compilers,

..  in which it darned well better be marked as an extension to standard
COBOL, regardless of which compiler you're talking about.

COMPUTATIONAL  is standard COBOL.

COMPUTATIONAL-1, COMPUTATIONAL-WHATSIS and COMPUTATIONAL-ANYTHING-ELSE mean
*exactly* and *only* what the particular compiler vendor on the particular
platform decides they mean, whatever that might be, and regardless of what
any other vendor on the same or any other platform decides they mean.

> including some from IBM, such as AS/400, Visual Age,
> AIX.

Is there any COBOL implementation anywhere in which COMP-1 *might* mean
anything else?   How about COMP-2?   I know of some ...

> "IEEE Binary Floating-Point is an industry-standard architecture.

To a point.  I haven't obtained a copy of IEC 559:1989 or ISO/IEC 10967:1994
to determine how compatible with IEEE 754 they are.

As it stands now, implementors are free to implement one or more of the
USAGEs FLOAT-SHORT, FLOAT-LONG and/or FLOAT-EXTENDED in a manner consistent
with IEEE Floating-Point representations, *if they so choose*, but USAGEs
for the floating-point representations described in IEEE 754 are *not* in
standard COBOL (of any vintage).  .

Note also that the 32-bit and 64-bit IEEE representations are insufficiently
precise or capacious for the purposes of describing a COBOL intermediate
result, and were thus expressly ruled out as a possible format for the COBOL
Standard Intermediate Data Item (SIDI) as described in ISO/IEC 1989:2002.  .

While the 128-bit quadruple-precision IEEE format that *has been proposed*
for the next revision of IEEE 754 is better, and might be shown to meet the
requirements of the COBOL Standard Intermediate Data Item, this format is
not yet *approved* as part of the IEEE standard.

Note also that so far as I know IEEE 754 is an *American* standard, not an
ISO-approved one, and that presents practical and diplomatic problems for
its citation within an *international* standard, particularly if IEC
559:1989 and ISO/IEC 10967:1994 (which *are* indisputably referenceable in
another ISO standard) differ from it in any significant way.

-Chuck Stevens

Hey Stella!!!!

Your sister would tell you it's unseemly to use the word urgent!!!!
when relying on the generosity of strangers.



gerry_anstey@hotmail.com (Gerry Anstey) wrote in message news:<87b8877d.0408240136.7dfcbd4c
@posting.google.com>...
> deepakhbti@rediffmail.com (Stella) wrote in message news:<455feb1d.0408232
110.50e690ee@posting.google.com>... 
>
> Comp-1 in single word floating point and comp-2 is double word
> floating point, see the principles of operation manual for an
> explanation of how the numbers are held: http://tinyurl.com/6p3qs
>
> GA

On Tue, 24 Aug 2004 09:43:12 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:7ugmi0p0h3r77ukbgki9i08k4k3ioe6pbu@
4ax.com...
> 
>
> ...  in which it darned well better be marked as an extension to standard
>COBOL, regardless of which compiler you're talking about.
>
>COMPUTATIONAL  is standard COBOL.
>
>COMPUTATIONAL-1, COMPUTATIONAL-WHATSIS and COMPUTATIONAL-ANYTHING-ELSE mean
>*exactly* and *only* what the particular compiler vendor on the particular
>platform decides they mean, whatever that might be, and regardless of what
>any other vendor on the same or any other platform decides they mean.

When the vendor says it complies with IEEE 754, users refer to that
standard for a definition. Granted it's not Cobol, but it's not
vendor-defined either.

>Is there any COBOL implementation anywhere in which COMP-1 *might* mean
>anything else?   How about COMP-2?   I know of some ...

You've kindly described here their meaning in Unisys.
 
>
>To a point.  I haven't obtained a copy of IEC 559:1989 or ISO/IEC 10967:199
4
>to determine how compatible with IEEE 754 they are.

IEC 559 is identical.  IEC 10967:1994 added integers.  Its
floating-point is close but not identical. Differences are in flags
and handling extreme values such as zero and infinity. The 2001 update
added numerical functions.

Floating-point numbers contain a flag specifying whether they follow
10967 or 'other', which usually means 754/559.

>As it stands now, implementors are free to implement one or more of the
>USAGEs FLOAT-SHORT, FLOAT-LONG and/or FLOAT-EXTENDED in a manner consistent
>with IEEE Floating-Point representations, *if they so choose*, but USAGEs
>for the floating-point representations described in IEEE 754 are *not* in
>standard COBOL (of any vintage).

In the 20 years since IEEE 754 was adopted, the computer industry
boomed. Because Cobol offered no floating-point, we used the best
standard available.

>Note also that the 32-bit and 64-bit IEEE representations are insufficientl
y
>precise or capacious for the purposes of describing a COBOL intermediate
>result, and were thus expressly ruled out as a possible format for the COBO
L
>Standard Intermediate Data Item (SIDI) as described in ISO/IEC 1989:2002.  
.
>
>While the 128-bit quadruple-precision IEEE format that *has been proposed*
>for the next revision of IEEE 754 is better, and might be shown to meet the
>requirements of the COBOL Standard Intermediate Data Item, this format is
>not yet *approved* as part of the IEEE standard.

These four sources say it has been in the standard since 1985. The
last two made machines and/or compilers that used it.

IEC 10967 inherited Extended (below) from the earlier standards. Look
at ISO/IEC 14882, the C++ standard approved in 1998. It includes a
'long double' type and it explicitly cites compliance with IEC 10967.
http://www.kuzbass.ru/docs/isocpp/l...b.support.types


"When comparing the format parameters of "extended double-precision"
in IEEE-754's Table 1 and those of the so-called
"quadruple-precision", one finds that the "quadruple-precision" format
is simply a specific instance of the "extended double-precision"
format. Similarly, one will note that "double-precision" is a specific
instance of "extended single-precision"."
http://babbage.cs.qc.edu/courses/cs...references.html

"The standard defines the encoding for the quadruple-precision
floating-point data type "quadruple" (128 bits or 16 bytes). The
encoding used is designed to be a simple analog of of the encoding
used for single and double-precision floating-point numbers using one
form of IEEE double extended precision. The standard encodes the
following three fields, which describe the quadruple-precision
floating-point number: "
[Sun manual]
http://asg.web.cmu.edu/rfc/rfc1832.html

Language elements that support the various extended range and ex-
tended precision floating-point architectural features:

-  32-bit IEEE S_floating data type, with an 8-bit exponent and
23-bit mantissa, which provides a range of 1.17549435E-38 (normal-
ized) to 3.40282347E38 (the IEEE denormalized limit is 1.40129846E-
45) and a precision of typically 7 decimal digits

-  64-bit IEEE T_floating data type, with an 11-bit exponent and
53-bit mantissa, which provides a range of 2.2250738585072013D-
308 (normalized) to 1.7976931348623158D308 (the IEEE denormal-
ized limit is 4.94065645841246544D-324) and a precision of typ-
ically 15 decimal digits

-  128-bit IEEE extended X_floating data type, with a 15-bit ex-
ponent and a 113-bit mantissa, which provides a range of approx-
imately 6.48Q-4966 to 1.18Q4932 and a precision of typically 33
decimal digits
[DEC manual]
http://www.iac.tut.fi/usr/local/doc.../f9a200_spd.txt

See also this bibliography. Search for extended.
http://www.cs.berkeley.edu/~dbindel...279/dsb-bib.pdf

>Note also that so far as I know IEEE 754 is an *American* standard, not an
>ISO-approved one, and that presents practical and diplomatic problems for
>its citation within an *international* standard, particularly if IEC
>559:1989 and ISO/IEC 10967:1994 (which *are* indisputably referenceable in
>another ISO standard) differ from it in any significant way.

That's a problem. It appears that IEC 559 will be replaced by IEC
10967, which has small differences -- not in number representation but
in administrative details.

I cannot find one single compiler, any language, claiming to be
10967-compliant. Yet J4 cannot give us IEEE floating-point because
10967 exists?

>As it stands now, implementors are free to implement one or more of the
>USAGEs FLOAT-SHORT, FLOAT-LONG and/or FLOAT-EXTENDED in a manner consistent
>with IEEE Floating-Point representations, *if they so choose*, but USAGEs
>for the floating-point representations described in IEEE 754 are *not* in
>standard COBOL (of any vintage).

This response from Ann Bennett, only two years ago, rejects the idea
of using EITHER standard in Cobol 2002.

"1.h. Reference, and use later on, IEC 60559 (a.k.a. IEEE 754, IEEE
floating point).

Response:     A floating point data type was added in FCD 1989 to
provide access to hardware floating point, which is not universally
IEEE 754.   A primary requirement addressed by FCD 1989 is interaction
with other programming languages.   A mandated IEEE 754 implementation
would not meet that requirement. "

http://www.cobolportal.com/j4/files/02-0060.doc

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
 news:m0vmi0p1e99g7sje29tmnt48rie677dlg3@
4ax.com...
 
10967:1994 
>
> IEC 559 is identical.  IEC 10967:1994 added integers.  Its
> floating-point is close but not identical. Differences are in flags
> and handling extreme values such as zero and infinity. The 2001 update
> added numerical functions.

> Floating-point numbers contain a flag specifying whether they follow
> 10967 or 'other', which usually means 754/559.

Aye, there's the rub.  "Usually means ..." doesn't work really well in a
standard, be it ISO 10967 or ISO/IEC 1989!

> In the 20 years since IEEE 754 was adopted, the computer industry
> boomed. Because Cobol offered no floating-point, we used the best
> standard available.

Who be "we"?  COBOL on Unisys MCP systems has had pretty near "the best
floating-point available" for forty-odd years! ;-)

What *one* format of high-precision floating-point do you believe is
appropriate for *every* existing machine, producing identical results across
all platforms?

That question hasn't even been answered in COBOL for "single-word" integers!

> These four sources say it has been in the standard since 1985. The
> last two made machines and/or compilers that used it.

"The encoding of extended formats is implementation-defined, and thus their
size in storage."   Quadruple precision formats are *basic*, one binary and
one decimal, and data items in each format occupy 128 bits.  That there are
exactly two instantiations of extended formats that match the quadruple
precision format (*still described as proposed* in the DRAFT dated last
Friday for the next revision of ISO 754!) is a red herring.   *Which*
extended format in the *existing* ISO 754 should the COBOL standard have
insisted was appropriate for all implementations?

> IEC 10967 inherited Extended (below) from the earlier standards. Look
> at ISO/IEC 14882, the C++ standard approved in 1998. It includes a
> 'long double' type and it explicitly cites compliance with IEC 10967.
> http://www.kuzbass.ru/docs/isocpp/l...b.support.types

From what I see, this is a panoply of formats, not a single one appropriate
to all implementations.

> "When comparing the format parameters of "extended double-precision"
> in IEEE-754's Table 1 and those of the so-called
> "quadruple-precision", one finds that the "quadruple-precision" format
> is simply a specific instance of the "extended double-precision"
> format. Similarly, one will note that "double-precision" is a specific
> instance of "extended single-precision"."

> http://babbage.cs.qc.edu/courses/cs...references.html

And ... Are you prepared to demand that all COBOL vendors support
bit-addressability and arbitrary word lengths in order to provide for
"extended double precision" in all formats?  Of all vendors around, I'd
argue that Unisys has more experience with that than anyone else around,
based on my eighteen years of intimate exposure to the Burroughs Small
System -- which had bit-addressable memory and for which the microcode
provided different word lengths (if any word orientation at all) for each
language!  I don't think other vendors would appreciate a demand by the
COBOL standard for such flexibility!

> "The standard defines the encoding for the quadruple-precision
> floating-point data type "quadruple" (128 bits or 16 bytes). The
> encoding used is designed to be a simple analog of of the encoding
> used for single and double-precision floating-point numbers using one
> form of IEEE double extended precision. The standard encodes the
> following three fields, which describe the quadruple-precision
> floating-point number: "
> [Sun manual]
> http://asg.web.cmu.edu/rfc/rfc1832.html

Ditto.  This isn't a *basic* format, it's an *extended* format.  It is still
*proposed* as a *basic* format as of the draft of the next revision for IEEE
754 *from last Friday*.

> Language elements that support the various extended range and ex-
>          tended precision floating-point architectural features:
> ... -  32-bit IEEE S_floating data type, with an 8-bit exponent and
> 23-bit mantissa, which provides a range of 1.17549435E-38 (normal-
>  ized) to 3.40282347E38 (the IEEE denormalized limit is 1.40129846E-
> 45) and a precision of typically 7 decimal digits
>
>  -  64-bit IEEE T_floating data type, with an 11-bit exponent and
>  53-bit mantissa, which provides a range of 2.2250738585072013D-
>  308 (normalized) to 1.7976931348623158D308 (the IEEE denormal-
>   ized limit is 4.94065645841246544D-324) and a precision of typ-
>   ically 15 decimal digits
>
>  -  128-bit IEEE extended X_floating data type, with a 15-bit ex-
>  ponent and a 113-bit mantissa, which provides a range of approx-
>  imately 6.48Q-4966 to 1.18Q4932 and a precision of typically 33
>  decimal digits
> [DEC manual]
> http://www.iac.tut.fi/usr/local/doc.../f9a200_spd.txt

And with the exceptions in range cited above, I'm supposed to assume that
the 32-bit and 64-bit encodings are consistent with the goal of
unconditionally identical results on *all* platforms?   That someone has
implemented something that looks like, and sometimes works like an IEEE 754
format doesn't impress me much!

It does appear that the particular choice for an Extended X-floating type
does match what is proposed as a basic type in IEEE 754, but it ain't in
IEEE 754 as a *basic* type yet, it is one among an undefined number of
possibilities within the set of extended binary floating-point formats.

> I cannot find one single compiler, any language, claiming to be
> 10967-compliant. Yet J4 cannot give us IEEE floating-point because
> 10967 exists?

I believe the *basic* 32-bit and the *basic* 64-bit floating-point encodings
are inadequate for general COBOL use, both in terms of precision and in
terms of range.   There is not a *single basic* IEEE floating-point format
that is sufficiently capacious for COBOL.  Once one of these standards
provides a *single basic* format adequate to contain a Standard Intermediate
Data Item then that format, and the rounding and precision loss rules
associated with that format, can be *considered* for *standard* COBOL.

Any vendor is free to provide support for whatever formats he wants, and for
whatever rules for "native arithmetic" he deems appropriate.

> This response from Ann Bennett, only two years ago, rejects the idea
> of using EITHER standard in Cobol 2002.
>
> "1.h. Reference, and use later on, IEC 60559 (a.k.a. IEEE 754, IEEE
> floating point).
>
> Response:     A floating point data type was added in FCD 1989 to
> provide access to hardware floating point, which is not universally
> IEEE 754.   A primary requirement addressed by FCD 1989 is interaction
> with other programming languages.   A mandated IEEE 754 implementation
> would not meet that requirement. "
>
> http://www.cobolportal.com/j4/files/02-0060.doc

Yes, this was in response to a comment from the national standards body of
Sweden about the Final Committee Draft, and I agree with the response, which
represented J4's consensus.

Your DEC example above amply illustrates my big concern for the 32-bit and
64-bit encodings:  even if the format matches, the *operating environment*
(regardless of system, hardware, platform, whatever you want to call it) has
to *operate the same* regardless.  This looks like IEEE floating-point
formats, but the documentation expressly states that it doesn't behave like
them.

And as to her concern:  floating-point formats are *typically* defined for
the individual platform, and the 2002 standard COBOL definition allows them
to be what the platform defines them to be.  If the COBOL compiler required
that IEEE-format floating-point be used, and the Pascal compiler on the same
platform used native-format floating-point, the two are incompatible.  For
any degree of more-than-snail-like performance, in order to make good use of
IEEE floating point formats, the particular platform vendor has to provide
*hardware* support for the format.  Not all do, not all wish to do so, not
all believe that there is sufficient customer demand for this feature.

I don't believe an ISO standard has yet "blessed" a *single* extended
X-floating format; my best guess is that the 128-bit decimal and binary
floating-point formats in the draft will be in the next revision of IEEE
754, and promulgated into ISO standards from there.  Until ISO (or IEEE)
establishes hard-and-fast rules for rounding and precision loss in
arithmetic for those *specific* formats, I don't think there's much chance
of convincing WG4 that this is a worthwhile addition to the standard.

Once these formats are accepted *as a basic format in an international
standard*, I see significant merit in the idea of data types corresponding
to them, and even in the idea of support (in the language, in hardware, and
in supporting software) for the IEC/IEEE arithmetic rules corresponding to
the six basic IEEE 754 floating-point formats in a manner similar to, and
according to the precedent established by, the ARITHMETIC clause of the
OPTIONS paragraph.  But *only* once the 128-bit encodings are ensconced as
*basic* formats in an ISO or IEC standard.

Note that another comment from Sweden was "Reference, and use later on,
LIA-1 (ISO/IEC 10967-1:1994;  note, however, annex E of LIA-2).  LIA-1 is
"Language independent arithmetic-integer and floating point arithmetic."
The J4 response was "Most of the arithmetic specification in FCD 1989
existed in the previous edition of the COBOL standard and cannot be changed
incompatibly.  WG4 will investigate mapping to LIA-1 in a future standard".

In this context, since the FCD that was being commented on was that which
has already led to ISO/IEC 1989:2002, and since WG4 has already indicated to
J4 what feature content they will accept in the planned 2008 draft, and by
their direction that feature content doesn't include LIA-1 and LIA-2.  So
far as I can tell, *basic* floating-point formats (as distinct from specific
or arbitrary selections from among the many possible *extended*
floating-point formats) sufficient to encompass the requirements of a COBOL
Standard Intermediate Data Item do not *yet* exist in a *published*
international standard.  "Future standard" in this case means "some version
of the standard after the one being proposed for publication in 2008", so
from that I'd think it'd be safe to surmise that LIA-1 and LIA-2 support
won't show up in an approved version of ISO/IEC 1989 any time soon.

-Chuck Stevens

Chuck Stevens wrote:

>Who be "we"?  COBOL on Unisys MCP systems has had pretty near "the best
>floating-point available" for forty-odd years! ;-)
>
>
"Who be 'we' ? Never realized you had visited my beloved Somerset on
vacation.

"Ooh bee wee ?". "Oi'll tell yoo ooh wee bee if yoo  tells  o'I  where
yooos at ".  :-)

Roberto,

ACCOUNTING :

While I'm at it. You posted something a while back on accounting -
nobody picked up on it.

Background, just before leaving RAF was doing correspondence course
Chattered Institute of Secretaries, (the corporate Secretary then was
chief legal-beagle(corporate law)/and chief bean-counter - now defunct
and as we know the two functions are now split). Then in civvy street
became the lowest of the low in Sep '61 coding A/P invoices to be
key-punched using either Power-Samas or Hollerith for print-outs. Come
late '62/early '63 was Deputy Accountant for this large dairy company.
Switched to EDP in June '64 with same company. Never regretted it,
getting away from bean-counting. (O'ive been at this ADP stuff, man an'
boiiy theese passt fortie yeers).

Now your message wasn't Misinformation but more Disinformation. That
Dutchman back in the 1600s invented Double-Entry book-keeping NOT
Quadruple. Where did you learn your Inventive Accounting ? Enron ? Ahhh
that explains all..As I recall you put $5,000 into a new company you set
up and called the money a 'Future Liability' ?. Then magically you
turned the $5,000 into $10,000. Sometime since I did manual accounting
or computer accounting but I thought that can't be right.

Two possibilities :-

1) Deposit to Bank then make immediate Payment (Zilch !)
2) What you suggested - Deposit to Bank, don't make payment and have it
in a 'Current future liability' - still only comes out as $5,000.

Whichever way you do it, you ain't gonna see Ten Grand on your Balance
Sheet. Don't believe me. Do what I did, for confirmation, post the
entries for  (1) and (2) above, as separate companies, through something
like Quickbooks !

I know........ You are going to tell me Intuit's Quickbooks is a lousy
package.

OBJECT ORIENTATION :

I read with interest your  "Random Number Simulation  ?" where you were
comparing using straight table features versus OO Collection classes.

- I'm going from memory but I think you set the Capacity to a figure of
50K.( NB Mr. Stephens - use of the word 'Capacity'.)

- One exercise you used Dictionary (will be called KeyedCollection in
new J4 TR(Technical Report) for collections). I could be wrong, but
reading Adele Golberg's book "Smalltalk 80", (the text, not the coded
examples), Dictionaries/KeyedCollections are primarily quick
memory-resident look-up tables. - so the vendor's code, having
physically placed the element in the collection, each element probably
added as "Last", then has to do the equivalent of an ISAM, registering
the Key and noting the 'silent' index position of the Element. - plus of
course no duplicate keys allowed. That means KeyedCollections are a bit
'busy, busy, busy' actioning elements. Truly doesn't make it suitable
for what you were doing.

- SortedCollections - I think you may have used ? Again adding records
as 'Last' and probably doing a silent index comparing values of elements
either side of the one you are entering. Busy, busy, busy - again not
suitable.

- OrderedCollection - just keeps adding as 'Last' which is what I think
you were after. However, you complained its performance was also lousy.
Haven't looked at them, because I haven't seen the need, but perhaps one
of the others, Bag, ValueSet might possibly have been useful . Now don't
rush off and try it because our kind friends at J4 have reduced it
currently to :-

- OrderedCollection
- UnorderedColllection
- KeyedCollection

Wait just a few days Chuck - I *USE* SortedCollections  80-95% of the
time. Piss on Unordered - that's achievable using Ordered. which will
also do what Robert wants.

Back to Robert - Smalltalk does have specific classes for Simulation -
but I've no idea how they perform. Perhaps the basic OrderedCollection
may not be up to the type of volume you are talking about, not a big
number, I believe it was 50K - but where there is user-interaction, or
say collecting data for a simulation (some O & M goof work-studying the
customer flow, through a department store central cash desk), then the
performance will be more than adequate.  They are just recording timed
events.

I believe you have Fujitsu as well as ServerExpress - does F/J provide
class source like M/F. ? It's a boon - gives you tips on coding and in
your case having access to the support classes for OrderedCollection you
could sub-class with your own methods to override  some of the current
ones, to fine-tune the simulation performance.

I could be real *evil* and suggest that if you think OO is lacking in
this area make a submission to J4 - Chuck is *already* groaning and
preparing his draft e-mail.  Don't you dare, Robert ! Because to use
your own wording, "this is one of my intellectual exercises....". Anyway
before your paper hits Don Schricker, Chuck will already have e-mailed
the others on J4 warning ,  "Whatever the number is that gets allocated,
from RW - get ready say, "No!"). :-)

Here endeth the lesson - people get paid for this stuff.

Jimmy,  Calgary  AB