Dlaczego młodzi programiści nie są zainteresowani komputerami mainframe? [Zamknięte]

Kluczową kwestią w przypadku komputerów mainframe jest to, że kohorta programistów wspierających się kurczy. Podczas gdy normalnie nie byłoby to problemem, ponieważ zmniejszająca się podaż programistów byłaby kompensowana przez rosnącą pensję powodującą rosnącą podaż programistów dzięki prawu podaży i popytu, nie jestem pewien, czy tak naprawdę dzieje się w przypadku komputery mainframe.

Mimo że nadal stanowią one infrastrukturę krytyczną dla wielu firm, prosty fakt jest taki, że nie ma wystarczającej liczby młodych programistów przybywających, aby utrzymać populację wsparcia.

Dlaczego to? Co sprawia, że ​​komputery mainframe są nieatrakcyjne dla młodych programistów?

Jestem starym programistą i nie interesują mnie komputery mainframe. Moje powody prawdopodobnie będą podobne do podanych przez młodych programistów, aczkolwiek bez nieznajomości technologii tak oczywistej w wielu z tych odpowiedzi.

Najpierw usuńmy ignorancję:

• Różne twierdzenia o niemożności wypróbowania komputerów mainframe są fałszywe. Hercules jest dostępny od 1999 r. - prawdopodobnie dłużej niż wiele osób, które biorą udział w programowaniu - i pomimo tego, że IBM żałuje, szanse na jego odejście w najbliższym czasie są znikome (szczególnie biorąc pod uwagę, że jest to oprogramowanie typu open source). Chociaż prawdą jest, że nie można (legalnie) uruchamiać dla niego drogiego oprogramowania, istnieje wiele dostępnych programów, które można na nim uruchomić, w tym oprogramowania, które jest nadal w powszechnym użyciu.
• Ponownie, w przeciwieństwie do opinii publicznej, w komputerach mainframe jest więcej niż COBOL, CICS i RPG2. Rzeczywiście prawie (ale nie do końca) wszystko, co można uruchomić na komputerze z systemem Linux, można uruchomić na komputerze mainframe. <irony> Nie jestem pewien dlaczego. </irony>

Dlaczego więc przez całe życie unikałem komputerów mainframe po ich spotkaniu w szkole? Dobrze:

• Chociaż prawdą jest, że możesz używać więcej niż COBOL, CICS, RPG2 itp. W komputerach mainframe, szanse są bardzo wysokie, że jeśli będziesz z nimi pracować, to będziesz spadał. Co gorsza, pomimo tego, że COBOL został masowo „zmodernizowany” w ciągu ostatnich dwóch dekad (przestraszyć cytaty, ponieważ nadal nie uważam, że jest to bardzo nowoczesny język), większość kodowania, które będziesz robić w języku COBOL, nadal będzie stare kod w stylu, ponieważ ...
• W komputerach mainframe niewiele się dzieje. Jeśli dostaniesz pracę w IBM, pracując dla działu R&D na komputerach mainframe, możesz mieć szansę na nowe prace rozwojowe (w takim przypadku możesz nawet cieszyć się z pracy!). W rzeczywistości jednak spójrz prawdzie w oczy: nie będziesz tam pracował. Będziesz pracował na zapleczu jakiejś instytucji finansowej lub innej, która utrzymuje 50-letni kod COBOL napisany przez kogoś, kto nadal uważa, że ​​64 KB to ogromny stos. (Ten sam facet prawdopodobnie będzie twoim szefem.)
• Chociaż prawdą jest, że możesz uruchamiać Linuksa na komputerach mainframe, a tym samym mieć dostęp do praktycznie dowolnego języka programowania lub środowiska, które chciałbyś, podobnie jak w przypadku prac badawczo-rozwojowych nad komputerami mainframe IBM, nie dostaniesz tego zadania. Powraca do utrzymywania tego 50-letniego COBOLA.
• Programowanie korporacyjne bardzo skutecznie wysysa z ciebie duszę (i pamiętaj, że to programowanie korporacyjne będziesz robić jako programista na komputerach mainframe, chyba że masz BARDZO szczęście).
• To getto i ciągle się kurczy. (W ten sposób przypomina to MUMPS .) Jeśli za bardzo zanurzysz się w wiedzę o komputerach mainframe, będziesz bardziej oddalony od wszystkiego, co nie jest na komputerze mainframe. Możesz spróbowaćnadążyć, ale nie zrobicie tego. Wiem, że ktoś zauważył, że sprzedaż komputerów mainframe wzrosła, podczas gdy inne sektory serwerów nieco się skurczyły, ale programowanie serwerów jest obecnie mniejszością. Piekielne komputery w ogóle tracą na znaczeniu. Świat programowania jest bardzo szeroki i bardzo różnorodny, a wzrost jego jednej niewielkiej części w porównaniu do innej niewielkiej części jest bez znaczenia w porównaniu, powiedzmy, z nagłym, gwałtownym rozwojem programowania w czymś tak trywialnym jak iPhone (który sam jest platforma mniejszościowa - zdecydowanie). Nie, zacznij pracować w komputerach mainframe, a będziesz mieć tylko innych komputerów mainframer, z którymi będziesz mógł dzielić się swoimi przemyśleniami, radościami i wściekłością - i to oni umierają. Prowadzi to do powstania pętli ujemnego sprzężenia zwrotnego, co powoduje, że stado kurczy się jeszcze bardziej i szybciej.

Jestem pewien, że istnieje wiele powodów, dla których programista komputerów mainframe może podać, dlaczego kariera jest satysfakcjonująca i pełna radości i interesujących wyzwań. Rzeczywiście słyszałem wiele z nich od ludzi próbujących zrekrutować mnie w teren. W końcu jednak nie byłem przekonany, głównie z powodu problemu z gettem. Jeśli wsiadłem i okazało się, że mi się nie podoba, jak mogę się wydostać?

Mam 27 lat i jestem profesjonalnym programistą od ponad 4 lat (więc mam nadzieję, że kwalifikuje mnie to jako wciąż młodego). Pracuję również jako specjalista ds. Integracji, dzięki czemu mam duży kontakt ze światem projektowania komputerów mainframe.

1. Wydaje się, że w społeczności niewiele się dzieje lub nic się nie dzieje.
   Wiem, że tak nie jest, ale dla zwykłego obserwatora wydaje się, że tak. Nikt nie chce się angażować w obszarze, w którym trudno „zostawić swój ślad”.
2. Ile się dzieje nowych projektów lub nowych projektów?
   Żadnego, o ile mogę powiedzieć. Jeśli wejdziesz w ten obszar, skazujesz się na zawsze programistą konserwacji.
3. Nie jest dostępny dla zwykłego ucznia.
   Większość osób zaczęła uczyć się programowania na komputerze w domu. Ponownie większość ludzi nie lubi rezygnować z tego, co wiedzą. Tak więc przejście od jednego do drugiego wymaga czasu i motywacji. Biorąc pod uwagę pozostałe 2 powody, nie ma wielu chętnych.

We wrześniu skończę 40 lat, więc nie wiem, czy to kwalifikuje mnie już jako młodą osobę, ale osobiście wiem, dlaczego ktoś może nie chcieć być programistą mainframe.

Ostatnie 10 lat mojego życia zawodowego poświęcone było programowaniu na komputerach mainframe. Ucząc się wszystkiego, co trzeba wiedzieć o partii, jcl, Cobolu, asemblerze, Easytrieve, CICS i usługach internetowych, bardzo mi się podobało i nadal robiłbym to, gdyby nie zauważenie trendu. Moje ostatnie miejsce pracy sprawiło, że pracowałem ramię w ramię z programistami stron internetowych (jsp, javascript, spring i hibernacja) i zauważyłem, że firma przyciągała programistów z porównywalnym wieloletnim doświadczeniem za dużo więcej pieniędzy. Nie wspominając już o tym, że pozycja programistów była o wiele mniej stresująca.

Po tym, jak mam dość tego trendu, postanowiłem wyjść z branży komputerów mainframe. Teraz jestem w stanie, w którym rozwijam usługi sieciowe z java i interfejs użytkownika z javascript. Ten styl programowania nie jest trudniejszy niż to, co zrobiłem na komputerze mainframe, ale teraz zarabiam więcej pieniędzy i mam mniejszy ból głowy. Nie dostaję już tego połączenia o 2 w nocy, że coś się skończyło, a podstawowe procesy systemowe czekają na mnie, aby naprawić moje problemy. Podaj mi więc jeden dobry powód, dla którego miałbym zostać programistą komputerów mainframe, kiedy mogę zarabiać więcej pieniędzy i mniej stresować w życiu jako programista systemów rozproszonych?

Jestem pewien, że zdarzają się sytuacje, w których firmy płacą komputerom mainframerzy, a także facetom systemów rozproszonych, ale ja osobiście ich nie znalazłem. Zacząłem również wyszukiwać oferty pracy z obu perspektyw i odkryłem, że liczba ofert systemów rozproszonych przewyższyła liczbę ofert pracy na komputerze mainframe co najmniej od 10 do 1. To oznacza, że ​​w tej chwili dla mnie, aby mieć lepsze możliwości pracy, mainframe nie jest miejscem być.

Z tego, co do tej pory widziałem, i w porównaniu do Linuksa i Windowsa, podstawowym problemem z komputerami mainframe i midframe jest to, że MUSISZ zapłacić z góry za ich użycie. I dużo płacić. Każdego roku. Za wszystko.

Nie jest to po prostu sposób, aby zainteresować uczniów czymś, ponieważ nie stać ich na to. Jeśli ich to nie interesuje, prawdopodobnie nie zrobią tego dobrowolnie.

Niestety model biznesowy IBM nie pozwala na tanie udostępnianie maszyn studentom lub mogą oni to zmienić.

Jedna z moich pierwszych wakacyjnych prac jako programista była w dużej mierze oparta na skrobaniu zielonych ekranów i plików PRN. Wtedy prawdopodobnie nie miałbym nic przeciwko zabrudzeniu rąk w języku COBOL (to znaczy, gdyby zaufali mi wystarczająco jako student, aby wpuścić mnie do tego kodu), ale nie jestem pewien, czy czułbym się tak samo z ta sama perspektywa dzisiaj.

Nie sądzę, aby problem dotyczył komputerów mainframe per se. To obsesja naszej branży (często uzasadniona) obsesją na punkcie tego, co nowe i lśniące.

Spójrz na C. C jest oczywiście niezwykle ważnym językiem. Prawie cały kod osadzony i większość systemów operacyjnych są napisane w języku C. W najbliższym czasie nigdzie się to nie pojawi. A jednak coraz trudniej jest znaleźć programistów C. Szybki podgląd na stronie znacznika Przepełnienie stosu powoduje, że ma on 1/6 rozmiaru [c#]i 1/4 rozmiaru [java]. Czy ktoś pamięta, kiedy C był zasadniczo dominującym językiem, prawdopodobnie jedyną grą w mieście?

Programiści uwielbiają potężne narzędzia. Może dlatego, że (ALERT SPECYFIKACJI) większość programistów to ludzie. Dajesz programiście Java lub .NET zadanie, powiedzmy, skopiowania pliku, a wielu, jeśli nie większość, nadal zdecyduje się napisać go w Javie lub C # zamiast pisać plik wsadowy DOS lub skrypt powłoki * nix, który byłby 50 razy szybsze pisanie i wdrażanie. Po co używać wędki i kołowrotka, aby złapać rybę, gdy masz gigantyczną wysuwaną siatkę, która może złapać 500 ryb?

Tak, COBOL i PL / I są stare , ale podobnie jak Pascal, i wciąż żyje i kopie w formie Delphi. Niechęć do tych pierwszych prawdopodobnie wynika z faktu, że te języki są nieporęczne w porównaniu do nowoczesnych narzędzi. Orientacja obiektowa jest wciąż stosunkowo nową koncepcją w świecie COBOL (nacisk na względnie ), ale w świecie C # LINQ i generics a AJAX przestały być rewolucyjne lata temu. Poproszenie programisty przyzwyczajonego do tych narzędzi o rozpoczęcie programowania na komputerach mainframe jest jak poproszenie muzyka rockowego o rozpoczęcie gry na banjo.

Oczywiście istnieje również problem samonapędzającego się stereotypu. Dopóki młodzi programiści uwierzyć , że nie ma nic dla nich w mainframe (czy nie jest prawdą), to każda młoda programiści, którzy nie zdecydowali się pójść w to skończyć spędzać większość swoich dni wśród ludzi wiele starsza. Początkowo IT nie jest zbyt atrakcyjnym społecznie zawodem, ale dodatkowy czynnik zniechęcający do różnic pokoleniowych sprawia, że ​​jest on niższy niż próg bólu wielu ludzi. Bez obrazy - osobiście większość życia spędziłem pracując z ludźmi o wiele starszymi, ale nie wszyscy mają to pochodzenie lub zdolności.

Wreszcie, większość programistów nie lubi prac konserwacyjnych, a prawie wszystkie prace na komputerach mainframe to konserwacja. W PL / I nie ma dużo nowego oprogramowania. Każde zadanie, które jest zdefiniowane w całości lub w dużej mierze wokół kodu konserwacji, automatycznie zaczyna się od wyniku negatywnego.

Tam są pozytywy do pracy na starszych kod ( „Legacy” obejmujących systemy komputerowe i wiele innych rzeczy), co będzie potrzebne do gry, jeśli starasz się przyciągnąć młodszą publiczność:

• Systemy są, jak mówisz, infrastrukturą krytyczną. Młodsi programiści, przynajmniej w świecie biznesu (nie Google / Microsoft), często nie mają szans na wywarcie realnego wpływu . Praca w systemie, o którym wiesz, że zostanie porzucona lub zastąpiona po kilku miesiącach lub latach, jest przygnębiająca. Aplikacje na komputery mainframe, które działają już od 50 lat, prawdopodobnie będą działać o wiele dłużej, ponieważ firmy nie mają sensu ich odbudowywać, więc praca, którą w nich wykonujesz, jest tak naprawdę ważna dla wielu ludzi.

• Jeśli jesteś jednym z tych nielicznych firm, które faktycznie nie mają skłonność do „upgrade”, wtedy dużo programistów, zarówno młodych i starych, będą przyciągane przez to szansę, bo wtedy są bliźniacze możliwości pracy na znaczeniu krytycznym kodu i aby wygiąć niektóre z mięśni C # / Java. Oczywiście żadna rozsądna firma nie po prostu złomowałaby komputera mainframe i odbudowy od zera, ale widziałem systemy, które (na przykład) mają rdzeń COBOL, który integruje się ze składnikami Java.

• Wreszcie, jest niezbędna - przynajmniej tak, jak my postrzegamy to osoby z zewnątrz. Gdy cały Twój kod znajduje się w .NET, zawsze istnieje ryzyko, że właściciele zamienią Cię na świeżego absolwenta college'u lub gorzej, na morski zespół, w nieudanej próbie obniżenia kosztów. Nie sądzę, że zdarza się to często w świecie komputerów mainframe, szczególnie jeśli to, co mówisz, jest prawdą, a podaż wydaje się maleć. Oczywiście ten punkt jest dyskusyjny, jeśli nie płacisz wystarczająco dobrze; wynagrodzenia muszą być dostosowane, aby odzwierciedlić malejącą podaż, w przeciwnym razie ludzie nie będą „sprzedawać”.

Jestem pewien, że jest wielu młodych programistów, którzy nie odrzuciliby rozsądnie hojnej oferty firmy, która wydawała się starać, aby środowisko pracy było atrakcyjne dla młodszych pracowników. Ale jeśli chcesz do nich dotrzeć, rozsądnie byłoby wykorzystać swoje mocne strony, a być może będziesz musiał rozpocząć marketing; mamy tendencję do postrzegania komputerów mainframe jako innego i bardzo obcego świata i jestem prawie pewien, że nie widziałem was na targach pracy w kampusie 10 lat temu, pracujących nad zmianą tego postrzegania.

Sprowadzając się do jednego zdania: nic nie powoduje, że komputery mainframe są nieatrakcyjne , po prostu nic też nie czyni ich atrakcyjnymi , co stawia ich w bardzo niekorzystnej sytuacji w porównaniu z przełomem, który oferuje nam ogromne zwiększenie wydajności i bezpłatne napoje bezalkoholowe.

Jestem młody (w połowie lat 30-tych) i obecnie pracuję nad obsługą mainframe. RPG, COBOL, własna bzdura 4GL. Rozwój jest powolny i tam, gdzie to możliwe, migrowany jest na bardziej nowoczesny sprzęt przy użyciu bardziej nowoczesnych języków.

Tworzenie komputerów mainframe jest tak kłopotliwe w porównaniu z nowoczesnymi systemami, że sama mainframe ma tendencję do spadania do zaplecza, podczas gdy bardziej nowoczesne języki są używane do wykonywania raportów i transformacji danych, które były wykonywane na samej płycie głównej. W tym momencie nawet wprowadziliśmy większość danych do procesu sterowanego wsadowo, więc jedyne rzeczy, które pozostają na serwerze, są związane z rozliczeniami.

Choć może się wydawać, że jest to dobra nisza, myślę, że wiele firm zdaje sobie sprawę, że tak naprawdę nie potrzebują już tych systemów. Zmiany zachodzą powoli w świecie finansów, ale się zdarzają.

Osobiście nie rozumiem, jaka jest korzyść rynkowa dla komputerów mainframe.

Szybkie kręcenie liczb i danych? Dlaczego nie mogę rozpowszechniać tego w farmie w celu przetworzenia lub kupić mocnego „normalnego” serwera.

Wysoka redundancja i skalowalność? Wolę farmę serwerów Linux lub zestaw serwerów wirtualnych.

Wirtualizacja i wiele systemów operacyjnych? Być może istnieje znacząca różnica w wydajności przy użyciu tego zamiast strategii „w chmurze”?

Chociaż chciałbym bardziej szczegółowo zrozumieć te wszystkie rzeczy, brak przydatnych wyjaśnień dotyczących tego, co wyróżnia komputer mainframe, jest głównym powodem, dla którego nie programuję dla tych systemów.

Mam 25 lat i obecnie jestem w programie MSCS (moje doświadczenie nie obejmuje CS) i zdecydowanie jestem zainteresowany komputerami mainframe. Problem polega na tym, że nie jestem pewien, od czego zacząć. Patrzyłem na COBOL i nie wiem, skąd wziąć porządny kompilator (nie jestem nawet pewien, co to jest porządny kompilator dla COBOL, wiem, że istnieje kompilator typu open source, ale nie jestem pewien, jaką ma on jakość). Po prostu nie widzę za dużo informacji i szczerze mówiąc, czas spędzony na szukaniu jest czasem, w którym mógłbym aktywnie pracować nad projektem w .Net lub Java (wolę .Net, ale praca szkolna jest w Javie) . Podobnie jak @Joshua Smith, martwię się, że gdybym dostał się do komputerów mainframe, byłoby to moje życie, ale uważam je również za bardziej interesujące niż aplikacje internetowe i całe szaleństwo Web 2.0 (nazywaj mnie szalonym). Dla mnie jednak

Najważniejsze jest to:

(1) Informacje nie są dla mnie łatwo dostępne, aby dowiedzieć się, czego powinienem się nauczyć, aby programować na komputerze mainframe
(2) Na tym etapie mojego życia chcę po prostu móc programować na życie, a .Net i Java zezwalają pracuję nad osiągnięciem tego celu w szkole, ponieważ jest mnóstwo zasobów, do których mogę się zwrócić i dowiedzieć się, czego potrzebuję, aby odejść z portfolio na koniec mojej kariery akademickiej
(3) Trudno byłoby mi utknąć robienie czegoś, co mi się nie podoba, a możliwość utknięcia tylko podczas robienia gier na komputerze mainframe jest czymś, co mnie przeraża (chociaż wiem, że są na to sposoby, takie jak wyszczuplanie nowych rzeczy w wolnym czasie i przyczyniając się do open source)

To tylko moja osobista perspektywa jako młodego programisty. Nigdy wcześniej nie pracowałem na komputerze mainframe, więc nie mogę rozmawiać z pierwszej ręki na jednym. Ale o to chodzi, nigdy nad tym nie pracowałem i nie przewiduję, że nastąpi to w najbliższym czasie. Nie jestem pewien, gdzie chcesz wytyczyć granicę między komputerem mainframe a prostym serwerem, ale kiedy myślę, że mainframe, wyobrażam sobie jakąś gigantyczną maszynę IBM, taką jak Z-Series 900, która zjada 35 $ za dzień tylko w elektryczności. W najbliższym czasie nie będę miał jednego z tych w piwnicy, żeby majstrować w wolnym czasie. Zwłaszcza, gdy mogę złapać starą maszynę, wrzucić na nią serwer Ubuntu i bardzo łatwo hostować wszystko, co chcę. Jeśli mam problem, społeczność Linuksa jest ogromna i istnieje szansa, że ​​ktoś inny napotkał mój problem i opublikował rozwiązanie online. Tylko zgaduję

Zacząłem od pracy na komputerze mainframe, kiedy 10 lat temu podjąłem pracę. Nigdy wcześniej nie dotykałem komputera mainframe.

Było kilka aspektów, które mi się nie podobały, więc przestałem jak najszybciej pracować na komputerze mainframe:

1. Edycja kodu była bardzo prymitywna. Zasadniczo pracowałeś w edytorze tekstów, ustawiony na WSZYSTKIE KAPSYKI i 80 linii znaków. Bez uzupełniania kodu i sprawdzania składni.
2. Kompilacja została wykonana przez uruchomienie zadania wsadowego, które następnie zostało zaplanowane i uruchomione w pewnym momencie, zwykle w ciągu następnych 5 minut, jeśli masz szczęście. Jeśli miałeś literówkę, a kod się nie skompilował, powtórz kilka razy.
3. Nie było żadnego debuggera. Debugowanie przeprowadzono poprzez wydrukowanie wartości zmiennych i powtórzenie tego długiego kroku kompilacji.
4. Zmiany, które wprowadziliśmy, były zawsze niezwykle konserwatywne. Opieraliśmy się na 20 latach starszego kodu, w którym jedyna dokumentacja została napisana ręcznie na papierze w szafce na dokumenty. Ponadto był to kod finansowy, więc nie było tolerancji na błędy. Tak więc faktyczny krok kodowania był minimalny w porównaniu z wymaganymi wcześniej badaniami.

(OTOH, mieli bardzo zaawansowaną kontrolę wersji i promocję kodu przez pewien okres.)

Dwa powody, dla których warto rozważyć dołączenie do pracowników mainframe:

1. Opłaca się dobrze
2. Istnieje mnóstwo otworów

Siwy personel w dziedzinie komputerów mainframe jest i będzie tworzył ogromną liczbę otworów w tej dziedzinie.

Pracuję dla dużej firmy finansowej i w ciągu najbliższych 5 lat stracimy około 30% naszej siły roboczej na emeryturę. Liczba ta wzrośnie wykładniczo za 10-15 lat.

Więcej powodów:

• Jestem w polu od ponad 25 lat i nigdy się nie nudziłem.
• Mniejsza konkurencja o miejsca pracy.
• Przestań narzekać na technologię (patrz niektóre posty powyżej) ... może być stara, ale pod wieloma względami lata świetlne wyprzedzają otwarte systemy. HTML - daj mi spokój. Jest tak podobny do Basic, który wziąłem 30 lat temu na studiach. Jesteśmy daleko poza tym.
• Komputer mainframe jest szybki i niezawodny, wypróbowany i prawdziwy.
• Spróbuj programowania systemowego, jeśli jesteś bardzo bystry i uwielbiasz rozwiązywać problemy.
• Jako lider zespołu chciałbym znaleźć młodych, wyszkolonych techników do obsadzenia stanowisk.
• Czy wspominałem, że dobrze się opłaca?
• Inne opcje kariery poza komputerami - inżynierowie sprzętu, technologie pamięci masowej, praca w sieci i wiele innych.
• To zabawne, ekscytujące, wymagające, a rozwój kariery jest świetny.
• Przestań myśleć o komputerze mainframe jako o starej technologii - sprawdź to i sprawdź wszystko, co powiedziałem.

Sprawdź także IBM System z Academic Initiative.

Nadal jestem młodym programistą (mam 29 lat) i zdecydowanie nie jestem zainteresowany nauką programowania dla komputerów mainframe. Pracuję dla firmy ubezpieczeniowej w zespole .NET, ale współpracujemy również z dużym zespołem oldschoolowych programistów komputerów mainframe.

Jest kilka rzeczy, które sprawiają, że świat komputerów mainframe jest dla mnie nieatrakcyjny. Po pierwsze, jest COBOL. Rozumiem, że znaczna część świata działa w języku COBOL, ale nie czyni mnie to mniej brzydkim dla moich oczu.

Następnie istnieje koncepcja „cyklu”. Nie wiem, czy jest to wspólne dla komputerów mainframe, czy jest to po prostu sposób, w jaki to robimy, ale nasza komputer mainframe musi uruchomić nocny cykl, zanim będziemy mogli uzyskać z niego aktualne dane. Strona .NET naszego sklepu jest mocno zaangażowana w wysyłanie danych i przetwarzanie danych z komputera mainframe (w szczególności wyświetlanie dużej ilości danych na wewnętrznej stronie LOB dla agentów). Firma chce, aby dane wyświetlane agentom były aktualne co do minuty. Jednak mainframe nie działa w ramach mojej (ograniczonej) koncepcji czasu rzeczywistego. Wprowadziliśmy pewne szalone obejścia, które symulują na stronie internetowej, czego oczekujemy od rzeczywistej wydajności z komputera mainframe następnego dnia.

Wreszcie, głęboko wierzę, że gdybym w tym momencie miał przejść do rozwoju komputerów mainframe, zdominowałoby to moją karierę. Myślę, że moje umiejętności jako nowoczesnego programisty byłyby coraz bardziej w tyle, ostatecznie osiągając punkt, w którym utrzymanie COBOL byłoby moją jedyną opcją. Wiem, że należy zarobić dobre pieniądze, teraz, a zwłaszcza za dziesięć lat, ale pieniądze są czwartym lub piątym miejscem na mojej liście priorytetów w mojej karierze. Wolałbym nadal otrzymywać przyzwoitą pensję, jeśli oznacza to pracę nad nowymi i interesującymi rzeczami.

Pracuję głównie z Javą, ale do naszego backendu używamy komputerów mainframe, co oznacza, że ​​mam z nimi dużo do czynienia (RPG). Największym problemem, jaki mam, jest brak publicznie dostępnej dokumentacji. Można znaleźć dokumentację SQL dla DB2, która przełoży się głównie na iSeries DB2, ale publib.boulder jest okropny w porównaniu do javadoców Sun.

Inną rzeczą, która mi się nie podoba, jest trudna do odczytania składnia głównych języków komputerów mainframe. RPG nie ma pojęcia zasięgu lokalnego, co oznacza, że ​​potrzebujesz ogromnych bloków deklaracji zmiennych. Myślę, że Cobol cierpi na ten sam problem. Prowadzi to również do bezsensownych nazw zmiennych i ukrytych znaczeń. Ma także wiele różnych wbudowanych funkcji, o których trudno mi się dowiedzieć (patrz wyżej). Przypomina mi to, dlaczego nie używam już języka BASIC do poważnego programowania. Na szczęście IBM próbuje przenieść wszystkich na Javę, ale te starsze języki wkrótce nie znikną.

Trudno mi ekscytować się nauką programowania w takim środowisku.

Mam 42 lata i nie interesują mnie komputery mainframe. Cóż, zakwalifikujmy to. Interesuje mnie historia komputerów. Studiowałem do pewnego stopnia architektury komputerów mainframe i rozumiem, w jaki sposób na przykład komputery mainframe IBM wpłynęły na architektury mikroprocesorów, takie jak Motorola 68000 lub 80386. W latach 60-tych komputery mainframe już płonęły z prędkością przekraczającą 30 MHz i korzystały z zaawansowanych wielozadaniowych systemów operacyjnych z wirtualnym wspomnienia Dla ludzi przyzwyczajonych do tych środowisk wczesne mikroprocesory były rozczarowujące pod wieloma względami, a architektura oparta na mikroprocesorach musiała nadrobić zaległości w zakresie podobnych możliwości i wydajności.

Ale nadrobili zaległości w tych architekturach, a komputery mainframe już dawno przestały być „modne”. Zdarzyło się to, gdy hakerzy mogli umieścić na swoich komputerach minikomputery, a wkrótce potem stacje robocze z systemem Unix.

Komputery mainframe są obce młodym programistom od początku 1980 roku. To może być doskonały czas, aby firmy zajmujące się komputerami mainframe zadały sobie pytanie.

Dzisiaj odpowiedź jest międzypokoleniowa: młodzi programiści nie są zainteresowani komputerami mainframe, ponieważ nawet jeśli ich rodzice lub nauczyciele są zainteresowani informatyką, ci rodzice i nauczyciele (ponad 40 geezerów takich jak ja) już nie byli zainteresowani robieniem czegokolwiek z komputerami mainframe sto lat temu.

W każdym razie dzisiaj telefon komórkowy poradzi sobie z zadaniami, z których korzystały komputery mainframe 30 lat temu! Farmy niedrogich serwerów są nową platformą mainframe. Tak więc w pewnym sensie są dziś nowi programiści komputerów mainframe, tylko ich specjalizacja polega na łączeniu w sieć maszyn w celu tworzenia chmur. Krótko mówiąc, moglibyśmy powiedzieć, że Mark Zuckerberg i jego gang pracowali nad nowym rodzajem programowania mainframe podczas tworzenia Facebooka, w tym sensie, że nie jest to tylko mała aplikacja, która działa na prostym mikroprocesorze z dyskiem.

Nawiasem mówiąc, jedną z ostatnich specjalności mainframe była wirtualizacja. Ale jest to obecnie wszechobecne w komputerach stacjonarnych / serwerowych. Ludzie na początku zaczęli robić to źle, stosując techniki oprogramowania. Maszyny wirtualne były tak przydatne, że użytkownicy nie mieli nic przeciwko wydajności. Następnie firmy takie jak Intel ponownie spojrzały na komputer mainframe i nauczyły się jeszcze kilku lekcji, wspierając wirtualizację sprzętu, aby był szybki.

Nauka tworzenia stron internetowych, telefonów komórkowych lub komputerów jest raczej tania i łatwa.

Koszty sprzętu nawet dla starej, pobitej mainframe są strasznie wysokie, a IBM często denerwuje się projektem emulatora Hercules (który pozwala emulować System / 370, ESA / 390 i zSeries). Bez Herkulesa powoduje to, że koszty wejścia do nauki architektury mainframe i rozwoju aplikacji są niedostępne dla wszystkich, oprócz najbogatszych hobbystów.

Żadna uczelnia, do której nie uczęszczałem od lat 80., nie posiadała żadnych komputerów mainframe do użytku dla studentów. Myślę, że IBM i reszta duchów przemysłu komputerów mainframe postrzelili się w stopę, czyniąc ich mniej dostępnymi do nauki.

Zacznijmy od kilku faktów na temat komputerów mainframe IBM, a konkretnie zSeries.

Sprzęt marki jest lśniący i nowy. Zawiera jedne z najbardziej zaawansowanych dostępnych układów elektronicznych i układów scalonych, które są szybkie.

Chociaż system z / OS ma swoje korzenie w latach 60. XX wieku, był nieustannie rozwijany i co najmniej dwa kompletne przepisywania, więc oprócz dziwactw wynikających z fetyszy IBM o kompatybilność wsteczną, prawdopodobnie jest to jeden z nowszych powszechnie używanych systemów operacyjnych.

Kluczowe punkty sprzedaży to: -

• Wspomniana poprzednia kompatybilność wsteczna, jeśli program działał w 1976 r. Na maszynie MVS / MVT, istnieje prawdopodobieństwo, że uruchomi się na najnowszym zSeries bez ponownej kompilacji i da dokładnie takie same wyniki.
• Przepustowość może przenosić dostęp i przechowywać ogromne ilości danych, z ogromną prędkością i na bardzo drobnym poziomie szczegółowości.
• Dostępność. SYSPLEX, który jest dostępny od około 15 lat, zapewnia bezproblemowe tworzenie klastrów w wielu lokalizacjach, wraz z równoważeniem obciążenia, automatycznym przełączaniem awaryjnym itp., Z których większość jest implementowana sprzętowo. Sprawia, że ​​większość klastrów * nix wygląda prymitywnie.
• Konwergencja. Brzmi to trochę dziwnie, ale z pełną obsługą POSIX i superszybką maszyną JVM nowoczesna komputer mainframe jest praktycznie nie do odróżnienia od innych urządzeń * NIX, jeśli tak chcesz tego używać.

Do tej pory komputer mainframe przeżył prawie wszystko, co według ekspertów miało go zastąpić.

Istnieje wiele wad:

• Kompatybilność wsteczna oznacza, że ​​wiele sklepów korzysta z dwudziestu, trzydziestu, a w niektórych przypadkach czterdziestoletnich systemów. Chociaż działają dobrze i dobrze wykonują swoje funkcje biznesowe (w przeciwnym razie nadal by nie działały!) Odzwierciedlają style kodowania i obsesje minionego wieku.
• kultura zacofana. Programiści pracujący w getcie starożytnych systemów COBOL nie zdawali się zdawać sobie sprawy, że świat się zmienił, lub jeśli wykonują skamieniałe zarządzanie, nie pozwolą.
• Brak dostępności. Jeśli nie otrzymujesz zapłaty za pracę nad jednym z tych potworów, nie uzyskasz dostępu do jednego z nich. Może być nawet taki, w którym pracujesz, ale jeśli twój bezpośredni opis stanowiska nie obejmuje pracy nad nim, nie otrzymasz loginu. Wiele powiedziano już w innych postach na temat oprogramowania do emulacji „herecules” i jest ono rzeczywiście doskonałe, ale jest przeznaczone tylko dla ekspertów, działa w starożytnej wersji systemu operacyjnego, brakuje większości standardowych komponentów, takich jak CICS, COBOL i DB2, które stanowią szkielet większości działających aplikacji na komputerach mainframe.

Zabawne, że o to pytasz. Właśnie rozmawialiśmy na Uniwersytecie na temat komputerów mainframe i że IBM jest niezadowolony z poziomu programistów komputerów mainframe, dlatego że wdrażają moduł mainframe na naszym uniwersytecie, uczą nas programowania komputerów mainframe i mają zdalny dostęp do jednego z nich.

Właściwie biorę ten moduł we wrześniu, może nie będzie to coś, co zrobię ponownie, ale da mi szansę pracy nad czymś „innym” i otworzę oczy na nowe paradygmaty.

Mam 28 lat i jestem profesjonalnym programistą od 10 lat. Spędziłem 3 lata pracując na komputerze mainframe.

Środowisko było ezoteryczne, przestarzałe, zastałe, zagmatwane (JCL i ISPF ktoś?). Powiedziawszy to, miałem ogromny szacunek dla systemu, jego działania i skali. System miał około 150 mln SLOC, obsługiwał farmę średnich serwerów UNIX za pośrednictwem SOA i dosłownie prowadził znaczną część kraju.

To powiedziawszy, dlaczego młodzi programiści nie są zainteresowani? Oto moje zdanie, jako „młody” programista (zacząłem na tym systemie w wieku 23 lat). Pamiętaj, że to moja perspektywa z systemu, nad którym pracowałem, a badania, które przeprowadziłem:

• Wprowadzono niewiele nowych rozwiązań dla komputerów mainframe. Wiele z nich to spuścizna.
• Istnieją ogromne bariery wejścia
• Wykonane prace dotyczą finansów, dużego biznesu i rządu. Nic z tego nie krwawi.
• Narzędzia programistyczne są stare i w dużej mierze przestarzałe. Debugowanie nie przypomina VS.

Komputery mainframe zawsze będą miały swoje miejsce w gospodarce. Po prostu nie prowadzą wczesnych firm ze względu na ich ogromne koszty i wymagania dotyczące wsparcia.

Chociaż myślę, że prawdopodobnie jest bardzo interesująca praca w komputerach mainframe, byłbym przerażony, mogąc przenieść moją karierę w tym kierunku. Jest o wiele za duża szansa, że ​​10 lat później moje doświadczenie stało się bezużyteczne i nie ma pracy dla programisty mainframe. Nie chcę się dezaktualizować, spędzając dużo czasu w stagnacyjnej technologii z kurczącą się bazą instalacyjną.

Ta odpowiedź jest taka, że ​​nie ma w tym przyszłości. Mam dwadzieścia dwa lata doświadczenia jako programista na komputerach mainframe i jestem bez pracy przez pięć lat. Wracam do szkoły, aby uzyskać tytuł licencjata w zakresie tworzenia stron internetowych. Dlaczego ktoś przy zdrowych zmysłach chce zostać programistą COBOL na komputerze mainframe?

Rozpoznać