¿Había algo en Cobol intrínsecamente por lo que es susceptible a los problemas del Y2K?

https://stackoverflow.com/questions/1463434

cobol
y2k

13-09-2019
|

Pregunta

Sé que una gran cantidad de esfuerzos Y2K / susto fue de alguna manera centrada en COBOL, con razón o no. (Diablos, vi Y2K menor en un scripts de Perl que rompieron 1/1/2000)

Lo que me interesa, ¿había algo específico a COBOL como lenguaje que hacía susceptibles a los problemas del Y2K?

Es decir, en lugar de simplemente la edad de la mayoría de los programas escritos en ella y la subsiguiente necesidad de escatimar en el uso de memoria / disco accionado por el viejo hardware y el hecho de que nadie anticipó esos programas para sobrevivir durante 30 años?

Estoy muy feliz si la respuesta es "nada específico a COBOL es la edad" - mera curiosidad, sin saber nada de COBOL

Solución

Sí y No. En COBOL que tuvo que declarar variables tales que en realidad tenía que decir cuántos dígitos hay en un número, es decir, YEAR PIC 99 declarado la variable YEAR tal que sólo podía contener dos dígitos decimales. Así que sí, que era más fácil de cometer el mismo error que en C se tendría int o short o char como el año y todavía tienen mucho espacio para años mayores de 99. Por supuesto que no le protegen de printfing 19%d en C y sigue teniendo el problema en su salida, o hacer otros cálculos internos basado en el pensamiento del año sería menor o igual a 99.

Otros consejos

Fue 80% sobre la capacidad de almacenamiento, puro y simple.

Las personas no se dan cuenta de que la capacidad de su disco duro portátil de hoy habría costado millones en 1980. Se cree que el ahorro de dos bytes es tonta? No cuando usted tiene unos 100.000 registros de clientes y un disco duro del tamaño de un refrigerador celebró 20 megabytes y requiere una habitación especial para mantener fresco.

Parecía ser más un problema de las personas sin saber cuánto tiempo sería utilizado su código, por lo que optó por utilizar 2 años dígitos.

Por lo tanto, nada específico a COBOL, es sólo que los programas COBOL tienden a ser críticos y viejo, así que eran más propensos a ser afectados.

¿Había algo en Cobol intrínsecamente por lo que es susceptible a problemas Y2K?

Los programadores ¹. Y los sistemas en los que se ejecutan programas COBOL ².

_{1: Ellos no diseñaron mirando hacia adelante 30 años. No puedo culpar a ellos realmente. Si tuviera restricciones de memoria, entre apretando 2 bytes por fecha y hacer que funcione 30 años últimos, más probable es que me gustaría hacer la misma decisión.}

2: Los sistemas podría haber tenido el mismo problema si el hardware almacena el año en dos dígitos.

pregunta fascinante. ¿Cuál es el problema Y2K, en esencia? Es el problema de la no definir su universo lo suficiente. No hubo ningún intento serio para modelar todas las fechas, porque el espacio era más importante (y las aplicaciones sería reemplazado por entonces). Así que en Cobol en todos los niveles, eso es importante:. A ser eficaz y no overdeclare la memoria que necesita, tanto en la tienda y en el nivel de programa

Cuando la eficiencia es importante, que cometen errores Y2Kish ... Hacemos esto cada vez que almacenamos una fecha en la base de datos sin una zona horaria. almacenamiento de manera moderna es, sin duda sujeta a Y2Kish errores, porque tratamos de ser eficiente con el espacio utilizado (aunque apuesto a que es el exceso de optimización en muchos casos, especialmente en el nivel overdo-todo de la empresa).

Por otro lado, se evitan errores Y2Kish en el nivel de aplicación, porque cada vez que trabaje con, por ejemplo, una fecha (en Java, digamos) que siempre lleva alrededor de una tonelada de equipaje (como zona horaria). ¿Por qué? Debido a la fecha (y muchos otros conceptos) son ahora parte del sistema operativo, por lo que los chicos inteligentes del sistema operativo de decisiones tratan de modelar un concepto en toda regla de la fecha. Como nos basamos en su concepto de la fecha, no podemos meter la pata ... y es modular y reemplazable!

idiomas más nuevos con tipos de datos internos (e instalaciones) para muchas cosas como la fecha, así como la memoria enorme para jugar, ayudar a evitar muchos de los problemas potenciales Y2Kish.

Fue dos partes. 1- la edad / longevidad de software de Cobol, y 2- el límite de 80 caracteres de registros de datos.

La mayoría del software de primero de esa edad se utiliza sólo 2 números de dos dígitos para el almacenamiento de año, ya que nadie imaginó su software duraría tanto tiempo! COBOL había sido adoptado por la industria bancaria, que son conocidos por no tirar código. La mayoría del software se tiraba, mientras que los bancos no lo hicieron!

En segundo lugar, COBOL estaba limitada a 80 caracteres por registro de datos (debido al tamaño de las tarjetas perforadas!), Los desarrolladores fueron a una presión aún mayor para limitar el tamaño de los campos. Debido a que se imaginaron "El año 2000 no estará aquí hasta que yo estoy mucho y se retiró!" los 2 caracteres de datos guardados eran enormes!

Fue mucho más relacionado con el almacenamiento del año en los elementos de datos que sólo podía contener valores de 0 a 99 (dos caracteres, o dos dígitos decimales, o un solo byte). Eso y cálculos que hicieron supuestos similares acerca de los valores del año.

No era una cosa-Cobol específica. Muchos de los programas se vieron afectados.

Hubo algunas cosas sobre COBOL que agravaron la situación.

es viejo, por lo menos uso de código de la biblioteca, más canteranos todo
es viejo, por lo que pre-internet, pre-social en red, más NIH, un menor número de marcos, más cosas a medida
es viejo, así, menos abstracto, más probabilidades de tener soluciones con código abierto
es viejo, así, ir hacia atrás lo suficiente y el ahorro de 2 bytes podría tener, más o menos, fue importante
es viejo, por lo que, por lo que es anterior a SQL. el software operativo heredado incluso había indexado archivos de disco orientados a registros para hacer balanceo-su-propio-base-en-cada-programa un poco más fácil.
cadenas de formato "printf" y declaración de tipo de datos son la misma cosa, todo lo que tenía n dígitos

He visto programas Fortran gigantes sin subrutinas reales. En definitiva, se programa principal 3000 de línea, ni una sola subrutina no biblioteca, eso fue todo. Supongo que esto podría haber sucedido en el mundo COBOL, por lo que ahora usted tiene que leer cada línea para encontrar el manejo de fechas.

COBOL nunca llegó con cualquier biblioteca de manejo de fechas estándar.

Para que todos codifica su propia solución.

Algunas soluciones eran muy malas vis-a-vis el milenio. La mayor parte de esos malos soluciones no importaba que las aplicaciones no vivieron más de 40 años. El no tan pequeña minoría de soluciones mala causa del problema Y2K bien conocido en el mundo de los negocios.

(Algunas soluciones fueron mejores que conozco de los sistemas COBOL codificados en la década de 1950 con un formato de fecha buena hasta 2027 - debe haber parecido para siempre en el momento;. Y yo diseñamos sistemas en los años 1970 que son buenas hasta 2079) <. / p>

Sin embargo, tenía COBOL tenía un tipo estándar de fecha ....

03 ORDER-DATE     PIC DATE.

.... Industria soluciones de ancho habrían estado disponibles a nivel del compilador, el corte de la complejidad de cualquier remediación necesario.

Moral:. Usar idiomas con bibliotecas estándar

COBOL 85 (el estándar 1985) y versiones anteriores no tenían ninguna manera de obtener el siglo actual **, que era uno de los factores intrínsecos a COBOL que desaconseja el uso de años de 4 dígitos incluso después de 2 bytes de espacio de almacenamiento adicional ya no era un problema.

** implementaciones específicas pueden haber tenido extensiones no estándar para este propósito.

El único problema intrínseco con Cobol fue que es original (finales de 1960) Declaración estándar para recuperar la fecha actual del sistema, lo que fue:

ACCEPT todays-date FROM DATE

Esto devuelve un número de 6 dígitos con la fecha en el formato AAMMDD.

Sin embargo, incluso esto no es necesariamente un problema, ya que escribió el código en la década de los 90 el uso de esta declaración que acaba de comprobar si la porción año fue inferior a 70 y asumió que la fecha era 20YY, lo que habría hecho que sea un problema Y2K070. : -)

La norma se amplió más tarde (COBOL-85, creo) por lo que se puede pedir a la fecha en diferentes formatos, como:

ACCEPT todays-date FROM CENTURY-DATE

¿Qué le dio un número de 8 dígitos con la fecha como CCYYMMDD.

Como usted, y otros han señalado, muchos otros lenguajes de programación permite a la representación 'con pérdida' de fechas / año.

El problema era realmente acerca de las limitaciones de memoria y almacenamiento en los finales de los 70 principios de los 80.

Cuando la cuarta parte de un equipo millón de dólares tenía 128K y 4 discos por un total de cerca de 6 megabytes que podría o bien pedir a su gestión durante otro cuarto molino para una máquina de 256 K con 12 megas de almacenamiento en disco o ser muy muy eficiente sobre el espacio.

Se usered

Así que todo tipo de trucos para ahorrar espacio. Mi favorito era almacenar la fecha AAMMDD como 991.231 en un abarrotado campo decimal x'9912310C', entonces retroceso del último byte y almacenarlo como '991231'. Así que en lugar de 6 bytes que sólo se tarda hasta 3 bytes.

Otros trucos incluidos algunos encodeing tipo Garfito hokey de precios - código 12 -> $ 19,99.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow