Что не так с моей функцией SORT здесь?

Во-первых, я полный новичок во всем, что связано с мэйнфреймами.

У меня есть учебное задание на работе, чтобы найти совпадающие ключи в двух файлах с помощью SORT. Я отправил этот код своему наставнику, псевдокод здесь, потому что я еще не могу получить доступ к системе из дома и не подумал скопировать его перед отъездом:

//STEP01 EXEC SORT
//SORTIN DD DSN=file1
//       DD DSN=file2
//SORTXSUM DD DSN=output file
//SORTOUT  don't need this data anywhere specific so just tossing at spool
//SYSIN DD *
  SORT FIELDS=(1,22,CH,A)
  SUM FIELDS=NONE,XSUM
/*

Когда я вставляю пару случайных последовательных файлов, результат именно такой, как я ожидаю. Однако мой наставник говорит, что это не работает. Его английский довольно плохой, и я редко понимаю, что он говорит в первые несколько раз, когда он это повторяет.

Это в сочетании с тем, что он упомянул JOINKEYS (конечно, перед тем, как уйти с работы), заставляет меня думать, что он просто хочет (нужно?), чтобы это было сделано по-другому, и очень плохо справляется с выражением этого.

В любом случае, может ли кто-нибудь сказать мне, является ли код, который я написал, отстойным, и объяснить, почему он явно не соответствует методу, использующему JOINKEYS?


mainframe jcl syncsort
person Caitlin    schedule 03.03.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вот требование, которое удовлетворило бы:

Возьмите два несортированных набора данных; сопоставить их по 22-байтовому ключу; вывод всех данных в один из двух файлов. Если ключи дублируются, выберите запись совпадающей группы, которая вам удобна, и нельзя гарантировать, что выборка будет воссоздана при последующем запуске, и запишите ее в выходной файл; вместо этого записывать все записи, не записанные в первый файл, во второй файл.

Если это требование, вы на пути к победителю, так как он будет работать лучше, чем эквивалентный JOINKEYS.

Решение также можно изменить несколькими способами. С OPTION EQUALS или EQUALS в операторе SORT всегда будет сохраняться первая запись равных ключей.

Для большей гибкости в отношении того, что сохраняется, вместо SUM можно использовать DUPKEYS.

Если требование может быть удовлетворено с помощью SUM или DUPKEYS, их использование более эффективно, чем использование JOINKEYS.

Если данные уже в последовательности, но в остальном требования одинаковы, то это не лучший способ сделать это. Вы можете попробовать MERGE вместо SORT и использовать SORTIN01 вместо SORTIN.

Если бы у вас был DFSORT вместо SyncSORT, вы могли бы использовать оператор SELECT ICETOOL, чтобы делать все, что могут XSUM и DUPKEYS (и многое другое).

Если вы делаете что-то большее, чем могут SUM и DUPKEYS, вам понадобится JOINKEYS.

Например, если данные уже находятся в последовательности, вы должны указать SORTED в JOINKEYS для этого ввода.

На мейнфрейме ресурсы оплачиваются клиентом. Поэтому мы стремимся избежать расточительности. Если один из способов использует меньше ресурсов, мы выбираем его.

Не зная ваших точных требований, нельзя сказать, является ли ваше решение лучшим :-)

person Bill Woodger    schedule 03.03.2015