Leitura de Layouts COBOL Este tutorial sobre como ler um layout COBOL foi escrito especificamente para nossos clientes que tiveram uma conversão realizada no Disc Interchange e receberam um layout COBOL com os dados. Pretende-se dar-lhe informações suficientes para ler layouts mais simples. Ele não abrange todos os tópicos ou tudo o que você encontraria em um layout complexo, e destina-se a explicar layouts COBOL apenas para que você possa usar seus dados convertidos, não para que você possa escrever programas COBOL. Este artigo começa aqui: Reading COBOL Layouts onde você também vai encontrar um índice de tópico. Parte 4: Campos Numéricos Esta seção descreve vários tipos de dados numéricos ea manipulação de sinais e pontos decimais. Conteúdo desta seção: Necessidade de converter campos numéricos Esse é o nosso negócio COBOL tem vários tipos de campos numéricos. Esses tipos de dados incluem um campo DISPLAY, que é composto de caracteres (os caracteres EBCDIC ou ASCII de 0 a 9), campos binários, campos compactados e campos de ponto flutuante. Há também opções para um separado ou - sinal ou um sinal overpunch, e para real ou implícita decimal. O tipo de dados é especificado pela cláusula USAGE IS. O USO É cláusula Há realmente mais para a declaração de imagem do que weve descrito anteriormente. Existe uma cláusula USAGE IS que especifica o tipo de armazenamento de um campo numérico - display, binário ou computacional. A sintaxe completa, por meio de um exemplo, é: Isto diz para armazenar o campo no formato computacional-3. O uso é parte é opcional e geralmente deixado de fora, e computacional pode ser abreviado COMP, então você verá mais comumente isso escrito Os tipos de campos numéricos que você geralmente verá em layouts COBOL são: Display (incluindo campos assinados) Binary Computational ou Comp Comp-1 Comp-2 Comp-3 Display, incluindo assinado ou Zoned campos, é o mais comum, e comp-3 é o segundo tipo mais comum de campo numérico. Alguns compiladores também podem ter comp-4 e comp-5 tipos de dados, geralmente para emular comp em outro compilador. Uso é Display O formato de exibição é o padrão para números em COBOL. Se nenhuma cláusula use is for especificada, o padrão é use is display, o que significa que o valor é armazenado como caracteres EBCDIC (dígitos), ao contrário de binário. O valor pode ou não ter um decimal - implícito ou real - e pode ser unsigned ou ter um incorporado ou um sinal separado - que pode ser líder ou à direita. O campo de formato de exibição assinado padrão contém um sinal de rastreamento incorporado e é comumente chamado de Signed, IBM Signed ou Zoned. Este tipo de dados é descrito abaixo. Campos assinados Há um tipo de dados numéricos comum usado em COBOL em mainframes IBM chamado Signed (também chamado IBM Signed ou Zoned). COBOL representa este tipo de campo por um S na cláusula de imagem de um campo de formato de exibição, e. PIC S9 (6). Um campo assinado é composto por caracteres numéricos EBCDIC regulares, um caractere por byte, para todos os dígitos, exceto aquele que contém o sinal, ou o dígito mais significativo (sinal que leva) ou o menos significativo Dígito menos significativo. O dígito que contém o sinal combina, ou mais socos o sinal do número para esse dígito. Isso economiza um byte que o sinal ocuparia de outra forma. O valor desse dígito é armazenado como um valor binário e é ORd com o código de sinal, que é D0 hex para números negativos, C0 hex para valores positivos e F0 hex para valores não assinados. Devido ao overpunch, o dígito que contém o sinal não será apresentado como um número quando o campo é visualizado no modo de carácter EBCDIC. Se você tiver o campo e exibir um valor de 1.23 com um editor EBCDIC, ele lerá 0000012C. Os compiladores ASCII COBOL também usam um tipo de dados assinados com um overpunch, mas os bits de sinal são diferentes e não padronizados entre os compiladores. Consulte os nossos campos assinados do Tech-Talk para mais detalhes sobre os campos assinados EBCDIC e ASCII. O sinal é campos COBOL assinados separados incorporam o sinal no valor por padrão (ver campos assinados acima). Mas há uma disposição em COBOL para um sinal separado, e pode ser líder ou à direita. A instrução para isso é Isto pode ser combinado com a cláusula inicial ou final: Esta declaração pode ser aplicada a um item elementar (campo) ou ao registro inteiro. Campos computacionais e binários Como os computadores executam cálculos com números binários, é mais eficiente armazenar esses valores no arquivo em sua forma binária nativa do que armazená-los em uma base 10 legível. Se o número é armazenado em seu formato binário nativo, ele pode ser inserido a partir do arquivo e usado diretamente. Se o seu armazenado em um formato de base dez ele precisa ser convertido em binário antes de executar cálculos sobre ele, em seguida, convertidos de volta para base dez para armazenamento. COBOL define vários tipos de dados binários. Vamos listar um breve resumo aqui, e você pode encontrar mais detalhes em campos computacionais COBOL e em COBOL Comp-3 Packed Fields. Antes de começarmos, há um ponto importante a entender: O padrão COBOL deixa a implementação real da maioria dos tipos de dados até o fornecedor que escreveu o compilador COBOL. A razão para isso é porque diferentes computadores - CPUs - usam diferentes representações binárias internamente e funcionam melhor com seu próprio tipo de números binários. Esta abordagem resulta em compiladores melhores e mais rápidos, mas também causa confusão, porque um tipo de dados comp em uma máquina não é necessariamente o mesmo que comp em outra máquina. A tabela abaixo lista os usos comuns não todos os compiladores seguirão esses tipos. Para mais detalhes sobre ordem de palavras e sinais, veja o link acima. O tipo de dados que um campo usa para armazenamento é determinado pela cláusula use is na definição de campo e, na maioria dos casos, o número de bytes de armazenamento é determinado pelo número de dígitos no PIC. Os números de ponto flutuante seguem formatos binários padrão e, como tal, seus tamanhos não são determinados por um PIC e nenhum PIC é usado na definição de campo. Descrição de como esse tipo de dados é armazenado Embalado decimal geralmente é implementado como comp-3. Ver comp-3. Ao ler uma especificação de campo binário ou comp, o tamanho listado no PIC é o número de dígitos decimais após o número ser convertido de binário para base dez. No caso de um campo embalado, é o tamanho após a desembalagem. Real Decimal A maioria dos programadores de PC tendem a pensar em termos de decimal real em valores numéricos. Em um PC, se você tiver um campo de dólares e centavos para, digamos, o total da fatura, no valor de 123.45, o arquivo conterá os seis bytes 123.45 (e provavelmente um sinal). Em outras palavras, há um ponto decimal real no arquivo. COBOL pode fazer isso, também, através do seguinte: OR: A presença do. No PIC causa um decimal real no arquivo. O decimal implícito, entretanto, é muito mais comum em COBOL. Decimal implícito O decimal implícito significa simplesmente que há um ponto decimal implícito em um local especificado em um campo, mas não realmente armazenado no arquivo. A localização do decimal implícito é indicada por um V no PIC. Usar decimal implícito economiza espaço no arquivo. O decimal implícito pode ser aplicado a qualquer tipo de campo numérico, incluindo um campo compactado ou comp-3. Por exemplo, é um campo decimal implícito. Existem 6 dígitos, então um decimal implícito - o V - e mais dois dígitos, para um total de 8 dígitos. O campo é de 8 bytes de tamanho não existe. No arquivo - o local do ponto decimal está implícito entre 9 (6) e 99. Se o campo contiver 00000123 então o saldo da conta é 1.23, porque há um decimal implícito entre os dólares e centavos. Sincronização e Alinhamento Este tópico é um pouco envolvido para este tutorial, mas você deve estar ciente disso. Ao usar o armazenamento binário (binário e comp), alguns compiladores em algumas máquinas podem exigir que um campo numérico começar em algum limite. Por exemplo, em uma máquina de 32 bits, pode exigir que um campo comp começa em um limite de 32 bits. Se você especificar um campo de compilação no meio de um registro e não acontecer de começar em um limite de 32 bits (4 bytes), o compilador alinhá-lo-á a um limite de 32 bits para sincronizá-lo. O que é realmente armazenado no arquivo pode não ser o mesmo que os PICs no layout indicar. Este não é um problema muito comum, em parte porque binário e comp campos não são muito comuns em arquivos, mas você deve estar ciente dela. Informações Adicionais Para obter mais artigos sobre conversão de dados, consulte nosso Índice TechTalk. Nossa Empresa de Serviços de Intercâmbio de Disco de Serviços de Conversão COBOL pode converter a maioria dos tipos de dados numéricos, incluindo todos os tipos de dados IBM mainframe EBCDIC ea maioria dos tipos de dados ASCII dos sistemas PC e UNIX. A nossa biblioteca de rotinas de conversão permite-nos lidar com os trabalhos difíceis que os compiladores COBOL padrão não podem converter. S9 (9) COMP e S9 (8) COMP S9 (9) COMP e S9 (8) COMP Hi All, Qual é o número máximo que pode Ser espremido em dois campos PIC diferentes acima, e como a opção de compilador TRUNC (BINOPTSTD) afetá-lo. A razão que eu pergunto é que eu estou trabalhando com um produto chamado HPS que define seus campos Integer como S9 (8) COMP e, em seguida, move-lo para um campo DB2 Integer, que é S9 (9) COMP. Há uma preocupação de que os dois são incompatíveis. RE: S9 (9) COMP e S9 (8) COMP k5tm (Programador) 23 Jul 02 11:46 Primeira revisão Thread209-205700 onde eu respondi a pergunta de quantos dígitos decimais podem ser representados por 31 dígitos binários. Obviamente, o truncamento padrão é feito em limites decimais independentemente da representação de dados subjacente. Meu palpite é que você não terá problemas em mover S9 (8) para S9 (9) em qualquer uma das opções TRUNC. Se o movimento fosse a outra direção, haveria diferenças. Em qualquer caso, parece que TRUNC BIN seria mais seguro para o seu problema, supondo que não causa efeitos colaterais indesejados. RE: S9 (9) COMP e S9 (8) COMP Tom, eu li o fio. E então eu li de novo. Depois de tomar um par de comprimidos e ter uma mentira para baixo, eu tinha outro ir e Im ainda não tenho certeza eu entendo Eu sei que comp S9 (8) e comp S9 (9) ocupam o mesmo armazenamento (palavra completa) e Im ciente de que com A opção TRUNC (BIN) do compilador, truncagem não deve ocorrer como faria com TRUNC (STD). Estou com a impressão de que com um campo comp S9 (4) há um número máximo que o campo pode conter, que por seu exemplo no segmento, é 32043. É este o mesmo para comp S9 (89) e são esses valores Eu acho que a pergunta que eu estou perguntando é que se eu preenchesse o campo comp S9 (9) com o maior valor que ele poderia tomar, e movido para um campo S9 (8), seria permanecer o mesmo valor Espero que isso faz sentido , E por favor perdoe minha ignorância na parte dianteira da matemática COMP / S9 (9) COMP e S9 (8) COMP Dimandja (programador) 23 Jul 02 19:50 Minha compreensão de S9 (9) COMP e S9 (8) COMP é COBOL Manipular qualquer número até -999.999.999 e -99.999.999, respectivamente. Quanto à comparação de inteiros com COBOL PIC 9s: COBOL PIC 9 (4) COMP max 9,999 COBOL PIC 9 (5) COMP max 99,999 COBOL NATIVE-2 máximo 65,535 16 bit Inteiro máximo 65,535 COBOL PIC 9 (8) COMP max 99,999,999 COBOL PIC 9 (9) COMP max 999,999,999 COBOL NATIVE-4 max 4,294,967,295 32 bits Número inteiro max 4,294,967,295 RE: S9 (9) COMP e S9 (8) COMP Dimandja (programador) 24 Jul 02 06:20 COBOL PIC 9 (4) COMP max 9,999 COBOL PIC 9 (9) COMP max 999,999,999 COBOL NATIVE-4 max 2 147 483 647 32 bits Número inteiro max 2,147,483,647 RE: S9 (9) COMP e S9 (8) COMP k5tm (programador) 24 Jul 02 10:05 Espero que eu não confundiu muito. Para reiterar: Você afirmou que seu problema estava movendo PIC S9 (8) para PIC S9 (9). Sob regras de truncamento decimal, isso não deve causar nenhum problema. Da mesma forma, sob truncamento binário, eu não acho que há um problema. Se você tiver dados indo a outra maneira, de 9 (9) a 9 (8), então você definitivamente tem truncamento decimal possível. Truncamento binário não deve ser um problema, embora eu não sou um especialista em seu compilador particular. RE: S9 (9) COMP e S9 (8) COMP Crox (Programmer) 24 Jul 02 12:03 Tente usar COMP-5 em vez de COMP. Ele funcionará da mesma maneira para a mesma alocação de armazenamento. Leia o seu manual sobre ele COMP-5 é quase sempre melhor do que COMP. Eu não posso usar o Comp-5 como se eu tivesse uma tabela do DB2 e sua definição de dclgen e, por outro, a definição do HPS, que não são 100 iguais . Im em um manframe e estou usando um xpediter compilar deck que eu acho que está usando cobol370, embora Im não positivo sobre isso. Theres obviamente não é um problema de 9 (8) comp para 9 (9) e estou começando a formar a impressão de que o valor máximo para o 9 (9) comp é o mesmo que 9 (8) comp usando um TRUNC (BIN ) Opção de compilação. Eu acho que Dimandja tem razão em dizer que o máximo de meia palavra é 32767 eo máximo para uma palavra cheia é 2,147,483,647. Eu acho que tanto 9 (8) e 9 (9) comp vai realizar este máximo, embora Im aberto a ser persuadido caso contrário sobre isso, se alguém pode me mostrar a matemática. Eu acho que eu poderia ter que knock up um programa que move os valores para os campos relevantes e ver o que acontece. Im sure Ive feito este com o 32767 muitos anos há, e você começa um abend. Vai tentar amanhã e relatar, a menos que alguém sabe o contrário. Ive apresentou o seguinte como fato, porque parece mais claro, sem todos os ifbes maybes e perhapes, mas Im não tenho certeza se é verdade. Eu gostaria de ouvir o que todos pensam. Eu não sei se este ponto foi abordado, mas o cálculo da capacidade de uma meia palavra, palavra ou palavra dupla depende se o campo é descrito como assinado ou não assinado ea opção TRUNC selecionada em tempo de compilação. Como eu me lembro o sinal usa o bit de alta ordem do campo, reduzindo a capacidade. Assumindo TRUNC (BIN), um campo COMP de meia palavra definido como PIC 9 tem a capacidade de manter um valor até 65.535 decimal (XFFFF) o mesmo campo, definido como PIC S9, pode conter um valor até 32.767 decimal (X7FFF). Este é do meu manual COBOL85 (TandemCompaqHP): Os intervalos de valores para os tipos NATIVE-2 (16 bits), NATIVE-4 (32 bits) e NATIVE-8 (64 bits) são: Tipo Limite Superior Ligado Baixo NATIVE-2 -32768 32767 NATIVE-4 -2147483648 2147483647 NATIVE-8 -9223372036854775808 9223372036854775807 Os intervalos de valores para o tipo COMPUTATIONAL-5 são: PIC S9 (1) - PIC S9 (4) equivalente é NATIVE-2 -32.768 a 32.767 (assinado) ou 0 a 65.535 (não assinado) PIC S9 (5) - PIC S9 (9) NATIVE-4 -2 147 413 648 a 2 147 483 647 (assinado ) Ou 0 a 4,294,967,295 (sem assinatura) PIC S9 (10) - PIC S9 (18) NATIVE-8 -9,223,372,036,854,775,808 a 9,223,372,036,854,775,807 (assinado) ou 0 a 18,446,744,073,709,551,615 (unsigned) Isso deve esclarecer um pouco as coisas. Olá a todos, primeiro muitos agradecimentos a todos vocês, porque todos vocês ajudaram de uma forma ou de outra, mas eu sinto que os posts Dimandjas foram os mais úteis, por isso vou dar D Estrela. Espero que seja ok com o resto de vocês A coisa que eu amo sobre este jogo é que não importa quanto tempo youve sido fazê-lo, há sempre algo novo para descobrir, mesmo se você pode ter tocado em anos atrás. Eu tenho o bug sobre esta questão quando alguém a propôs como um problema na segunda-feira. O sistema definiu um valor em um campo comp S9 (8) e moveu-o para um campo db2 S9 (9) comp em uma tabela ea tabela foi atualizada. O cenário que me foi apresentado foi que ele estava causando um problema na produção como valores grandes estavam ficando na tabela que couldnt subsequentemente ser lido usando o campo S9 (8) como chave. Foi-me dito que TRUNC (BIN) estava a ser utilizado. Meu primeiro argumento foi que, se ele sempre foi obtido a partir do S9 (8) comp campo não deve ser um problema. Foi-me dito que este didnt parecem ser o caso. Eu ainda tinha a sensação de que isso não deveria ter sido um problema, pois eu tinha certeza de que o número de dígitos especificados no tamanho do campo era irrelevante quando TRUNC (BIN) como havia um valor máximo em meia palavra, palavra, etc As postagens aqui tipo De confirmar meu pensamento, especificamente Dimandjas. Então, hoje, eu escrevi um programa para mover vários valores para vários campos. Os resultados me surpreenderam. Movi 32768 para um S9 (4) COMP campo e olhou para o valor. Ele continha -32768. Vários valores mais altos movidos para o campo produziram vários números negativos inferiores. Comuniquei as minhas conclusões, a saber, que S9 (8) COMP e S9 (9) COMP quando usado com a opção TRUNC (BIN) iria conter exatamente o mesmo valor máximo, apenas para ser dito. Oh não, o deck de compilação é TRUNC (STD). - O que causa um problema Para resumir tudo isso: TRUNC (STD) seguirá o PIC que você definir, então S9 (4) COMP permitirá um máximo de 9999 e um mínimo de -9999 TRUNC (BIN) dará: S9 a S9 (4) COMP -32768 a 32767 S9 (5) a S9 (9) COMP -2147483648 a 2147483647 remover o sinal desta opção altera o intervalo para: 9 a 9 (4) COMP 0 a 65535 9 (5) a 9 ( 9) COMP 0 a 4.294.967.295 Mais uma vez, obrigado por toda a sua ajuda. MarcA1 PIC X40841 valor 1. A2 s940841 Comp redefines A1. (Valor Hex em A1 30 30 30 30 30 30 30 31) (Valor hexadecimal em A2 30 30 30 30 00 00 00 01) A definição de exemplo para A1 poderia conter o caractere 1 seguido de sete espaços em branco. O redef de A1 como A2 só redefinir os quatro primeiros caracteres de A1, não os oito bytes inteiros de A1. O valor hexadecimal em A1 seria XF140404040404040. O valor hexadecimal em A2 seria XF1404040. O valor numérico de A2 seria 4047519808. Eu não tenho idéia de como você obteve os valores ASCII em A1. Eu não tenho idéia de como você obteve o valor 1 para justificar direito e levando espaços em branco convertido em zeros. Eu não tenho idéia de como sua redef conseguiu mudar direito quatro bytes. Como visto acima, o valor em A2 não é numérico, pois tem x00 (ou seja, NULL) Os nulos em A2 são comp numerics, juntamente com o 01 à direita. Meu requisito é obter 30 30 30 30 30 30 30 31 em A2. Para que eu possa usá-lo para operações numéricas Assumindo que você tem zônico válido decimal em A1 e realmente deseja A2 para conter valores válidos COMP (binário), veja acima Se você realmente queria dizer A2 para conter dígitos decimais zoned válido para usar em operações numéricas, O COMP na redef A2. Note: É obrigatório para mim usar uma variável comp. Por que é obrigatório Você não pode usar decimal empacotado ou este código está sendo executado em uma máquina que não suporta nativamente instruções decimais cheias Pls me avise se mais informações são necessárias do meu lado. Inicialmente, apenas as respostas às perguntas acima.
Comments
Post a Comment