SORT syntax in VMS COBOL

[Jabez]

Hi all,

We have a requirement to Sort the Array field on Ascending Order.

If some one has the syntax, please let me know. The Array will have 150000 entries in it.

Also, In IBM COBOL the internal SORTS are avoided as it consumes more of the CPU & nowadays it is not accepted as a coding standard. Using SORT in VMS COBOL, will it affect the performance of the Code? If yes, is there any other alternatives to sort the values in ascending value?

Regards,

John Jabez

[Dennis Handly]

I suppose you can implement your own sort algorithm, especially if it already is in an array vs file.

[Homer Shoemaker]

Hi John,

Just to clarify your question.  Do you want to sort an external file or do you want to sort an array that you have created in working storage and then populated from within your program?

http://h71000.www7.hp.com/doc/82final/6297/aa-q2g1h-tk.pdf

See chapter nine for the syntax, either way.

In my experience, sorting 150,000 records in an external file is not that big a deal from a resource usage perspective.  I use an Rx2660 with a hundred or more users at any one time.  Just give it a try.

If you are creating a new file, and the goal is to process the records in the sort order, I would consider setting up the file as an indexed file, and the fields that you want to sort on as keys.  Then access the file/records via the index.

[Hoff]

COBOL SORT uses the OpenVMS system sort routines, so it's fairly speedy.

A sort of 150,000 entries is a small sort and may well run largely within or entirely within process virtual memory, if the box has a reasonable configuration and process quotas are appropriately sized. 

When you get up into the billions of records, then you'll see some overhead.  Most of the overhead on a "small" sort is reading the data from storage into memory, and then writing it out, as VMS doesn't have bulk marshalling and unmarshalling; it uses RMS to process individual records, and that's slow.  As that scales upward, the disks (and RMS, to a lesser degree) increasingly becomes the problem.

Another option is to use an RMS indexed file, and 150,000 entries is a small RMS indexed file.  

Or depending on what's going on, keeping the list in sorted order, either via RMS or via an insertion sort.

In general...

• > VMS is not whichever IBM operating system you were using (and there are various IBM operating systems, and various versions), and the platforms can and often do work quite differently. 
• > Worrying about SORT performance at this stage is likely premature optimization.  Code it.  See if it's slow, within whatever constraints your application might be operating under.  (You haven't listed the hardware here, for instance.  A VAX is far slower than an Itanium, and far more resource-constrained.)  Then (if the results are slow) determine why the particular sort is slow.  Then see if Hypersort helps, for instance, or if you need a different sort scheme, or a different sorting implementation, or if you need to do the sort now or if you could maintain a sorted list.  (Sorts were a big deal back in school an eon or two ago, but now they're library calls.)
• > And a related topic...  How big is this sort going to scale to, and over what time-line?  (This is where some applications get in trouble.  Applications can be used far longer than might be expected, and can scale past what the original designs expected.  An increase from 150,000 entries to, say, a billion entries, might well point to differences in how your sort should be constructed, in what types of hardware and how your storage hardware is configured, and related details.)

 Edit: the forum software is not displaying the bulleted list, so please excuse what might be some bizarre formatting.

[Hein van den Heuvel]

Does the array itself need to become sorted, or does the program only need to process record from the array in sorted order?

HP Cobol has perfectly fine sorting build in, and it is perfectly documented between the Userguide and the Reference manual, with example program. Just read up and use it: release records, sort, return records (and process). Or if the data is already in a table, use the sort verb to sort that as Phil reminds us of in the next reply.

http://h71000.www7.hp.com/doc/82final/6297/6297pro_063.html#sort_merge_chap

Nobody here can improve that. 
Now once you've done that and have specific question and/or specific performance concerns then by all means please ask for help providing additional details.

In addition to the COBOL build-in sort, OpenVMS has a well documented, callable SORT.

You can pass it records (array elements) if they are already in memory, or pass it files.

It will stay in memory if it can, it has an extensive, powerful addition sort definition language if needed.

http://h71000.www7.hp.com/doc/83final/4493/4493pro_064.html#55_introductiontosorroutines

If the format-2 table sort does not meet your needs, then perhaps roll your own  calling a (C) routine to call Quick-sort or whatever.

To minimize data movement I would consider using the LIB$ b-tree routines:

Insert first: http://h71000.www7.hp.com/doc/82final/5932/5932pro_030.html#inser

Lookup a specific value: http://h71000.www7.hp.com/doc/82final/5932/5932pro_033.html#lookut

More likely you just want to return all: http://h71000.www7.hp.com/doc/82final/5932/5932pro_053.html#trave

Using an RMS indexed file is certainly easy to program (in Cobol) but likely to be the least performant.

It should only be consider if the data has permanent value, or if multiple orders have to be available.

IF you go that route, be sure to apply 50 - 100 areas, and opt for big buffers and opt NOT to share the file, or apply deferred write if you have to share.

Cheers,

Hein

[Phil.Howell]

SORT table-name (Format 2) will do this

SORT (Format 2) orders the elements in a table. This is especially useful for tables used with SEARCH ALL. The table elements are sorted based on the keys as specified in the OCCURS for the table unless you override them by specifying keys in the SORT statement. If no key is specified, the table elements are the SORT keys.

see http://h71000.www7.hp.com/doc/82final/6296/6296pro_082.html#index_x_771

Phil