MSIR.0303 SORT/HASH key out of order: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (link repair)
(Automatically generated page update)
Line 7: Line 7:
If you can tolerate the slower speed of loading without full track I/O, use the <var>[[Fast/Reload_statements#ANYorder|OPTIONS ANYORDER]]</var> statement.
If you can tolerate the slower speed of loading without full track I/O, use the <var>[[Fast/Reload_statements#ANYorder|OPTIONS ANYORDER]]</var> statement.


{{Template:MSIR.0303 footer}}
[[Category:Sirius Mods messages]] [[Category:MSIR.0200 - MSIR.0399]]
[[Category:Sirius Mods messages]] [[Category:MSIR.0200 - MSIR.0399]]

Revision as of 16:40, 11 July 2016

This message is preceded by MSIR.0304, and it indicates that the switch was required because you were loading data to a hash or sort key file and a record was encountered out of hash or sort key order.

If you are using LAI, the ordering can be done by the HASH or SORT option of the UAI statement in Fast/Unload.

Otherwise, you should ensure that your input records are in the correct order, to obtain the full track I/O benefits of Fast/Reload. You must sort the TAPEI data set in order by the SORT key, or by the hash code of the hash key. You can do this hash key sorting using the M204HASH utility.

If you can tolerate the slower speed of loading without full track I/O, use the OPTIONS ANYORDER statement.


Message attributes:

RETCODEO=0Sets online return code
RETCODEB=0Sets batch (single user) return code
CLASS=IInformation class; the message can be suppressed with the X'02' bit setting of the MSGCTL parameter
AUDITMSWrites the message with line type MS to the audit trail
NOCOUNTDoes not increment the error count (ERCNT) parameter

Back to list of messages