DFSORT дает SB37 неоднократно

Когда я сортирую файл переменной длины, задание неоднократно завершается с SB37. Даже когда я увеличил значения параметров SPACE, работа все еще не завершена.

Может кто-нибудь, пожалуйста, помогите мне узнать, что может быть причиной этого..?

Ниже JCL, я пытался.

//STEP01   EXEC PGM=SORT
//SORTIN    DD DSN=<Input DSN>,DISP=SHR   [the i/p DSN created with SPACE=(CYL,(1200,120),RLSE) ]
//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
//             DCB=(RECFM=V,LRECL=32756,DSORG=PS)
//SYSIN     DD *
  SORT FIELDS=(1,15,CH,A)
  SUM FIELDS=NONE
/*
//SYSOUT    DD  SYSOUT=*
Источник

4 ответа

Решение

Поскольку вы намерены избавиться от конечных пробелов и иметь дело только с максимальной длиной данных 246, вы должны делать все это в SORT.

//STEP01   EXEC PGM=SORT
//SORTIN    DD DSN=<Input DSN>,DISP=SHR
//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(1200,120),RLSE)
//SYSIN     DD *
  INREC BUILD=(1,4,5,246)
  SORT FIELDS=(5,246,CH,A)
  SUM FIELDS=NONE
  OUTFIL VLTRIM=C' '
//SYSOUT    DD  SYSOUT=*

Обратите внимание, что я удалил информацию DCB из SORTOUT. SORT позаботится об этом, и вы запутаете и увеличите техническое обслуживание, включив его в SORTOUT (или любой DD из OUTFIL) в шаг SORT.

В INREC новая запись создается на входе длиной 250 байт (четыре байта RDW и 246 байт данных). RDW и данные упоминаются отдельно, поэтому следующему человеку ясно, что вы знаете, что делаете (и, возможно, вам действительно нужно 250 байтов данных?).

Таким образом, все данные, которые вам не нужны, не попадают в саму SORT, что значительно снижает ваши требования к рабочему пространству, сокращает время ЦП и затраченное время.

Если ваши данные не имеют фактического ключа (в позиции 5 на длину 11), вы можете рассматривать неповторяющиеся данные как дубликаты. Если у вас нет ключа, теперь сортировка сортируется по данным. Больше нет даже необходимости удаленной сортировки в RDW, так как все RDW будут содержать длину записи 250 (в двоичном виде) в первых двух байтах из-за BUILD на INREC.

SUM FIELDS=NONE теперь будет дублировать 246 байтов данных.

В OUTFIL, VLTRIM=C' ' используется для удаления любых оставшихся пробелов

Будучи обеспокоен тем, что вы не уверены в своих реальных длинах записей, я бы запустил что-то вроде этого:

  INREC BUILD=(1,4,1,2) 

  SORT FIELDS=(5,2,BI,A) 

  OUTREC OVERLAY=(5:5,2,BI,EDIT=(IIIIT),10:18X)

  OUTFIL NODETAIL, 
         REMOVECC, 
         HEADER2=('RECLENS PRESENT ON FILE'), 
         SECTIONS=(5,5, 
             TRAILER3=(5,5)), 
         TRAILER1=('MIN/MAX ', 
             MIN=(5,5,ZD,EDIT=(IIIIT)), 
             ' ', 
             MAX=(5,5,ZD,EDIT=(IIIIT)))

Это создаст простой файл, показывающий вам всю вашу длину записи и показывающий минимальное / максимальное значения на последней странице.

INREC используется для создания записей, содержащих только (двоичную) длину записи. Затем они сортируются. OUTREC увеличивает двоичную длину записи до пяти печатаемых цифр с подавлением начальных нулей. Используются функции отчетности OUTFIL: подробные строки подавляются, коды управления печатью не включаются, заголовок печатается вверху каждой "страницы", устанавливается разрыв управления для длины отформатированной записи, а длина записи - печатается, когда происходит перерыв. В конце минимальные и максимальные значения печатаются.

Если вы создадите вход для этого с шагом SORT, состоящим из этого:

ВАРИАНТ КОПИРОВАНИЯ OUTFIL VLTRIM=C' '

Затем вы получите отчет о длине записи вашего файла после того, как завершающие пробелы будут проигнорированы, и вы можете быть уверены (для этого примера данных), что то, что вы знаете о спецификации, соответствует данным.

Источник

Попробуйте следующее: SB37 может быть из-за того, что рабочие файлы сортировки не получают достаточно места при динамическом распределении.

/STEP01   EXEC PGM=SORT
//SORTIN    DD DSN=<Input DSN>,DISP=SHR   [the i/p DSN created with SPACE=(CYL,(1200,120),RLSE) ]
//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
//             DCB=(RECFM=V,LRECL=32756,DSORG=PS)
//SORTWK01 DD  UNIT=SYSDA,SPACE=(CYL,(500,10))
//SORTWK02 DD  UNIT=SYSDA,SPACE=(CYL,(500,10))
//SORTWK03 DD  UNIT=SYSDA,SPACE=(CYL,(500,10))
//SORTWK04 DD  UNIT=SYSDA,SPACE=(CYL,(500,10))
//SYSIN     DD *
  SORT FIELDS=(1,15,CH,A)
  SUM FIELDS=NONE
/*
//SYSOUT    DD  SYSOUT=*
Источник

Вот JCL, я модифицировал. И это работает.

Даже здесь длина записи (LRECL) входного набора данных составляет 32756.

//STEP01   EXEC PGM=SORT
//SORTIN    DD DSN=<Input DSN>,DISP=SHR   [the i/p DSN created with SPACE=(CYL,(1200,120),RLSE) ]
//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
//             DCB=(RECFM=V,LRECL=500,DSORG=PS)
//SYSIN     DD *
  SORT FIELDS=(1,15,CH,A)
  SUM FIELDS=NONE
/*
//SYSOUT    DD  SYSOUT=*
Источник

Прошло некоторое время с тех пор, как я работал на мэйнфрейме, но если память обслуживает B37, это может произойти по двум основным причинам:

1) Недостаточно места на диске для первоначального выделения

2) Недостаточно места на диске для вторичного размещения

Ваше заявление JCL:

//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
//             DCB=(RECFM=V,LRECL=32756,DSORG=PS)

Просит 1200 начальных цилиндров. Это кажется много места, попробуйте что-то вроде:

//SORTOUT   DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
//             UNIT=DISK,SPACE=(CYL,(12,240),RLSE),
//             DCB=(RECFM=V,LRECL=32756,DSORG=PS)

Это должно дать вам первичное распределение, а затем 240 цилиндров для каждого из вторичных распределений, если это необходимо.

Кроме того, посмотрите точное описание SB37, оно должно описать, когда проблема связана с отсутствием пространства для первичного распределения по сравнению с отсутствием пространства для вторичного распределения.

Источник
Другие вопросы по тегам