#mainframe #jcl
#мэйнфрейм #jcl
Вопрос:
У меня есть требование, подобное приведенному ниже.
-> У меня есть 2 входных файла FILE1 и FILE2.
-> Записать совпадающие записи в ФАЙЛ3.
-> Записать несовпадающие записи из FILE1 в FILE4.
-> Записать несовпадающие записи из FILE2 в FILE5.
Ключевая позиция в обоих входных файлах равна (1,10).
Может кто-нибудь, пожалуйста, сообщите мне КАРТОЧКУ СОРТИРОВКИ, как я могу получить это за один шаг в SyncSort??
Заранее спасибо, Раджасекхар Джанну.
Ответ №1:
JOINKEYS FILE=F1,FIELDS=(01,10,A)
JOINKEYS FILE=F2,FIELDS=(01,10,A)
UNPAIRED F1,F2 <== This results in cartesian product
REFORM FIELDS=(F1:01,10,F2:01,10),FILL=C'$'
SORT FIELDS=(01,10,CH,A)
OUTFIL FNAMES=03,
INCLUDE=(01,01,CH,NE,C'$',AND,11,01,CH,NE,C'$') <== Matched Records
OUTFIL FNAMES=04,
INCLUDE=(01,01,CH,NE,C'$',AND,11,01,CH,EQ,C'$') <== Non-Matched Records from File1
OUTFIL FNAMES=03,
INCLUDE=(01,01,CH,EQ,C'$',AND,11,01,CH,NE,C'$') <== Non-Matched Records from File2
Также обратите внимание, что из обоих файлов было учтено только 10 байт, поскольку вы не указали длину каждого файла.
Также предлагаю вам поискать известные форумы мэйнфреймов и опубликовать его здесь, если вы не получите рабочее решение. Надеюсь, это поможет
Обратитесь к этому: Руководство Joinkeys
Комментарии:
1. Привет, Раджа Анна, не могли бы вы объяснить, что такое FILL=C’$’? почему мы добавляем здесь знак ‘$’?
2. Он не добавляется, а дополняется. При сравнении двух файлов мы создаем переформатированную промежуточную запись с данными из каждого входного файла. Символы, указанные в ключевом слове FILL, будут дополнены вместо данных несогласованного входного файла. Если вам все еще не ясно, перейдите по ссылке, указанной в ответе
3. Это не приводит к «декартову произведению» (если только ключи в обоих файлах не равны). Поскольку запись ПЕРЕФОРМАТИРОВАНИЯ должна содержать данные, полученные по крайней мере из одной записи, выходные файлы можно упростить, а для совпадающих записей использовать OUTFIL,SAVE.
Ответ №2:
enter code here
//JOIN EXEC PGM=SORT
//SORTJNF1 DD *
1234567890 FILEB
1234678901 FILE1
/*
//SORTJNF2 DD *
1234567890 FILEB
1234789012 FILE2
/*
//JNF1CNTL DD DUMMY <=== not necessary(informatory)
//JNF2CNTL DD DUMMY <=== not necessary(informatory)
//BOTH DD DSN=<FILENAME>
//FILE1 DD DSN=<file name>
//FILE2 DD DSN=<file name>
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SORTOUT DD SYSOUT=* <=== we can see the JOIN output here(explanatory)
//SYSIN DD *
JOINKEYS FILE=F1,FIELDS=(1,10,A)
JOINKEYS FILE=F2,FIELDS=(1,10,A)
JOIN UNPAIRED,F1,F2
REFORMAT FIELDS=(F1:1,16,F2:1,16),FILL=C'@'
OPTION COPY
OUTFIL FNAMES=BOTH,
INCLUDE=(01,01,CH,NE,C'@',AND,17,01,CH,NE,C'@'),BUILD=(1,16)
OUTFIL FNAMES=FILE1,
INCLUDE=(01,01,CH,NE,C'@',AND,17,01,CH,EQ,C'@'),BUILD=(1,16)
OUTFIL FNAMES=FILE2,
INCLUDE=(01,01,CH,EQ,C'@',AND,17,01,CH,NE,C'@'),BUILD=(17,16)
/*
//***** this REFORMAT output would be something like
1234567890 FILEB1234567890 FILEB
1234678901 FILE1@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@1234789012 FILE2
//*********************************
FILL=C’@’ добавляет символ ‘@’ к записи, созданной операцией ОБЪЕДИНЕНИЯ, чтобы этот дополненный символ можно было использовать позже во время фильтрации с использованием INCLUDE
Комментарии:
1. Как вам удалось получить два голоса? Вам никогда не нужно подделывать файлы JNFnCNTL. Вы помещаете все выходные данные в спул. У вас есть F1, F2 в качестве комментария к ОБЪЕДИНЕНИЮ. Вам не нужно иметь отрицательные результаты тестов. Вы можете использовать СОХРАНИТЬ для файла БОТА. Ваша ОПЦИЯ COPY логически неуместна. И у вас есть два голоса? Если это было от друзей, это любезно с их стороны, но я думаю, вы рискуете применить санкции ко всем троим из вас. Лучше всего, если они просто удалят голоса. В любом случае приведите в порядок ответ. Тогда это будет лучше, чем у Raja, который получил два голоса за два года.
2. Я поместил все данные в спул здесь, поскольку я ввел только 2-2 строки ввода, и, поскольку Сехар спросил выше «почему используется ЗАПОЛНЕНИЕ», я подумал о том, чтобы показать весь вывод соединения в спуле (СОРТИРОВКА), это просто для пояснения. JNFnCNTL: опять же, здесь я просто хотел показать, что это также доступный оператор DD, который можно использовать для предварительной обработки входных файлов перед отправкой в качестве входных данных для СОРТИРОВКИ. не могли бы вы помочь мне понять, как ОПЦИЯ COPY неуместна
3. Вопрос касается SyncSort. Только обновленная версия SyncSort поддерживает JNFnCNTL. Для не совсем актуальной SyncSort доступно исправление, но до этого ничего не было доступно.
4. Раджа разобрался с комментарием. Возможно, вы не знаете, но допустимо отредактировать ответ, чтобы включить такую информацию. Вы получаете два бонусных балла, если предлагаемая правка принята.
5. ОПЦИЯ КОПИРОВАТЬ логически неуместна . Ожидается, что карта ОПЦИЙ будет использоваться в качестве первой контрольной карты. Поскольку в этом случае, при объединении, ОПЦИЯ КОПИРОВАТЬ применяется только к основной задаче, обычно ОПЦИЯ КОПИРОВАТЬ (или СОРТИРОВАТЬ ПОЛЯ = КОПИРОВАТЬ, что одно и то же) отображается в качестве первой карточки основной задачи. На самом деле это не имеет значения (во всяком случае, с DFSORT, я не знаю наверняка для SyncSort), где вы кодируете ОПЦИЮ — действия из ОПЦИИ всегда будут активированы в первой логической точке обработки. Но если вы поместите его внизу, следующий пользователь может пропустить его.