MSIR.0303 SORT/HASH key out of order: Difference between revisions
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=0 | Sets online return code |
---|---|
RETCODEB=0 | Sets batch (single user) return code |
CLASS=I | Information class; the message can be suppressed with the X'02' bit setting of the MSGCTL parameter |
AUDITMS | Writes the message with line type MS to the audit trail |
NOCOUNT | Does not increment the error count (ERCNT) parameter |