Why the NeoSort World Record is
Good News for Mainframe Users
Published: July 2006
For the latest information, please see www.microsoft.com/mainframe
Abstract
On February 7, 2006, Ordinal Technology and Fujitsu set a new world record for the
MinuteSort benchmark in the “Daytona,” or commercial program, category using the
NeoSort sort program. NeoSort read 40 gigabytes of data (400 million 100-byte
records) in less than one minute. The sort ran on Fujitsu PRIMEQUEST computers
using Fujitsu ETERNUS storage subsystems—hardware that costs a fraction of the
cost of today’s mainframe systems. Given the very real challenge of mainframe batch
jobs approaching or exceeding the limits of available batch windows, this benchmark
proves that companies now have a choice outside of expensive mainframe upgrades.
This paper details how the benchmark was performed and more importantly, how
this technology can reduce costs and speed batch processing.
Why the NeoSort World Record is Good News for Mainframe Users
2
Table of Contents
Introduction.......................................................................................................... 4
Significance .......................................................................................................... 4
What Was Tested .................................................................................................. 5
Test Location ........................................................................................................ 6
How the MinuteSort Test is Administered ............................................................... 6
Hardware Highlights .............................................................................................. 7
Software Description ............................................................................................. 7
Right Combination of Hardware and Software Key to Benchmark Results ........... 8
Inhibitors to High-Performance Sort on the Mainframe ............................................ 9
Creating Your Own High-Speed Sort Engine .......................................................... 10
Conclusions ........................................................................................................ 11
Appendix A. JCL Used to Execute the Sort ............................................................ 12
Appendix B. Message Log from Record-Breaking Run ............................................ 13
Appendix C. Checking the Data Input and Output ................................................. 14
Appendix D. Hardware Specifications and Firmware Levels .................................... 15
Server .......................................................................................................... 15
Host Bus Adapters (HBA) ............................................................................... 15
Server/Storage Connection ............................................................................ 15
Storage Subsystems ...................................................................................... 15
Why the NeoSort World Record is Good News for Mainframe Users
3
Introduction
It may be tempting to think that because today’s databases efficiently support huge
amounts of data the importance of batch sort operations may be in decline.
However, that is not the case. In the DFSORT Tuning Guide,1 published in 2004, IBM
states:
The tuning of DFSORT and the way applications use it is important because
sorting and copying are two of the most frequently used functions at z/OS sites.
DFSORT applications typically consume from 10 to 25 percent of the total
processor resources and 15 to 30 percent of the total I/O channel resources.
Trevor Kingsbury, writing in an earlier tuning guide in 2001,2 also published by IBM,
partly explains why this is the case:
While RDBMS on either MVS or UNIX remains the permanent data storage
platform of choice, much of this data must be extracted, processed, transformed
and loaded using traditional MVS batch processing. Sorting and merging of data,
using DFSORT under MVS, endures as a key component of this batch processing.
In other words, long-term data storage will occur in a relational database
management system (RDBMS). However, many processes, including loading the
databases, will require batch sorts.
Given this evidence, it is imperative that information services (IS) departments that
store large amounts of data keep an eye on advances in sorting technology. By
utilizing the latest innovations in sort processing, companies can:

Reduce the time required for batch windows

Ease the pressure on cramped batch windows

Free up mainframe CPU cycles

Slash expenses
This paper considers one recent development in the sort arena: the ability to migrate
existing JCL-driven sort processes to commodity hardware running the Microsoft®
Windows Server® 2003 operating system to produce world record–breaking
performance, as demonstrated by Fujitsu and Ordinal Technology. This paper
describes how this performance was obtained, why it was possible using a Windows
Server–based system, why it is unlikely to be challenged by mainframe
configurations, and why the results are worthy of serious consideration by
organizations with large or challenging sort workloads.
Significance
As an example of why this type of record-setting result is noteworthy, consider the
situation of a company with a large mainframe system. The company had a large
customer list that needed to be updated and sorted regularly. The challenge was that
1
“DFSORT Tuning Guide.” IBM. 2004.
http://publibz.boulder.ibm.com/epubs/pdf/ice1ct00.pdf
2
Kingsbury, Trevor. “Recommendations for Tuning Large DFSORT Tasks.” IBM. 2001.
http://www-03.ibm.com/servers/storage/support/software/sort/mvs/tuning/pdf/srtmltun.pdf
Why the NeoSort World Record is Good News for Mainframe Users
4
the file was larger than 65 gigabytes (GB) and the sort ran for more than 10 hours
on the mainframe. This time frame was longer than the daily batch window, and
Saturday night was the only time when a longer batch window was available to run
the sort. Although run less frequently than desired, the weekly schedule might have
worked if the mainframe system had not required a scheduled IPL every Saturday
night, as many such systems require. Thus, the Saturday night window for running
the sort process was halved, and neither half was long enough to finish the sort job.
If this company’s system were capable of sorting 40 GB of information in under a
minute, or even in 10 minutes or an hour, the company would not have encountered
this roadblock to conducting routine operations—or it would have been able to
circumvent the problem quickly.
Not every company will have this kind of challenging issue to resolve with sort
processes, but with 10 to 25 percent of processor resources consumed by sort
applications and the volume of data to be processed increasing daily, it is vital for IS
managers to understand how to achieve faster sort times and to investigate whether
new technology can be applied to their operations.
Because the record-breaking results reported in this paper were achieved on
commodity hardware running the Windows Server operating system, which typically
costs a tenth of the comparable mainframe system, it may also be worth considering
whether significant costs can be saved.
What Was Tested
The MinuteSort sorting benchmark is described in papers available on the Sort
Benchmark Page at http://research.microsoft.com/barc/SortBenchmark/. Lists of
current and past best results are also maintained on this site.
The test requires a sorting program to:

Read a file that contains 100-byte records, where the first 10 bytes of each
record contain a random key

Sort the records based on the random key

Create a new output file

Write the sorted data to the output file on disk
The goal is to sort as many records as possible in one minute. The clock starts when
the sort program is invoked. Within the one-minute time frame, the sort program
must finish the sort, write the output file, and return to the caller.
For the current test, random keys and record data were generated using the
Generate.exe program created by Ordinal Technology and used in past MinuteSort
record-breaking runs.
To determine the size of the input file, Ordinal engineers calculated the bandwidth
likely to be achieved with the selected hardware configuration and determined that a
file in the range of 40 GB could be sorted within one minute. The calculations were
accurate: test completion times under one minute and time overruns of files larger
than 41 GB confirmed the file size.
The data was sorted using NeoSort invoked from a specially written test harness that
accurately timed the sort invocation and control return. Apart from the test harness,
the invocation looked like a standard DFSORT step written in JCL (see Appendix A).
The Fujitsu NeoBatch Job Manager ran the JCL.
Why the NeoSort World Record is Good News for Mainframe Users
5
Test Location
The benchmark tests occurred at the Fujitsu North American TRIOLE Integration
Center using hardware made available by Fujitsu Computer Systems (described in
“Hardware Highlights” and in Appendix D later in this paper).
The TRIOLE Integration Center, located in Sunnyvale, California, is a facility available
to Fujitsu customers and prospective customers who want to test the performance of
their own applications and data running on Fujitsu hardware and software.
How the MinuteSort Test is Administered
The Sort Benchmark Page run by ACM Turing Award winner Jim Gray sets the
ground rules for the sort tests. The “Ground rules” section of the Web site states:

Must sort to and from operating system files on secondary storage.

No raw disk benchmarks allowed since we are trying to test the IO
subsystem.

File or device striping (RAID 0) are allowed (encouraged) to get bandwidth.

The output file must be created as part of the sort.

Time includes the launching of the sort program.
The Benchmark Page FAQ includes additional details and guidelines along with
source code for the data-generating and checking programs to be used.
Once a year, an award is given. The Benchmark Page describes this process:

Trophies are awarded each year at ACM SIGMOD.

Entrants can contact any previous winner and get their result "certified" by
April 1.

Entries must include a document describing the algorithm and the hardware
in enough detail so that others could reproduce the result.
The 40-GB NeoSort record was audited by Chris Nyberg, representing Ordinal
Technology, the last winner of the Daytona Minute Sort benchmark award (2004).
Jim Gray confirmed that 40 GB is the fastest sort for the Minute Sort benchmark to
date in the commercial category.
Why the NeoSort World Record is Good News for Mainframe Users
6
Hardware Highlights
Figure 1. Diagram of hardware used for the benchmark test
Key features of the hardware configuration that supported the high performance
sort:

The design of the PRIMEQUEST computers, in which motherboards connect to a
common memory and I/O system interconnect that allows all processors to
access the same memory and allows any device on the system (such as a Fibre
Channel card and Ethernet network) to be accessed by any process running on
any processor.

Fibre channel host bus adapters allowed high volumes of data to move between
memory and the disks.

ETERNUS3000 disk arrays accepted and retrieved data at the rates provided by
the host bus adapters.
Software Description
NeoSort, based on Ordinal Technology’s Nsort, was the core software product
employed in the MinuteSort benchmark run. NeoSort works with NeoBatch to process
sort steps in mainframe JCL batch jobs.
This was supported by the following system software:

Microsoft Windows Server 2003 Datacenter Edition for Itanium-based Systems
Why the NeoSort World Record is Good News for Mainframe Users
7

NTFS

Veritas Volume Manager (VxVM)—employed to stripe the 32 disks in the RAID
array

NeoBatch—processed the JCL that defined and invoked the sort operation
Right Combination of Hardware and Software Key to
Benchmark Results
It is not enough to just run sort software on higher-speed processors. To achieve the
results outlined in this paper, the software must take full advantage of the parallel
processors, I/O channels, and shared memory. This requires a sophisticated design
effort with special attention paid to how tasks can be shared between processors and
how I/O can be driven at the rates available.
This understanding is built into the Nsort technology that is at the core of NeoSort.
Nsort shares some of the goals of mainframe sort programs, such as:

Minimizing key comparisons

Fast key comparisons

Fast file I/O
However, mainframe sorts are generally limited (by either practical or financial
constraints as explained in the next section) to utilizing a single processor, a few
disks, and 32-bit memory addressing.
Nsort is designed to utilize the power of large, modern systems during a single sort
job. As such, it has these additional design goals:

Minimizing processor cache misses. Modern processors rely on caches
to gain quick access to frequently used data. Caches are small, fast
memories either on the processor or between the processor and the main
memory. When a processor's read/write request cannot be found in the
cache, the processor must access that information from the slower main
memory system. Without careful programming, these wait cycles can vastly
outnumber the time spent to execute instructions such as key comparisons.
The NeoSort data reference pattern is arranged to minimize cache misses so
that the processors stay busy doing useful work and overall CPU use is
reduced.

Utilizing large numbers of processors. During the MinuteSort
benchmark run, NeoSort employed an average of 21 processors to read the
input file and sort portions of the records, and then an average of 25
processors to merge the records and write them to the output file.

Employing large numbers of disks for fast file I/O. During the
MinuteSort benchmark run, NeoSort read the input file at 2.6 gigabytes per
second and wrote the output file at 1.2 gigabytes per second. These speeds
were possible due to NeoSort’s sophisticated I/O architecture: Using large
asynchronous unbuffered I/O requests, NeoSort harnessed the aggregate
speed and capabilities of 128 disks, 4 ETERNUS3000 storage systems, 16
fibre channel adaptors, the PRIMEQUEST server memory bandwidth, the
Veritas VxVM volume, and the NTFS file system.

Using large memories. For the MinuteSort benchmark run, NeoSort used
45 gigabytes of main memory to hold the entire data set. Because temporary
Why the NeoSort World Record is Good News for Mainframe Users
8
(or work) files were not necessary, all available disk bandwidth could be
used for the sort input and output files. (Large amounts of memory are not
required for NeoSort to perform well, assuming a set of work disks with
sufficient bandwidth is available.)
Windows Server 2003 for Itanium-based systems is the platform for running this
high-powered program, and NeoBatch with NeoSort provides a bridge for the
majority of today’s batch sort jobs, from IBM mainframes to the optimum platform
used for the MinuteSort benchmark.
With NeoSort, a 40-GB sort in one minute was possible because of hardware
performance characteristics:

The PRIMEQUEST server architecture provides high bandwidth from all of the
processors to the disks, which allows the sort tasks to be distributed across the
processors to help increase the I/O speeds.

The ETERNUS3000 storage systems support this high-bandwidth architecture by
distributing the sort work files across many disks.

The PRIMEQUEST server supports very large amounts of memory that can be
shared across processors, which allows much of the sorting to be done in
memory.
Inhibitors to High-Performance Sort on the Mainframe
Mainframes have several limitations that keep them from matching the results
described earlier. Before delving deeper, here is a review of the key elements that
made this record-breaking sort possible:

Multiple processors

Multiple disks

High bandwidth between processors and disks

Large amounts of memory

Software that can take advantage of all the above
For all of the hardware elements listed above, hardware for the mainframe costs
several times more than equivalent hardware for the Windows Server operating
system. The difference in cost is partly historical, but it also is due to the more
complex infrastructure that has developed for mainframes.
Due to the high costs associated with mainframe environments, companies do not
necessarily have the option of adding more hardware to solve the problem of finding
batch windows long enough to run large sorts. Instead, companies must try to
manage system resources to optimize sorts without compromising the performance
of other applications. This practice leads to a series of tradeoffs in processor load,
paging activity, I/O activity, disk utilization, and elapsed time.
Ways to improve mainframe sort performance include DFSORT features such as:

Hipersorting, which uses Hiperspaces for sorting. Hiperspaces use expanded or
central storage and can significantly speed up a sort process. However,
Hipersorting uses a lot of CPU bandwidth, and the increased paging results in a
total reduction of system performance.
Why the NeoSort World Record is Good News for Mainframe Users
9

Dataspace sorting allows sorting to occur completely within main storage, and
thus eliminates the need to write intermediate data to disk. The limitation of this
method is that a dataspace size limit is usually about 2 GB, which precludes the
sorting of large files. This method also incurs a large paging expense.

Cache Fast Write allows data to be read and written to and from work data sets
at cache speed.

Sequential disk striping can also improve elapsed time performance.
Of course, building the hardware infrastructure is only part of the task; the other part
is building the sorting application. DFSORT cannot take advantage of parallel
processors, which limits its ability to scale to the levels of a Windows Server–based
solution. Hardware that supports Windows Server and the Windows Server software
architecture have evolved together so that sorting across multiple processors can be
readily achieved.
In summary, achieving record-breaking performance from mainframes is unlikely
because of:

Expense

The effort involved

Systems architecture limitations

Sort utilities limited to single processors
Creating Your Own High-Speed Sort Engine
You may not need to sort 40 GB in a minute, but if you are experiencing batch
window challenges or can see that challenges will happen if your data continues to
grow at current rates, you may be interested in finding out what it would take to
achieve results in a time frame anywhere within an order of magnitude of the record
time.
The company in the example described earlier in this paper needed more than 10
hours to sort 60 GB of data. That is a rate of about 0.1 GB per minute.
Using products such as NeoSort and Fujitsu hardware, it should be clear that exciting
improvements on that kind of performance are well within reach—whether 1 GB per
minute (a tenfold improvement), 10 GB per minute (a hundredfold improvement) or
40 GB per minute (a four-hundredfold improvement). These levels of improvements
can present significant new opportunities for organizations, and they are worthy of
serious consideration.
If you would like to see what it would take to improve your batch processing
performance while reducing costs, you can take advantage of capacity planning and
testing services such as those provided by Microsoft, Fujitsu, and others.
To utilize the platform outlined in this document:

Contact Fujitsu’s COBOL group at COBOL@NetCOBOL.com with details of your
sort tasks and ask for a quick, cost/time estimation. Provide the following details
for up to 10 files:
-
File size
-
Record size
-
Sort keys (type and length)
Why the NeoSort World Record is Good News for Mainframe Users
10
-
Current elapsed time
Fujitsu’s COBOL group will give you low, medium, and high suggested
configurations with estimated times for the sort operations.

If you would like to validate the estimates, you can visit the TRIOLE Integration
Center to run tests on your data using the configuration that you think will best
meet your needs.

Fujitsu also provides services to help you plan for the implementation of NeoSort
and the integration of data from your mainframe systems.
Conclusions
The latest developments in multiprocessor, multiple-disk, and high I/O bandwidth
architectures—as demonstrated in the Fujitsu PRIMEQUEST and ETERNUS3000
setups—when combined with software designed to take advantage of these
architectures, improve the likelihood that many organizations can achieve
hundredfold speed improvements in sort operations.
Enterprise companies seeking to dramatically reduce batch job execution times and
free up precious host CPU cycles would be well served by off-loading all or some sort
jobs from their mainframe.
Why the NeoSort World Record is Good News for Mainframe Users
11
Appendix A. JCL Used to Execute the Sort
Figure 2 shows the JCL executed by NeoBatch to run the test sort. TIMEX is the test
harness program that invoked NeoSort and wrote the timing results (shown in
Appendix B).
//SORT1 JOB 62341,'K.Hollis',MSGCLASS=X,CLASS=C,
//
REGION=4M,NOTIFY=Administrator,RESTART=*
//*
//* Del files
//*
//DEL
EXEC PGM=IDCAMS
//SYSIN DD *
DELETE SORT.OUT
SET MAXCC=0
//*
//SYSPRINT DD SYSOUT=*
//*
//* Sort the big file
//*
//STP1
EXEC PGM=TIMEX,PARM='SORT'
//SORTIN DD DSN=BIG.40G,DISP=SHR
//SORTOUT DD DSN=SORT.OUT,DISP=(,CATLG,DELETE),
//
DCB=(LRECL=100,RECFM=FB),VOL=SER=BIG
//SYSIN DD *
SORT FIELDS=(1,10,CH,A)
//SYSOUT DD SYSOUT=*
Figure 2. JCL used in NeoSort record-breaking test
Why the NeoSort World Record is Good News for Mainframe Users
12
Appendix B. Message Log from Record-Breaking Run
Figure 3 shows the message log output from one of the record-breaking test
executions.
The lines marked with E were written by the TIMEX program and provide:

ExitCode—Zero indicates the operation terminated successfully.

Elapsed Time—The time between the invocation of the sort operation to
receiving the return from the call.

Kernel Time—The amount of CPU time, across all processors, spent in the
operating system (Windows Server).

User Time—The time spent running the sort on all of the processors added
together.
The sort input file was called BIG.40G and was generated by Ordinal Technology’s
Generate.exe program.
The sort output file was called SORT.OUT.
The results of checking the input and output files are shown in Appendix C.
M S G L O G -- S Y S T E M
F C S 2 - P 0
JOB NAME: SORT1
JOB ID:
34
JCL: c:\NeoBatch\ProductDir\SYSOUT\Administrator\SORT1\34\JCL.jcl
JS: c:\NeoBatch\ProductDir\SYSOUT\Administrator\SORT1\34\JSCRIPT.js
-------------------------------------------------------------------------------00034: Starting step DEL.
00034: Executable: c:\neobatch\productdir\IDCAMS.EXE
00034:
DELETED: (SYSIN)SYS06038.T133934.RA000034.SORT1.R0100001
00034: Completed step DEL, RC=0
00034: Starting step STP1.
00034: Number of data directories is 0
00034: Executable: c:\neobatch\productdir\TIMEX.EXE
00034E: ExitCode: 0
00034E: Elapsed Time:
58.790
00034E: Kernel Time :
18.300
00034E: User Time
:
1296.930
00034:
DELETED: (SYSIN)SYS06038.T133937.RA000034.SORT1.R0100003
00034:
KEPT:
(SORTIN)BIG.40G
00034:
CATLGD: (SORTOUT)SORT.OUT
00034: Completed step STP1, RC=0
Job 34 Completed. Job exit code: 0
Figure 3. Message log from the NeoSort record-breaking test
Why the NeoSort World Record is Good News for Mainframe Users
13
Appendix C. Checking the Data Input and Output
The Chk.exe program, developed by Ordinal Technology, was used to verify the
correct order of records in the NeoSort output. Chk was run twice after the execution
of the sort: once on the output file and once on the input file.
The command line inputs for Chk are: the name of a file containing parameters that
define the record length, field characteristics, and key specification; and the name of
the file to be analyzed.
Chk outputs:
1. The number of records (the number after “Check”).
2. The number of records that are different (the number after “distinct”).
3. If the records are not in order, the program generates the number of unordered
records (which should be about half the records for the keys generated by
Generate.exe). If all records are in order, it will not print a line that reads: “Total
of nnnn unordered records…”
4. Checksums generated from the records read. These should be the same for input
and output files.
Output from the Chk program is shown in Figure 4, and the file containing the
input/output file specifications is shown in Figure 5.
Note: NeoBatch puts cataloged files in a folder specified for the data set name and it
appends an extension that relates to the file type, such as .seq for sequential files.
Thus the SORT.OUT file shown in the message log (Figure 3) is stored as
f:\SORT\out.seq. Because it was created outside of NeoBatch, the input file BIG.40G
was mapped directly in the NeoBatch catalog to the file on disk: f:\40g.dat.
C:\chris>chk -spec:f100.spec f:\SORT\out.seq
Check 400,000,000 distinct 400000000
Checksums: ed2168a3 f3b5624e
C:\chris>chk -spec:f100.spec f:\40g.dat
Check 400,000,000 distinct 400000000
Total of 199997193 unordered records out of 400000000
Checksums: ed2168a3 f3b5624e
Figure 4. Output from the Chk program
-format:size=100
-field:k1,char,size=10,remainder,char,size=90
-key:k1
Figure 5. The contents of the f100.spec file specify the format of the files
processed by the Chk program
Why the NeoSort World Record is Good News for Mainframe Users
14
Appendix D. Hardware Specifications and Firmware Levels
Below are the hardware specifications and firmware levels provided by the Fujitsu
Computer Systems team that set up the testing environment for the NeoSort recordbreaking run.
Server
A. 1 x PRIMEQUEST 480 Server
32 x Intel Itanium2 1.6 GHz
Memory: 127 GB
FUJITSU SAL_B Version 1.11, 12/6/2005
SMBIOS Version 2.3
HAL Version 5.2.3790.1830 (srv03_sp1rtm.050324-1447)
B. Microsoft Windows Server 2003
Datacenter Edition for Itanium-based Systems
Service Pack 1
Build 3790
C. VERITAS Storage Foundation and High Availability Version 4.3
Windows 2000, Windows Server 2003
Host Bus Adapters (HBA)
A. 16 x Emulex LP10000 (2
Driver
Firmware
Driver name
Hardware version
Boot Bios
Gbps) Fibre Channel HBAs
: 6-1.10X1; HBAAPI V2.2b, 02-17-05
: 1.91A1
: elxstor
: 1001206D
: 1.41a4
Server/Storage Connection
A. 16 x Direct (FC-AL) connections; 4 x connection per ETERNUS3000 storage
system and PRIMEQUEST server
Storage Subsystems
A. 3 x ETERNUS3000 Model 700 (4 Gbps Host Interface)
1 x ETERNUS3000 Model 600 (2 Gbps Host Interface)
128 Disks in the storage array made up of
50 x 73 GB disks
78 x 146 GB disks
These disks were arranged in RAID groups, 4 disks per RAID group with each group
constituting a 4 GB logical unit (LUN)—only 1 GB was used on each disk. Each
ETERNUS3000 had 8 such RAID groups, so there were a total of 32 RAID groups.
These were combined by the VERITAS system (described below) into a single 124.8
GB RAID0 volume, so that the software treated it as a single large drive.
ETERNUS3000 Configuration
Firmware (EC2) - V20L30-0000
2 x Cache Managers (CM) or Controllers
Why the NeoSort World Record is Good News for Mainframe Users
15
Memory: 8 GB per CM; 16 GB total
Memory Reserved for CM: 1 GB; 2 GB total
2 x Channel Adapters (CA); 2 x ports per CA (BMT configuration)
8 x Channel Adapters (CA); 2 x ports per CA (Maximum)
4 x Device Adapters (DA); 4 x ports per DA (BMT configuration)
8 x Device Adapters (DA); 4 x ports per DA (Maximum)
8 x Disk Enclosures (DE); 15 x SEAGATE/FUJITSU Drives per DE
16 x Disk Enclosures (DE) (Maximum)
-
-
Specifications of Seagate ST373453FC Drives
Capacity
: 73 GB
Interface Type
: FC-AL
Data Transfer Rate : 200 MB/s
Average Seek Time : 3.6 ms (Read)
Spindle Speed
: 15,000 rpm
Buffer Size
: 8 MB
Revision
: 4F1F
Specifications of Seagate ST3146854FC Drives
Capacity
: 146 GB
Interface Type
: FC-AL
Data Transfer Rate : 200 MB/s
Average Seek Time : 3.6 ms (Read)
Spindle Speed
: 10,000 rpm
Buffer Size
: 8 MB
Revision
: 4F0B
B. 1 x VERITAS VxVM volume
Capacity
: 124.80 GB
Layout
: Striped
Stripe width
: 512 KB
File System
: NTFS
Why the NeoSort World Record is Good News for Mainframe Users
16
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed
as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted
to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented
after the date of publication.
This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN
THIS
DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright,
no part of this document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form
or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express
written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering
subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the
furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual
property.
© 2006 Microsoft Corporation. All rights reserved.
Microsoft and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United
States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Why the NeoSort World Record is Good News for Mainframe Users
17