HP3000-L Archives

August 1997, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Duane Percox <[log in to unmask]>
Reply To:
Duane Percox <[log in to unmask]>
Date:
Tue, 19 Aug 1997 09:31:03 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (78 lines)
Glenn and Jerry debate some nm cobol sort issues:

>>>> Does anyone know what the maximum numbers of records is for an
>>>> internal COBOL sort?
>
>>>10,000 is the default maximum. Two ways to increase this. First, via
>>>ASSIGN, as in ASSIGN SORT-FILE TO WORKFILE,,,,50000. Second, and
>>>preferred, issue a :FILE for WORKFILE, as in :FILE WORKFILE;DISC=50000.
>>>Further info is in the SORT/MERGE section of the COBOL II/XL manual,
>>>under "Sorting Large Files".
>
>> If Native Mode COBOL is used, it will utilize SORT/XL.  SORT/XL uses
>> 2 unnamed scratch files and as such, one cannot issue a file equation
>> for them.
>
>Holy moly, Jerry! That strikes me as a heck of an incompatibility.
>I wonder why I haven't heard in the last -- what is it? -- TEN YEARS
>that the :FILE equation method no longer works. But wait a sec...
>
>> In terms of the maximum number of records SORT/XL can handle one has
>> to use the basic formula used by sort for building these files which
>> is outlined in the manual.
>
>"can handle." Does that mean even without any indication that more
>than 10,000 recs are to be sorted? So issuing a :FILE equation just
>doesn't have any effect as far as max recs goes?
>
>So it's not so much an incompatibility as it is an ineffective command.
>
>> It uses the size and type of the sort key,
>> the size of the entire record and some control bytes to calculate the
>> size of the unnamed 2 scratch files.
>
>So, the max recs on the SELECT...ASSIGN has no meaning. For that
>matter, even the *filename* on the ASSIGN has no meaning!
>
>I'll be darned. Learn something new every day. :)

I have to respectfully respond that this information is not
entirely accurate. Remember, cobol is calling hpsortinit, etc
to get the sort accomplished. One of the parms to hpsortinit
is the number of records to sort (32 bit integer) when not sorting
a file directly (using cobol release/return mechanism).

If you have a nm cobol program with these constructs:

1. select sort-file assign to "tmsort".

2. sort sort-file on ascending key ...
    input procedure is ....
    output procedure is ...

You will get a temp file called 'tmsort' and it will be as large
as you have defined it through your file equation.

If you make the file too small (or you don't have a file equation
and the # of records > 10000) you get this error:

There are too many input records.
HPSORT message 16
Internal SORT/MERGE error $FFF000C3 (COBERR 500)
Program file: LO0100.PRNPPC.PSISCH
**** COB_QUIT 500 ****

ABORT: LO0100.PRNPPC.PSISCH
NM SYS   a.00990180 dbg_abort_trace+$24
NM USER  145.00126f18 COB_QUIT+$b8
NM PROG  661.00006c30 lo0100+$550

PROGRAM TERMINATED IN AN ERROR STATE.  (CIERR 976)

If you sort with 'using/giving' then sort/xl uses the file label
information to determine how big to make the scratch file.

Duane Percox ([log in to unmask]  v/650.306.1608 f/650.365.2706)
http://www.qss.com/          http://qwebs.qss.com/qwebs
http://qwebs.qss.com/faq3k

ATOM RSS1 RSS2