сортировка и разбиение в DFSORT вместе? - PullRequest
Новая
       29

сортировка и разбиение в DFSORT вместе?

0 голосов
/ 12 августа 2011

Формат входного файла: От 01 до 10 - 10-значный Acct # С 53 по 01 - индикатор со значениями «Y» или «N» 71 до 10 - отметка времени (Остальные поля незначительны для этого вида)

При сортировке входного файла путем разделения и удаления дубликатов двумя способами получаются разные результаты. Я хочу знать, почему?

Кейсы: разделение и удаление дубликатов на одном шаге. 

SORT FIELDS=(01,10,CH,A,53,01,CH,A)
SUM FIELDS=NONE
OUTFIL FILES=01,                                             
INCLUDE=(53,01,CH,C'Y',AND,71,10,CH,GT,&DATE2(-)),                            
OUTFIL FILES=02,                                             
INCLUDE=(53,01,CH,C'N',AND,71,10,CH,GT,&DATE2(-)),

Caseii: разбиение и удаление дубликатов в два этапа: 

STEP:01
SORT FIELDS=(01,10,CH,A,53,01,CH,A)
SUM FIELDS=NONE

STEP:02
SORT FIELDS=COPY
OUTFIL FILES=01,                                             
INCLUDE=(53,01,CH,C'Y',AND,71,10,CH,GT,&DATE2(-)),                            
OUTFIL FILES=02,                                             
INCLUDE=(53,01,CH,C'N',AND,71,10,CH,GT,&DATE2(-)),

Эти два шага дают разные результаты. Видите ли вы разницу между обоими случаями? Пожалуйста, уточните.

Ответы [ 2 ]

3 голосов
/ 12 августа 2011

Вы просите выполнить сортировку по номеру счета (10 символов по возрастанию), а затем по показателю (1 символ по возрастанию).Только эти два поля определяют ключ записи - Метка времени не является частью ключа сортировки.Следовательно, если есть две или более записи с одинаковым ключом , они могут быть расположены в любом (случайном) порядке по сортировке.Не сообщая, в каком порядке появятся значения Timestamp .

Принимая во внимание вышесказанное, подумайте, что произойдет, если у вас есть две записи с одинаковой клавишей , но разными Метка времени значений.Одно из этих значений Timestamp соответствует заданным критериям INCLUDE , а другое - нет.Параметр SUM FIELDS = NONE запрашивает удаление дубликатов на основе клавиши .Он делает это, группируя все записи с одинаковой клавишей вместе, а затем выбирая последнюю запись в группе.Поскольку key не включает Timestamp , выбранная запись по сути является случайным событием.Следовательно, непредсказуемо, получите ли вы запись, которая соответствует последующему условию INCLUDE .

Существует несколько способов исправить это:

  • Добавить Метка времени для ключа сортировки.Это может не сработать, поскольку может оставить несколько записей для одного и того же номера учетной записи / Inidcator , то есть это может нарушить ваше требование удаления дубликатов
  • Запрос стабильной сортировки.

Стабильная сортировка приводит к тому, что записи, имеющие одинаковый ключ сортировки , сохраняют свои одинаковые относительные позиции после сортировки.Это сохранит исходный порядок значений Timestamp в вашем файле с той же клавишей .Когда произойдет удаление дубликатов, DFSORT выберет последнюю запись из набора дубликатов.Это должно обеспечить предсказуемость процесса удаления дубликатов, который вы ищете.Укажите стабильную сортировку, добавив ОПЦИИ РАВНЫЕ контрольную карту перед картой СОРТИРОВКА .

РЕДАКТИРОВАТЬ Комментарий: ... picksОЧЕНЬ ПЕРВАЯ запись

Книга, на которой я основывал свой первоначальный ответ, четко указала последнюю запись в группе записей с одним и тем же ключом, будет выбрана, когда SUM =НЕТ указано.Однако всегда лучше проконсультироваться с собственными руководствами производителей. Руководство по прикладному программированию IBM DFSORT гласит, что будет выбрана только одна запись с каждым ключом.Однако он также имеет следующее примечание:

Первый операнд оператора SELECT ICETOOL может использоваться для выполнения той же функции, что и SUM FIELDS = NONE с OPTION EQUALS.Кроме того, операнды SELECT FIRSTDUP, ALLDUPS, NODUPS, HIGHER (x), LOWER (y), EQUAL (v), LASTDUP и LAST могут использоваться для выбора записей на основе других критериев, связанных с дублирующимися и неповторяющимися ключами.Операнд SELECT DISCARD (сохраненный) можно использовать для сохранения записей, удаленных с помощью FIRST, FIRSTDUP, ALLDUPS, NODUPS, HIGHER (x), LOWER (y), EQUAL (v), LASTDUP или LAST. См. Оператор SELECT для получения полной информации об операторе SELECT.

На основании этой информации я бы предложил использовать оператор SELECT ICETOOL для выбора правильной записи.

Извините за дезинформацию.

0 голосов
/ 10 апреля 2013

Проблема как NealB идентифицирована.

Самое простое, что нужно сделать - это "избавиться" от записей, которые вам не нужны, по дате до сортировки. Сортировка займет меньше времени. Это предполагает, что SORTOUT не требуется. Если это так, вы должны оставить свой INCLUDE = в OUTFILs.

SELECT - хороший вариант. SELECT использует OPTION EQUALS по умолчанию. Приведенные ниже контрольные карты могут быть включены в набор данных xxxxCNTL, и действие из SELECT with USING (xxxx). SELECT дает вам большую гибкость, чем SUM (среди прочего, вы можете получить последнее).

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

 OPTION EQUALS

 INCLUDE COND=(71,10,CH,GT,&DATE2(-))

 SORT FIELDS=(01,10,CH,A,53,01,CH,A)

 SUM FIELDS=NONE

 OUTFIL FILES=01,                                             
      INCLUDE=(53,01,CH,EQ,C'Y')

 OUTFIL FILES=02,                                             
      INCLUDE=(53,01,CH,EQ,C'N')

Или, если Y / N охватывает все записи: 

 OUTFIL FILES=02,SAVE
...