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

51

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?

temptar
fuente
40
1.) Son caros 2.) Parece que no hay simulador o algo que pueda cargar en una máquina virtual (?) 3.) Uno debe usar corbatas cuando trabaje en mainframes. :)
Ingo
8
Si soy un desarrollador web por día, puedo hacer un poco de $$$ extra haciendo esto para otra persona en un fin de semana. No es así con los mainframes. Además, un desarrollador de mainframe no puede "conquistar el mundo" como lo hicieron Facebook, Twitter y Angry Birds. Finalmente, ¿hacer este trabajo me ayudará con el próximo?
Trabajo
86
Soy un joven programador. Nunca he visto un mainframe, nunca tuve un sandbox / mainframe virtual para jugar, nunca tuve un amigo que se me acercara y me dijera: "¡Esto es realmente genial, échale un vistazo!". Veo la web todos los días, hay herramientas de aprendizaje de desarrollo de aplicaciones web disponibles y gratuitas, y todos mis amigos están haciendo cosas interesantes en ella. ¿Cuál voy a elegir? (Aunque, si tuviera acceso a uno, me aseguraría de comprobarlo, solo porque podría ser interesante ... (Comente porque esto es esencialmente un +1 para las cosas que se dicen a continuación ...)
Beekguk
55
Si no has tenido un mainframe virtual para jugar, Beekguk, es porque no has ido a buscar uno .
SOLO MI OPINIÓN correcta
48
He estado programando durante unos 35 años y no sé qué quieres decir con "mainframe". Si tengo una máquina con 128 procesadores que ejecuta Unix, ¿es un mainframe? ¿O se refiere a máquinas que ejecutan sistemas operativos obsoletos, con aplicaciones escritas en idiomas obsoletos?
Kevin Cline

Respuestas:

98

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?

SOLO MI OPINIÓN correcta
fuente
11
"Si entré y descubrí que no me gustaba, ¿cómo salgo?" --- ¿salir?
Aaronaught
36
¿Dejar para dónde? Mis habilidades para mantener COBOL de 50 años no se transfieren a escribir aplicaciones web atractivas o aplicaciones para iPhone / Android o lo que sea.
SOLO MI OPINIÓN correcta
24
Si puede descubrir los entresijos de todo un ámbito de trabajo en dos meses, es un hombre mucho más brillante que yo
SOLO MI OPINIÓN correcta
11
@Aaronaught En un mundo competitivo de TI, si pasara el par de años que se necesitaría para llegar al comienzo de una velocidad razonable en los mainframes, no perdería sus habilidades anteriores, pero automáticamente sería menos atractivo cuando buscara otros trabajo, al igual que si hubiera pasado dos años haciendo silvicultura o administrando un Starbucks: lucir como si estuviera fuera del circuito, incluso un poco, no le favorece en comparación con alguien que no se ve de esa manera.
Matthew Frederick
55
@Aaronaught Estoy de acuerdo en que puedes salir y que no arruinará tu carrera para siempre, nada tan hiperbólico. Sostengo que lo haría menos competitivo, y que para la mayoría de los empleadores modernos no ayudaría a su carrera mucho más que otros trabajos de pensamiento: no utilicé "paisajismo" como ejemplo, utilicé trabajos que requieren pensar .
Matthew Frederick
59

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.
aceinthehole
fuente
20
+1: Esto concuerda bien con mi experiencia. El último recurso absoluto es poner nuevo código en los sistemas antiguos, y muchas de las líneas venerables se están quedando sin soporte, por lo que la antigua línea de "confiabilidad" está empezando a deteriorarse. Una cosa que no menciona es que el mantenimiento del mainframe es muy específico y muy exclusivo. Pones años de tu vida en una rama de tecnología muerta o moribunda. No le ayudará a conseguir ningún trabajo, excepto un trabajo que trabaje en el mismo tipo de sistema, y ​​hay menos de ellos todo el tiempo.
Satanicpuppy
Incluso en una economía generalmente mala, las ventas de mainframes de IBM están creciendo . No es realmente un crecimiento rápido , pero es más que sus competidores (recientemente pasaron a HP para tomar el primer lugar en ventas de servidores).
Jerry Coffin
Me inclino a deambular por lo que se considera "innovación" en la comunidad. Lo que he encontrado es que es una comunidad relativamente cerrada que conduce a una falta de conocimiento más amplio sobre lo que está sucediendo en el mundo del mainframe. ~ Estoy de acuerdo en que no es accesible para el alumno casual. En términos de IBM, aunque creo que abordar el acceso en las universidades es interesante, creo que algo como esto realmente debe abordarse particularmente en un mundo razonablemente bien conectado.
temptar
25

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.

Jeff
fuente
Interesante que digas eso. Soy un año menor que tú y he notado que es muy similar. Es más o menos por qué hice la pregunta.
temptar
Pensé que los chicos de mainframe eran pagados por camiones
Kemoda
2
Creo que si quisieras ganar un millón de dólares al año como programador, la forma de hacerlo sería ser el último tipo en BigAmericanBank que sepa cómo funcionan sus sistemas bancarios.
Warren P
¿Cómo es que gana menos dinero manteniendo los sistemas bancarios críticos, las personas que están en alerta, es decir, que reciben llamadas a las 2 AM, generalmente ganan más?
ALXGTV
19

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.

usuario1249
fuente
44
+ 1- No solo los servidores son caros, sino que las licencias también pueden ser excesivas para obtener cualquier tipo de interoperabilidad básica.
Morgan Herlocker
Sí, aunque IBM se dirige principalmente a organizaciones gubernamentales y corporativas más grandes. Se venden en entrenamiento y mantenimiento a primera vista. La licencia es solo una pequeña fracción del costo total de operar el sistema y las personas que necesita para mantenerlo en movimiento. ¿Por qué IBM cobra tanto? Es porque tienen personas especializadas para tratar con este dominio.
Chad
NO, es porque son conscientes de que pueden seguir jodiendo a sus clientes, que no tienen otra opción en el asunto. Se llama bloqueo por una razón.
Warren P
Es una industria extraña. No puedes jugar con mainframes en tu sótano, de la misma manera que no puedes jugar con, por ejemplo, motores a reacción en tu sótano, todavía hay personas trabajando en esos Dreamliners y F-35.
el.pescado
14

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.

Aaronaught
fuente
12
Tuvimos 4 programadores de mainframe de más de 20 años en mi tienda hace 6 años, y ahora no tenemos ninguno. No empieces a pensar que la experiencia te hará indispensable.
Satanicpuppy
1
@aaronaught: despedido, despedido, compra, renuncia. ¿Qué nuevas tecnologías? Es un entorno mainframe. No ha cambiado significativamente en 30 años. Nuevo hardware, sistema operativo actualizado, mismos programas malos. Cuando se fueron, descargamos el 95% de lo que hicieron a los sistemas externos, y hacemos el mantenimiento mínimo en el resto. Para mi corporación esto es más o menos cómo ha ido en los últimos 10 años más o menos.
Satanicpuppy
3
@aaronaught: Tienes que entender el proceso , pero el código generalmente puede dar un paseo. Se hacen tantas cosas para sortear las limitaciones del sistema. Si tengo que enviar un lote de tarjeta de crédito encriptada a nuestro proveedor de comerciantes (por ejemplo), en realidad es más fácil hacerlo desde una máquina Linux moderna. Y la presentación de informes es mucho más fácil: hacemos toneladas de informes y proyecciones, la mayoría de los cuales se realizan con datos históricos, por lo que podemos descargar conjuntos de datos y ponerlos en una base de datos moderna, y luego generar informes llamativos con informes de Crystal (o lo que sea).
Satanicpuppy
2
En C, ¿quizás el problema sea menos "pocos desarrolladores" y más "lenguaje más simple y estable, con menos preguntas que hacer"? No es sorprendente que C # genere muchas preguntas: el flujo interminable de nuevas API, etc., me recuerda joelonsoftware.com/articles/fog0000000339.html
Steve314
3
La programación se ha alejado de la abstracción de bajo nivel que ofrece C, y estamos mejor para ello. A menos que sea un desarrollador experto en C-only, escribir en C le llevará mucho más tiempo. E infinitamente más tiempo si eres un desarrollador de código-mono. Prefiero perder el tiempo resolviendo problemas interesantes que son específicos del dominio y no del lenguaje extraño / extraño.
Zoran Pavlovic
9

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.

Satanicpuppy
fuente
Saben, supongo, en algún nivel, incluso si no es consciente, que CUALQUIER lenguaje se puede usar en un mainframe, ¿verdad? Aquí hay una pequeña pista.
SOLO MI OPINIÓN correcta
@JUST: ¿Linux es un lenguaje de programación? Publicar un sitio de Linux te saca de quicio cuando eras joven. La gran mayoría de los mainframes se implementaron antes de que Linux alcanzara cualquier tipo de madurez. Una vez que los mainframes eran la regla, no la excepción: eran los servidores, y todos los terminales eran terminales tontos con pantallas verdes. Agrupar a las supercomputadoras modernas con esas un poco pierde el punto de la pregunta original.
Satanicpuppy
Satanicpuppy: Al parecer, a los jóvenes no se les enseñó a leer entre líneas, así que permítanme explicarlo: si pueden ejecutar Linux en un mainframe, pueden ejecutar gran parte del software de Linux en ese mismo mainframe. Eso significa que puede ejecutar la mayoría de los lenguajes de programación que se pueden compilar sin fragmentos específicos de la máquina. ¿Eso fue lo suficientemente claro? (Hay una razón por la que lo llamé una "pista" y no una "respuesta".)
SOLO MI OPINIÓN correcta
55
@just: ¿Con qué conectores para las bases de datos propietarias? ¿Con qué soporte para formatos numéricos patentados (BCD cualquiera?) ¿Por qué debería muckear en esa máquina? Simplemente te estás obligando a hacer MÁS trabajo en una máquina de la que deberías intentar alejarte.
Satanicpuppy
1
Ni siquiera necesita ejecutar LINUX. La generación actual de z / OS admite C, C ++, Java, etc. de forma nativa. El entorno USS es 100% compatible con POSIX (que es más de lo que se puede decir de Solaris).
James Anderson
9

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.

Jordán
fuente
Jordan, la mayoría de lo que tienes en * nix estuvo durante años en mainframes IBM. La alta redundancia y escalabilidad es muy atractiva y hay algunos indicios de que una unidad central tiene una huella de carbono / energía más baja (y, por lo tanto, el costo de energía) que una granja de servidores equivalente. Si esto es en última instancia vendible a largo plazo depende de si habrá personas dispuestas a manejar las cosas. No creo que lo haya.
temptar
8

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)

Jetti
fuente
Un rápido Google revela freebyte.com/programming/cobol : no recomiendo aprender COBOL, pero hay compiladores disponibles si decides hacerlo.
Steve314
Assembler también es una opción si no quieres ir a Cobol y, aunque no lo uso, es posible que puedas encontrar una herramienta de ensamblador en el emulador de Hercules.
temptar
6

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

XHR
fuente
1
No necesita una Z-Series 900 en su sótano. Puede ejecutar Hercules en su PC, incluso una antigua.
SOLO MI OPINIÓN correcta
No entiendo el argumento del "sótano". No puedes jugar con el motor a reacción en tu sótano, no hay tutoriales sobre cómo hacer un submarino y no hay software de código abierto para que jueguen los reactores nucleares, pero de alguna manera los ingenieros de todo el mundo aprenden esas cosas.
el.pescado
6

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).

Scott McIntyre
fuente
2
Pruebe "CAPS OFF" para usar minúsculas, "SYNTAX" para resaltar y verificar errores, sus registros tienen 32K de largo y luego puede editarlos con facilidad. La compilación interactiva ha estado disponible desde 1974, pero la mayoría de los programadores prefieren los trabajos por lotes en segundo plano por las mismas razones por las que los programadores de Java usan scripts ANT. Los depuradores han existido desde siempre.
James Anderson
Me imagino que podría haber un banco donde ninguno de los programadores sepa cómo usar el depurador de línea de comandos primitivo de los años 60 que viene con su dinosaurio gigante de un sistema operativo.
Warren P
6

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.

Sarah T
fuente
5

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.

Joshua Smith
fuente
Su ciclo simplemente suena como un proceso mal diseñado. Los mainframes pueden entregar fácilmente datos en tiempo real o casi en tiempo real. Es caro pero se puede hacer.
bot403
44
@ bot403: te creo. Los procesos mal diseñados son nuestra especialidad.
Joshua Smith
@Joshua, ¿alguna razón particular por la que se ve feo? ¿Y por qué otros idiomas te parecen mejores?
@Joshua Estoy en una situación sorprendentemente similar (aunque está en alza). Por lo que he visto, muchos de los principales redactores tienen un historial de procesamiento de datos en lotes. ¿Cuándo ejecutas un lote? A la medianoche. Los procesos toman 5 horas todas las noches porque hacen el trabajo de todo un día (o un mes) al mismo tiempo. Cómo algunos de ellos se perdieron todo el asunto de la "Programación dirigida por eventos" parece un poco extraño, pero el tiempo real no era una gran prioridad para los cuadros principales en los años 80.
Morgan Herlocker
2
@ Thorbjørn Ravn Andersen: No estoy menospreciando a los programadores de COBOL. El lenguaje simplemente parece innecesariamente detallado. No puedo entender cómo escribir MULTIPLY Num1 BY Num2 GIVING Result.cuando puedo escribirresult = num1 * num2;
Joshua Smith
5

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.

Michael K
fuente
3
+1 para nombres sin sentido. Estoy en el proceso de reemplazar un gran sistema ERP que estaba en RPG a .Net. El programador que lo escribió tenía antecedentes en algún idioma que tenía un límite de nombre de variable de 6 caracteres. Además de mantener viva esa convención, también continuó utilizando la notación de tarjetas perforadas en todos los archivos de código, por lo que cada uno tiene "CardID" y deben ejecutarse en el orden de la identificación de los archivos. Combine eso con casi nunca usar identificadores únicos o cualquier diseño relacional en los datos y eso casi nunca hace que quiera tocar un mainframe.
Morgan Herlocker
"El mayor problema que tengo es la falta de documentación disponible públicamente". +1 Además, posiblemente debido al perfil de edad de muchos mainframers, la comunidad de soporte de Internet está severamente limitada en comparación con otras ramas tecnológicas.
temptar
@Morgan: las bases de datos relacionales se inventaron en mainframes. La Serie i en particular usa una base de datos relacional para todo.
James Anderson el
1
Desafortunadamente, aún puede usar una base de datos de relaciones como un archivo plano, y algunas personas lo hacen.
Michael K
5

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.

Kaz
fuente
1
+1 para "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 compañías de mainframes se hicieran la misma pregunta".
Kyle Hodgson
3

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.

Tangurena
fuente
1
¿Hercules también simula los costosos y variados programas que necesita (solía ser cosas como IMS y CICS; DB2 ha reemplazado a IMS (o lo espero sincera y profundamente))?
David Thornley
1
Por supuesto, no simula el software. Debe adquirir ese software en otro lugar (o usar Linux / 390 o similar y hacer lo que quiera).
SOLO MI OPINIÓN correcta
1
@David, no, no incluye el software (caro). Solo el sistema operativo.
Tangurena
3

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.
James Anderson
fuente
Esto es exactamente lo mismo que Fortran es brillante y nuevo, con un estándar ISO recientemente revisado y sobrecarga del operador, orientación a objetos. Puede ser actualizado, pero irrelevante.
Kaz
2
Con respecto a la disponibilidad, ¿por qué no fabrican dispositivos pequeños que ejecutan la misma arquitectura? ¿Dónde puedo obtener una placa de $ 50 con z / OS integrado en un pequeño sistema en un chip? Por qué no?
Kaz
2
Por la misma razón, no puede obtener un sistema operativo actualizado para Hercules. Hay muchas aplicaciones de mainframe que tienen una carga de trabajo ligera pero son demasiado caras para reemplazar. Podrían ejecutarse fácilmente en el hardware de PC de hoy en día, pero si IBM lo permitiera, perderían las ventas de mainframe y los ingresos por licencias. ¡Capitalismo maravilloso!
James Anderson el
1
Había trabajado durante el verano a principios de los 90 en mainframes. La cultura fue un desvío para mí. Muchos de esos programadores de mainframe no sabían por qué o cómo funcionan las cosas y no parecían interesados ​​en ese tipo de cosas. Estaban usando COBOL85 que no soportaba conceptos tales como variables locales o cualquier cosa relacionada con una buena ingeniería de software. Era difícil acceder a información técnica detallada en mainframes porque gran parte de ella era de manuales caros que fueron tratados como tesoros sagrados encerrados de todos menos unos pocos.
Aprendiz de cola
1

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.

Darren Young
fuente
Eso es realmente genial. Es genial que también lo estés aprovechando. Si bien (la mayoría) de las personas parece tener problemas con los mainframes, ¡sería genial tener experiencia práctica con uno!
Jetti
Es genial hacer algo fuera del campo de vez en cuando y también porque hay un cierto elemento del mundo tecnológico en el que se encuentra, debido a cómo se utilizaron los mainframes en los negocios en los primeros días ... Espero que lo disfruten. Que te diviertas.
temptar
1

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.

Sam
fuente
0

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.

MattBelanger
fuente
0

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

Ken Dawson
fuente