Hallo Freunde, die Frage ist ein wenig Off Topic, aber ich frage mich, wie man zur Zeit der Lochkarten eine Hochsprache wie Fortran umsetzen konnte. Ich kann mir ja noch vorstellen, dass ein damaliger Computer Maschinencode von Lochkarten lesen und abarbeiten konnte. Aber wie hat man ohne Bildschirm-Terminal Sourcecode eingegeben? Wie wurde der Compiler in den Computer geladen (oder war er fest verdrahtet)? Und wo wurde der vom Compiler erzeugte Maschinencode gespeichert? Alles per Lochkarten? Hat jemand vielleicht ein paar interessante Links?
Die Lochkarte hatte man auf einem schreibmaschinenähnlichen Lochkartenstanzer eingetippt. Falsch getippt -> neue Lochkarte Der Text stand in Klartext in der unteren Zeile, insofern Menschenlesbar. Pro Zeile eine Lochkarte, nicht mehr als 72 Spalten.
:
Bearbeitet durch User
Udo Schmitt schrieb: > Pro Zeile eine Lochkarte, nicht mehr als 72 Spalten. … dieweil in Spalte 73 bis 80 die Kartennummer stand, damit man sie nach dem Runterfallen des Stapels auch wieder sortiert bekommt. ;-) Nein, Maschinencode haben die Maschinen auch damals schon eher nicht von Lochkarten aus ausgeführt. Es macht sich ausgesprochen schlecht für den Kartenleser, wenn man bei einer Schleife dann 10 Karten zurück springen soll. :)
Bronco schrieb: > Alles per Lochkarten? Der Programmcode eher auf Lochstreifen! Auf Lochkarte waren hauptsächlich Daten (Kunden, Lieferanden, Artikel,..) Und man kam als "normaler" Programmierer auch nichteinmal in die Nähe des Rechners. Man durfte den Lochstreifen an einem Schalter abgeben, der wurde dann irgendwann vom Bedienpersonal in weißen Kitteln durchlaufen lassen und konnte ihn dann irgendwann mit eine Liste der Errors wieder abholen. Und es nach ausbesserung der Fehler noch mal versuchen.
:
Bearbeitet durch User
Aber wie muss man sich denn den Build-Vorgang vorstellen? Hat man den Sourcecode (als Daten) am Schalter abgegeben und einen Lochstreifen mit Executable zurückbekommen? Oder hat der Rechner den Sourcecode eingelesen, ins RAM compiliert und dann aus dem RAM ausgeführt?
Bei uns waren die Quelltexte auch auf Lochkarten. Ein Programmjob bestand aus einem Stapel Lochkarten, der in einzelne sections unterteilt war. Es begann mit ein paar Steuerkarten (Accountkarte mit Projektname bzw. Kostenstelle etc., dann je nach Bedarf ein paar Karten mit Anweisungen an das OS, was zu tun ist, z.B. FTN-Compiler aufrufen und dann das Programm ausführen). Dann kommt eine spezielle Lochkarte "end of section". In der zweiten section war dann (wenn in der ersten der Compiler aufgerufen wird) der komplette Quelltext, je Karte das, was heute eine Zeile ist. Danach wieder eine Karte "end of section". In der der dritten section kam dann die Standardeingabe des Programms, also was man am Terminal eintippen würde, Zeile für Zeile. Hinter allen sections kam wieder eine spezielle Karte "end of information". Mehrere solche Jobs wurden dann vom Operator in einem Rutsch in den Kartenleser gefüttert. Die Standardausgabe des Jobs landet dann auf dem Banddrucker auf Elefantenklopapier, also die Diagnosemeldungen zu den Anweisungen der Steuerkarten, evtl. Fehlermeldungen des Compilers, wnen alles gut läuft die Standardausgabe des gelaufenen Programms, oder bei einem Abbruch der Kerneldump als Text (Adressen und Hex-Werte des Speichers, Register...).
Bronco schrieb: > Aber wie muss man sich denn den Build-Vorgang vorstellen? > Hat man den Sourcecode (als Daten) am Schalter abgegeben und einen > Lochstreifen mit Executable zurückbekommen? > Oder hat der Rechner den Sourcecode eingelesen, ins RAM compiliert und > dann aus dem RAM ausgeführt? Es gab den key Punch Operator, eine Sekretärin zum Lochkartenschreiben. Die bekam einen handschriftlichen Zettel, oder die korrigierten Lochkarten vom vorherigen Lauf. Ärmere Programmierer mussten selber stanzen. Immerhin kann man aus einem Satz von Karten (A=1; DO 100 I = 1, 10 ; etc.) die Hälfte der Programmzeilen eines neuen Programms zusammensuchen.
Bronco schrieb: > Aber wie muss man sich denn den Build-Vorgang vorstellen? > Hat man den Sourcecode (als Daten) am Schalter abgegeben und einen > Lochstreifen mit Executable zurückbekommen? > Oder hat der Rechner den Sourcecode eingelesen, ins RAM compiliert und > dann aus dem RAM ausgeführt? Wir mussten den ganzen Stapel (siehe oben) in einem Regal ablegen, der Operator kommt von Zeit zu Zeit vorbei und karrt das ganze Regal in den magischen Raum und füttert alles in den Kartenleser. In dem Raum, wo man die Karten abgibt, waren auch die Regale für die Ausgabe auf Endlospapier (sortiert in Fächer nach der Projektnummer, also anhand der Accountkarte aus der section mit den Steuerkarten. Man legt also den Stapel mit den Lochkarten ab, und bekommt irgendwann die Ausgabe auf Papier. Dann schaut man, was schief gelaufen ist, versucht etwas Zeit an einem Kartenstanzer zu bekommen, korrigiert bzw. schreibt falsche Karten neu (gelocht ist gelocht), und gibt den Stapel wieder ab. Nach ein paar Stunden ...
Klaus Wachtler schrieb:
...viele interessante Dinge...
Das heißt, man konnte dem Computer direkt den Hochsprachen-Sourcecode
auf Lochkarten geben, und dieser hat ihn übersetzt, ausgeführt und man
bekam dann als Ergebnis die Ausgabe zurück?
Bronco schrieb: > Klaus Wachtler schrieb: > ...viele interessante Dinge... > > Das heißt, man konnte dem Computer direkt den Hochsprachen-Sourcecode > auf Lochkarten geben, und dieser hat ihn übersetzt, ausgeführt und man > bekam dann als Ergebnis die Ausgabe zurück? Genau. Ich kann mich erinnern, dass ich am Ernst-Reuter-Platz in Berlin, wo die FU ihren Rechner stehen hatte ab und zu mal eine Lochkarte gefunden habe. Da lief ich auf dem Weg zur Bibliothek vorbei, von einem 6502 träumend meine Geldvorräte im Geiste zusammenzählend und lugte sehnsüchtig ins Erdgeschoß, wo die Lochkartenstanzer standen. Hoffe das das alles nur Fehllochungen waren, die ich da gefunden habe.
Ja, das konnte man. Erst die Steuerinformationen (Jobname, E/A-Ziele usw) und dann der Sourcecode (z.B. direkt PL/1). Gruß
Jan A. schrieb: > Erst die Steuerinformationen (Jobname, E/A-Ziele usw) Wobei die IBM JCL extrem kryptisch aussieht: https://de.wikipedia.org/wiki/Job_Control_Language#Beispiele
Klaus schrieb: > Hoffe das das alles nur Fehllochungen waren, die ich da gefunden habe. Ja, sorry, das waren meine Fehllochungen. Man konnte das Ergebnis ja auch auf das Punch-Device schicken, um es dann mit dem nächsten Programm weiter zu verarbeiten. Dumm nur, wenn die Daten wegen einer Endlosschleife endlos ausgegeben wurden. Zum Glück schlug irgendwann das Card-Limit zu und terminierte das Programm, um dann noch den aktuellen Speicher mit ein paar Seiten Core Dump auszudrucken :-( Es war übrigens der P-Pascal Compiler der ETH Zürich, der meine persönlichen Pascal-Compiler in ca. 30.000 Zeilen P-Code übersetzen sollte. Leider war der Karton Lochkarten dann wertlos weil unvollständig. Übrigens: die FU hatte dort keine Rechner, es war die TU, ein kleiner wichtiger Unterschied. Gruß, Michael
Wir hatten an einem KRS4201 http://www.robotrontechnik.de/index.htm?/html/computer/r4201.htm einen Lochkartenleser. Von den Datenerfasserinnen wurden auf DARO-Maschinen Produktions -und Lohndaten etc. auf Lochkarte ausgegeben, die dann im Zuge der Programmausführung in das KRS4201 eingelesen wurden. Die Programme selbst wurden in Algol 60 geschrieben und waren auf Magnetrommelspeichern "gelagert" Aufgerufen wurde immer eine Abfolge von Programmen, (eine Art Batch-Datei, die jeweils per Lochstreifen eingelesen wurde. Programmeldungen gab man auf sog. Bediendrucker aus, damit war auch gleich der Programmlauf dokumentiert und falls Fehler auftraten, konnten die Progarmmierer(innen) sehen, wo es hing. Jeden Freitag war die Spätschicht für die Programmierer reserviert, damit sie neue Programme ausprobieren und korrigieren konnten. Ausgegeben wurden die Resultate auf Magnetband oder Listen eben auf Parallel-Drucker. MfG Paul
Michael Appelt schrieb: > Klaus schrieb: >> Hoffe das das alles nur Fehllochungen waren, die ich da gefunden habe. > > Ja, sorry, das waren meine Fehllochungen. Nicht schlimm. Für mich waren das schöne Andenken. Wann kam man als kleiner Lehrling schon mal an solche Lochkarten. > Übrigens: die FU hatte dort keine Rechner, es war die TU, ein kleiner > wichtiger Unterschied. Richtig. TU. FU ist ja im Südwesten. Bin zutiefst zerknirscht.
das waren noch zeiten, ich habe 1984 ausgelernt. eser, ibm und krs, ach icl gab es auch noch. :D
Hmmm ... Lochkarten, Compiler, Hiwis die die Stapel durch die Gegend schleppten ... davon träumte ich damals als ich vor so einer Büchse http://www.vintagecomputer.net/digital/pdp11-40/PDP11-40_fontpanel.JPG saß und meine selbst assemblierten Programme binär in den Kernspeicher geladen habe ... Erst wenn man das zur Zufriedenheit des Prof. beherrschte durfte man die "höheren" Gerätschaften wie TTY und Lochstreifenstanzer/leser nutzen ...
Als ich studierte, war an der Uni bereits das Terminal-Zeitalter angebrochen. Die Lochkartengeräte waren aber noch nicht entsorgt, sondern wurden in frei zugänglichen Räumen weiterbetrieben. So konnte man – wenn es einen interessierte – diese alte, aber überaus geniale Technik hautnah erleben. Einen Stapel von ca. 500 Karten in den monströsen Kartenleser einzulegen und zuzusehen, wie dieser den Stapel mit lautem Rattern in weniger als 30 Sekunden verschlang, ist ein Erlebnis, das man nicht so schnell vergisst :) Zusätzlich zu diesem Kartenleser gab es auch noch einen automatische Stanzer (mit dem Dateien mit einem rasenden Tempo auf Lochkarten gebackupt werden konnten), eine Lochkartenbeschrifter (der auf bestehende Lochkarten den decodierten Quelltext aufdruckte) und einen Kettendrucker. Alles sauschnell und höllenlaut, richtige Mechanik eben, die bis an die Grenze des physikalisch Machbaren optimiert war :)
Bronco schrieb: > Hat man den Sourcecode (als Daten) am Schalter abgegeben und einen > Lochstreifen mit Executable zurückbekommen? Aus Sicht der Benutzer (Studenten) gab es sowas wie Executables garnicht, und Lochstreifen waren sowieso extrem unüblich, die wurden für NC-Maschinen verwendet, ganz andere Baustelle. Für die Lochkarten mit dem Sourcecode gab es längliche Kästen wie heute noch für Karteikarten, die hat man abgegeben und irgendwann wurden sie der Anlage zum Frass vorgeworfen - es wurde compiliert, wenn kein Fehler ausgeführt, und der Auftraggeber erhielt seine Lochkarten plus Ausdruck der Rechenergebnisse oder eben Fehlermeldungen zurück. Was im Erfolgsfall gedruckt werden sollte musste man natürlich im Programm formulieren. Der Buildprozess war also für uns Lochkartenstapel -> Ergebnisausdruck. Georg
Georg schrieb: > Lochstreifen waren sowieso extrem unüblich Bei Großrechnern schon, bei „Minis“ (PDP-11, oder das von Paul genannte KRS-4201, das wohl ein Honeywell-Clone ware) dagegen eher noch. Ich weiß gar nicht, ob ich meine BASIC-Mondlandungs-Lochstreifen noch irgendwo habe. ;-) Am PDP-11-Clone (K1630) hatten wir allerdings Magnetbänder. Die lagen zwar in der Rechenstation, aber jeder hatte ein persönliches.
:
Bearbeitet durch Moderator
Wenn man sich Eure Erzählungen so anhört, kann man sich schwer vorstellen, dass damals Computer effizient zu produktiven Zwecken (in Firmen und Behörden) eingesetzt werden konnte. Die Aufwand, Daten in eine maschinenlesbare Form zu bringen, muß doch gigantisch gewesen sein, von den Fehlerquellen ganz abgesehen. Ich frage mich, wie man damals sichergestellt hat, dass eine so berechnete Lohnbuchhaltung (o.ä.) tatsächlich halbwegs gestimmt hat.
Bronco schrieb: > Die Aufwand, Daten in > eine maschinenlesbare Form zu bringen, muß doch gigantisch gewesen sein, > von den Fehlerquellen ganz abgesehen. Nein, so schlimm war das nicht. Die Programmierer haben einen ganz normalen Quelltext in Algol 60 auf einem sog. DEG (Datenerfassungsgerät) geschrieben. Dort konnte man dann auf Lochstreifen ausgeben. Auf dem KRS konnte man einen Kompiler laufen lassen, den Lochstreifen einlesen und übersetzen lassen und die dabei entstehende ausführbare Datei entweder auf dem Trommelspeicher "lagern", auf Magnetband ausgeben oder auch wieder ausstanzen lassen. (Archivierung) Man konnte (wenn Rechnerzeit frei war (o.g. Freitag Nachmittag)) auch den Quelltext direkt in den Bediendrucker oder das Bildschirmterminal wämmern und brauchte den Zwischenschritt von oben nicht zu machen. Fehler beim Kompilieren konnte man auch gleich auf den Bediendrucker ausgeben lassen und enteder gleich beheben (Semikolon vergessen oder so) Größer "Späße" wurden dann offline verbessert und erneut dem freundlichen Kompiler zum Fraß vorgeworfen. Anders mache ich es heute auch nicht... MfG Paul
Paul Baumann schrieb: > Anders mache ich es heute auch nicht... Wie Paul, du hast noch einen Stanzer an deinem PC :=)
Helmut Lenzen schrieb: > Wie Paul, du hast noch einen Stanzer an deinem PC :=) Wie willst du denn sonst deine Software so archivieren, dass man sie auch in 100 Jahren noch entziffern kann? 8.)
für Nostalgiker zum Nachfühlen: Google60: Lochkarten-Großrechner aus den 60ern in HTML5 nachgebaut http://t3n.de/news/google60-lochkarten-grosrechner-432196/ http://www.masswerk.at/google60/
Bronco schrieb: > Ich frage mich, wie man damals sichergestellt hat, dass eine so > berechnete Lohnbuchhaltung (o.ä.) tatsächlich halbwegs gestimmt hat. Hallo, die Lohndaten wie geleistete Stunden wurden gelocht, d.h. am Kartenlocher eingegeben. Um Tippfehler zu verhindern wurde an einem 2. Arbeitsplatz Prüfgelocht, d.h. es wurde mit der vorhandenen Karte erneut eingegeben und die Tasteneingabe mit den vorhandenen Löchern verglichen. Gruß, Michael
Bronco schrieb: > Ich frage mich, wie man damals sichergestellt hat, dass eine so > berechnete Lohnbuchhaltung (o.ä.) tatsächlich halbwegs gestimmt hat. Das war nie mehr Arbeit, als manuell, im Gegenteil, es wurde automatisiert gerechnet, addiert etc., aber ja: Buchhaltung war damals teuer. Damals hat man sich bei den eingegebenen Daten noch Mühe gegeben, damit sie gestimmt haben, denn jeder Fehler machte Mühe. Heute wird drauf geschissen und täglich mehrmals Fehler gemacht die dann der Kunde ausbaden muss.
Bronco schrieb: > Wenn man sich Eure Erzählungen so anhört, kann man sich schwer > vorstellen, dass damals Computer effizient zu produktiven Zwecken (in > Firmen und Behörden) eingesetzt werden konnte. Computer wurden früher nicht für jeden möglichen Kleinkram eingesetzt, sondern nur für einige wenige Vorgänge, bei denen die Produktivität gewährleistet war. Für Geschäftsbriefe o.ä. hätte man damals eine Schreibmaschine verwendet und keinen Computer, und zwar vor allem aus Kostengründen. Irgendwann gab es dann auch Grenzfälle, z.B. bei elektrischen Schreibmaschinen mit Textspeicher. Kugelkopfschreibmaschinen (insbesondere von IBM) und Terminals mit Kugelkopfdrucker waren mechanisch sehr ähnlich aufgebaut. > Die Aufwand, Daten in > eine maschinenlesbare Form zu bringen, muß doch gigantisch gewesen sein, > von den Fehlerquellen ganz abgesehen. Es gab einen Haufen mechanischer Hilfsmittel, um sich das Leben einfach zu machen. Damals ging man viel bewusster mit der Ressource Computer um, insbesondere auch wegen der exorbitanten Kosten. In meiner Kindheit begleitete ich meine Eltern des öfteren zum Einkaufen in den Großmarkt, vergleichbar mit heutzutage Metro oder Citti. An den Regalen befand sich bei jedem Artikel ein Fach mit Lochkarten. Man nahm also z.B. eine Flasche Ketchup und die zugehörige Lochkarte heraus. Am Einkaufswagen befand sich ein Klemmbrett für die Lochkarten. An der Kasse wurde der eigene Einkaufswagen dann einem anderen leeren Einkaufswagen gegenübergestellt. Man gab der Kassiererin den Stapel Lochkarten und lud die Artikel dann auf den neuen Wagen um. Die Kassiererin kontrollierte dabei die Vollständigkeit der Lochkarten. Das ging alles mindestens so schnell wie heute an der Supermarktkasse. Der leere eigene Einkaufswagen wurden zum Schluss umgedreht für den nächsten Kunden. Der Stapel Lochkarten enthielt als erste Karte die eigene Kundenkarte und wurde auf ein Transportband oberhalb des Durchganges zwischen des Kontrollstationen gelegt. Ich war als Kind immer ganz begeistert davon, wie schnell die Lochkarten dann zum Lochkartenleser transportiert und dort automatisch eingelesen wurden. Beim Hinausgehen ging man dann an der eigentlichen Kasse vorbei und bezahlte. Dort lag schon die auf einem unglaublich schnellen Kettendrucker erstellte Rechnung bereit. Leider weiß ich nicht mehr, ob die Lochkarten schon gleich beim Einlesen wieder sortiert wurden oder ob das separat erfolgte. Schließlich gab es ja Tausende verschiedener Artikel mit jeweils eigenen Kartenfächern. Die Relikte kann man heute in manchen Großmärkten noch sehen. Vielleicht hat sich schon manch einer darüber gewundert, dass etliche ältere Regale an der Vorderkante einen tiefen Schlitz aufweisen. Dort lagen früher die Lochkarten drin. > Ich frage mich, wie man damals sichergestellt hat, dass eine so > berechnete Lohnbuchhaltung (o.ä.) tatsächlich halbwegs gestimmt hat. Wie schon erwähnt, gab es viele Hilfsmittel. Meine Eltern hatten für die Buchhaltung ein System von Taylorix, welches aber nicht computergestützt war. Den Begriff "Buchungsjournal" findet man auch heutzutage noch in so ziemlich jeder Buchhaltungssoftware. Er stammt aber von Taylorix: http://www.computermuseum-muenchen.de/computer/taylorix/ http://www.stb-betzwieser.de/aktuelles/ausstellung/kategorien-1/taylorix.php
Übrigens sind alle Berichte, dass der Terminator in Fortran auf Lochband programmiert wurde einfach übertrieben. Das war 6502-Assembler: http://www.pagetable.com/docs/terminator/00-37-23.jpg :D
Die schönen Kettendrucker. Unsere Firma hat ihren letzten von ca. 12 Jahren verschenkt. Hat über 100kg gewogen, deshalb habe ich nicht zugeschlagen.
Yalu X. schrieb: > Als ich studierte, war an der Uni bereits das Terminal-Zeitalter > angebrochen. Die Lochkartengeräte waren aber noch nicht entsorgt, > sondern wurden in frei zugänglichen Räumen weiterbetrieben. Es gab Anfang der 80er am Mainframe der Informatiker (TR440 von ~1970) noch beides. Denn von den Terminals gab es relativ wenige (darunter aber immerhin ein grafikfähiges mit Rollkugel), so dass die Anfänger noch ganz klassisch per Lochkarte und Papierstapel arbeiten durften.
Udo Schmitt schrieb: > ie schönen Kettendrucker. Unsere Firma hat ihren letzten von ca. 12 > Jahren verschenkt. Konnte der überhaupt Umlaute drucken? Von Grafik mal ganz abgesehen. Und das Endlospapier verursachte auch seine Kosten, ganz extrem wenn man Durchschläge brauchte. Georg
Bronco schrieb: > Oder hat der Rechner den Sourcecode eingelesen, ins RAM compiliert und > dann aus dem RAM ausgeführt? RAM war teuer. Und Compiler brauchten damals oft mehrere Durchläufe. Da konnte beispielsweise Magnettrommel-Speicher dazwischen liegen, oder früher Plattenspeicher. Im klassischen Batch-Ablauf bei den Mainframes wurden die Jobs von den Lochkarten erst einmal von einem kleinen Vorrechner eingesammelt und zusammen auf einem Band geparkt. Das Band landete dann irgendwann am Mainframe und wurde von dem abgearbeitet. Mit den Ergebnissen lief es ähnlich, d.h. der Mainframe schmiss es auf Band aus und der Vorrechner schob es dann auf den Drucker.
Georg schrieb: > Udo Schmitt schrieb: >> ie schönen Kettendrucker. Unsere Firma hat ihren letzten von ca. 12 >> Jahren verschenkt. > > Konnte der überhaupt Umlaute drucken? Von Grafik mal ganz abgesehen. Und > das Endlospapier verursachte auch seine Kosten, ganz extrem wenn man > Durchschläge brauchte. Nur, wenn die Umlaute auf dem umlaufenden Stahlband waren. Also nein :-)
Georg schrieb: > Konnte der überhaupt Umlaute drucken? Von Grafik mal ganz abgesehen. Und > das Endlospapier verursachte auch seine Kosten, ganz extrem wenn man > Durchschläge brauchte. Umlaute bin ich mir nicht sicher. Ich weiss nur, dass die Jungs, die bei uns die Programme für IBM Host schrieben statt geschweifte Klammern Umlaute eingetippt hatten. Irgendwann hatte ich mal rausgefunden, das das eigentlich nur daran lag, dass der alte C Compiler fest den US EBCDIC Zeichensatz benutzte, der IBM Rechner bzw. die Terminals aber auf deutschen EBCDIC Zeichensatz konfiguriert waren. Man hätte den neueren Compilern durchaus als Parameter mitgeben können dass die Sourcen als deutscher EBCDIC codiert wären, aber keine hat sich getraut das alles umzustellen. Das Druckpapier war günstig, Durchschläge gabs ja nicht war ja reine SW Entwicklung. Das war Recyclingpapier A3, das kam bei jedem Fehler als Dump kiloweise aus dem Drucker gerattert.
Georg schrieb: > Konnte der überhaupt Umlaute drucken? Im wissenschaftlichen Kontext waren 6-Bit Zeichensätze recht beliebt. Da fehlten nicht nur die Umlaute, sondern auch die Kleinbuchstaben. Dafür passten 6 Zeichen in ein 36-Bit Wort (1), oder 10 in ein 60-Bit Wort (2). Textverarbeitung war sowieso nicht das Mass der Dinge auf diesen Rechnern. 1: Die Begrenzung externer Namen in frühem C auf eindeutige 6 Zeichen dürfte damit zu tun haben. 2: Weshalb man im Wirth'schen Pascal-Handbuch einem seltsam anmutenden fest eingebauten 10-Zeichen String begegnete (implementation report). Da aber auch 8-Bit Zeichensätze aufkamen fand man bei den Maschinen ein ziemliches Wirrwar an Zeichensätzen vor. Die 60-Bit CDCs verwendeten dann beides, 6 Bits und 8 Bits, je nach Kontext und Laune. War aber letztlich egal, da deren Prozessoren Hardware keinerlei Zeichenverarbeitung kannten, sondern eben nur 60 Bits breite Daten mit Wortadressierung. Bei den IBMs war es ab 360 klarer, die hatten Stringverarbeitung und Byteadressierung und haufenweise Codepages für die jeweiligen nationalen Umlaute. Aber dafür EBCIC- statt ASCII-Code.
:
Bearbeitet durch User
Meine Güte .... und ich dachte schon, ich wäre ein alter Sack! <:-} Aber sehr interessant, das alles. Meine "Karriere" begann erst 1983 mit einem VC-20.
:
Bearbeitet durch Moderator
Chris D. schrieb: > Meine "Karriere" begann erst 1983 mit > einem VC-20. Meine 1984 mit einem IBM PC XT clone für viel Geld. Aber ich war/bin in einer Firma die heute noch die Software für alle möglichen Betriebssysteme schreibt. Unsere Hauptsoftware gab es damals für Windows16, Win-NT, OS/2, AIX, SUN, HP-UX, AS400, VAX-MVS, BS-2000, und IBM Host mit MVS, CICS, und noch 2 oder 3 anderen IBM Host Subsystemen. Insofern hatte ich mehr oder weniger intensive Berührung mit diversen Rechnern und Betriebssystemen, zumal wir alle diese Systeme im eigenen Haus hatten.
A. K. schrieb: > 1: Die Begrenzung externer Namen in frühem C auf eindeutige 6 Zeichen > dürfte damit zu tun haben. Bzw. „geerbt“ vom Linker, der wiederum zuvor FORTRAN gelinkt hat, welches ebenfalls nur 6-Zeichen-Bezeichner kannte. Daher lesen sich ja FORTRN PRGRME AUCH IMMER SO SCHLCH WAS WILL MAN MACHEN MIT NUR SECHS ZEICHN? ;-) Aber gut möglich, dass der das wiederum aus den 36-Bit-Zeichen herleitete … auf der PDP-11 wiederum passten halt die 6 Zeichen hervorragend in zwei RADIX50-Worte.
Jörg Wunsch schrieb: > Bzw. „geerbt“ vom Linker, der wiederum zuvor FORTRAN gelinkt hat, > welches ebenfalls nur 6-Zeichen-Bezeichner kannte. Daher lesen > sich ja FORTRN PRGRME AUCH IMMER SO SCHLCH WAS WILL MAN MACHEN MIT > NUR SECHS ZEICHN? ;-) Stell dich nicht an, immerhin kann man Leerzeichen auch innerhalb von Namen einstreuen, wie man will. Das erlaubt sehr schöne Schreibweisen!
Weiss einer von euch noch was eine Patch-Area in einem Programm ist?
Udo Schmitt schrieb: > Weiss einer von euch noch was eine Patch-Area in einem Programm ist? Klar. Wenn der Binärcode gepatcht werden musste. An der zu fixenden Stelle landet dann ein Sprung in die Patch-Area und in dieser der Ersatzcode, der anschliessend zurück sprang. Beim AIM65 (6502 Rechnerlein) hatte Rockwell in seltsam anmutender Hybris im Monitor keine Sprungleiste implementiert. Weshalb Anwendercode in den Zusatz-ROMs direkt eine Funktion auf Adresse $EBDB aufrief. Spätere Korrekturen durften folglich die Adresse nicht ändern und am Ende vom ROM stapelten sich solche Flicken. Ich meine mich zu erinnern, dass auch IBMs XT BIOS ein paar solcher Flicken enthält.
:
Bearbeitet durch User
A. K. schrieb: > Klar. Wenn der Binärcode gepatcht werden musste. An der zu fixenden > Stelle landet dann ein Sprung in die Patch-Area und in dieser der > Ersatzcode, der anschliessend zurück sprang. Genau, weil eine offizielle Auslieferung auf Band wäre viel zu aufwändig gewesen und der Betrieb des Hosts hätte zum Einspielen unterbrochen werden müssen. So konnte das des Systemoperator direkt im laufenden Betrieb patchen. Ich komme wie gesagt aus der PC Ecke, als ich das das erste Mal erklärt bekam waren meine Augen größer als 5Mark Stücke :-)
Udo Schmitt schrieb: > So konnte das des Systemoperator direkt im laufenden Betrieb patchen. Und so etwas wird doch heute auch noch bei SPS-basierten Steuerungen gemacht, wenn eine Anlage zwischendurch nicht angehalten werden darf. So übel STEP7 auch ist, zumindest hat Siemens den Austausch von FB/FC usw. im laufenden Betrieb wohl besser hinbekommen als andere Anbieter. Dennoch kracht es aber ganz gewaltig, wenn z.B. die Daten in einem DB auch nur etwas anders angeordnet sind.
Helmut Lenzen schrieb: > Wie Paul, du hast noch einen Stanzer an deinem PC :=) Ich hab' noch einen Stanzer in Berlin.... ;-) Ha! Hast Du mich erwischt -ich habe mich verdrückt ausgekehrt. MfG Paul
Udo Schmitt schrieb: > A. K. schrieb: >> Klar. Wenn der Binärcode gepatcht werden musste. An der zu fixenden >> Stelle landet dann ein Sprung in die Patch-Area und in dieser der >> Ersatzcode, der anschliessend zurück sprang. > > Genau, weil eine offizielle Auslieferung auf Band wäre viel zu aufwändig > gewesen und der Betrieb des Hosts hätte zum Einspielen unterbrochen > werden müssen. > So konnte das des Systemoperator direkt im laufenden Betrieb patchen. > Ich komme wie gesagt aus der PC Ecke, als ich das das erste Mal erklärt > bekam waren meine Augen größer als 5Mark Stücke :-) Mittlerweile hält das wieder Einzug in Marktübliche Betriebssysteme: http://en.wikipedia.org/wiki/Kpatch
Bei uns gabs 1973 eine IBM1620 im geheiligten Raum. Morgens wenn wir Studenten zu früh kamen, war der Raum noch nicht auf einer der 1620 genehmen Temperatur und nichts lief bis dass der HiWi die Klimaanlage passend reguliert hatte. Unsere FORTRAN Programme mussten wir selber auf Karten stanzen. Käse wenn man sich vertippt hatte oder Fehler im Code waren. Ein Jahr später gab es dann so eine kleine Olivetti, halb so gross wie eine Schreibmaschine, mit einer kleinen Tastatur und Ausgabe über eingebautem Drucker. Wie die programmiert wurde kann ich mich nur noch schemenhaft erinnern, auf jeden Fall schon was komfortableres als Assembler.
:
Bearbeitet durch User
Ja den AIM65 hab ich auch noch irgendwo rumstehen, einschließlich einiger Compact-Cassetten mit Programmen drauf. 1979 gekauft mit sagenhaften 1k RAM, bald auf 4k erweitert, später auf 32k. Dazu die beiden teuren BASIC-ROMs ca. 300DM damals, auch ein Assembler im ROM. Später hatte ich dafür ein "Elekterminal" mit SW-Fernseher dran. Es gab einen AIM65-Emulator auf dem AppleÜÄ, vom Franzis-Verlag/mc, aber der konnte natürlich die echte Hardware nicht emulieren. Damit ließe sich heute der wieder auf dem PC emulieren.
Für die Lochkarten gab es an der TU Dresden am Zelleschen Weg eine Tür mit dem Schild "Kundenlocherei". Dahinter hätte sich auch eine sadistische Studentenvereinigung befinden können. Es war aber: die wissenschaftliche, marxistisch-leninistische und friedenserhaltende Stelle zur Umsetzung des Programmes des ??.Parteitages der sozialistischen Einheitspartei Deutschlands (SED) für die planwirtschaftlich gebotene Übertragung eines PL/1-Quelltextes auf Lochkarten. Krank, oder?
Tulsa Oklahoma schrieb: > Krank, oder? Krank wäre es gewesen, wie per Türschild angekündigt die Kunden einzulochen statt der Karten.
:
Bearbeitet durch User
ach ja, damals bits geschubst, heute dot.net bibliothekar. bin in den keller gegangen, und habe meine (lauffähige) pdp-7 gestreichelt...
Bronco schrieb: > Aber wie hat man ohne Bildschirm-Terminal Sourcecode eingegeben? Mit einem ganz gewöhnlichen Fernschreiber. Ein weit verbreiteter Editor war z.B. TECO von DEC. Durch entsprechende Kommandos hat man sich im Text bewegt und ihn bearbeitet. Ab und zu war es gut, mal ein paar Zeilen zurück zu gehen und sie vollständig zu Papier zu bringen ;-) Mit TECO konnte man aber auch ganze Makros zur Bearbeitung des Textes bauen. http://de.wikipedia.org/wiki/TECO_%28Texteditor%29
Wolfgang schrieb: > Ein weit verbreiteter Editor > war z.B. TECO von DEC Editor war damals noch lange nicht. Egal ob Lochkarte oder Lochstreifen, ein A auf der Tastatur tippen und sofort Ratsch waren die entsprechenden Löcher gestanzt. Bei Fehlern neue Karte oder bei Lochstreifen zurück und DEL (alle Löcher) drüberstanzen. Fördert sehr das fehlerfreie Tippen. Georg
lover schrieb: > und habe meine (lauffähige) pdp-7 gestreichelt... Du hast ne PDP7 im Keller? Das ist nicht dein Ernst, oder?
Bronco schrieb: > Ich kann mir ja noch vorstellen, dass ein damaliger Computer > Maschinencode von Lochkarten lesen und abarbeiten konnte. Falsch. Ganz falsch. Was man da gestanzt hatte, war Quellcode und der auf dem Mainframe werkelnde Compiler hat daraus den eigentlichen Maschinencode gemacht - den man freilich NIE selber gesehen hat. Es ist schon erstaunlich, wie schnell es geht, bis daß die Leute niht mehr begreifen können, was doch die eigentlichen Grundlagen ihrer üblichen Betätigung sind. Also: Thema Lochkarten: Da gab es im (oder sollte man besser sagen "beim") Rechenzentrum einen Raum, wo Lochkarten-Stanzgeräte standen. Sah so aus wie eine Art zu groß geratene Schreibmaschine auf einem Schreibtisch. Dort konnte man seinen Quelltext in die Maschine reinhacken und mit jedem Tastendruck wurde eine Spalte auf der Karte gestanzt. Vertippt? --> neue Karte und nochmal. Hatte man seinen Quelltext fertig getippt, kam er in eine Art flache Blechkiste. Nun gab es ein winzig kleines Fenster in der fetten Betonwand zwischen dem Userbereich und dem eigentlichen Rechenzentrum. Dort konnte man auf nen Klingelknopf drücken und nach angemessener Wartezeit erschien dann auch so ein Admi, um den Blechkasten mit dem Quellcode entgegenzunehmen und dabei Kostenstelle und sonstige kommerziellen Details abzufragen. Nach einem Tag durfte man dann wieder an diesem Fensterchen antanzen und bekam seinen Blechkasten zurück. Obendrauf lag ein mehr oder weniger dicker Stapel von Leporellopapier in A3, quer gedruckt mit nem Paralleldrucker (jede Zeile mit eigenem Wellengang, also kein Zeichen auf der Höhe wie das andere und obendrein bei O und Nullen das Papier drin halb rausgehackt). Das war's. War der Stapel ganz dünn, dann bestand er nur aus dem Abrechnungsbogen mit Fehlermeldung, pro Sekunde Bearbeitungszeit etwa 100 Mark teuer. Ätsch. Thema Lochband: Editieren von Quellcode mit einer Art Teletype direkt am Rechner, natürlich OHNE den aktuellen Text sehen zu können. Dafür hatte man ja seine Übersetzungsliste. Den zu editierenen Quelltext mußte man zuerst in den Lochbandleser einlegen und den Lochbandstanzer mit ner frischen Rolle Lochband bestücken. Dann Editor starten und los gings: COPY (bis Zeile) 73, EDIT, (Zeile 74 wurde auf Teletype ausgedruckt) dann Zeile nochmal und bittesehr richtig eintippen, dann PUNCH. Dann weiter mt COPY 196, EDIT.. und so weiter. Höchst komfortabel, sag ich euch!!!! Natürlich bekam man als Student seine Rechenzeit zu den besten Zeiten, also so etwa von 2.00 "morgens" bis 4.30 "morgens". Also, wo man am besten konzentriert und wach war.. Anschließend auf den Knopf am Stanzer drücken wegen des Nachlaufes, Lochband abreißen und aufwickeln. Dann Editor beenden, den Fortran-Compiler reinladen, Lochband in den Leser laden, Compiler starten.. warten bis er fertig war und nicht gemeckert hat, Lochband nochmal aufrollen, nochmal in den Leser für den zweiten Pass, neues Band in den Stanzer, zweiten Pass starten. Quell-Lochband aufwickeln, vom Compiler gestanztes Band mit dem Objektcode aufwickeln, Compiler beenden, Systemlinker laden, Objektcodeband in den Leser, Linker starten, dann endlich das eigene Werk bewundern.. im Allgemeinen gab's da nix außer entweder einem Ausdruck auf dem Paralleldrucker oder wieder ein Lochband zu bewundern.. Ich hab wahrscheinlich zu meiner Studentenzeit den Äquator aus Lochband mindestens dreimal aufgewickelt, wenn nicht noch mehr. Aus der Zeit stammt auch, daß ich vorher lieber gründlich nachdenke. Die heurigen Hasen machen es genau anders herum: zuerst was eintippen, dann Compiler starten, dann Debugger starten, dann sehen (oder nicht) was draus geworden ist - huch, da kommt ja was ganz anderes raus, als ich mir gedacht habe.. nee, diese Spezies hat nicht gedacht. W.S.
W.S. schrieb: > Falsch. Ganz falsch. Was man da gestanzt hatte, war Quellcode und der > auf dem Mainframe werkelnde Compiler hat daraus den eigentlichen > Maschinencode gemacht - den man freilich NIE selber gesehen hat Doch, wir hatten 1974 bei der IBM1620 eine Speicher-Abbild Möglichkeit und durften uns mit der Interpretation der Nullen und Einsen vergnügen. Der Prof und der Labor Hiwi wollten uns augenscheinlich quälen.
:
Bearbeitet durch User
Albert M. schrieb: > Doch, wir hatten 1974 bei der IBM1620 eine Speicher-Abbild Möglichkeit Analyse von Dumps war eine sehr verbreitet Debugging-Technik.
W.S. schrieb: > dann Compiler > starten, dann Debugger starten, dann sehen (oder nicht) was draus > geworden ist Das habe ich öfter als alternativen, aber etablierten Software-Entwicklungsstil kennengelernt, ich nenne das analytisch anstelle von synthetisch - man fängt mit einem einzelnen NOP als Programm an, und von da an sucht man mit Debuggerhilfe nach Gründen, warum nicht das gewünschte rauskommt. Georg
Bronco schrieb: > Hallo Freunde, > > die Frage ist ein wenig Off Topic, aber ich frage mich, wie man zur Zeit > der Lochkarten eine Hochsprache wie Fortran umsetzen konnte. > Ich kann mir ja noch vorstellen, dass ein damaliger Computer > Maschinencode von Lochkarten lesen und abarbeiten konnte. > Aber wie hat man ohne Bildschirm-Terminal Sourcecode eingegeben? Überraschung: zeitgenössische Telefone und Schreibmaschinen hatten auch keine Displays. :-) Ich habe noch als Gymnasiast Stunden und Tage an so einem Teil http://www.columbia.edu/cu/computinghistory/026.html verbracht, um Fortran- und dann später im Studium auch PL/I-Programme abzulochen. Da der 026 z.B. kein Semikolon konnte, mußte man mit Ersatzdarstellungen arbeiten, also ",." statt ";". Später gab es dann zusätzlich 029, die hatten einen erweiterten Zeichensatz. https://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV4002.html Dummerweise waren die natürlich immer als erste besetzt. :-) > Wie wurde der Compiler in den Computer geladen (oder war er fest > verdrahtet)? Nein, auf Tape oder auf Platte. Die IBM 7094 hatte durchaus schon Festplatten. http://en.wikipedia.org/wiki/IBM_7090 http://en.wikipedia.org/wiki/History_of_IBM_magnetic_disk_drives > Und wo wurde der vom Compiler erzeugte Maschinencode gespeichert? > Alles per Lochkarten? Gab's auch. > > Hat jemand vielleicht ein paar interessante Links? http://ibm-1401.info/1401-FORTRAN-Illustrated.html Kann man sich heute gar nicht mehr vorstellen.
Wolfgang S. schrieb: > Überraschung: zeitgenössische Telefone und Schreibmaschinen hatten auch > keine Displays. :-) Das Telefon in unserer WG hatte damals schon einen Gebührenzähler mit Ziffern.
Klaus Wachtler schrieb: > Wolfgang S. schrieb: >> Überraschung: zeitgenössische Telefone und Schreibmaschinen hatten auch >> keine Displays. :-) > > Das Telefon in unserer WG hatte damals schon einen Gebührenzähler mit > Ziffern. Es war ein Kommentar zu "wie hat man ohne Bildschirm-Terminal Sourcecode eingegeben?", also die Verwunderung darüber, wie die Text- oder Zifferneingabe auch ohne visuelle Rückkopplung funktioniert hat. Ein Gebührenzähler ist dafür nicht hilfreich. Ein noch weniger bekanntes resp. erinnertes Feature damaliger Locher ist übrigens das sog. "Prüflochen". Ich selber habe das nie benutzt, sondern die Compiler die Tippfehler raussuchen lassen, es war aber bei einigen Datenerfassungen nützlich, die ich damals organisiert habe. Im Prüflochmodus wurden die fertig gelochten Karten erneut eingelegt, statt der Leerkarten, und dann erneut "abgelocht", wobei aber nicht gelocht, sondern nur verglichen wurde. Ergab sich eine Diskrepanz, blockierte das Gerät und man konnte z.B. korrigieren, indem man den Locher die Karte bis zu dem Punkt duplizieren ließ und dann ausbesserte. So hat man auch "editiert". Ein weitereres Feature dieser gar nicht so trivialen Geräte war eine Programmiertrommel, mit dem man das Verhalten beim Lochen spaltenweise steuern konnte - Festwerte, Sprung nach Spalte x, etc. Details findet man vielleicht noch irgendwo im Web.
Wolfgang S. schrieb: > Die IBM 7094 hatte durchaus schon Festplatten. Die so genannten „Waschmaschinen“. ;-)
Andreas Schweigstill schrieb: > Das > ging alles mindestens so schnell wie heute an der Supermarktkasse. In meiner Kindheit war der Beruf einer Kassierin beim Hofer (Anm. Hofer = österreichischer Aldi) ein angesehener Beruf. Die Kassierinnen kannten alle Preise aller Produkte auswendig und tippten die in einer Windeseile in die Kasse, dass einem schwindlig wurde. Geschätzt würde ich mal sagen, dass 80% aller heutigen Kassierinnen selbst mit ihren Scannerkassen dieses Tempo bei weitem nicht erreichen.
W.S. schrieb: > Ich hab wahrscheinlich zu meiner Studentenzeit den Äquator aus Lochband > mindestens dreimal aufgewickelt, wenn nicht noch mehr. Aus der Zeit > stammt auch, daß ich vorher lieber gründlich nachdenke. In meiner Studentenzeit kriegten wir ebenfalls unsere Jobs des Nachts gerechnet. Und zwar jeder Job genau ein einziges mal pro Nacht. In jeder Woche gab es eine Übung, pro Übung 3 Stück 2 Wochen später abzuliefernde Aufgaben. Bei genau einem Compilerlauf täglich war ein vergessenes ';' eine mittlere Katastrophe. Wer 10 Compilerläufe brauchte um seine Syntaxfehler auszumerzen hatte kaum noch Chancen eventuelle Logikfehler zu beheben. Beherrschung der Syntax war das um und auf um weiter zu kommen.
:
Bearbeitet durch User
Wolfgang S. schrieb: >> Wie wurde der Compiler in den Computer geladen (oder war er fest >> verdrahtet)? > > Nein, auf Tape oder auf Platte. Die IBM 7094 hatte durchaus schon > Festplatten. Wobei man sagen muss, dass Platten ein Vermögen gekostet haben bei einer Kapazität, die einem heute nur noch ein müdes Lächeln entlockt. Auch interessant: Die 'ROM's für die Apollo-Mondflüge wurden von Hand, äh, gefädelt. (es war Kernspeicher) https://www.youtube.com/watch?v=YIBhPsyYCiM (ab 20:35)
:
Bearbeitet durch User
>> Die IBM 7094 hatte durchaus schon Festplatten. Jörg Wunsch schrieb: > Die so genannten „Waschmaschinen“. ;-) Ich hatte auch solche "Waschmaschinen" (m.E.n aus Bulgarien) bei der Materialbörse von Onkel Robotron in Karl-Marx-Stadt erbeutet Die hatten, glaube ich wnigstens 19MB Kapazität. Zwei davon habe ich mittels einer selbstgebauten Anpass-Karte an einem A5120 Bürocomputer betrieben. Der war der "Materialverwaltungsrechner" im Zentrallager und brauchte Speicherplatz. MfG Paul
Karl Heinz schrieb: > Wobei man sagen muss, dass Platten ein Vermögen gekostet haben bei einer > Kapazität, die einem heute nur noch ein müdes Lächeln entlockt. Naja, meine erste 20MByte NEC Platte von 1986 hatte auch rund 900DM gekostet. Paul Baumann schrieb: > Die hatten, glaube ich wnigstens 19MB Kapazität. Reicht ja locker fuer 4 Fotos......
Karl Heinz schrieb: > Auch interessant: Die 'ROM's für die Apollo-Mondflüge wurden von Hand, > äh, gefädelt. (es war Kernspeicher) Kernspeicher war doch RAM?
Helmut Lenzen schrieb: > Reicht ja locker fuer 4 Fotos. Damals gab's ja auch den berühmten Snoopy als ASCII-Art. :)
W.S. schrieb: > Es ist schon erstaunlich, wie schnell es geht, bis daß die Leute niht > mehr begreifen können, was doch die eigentlichen Grundlagen ihrer > üblichen Betätigung sind. Hmmm... von 1975 bis 2015... sind ja nur 40 Jahre, das ist echt verdammt schnell.
Klaus Wachtler schrieb: > Karl Heinz schrieb: >> Auch interessant: Die 'ROM's für die Apollo-Mondflüge wurden von Hand, >> äh, gefädelt. (es war Kernspeicher) > > Kernspeicher war doch RAM? In dem Fall nicht. Der Lesedraht ging entweder durch den Ring durch oder nicht durch. Dieser Speicher wurde wirklich in Handarbeit tatsächlich 'programmiert'.
Jörg Wunsch schrieb: > Helmut Lenzen schrieb: >> Reicht ja locker fuer 4 Fotos. > > Damals gab's ja auch den berühmten Snoopy als ASCII-Art. :) Oh. Ja. Die wurden damals regelrecht 'im Untergrund' gehandelt. Ich hatte einen 'Jesus' und einen Snoopy Calender aus ca. 1965 (war ab 1982 an der Uni). Im Rechenzentrum durften wir die nicht durch den Drucker jagen, das hätte Ärger gegeben. Aber im JCL-Praktikum hatten wir unsere eigene IBM-370/115 mit Kettendrucker :-) (und 4 MB Hauptspeicher in 2 Schränken, 2 Waschmaschinen, Lochkartenleser, Operator-Terminal mit eingebranntem Bild und riesigem Notausknopf. gebootet wurde von einer 8' Floppy)
Karl Heinz schrieb: > hätte Ärger gegeben. Aber im JCL-Praktikum hatten wir unsere eigene > IBM-370/115 mit Kettendrucker Ha! Weil es mich gerade interessiert hat: https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3115.html
1 | An optional integrated printer attachment permits use of the newly-announced IBM 3203 printer, with speeds of 600 or 1,200 lines per minute, |
1200 lines per minute sind 20 Zeilen in der Sekunde oder bei einer Standard-80 Zeilen Seite ca 4 Sekunden pro Seite. Hmm. Da sieht so mancher Laserdrucker heute alt aus. Von Tinenpissern reden wir erst mal gar nicht :-) (OK, ok. Das Schriftbild ist nicht zu vergleichen)
:
Bearbeitet durch User
Karl Heinz schrieb: >> Kernspeicher war doch RAM? > > In dem Fall nicht. > Der Lesedraht ging entweder durch den Ring durch oder nicht durch. > Dieser Speicher wurde wirklich in Handarbeit tatsächlich 'programmiert'. Das hatte ich auch noch gemacht bei Siemens Prozessrechnern. Das war bei Softwareänderungen ganz übel......
Jörg Wunsch schrieb: > Die so genannten „Waschmaschinen“. ;-) Als "Waschmaschine" bezeichne ich die IBM 3380 von 1980: http://www.suomentietokonemuseo.fi/vanhat/eng/ibm_3380_eng.htm Ältere IBM Plattensysteme hatten meist Wechselplattenstapel wie: http://en.wikipedia.org/wiki/File:IBM_2311_memory_unit.JPG http://en.wikipedia.org/wiki/File:IBM_magnetic_disk_drives_3330%2B3333.png Oder das erste Festplattensystem: http://de.wikipedia.org/wiki/IBM_350
:
Bearbeitet durch User
A. K. schrieb: > Ältere IBM Plattensysteme hatten meist Wechselplattenstapel wie: > http://en.wikipedia.org/wiki/File:IBM_2311_memory_unit.JPG > http://en.wikipedia.org/wiki/File:IBM_magnetic_disk_drives_3330%2B3333.png Von zwei solcher Platten habe ich noch eine Uhr an der Wand hängen. Ein Stapel mit 6 solcher Platten hatte 10Mb Kapazität
ououfiodfu schrieb: >> In dem Fall nicht. >> Der Lesedraht ging entweder durch den Ring durch oder nicht durch. >> Dieser Speicher wurde wirklich in Handarbeit tatsächlich 'programmiert'. > > Das hatte ich auch noch gemacht bei Siemens Prozessrechnern. Das war > bei Softwareänderungen ganz übel...... Und ich dachte immer, dass Abtippen von seitenlangen Hexdump aus 1980er-Computer-Magazinen sei mühsam...
Vor allem, wenn man aus der Aprilausgabe ein Programm abtippt, das den Atari ST beschleunigen soll, indem es angeblich die Taktfrequenz irgendwie hochsetzt von 8MHz auf 8.wenig. Und wenn man es fehlerfrei geschafft hat und es tatsächlich startet, gibt es aus "April, April"... (Glaube, das Pamphlet hieß "ST-Magazin").
ymmd na wer das nicht geblickt hatt dem gehörte es nicht anders. etwas HW Kenntis hätte den Unfug sicher vermieden, ebenso wenn man das mal im kopf dissasambliert hätte, aber dazu musste man schon etwas tiefer in die materie schauen können. Namaste
Jörg Wunsch schrieb: > Die so genannten „Waschmaschinen“. ;-) So eine hatte ich an meinem ersten Z80 System. Was war ein Teil von DEC 5MB Fest, 5MB Wechselbar. 80Kg schwer. Der Controller war ein einziges TTL-Grab. Hat mich ziemlich viel Nerven gekostet bis das ging. Das war natürlich eine riesiger Sprung nach vorne. Die Kumpels die so etwas nicht hatten mussten sich noch mit Lochstreifen oder Kassettenrecordern abplagen.
Erleuchteter schrieb: > Was war ein Teil von DEC > 5MB Fest, 5MB Wechselbar. 80Kg schwer. Ja, sowas in der Gewichtsklasse habe ich für meine HP2100. Dreizehn Zoll Plattendurchmesser. Allerdings nur mit je 2.5MB Speicherplatz.
Vielleicht mal nachforschen, die Grace Hopper das gemacht hat :-) http://de.wikipedia.org/wiki/Grace_Hopper#Leistungen
Klaus Wachtler schrieb: > Aprilausgabe Ich erinnere mich noch, dass es beim Amiga eine spezielle Tastenkombination gab, mit der man eine Überspannung erzeugen konnte, die zu einem gezielten Umprogrammieren der CustomChips führte, wodurch der Chipsatz auf eine neuere Generation gepatch wurde...
Jörg Wunsch schrieb: > Wolfgang S. schrieb: >> Die IBM 7094 hatte durchaus schon Festplatten. > > Die so genannten „Waschmaschinen“. ;-) nein die waschmaschinen waren die aus der udssr :D
So, jetzt wurde einige Male behauptet, man hätte die Ausdrucvke auf der IBM mit Kettendruckern gedruckt - es waren vermutlich Trommeldrucker. 1 Walze mit rundum verteilten Ascii-Zeichen. 132 Hämmerchen, 1 pro Stelle, klopft im richtigen Moment das Papier an die Type auf der Walze, die gerade vorbeirauscht. Daher erkennt man ein Verwischen in vertikaler Richtung. 1-2 Seiten pro Sekunde schätz ich, das schafft kein Kettendrucker. Gruß, Michael
Michael Appelt schrieb: > So, jetzt wurde einige Male behauptet, man hätte die Ausdrucvke > auf der > IBM mit Kettendruckern gedruckt - es waren vermutlich Trommeldrucker. > > 1 Walze mit rundum verteilten Ascii-Zeichen. > 132 Hämmerchen, 1 pro Stelle, klopft im richtigen Moment das Papier an > die Type auf der Walze, die gerade vorbeirauscht. Daher erkennt man ein > Verwischen in vertikaler Richtung. > > 1-2 Seiten pro Sekunde schätz ich, das schafft kein Kettendrucker. > > Gruß, > Michael man hat ganz genau erkannt was von der trommel und was von der kette kam, selbst wenn die trommel perfekt eingestellt war. wir haben die trommeel sowieso nur genutzt wenn es sein mußte, weil die kette hatte besseren schallschutz und man konnte auch von draussen sehen wenn papier nachgelegt werden mußte :D
morob65 schrieb: > wir haben die trommeel sowieso nur genutzt wenn es sein mußte, weil die > kette hatte besseren schallschutz und man konnte auch von draussen sehen > wenn papier nachgelegt werden mußte :D und die Kette konnte "Kopien durch gemeinsamen Anschlag" ausdrucken - ich glaube, so heißt das im Juristendeutsch. Gruß, Michael
Ich hatte eine ungarischen Parallel-Drucker VT27000 der Firma "Videoton", der mit der (originalen) Centronics-Schnittstelle an einem K1630-System hing. Bild im unteren Drittel der Seite: http://www.robotrontechnik.de/index.htm?/html/drucker/paralleldrucker.htm Der war unheimlich schnell, laut, konnte 136 Zeichen breit drucken und kostete unheimlich viel Geld. (Weshalb ich ihn auch für diese Doppelnutzung ausrüstete) Dort habe ich dann die Testkarte entfernt und mit einer Eigenbau-SIF1000 Schnittstelle versehen. So konnte ich aussuchen, welches der beiden Systeme den Drucker nutzen konnte. MfG Paul
:
Bearbeitet durch User
Angehängte Dateien:
-
tr440.png
60 KB
A. K. schrieb: > Es gab Anfang der 80er am Mainframe der Informatiker (TR440 von ~1970) > noch beides. Denn von den Terminals gab es relativ wenige (darunter aber > immerhin ein grafikfähiges mit Rollkugel), so dass die Anfänger noch > ganz klassisch per Lochkarte und Papierstapel arbeiten durften. Wer weiss denn heute noch, dass Telefunken mal Grossrechner gebaut hat. Ich durfte an der Uni Würzburg Anfang der 70er an der TR440 http://de.wikipedia.org/wiki/TR_440 rechnen, die hatte 64k Kernspeicher http://de.wikipedia.org/wiki/Kernspeicher, also aufgefädelte Ferritringe! Die Anfänger mussten Lochstreifen stanzen, die mittleren Cracks Lochkarten und nur die Profis durften an ein Terminal SIG50 oder SIG100. Das Kommando-Taschenbuch der TR440 habe ich noch.
@Usuru Dein Bild ist prima. Weißer Adler auf weißem Grund. Ich habe es mir ausgedruckt, damit ich mal eine saubere A4-Seite zur Verfügung habe. ;-) MfG Paul
Angehängte Dateien:
-
tr440b.png
60 KB
Paul Baumann schrieb: > Weißer Adler auf weißem Grund. Der Adler ist nicht weiß, sondern durchsichtig. Falls dein Drucker das Bild richtig ausgedruckt hat, brauchst du den Ausdruck nur auf eine schwarze Unterlage zu legen, und schon wird der Adler schwarz :)
Ah, ich hatte mich schon gewundert, warum bei mir der Adler nicht weiß, sondern kariert ist. Mein Browser zeigt durchsichtige Sachen mit einem karierten Hintergrund an.
Paul Baumann schrieb: > Dein Bild ist prima. Weißer Adler auf weißem Grund. Ich habe es mir > ausgedruckt, damit ich mal eine saubere A4-Seite zur Verfügung habe. Pass auf Paul das dir weisse Toner nicht ausgeht...
usuru schrieb: > Ich durfte an der Uni Würzburg Anfang der 70er an der TR440 > http://de.wikipedia.org/wiki/TR_440 rechnen, die hatte 64k Kernspeicher Allerdings waren das 64K Worte zu 48 Bits (netto), also 384K Bytes.
:
Bearbeitet durch User
Paul Baumann schrieb: > @Usuru > Dein Bild ist prima. Weißer Adler auf weißem Grund. Ich habe es mir > ausgedruckt, damit ich mal eine saubere A4-Seite zur Verfügung habe. > ;-) > > MfG Paul Das Original ist 2-farbig schwarz auf weiss, in meinem Firefox wird es aber hellgrau auf weiss angezeigt, im Chromium tatsächlich ganz weiss. Lade ich es in Irfanview, ist es wieder s/w. Keine Ahnung warum.
A. K. schrieb: > usuru schrieb: >> Ich durfte an der Uni Würzburg Anfang der 70er an der TR440 >> http://de.wikipedia.org/wiki/TR_440 rechnen, die hatte 64k Kernspeicher > > Allerdings waren das 64K Worte zu 48 Bits (netto), also 384K Bytes. Deswegen habe ich ja 64k und nicht 64kB geschrieben.
Michael Appelt schrieb: > So, jetzt wurde einige Male behauptet, man hätte die Ausdrucvke auf der > IBM mit Kettendruckern gedruckt - es waren vermutlich Trommeldrucker. Nö. Es war wirklich ein Kettendrucker an unserer 115-er Bei geöffnetem Gehäuse sah man die Kette ganz deutlich und sie machte beim Umlauf einen Höllenlärm. Drum stand das ganze Druckwerk auch in einem schallgedämmten Schrank :-) > 1-2 Seiten pro Sekunde schätz ich, das schafft kein Kettendrucker. Kommt drauf an, was er drucken soll. Die Dinger waren allerdings wirklich sauschnell. Ist ja nicht so, dass die Kette da im Schneckentempo umlief.
Was ich am meisten aus der Zeit vermisse: Die Handbücher. Die waren ihren Kilopreis noch wert. (This line intentionally left blank)
Die Handbücher (und auch Software) gibts aber zum Teil noch bei den Bitsavers http://bitsavers.informatik.uni-stuttgart.de/pdf/ z.B. http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/punchedCard/
:
Bearbeitet durch User
Paul Baumann schrieb: > Ich hatte eine ungarischen Parallel-Drucker VT27000 der Firma "Videoton" Hatten wir auch. Im Vergleich zu vielen anderen Paralleldruckern war der unwahrscheinlich sauber im Druckbild, nicht diese sonst so typischen Ausreißer nach unten und oben. Aber schweinelaut war er natürlich und nur GROSSBUCHSTABEN.
Christoph Kessler (db1uq) schrieb: > Die Handbücher (und auch Software) gibts aber zum Teil noch bei den > Bitsavers Ich hatte eigentlich mehr gemeint, dass ich mir heutige Handbücher ein wenig mehr in diese Richtung wünschen würde :-) Ausser in 20 verschiedenen Sprachen "Wir beglückwünschen sie zum Kauf" steht doch da heute nichts wesentliches mehr drinnen. Im Prinzip würde es reichen, wenn sie einen Zettel beiliegen, auf dem zu lesen ist "Der übliche Blabla. Danke". Natürlich in 20 Sprachen.
:
Bearbeitet durch User
Heute steht da praktisch nichts mehr, aber dafür gibts viele Fotos Sogar Wörterbücher gibts jetzt nur mit Bildern: ISBN 9783468298387
"Der übliche Blabla. Danke" "The usual blah Thank you." "Les bla habituels Merci." 「いつも何とかありがとうございました。」 "Обычные бла Спасибо." "Звичайні бла Спасибо." "A szokásos bla Köszönöm." "Her zamanki falan teşekkür ederiz." "Уобичајени бла Хвала." "Il-blah soltu Grazzi." "Обичайните бла Благодаря." "ჩვეულებრივი blah დიდი მადლობა." "Të blah zakonshme Ju faleminderit." "De gebruikelijke bla Dank je wel." "I soliti bla Grazie." "Los bla habituales Gracias." "Os blah habituais Obrigado." "Zwykłe bla Dziękuję." "De sædvanlige bla Tak." "De vanlige blah Takk." Bitte schoen, das Universal Handbuch fuer jeden Mist.
usuru schrieb: > Das Original ist 2-farbig schwarz auf weiss, Nein, es ist transparent auf weiß (bzw.umgekehrt). > in meinem Firefox wird es aber hellgrau auf weiss angezeigt, In meinem auch. Das liegt daran, dass er das Bild auf einem hellgrauen Hintergrund darstellt. > im Chromium tatsächlich ganz weiss. Offensichtlich verwendet Chromium einen weißen Hintergrund. Bei den meisten Browsern kann man mittels Addons die Hintergrundfarbe ändern. Hab's aber nicht ausprobiert. > Lade ich es in Irfanview, ist es wieder s/w. Keine Ahnung warum. GQView verwendet als Hintergrund ein Schachbrettmuster mit hell- und dunkelgrauen Feldern. Entsprechend sehen die transparenten Flächen in dem Scan gemustert aus. Für das Bild in diesem Beitrag Yalu X. schrieb: > Der Adler ist nicht weiß, sondern durchsichtig. habe ich dem Bild mit Gimp einfach einen zweiten, komplett schwarzen Layer hinterlegt und das Ganze wieder als PNG exportiert. Dadurch werden alle ursprünglich transparenten Flächen unabhängig vom verwendeten Viewer schwarz dargestellt.
Angehängte Dateien:
-
Unbenannt-60-k.jpg
230 KB
Ein Computer muß nicht Speicherprogrammiert sein. ES gibt auch Schalttafel programmierte. Hier ein Bild Nettolohnabrechnung auf IBM609 Steuer- uns Sozialabzüge. (1962) Um vorzubeugen diese Tafel stammt aus dem prouktiven Betrieb eines Betriebes mit 2000 Beschäftigten. Es wurde auch die Produktionsplanung unterstützt, mit einer anderen Tafel. Nebenbei: Die IBM305 war sowohl Speicherprogrammiert und gleichzeitig Schalttafel- programmiert.
klausb schrieb: > Hier ein Bild Nettolohnabrechnung auf IBM609 Steuer- uns Sozialabzüge. > (1962) Muss die bessere Programmierung gewesen sein, damals gab es mehr raus und weniger Abzuege...
Helmut Lenzen schrieb: > Bitte schoen, das Universal Handbuch fuer jeden Mist. :-) Und jetzt fehlt nur noch ein passendes Piktogramm, denn Lesen ist doch aber sowas von gestern, ey!
Konrad S. schrieb: > Und jetzt fehlt nur noch ein passendes Piktogramm, denn Lesen ist doch > aber sowas von gestern, ey! Das darfst du jetzt machen...
Angehängte Dateien:
-
bla_tnx.png
5,6 KB
Helmut Lenzen schrieb: > Das darfst du jetzt machen... Oje! Ich probier's mal auf Arduino-Art: Google fragen und dann einfach irgendwas aus dem Internet zusammenkopieren. ;-)
Angehängte Dateien:
-
Scan10006.jpg
220 KB
Georg schrieb: > Udo Schmitt schrieb: >> ie schönen Kettendrucker. Unsere Firma hat ihren letzten von ca. 12 >> Jahren verschenkt. > > Konnte der überhaupt Umlaute drucken? Von Grafik mal ganz abgesehen. Und > das Endlospapier verursachte auch seine Kosten, ganz extrem wenn man > Durchschläge brauchte. Unserer Kettendrucker konnte, jedenfalls dann, wenn die Spezialkette montiert war. Siehe den Scan einer 1979 gedruckten Seite. Ein interessantes Feature der damaligen Kettendrucker war, daß man die Druckgeschwindigkeit mit einer geeigneten Kette optimieren konnte, indem man die Häufigkeitsverteilung der zu druckenden Zeichen berücksichtigte. Üblicherweise verwendete man einen beschränkten Zeichensatz und eine Kette, auf der die häufig zu druckenden Zeichen mehrfach vorkamen. Details siehe z.B. http://en.wikipedia.org/wiki/Line_printer#Chain_.28train.29_printer Anders ausgedrückt, der der prinzipiell mögliche Umfang an Zeichen war viel größer als das, was man üblicherweise zu sehen bekam (nämlich Ziffern und Großbuchstaben) und nur durch die Länge der Kette (ca. 2 x Zeilenlänge) beschränkt. Und das hatten wir ausgenutzt. Wir hatten uns eine Kette anfertigen lassen, die jedes Zeichen nur einmal enthielt, die dafür aber einen sehr umfangreichen Zeichenvorrat drucken konnte, wenn auch nur relativ gesehen langsamer. Neben den Umlauten ließen sich so diverse in der mathematischen Notation gebräuchliche Zeichen drucken. Allerdings waren solche Spezialketten sündhaft teuer, so daß es davon nur eine gab und die auch nur dann montiert wurde, wenn sich genügend Outputs der entsprechenden Outputklasse angesammelt hatten.
Karl Heinz schrieb: > Was ich am meisten aus der Zeit vermisse: > Die Handbücher. > Die waren ihren Kilopreis noch wert. Und im Anhang waren sogar noch die Schaltpläne drinn! (Macht ja heute keinen großen Sinn mehr bei der Integrationsdichte...)
Hallo, Wolfgang S. Die 7094 hört sich nach Garching an. Da war doch schon eine 1401 als Spoolmaschine. Und eine 1402 als Stanzer und Leser. War wohl in den 60gern eins der schweren Eisen :-)
Bronco schrieb: > Und im Anhang waren sogar noch die Schaltpläne drinn! Bei meiner HP 2100 sind sogar die ROM-Listings vom "Microcode" in der Dokumentation enthalten. Ja, gut, die paar Hundert Bytes machen bei den Manuals jetzt auch nicht mehr viel aus
Konrad S. schrieb: > Bei meiner HP 2100 sind sogar die ROM-Listings vom "Microcode" in der > Dokumentation enthalten. Damit ist HP aber nicht alleine gewesen. In den "Field Maintenance Print Sets" von DEC für die PDP11s sind auch sämliche Informationen vorhanden: Microcode-Listings, Verdrahtungspläne für die Backplanes (die sind gewickelt), Schaltungen, Layouts usw.. Im Prinzip alles, um die Funktion zu verstehen und die Boards nachbauen zu können. Einfach traumhaft und auch sehr beruhigend. Apropos HP2100: Hast du eventuell Unterlagen über das Board "12665-60001 serial interface". Darüber ist auf der ganzen durchsuchbaren Welt nichts zu finden.
:
Bearbeitet durch User
klausb schrieb: > Hallo, > Wolfgang S. > > Die 7094 hört sich nach Garching an. Da war doch schon eine 1401 als > Spoolmaschine. Und eine 1402 als Stanzer und Leser. Nein, die stand im RHRZ in Bonn, und war wohl doch nur eine 7090. Leider habe ich überhaupt keine Unterlagen mehr aus der Zeit. Damals habe ich mich mehr für die Feinheiten von Fortran IV interessiert als für die Hardware und für die Schnelldruckeroutputs gab es seinerzeit erstaunlich viel Interesse. Da die Ausdrucke meist ziemlich blaß waren, konnte man die großen Bögen sehr gut zweitverwerten. > > War wohl in den 60gern eins der schweren Eisen :-) Sie nahm jedenfalls einen großen Teil des Erdgeschosses in diesem Klotz http://www.hrz.uni-bonn.de/ueber-uns/bilder-vom-hochschulrechenzentrum ein.
Sinus Tangentus schrieb: > Apropos HP2100: Hast du eventuell Unterlagen über das Board "12665-60001 > serial interface". Darüber ist auf der ganzen durchsuchbaren Welt nichts > zu finden. Ich habe mindestens ein Board mit serieller Schnittstelle für die HP 2100 und habe die Schnittstelle auch schon mal mit einem eigenen Programm angesteuert. Also müsste ich auch Dokumentation dazu haben. Ich kann leider nicht sagen, ob es genau dieses Board ist, denn die Anlage ist an einem etwas abgelegenen Ort eingelagert. Das kann durchaus ein Jahr dauern, bis ich da mal wieder vorbeikomme. Dann guck ich mal, was ich dazu habe. Hoffentlich finde ich dann diesen Thread wieder.
Angehängte Dateien:
-
lk-deck-k.jpg
250 KB
zurück zum Anfang grüne Lochkarte: ein JOB Control Fragment der Rest: Fragmente eines PL/1 Programms
Mit den Kettendruckern konnte man auch einigen Schabernack anstellen, z.B. Zeilen ohne LF ausgeben, die jeweils nur ein Zeichen enthielten und die "zufällig" auf der Kette so angeordnet sind, dass ein kompletter Zeichensatz durchlaufen muss, bis das nächst Zeichen kommt. Das LF musste dann aber irgendwann kommen, bevor das Papier abgedruckt war... Dann irgendwann zur Abwechslung eine Zeile, die den ganzen Zeichensatz in Kettenreihenfolge enthält. Das war eben noch richtige Hardware...
Uhu Uhuhu schrieb: > Mit den Kettendruckern konnte man auch einigen Schabernack anstellen..... Du bist ein Elektronik-Sadist! ;-) So ein Drucker ist auch nur ein Mensch. MfG Paul
Paul Baumann schrieb: > Du bist ein Elektronik-Sadist! Der Elektronik hat das nichts ausgemacht und die Mechanik hats auch nicht übel genommen - im Gegensatz zum Operateur ;-)
Am Wochenende kam der Film "Password Swordfish", da hat Hugh Jackman als Superhacker die "einzige PDP10, die noch am Internet hängt" aktiviert, um seine Missetaten zu begehen.
Wer es ihm nachtun will: http://simh.trailing-edge.com/ Doku: http://simh.trailing-edge.com/pdf/pdp10_doc.pdf Einschliesslich Ethernet. Zumindest dem Prinzip nach, denn "XU simulates the DEUNA/DELUA Ethernet controller. The current implementation is experimental, and its operation is not supported under any known operating system."
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.