Gad godt det her var breaking news.
I stedet er det nærmest ligegyldigt at skrive om millarder der fosser ud af statskassen på IT-projekter.
Brug nu bare DataRobot og få det overstået.
... idet der nu skal udvikles en ny portal til brug for indsamling af vælgererklæringer ...
Glæder mig til 8 års forsinkelse og 12 millarder kr i ekstraudgifter til CSC, hertil droppet projekt grundet uddateret software.
Firmaet har stadig sine to mainframes, som det er standard i bankverdenen, og de bliver stående hvor de står.
Slukket, forhåbentlig?
Det meste af SKAT er baseret på 1960'ernes mainframeteknologi. Ligesom bankerne og forsikringsselskaberne. Jeg er mest interesseret i hvad der kommer først; det totale kollaps af SKATs IT-infrastruktur, eller nye boligvurderinger.
I min bog er det offentligt ombud, så det bør være dygtige folk fra både private og offentlige organisationer, som sammen finder de bedste løsninger.
Det er bare lidt svært at finde dygtige folk i det offentlige, når lønningerne ligger 20-30.000 kr under den private sektor, og det offentlige skal spare 2% om året...
“If you pay peanuts..” som de siger.
Og så er det jeg gentager mit spørgsmål, hvad er dit belæg for det?
Hvad ønsker du? Statistikker? Brugerundersøgelser? Jeg har arbejdet i 15 år i branchen - både i startups, mainframehelvede og mellemstore it virksomheder, både dansk og internationalt - er det nok?
Helt ærligt, jeg vil skide på Silicon Valley, for den virkelighed f.eks. produktions- og servicevirksomheder, samt myndigheder og meget andet skal forholde sig til, er en helt, helt anden.
Det fortæller du bare til udbuddet af nyuddannede udviklere, så.
Det var dog det mest håbløse vrøvl, men du mener åbenbart at det drejer sig om at fyre så mange som muligt bullshit banko ord af, så er alt godt.
Hehe, okay så. Jamen FTP og CSV filer er da også fedt nok.
Det er jeg fuldstændig enig med dig i. Når udskiftningsraten på dygtige udviklere ligger på omkring 2 år i gennemsnit, er det imperativt at man skriver kode som andre kan overtage. Det har jeg ikke sagt noget sted, at man ikke skal.
Mainframes har ikke monopol på databasetransaktioner, som garanterer konsistens. Den sikkerhed har de fleste forbrugere kunne få ganske gratis og open source siden i hvert fald midt 90'erne.
De fleste virksomheder vil være overmåde kede af at deres IT kun ville kunne leve i 6 måneder, og de så skal ud og investere i nyt og lave omstillinger, ligesom en håndværker ikke går ud og køber en ny boremaskine hver uge, bare fordi farven på plastikkken ændrer sig.</p>
<p>Og der hvor vi taler om virksomheder, myndigheder og andet skal interface, der er vi nødt til at lave robuste og langtidslevebare protokoller/formater for udveksling af data, og ikke bare lade os diktere af hvad en bumset teenager tilfældigvis synes er sjovt den dag - og så er vi tilbage til XML vs JSON.
Nu kører vi jo bare i ring, og jeg ved ikke hvad det her had mod teenageres hudproblemer og juniorprogrammører har at gøre i debatten - jeg har aldrig talt om at man skal skifte teknologi fordi en eller anden synes det er skægt, jeg fortæller dig bare hvordan IT-verden ser ud i 2019, ligemeget om folk i denne tråd mener, at en softwareservice bør kunne eksistere i årtier uden at blive udskiftet, eller ej.
Det er muligt du har den mening at "vi er nødt til at lave robuste og langtidslevebare protokoller", men jeg fortæller dig at det er ikke virkeligheden i Silicon Valley. Formater til protokoller skifter hele tiden, og det gør økosystemerne omkring dem også, og så er det dit problem ligemeget om du kan lide det eller ej, når der pludselig ikke er nogen andre i verden der hverken kan eller gider interface med dit oldnordiske endpoint som har fungeret upåklageligt i 25 år.
Jeg er godt klar over, at CSC stadig ikke ser noget problem i at kræve et dagligt job kopierer en .csv fra en FTP server, men i resten af verden er selv XML og JSON ved at blive udskiftet med ting som GraphQL og diverse udgaver af protobuf og gRPC, og om 2 år er der noget nyt, og du kan hoppe med på vognen eller falde af i svinget - og så bliver man et emne i en mainframe-debat om gammeldags mainframeudviklere der ikke vil indse at verden omkring dem har ændret sig - og aktivt kæmper imod det, til en ubegribelig høj pris for den danske skattebetaler.
It-chefen har ikke fået oplyst af KMD, hvad årsagen til problemerne er, og han har forgæves prøvet at tjekke KMDs kundenet, der også er ramt af nedbrud.
seriøs driftvirksomhed
?
Men det har jo ikke noget med failover at gøre, så du må nødvendigvis tænke på noget andet.
Baldurs pointe er den samme, uagtet af dette. Hans svar var til en kommentar om, at værdien i mainframes åbenbart lå i, at fraværet af nedetid var en grund til at vælge mainframeteknologi over moderne teknologi.
Specifikt i den sag blev Danske Bank nødt til at flyve IBM-specialister ind for at løse problemet, fordi ingen af deres egne teknikere forstod problemet, hvilket falder fint i hak med mit oprindelige indlæg om, at resten af verden er rykket videre imens mainframeverden har stået stille.
Og hvilket belæg har du for at docere dette over for mig?
At gennemsnitslevetiden for kode i højprofilerede softwarevirksomheder er mellem 6 måneder og 2 år. Det er et paradoks at tale om fremtidssikring af software, da krav, teknologi og infrastruktur skifter så hurtigt, at det ikke giver mening at planlægge udfra at et stykke software skal kunne eksistere i 10 år, for hele grundlaget for den beregning har ændret sig markant efter 10 år. Derfor er der ikke noget galt i at software ikke lever længere end få år, da værdien ligger i de udviklere, som kan finde ud af at navigere i en verden af konstant-skiftende krav og teknologier.
Jeg er tilbøjelig til at svare 'nej', og jeg har udførligt beskrevet hvorfor ovenover. Du kunne måske passende komme med noget den anden vej?
Forkert. Database-tuning er et emne alle udviklere på et udviklingsteam bør vide noget om, og mestre, akkurat, som alle andre aspekter af morderne udviklingsparadigmer. At opdele folk i siloer er netop at sidde i fortiden, som mainframeudviklerne stadig gør.
Faktum er, at mange gange så er det altså nødvendigt at forholde sig at det er altafgørende at at produkt har en levetid på mere end nogle få år.
Og her fortæller jeg dig, at det er ikke virkeligheden i IT-verden anno 2019. Det er afgjort virkeligheden i mainframe-verden, fordi udviklerne stadig lever i 1960.
Mange banker vil ikke være ligeglade med den nedetid, som Nemlogin præsterede da Interxion mistede et datacenter.
Jeg kender ikke ret mange virksomheder, der er ligeglade med nedetid. Mainframe eller ej.
Så jeg anerkender til fulde validiteten af dine oplevelser, men jeg har på den anden side set, hvad man kan med mainframes, hvis man ved, hvad man gør, og jeg er stadig imponeret.
Jeg anerkender til fulde validiteten af dine mainframeoplevelser, men du fortæller ikke noget om hvad de er.
Nåeh, som i C - host, host.
Ja. Og jeg ville aldrig anbefale at bruge C til noget i dag.
Og for ti år siden var det XML der var det helt hotte, så hvad mon der skal være hot om ti år.
Velkommen til IT.
Sikkerhed er ret så vigtig i mainframeverdenen, så lad lige teknologien blive moden og sikker.
Det var #1 modargument jeg hørte. "Teknologien skal blive moden". Hvad betyder det? Teknologi bliver moden og dør igen på 2 år. Enhver moderne platform har forudsætningerne for at kunne håndtere en teknologis introduktion og udfasning igen efter 2 år. Gennemsnitlevetiden for kode i Google er mellem 6 og 12 måneder. At mene det er fornuftigt at vente 20 år på at Java bliver moden er at leve i fortiden.
"Sikkerhed" er et andet generisk modargument der blev brugt ofte, som ingen hold har i virkeligheden. CSC lækkede danske kørekortinformationer i 9 måneder før hullet blev lukket, fordi ingen udviklere kunne finde ud af at gennemskue logfiler på en mainframe. Det er security through obscurity, og den sild er død.
Og organisationen har vist også en gæld, siden det er en senior programmør, som skal lave en Capitalize-funktion - noget man typisk ville sætte en junior-programmør til, da det ikke kræver forretningskendskab.
Hvorfor skal man overhovedet sætte nogen til at koden en capitalize-funktion?!!?
Jeg vil gerne sige tak for din kommentar, da den præcis belyser min pointe, til UG med kryds og slange.
quote men svaret findes skam, du skal blot søge andre steder, som f.eks. erfarne kollegaer og mainframe brugergrupper.[/quote]
Velkommen til 1990.
Bruger du aldrig DOS eller PowerShell prompten i Windows?
Nej, jeg bruger den ondefløjtemig ikke DOS nogensinde. Jeg bruger gerne en bash shell der har været cirka det samme siden 1980, den har tab-completion og indbygget shell scripting. Hvordan er det lige man gør det på 3270?
Du kan ikke kompilere COBOL på din PC? Nej, og selvom du kunne, ville du sandsynligvis ikke kunne afvikle COBOL programmet på mainframen, da din PC kører på en anden processor type end mainframe (x86 vs. f.eks. Power).
Forskellige arkitekturer og deres mangel på kompatibilitet mellem hinanden har ikke været noget problem siden midt 2000, slet ikke efter Docker blev mainstream. Det er normalt ret fedt, i en udviklingsprocess, at man kan afvikle det program man sidder og koder, på den maskine man udvikler på.
Har arbejdet i miljøet. Den eneste grund til at mainframes ikke kan dø, er det ekstreme politiske pres fra inkompetente, omskolede udviklere fra 1970’erne som stadig ikke ved hvad internettet er.
Hvis man tvang mainframes væk fra banker og forsikringsselskaber ville man kunne spare 90% af udviklingsbudgettet, nemt. Den rabat burde ryge direkte til forbrugerne.
Det mainframe miljø jeg blev kastet ud i før jeg løb skrigende væk havde blandt andet følgende flotte features:
Intet brugbart standardbibliotek til Cobol og PL/1 (tænk simple ting som strengformatering, websockets, json parsing, bufferedreader, alt hvad alle moderne sprog har)
Ingen deployment pipelines til at køre integration- og unit tests
Faktisk ingen testframeworks til automatiserede test overhovedet, alle tests blev lavet af mennesker kl 6 om morgen efter release til prod.
Elendig performance sammenlignet med ethvert moderne sprog der udførte en normal, standard opgave (dvs ikke benchmark af math.pow, som cobol eller PL/1 i øvrigt heller ikke har)
Ingen moderne versionskontol af koden, til pull requests, code review, dokumentation etc.
Ingen moderne IDE (glem det, Eclipse-elskere, 10 GB ram for at åbne en fil er ikke moderne)
Ingen organisering af de faktiske filer og/eller koden i et program. Alle programmer var begrænset til én fil med et navn på maks 8 tegn, caps selvfølgelig. Fx “ZBTS1000.CBL” - så regn selv ud hvad det gør.
Bemærk at alt dette er den dag i dag anset for helt normale vilkår af en udvikler af mainframes. Fordi ingen af dem har prøvet andet, og har ingen interesse i at gøre det.
Vi har fået en opgave om at returnere et brugernavn Capitalized i stedet for ALL CAPS. Ok, vi estimeret cirka en måned, fuldtid, til en senior softwareudvikler der har anciennitet nok til 80.000 om måneden i løn. Han skal lige kode en all caps funktion og bruge 2 uger på at teste den manuelt og endnu 2 uger på at teste det samme i produktion. (DET HER ER SERIØST SKET)
Overvej det en tilfældig dag du koder HelloWorld i Rust eller Go eller Scala eller noget andet, der ikke er fra 1950.
Du starter med at hente en runtime. Nope, kan man ikke på en mainframe.
Du tjekker noget ud fra Git. Nope, bruger vi ikke. Hvad er Git?
Du kalder filen helloworld.rs og lægger den i roden af mappen. Nix, vi har ikke mapper eller filhåndtering. Der er kun en Root. Læg filen dér og send en mail til dine kollegaer om hvad filen hedder, så kan de søge i Outlook 3 år senere hvis de har glemt det.
Du trykker lige compile.. nå nej, mainframe bruger nogle load jobs, send programmet til load og refresh en eller anden side med sort baggrund og grøn skrift og se om programmet compilede. Indbyggede compiler i IDE’en? Ej det kan man ikke.
Du vil gerne ind i debug mode og trykke igennem programmet. Ok, du skal lige sende programmet til load, gå ind i et program i en 3270 terminal for at slå et debug flag til, skriv de 8 tegn programmet hedder og vent venligst. Glemte du at sætte det rigtige breakpoint? Surt, start forfra.
Du vil gerne deploye det? Ok, ring til IBM.
Du vil gerne forstå hvorfor din COBOL kode ikke virker? Held og lykke med at finde noget på StackOverflow. Får du mærkelige systemfejl fra zOS når du compiler? Ja Google ved det nok heller ikke.
Velkommen til bank- og forsikringsverden anno 2019. Er I stadig glade for at flyve?
Bh MP
Michael Park