[Noticia] Los Límites del COBOL

[Josber]

Nunca os habeis preguntado, cuántos registros, cuántos OCCURS, cuántas líneas, cuántos ... puede tener un programa COBOL

Pues ale a leer ...



Líneas de un programa:
El nº máximo de líneas que puede tener un programa son 999.999 líneas. Sinceramente, encontrarse un programa así de largo haría que nos acordásemos de toda la familia del que tuvo la idea...

En dos palabras, in-mantenible^^

Ficheros:
El nº máximo de ficheros por programa es de 65.535 ficheros.
Y si tal que haya que cruzarlos!!!

Longitud de fichero:
La longitud máxima que puede tener un fichero en su RECORD es de 1.048.575 posiciones.
Total na.

Variables de working:
La suma de las variables definidas en la WORKING-STORAGE, no podrá pasar de 134.217.727. Lo mismo para la LINKAGE-SECTION.

EVALUATE:
El nº máximo de cláusulas WHEN en un EVALUATE será de 256.
Si que son posibilidades!

PERFORM:
A lo largo del programa sólo podremos utilizar 4.194.303.
Debe ser por si queremos codifcar el programa de 999.999 líneas...

OCCURS:
El número máximo de occurs que podrá tener una tabla interna será de 16.777.215.

USING en la procedure:
Cuando tengamos un programa con LINKAGE SECTION, el máximo de variables que podremos incluir en la PROCEDURE DIVISION USING ... será de 32.767.

Cláusula VALUE:
El total de las longitudes de los valorse incluidos en las cláusulas VALUE no podrá superar los 16.777.215.


"pa'vernos matao"

Un saludo.-

[Rapinto]

Josber,

Há um limite muito importante nos dias de hoje.

O tamanho físico máximo de um ficheiro indexado no disco.

Tenho um cliente com 20 lojas, que nos documentos, chegou aos 3 Gbytes
Terminou. O ficheiro não pode conter mais registos. Tive que o partir e continuar noutro ficheiro.
E para chegar aquele limite tive que utilizar a DLL do LargeFile

Un saludo,
Rui

[Dasije]

Una de las limitaciones más gordas que tiene, son los cambios de estructura de archivo, cada cambio, un programa de traspaso, en SQL eso ya está solucionado, solo hay que preparar el script, que las propias herramientas de administración ya te lo dan hecho cuando se guardan los cambios en una tabla, y solo ejecutas el script en el cliente final y listo.

Saludos.

[Kuk]

❞ Una de las limitaciones más gordas que tiene, son los cambios de estructura de archivo

Esto lo no lo veo yo un problema, de toda la vida en los ficheros se ha previsto FILLER-s precisamente para lo que dices. Nunca he hecho un fichero estrictamente según la estructura que se necesita en el momento. Y normalmente no suele haber cambios tan gordos en una aplicación como para cambiar la estructura entera un fichero. Si se añade algo gordo, se crea un fichero nuevo con su estructura y listo.

Si no, también hay la opción de un VB (longitud variable), y definir tipos de registro con distintas estructuras, 01, 02, 03 etc.

La ventaja de SQL es la conectividad a distancia y SGBD. Pero son cosas que se puede hacer también, porque las SGBD vienen a ser software de gestión de ficheros, y la conexión a distancia es todo basado en SOCKET-s.

[Dasije]

Lo de fillers es cosa de hace unos años, los equipos informáticos tienen capacidades muy grandes de memoria y disco duro, antes no, por lo tanto, se reservaba mucha memoria.

Cuando tengas que crear un nuevo indice, obligatoriamente hacer un programa de traspaso, pero claro, dirás que los equipos informáticos son muy rápidos y es un problema menor recorrer todo el fichero.

En SQL Server, solo es necesario crear indices en tablas de más 500.000 registros, ya que se degrada el rendimiento en recorrer la tabla por un campo no indexado, y no hay que hacer traspasos.

Los ficheros indexados le viene muy bien trabajar en modo CMS, sería muy potente, cada fichero sería una tabla con un tipo tipo de campo (númerico, texto, fecha, etc) y después montar un administrador de tablas "virtuales" donde se guardarían tablas de artículos, clientes, etc.

[Kuk]

Dasije, échale un ojo a este tema que he creado hace un tiempo: [Información] Velocidad y rendimiento: BBDD/Ficheros Indexados - COBOL Foro

Los FILLER-s no se hacen en fichero para reservar memoria, sino para alterar la estructura. A lo que tú te refieres creo que son los FILLER-s en LINKAGE, para no tener que recompilarlo todo si la nueva parte se usa sólo en la evolución. Al revés, antes no se declaraban variables innecesarias para ahorrar memoria.

Una BBDD nunca será más rápida que los ficheros indexados, si está todo bien pensado. Y aunque sea un bucle secuencial, y la BBDD trabaje con íncides adicionales, la capa de software intermedia de SGBD ya quita bastante velocidad. Las BBDD tienen otras ventajas, entre las cuales está la comodidad.

[Gusaiello]

Ya que salió el tema aporto mi pequeño granito de arena.
Esto fue tomado textualmente del manual.

ACUCOBOL-GT 5.1 has the following limits:

Maximum Program Size: 1 MB code, 1 MB data
(compilation unit) 1 GB data for large model

Maximum Program Size: Limited only by machine memory
(run unit)

Maximum Record Size: 32767 bytes

Number of Indexed Keys: Primary + 119 alternates

Number of Segments per Key: 16

Maximum Indexed Key Size: 250 bytes

Maximum Sort Key Size: 32767 bytes

Maximum Number Sort Keys: 255

Maximum duplicate keys: No limit

Maximum File Size: Host system dependent.
Logical limit: 128 terabytes if Vision Version 4
is used; for all other file systems the logical
limit is 2048 MB

Maximum Data Item Size
- Alphanumeric: 65520 bytes*
- Numeric: 18 digits
- Edited: 255 bytes

Maximum size of an external : 64K (larger in large model)*
data item:

Maximum Table Indexes: 15

Maximum Open Files/Process: 255 (128 on MS-DOS)

Maximum Literal Size: 4096 characters

Maximum Paragraph Size: 32767 bytes

Maximum Pop-Up Windows: Limited only by machine memory

Maximum Picture String: 100 Characters

SPECIAL-NAMES Switches: 26

Maximum number of OCCURS: 65,280

Maximum nesting:
- IFs: limited by machine, least max.=2720
- PERFORMS: No limit
- PERFORMS n times: No limit
- CALLS: No limit
- Recursive CALLS: 32767

Maximum number of data and Limited only by machine memory
procedure names:

Maximum number of : 50
parameters
in a CHAIN statement

[Dasije]

Si creas un filler de 32.000 caracteres por ejemplo, cuando compilas crea un ejecutable más grande, por la reserva de memoria en cada formulario donde incluyas ese fichero, e igual con las variables de la working.

En RM/COBOL, no existía ese problema, creaba un objeto compilado tal cual, solo aumentaba por código nuevo escrito.

Hace unos años, los equipos y las redes eran lentos/as, entonces el TCP/IP consumía más paquetes de sockets en comunicar servidor y cliente que una comunicación SMB, por eso se quejaban mucho de las aplicaciones SQL, hoy en día ese problema está resuelto, y una aplicación bien programada (nada de SELECT * FROM CLIENTES WHERE ...), puede ser rápida y potente.

No te discuto que COBOL sea muy rápido, ya que no maneja nada por medio, acceso a datos puro y duro, pero cuando necesitas una aplicación donde el cliente quiere libertad de trato de información y yo quiero más tranquilidad, COBOL se queda corto, por ejemplo acceso a través de OBDC.

[JulioBenitez9470]

Yo desarrollo software bajo cobol desde mis 27 años hasta ahora mismo que tengo 62, y he visto mucha gente modernosa que trata de enviarlo al arcon de los recuerdo, yo comence con una NCR 8200 con 32 K de RAM en esa cancha se sabia si era uno bueno o no en estas lides, habia que cuidar cada linea, cada variable, luego vinieron con el paso del tiempo los equipos altamente potentes y nacieron los programadores de macros, que tal vez ignoran que fue otro programado que las armo antes, en cobol habia que arreglarselas y bien que nos arreglabamos, yo personalmente ante la posibilidad de un desarrollo grande cree con cobol (en aquellos tiempos 1995) rmcobol una herramienta de programacion que generaba progrmas cobol obvio sin la instruccion GO, lo que se llamaba cobol estructurado, podia generar en segundos programas de mantenimiento basico de archivos, menues, consulta de uno o mas archivos interrelacionados con diversos cortes de control, igualmente listados, y tenia una gran diferencia con algunas herramienta que venian de EEUU que este te dejaba los programas completamente abiertos para que tu le retocaras lo que quieras.
Con mi herramienta un principiante armaba un sistema en unos dias, nunca la vendi, nunca desarrollo una ayuda, aun la conservo y uso su diccionario de archivo para mis desarrollos en POWER COBOL y como prueba tengo desde el primer al ultimo origen con todas las variable bien en español, jaja

saludos