¿Por qué los programadores jóvenes no están interesados ​​en mainframes? [cerrado]

Un problema clave con los mainframes es que la cohorte de programadores de apoyo está disminuyendo. Si bien normalmente esto no sería un problema, ya que una disminución de la oferta de programadores se vería compensada por una cantidad cada vez mayor de salario, lo que provocaría un aumento de la oferta de programadores a través de la ley de oferta y demanda, no estoy seguro de que esto esté sucediendo realmente para mainframes

Si bien todavía forman una infraestructura crítica para muchas empresas, el simple hecho es que no hay un número adecuado de programadores jóvenes que se acerquen para mantener poblada la población de apoyo.

¿Por qué es esto? ¿Qué hace que los mainframes no sean atractivos para los programadores jóvenes?

Soy un viejo programador y no estoy interesado en mainframes. Sin embargo, mis razones probablemente serán similares a las razones dadas por los programadores jóvenes, aunque sin el desconocimiento de la tecnología tan evidente en muchas de estas respuestas.

Primero, eliminemos la ignorancia:

• Las diversas afirmaciones de incapacidad para probar mainframes son falsas. Hércules ha estado disponible desde 1999, probablemente durante más tiempo del que muchas de las personas que respondieron han estado programando, y a pesar de que IBM se quejó, las probabilidades de que desaparezca pronto son insignificantes (especialmente dado que es de código abierto). Si bien, de hecho, es cierto que no puede (legalmente) ejecutar el software costoso para él, hay un montón de software disponible que puede ejecutar en él, incluido el software que en realidad todavía es de uso bastante común.
• Nuevamente, a diferencia de la opinión pública, hay más en mainframes que COBOL, CICS y RPG2. De hecho, casi (pero no del todo) cualquier cosa que pueda ejecutar en su PC con Linux puede ejecutarla en un mainframe. <irony> No estoy seguro de por qué. </irony>

Entonces, ¿por qué evité los mainframes durante toda mi vida después de encontrarlos en la escuela? Bien:

• Si bien es cierto que puede usar más que COBOL, CICS, RPG2, etc. en mainframes, las probabilidades son muy altas de que si trabaja con ellas, esto es lo que quedará relegado a hacer. Peor aún, a pesar de que COBOL se ha "modernizado" masivamente en las últimas dos décadas (citas de miedo porque todavía no creo que sea un lenguaje muy moderno), la mayor parte de la codificación que hará en COBOL seguirá siendo antigua código de estilo porque ...
• Hay muy poco desarrollo nuevo real en mainframes. Si consigue un trabajo en IBM trabajando para su división de I + D de mainframe, podría tener la oportunidad de hacer un nuevo desarrollo (¡y en ese caso, incluso podría disfrutar realmente su trabajo!). Sin embargo, en realidad, acéptelo: no trabajará allí. Trabajará en la trastienda de alguna institución financiera u otra manteniendo el código COBOL de 50 años escrito por alguien que todavía piensa que 64 KB es un enorme montón de cosas. (Este mismo tipo probablemente será tu jefe).
• Si bien es cierto que puede ejecutar Linux en mainframes y, por lo tanto, tener acceso a prácticamente cualquier lenguaje de programación o entorno que desee, una vez más, al trabajar para la investigación y desarrollo de mainframe de IBM, no obtendrá ese trabajo. Es volver a mantener ese COBOL de 50 años.
• La programación corporativa es muy eficiente para chuparte el alma (y recuerda, es la programación corporativa que harás como programador de mainframe a menos que tengas MUCHA suerte).
• Es un ghetto y cada vez más pequeño. (Es como MUMPS de esta manera.) Si te sumerges demasiado en la tradición de mainframe, te alejas más de cualquier cosa que no sea mainframe. Puedes probarmantener el ritmo, pero no lo harás. Sé que alguien señaló que los mainframes han crecido en ventas mientras que otros sectores de servidores se han reducido un poco, pero la programación de servidores es la minoría en estos días. Las computadoras infernales en general están perdiendo importancia. El mundo de la programación es muy amplio y muy diverso, y el hecho de que una porción minúscula crezca en comparación con otra porción minúscula no tiene sentido en comparación con, por ejemplo, el crecimiento repentino y explosivo de la programación en algo tan trivial como el iPhone (que en sí mismo es una plataforma minoritaria, de lejos). No, comience a trabajar en mainframes y solo tendrá otros mainframers para compartir sus pensamientos, alegrías y rabia, y son una raza moribunda. Esto conduce a un ciclo de retroalimentación negativa que hace que el rebaño se reduzca aún más y más rápido.

Estoy seguro de que hay muchas razones por las que un programador de mainframe podría explicar por qué la carrera es gratificante y llena de alegrías y desafíos interesantes. De hecho, he escuchado muchos de ellos de personas que intentan reclutarme en el campo. Al final, sin embargo, no me convencí, principalmente debido al problema del gueto. Si entré y descubrí que no me gustaba, ¿cómo salgo?

Tengo 27 años y he sido desarrollador profesional durante más de 4 años (así que espero que eso me califique como todavía joven). También trabajo como especialista en integración, por lo que tengo mucha exposición al mundo del desarrollo de mainframe.

1. Parece que hay poca o ninguna innovación en la comunidad.
   Sé que este no es exactamente el caso, pero para el observador casual lo parece. Nadie quiere involucrarse en un área donde es difícil 'dejar su huella'.
2. ¿Cuánto desarrollo nuevo o proyectos nuevos están sucediendo?
   Ninguno por lo que puedo decir. Si entras en esta área, te estás condenando a ser un programador de mantenimiento para siempre.
3. No es accesible para el alumno casual.
   La mayoría de las personas comenzaron a aprender a programar en su PC en casa. Nuevamente, a la mayoría de las personas no les gusta cambiar de lo que saben. Por lo tanto, hacer la transición de uno a otro requiere tiempo y motivación. Dadas las otras 2 razones, no hay muchos interesados.

Cumpliré 40 años en septiembre, así que no sé si eso ya me califica como joven, pero tengo conocimiento personal de por qué alguien podría no querer ser un programador de mainframe.

Los últimos 10 años de mi vida laboral me han dedicado a la programación de mainframe. Aprendí todo lo que hay que saber sobre batch, jcl, Cobol, Assembler, Easytrieve, CICS y Web Services y lo disfruté inmensamente y aún lo estaría haciendo si no fuera por notar una tendencia. Mi último lugar de trabajo me hizo trabajar codo a codo con desarrolladores web (jsp, javascript, spring e hibernate) y noté que la compañía estaba trayendo desarrolladores web con años de experiencia comparables por mucho más dinero. Sin mencionar el hecho de que la posición de los desarrolladores web era mucho menos estresante.

Después de hartarme de esta tendencia, decidí salir del negocio de mainframe. Ahora estoy en una posición en la que desarrollo servicios web con Java y la interfaz de usuario front-end con javascript. Este estilo de programación no es más difícil que lo que hice en el mainframe, pero ahora gano más dinero y tengo menos dolor de cabeza. Ya no recibo esa llamada a las 2:00 am de que algo se anuló y los procesos centrales del sistema me están esperando para solucionar mis problemas. Entonces, ¿me da una buena razón por la que me quedaría como programador de mainframe cuando puedo ganar más dinero y tener menos estrés en mi vida como programador de sistemas distribuidos?

Estoy seguro de que hay circunstancias en las que las empresas pagan tanto a los mainframers como a los sistemas distribuidos, pero personalmente no los he encontrado. Además, comencé a hacer búsquedas de trabajo desde ambas perspectivas y descubrí que los listados de trabajos de sistemas distribuidos superaban en número a los listados de trabajos de mainframe al menos 10 a 1. Eso me dice que en este momento para tener mejores oportunidades de trabajo, el mainframe no es el lugar para ser.

Por lo que he visto hasta ahora, y en comparación con Linux y Windows, el problema básico con mainframes y midframes es que DEBE pagar por adelantado para usarlos. Y paga mucho. Todos los años. Para todo.

Esto simplemente no es la forma de hacer que los estudiantes se interesen en algo, porque no pueden pagarlo. Si no les interesa, probablemente no lo harán voluntariamente.

Lamentablemente, el modelo de negocio de IBM no permite que las máquinas estén disponibles de forma económica para los estudiantes, o podrían tener la oportunidad de cambiar esto.

Uno de mis primeros trabajos de verano como programador se basó principalmente en eliminar pantallas verdes y archivos PRN. En aquel entonces, probablemente no me hubiera importado ensuciarme las manos en COBOL (es decir, si hubieran confiado en mí lo suficiente como estudiante para dejarme entrar en ese código), pero no estoy seguro de si sentiría lo mismo por el La misma perspectiva hoy.

No creo que el problema sea realmente con los mainframes per se. Es la obsesión de nuestra industria (a menudo justificada) con lo nuevo y brillante.

Mire C. C es obviamente un lenguaje críticamente importante. Casi todo el código incrustado y la mayoría de los sistemas operativos están escritos en C. No irá a ningún lado pronto. Y, sin embargo, cada vez es más difícil encontrar programadores en C. Un vistazo rápido en la página de etiqueta de desbordamiento de pila lo coloca a 1/6 del tamaño de [c#]y 1/4 del tamaño de [java]. ¿Alguien recuerda cuando C era esencialmente el lenguaje dominante, posiblemente el único juego en la ciudad?

Los programadores aman las herramientas poderosas. Tal vez sea porque (ALERTA DE ESPECULACIÓN) la mayoría de los programadores son chicos. Le da a un programador de Java o .NET la tarea de, por ejemplo, copiar un archivo, y muchos, si no la mayoría, aún elegirán escribirlo en Java o C # en lugar de escribir un archivo por lotes de DOS o un script de shell * nix que sería 50 veces más rápido de escribir y desplegar. ¿Por qué usar una caña y un carrete para atrapar un pez cuando tienes una red gigantesca retráctil que puede atrapar 500 peces?

Sí, COBOL y PL / I son viejos , pero también lo es Pascal, y todavía está vivo y pateando en forma de Delphi. La aversión a la primera probablemente se debe al hecho de que esos idiomas son difíciles de manejar en comparación con las herramientas modernas. La orientación a objetos sigue siendo un concepto relativamente nuevo en el mundo COBOL (énfasis en relativamente ), pero en el mundo C #, LINQ y los genéricos y AJAX dejaron de ser revolucionarios hace años. Pedirle a un desarrollador acostumbrado a esas herramientas que comience a programar en mainframes es como pedirle a un músico de rock que comience a tocar en un banjo.

Por supuesto, también existe el problema del estereotipo de autoperpetuación. Como siempre y cuando los programadores más jóvenes creen que no hay nada para ellos en unidades centrales (si es o no es cierto), entonces cualquier programadores jóvenes que no optan a entrar en ella va a terminar pasando la mayor parte de sus días rodeado de gente mucho mayor. Para empezar, no es una profesión socialmente atractiva, pero el desincentivo agregado de una brecha generacional tiende a colocarla por debajo de los umbrales de dolor de muchas personas. Sin ánimo de ofender, personalmente he pasado la mayor parte de mi vida trabajando con personas mucho mayores, pero no todos tienen esos antecedentes o esa capacidad.

Finalmente, la mayoría de los programadores no disfrutan el trabajo de mantenimiento, y casi todo el trabajo de mainframe es mantenimiento. No se está escribiendo mucho software nuevo en PL / I. Cualquier trabajo que se defina por completo o en gran medida en torno al código de mantenimiento comienza automáticamente con una puntuación negativa.

No son positivos a trabajar en el código heredado ( "legado" que abarcan mainframes y muchas otras cosas), que es probable que necesite para jugar arriba si usted está tratando de atraer a un público más joven:

• Los sistemas son, como usted dice, infraestructura crítica. Los desarrolladores más jóvenes, al menos en el mundo de los negocios (no Google / Microsoft), a menudo no tienen la oportunidad de tener un impacto real . Es desalentador trabajar en un sistema que sabe que será abandonado o reemplazado después de unos meses o años. Las aplicaciones de mainframe que ya se han estado ejecutando durante 50 años probablemente se ejecutarán por mucho más porque no tiene sentido que las empresas las reconstruyan, por lo que el trabajo que realiza en ellas es realmente importante para mucha gente.

• Si usted es una de esas pocas empresas que realmente no tienen una inclinación a "actualizar", entonces un montón de programadores, jóvenes y viejos, serán atraídos por esa oportunidad, porque entonces no son gemelas oportunidades para trabajar en código de misión crítica y flexionar algunos de esos músculos C # / Java. Obviamente, ninguna compañía sensata simplemente desecharía el mainframe y reconstruiría desde cero, pero he visto sistemas que (por ejemplo) tienen un núcleo COBOL que se integra con componentes Java.

• Finalmente, está la indispensabilidad, al menos, como la percibimos los de afuera. Cuando todo su código está en .NET, siempre existe el riesgo de que los propietarios lo cambien por un graduado recién salido de la universidad o, peor aún, un equipo offshore, en un intento equivocado de reducir costos. No creo que eso ocurra muy a menudo en el mundo de mainframe, especialmente si lo que usted dice es cierto y la oferta parece estar disminuyendo. Por supuesto, este punto es discutible si no paga lo suficiente; los salarios deben ajustarse para reflejar esa disminución de la oferta, de lo contrario la gente no "venderá".

Estoy seguro de que hay muchos desarrolladores más jóvenes que no rechazarían una oferta razonablemente generosa de una compañía que parecía estar haciendo todo lo posible para que el ambiente de trabajo sea atractivo para los empleados más jóvenes. Pero si desea llegar a ellos, entonces sería prudente aprovechar sus puntos fuertes, e incluso podría tener que comenzar a hacer algo de marketing; tendemos a ver los mainframes como un mundo diferente y muy extraño, y estoy bastante seguro de que no los vi en la feria de empleo del campus hace 10 años trabajando para cambiar esa percepción.

Para resumirlo en una sola oración: nada hace que los mainframes sean poco atractivos , es solo que nada los hace atractivos tampoco, y eso los pone en una grave desventaja en comparación con el borde sangriento que nos ofrece enormes aumentos de productividad y refrescos gratuitos.

Soy joven (mediados de los años 30) y actualmente trabajo en soporte de mainframe. RPG, COBOL, propiedad 4GL basura. El desarrollo es lento y, cuando es posible, se migra a un hardware más moderno utilizando lenguajes más modernos.

El desarrollo del mainframe es tan engorroso en comparación con los sistemas modernos que el mainframe en sí mismo tiende a quedar relegado al back-end, mientras que los lenguajes más modernos se utilizan para hacer los tipos de informes y transformaciones de datos que solían realizarse en el mainframe. En este punto, incluso hemos convertido la mayor parte de la entrada de datos en un proceso impulsado por lotes, por lo que lo único que queda en el servidor está relacionado con la facturación.

Si bien puede parecer un buen nicho para entrar, creo que muchas empresas se están dando cuenta de que realmente ya no necesitan estos sistemas. El cambio ocurre lentamente en el mundo de las finanzas, pero sucede.

Personalmente, no entiendo cuál es la ventaja comercializable para los mainframes.

¿Número rápido y procesamiento de datos? ¿Por qué no puedo distribuir eso en una granja para su procesamiento o comprar un servidor "normal" robusto?

¿Alta redundancia y escalabilidad? Prefiero tener una granja de servidores Linux o un conjunto de servidores virtuales.

¿Virtualización y múltiples sistemas operativos? ¿Quizás haya una diferencia de rendimiento considerable para usar esto en lugar de una estrategia de "nube"?

Si bien me encantaría entender todas estas cosas con más detalle, la falta de explicaciones útiles de lo que diferencia a un mainframe es la razón principal de por qué no programo para esos sistemas.

Tengo 25 años y actualmente estoy en un programa MSCS (mi experiencia no es CS) y definitivamente estoy interesado en mainframes. El problema es que no estoy seguro de por dónde empezar. He visto COBOL y no sé dónde obtener un compilador decente (ni siquiera estoy seguro de qué es un compilador decente para COBOL, sé que hay un compilador de código abierto, pero no estoy seguro de qué calidad tiene). Simplemente no veo mucha información y, para ser honesto, el tiempo dedicado a buscar ese es el tiempo en el que podría estar trabajando activamente en un proyecto en .Net o Java (prefiero .Net pero el trabajo escolar está en Java) . Al igual que @Joshua Smith, me preocupa que si me metiera en mainframes sería mi vida, pero también me parecen más interesantes que las aplicaciones web y toda la moda de la Web 2.0 (llámame loco). Para mí, sin embargo,

La conclusión es esta:

(1) La información no está disponible para que yo aprenda lo que necesitaría aprender a hacer la programación de mainframe
(2) En este punto de mi vida, solo quiero poder programar para vivir y .Net y Java me permiten que trabaje para lograr este objetivo mientras estoy en la escuela porque hay muchos recursos a los que puedo recurrir y aprender lo que necesito para obtener un portafolio al final de mi carrera académica
(3) Me sería difícil quedarme atascado hacer algo que no disfruto y la posibilidad de quedarme atascado solo haciendo mainframes para una carrera es algo que me asusta (aunque sé que hay formas de evitarlo, como repasar cosas nuevas en mi tiempo libre y contribuyendo al código abierto)

Esta es solo mi perspectiva personal como joven programador. Nunca he trabajado en un mainframe antes, así que no puedo hablar de experiencia de primera mano en uno. Pero, esa es la cuestión, nunca he trabajado en uno y no preveo que sucederá pronto. No estoy seguro de dónde desea trazar la línea entre el mainframe y un servidor simple, pero cuando pienso en el mainframe, imagino que una gigantesca máquina IBM como la Z-Series 900 consume $ 35 / día solo en electricidad. No voy a tener uno de esos en mi sótano para jugar en mi tiempo libre. Especialmente cuando puedo tomar una máquina vieja, lanzar ubuntu-server en ella y alojar lo que me apetece muy fácilmente. Si tengo un problema, la comunidad de Linux es enorme y es probable que alguien más haya encontrado mi problema y haya publicado una solución en línea. Solo estoy adivinando

Comencé a trabajar en mainframe cuando ingresé a la fuerza laboral hace 10 años. Nunca antes había tocado un mainframe.

Hubo varios aspectos que no disfruté, por lo que dejé de hacer mainframe tan pronto como pude:

1. La edición del código fue muy primitiva. Básicamente, solo trabajabas en un editor de texto, fijo a TODAS LAS MAYÚSCULAS y 80 líneas de caracteres. No se completó el código ni se verificó la sintaxis.
2. La compilación se realizó iniciando un trabajo por lotes, que luego se programó y ejecutó en algún momento, generalmente en los siguientes 5 minutos si tuvo suerte. Si tuvo un error tipográfico y el código no se compiló, repítalo varias veces.
3. No hubo depurador de ningún tipo. La depuración se realizó imprimiendo valores variables y repitiendo ese largo paso de compilación.
4. Los cambios que hicimos siempre fueron increíblemente conservadores. Estábamos construyendo sobre 20 años de código heredado donde la única documentación estaba escrita a mano en papel en un archivador, en algún lugar. Además, este era un código financiero, por lo que no había tolerancia para los errores. Entonces, el paso de codificación real fue mínimo en comparación con la investigación que se requería de antemano.

(OTOH, tenían control de versiones muy avanzado y promoción de código, por el período de tiempo).

Dos razones para considerar unirse a la fuerza laboral de mainframe:

1. Paga bien
2. Hay toneladas de aperturas

La fuerza laboral canosa en el campo de mainframe es, y creará un gran número de aperturas en el campo.

Trabajo para una gran compañía financiera y, en los próximos 5 años, perderemos aproximadamente el 30% de nuestra fuerza laboral al jubilarnos. Ese número aumentará exponencialmente en 10-15 años.

Más razones:

• He estado en el campo por más de 25 años y nunca me aburrí.
• Menos competencia por el trabajo.
• Deje de quejarse de la tecnología (vea algunas publicaciones anteriores) ... puede ser antigua, pero en muchos sentidos está a años luz de los sistemas abiertos. HTML: dame un descanso. Es muy similar a Basic que tomé hace 30 años en la universidad. Estamos mucho más allá de eso.
• El mainframe es rápido y confiable, probado y verdadero.
• Pruebe la Programación de sistemas si es muy brillante y le encantan los problemas de resolución de problemas.
• Como líder de equipo, desearía poder encontrar técnicos jóvenes y capacitados para llenar vacantes.
• ¿Mencioné que paga bien?
• Otras opciones profesionales de mainframe además del desarrollo de software: ingenieros de hardware, técnicos de almacenamiento, redes y más.
• Es divertido, emocionante, desafiante y hay un gran crecimiento profesional.
• Deje de pensar en mainframe como solo una tecnología antigua: compruébelo y verifique todo lo que he dicho.

Consulte también la Iniciativa académica System z de IBM.

Todavía soy un programador joven (tengo 29 años) y definitivamente no estoy interesado en aprender a desarrollar para el mainframe. Trabajo para una compañía de seguros en un equipo .NET, pero también trabajamos con un gran equipo de programadores de mainframe de la vieja escuela.

Hay algunas cosas que hacen que el mundo de mainframe no sea atractivo para mí. Primero, hay COBOL. Entiendo que gran parte del mundo funciona con COBOL, pero eso no hace que el lenguaje sea menos feo para mis ojos.

A continuación, está el concepto del 'ciclo'. No sé si esto es común a los mainframes o es solo la forma en que hacemos las cosas, pero nuestro mainframe tiene que ejecutar un ciclo nocturno antes de que podamos obtener datos actuales de él. El lado .NET de nuestra tienda está muy involucrado en el envío de datos y el manejo de datos desde el mainframe (específicamente, mostrando una tonelada de datos en un sitio web interno de LOB para agentes). La empresa desea que los datos que se muestran a los agentes estén actualizados al minuto. Sin embargo, el mainframe no funciona dentro de mi concepto (limitado) de tiempo real. Tenemos algunas soluciones alternativas para simular en el sitio web lo que esperamos que sea la salida real del mainframe al día siguiente.

Finalmente, creo firmemente que si tuviera que avanzar hacia el desarrollo de mainframe en este punto, llegaría a dominar mi carrera. Creo que mis habilidades como desarrollador moderno se retrasarían cada vez más, llegando finalmente al punto en que el mantenimiento de COBOL sería mi única opción. Sé que hay mucho dinero por hacer, ahora y especialmente dentro de diez años, pero el dinero es cuarto o quinto en mi lista de prioridades para mi carrera. Prefiero seguir ganando mi salario decente si eso significa trabajar en cosas nuevas e interesantes.

Trabajo principalmente con Java, pero usamos mainframes para nuestro backend, lo que significa que tengo que lidiar mucho con ellos (RPG). El mayor problema que tengo es la falta de documentación disponible públicamente. Puede encontrar documentación SQL para DB2 que se traducirá principalmente a iSeries DB2, pero publib.boulder es horrible en comparación con los javadocs de Sun.

Otra cosa que no me gusta es la sintaxis difícil de leer de los principales idiomas de mainframe. RPG no tiene el concepto de alcance local, lo que significa que necesita enormes bloques de declaración de variables. Creo que Cobol sufre el mismo problema. También conduce a nombres de variables sin sentido y significados ocultos. También tiene muchas, muchas funciones integradas diferentes que me cuesta encontrar (ver más arriba). Me recuerda por qué ya no uso BASIC para una programación seria. Afortunadamente, IBM está tratando de trasladar a todos a Java, pero esos lenguajes heredados no desaparecerán pronto.

Me resulta difícil entusiasmarme con aprender a programar en un entorno como este.

Mira, tengo 42 años y no me interesan los mainframes. Bueno, califiquemos eso. Estoy interesado en la historia de la informática. He estudiado arquitecturas de mainframe hasta cierto punto, y entiendo cómo, por ejemplo, los mainframes de IBM influyeron en arquitecturas de microprocesadores como Motorola 68000 u 80386. En la década de 1960, los mainframes ya brillaban a velocidades superiores a 30 Mhz y lucían sistemas operativos multitarea avanzados con sistemas virtuales. recuerdos. Para las personas acostumbradas a esos entornos, los primeros microprocesadores fueron decepcionantes en muchos aspectos, y las arquitecturas basadas en microprocesadores tardaron bastante en ponerse al día con capacidades y rendimiento similares.

Pero ponerse al día con esas arquitecturas lo hizo, y los mainframes dejaron de ser "modernos" hace mucho tiempo. Sucedió cuando los piratas informáticos podían tener minicomputadoras en sus bancos y poco después las estaciones de trabajo con Unix.

Los mainframes han sido ajenos a los programadores jóvenes desde principios de 1980, algo así. Ese podría haber sido un excelente momento para que las empresas de mainframe se hicieran la misma pregunta.

Hoy la respuesta es recursiva entre generaciones: los jóvenes programadores no están interesados ​​en mainframes porque incluso si tienen padres o maestros interesados ​​en la informática, esos padres y maestros (más de 40 años como yo) ya no estaban interesados ​​en hacer nada con mainframes por trimestre hace siglo.

¡De todos modos, hoy en día, un teléfono celular puede manejar las tareas que las computadoras centrales se usaron hace 30 años! Las granjas de servidores de bajo costo son el nuevo mainframe. Entonces, en cierto modo, hoy hay nuevos programadores de mainframe, solo que su especialidad es juntar máquinas en red para construir nubes. En un momento, podríamos decir que Mark Zuckerberg y su pandilla estaban haciendo un nuevo tipo de programación de mainframe cuando produjeron Facebook, en el sentido de que no se trata solo de una pequeña aplicación que solo se ejecuta en un microprocesador simple con un disco.

Por cierto, una de las últimas especialidades del mainframe fue la virtualización. Pero eso ahora es omnipresente en las máquinas de escritorio / servidor. La gente comenzó a hacerlo mal al principio, utilizando técnicas de software. Las máquinas virtuales fueron tan útiles que a los usuarios no les importó el impacto en el rendimiento. Luego, compañías como Intel volvieron a mirar el mainframe y aprendieron un par de lecciones más al apoyar la virtualización en hardware para que sea más rápido.

Aprender el desarrollo web, de teléfonos móviles o PC es bastante barato y fácil.

Los costos de hardware incluso para un viejo mainframe son terriblemente altos, e IBM con frecuencia se molesta por el proyecto del emulador Hercules (que le permite emular System / 370, ESA / 390 y zSeries). Sin Hércules, esto hace que los costos de entrada para aprender la arquitectura de mainframe y el desarrollo de aplicaciones estén fuera del alcance de todos menos los aficionados más adinerados.

Ninguna universidad a la que he asistido desde los años 80 ha tenido una computadora central disponible para el uso de los estudiantes. Creo que IBM y el resto de los fantasmas de la industria de mainframe se dispararon en el pie haciéndolos menos accesibles para el aprendizaje.

Comencemos con algunos datos sobre mainframes de IBM y específicamente zSeries.

El hardware es totalmente nuevo y brillante. Contiene algunos de los diseños electrónicos y de chips más avanzados disponibles y son rápidos.

Si bien z / OS tiene sus raíces en la década de 1960, ha experimentado un desarrollo continuo y al menos dos reescrituras completas, por lo que, aparte de las peculiaridades resultantes del fetiche de IBM por la compatibilidad con versiones anteriores, es probablemente uno de los sistemas operativos más nuevos de uso general.

Los puntos clave de venta son: -

• La compatibilidad con versiones anteriores antes mencionada si un programa se ejecutó en 1976 en una máquina MVS / MVT, es probable que se ejecute en la última zSeries sin volver a compilarse y producir exactamente los mismos resultados.
• Ancho de banda puede mover el acceso y almacenar cantidades masivas de datos, a una velocidad masiva y a un nivel de grano muy fino.
• Disponibilidad. SYSPLEX, que ha estado disponible durante los últimos 15 años, proporciona una agrupación sin interrupciones en varios sitios, completa con equilibrio de carga, conmutación por error automática, etc., gran parte de la cual se implementa en hardware. Hace que la mayoría de los clústeres * nix parezcan primitivos.
• Convergencia. Este suena un poco extraño, pero con el soporte completo de POSIX y una JVM súper rápida, un mainframe moderno es prácticamente indistinguible de cualquier otro * NIX box si así es como quieres usarlo.

Hasta ahora, el mainframe ha sobrevivido a casi todo lo que los expertos dijeron que lo reemplazarían.

Hay una serie de inconvenientes: -

• La compatibilidad con versiones anteriores significa que muchas tiendas ejecutan sistemas de veinte, treinta y en algunos casos de cuarenta años. Si bien funcionan bien y desempeñan bien sus funciones comerciales (¡o aún no estarían funcionando!) Reflejan los estilos de codificación y las obsesiones de una época pasada.
• cultura atrasada. Los programadores que trabajan en un gueto de antiguos sistemas COBOL no parecen haberse dado cuenta de que el mundo ha avanzado, o si lo hacen, una administración fosilizada no los dejará.
• Falta de disponibilidad. A menos que te paguen por trabajar en uno de estos monstruos, no tendrás acceso a uno. Incluso puede haber uno en el que trabaje, pero si la descripción inmediata de su trabajo no incluye trabajar en él, no obtendrá un inicio de sesión. Mucho se ha dicho en otras publicaciones sobre el software de emulación "herecules" y de hecho es excelente, pero es solo para expertos, ejecuta una versión antigua del sistema operativo, carece de la mayoría de los componentes estándar como CICS, COBOL y DB2 que forman el marco de trabajo de la mayoría de las aplicaciones mainframe en ejecución.

Es gracioso que debas preguntar esto. Acabamos de hablar en la Universidad sobre mainframes, y de que IBM está disgustado con el nivel de los desarrolladores de Mainframe, de modo que están implementando un módulo de mainframe en nuestra Universidad, enseñándonos programación de mainframe y teniendo acceso a uno de sus mainframes de forma remota.

De hecho, estoy tomando este módulo en septiembre, puede que no sea algo que vuelva a hacer, pero me dará la oportunidad de trabajar en algo 'diferente' y abrir los ojos a nuevos paradigmas.

Tengo 28 años y he sido desarrollador profesional durante 10 años. Pasé 3 años trabajando en una computadora central.

El ambiente era esotérico, rancio, estancado, confuso (¿JCL e ISPF alguien?). Dicho esto, tenía un enorme respeto por el sistema, cómo funcionaba todo, la escala del mismo. El sistema tenía algo así como 150M SLOC, era compatible con una granja de servidores UNIX de rango medio a través de SOA y literalmente corría una gran parte del país.

Dicho esto, ¿por qué los jóvenes programadores no están interesados? Aquí está mi opinión, como programador "joven" (comencé a usar este sistema a los 23 años). Ten en cuenta que esta es mi perspectiva desde el sistema en el que estaba trabajando, y la investigación que hice:

• Hay poco desarrollo nuevo de mainframe. Mucho de esto es legado.
• Hay enormes barreras de entrada.
• El trabajo realizado es para finanzas, grandes empresas y gobierno. Nada de esto es sangriento.
• Las herramientas de desarrollo son antiguas y en gran parte anticuadas. La depuración no se parece en nada a VS.

Los mainframes siempre tendrán un lugar en la economía. Simplemente no manejan negocios tempranos debido a sus enormes costos y requisitos de soporte.

Si bien creo que probablemente haya un trabajo muy interesante en los mainframes, me aterrorizaría realmente mover mi carrera en esa dirección. Existe una posibilidad demasiado grande de que 10 años después, mi experiencia se haya vuelto inútil y no haya trabajo disponible para un programador de mainframe. No quiero quedarme obsoleto pasando mucho tiempo en una tecnología estancada con una base de instalación cada vez más reducida.

Esa respuesta es que no hay futuro en ello. Tengo veintidós años de experiencia como programador de mainframe y he estado sin trabajo durante cinco años. Voy a volver a la escuela para obtener mi licenciatura en desarrollo web. ¿Por qué alguien en su sano juicio querría ser un programador COBOL de mainframe?

Conocer