Hace 15 años | Por maxim.rudin a eltamiz.com
Publicado hace 15 años por maxim.rudin a eltamiz.com

La continuacion de la saga. Después del entrada dedicada al equipamiento, ahora como se trabajaba en los setenta. ¡Muy bueno!

Comentarios

D

Años después, en muchos casos, la vida fue injusta con esos grandes profesionales. La “titulitis” que apareció en España en los años ochenta y noventa los dejó fuera; muchos de ellos están “prejubilados” o simplemente “despedidos” de mala manera. Becario, jovenzuelo e inexperto (y sin saber una palabra de Banca) ellos me acogieron, me tutelaron y enseñaron lo que sabían. Aprendí muchísimo de estos profesionales como la copa de un pino. Quiero expresar desde estas humildes líneas mi Admiración y Respeto por ellos, y hacerles el homenaje que, que yo sepa, nadie les ha hecho. ¡Gracias, amigos!

Vaya, la titulitis ya estaba de moda por aquel entonces. No hay nada nuevo bajo el sol, me temo.

D

No sé si alguien se ha preguntado el por qué de esta frase: (Sistema Operativo, Compilador, *Sort*, etc)

Sort en la mayor parte de ordenador y sistemas no es mas que un comando de ordenación (por ejemplo: ls -l | sort -n +4 ordena los ficheros de un directorio UNIX por su tamaño) pero en los mainframes de IBM era y SIGUE siendo algo muy distinto.

SORT se usa, aparte de para ordenar, para sacar campos de un fichero secuencial (en el campo mainframe sigue siendo muy habitual) para extraer líneas de un fichero (es un cruce de grep y awk, con muchísimas limitaciones) ordena (cómo no) y hace alguna que otra operación rara que ahora no me acuerdo. SORT es básico para el tratamiento BATCH en los mainframes. Sin SORT no se podrían mezclar ficheros, sacar campos, etc.

Salvo en el tema de que los ordenadores son multitarea y las compilaciones son mucho mas rápidas, el campo mainframe ha avanzado muy poco con respecto a lo que describe el artículo (he estado en proyectos de mainframe hace relativamente poco) Aunque hay BD relacionales (DB/2) lo normal es operar en batch, lo que significa sacar datos de las BD o indexados (se siguen usando) a un "bote" (es un fichero, pero en un organigrama se dibuja como un bote y de ahí viene) que luego se procesa en otros ficheros hasta obtener el resultado esperado en otro fichero, que luego puede volcarse o no a una BD o donde sea. El Mainframe distingue claremente entre on-line (habitualmente con CISC) y el batch (proceso de ficheros) Y lo normal es que si una consulta on-line ocupa mas de 2 segundos de CPU, el sistema de hecha.

Saludos

D

¡Por los Dioses de Kobol! Pedazo artículo

w

Plas, plas, plas

La verdad es que creo que soy demasiado joven para la Hoja de cobol, creo recordar que cuando lo di...andábamos ya por los ordenadores a 33mhz monocromo,pero del organigrama me acuerdo perfectamente

Saludos
PD Y esta claro que las servilletas de bar son uno de los grandes impulsores de cualquier proyecto en este pais... porque para escribir van de vicio... pero para limpiar no valen , lo unico que hacen es esparcir el liquido

Saludos

LadyMarian

#1 Y la hoja de Cobol despertará los recuerdos...

Santimu

#18: Pues en la informática es en donde menos titulitis hay. En muchos otros trabajos directamente no puedes ni trabajar, porque porque la ley no te lo permite. Sin embargo los estudiantes de ingeniería informática somos los más atacados por esa razón, es curioso (bueno, no, teniendo en cuenta que en internet hay un gran porcentaje de gente que se dedica a esto).

Respecto al artículo, un profesor nos contó más o menos algo así (mucho más escueto). Y desde luego pone la piel de gallina, cosas que hoy se arreglan en cuestión de segundos, antes eran días. Desde luego se ha avanzado muchísimo en este campo, y estoy seguro que se seguirá avanzando mucho más.

D

Joder, el notas este debe ser de mi pueblo. La de tiempo que hacía que no escuchaba la palabra "cedazo" lol

D

Sin desmerecer el trabajo que hacian, que era evidentemente latoso, no comprendo como puede decir en el mismo articulo que sus programas requerian "cientos o miles" de tarjetas perforadas, a razon de una linea de COBOL por tarjeta y luego comenta como la productividad hoy dia tampoco es muy buena porque "en la actualidad es imposible poner en marcha ninguna nueva aplicación, por sencilla que parezca, en menos de seis meses".

Es que la complejidad del software que escribimos hoy dia es facilmente dos ordenes de magnitud mayor. En vez de "cientos o miles" de lineas de codigo, hablamos de cientos de miles o mas, dependiendo de tu area.

Dicho esto, el articulo me ha encantado

a

Cuando yo entré en la universidad politécnica de Madrid trabajé un año con las fichas perforadas. Fue el último año que las usaron. Yo en mi casa tenía ya un videogenie basado en el Z80, venia con un SO rudimentario y en la BIOS tenía un interprete de basic.

timonoj

Yo cuando leo estas cosas pienso "Ainnns, cuánto daño han hecho las consultoras...Y hasta dónde se habría podido llegar sin ellas"

iramosjan

Salvo porque ya teníamos pantallas (de riguroso fósforo verde) todo esto todavía lo viví yo a comienzos de los 80... snif, qué tiempos aquellos.

En lo único que difiero es en lo del 'código spagetti'. Eso no tenía por qué ser así si te montabas bien el ordinograma. Y por bien entiendo comienzo, actividades de arranque, núcleo de decisión central, y actividades de cierre del programa.

De ese 'núcleo de decisión central' saltabas (GOTO, of course) a rutinas y subrutinas que repetían ese esquema más o menos fijo. Si eras un programador competente el resultado no era un plato de 'spagetti' sino un árbol. El secreto estaba en no permitir saltos de acá para allá sino retornar siempre al núcleo de decisión. Claro que a veces eso era más fácil decirlo que hacerlo... pero como casi todos los programas eran procesos batch ABM (Altas, Bajas, Modificaciones) en ficheros y obtención de listados el método era eficaz.

iramosjan

#17 Yo no llegué a usar las hojas de codificación en el trabajo, salvo en el examen que me hicieron antes de contratarme..., pero sí cuando aprendía y hacía prácticas. Y había veteranos que primero escribían el programa en las hojas y luego lo picaban en el terminal (no en el ordenador, que era el host; en la pantalla "tonta" de fósforo verde) porque en la pantalla no se aclaraban ¡solo podían ver media página, eso no podía ser! ellos preferían tener en la mesa las hojas divididas en montoncitos, alguno parecía que reprodujese el flujo del ordinograma.

j

Increíble, no leía algo tan entretenido desde hace mil.

Esto va a recomendados... (casi lectura obligatoria)

D

De qué coño me quejo yo de java?? ( Si, java se puede debuggear, pero no cuando corre en un tomcat... bueno sí, sí que se puede, pero no si el eclipse peta porque el tomcat tiene más movidas... vamos que yo soy de la escuela del println y reinicio del tomcat cada cambio)
A veces pienso que la programación podría ser así siempre, se evatarían muuuuchos problemas actuales

D

#26 De mi eclipse no me baja ni el tato! X_D No en serio, es que se pueden enlazar los código fuente y javadocs con el eclipse, y tengo el culo pelao de usarlo... el netbeans no me enamoró en su día, qué le vamos a hacer?

D

#14 con netbeans es más fácil debugear cuando corre en un tomcat

j

Eso si era programar y no lo de ahora. Buen artículo.

B

Me encanta, aunque no este muy de acuerdo con algunas cosas como lo de "titulitis".

Cuando se empezó a hacer puentes probablemente el encargado de hacer el puente no tenía un título de ingeniero ni existía la ingeniería, si embargo nadie dice que en el gremio hay titulitis porque piden titulación para ello.

Pero bueno, ese es otro tema.

Comandante007

Sí, seguramente ahora los programas serán mas complejos (muchas veces innecesariamente). Pero esa forma de trabajar, ese amor por lo que se hacía se ha perdido y por eso ahora as cosas salen como salen... 6 meses para sacar un programa adelante ¡con suerte!... si las cosas se hicieran como antes, pensando en que si te equivocas tienes un marrón importante otro gallo nos cantaría...
Pero esto es aplicable a muchos otros ámbitos de la vida... nos hemos vuelto muy cómodos-vagos y muchas veces es mas fácil el método ensayo/error.

Aun recuerdo con nostalgía esos primeros programas en COBOL en mi pantalla de fosforo verde.... ayyy

D

Y yo me quejo muchas veces por usar turbo c roll

D

Joder copiaban los programas de cobol en las hojas de codificacion esas!! que infierno!

A

meneo!! Que la primera parte me encantó

jguijarro

Muy completo el artículo. Me ha traído muchos recuerdos.

k

Genial Artículo! Puede parecer un poco largo, pero merece la pena, no lo dudéis!

arn01d

"Plantilla para pintar organigramas", que recuerdos... utilizábamos una radiografía que se limpiaba con limón, se dibujaban los diagramas y se recortaban, listos para re-utilizar: inicio-let-print-fin

R

aqui otro currante de mainframe jejeje
esta bien ver que hacian los "dinosaurios" de la profesion

D

#29 Las consultoras.. y SAP y Navision o cualquiera que hubiera antes, la informatica para empresa ha perdido encanto con la entrada de las calculadoras con pantalla a color, los PC's (Esto seguro que si alguien ha trabajado en Agentes IBM conoce la definicion). Yo sigo en entornos Mainframes y como dice #10 seguimos diferenciando claramente los procesos Batch y los Interactivos.

El comando Sort aunque con pocas posibilidades nos ahorraba realizar las rutinas de ordenamiento, como el de burbuja o el de araña, que al ser compilados usaban mas ciclos de sistema.

D

ya poodia meter este articulazo en la wikipedia... impresionante. que tiempos esos de cobol.. sniff