Бра для КОБОЛА

#cobol #scons #gnucobol

Вопрос:

Я хочу создать конструктор в scons, работающий с COBOL.

Вот это и есть начало:

 import re

Import('env')

# Source:
# src/cpy/COPYBK1.cpy
# src/cpy/COPYBK2.cpy
# src/cpy/COPYBK3.cpy
# src/bat/PROG1.cbl
# src/bat/PROG2.cbl
# These commands would run:
# cobc -o lib/PROG1.so -Isrc/cpy src/cbl/PROG1.cbl
# cobc -o lib/PROG2.so -Isrc/cpy src/cbl/PROG2.cbl
#      -.
#        -SConstruct
#        -PROG1.cbl
#        -PROG1.so
#       |  -PROG1.cbl
#       |  -COPYBK1.cpy
#       |  -COPYBK2.cpy
#        -PROG2.cbl
#        -PROG2.so
#       |  -PROG2.cbl
#       |  -COPYBK1.cpy
#       |  -COPYBK3.cpy
#
# Also, PROG2 is called from PROG1 so lib/PROG2.so target should be automatically generated.
# PROG2 is dynamically loaded so it does not need to linked into PROG1 target.

"""
def getCalls(fullprogrampath):
    # This needs to be modified to support multiple lines.
    # This needs to be modified to support nested COPY.
    theregex = r'^......]s*CALLs*([A-Z0-9]*).

Это на самом деле работает

вот что нужно добавить:

  1. Кэшируйте сканирование тетрадей, чтобы мы проверяли тетради только в том случае, если файлы изменились. Scons, похоже, делает это для файлов C, так что это должно быть возможно.
  2. Обнаружение операторов вызовов и добавление целевых объектов. В С. нет аналогии с этим.
О. Как мне это сделать? B. Есть ли какие-нибудь образцы конструкторов, на которые я мог бы посмотреть, с помощью которых я мог бы смоделировать? Я признаю, что COBOL трудно сканировать и что это будет ограничено тем, насколько безумно отформатирован COBOL. разработчик COBOL должен будет добавлять Depends вызовы для своих тетрадей и операторов вызовов, которые не обнаружены.

Комментарии:

1. К вашему сведению: При работе с "вложенными" (или содержащимися) программами (COBOL 85 и более поздних версий) CALL literal будут возникать операторы. Некоторые из этих CALL утверждений будут ссылками на содержащиеся в них программы. Кроме того, CALL относится ли оператор к такой содержащейся программе, зависит от области действия содержащей программы. Все program-names они должны быть уникальными по отношению к самой внешней содержащей программе, но не обязательно должны быть уникальными по отношению к другим программам. Могут быть случаи, когда идентично закодированные CALL literal буквы s могут относиться к двум разным программам.

Ответ №1:

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

Считать...

 01  Work-Areas.
    05  Program1     PIC X(008) Value Low-Values.
        88  Name-Validate       Value 'N8675309'.
        88  Addr-Validate       Value 'A2718281'.
        88  Date-Validate       Value 'D3141592'.

[...]

    Set Addr-Validate To True
    Call Program1 Using [...]
    Set Date-Validate To True
    Call Program1 Using [...]
    Move 'X' To Program1(1:1)
    Call Program1 Using [...]
 

...и обратите внимание, что код даже не является патологическим, как это...

     Identification Division.
    Program-ID. CRAIS.
    Data Division.
    Working-Storage Section.

    01                                                              C
   -                                                                O
   -                                                                N
   -                                                                S
   -                                                                T
   -                                                                A
   -                                                                N
   -                                                                T
   -                                                               S.
        05                                                          P
   -                                                                G
   -                                                                M
                                                                    P
   -                                                                I
   -                                                                C
                                                                    X
   -                                                                (
   -                                                                8
   -                                                                )
                                                                    V
   -                                                                A
   -                                                                L
   -                                                                U
   -                                                                E
                                                                   'B
   -                                                               'R
   -                                                               'A
   -                                                               'C
   -                                                              'A'
        .
    Procedure Division.
                                                                    C
   -                                                                A
   -                                                                L
   -                                                                L
                                                                    P
   -                                                                G
   -                                                                M
                                                                    G
   -                                                                O
   -                                                                B
   -                                                                A
   -                                                                C
   -                                                                K
        .
 

Операторы КОПИРОВАНИЯ COBOL также могут быть продолжены, как и неприятный ВЫЗОВ выше.

Комментарии:

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

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

3. Две вещи, которые следует добавить к рассмотрению: вы также можете CALL программировать указатели и иметь пользовательские функции (как "именованные", так и снова с указателем функции). Что касается включения в GnuCOBOL: существует зависимость поколения ( -MT и друзей) в GnuCOBOL 1.1 - они получили удален на 2.х. Я понятия не имею, если они когда-либо работали, но было бы очень здорово, чтобы они снова работает (даже если те make связаны они могут быть легко разобраны для использования с проектов SCons). Примечание: сгенерированный список внешняя ссылка можно использовать для поиска вызовов и УСТАНОВКИ/ПЕРЕМЕЩЕНИЯ констант при вызове переменных.

calllist = []

with open(fullprogrampath, 'r') as f:
linenum = 0
for line in f.readlines():
linenum = 1
line = line.rstrip()
m = re.match(theregex, line, re.I)
if m:
calllist.append(m.group(1))

return(calllist)
"""

def getCopyBooks(fullprogrampath):
# This needs to be modified to support multiple lines.
# This needs to be modified to support nested COPY.
theregex = r'^...... s*COPYs*([A-Z0-9]*).Это на самом деле работает

вот что нужно добавить:

  1. Кэшируйте сканирование тетрадей, чтобы мы проверяли тетради только в том случае, если файлы изменились. Scons, похоже, делает это для файлов C, так что это должно быть возможно.
  2. Обнаружение операторов вызовов и добавление целевых объектов. В С. нет аналогии с этим.

О. Как мне это сделать?

B. Есть ли какие-нибудь образцы конструкторов, на которые я мог бы посмотреть, с помощью которых я мог бы смоделировать?

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

Комментарии:

1. К вашему сведению: При работе с "вложенными" (или содержащимися) программами (COBOL 85 и более поздних версий) CALL literal будут возникать операторы. Некоторые из этих CALL утверждений будут ссылками на содержащиеся в них программы. Кроме того, CALL относится ли оператор к такой содержащейся программе, зависит от области действия содержащей программы. Все program-names они должны быть уникальными по отношению к самой внешней содержащей программе, но не обязательно должны быть уникальными по отношению к другим программам. Могут быть случаи, когда идентично закодированные CALL literal буквы s могут относиться к двум разным программам.

Ответ №1:

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

Считать...


...и обратите внимание, что код даже не является патологическим, как это...


Операторы КОПИРОВАНИЯ COBOL также могут быть продолжены, как и неприятный ВЫЗОВ выше.

Комментарии:

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

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

3. Две вещи, которые следует добавить к рассмотрению: вы также можете CALL программировать указатели и иметь пользовательские функции (как "именованные", так и снова с указателем функции). Что касается включения в GnuCOBOL: существует зависимость поколения ( -MT и друзей) в GnuCOBOL 1.1 - они получили удален на 2.х. Я понятия не имею, если они когда-либо работали, но было бы очень здорово, чтобы они снова работает (даже если те make связаны они могут быть легко разобраны для использования с проектов SCons). Примечание: сгенерированный список внешняя ссылка можно использовать для поиска вызовов и УСТАНОВКИ/ПЕРЕМЕЩЕНИЯ констант при вызове переменных.

copybooklist = []

with open(fullprogrampath, 'r') as f:
linenum = 0
for line in f.readlines():
linenum = 1
line = line.rstrip()
m = re.match(theregex, line, re.I)
if m:
copybooklist.append(m.group(1))

return(copybooklist)

bld = Builder(action = 'cobc -o $TARGET -Icpy $SOURCE')
env.Append(BUILDERS = {'CobolProgram': bld})

env.CobolProgram('lib/PROG1.so', 'bat/PROG1.cbl')
env.Depends(target = 'lib/PROG1.so', dependency = getCopyBooks('bat/PROG1.cbl'))

env.CobolProgram('lib/PROG2.so', 'cbl/PROG2.cbl')
env.Depends(target = 'lib/PROG2.so', dependency = getCopyBooks('cbl/PROG2.cbl'))
Это на самом деле работает

вот что нужно добавить:

  1. Кэшируйте сканирование тетрадей, чтобы мы проверяли тетради только в том случае, если файлы изменились. Scons, похоже, делает это для файлов C, так что это должно быть возможно.
  2. Обнаружение операторов вызовов и добавление целевых объектов. В С. нет аналогии с этим.

О. Как мне это сделать?

B. Есть ли какие-нибудь образцы конструкторов, на которые я мог бы посмотреть, с помощью которых я мог бы смоделировать?

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

Комментарии:

1. К вашему сведению: При работе с «вложенными» (или содержащимися) программами (COBOL 85 и более поздних версий) CALL literal будут возникать операторы. Некоторые из этих CALL утверждений будут ссылками на содержащиеся в них программы. Кроме того, CALL относится ли оператор к такой содержащейся программе, зависит от области действия содержащей программы. Все program-names они должны быть уникальными по отношению к самой внешней содержащей программе, но не обязательно должны быть уникальными по отношению к другим программам. Могут быть случаи, когда идентично закодированные CALL literal буквы s могут относиться к двум разным программам.

Ответ №1:

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

Считать…


…и обратите внимание, что код даже не является патологическим, как это…


Операторы КОПИРОВАНИЯ COBOL также могут быть продолжены, как и неприятный ВЫЗОВ выше.

Комментарии:

1. Этот комментарий очень ценен, но мое решение не обязательно должно охватывать все случаи. Просто мой случай, когда я знаю, что код «чистый». если это хорошо сработает, я мог бы продолжать обрабатывать больше крайних случаев, но, как вы указали, это практически безнадежно, когда программист кодирует динамический вызов.

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

3. Две вещи, которые следует добавить к рассмотрению: вы также можете CALL программировать указатели и иметь пользовательские функции (как «именованные», так и снова с указателем функции). Что касается включения в GnuCOBOL: существует зависимость поколения ( -MT и друзей) в GnuCOBOL 1.1 — они получили удален на 2.х. Я понятия не имею, если они когда-либо работали, но было бы очень здорово, чтобы они снова работает (даже если те make связаны они могут быть легко разобраны для использования с проектов SCons). Примечание: сгенерированный список внешняя ссылка можно использовать для поиска вызовов и УСТАНОВКИ/ПЕРЕМЕЩЕНИЯ констант при вызове переменных.