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