Jag gick ADB-linjen 40 p 1985-1986 och blev Cobol-programmerare. Alla 3 klasser på Fridhelsplan hade fast anställning innan utbildningen var klar. Jobbade med det under 4 år med mycket god löneutveckling redan då. Det var ett bra sätt att komma in i IT-branschen. Stannat hela mitt yrkesliv.
2 gillningar
Läste någonstans att många flygplan, typ Boeing 747, fortfarande använder disketter för att uppdatera sina system.
Nu väntar vi med spänning på vilka som fortfarande har hålkort.
1 gillning
Man bör väl också budgetera för terapi hos en psykolog efter några år med Cobol, kan inte bara se på intäkterna.
6 gillningar
När jag googlade på att Boeing 747 fortfarande använder disketter så kom jag fram till denna reddit-tråd:
6 gillningar
Jag är ganska säker på att Lantmäteriet gått ifrån stordatorn nu. För 3-4 år sedan hade vi en kille som höll utbildning för några av våra nyaste programmerare och operatörer. Han hade konsultat åt just Lantmäteriet i många år, men uppdraget skulle sluta inom kort eftersom de var i slutfasen av att migrera bort från plattformen.
2 gillningar
Haha. Kul grej.
Själv fick jag en gång i uppgift att göra en ritningsändring på en leverantörsritning hos en stor lastbilstillverkare. Det visade sig att ritningen bara fanns i pappersarkivet… Dvs ca 80-tal utan att ha rörts.
Detta var 2019.
4 gillningar
Jag jobbar som (bl a) COBOL-Utvecklare och har gjort det i snart 10 år. Man blir väl van vid miljön och visst är det osmidigt jämfört med moderna språk, men det är stor skillnad på program från 70-talet och de från 00-talet.
Taskigt namnsatta variabler ser man främst i program från hålkortstiden.
Jag skulle säga att COBOL är den enkla biten - att lära sig miljön i övrigt, och framförallt systemet man bygget är utmaningen.
Filer (dataset) är exempelvis något helt annat i stordatorn. Mappstrukturer existerar inte på samma vis och så vidare.
9 gillningar
Tågen jag kör av typ X50 (Regina) har Windows 95. Problem när datorn nu börjat visa fel datum och tid. Någon pratade om att sekunderna var slut (!?). Konstigt att man gör Embedded-versioner av operativsystem och sedan inte har en långvarig support. Man borde väl räkna med att systemen finns i prylar med längre livslängd än en hemdator. Han som lägger in nya tidtabeller i tågens datorer måste hålla sig med en tillräckligt gammal PC för att kunna koppla in sig.
3 gillningar
Mats Nordkvist och Erik Weyler från SEB har varit med i flera avsnitt av podden Kodsnack och pratat om COBOL-utvecklingen där. De är förstås delvis med för att göra reklam för SEB så de kanske skönmålar lite men det verkar som de ändå har ett välfungerande system och utvecklingsteam. Det verkar inte som de som jobbar med det känner “åh nej, vi är fast med den här gamla skiten”, vilket är en känsla jag upplevt i flera team som hamnat i en några år gammal version av något “modernt” ramverk.
Jag tror inte programmeringsspråket i sig bidrar jättemycket till hur jobbigt det är att jobba med ett system utan snarare hur genomtänkt systemet i sig är. Fast det är klart, alla utvecklare har ju sina favoritspråk och det är nog svårt att hitta de som föredrar COBOL.
3 gillningar
Generellt håller jag med om detta men inte i fallet med Cobol. Vem gillar ett pratigt språk skrivet med caps-lock? De flesta blir upprörda när folk skriver med caps-lock i inlägg också, känns som man skriker och detta är snarast något för ett skyddsombud att ta tag i 
2 gillningar
Ska man vara petig så får inte verb som DISPLAY och STOP RUN börja i “Area A” d.v.s i position 8-11 där bl a divisionsnamn måste börja, utan i Area B (Pos 12 - 80). Det kommer bli kompileringsfel.
För den som då undrar vad position 1-7 är så är 1-6 sekvensnummer, på hålkortstiden användes det för att sortera hålkorten om man råkade tappa bunten. Position 7 används för exempelvis kommentarstecken och vissa andra saker som fortsättningstecken etc 
Korrekt kod ser alltså ut såhär:
Och resultatet blir Hello World i sysouten (loggen).
15 gillningar
Hur bra är pengarna? Det känns som att man kan behöva psykolog ganska omgående
4 gillningar
Det är inget tvång och används för att göra koden mer läsbar. I datorernas begynnelse fanns inga “små bokstäver” och i de programspråk jag jobbat med genom åren har det varit valfritt.
"What is the purpose of uppercase in programming?
Uppercase letters in programming are often used to make code more readable and distinguish certain elements. They can be used for naming conventions, constants, or representing specific constructs in the language"
1 gillning
Jag hade säkert kunnat få bättre betalt hos en storbank eller som konsult, men jag tjänar 55 000 (plus beredskapsersättning) vilket jag antar är i linje med vilken utvecklare som helst.
Jag gillar stordatormiljön och skulle nog behöva psykolog i den “moderna” världen istället
Sen sitter jag inte och knackar kod dagarna i ända heller, det står nog för mindre än 10% av min arbetstid nu för tiden.
4 gillningar
De enda språk jag jobbat med där det är valfritt är SQL och Ada.
Så vitt jag vet är nästan alla språk case-sensitive. T.ex. C och alla dess derivat (C/C++/Java/C#/etc).
Way back in the early 80’s when I started developing in COBOL, code was always written entirely in uppercase, due to the limitations of the keypunch machines used in those days. We’ve come a long way since then, and today’s COBOL is pretty easy-going. It isn’t at all particular about whether you use uppercase or lowercase when you enter your code.
The following lines of code will all compile and have identical results when executed:
MOVE 1 TO NUMBER-FIELD.
move 1 to number_field.
MOVE 1 to number-field.
move 1 to NUMBER_FIELD.
Move 1 to Number-Field.
mOve 1 to nUmBer_FieLd.
2 gillningar
COBOL är inte case sensitive, däremot har många ställen gamla precompilers som kan vara det vilket ju ställer till det med kommandon som dessa precompilers ska tolka.
Utan precompiler går det fint att blanda gemener och versaler som man vill.
3 gillningar
Jag svarade alltså på den här meningen. De allra flesta språk är case-sensitive. I synnerhet de mest populära språken under de senaste 4 decennierna eller så. Så att lyckas ha en karriär där man bara jobbar med språk som inte bryr sig om man använder gemener eller versaler är nog ganska unikt.
Vi pratar kanske om olika saker? Variabler och andra egendefinierade identifierare är väl case-sensitive för det mesta på senare år. Men det var inte det jag kommenterade i mitt första svar.
ChatGPT:
The necessity of using case-sensitive characters in programming languages depends on the specific language being used. Case sensitivity in programming languages affects how identifiers (such as variable names, function names, and class names) are recognized. Here are a few points to consider:
- Case-Sensitive Languages: Many programming languages are case-sensitive, meaning they treat uppercase and lowercase letters as distinct characters. Examples include:
- C:
variable,Variable, andVARIABLEare considered different identifiers. - Java:
myMethod()andmymethod()would refer to different methods. - Python:
myVariableandMyVariableare different variables. - JavaScript:
myFunctionandMyFunctionare distinct.
- Case-Insensitive Languages: Some languages are case-insensitive, meaning they do not differentiate between uppercase and lowercase letters for identifiers. Examples include:
- SQL:
SELECTandselectare treated the same. - BASIC:
PRINTandprintare considered equivalent.
- Partially Case-Sensitive Languages: Some languages may treat certain parts of the language as case-sensitive while others are not. For example:
- HTML: Attribute names and tags are generally case-insensitive (though HTML5 recommends lowercase).
- CSS: Selectors are case-insensitive in HTML, but case-sensitive in XML documents.
Why Case Sensitivity Matters
- Precision and Readability: In case-sensitive languages, developers can use case differences to convey meaning or intention, improving readability and organization. For example, using camelCase for variables and PascalCase for class names is a common convention.
- Error Prevention: Case sensitivity can prevent accidental shadowing of variables or functions. For instance,
tempandTempcan coexist without conflict in a case-sensitive language. - Consistency with Syntax: Case sensitivity is often part of the syntax rules of a language. It ensures that keywords, functions, and other language constructs are used consistently.
Best Practices
- Consistency: Stick to a consistent naming convention (e.g., camelCase, snake_case) to avoid confusion and errors.
- Clarity: Choose clear and descriptive names for variables, functions, and other identifiers.
- Awareness: Be aware of the case sensitivity rules of the language you are using to prevent bugs and ensure code readability.