Havia algo em Cobol intrinsecamente tornando-se suscetível a problemas Y2K?

https://stackoverflow.com/questions/1463434

cobol
y2k

13-09-2019
|

Pergunta

Eu sei que um monte de Y2K esforços / susto foi de alguma forma centrada em COBOL, merecidamente ou não. (Que diabo, eu vi minor bug Y2K em um script Perl que quebraram 1/1/2000)

O que eu estou interessado, estava ali algo específico para COBOL como linguagem que tornou suscetível a problemas Y2K?

Isto é, ao invés de apenas a idade da maioria dos programas escritos nele e subsequente necessidade de economizar no consumo de memória / disco impulsionado por hardware antigo e o fato de que ninguém antecipou esses programas para sobreviver por 30 anos?

Eu estou perfeitamente feliz se a resposta for "nada específico para COBOL além da idade" - apenas curioso, sabendo nada sobre COBOL

Solução

Sim e Não. Em COBOL você tinha que declarar variáveis ??de tal forma que você realmente tinha a dizer quantos dígitos havia em um número ou seja, YEAR PIC 99 declarou a variável YEAR de tal forma que ele só poderia prender dois dígitos decimais. Então, sim, era mais fácil cometer esse erro do que em C foram você teria int ou short ou char como o ano e ainda tem muito espaço para anos maior que 99. É claro que não protegê-lo de printfing 19%d em C e ainda ter o problema na sua saída, ou fazer outros cálculos internos baseados em pensar que o ano seria menor ou igual a 99.

Outras dicas

Foi de 80% sobre a capacidade de armazenamento, pura e simples.

As pessoas não percebem que a capacidade de seu laptop disco rígido hoje teria custado milhões em 1980. Você acha que salvar dois bytes é bobagem? Não quando você tem 100.000 registros de clientes e uma unidade de disco rígido do tamanho de uma geladeira realizadas 20 megabytes e exigiam uma sala especial para manter a calma.

Ele parecia ser mais um problema das pessoas não saber quanto tempo seu código seria usado, por isso eles escolheram usar 2 anos dígito.

Então, nada específico para COBOL, é apenas que os programas COBOL tendem a ser crítica e idade para que eles eram mais susceptíveis de serem afectadas.

Havia algo em Cobol intrinsecamente tornando-se suscetível a problemas Y2K?

Os programadores ¹. E os sistemas onde os programas COBOL executar ².

_{1: Eles não projetar para a frente olhando 30 anos. Eu não posso culpá-los realmente. Se eu tivesse restrições de memória, entre apertando 2 bytes por data e fazê-lo funcionar 30 anos depois, provavelmente eu iria tomar a mesma decisão.}

2: Os sistemas poderiam ter tido o mesmo problema se o hardware armazenado o ano em dois dígitos.

pergunta fascinante. Qual é o problema Y2K, em essência? É o problema da não definir o seu universo suficientemente. Não houve nenhuma tentativa séria para modelar todas as datas, porque o espaço era mais importante (e os aplicativos seriam substituídos por então). Assim, em Cobol em todos os níveis, o que é importante:. Para ser eficiente e não overdeclare a memória que você precisa, tanto na loja e no nível do programa

Onde a eficiência é importante, nós cometemos erros Y2Kish ... Fazemos isso cada vez que armazenar uma data no DB sem um fuso horário. Então armazenamento moderno é definitivamente sujeitas a erros Y2Kish, porque tentamos ser eficiente com o espaço utilizado (embora eu aposto que é o excesso de otimização em muitos casos, especialmente no nível exagerar-tudo empresa).

Por outro lado, evitar erros Y2Kish sobre o nível de aplicação, porque cada vez que você trabalha com, digamos, a Data (em Java, digamos) que sempre leva em torno de uma tonelada de bagagem (como fuso horário). Por quê? Porque Data (e muitos outros conceitos) são agora parte do sistema operacional, então os caras inteligentes de tomada OS tentar modelar um conceito full-blown da data. Desde que confiam em seu conceito de data, não podemos estragar tudo ... e é modular e substituível!

línguas mais novos, com built-in tipos de dados (e instalações) para muitas coisas, como data, bem como a memória enorme para brincar, ajudar a evitar uma série de problemas Y2Kish potenciais.

Foi duas partes. 1- a idade / longevidade do software Cobol, e 2- o limite de 80 caracteres de registros de dados.

First- A maioria dos softwares de que a idade usado apenas 2 números do dígito para o armazenamento ano, uma vez que ninguém imaginou seu software iria durar muito tempo! COBOL tinham sido adoptadas pelo sector bancário, que são notórios por não jogar fora código. A maioria dos outros software foi jogado fora, enquanto os bancos não!

Em segundo lugar, COBOL foi constrangido a 80 caracteres por registro de dados (devido ao tamanho dos cartões perfurados!), Os desenvolvedores foram a uma pressão ainda maior para limitar o tamanho dos campos. Porque eles perceberam "2000 não será aqui até que eu sou longa e aposentado!" os 2 caracteres de dados guardados eram enormes!

Foi muito mais relacionado com o armazenamento do ano em itens de dados que só poderia armazenar valores de 0 a 99 (dois personagens, ou dois dígitos decimais, ou um único byte). Isso e cálculos que fizeram suposições semelhantes sobre valores de ano.

Não era uma coisa específica-Cobol. Muitos programas foram impactados.

Houve algumas coisas sobre COBOL que agravou a situação.

é velho, então menor uso de código da biblioteca, mais homegrown tudo
é velho, então pré-internet, pré-social-networking, mais NIH, menos frameworks, mais coisas personalizado
é velho, então, menos abstrato, mais propensos a ter soluções abertas com códigos
é velho, então, voltar longe o suficiente e salvar 2 bytes pode ter, mais ou menos, foi importante
é velho, então, assim que antecede SQL. software operacional legado ainda tinha arquivos de disco orientados por registro indexados para fazer rolar o seu próprio banco de dados-em-cada-programa um pouco mais fácil.
"printf" seqüências de formato e tipo de dados declaração eram a mesma coisa, tudo tinha n dígitos

Já vi programas Fortran gigantes sem sub-rotinas reais. Realmente, um programa principal de 3.000-line, nem uma única sub-rotina não-biblioteca, que era ele. Suponho que isto poderia ter acontecido no mundo do COBOL, então agora você tem que ler cada linha para encontrar o manuseio data.

COBOL nunca veio com qualquer biblioteca de manipulação de data padrão.

Assim, todos codificados por sua própria solução.

Algumas soluções foram muito ruim vis-a-vis o milênio. A maioria dessas soluções ruins não importa como as aplicações não viveu 40 anos. A não tão pequena minoria de más soluções causar o problema Y2K bem conhecido no mundo dos negócios.

(Algumas soluções foram melhores do que eu sei de sistemas COBOL codificados na década de 1950 com um formato de data boa até 2027 - deve ter parecido para sempre no momento;. E eu projetei sistemas na década de 1970 que são bons até 2079).

No entanto, teve COBOL teve um tipo de data padrão ....

03 ORDER-DATE     PIC DATE.

.... soluções toda a indústria teria sido disponível no nível do compilador, cortando a complexidade de qualquer correção necessária.

Moral:. Linguagens de uso com bibliotecas padrão

COBOL 85 (o padrão 1985) e versões anteriores não tem qualquer maneira de obter o século atual **, o que foi um fator intrínseco para COBOL que desencorajava o uso de anos de 4 dígitos, mesmo depois de 2 bytes espaço de armazenamento extra já não era um problema.

** implementações específicas podem ter extensões não padrão para esta finalidade.

O problema só intrínseca com Cobol era de origem (1960 final) declaração padrão para recuperar a data atual do sistema, o que era:

ACCEPT todays-date FROM DATE

Este retornou um número de 6 dígitos com a data no formato AAMMDD.

No entanto, mesmo isso não era necessariamente um problema como nós escrevemos código na década de 90 com esta afirmação que apenas verificado se a parte do ano foi inferior a 70 e assumiu que a data foi 20YY, o que teria tornado um problema Y2K070. : -)

O padrão foi estendido mais tarde (COBOL-85, eu acho), de modo que você poderia pedir a data em diferentes formatos, como:

ACCEPT todays-date FROM CENTURY-DATE

O que lhe deu um número de 8 dígitos com a data como SSAAMMDD.

Como você e outros apontaram, muitas outras linguagens de programação de computador permitiu a representação 'lossy' de datas / anos.

O problema era realmente sobre restrições de memória e armazenamento no final dos anos 70 início dos anos 80.

Quando seu quarto de computador milhão de dólares tinha 128K e 4 discos, totalizando cerca de 6 megabytes você poderia pedir a sua gestão para outra usina trimestre para uma máquina de 256K com 12 meg de armazenamento em disco ou ser muito muito eficiente sobre o espaço.

Assim, todos os tipos de economia de espaço truques foram usered. O meu favorito era para armazenar data AAMMDD como 991.231 em um x'9912310C campo decimal embalado' depois bater do último byte e armazená-lo como '991231'. Então, ao invés de 6 bytes você só pegou 3 bytes.

Outros truques incluiu alguns piegas tipo Hooky encodeing para os preços - código 12 -> US $ 19,99.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow