Lochkarten lesen?

[Peter Heitzer]

Ich hatte gerade eine Anfrage eines Biologen, der seine ornithologischen
Beobachtung auf mehreren Tausend Lochkarten gespeicher hat und nun
nach einer Lösung sucht, die Daten in eine Tabellenkalkulation einzulesen.
Da ein Kartenleser wohl kaum aufzutreiben ist und dann auch noch an
einen modernen Rechner angeschlossen werden müsste frage ich, ob es einfache
Möglichkeit gibt, die Lochkarten mit einem Flachbettscanner auszuwerten.


--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de

[Dennis Grevenstein]

Peter Heitzer <peter....@rz.uni-regensburg.de> wrote:
> Ich hatte gerade eine Anfrage eines Biologen, der seine ornithologischen
> Beobachtung auf mehreren Tausend Lochkarten gespeicher hat und nun
> nach einer Lösung sucht, die Daten in eine Tabellenkalkulation einzulesen.
> Da ein Kartenleser wohl kaum aufzutreiben ist und dann auch noch an
> einen modernen Rechner angeschlossen werden müsste frage ich, ob es einfache
> Möglichkeit gibt, die Lochkarten mit einem Flachbettscanner auszuwerten.

Lustig, ja...

Wenn Du selbst kein intensives Interesse an dem Problem hast, dann
würde ich das Problem erstmal an den Forscher zurückgeben und ihn
bitten genaue Angaben zu machen, mit welchem Rechner, welcher Software,
in welchem Format die Daten gespeichert wurden.

Abgesehen davon brauchst Du für "mehrere tausend" Karten eine automatisierte
Lösung, sonst wirst Du ja verrückt bei der Aufgabe.
Die DFG verlangt übrigens als "langfristige Sicherung" eine Archivierung
von Daten für "mindestens 10 Jahre". Vermutlich sind die Lochkarten
deutlich älter. Da wäre schon die Frage, wieviel Zeit und Geld das
kosten darf. Das Problem ist tatsächlich real und betrifft immer
wieder nicht nur alte Daten, sondern auch so Sachen wie Experimental-
software oder Auswertungssoftware. Lochkarten sind natürlich ein
extremes Bespiel ganz nah am Aprilscherz.

gruss,
Dennis

--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."

[Michael van Elst]

"Peter Heitzer" <peter....@rz.uni-regensburg.de> writes:

>Ich hatte gerade eine Anfrage eines Biologen, der seine ornithologischen
>Beobachtung auf mehreren Tausend Lochkarten gespeicher hat und nun

>nach einer Lösung sucht, die Daten in eine Tabellenkalkulation einzulesen.

>Da ein Kartenleser wohl kaum aufzutreiben ist und dann auch noch an

>einen modernen Rechner angeschlossen werden müsste frage ich, ob es einfache
>Möglichkeit gibt, die Lochkarten mit einem Flachbettscanner auszuwerten.

Hier wird es mit einer Kamera und einem gebastelten Feeder gemacht:

https://hackaday.com/2012/07/30/reading-punch-cards-with-an-arduino-and-digital-camera/

Der relevante Teil dürfte die Software zur Auswertung sein:

http://codeincluded.blogspot.com/2012/07/punchcard-reader-software.html

[Hermann Riemann]

Am 19.04.21 um 09:41 schrieb Peter Heitzer:

> Ich hatte gerade eine Anfrage eines Biologen, der seine ornithologischen

> Beobachtung auf mehreren Tausend Lochkarten gespeichert hat und nun

> nach einer Lösung sucht, die Daten in eine Tabellenkalkulation einzulesen.
> Da ein Kartenleser wohl kaum aufzutreiben ist und dann auch noch an
> einen modernen Rechner angeschlossen werden müsste frage ich, ob es einfache
> Möglichkeit gibt, die Lochkarten mit einem Flachbettscanner auszuwerten.

Flachbrettscanner dauert zu lange.
Lochkarten auf einen möglichst dunklen Hintergrund legen und dann
fotografieren.
Vielleicht noch Markierungsstangen

Aus den hell dunkel x y Werten kann man die Bits der
Lochkarten Löcher berechnen.

Alternative wäre ein ausrangierter Multifunktionsdrucker
mit Papiereinzug.
Ein Experiment wäre es wert.

Sollten Kartenleser eine Schnittsstelle haben
ist es wahrscheinlich RS232 wofür es heute noch Bauteile gibt.
Vielleicht vorher noch einige Messungen machen,
denn hardware Kurzschlüsse lassen sich nicht immer reparieren.
Mit Arduino und Unterschiedliche Widerstände
kann man experimentieren.

Hermann
vermutend, dass die Daten dann mit viel Aufwand
zwar eingelesen werden aber wegen Format Probleme
dann nicht verwendet werden können.

--
http://www.hermann-riemann.de

[Thomas Koenig]

Peter Heitzer <peter....@rz.uni-regensburg.de> schrieb:

> Ich hatte gerade eine Anfrage eines Biologen, der seine ornithologischen
> Beobachtung auf mehreren Tausend Lochkarten gespeicher hat und nun
> nach einer Lösung sucht, die Daten in eine Tabellenkalkulation einzulesen.
> Da ein Kartenleser wohl kaum aufzutreiben ist und dann auch noch an
> einen modernen Rechner angeschlossen werden müsste frage ich, ob es einfache
> Möglichkeit gibt, die Lochkarten mit einem Flachbettscanner auszuwerten.

Könnte https://www.masswerk.at/cardreader/ helfen?

[Hanno Foest]

Am 19.04.21 um 10:13 schrieb Michael van Elst:

> Hier wird es mit einer Kamera und einem gebastelten Feeder gemacht:
>
> https://hackaday.com/2012/07/30/reading-punch-cards-with-an-arduino-and-digital-camera/
>
> Der relevante Teil dürfte die Software zur Auswertung sein:
>
> http://codeincluded.blogspot.com/2012/07/punchcard-reader-software.html

Kamera wäre auch meine Idee gewesen, auch ohne dieses Projekt zu
kennen... aber bevor man das überhaupt anfängt, sollte man eine Idee
haben, was das Datenformat ist und wie man das konvertieren möchte,
ansonsten hat man hinterher einen Dump Rohdaten, mit denen man nichts
anfangen kann.

Hanno

--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

[olaf]

Dennis Grevenstein <dennis.gr...@gmail.com> wrote:

>bitten genaue Angaben zu machen, mit welchem Rechner, welcher Software,
>in welchem Format die Daten gespeichert wurden.

Fuer meine Physik klausur hat uns der Prof aufgefordert alle
Ergebnisse in wissenschaftliche Schreibweise umzuwandeln, der Exponenten
zu Zahl vor dem Komma zu addieren, in irgendwas binaeres umzuwandeln und
dann mit dem Bleistift die kleinen Papierfitzel aus den Lochkarten
rauszustanzen. Das muss so 92/93 gewesen sein und hat uns damals
schon schwer verwirrt. :-)
Ich denke mal aehnlich wird das wohl hier auch gelaufen sein. Oder
meinst du der hat in der freien Natur einen Lochkartenstanzer dabei?

Olaf

[Thomas Koenig]

Thomas Koenig <tko...@netcologne.de> schrieb:

Oder das hier? https://github.com/digitaltrails/punchedcardreader

[Peter Heitzer]

Das stelle ich mir bei einigen Tausend Karten nicht lustig vor. Die Karten
müssen ja zuvor auch erst gescannt werden. Aber es könnte für eine
erste Evaluation nützlich sein, um die Kodierung zu testen.
Es handelt sich übrigens um IBM 80 Zeichen Lochkarten wie auf der
angegebenen URL angezeigt.

[Peter Heitzer]

Vermutlich hat er seine handschriftlichen Notizen damals in ein Terminal
eingegeben und die Karten gestanzt, um sie dann auf dem Grossrechner, einer
vmtl. TR440 auszuwerten. Evtl. gab es die Daten dann auf Magnetband, aber
das wäre eine noch grössere Aufgabe, dieses einzulesen.

[Christian Corti]

Peter Heitzer <peter....@rz.uni-regensburg.de> wrote:
> Ich hatte gerade eine Anfrage eines Biologen, der seine ornithologischen
> Beobachtung auf mehreren Tausend Lochkarten gespeicher hat und nun
> nach einer Lösung sucht, die Daten in eine Tabellenkalkulation einzulesen.
> Da ein Kartenleser wohl kaum aufzutreiben ist und dann auch noch an
> einen modernen Rechner angeschlossen werden müsste frage ich, ob es einfache
> Möglichkeit gibt, die Lochkarten mit einem Flachbettscanner auszuwerten.

Der Herr könnte sich einfach mal an uns wenden. Warum ein Kartenleser an
einen modernen Rechner angeschlossen werden muß, verstehe ich aber
nicht. Wir übertragen die Daten von der 1130 per V.24 rüber.

Christian

[Christian Corti]

Hanno Foest <hurga...@tigress.com> wrote:
> kennen... aber bevor man das überhaupt anfängt, sollte man eine Idee
> haben, was das Datenformat ist und wie man das konvertieren möchte,
> ansonsten hat man hinterher einen Dump Rohdaten, mit denen man nichts
> anfangen kann.

Was interessiert den Ausleser, was die einzelnen Felder bedeuten? Das
wird der Datenbesitzer schon wissen, weil er sie in ein Spreadsheet
übernehmen will.
Hast du denn schon mal mit Lochkarten gearbeitet?

Christian

[Christian Corti]

Dennis Grevenstein <dennis.gr...@gmail.com> wrote:
> würde ich das Problem erstmal an den Forscher zurückgeben und ihn
> bitten genaue Angaben zu machen, mit welchem Rechner, welcher Software,
> in welchem Format die Daten gespeichert wurden.

Warum? Was hat das mit dem Auslesen der Lochkarten, die zu 100% in
EBCDIC sein werden, zu tun? Das Format nennt sich "Lochkarte", die
Felder sind Spalten getrennt. Lochkarten funktionieren ohne Rechner,
d.h. man kann dezentral Daten erfassen.

Christian

[Hanno Foest]

Am 19.04.21 um 10:58 schrieb Christian Corti:

>> kennen... aber bevor man das überhaupt anfängt, sollte man eine Idee
>> haben, was das Datenformat ist und wie man das konvertieren möchte,
>> ansonsten hat man hinterher einen Dump Rohdaten, mit denen man nichts
>> anfangen kann.
>
> Was interessiert den Ausleser, was die einzelnen Felder bedeuten?

Nicht den Ausleser, der produziert halt den erwähnten Dump Rohdaten.
Aber vermutlich wird es schon die Person mit den Lochkarten interessieren.

> Das
> wird der Datenbesitzer schon wissen, weil er sie in ein Spreadsheet
> übernehmen will.

Hast du schon mal mit Usern gearbeitet? Wenn man sowas nicht vorher
abklärt, ist dann die nächste Frage "und wo bekomm ich jetzt <antikes
Programm für Großrechner, mit dem die Daten damals bearbeitet wurden>
her, um sie zu konvertieren?"

Nicht immer, aber immer, wenn man nicht vorher fragt. Murphy halt.

[Kay Martinen]

Am 19.04.21 um 10:56 schrieb Christian Corti:

Gab es nicht auch mal Mechanische oder Elektromechanische Geräte im
Format einer Schreibmaschine mit denen man OOTB Lochkarten BE-Stanzen
konnte? Ich meine sowas in einem Buch gelesen zu haben.

Hallo Klemens K. liest du mit?


Kay

--
Posted via leafnode

[Christian Corti]

Peter Heitzer <peter....@rz.uni-regensburg.de> wrote:
> Das stelle ich mir bei einigen Tausend Karten nicht lustig vor. Die Karten
> müssen ja zuvor auch erst gescannt werden. Aber es könnte für eine
> erste Evaluation nützlich sein, um die Kodierung zu testen.

Man kann sich auch von hinten durch die Brust ins Auge schießen...
Wie wäre es, einfach einen Blick auf eine Karte zu werfen? Lochkarten
kann man mit dem bloßen Auge lesen und entziffern. Und evtl. ist der
Klartext unter der oberen Kante aufgedruckt (das konnten die guten
Kartenstanzer).
Ich vermute, es handelt sich um Text, ggf. Abkürzungen, und Zahlen. Das
Auswerteprogramm könnte ein FORTRAN-Programm gewesen sein. Und dann ist
es wirklich nur eine Frage des Einlesens und Übertragen. Aber ihr könnt
die Karten auch einscannen und über das Lochmuster eine KI laufen lassen
;-))))

Christian

[Marcel Mueller]

Am 19.04.21 um 09:41 schrieb Peter Heitzer:

> Ich hatte gerade eine Anfrage eines Biologen, der seine ornithologischen
> Beobachtung auf mehreren Tausend Lochkarten gespeicher hat und nun
> nach einer Lösung sucht, die Daten in eine Tabellenkalkulation einzulesen.
> Da ein Kartenleser wohl kaum aufzutreiben ist und dann auch noch an
> einen modernen Rechner angeschlossen werden müsste frage ich, ob es einfache

Ich würde mal in einem (Computer-)Museum fragen. Die haben zuweilen noch
funktionierende Geräte. Mit etwas Glück haben die eine serielle
Schnittstelle, wo die Daten raus kommen. Die bekommt man für wenig Geld
auch heute noch an einen Laptop.

> Möglichkeit gibt, die Lochkarten mit einem Flachbettscanner auszuwerten.

Wenn er *viel* Zeit hat, geht das.
Aber ob es am Ende bis alles läuft, wirklich schneller ist als
Abschreiben, wage ich zu bezweifeln. Weniger fehleranfällig vielleicht.
Ich meine, das fängt mit der Bildauswertungssoftware an, die will erst
mal auf das Format der Karten getrimmt werden. Da muss man schon einiges
Scripten und testen, bevor man das halbwegs am laufen hat. Wenn man dann
noch keine allgemeine Programmiererfahrung hat, dauert es noch 5-mal länger.


Marcel

[Kay Martinen]

Am 19.04.21 um 12:51 schrieb Christian Corti:

> Ich vermute, es handelt sich um Text, ggf. Abkürzungen, und Zahlen. Das
> Auswerteprogramm könnte ein FORTRAN-Programm gewesen sein. Und dann ist
> es wirklich nur eine Frage des Einlesens und Übertragen. Aber ihr könnt
> die Karten auch einscannen und über das Lochmuster eine KI laufen lassen
> ;-))))

KI? Eine "Karten-Instanz"? :-) Wie könnte diese dabei helfreich sein?

Mal Poettering fragen wann systemd-punchreaderd fertig ist? Und, wann er
funktioniert. :-)

SCNR

[Arno Welzel]

Hanno Foest:

> Am 19.04.21 um 10:58 schrieb Christian Corti:
>
>>> kennen... aber bevor man das überhaupt anfängt, sollte man eine Idee
>>> haben, was das Datenformat ist und wie man das konvertieren möchte,
>>> ansonsten hat man hinterher einen Dump Rohdaten, mit denen man nichts
>>> anfangen kann.
>>
>> Was interessiert den Ausleser, was die einzelnen Felder bedeuten?
>
> Nicht den Ausleser, der produziert halt den erwähnten Dump Rohdaten.
> Aber vermutlich wird es schon die Person mit den Lochkarten interessieren.

Genau diese Person muss halt wissen, was auf den Lochkarten gespeichert
wurde, damit man die Rohdaten danach passend aufbereiten kann.


--
Arno Welzel
https://arnowelzel.de

[Christian Corti]

Marcel Mueller <news.5...@spamgourmet.org> wrote:
> Ich würde mal in einem (Computer-)Museum fragen. Die haben zuweilen noch
> funktionierende Geräte. Mit etwas Glück haben die eine serielle
> Schnittstelle, wo die Daten raus kommen. Die bekommt man für wenig Geld
> auch heute noch an einen Laptop.

Ok, ich packe meinen Zaunpfahl wieder ein, sieht ja eh keiner ;-)

Christian

[K. Krause]

On 19.04.21 10:08, Dennis Grevenstein wrote:
...

> Die DFG verlangt übrigens als "langfristige Sicherung" eine Archivierung
> von Daten für "mindestens 10 Jahre". Vermutlich sind die Lochkarten
> deutlich älter. Da wäre schon die Frage, wieviel Zeit und Geld das
> kosten darf. Das Problem ist tatsächlich real und betrifft immer
> wieder nicht nur alte Daten, sondern auch so Sachen wie Experimental-
> software oder Auswertungssoftware. Lochkarten sind natürlich ein
> extremes Bespiel ganz nah am Aprilscherz.
>

Ich weiss gar nicht was Ihr habt, Lochkarten sind doch ein sehr
langlebiges Archivierungsmedium. Ob eine DVD nach 10 Jahren noch lesbar
ist, ist ja sehr fraglich. Aber ich denke, wenn da nicht grade der
Bücherwurm reinkommt, oder Micky- und Minnie Maus ein Nest reinbauen,
kann man auch noch 80-spaltige Lochkarten von 1928 einlesen.

Ich habe übrigens schon in den 1990er Jahren ein Programm geschreiben,
das drei auf einen HP-Scanjet 1 gelegte Lochkarten gescannt hat, und
mit einem, wie ich mich kenne, in Turbo-Pascal geschriebenen Programm
in ASCII-Text umgewandelt hat. Das lief unter MSDOS recht flott, weil
man zu der Zeit auch noch graphische Programme mit der Tastatur bedienen
konnte.
Der PC, eine HP Vectra (pcscan) und der Scanner stehen, wenn ich mich
recht erinnere ganz oben hinten bei uns im Depot.

Grüßle
Klemens

[Christian Corti]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
> Wie ist das eigentlich mit den zuletzt genutzten Lochkarten und den
> Formaten? Ist das äußere Papierformat standardisiert? Und die Lage der
> Lochreihen?

Die Lochkarten sind sehr präzise definiert und standardisiert. Es gab
auch Lochkartenlehren, um zu testen, ob ein Stanzer, z.B. nach der
Reparatur, die Löcher an der richtigen Stelle macht.
*Alle* 80-spaltigen Lochkarten im IBM-Format sind gleich und können von
allen entsprechenden Geräten verarbeitet werden.
Ich habe mal kurz gegoogelt, die Maße sind im Standard EIA RS-292 definiert,
und die Löcher zuletzt in ANSI X3.21-1967. Die Maße entstammen den zur
Jahrhundertwende verwendeten US-Banknoten, weil Hollerith diese Magazine
zur Lagerung benutzen wollte.

Christian

[Norbert Narten]

Am 19.04.21 um 10:30 schrieb Hermann Riemann:

>
> Hermann
>    vermutend, dass die Daten dann mit viel Aufwand
>    zwar eingelesen werden aber wegen Format Probleme
>    dann nicht verwendet werden können.
>

Warum so pessimistisch? Wenn tatsächlich auf den Lochkarten EBCDIC gespeichert
ist, lässt sich so was für eine Analyse nach ASCII wandeln. Dann kann man ggf.
eine Import- Regel für sein bevorzugtes Programm erstellen. Wenn der User einen
wissenschaftlichen Hintergrund hat, dann sollte er das auch hinbekommen,
vorausgesetzt, die Lochkarten sind noch in der richtigen Reihenfolge... ;-) ...

Anyway... Ich hatte letztens die "Unmögliche" Aufgabe, einen Server, auf dem ein
OAS10g R2 installiert ist, eine neue IP-Adresse und einen neuen Host-Namen samt
DNS-Domain um zu verpassen. Die Aussage war: "installiere den OAS10g R2 neu,
umkonfigurieren ist nicht möglich und auch nicht vorgesehen!". Mangels Installations-
Satz ging das nicht - den hatte jemand zu voreilig entsorgt. Ungefähr 70 OAS10g-
Konfigurations-Dateien + Betriebssystem und drei Tage später lief die Kiste wieder
(mit neuer IP-Adresse und Namen) mit abschließendem User Acceptance Test. Soviel zu
dem Thema "Das ist Unmöglich"... ;-) ...


Norbert

[Thomas Koenig]

Norbert Narten <nor...@narten.de> schrieb:

> Am 19.04.21 um 10:30 schrieb Hermann Riemann:
>
>>
>> Hermann
>>    vermutend, dass die Daten dann mit viel Aufwand
>>    zwar eingelesen werden aber wegen Format Probleme
>>    dann nicht verwendet werden können.
>>
>
> Warum so pessimistisch? Wenn tatsächlich auf den Lochkarten EBCDIC gespeichert
> ist, lässt sich so was für eine Analyse nach ASCII wandeln.

Das kann sogar dd (1).

>Dann kann man ggf.
> eine Import- Regel für sein bevorzugtes Programm erstellen. Wenn der User einen
> wissenschaftlichen Hintergrund hat, dann sollte er das auch hinbekommen,
> vorausgesetzt, die Lochkarten sind noch in der richtigen Reihenfolge... ;-) ...

Mit ein bisschen Glück gibt es in den Spalten 73-80 eine
Nummerierung, nach der man sortieren kann.

[Andreas Kohlbach]

On Mon, 19 Apr 2021 10:58:38 +0200, Christian Corti wrote:
>
> Hanno Foest <hurga...@tigress.com> wrote:
>> kennen... aber bevor man das überhaupt anfängt, sollte man eine Idee
>> haben, was das Datenformat ist und wie man das konvertieren möchte,
>> ansonsten hat man hinterher einen Dump Rohdaten, mit denen man nichts
>> anfangen kann.
>
> Was interessiert den Ausleser, was die einzelnen Felder bedeuten? Das
> wird der Datenbesitzer schon wissen, weil er sie in ein Spreadsheet
> übernehmen will.

Peter wollte die Daten in einen Art Tabellenkalkulation haben. Wenn das
Format auch EBCDIC sein mag, nutzt das wenig, wenn man diese nackten Daten
nicht. Die Daten könnten einen Tabellenkalkulation entstammen, sind
vielleicht aber MIDI Daten oder ASCII-Porn.

Daher sollte der Produzent der Daten Informationen zum Format beifügen.

> Hast du denn schon mal mit Lochkarten gearbeitet?

Ja. Früher, als wir uns noch keinen Leser leisten konnten, haben wir die
Löcher mit den Eckzähnen in die Karten gestanzt. ;-)
--
Andreas

[Markus Elsken]

Moin!

Am 19.04.21 um 10:08 schrieb Dennis Grevenstein:

> Wenn Du selbst kein intensives Interesse an dem Problem hast, dann
> würde ich das Problem erstmal an den Forscher zurückgeben und ihn
> bitten genaue Angaben zu machen, mit welchem Rechner, welcher Software,
> in welchem Format die Daten gespeichert wurden.

Und danach mal bei diversen Computermuseen anfragen. Die LK können
sicher viele lesen, aber die Daten konvertieren - nunja.

mfg Markus

[Diedrich Ehlerding]

K. Krause meinte:

> Aber ich denke, wenn da nicht grade der
> Bücherwurm reinkommt, oder Micky- und Minnie Maus ein Nest reinbauen,
> kann man auch noch 80-spaltige Lochkarten von 1928 einlesen.

Ja ... wenn man noch ein Lesegerät dafür hat und einen Rechner, an dem
man das anschließen kann, sowie einen Admin, der diesen Rechner bedienen
kann. Vermutlich sind der letzte Rechner und dessen Admin, die das
noch konnten, ca. 1990 in Schutzgasatmosphäre gemeinsam eingelagert
worden ...
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Andreas Kohlbach]

On Mon, 19 Apr 2021 12:51:15 +0200, Christian Corti wrote:
>
> Peter Heitzer <peter....@rz.uni-regensburg.de> wrote:
>> Das stelle ich mir bei einigen Tausend Karten nicht lustig vor. Die Karten
>> müssen ja zuvor auch erst gescannt werden. Aber es könnte für eine
>> erste Evaluation nützlich sein, um die Kodierung zu testen.
>
> Man kann sich auch von hinten durch die Brust ins Auge schießen...
> Wie wäre es, einfach einen Blick auf eine Karte zu werfen? Lochkarten
> kann man mit dem bloßen Auge lesen und entziffern.

Du vielleicht. Aber Du kannst auch rot13 direkt lesen. ;-)

Aber dennoch gute Idee. Peter sollte vielleicht mal eine (die erste, wenn
er die identifizieren kann) Karte fotografieren, das Foto irgendwo
hochladen und den Link hier posten.
--
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0

[Kay Martinen]

Am 19.04.21 um 20:20 schrieb Andreas Kohlbach:

> On Mon, 19 Apr 2021 10:58:38 +0200, Christian Corti wrote:
>>
>> Hanno Foest <hurga...@tigress.com> wrote:
>>> kennen... aber bevor man das überhaupt anfängt, sollte man eine Idee
>>> haben, was das Datenformat ist und wie man das konvertieren möchte,
>>> ansonsten hat man hinterher einen Dump Rohdaten, mit denen man nichts
>>> anfangen kann.
>>
>> Was interessiert den Ausleser, was die einzelnen Felder bedeuten? Das
>> wird der Datenbesitzer schon wissen, weil er sie in ein Spreadsheet
>> übernehmen will.
>
> Peter wollte die Daten in einen Art Tabellenkalkulation haben. Wenn das
> Format auch EBCDIC sein mag, nutzt das wenig, wenn man diese nackten Daten
> nicht. Die Daten könnten einen Tabellenkalkulation entstammen, sind
> vielleicht aber MIDI Daten oder ASCII-Porn.

Das könnte sogar sein. Im OP stand was von Ornitologischen Daten. Das
wären dann wohl Midi-Vogelgezwitscher und Nackte Vögel ähh Küken oder?

> Daher sollte der Produzent der Daten Informationen zum Format beifügen.
>
>> Hast du denn schon mal mit Lochkarten gearbeitet?
>
> Ja. Früher, als wir uns noch keinen Leser leisten konnten, haben wir die
> Löcher mit den Eckzähnen in die Karten gestanzt. ;-)

Ach? So was hab ich nur mit meinen C-64 Floppys gemacht - bevor ich
einen Stanzer hatte - für die Rückseite.

[Andreas Kohlbach]

On Mon, 19 Apr 2021 22:14:48 +0200, Kay Martinen wrote:
>
> Am 19.04.21 um 20:20 schrieb Andreas Kohlbach:
>>

>> Peter wollte die Daten in einen Art Tabellenkalkulation haben. Wenn das
>> Format auch EBCDIC sein mag, nutzt das wenig, wenn man diese nackten Daten
>> nicht. Die Daten könnten einen Tabellenkalkulation entstammen, sind
>> vielleicht aber MIDI Daten oder ASCII-Porn.
>
> Das könnte sogar sein. Im OP stand was von Ornitologischen Daten. Das
> wären dann wohl Midi-Vogelgezwitscher und Nackte Vögel ähh Küken oder?

Heiße Küken.

>> Daher sollte der Produzent der Daten Informationen zum Format beifügen.
>>
>>> Hast du denn schon mal mit Lochkarten gearbeitet?
>>
>> Ja. Früher, als wir uns noch keinen Leser leisten konnten, haben wir die
>> Löcher mit den Eckzähnen in die Karten gestanzt. ;-)
>
> Ach? So was hab ich nur mit meinen C-64 Floppys gemacht - bevor ich
> einen Stanzer hatte - für die Rückseite.

Echt? Wir hatten eine Schere genommen.

In Disketten gebissen hatten wir nie. Aber die Bräuche mochten je nach
Bundesland unterschiedlich gewesen sein.

[Kay Martinen]

Am 19.04.21 um 23:32 schrieb Andreas Kohlbach:

> On Mon, 19 Apr 2021 22:14:48 +0200, Kay Martinen wrote:
>>
>> Am 19.04.21 um 20:20 schrieb Andreas Kohlbach:
>>>

>>>> Hast du denn schon mal mit Lochkarten gearbeitet?
>>>
>>> Ja. Früher, als wir uns noch keinen Leser leisten konnten, haben wir die
>>> Löcher mit den Eckzähnen in die Karten gestanzt. ;-)
>>
>> Ach? So was hab ich nur mit meinen C-64 Floppys gemacht - bevor ich
>> einen Stanzer hatte - für die Rückseite.
>
> Echt? Wir hatten eine Schere genommen.

Nach der ersten versehentlich ZERschnittenen Disk mit Daten drauf legt
sich dies Verlangen.

> In Disketten gebissen hatten wir nie. Aber die Bräuche mochten je nach
> Bundesland unterschiedlich gewesen sein.

<Ironie> Oh. Ich hab den Smiley vergessen.</ironie>

[Dennis Grevenstein]

K. Krause <klemens...@gmx.net> wrote:
>
> Ich weiss gar nicht was Ihr habt, Lochkarten sind doch ein sehr
> langlebiges Archivierungsmedium. Ob eine DVD nach 10 Jahren noch lesbar
> ist, ist ja sehr fraglich. Aber ich denke, wenn da nicht grade der
> Bücherwurm reinkommt, oder Micky- und Minnie Maus ein Nest reinbauen,
> kann man auch noch 80-spaltige Lochkarten von 1928 einlesen.

Ich meinte auch mehr die Möglichkeit mit den Daten auch was
anzufangen. Und natürlich ist klar, dass man die Löcher in den
Karten im Ernstfall auch mit dem blossen Auge abzählen kann.
Und ja: bestimmt kann man das irgendwie auch als Rohdaten-dump
in eine Tabelle kippen.
Allerdings hatte ich angenommen, dass noch unklar ist, was überhaupt
auf den Karten gespeichert ist. Zumindest ist das genau das Problem,
das ich kenne. Man muss oft genug den ganzen lauffähigen Computer
vorhalten und nicht nur die Daten.

Daher glaube ich schon, dass es hilfreich wäre, erstmal diese
Grundbedingungen zu klären und dann vielleicht doch jemanden
zu finden, der diese Karten irgendwie direkt einlesen könnte.
Wenn Ihr die passende hardware habt, dann ist doch super. Falls
nicht, dann gibt es vielleicht doch noch andere Leute, die das
passende noch haben.

gruss,
Dennis

--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."

[Hermann Riemann]

Am 19.04.21 um 18:30 schrieb Norbert Narten:

> Am 19.04.21 um 10:30 schrieb Hermann Riemann:
>
>>
>> Hermann
>>    vermutend, dass die Daten dann mit viel Aufwand
>>    zwar eingelesen werden aber wegen Format Probleme
>>    dann nicht verwendet werden können.
>>
>
> Warum so pessimistisch? Wenn tatsächlich auf den Lochkarten EBCDIC gespeichert
> ist, lässt sich so was für eine Analyse nach ASCII wandeln.

So etwas ist für einen Programmierer kein ernsthaftes Problem.
Wenn er sonstige Zeichencodes ( CBM?) verwendet,
geht das auch noch mit mehr Arbeit.

Wenn allerdings die Daten wegen copyright des
Programm Herstellers verschlüsselt ist..

Ich erinnere mich an Platine ST von Data Becker.
Extrem unhandlich in der Bedienung und bestimmt kein Gerber Format.

> Dann kann man ggf.
> eine Import- Regel für sein bevorzugtes Programm erstellen.

das erinnert mich an export nach html eine .xls Datei,
die mehrere Tabellen enthielt.
Da fehlten dann relevante Daten.

> Anyway... Ich hatte letztens die "Unmögliche" Aufgabe, einen Server, auf dem ein
> OAS10g R2 installiert ist, eine neue IP-Adresse und einen neuen Host-Namen samt
> DNS-Domain um zu verpassen. Die Aussage war: "installiere den OAS10g R2 neu,
> umkonfigurieren ist nicht möglich und auch nicht vorgesehen!". Mangels Installations-
> Satz ging das nicht - den hatte jemand zu voreilig entsorgt. Ungefähr 70 OAS10g-
> Konfigurations-Dateien + Betriebssystem und drei Tage später lief die Kiste wieder
> (mit neuer IP-Adresse und Namen) mit abschließendem User Acceptance Test. Soviel zu
> dem Thema "Das ist Unmöglich"... ;-) ...

Festplatte Ausbauen, locker an einen PC verkabeln, mounten
/etc/hosts und die Apache Datei editieren ..
Eventuell mit grep -rn 2> /dev/null nach IP-Adresse suchen..

Hermann
der seine Festplatten @home vorerst nicht direkt verschlüsselt.

--
http://www.hermann-riemann.de

[Christian Corti]

Andreas Kohlbach <a...@spamfence.net> wrote:
> Peter wollte die Daten in einen Art Tabellenkalkulation haben. Wenn das
> Format auch EBCDIC sein mag, nutzt das wenig, wenn man diese nackten Daten
> nicht. Die Daten könnten einen Tabellenkalkulation entstammen, sind
> vielleicht aber MIDI Daten oder ASCII-Porn.

Ok...

> > Hast du denn schon mal mit Lochkarten gearbeitet?
> Ja. Früher, als wir uns noch keinen Leser leisten konnten, haben wir die
> Löcher mit den Eckzähnen in die Karten gestanzt. ;-)

... also keine Erfahrung mit Lochkarten. Sag das doch gleich ;-)

Christian

[Christian Corti]

Dennis Grevenstein <dennis.gr...@gmail.com> wrote:
> auf den Karten gespeichert ist. Zumindest ist das genau das Problem,
> das ich kenne. Man muss oft genug den ganzen lauffähigen Computer
> vorhalten und nicht nur die Daten.

Das Prinzip von Lochkarten ist ja, daß es (von Binärdecks mal abgesehen,
aber die waren nicht üblich) völlig unabhängig vom Computer ist. Die
Daten wurden beispielsweise von einem FORTRAN-Programm ausgewertet. Mit
Glück ist das Programm auch auf einem Stapel Lochkarten dabei. Wenn
nicht, auch nicht schlimm.
Man darf hier nicht zu modern denken, ich brauche keine Software auf dem
Originalcomputer, um damit was anzufangen. Es reicht zu wissen, was die
einzelnen Felder bedeuten, das Format ist wie gesagt "Lochkarte".

Christian

[Christian Corti]

Markus Elsken <markus...@ewetel.net> wrote:
> Und danach mal bei diversen Computermuseen anfragen. Die LK können
> sicher viele lesen, aber die Daten konvertieren - nunja.

Sagt mal, warum schießt ihr euch alle auf die Datenkonversion ein? Das
sind keine kryptisch-binären Word-Dateien, sondern einfach nur
Lochkarten...
Und ja, ich und Klemens arbeiten regelmäßig mit Lochkarten!

Christian

[Hermann Riemann]

Am 20.04.21 um 08:58 schrieb Christian Corti:

> Man darf hier nicht zu modern denken, ich brauche keine Software auf dem
> Originalcomputer, um damit was anzufangen. Es reicht zu wissen, was die
> einzelnen Felder bedeuten, das Format ist wie gesagt "Lochkarte".

Früher wollte ich mal Lochkarten effizient benutzen.
Da die meisten Plätze normalerweise nicht benutzt werden,
habe ich sozusagen senkrecht binär stanzen lassen.
Allerdings weigerte sich der Lochkartenleser
das wieder einzulesen.
So wie bei den Kollegen,
die die Lochkarten zum Abheften mit einem Handlocher bearbeitet haben.

Hermann
der noch nicht ausprobiert hat,
ob das frühere übereinander drucken von Buchstaben
heute noch auf Bildschirm und aktuelle Drucker geht.

--
http://www.hermann-riemann.de

[Josef Moellers]

On 19.04.21 18:30, Norbert Narten wrote:

> dem Thema "Das ist Unmöglich"... ;-) ...

Mein Lieblingsspruch ... die Auto-Reaktion: "Das wollen wir doch mal sehen!"

Einmal: "Kann man den Code aus dem Mikrocontroller (einem 8052-BASIC
oder war's ein Z8 BASIC/DBUG?) auslesen?" - "Nein, das ist unmöglich" ...
Ein anderes Mal: "Warum tut es das Terminal an der seriellen Leitung
dieses Desktop-Unix-Rechners nicht?" "Sie haben da wohl nur eine
Einplatz-Lizenz, da ist Echo abgeschaltet, das ist unmöglich!" ...

Geht nicht ... gibt's nicht (*)

Josef

(*) Nunja, bevor einer mit "Perpetuum Mobile" anfängt ... Das ist
unmöglich ;-)

[Josef Moellers]

On 19.04.21 17:26, Stefan Ram wrote:

> "Peter Heitzer" <peter....@rz.uni-regensburg.de> writes:

>> Da ein Kartenleser wohl kaum aufzutreiben ist und dann auch noch an
>> einen modernen Rechner angeschlossen werden müsste frage ich, ob es einfache

>> Möglichkeit gibt, die Lochkarten mit einem Flachbettscanner auszuwerten.
>

> Wenn man sie immer an die Kanten führt, so daß alle gleich
> ausgerichtet sind, und eine schwarze matte Pappe dahinter
> wäre das eine Hilfe für die Bildauswertung. Das würde auch
> mit einer Kamera (Smartphone) und einem entsprechenden
> Aufbau gehen.
>
> Die Programmierung der Software scheint relativ einfach zu
> sein: Man muß ja nur sehen, ob bestimmte Positionen auf dem
> Bild hell oder dunkel sind. Eventuell ist vorher noch eine
> Feinausrichtung nötig.
>
> (Theoretisch sollte Laptop-Hardware sogar reichen, wenn man
> die Karte auf den Bildschirm hält, dann die Pixel dahinter
> ansteuert und mit der Webcam das Streulicht mißt [etwas wie
> einen Software-Lock-In-Amplifier verwenden]).
>
> In jedem Fall können Lesefehler vorkommen, und man muß sich
> Gedanken über Fehlererkennung und -behebung machen.

Hm, die Löcher sind ... moment ...
bei 300dpi 39 pixel hoch und 17 pixel breit, da ist also etwas
Spielraum, wenn die Karten gut ausgerichtet sind.

Mein Brother ADS-2100e hat ohne Probleme erst einmal 10 Karten einlesen
können. Sie sind auch recht gut ausgerichtet.
Klar, man müßte dann jemanden davor setzen, der für Nachschub sorgt und
alle paar zig Karten muß eine Pause, aber es geht!

Josef

[Peter Heitzer]

Kay Martinen <use...@martinen.de> wrote:
>Am 19.04.21 um 20:20 schrieb Andreas Kohlbach:
>> On Mon, 19 Apr 2021 10:58:38 +0200, Christian Corti wrote:
>>>
>>> Hanno Foest <hurga...@tigress.com> wrote:
>>>> kennen... aber bevor man das überhaupt anfängt, sollte man eine Idee
>>>> haben, was das Datenformat ist und wie man das konvertieren möchte,
>>>> ansonsten hat man hinterher einen Dump Rohdaten, mit denen man nichts
>>>> anfangen kann.
>>>
>>> Was interessiert den Ausleser, was die einzelnen Felder bedeuten? Das
>>> wird der Datenbesitzer schon wissen, weil er sie in ein Spreadsheet
>>> übernehmen will.
>>
>> Peter wollte die Daten in einen Art Tabellenkalkulation haben. Wenn das
>> Format auch EBCDIC sein mag, nutzt das wenig, wenn man diese nackten Daten
>> nicht. Die Daten könnten einen Tabellenkalkulation entstammen, sind
>> vielleicht aber MIDI Daten oder ASCII-Porn.

>Das könnte sogar sein. Im OP stand was von Ornitologischen Daten. Das
>wären dann wohl Midi-Vogelgezwitscher und Nackte Vögel ähh Küken oder?


>> Daher sollte der Produzent der Daten Informationen zum Format beifügen.

Das hat der Anfrager angegeben:
und 8,3 cm hoch. Darin sind (durch Leerzeichen/Leerspalten getrennt)
codiert:
* Vogelart,
* Datum,
* Qualität der Beobachtung,
* Anzahl der Exemplare,
* UTM-Koordinaten,
* Beobachter.

Ich vermute, es sind reine (EBCIDC)Zeichen, aber es ist sicher notwendig,
einige Exemplare der Karten zu sehen.

--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de

[Peter Heitzer]

Ich denke, das ist gar nicht nötig. Jede Sichtung ist auf genau einer Karte
gespeichert. In 80 Zeichen passt einiges.

[Josef Moellers]

... und der Vortiel: die Karten sind schon senkrecht einge-scan-t, da
geht dann also doch recht einfach ein Programm, daß Bilder Zeilenweise
lesen kann, z.B. ein PERL Skript mit Image::Magick.

[K. Krause]

On 20.04.21 08:58, Christian Corti wrote:
....

> Das Prinzip von Lochkarten ist ja, daß es (von Binärdecks mal abgesehen,
> aber die waren nicht üblich) völlig unabhängig vom Computer ist. Die
> Daten wurden beispielsweise von einem FORTRAN-Programm ausgewertet. Mit
> Glück ist das Programm auch auf einem Stapel Lochkarten dabei. Wenn
> nicht, auch nicht schlimm.
> Man darf hier nicht zu modern denken, ich brauche keine Software auf dem
> Originalcomputer, um damit was anzufangen. Es reicht zu wissen, was die
> einzelnen Felder bedeuten, das Format ist wie gesagt "Lochkarte".

Die Arbeit mit Lochkarten ist übrigens der heutigen Arbeit mit
Tabellenkalkulation sehr ähnlich:
Wenn man mal von Binärdecks mal absieht, dann enthält jeder Karte eine
Reihe von Datenfeldern, die z. B. numerisch oder Textformat haben
können. Das wiederholt sich von Karte zu Karte. Das entspricht recht
genau den Spalten und Zeilen eines Spreadsheet-Programms.

Auf diese Felder werden dann bestimmte festgelegte Operationen
angewandt: z. B. werden alle Spalten einer Karte, die einem Preis
entsprechen aufaddiert. Alle Spalten, die einer Stückzahl und einem
Einzelpreis entsprechen werden multipliziert, und zu einer Bestell-
nummer wird aus einer Tabelle eine Produktbezeichnung, oder aus einer
Kundennummer Name und Anschrift herausgesucht.

Das war sogar bei den FORTRAN-Programmen auch so:
Spalte 1: Kommentarkennzeichnung
Spalten 2- 6: Label
Spalte 7: Continuationkennung
Spalte 8-72: Statement
Spalte 73-78: Kartenkennzeichnung, Kann auch nur rein numerisch sein

Diese Arbeitsweise hat sich von den Tabelliermaschinen, über die
elektronischen Rechenlocher, bis zu den Computern, die mit RPG dieses
Verfahren sehr genau nachgebildet haben bis zu den Spreadsheet-
Programmen durchgezogen.
Ob das ganze nun EBCDIC (die IBM arbeitet bei ihren Großrechnern immer
noch damit) oder ASCII ist, ist wirklich pillepalle. An den System-
grenzen gibts dann eine Codetabelle, die den Code wandelt.

Die Problematik liegt aber bei diesen Daten an einer anderen Stelle:
Da Lochkarten teuer sind und nur eine begrenzte Kapazität haben,
nämlich 80 Zeichen pro Karte, hat man reduntante Teile der Daten nicht
mit abgelocht. D.h. Dezimalpunkte wurden nicht notwendigerweise mit
abgelocht. Ebenfalls wurden zwischen den einzelnen Zahlen nicht unbe-
dingt trennende Zwischenräume abgelocht. Wenn auf einer Lochkarte
also z. B. 123456 abgelocht ist, dann kann das eine Zahl im Format
I6 sein, oder oder zewi Zahlen im Format I5,I2 oder 6 Zahlen im
Format 6I1. (wenn hier noch jemand richtiges FORTRAN versteht.
An der Ecke wäre also etwas Hellseherei angesagt, oder Kenntnis des
Programm das diese Zahlen produziert hat.


Wer sich das mal anschauen will:
http://computermuseum.informatik.uni-stuttgart.de/virtuell/ibm1130.mp4


Grüßle
Klemens

[Thomas Koenig]

K. Krause <klemens...@gmx.net> schrieb:

> Das war sogar bei den FORTRAN-Programmen auch so:
> Spalte 1: Kommentarkennzeichnung
> Spalten 2- 6: Label
> Spalte 7: Continuationkennung

Ein bisschen anders...

Spalte 1 ist Kommentar (* oder C).

Spalten 1 bis 5 können das Label enthalten.

Fortsetzung ist Spalte 6.

Spelte 7 bis 72 enthalten dann den Quellcode.

Siehe https://wg5-fortran.org/ARCHIVE/Fortran77.html .

Der Grund ist ganz interessant - die IBM 704, für die Fortran am
Anfang entwickelt wurde, hatte zwei 36-bit-Register, und die
Einleseroutinen lasen jeweils ein Bit von der Lochkarte in jedes
der beiden Register ein. Daher konnte die Maschine so erst mal
nur 72 Zeichen lesen, und die 80-bit-Lochkarten waren vorher
schon standardisiert.

[K. Krause]

On 20.04.21 10:36, Thomas Koenig wrote:
> K. Krause <klemens...@gmx.net> schrieb:
>
>> Das war sogar bei den FORTRAN-Programmen auch so:
>> Spalte 1: Kommentarkennzeichnung

...

>
> Ein bisschen anders...
>
> Spalte 1 ist Kommentar (* oder C).
>

....

Das war ja ein Aufmerksamkeitstest meinerseits um rauszufinden,
dass hier überhaupt jemand, das was ich geschrieben habe, inhaltlich
nachvollzieht. ;-)


Klemens

A QUICK BROWN FOX JUMPS OVER THE LAZY DOG: 0123456789

[Diedrich Ehlerding]

Thomas Koenig meinte:

> Spalte 1 ist Kommentar (* oder C).

In "klassischem" FORTRAN gabs da nur C, nicht sowas neumodisches wie *

[Thomas Koenig]

Diedrich Ehlerding <diedrich....@t-online.de> schrieb:

> Thomas Koenig meinte:
>
>> Spalte 1 ist Kommentar (* oder C).
>
> In "klassischem" FORTRAN gabs da nur C, nicht sowas neumodisches wie *

Hmm...

https://wg5-fortran.org/ARCHIVE/Fortran77.html sagt

3.2.1 Comment_Line. A comment line is any line that
contains a C or an asterisk in column 1, or contains
only blank characters in columns 1 through 72. A
comment line that contains a C or an asterisk in column
1 may contain any character capable of representation
in the processor in columns 2 through 72.

Aber du hast recht, in Fortran 66 hieß es

3.2.1 Comment Line. The letter C in column 1 of a line
designates that line as a comment line. [...]

Wenn wir hier folkloristisch unterwegs sind, dann ist vermutlich
schon Fortran 77 nemodisches Zeuchs mit IF/THEN/ELSE und so.

Und Fortran 90... das ist ja erst 30 Jahre her!

[Hanno Foest]

Am 20.04.21 um 03:33 schrieb Andreas Kohlbach:

> Wenn wir Wochenende zu viel mit dem Maria-Zeit-Daemon spielten, kam man
> auch auf lustige Ideen. Wie statt der Magnet-Scheibe Sandpapier
> einzulegen. Hätte der Kopfreinigung eine ganz neue Dimension gegeben.

Kam gerade kürzlich bei mir vorbei...

https://www.tigress.com/hurga/reinigungsdiskette.jpg

Hanno

--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

[Peter Heitzer]

Peter Heitzer <peter....@rz.uni-regensburg.de> wrote:
>Ich hatte gerade eine Anfrage eines Biologen, der seine ornithologischen
>Beobachtung auf mehreren Tausend Lochkarten gespeicher hat und nun
>nach einer Lösung sucht, die Daten in eine Tabellenkalkulation einzulesen.

>Da ein Kartenleser wohl kaum aufzutreiben ist und dann auch noch an
>einen modernen Rechner angeschlossen werden müsste frage ich, ob es einfache
>Möglichkeit gibt, die Lochkarten mit einem Flachbettscanner auszuwerten.

Ich habe mal ein Muster so einer Karte
https://homepages.uni-regensburg.de/~hep09515/dafc/lochkarte.jpg

Man sieht, daß Vogelart und Beobachter nicht im Klartext kodiert sind.
Wenn also die Kodierung nicht mehr bekannt ist, sind die kompletten
Daten wertlos.

[Kay Martinen]

Am 20.04.21 um 09:01 schrieb Christian Corti:

> Andreas Kohlbach <a...@spamfence.net> wrote:
>
>>> Hast du denn schon mal mit Lochkarten gearbeitet?
>> Ja. Früher, als wir uns noch keinen Leser leisten konnten, haben wir die
>> Löcher mit den Eckzähnen in die Karten gestanzt. ;-)
>
> ... also keine Erfahrung mit Lochkarten. Sag das doch gleich ;-)

Aber Erfahrungen mit löcher_in_den_Zähnen hat er bestimmt!
Die ausgestanzten Papierfitzel müssen ja irgendwo bleiben.

:-)

[Thomas Koenig]

Peter Heitzer <peter....@rz.uni-regensburg.de> schrieb:

> Peter Heitzer <peter....@rz.uni-regensburg.de> wrote:
>>Ich hatte gerade eine Anfrage eines Biologen, der seine ornithologischen
>>Beobachtung auf mehreren Tausend Lochkarten gespeicher hat und nun
>>nach einer Lösung sucht, die Daten in eine Tabellenkalkulation einzulesen.
>>Da ein Kartenleser wohl kaum aufzutreiben ist und dann auch noch an
>>einen modernen Rechner angeschlossen werden müsste frage ich, ob es einfache
>>Möglichkeit gibt, die Lochkarten mit einem Flachbettscanner auszuwerten.
> Ich habe mal ein Muster so einer Karte
> https://homepages.uni-regensburg.de/~hep09515/dafc/lochkarte.jpg

Da stehen ja sogar die Buchstaben oben drauf, das könnte man ja
schon mit normalem OCR machen.

Drauf steht (aus deinem vorherigen Post):

> * Vogelart,

080.

> * Datum,

Format YYMMDD, vermutlich

> * Qualität der Beobachtung,

7 (was das auch heißt)

> * Anzahl der Exemplare,

5, vermutlich

> * UTM-Koordinaten,

Die sind sogar "Klartext", 33UUQ... sieht so aus.

> * Beobachter.

FLX. Hm.

> Man sieht, daß Vogelart und Beobachter nicht im Klartext kodiert sind.
> Wenn also die Kodierung nicht mehr bekannt ist, sind die kompletten
> Daten wertlos.

Der Beobachter sollte sich anhand seiner Initialien vielleicht
noch rekonstruieren lassen. Die Vogelart... klar, da braucht
man die Unterlagen.

[Kay Martinen]

Am 20.04.21 um 09:29 schrieb Josef Moellers:

> On 19.04.21 18:30, Norbert Narten wrote:
>
>> dem Thema "Das ist Unmöglich"... ;-) ...
>
> Mein Lieblingsspruch ... die Auto-Reaktion: "Das wollen wir doch mal sehen!"

> ...
> Geht nicht ... gibt's nicht (*)
>

> (*) Nunja, bevor einer mit "Perpetuum Mobile" anfängt ... Das ist
> unmöglich ;-)

Ahem: "glauben SIE an diesen Kalte-Fusions-Kwatsch?"
Ahem: "Zeitreisen sind nicht möglich" Sagte der Zeitreisende!
Ahem: " 2 Unendliche Dinge: Das universum und Menschliche Dummheit"

:-) Perpetuum Mobile SIND möglich! Nach einer weiter gefassten
Definition von Verlustfreiheit!

Denn des einen Horizont fängt dort an wo der andere einen Tellerrand
sieht, und beide Ahnen nur das die Wahrheit noch weiter draußen liegt,
begraben unter Nichtwissen.

[Kay Martinen]

Am 20.04.21 um 09:00 schrieb Christian Corti:

> Markus Elsken <markus...@ewetel.net> wrote:
>> Und danach mal bei diversen Computermuseen anfragen. Die LK können
>> sicher viele lesen, aber die Daten konvertieren - nunja.
>
> Sagt mal, warum schießt ihr euch alle auf die Datenkonversion ein? Das
> sind keine kryptisch-binären Word-Dateien, sondern einfach nur
> Lochkarten...

Wundert mich auch. Das einlesen (zweimal zw. Verify?) ist doch der
einzige HW-Job daran. Den Rest kann *später* Software erledigen (+Brain.exe)

Enstammt nicht dieser Epoche die bezeichnung dieser
Verarbeitungs-Methode: Batch = Stapel. Eine DOS Batchdatei ist auch nur
eine aneinanderreihung von kommando-statements. Jedenfalls im
Elementarsten Falle - ohne neumodsches MENU oder Kontrollstrukturen...

Zur Datenstruktur der Karten hab ich eben schon was von Peter gelesen,
es gilt einen Batch an Karten ein zu lesen und in Elektronisch/Digital
Speicherbare Form zu überführen. Danach könnten die im Prinzip
*überallhin* geschickt werden.

Mit diesen Rohdaten kann man dann immer noch Struktur und Text-analyse
betreiben um Feldgrenzen u. Datentypen ab zu leiten. Scheiße, das hab
ich mit dem Import-assistenten einen Steinalten Windows-Office schon vor
20+ Jahren hin bekommen. Und heute gibt es bestimmt noch bessere Tools
dafür.

> Und ja, ich und Klemens arbeiten regelmäßig mit Lochkarten!

Von Klemens hab ich es angenommen. Von dir wußte ich es nicht, bis du
neulich das entsprechende Angebot machtest.

[Peter Heitzer]

Thomas Koenig <tko...@netcologne.de> wrote:
>Peter Heitzer <peter....@rz.uni-regensburg.de> schrieb:
>> Peter Heitzer <peter....@rz.uni-regensburg.de> wrote:
>>>Ich hatte gerade eine Anfrage eines Biologen, der seine ornithologischen
>>>Beobachtung auf mehreren Tausend Lochkarten gespeicher hat und nun
>>>nach einer Lösung sucht, die Daten in eine Tabellenkalkulation einzulesen.
>>>Da ein Kartenleser wohl kaum aufzutreiben ist und dann auch noch an
>>>einen modernen Rechner angeschlossen werden müsste frage ich, ob es einfache
>>>Möglichkeit gibt, die Lochkarten mit einem Flachbettscanner auszuwerten.
>> Ich habe mal ein Muster so einer Karte
>> https://homepages.uni-regensburg.de/~hep09515/dafc/lochkarte.jpg

>Da stehen ja sogar die Buchstaben oben drauf, das könnte man ja
>schon mit normalem OCR machen.

Sofern alle Karten so sind, wäre das die einfachere Methode.

>Drauf steht (aus deinem vorherigen Post):

>> * Vogelart,

>080.

>> * Datum,

>Format YYMMDD, vermutlich

Der Fragesteller gab an, von 1971-1976 studiert zu haben. Das würde passen.

[Christian Corti]

Thomas Koenig <tko...@netcologne.de> wrote:
> Da stehen ja sogar die Buchstaben oben drauf, das könnte man ja
> schon mit normalem OCR machen.

Viel Spaß ;-)
Aber endlich mal ein konstruktiver Beitrag :-))

> Drauf steht (aus deinem vorherigen Post):
> > * Vogelart,
> 080.

Das steht vielleicht in einem Büchlein oder der Verfasser weiß das noch.

> > * Datum,
> Format YYMMDD, vermutlich

Sehe ich auch so.

> > * Qualität der Beobachtung,
> 7 (was das auch heißt)

+1

> > * Anzahl der Exemplare,
> 5, vermutlich

+1

> > * UTM-Koordinaten,
> Die sind sogar "Klartext", 33UUQ... sieht so aus.

Und sogar plausibel, wenn man sich den Wikipedia-Artikel zu UTM
durchliest. Meridianzone 33, Zonenfeld U, Gitterquadrat UQ, irgendwo im
Osten Bayerns.
Also absoluter Klartext, ohne Computer verständlich.

> > * Beobachter.
> FLX. Hm.

Namenskürzel vermutlich.

> > Man sieht, daß Vogelart und Beobachter nicht im Klartext kodiert sind.
> > Wenn also die Kodierung nicht mehr bekannt ist, sind die kompletten
> > Daten wertlos.
> Der Beobachter sollte sich anhand seiner Initialien vielleicht
> noch rekonstruieren lassen. Die Vogelart... klar, da braucht
> man die Unterlagen.

Eben, aber alles wirklich ganz einfach.
Wie gesagt, Lochkarten sind kein Werk von Hexenmeistern, sondern von
ganz normalen Anwendern, oft genug ohne Computerwissen.

Christian

[Christian Corti]

Christian Corti <u...@reply.to> wrote:
> > > * UTM-Koordinaten,
> > Die sind sogar "Klartext", 33UUQ... sieht so aus.

> Und sogar plausibel, wenn man sich den Wikipedia-Artikel zu UTM
> durchliest. Meridianzone 33, Zonenfeld U, Gitterquadrat UQ, irgendwo im
> Osten Bayerns.
> Also absoluter Klartext, ohne Computer verständlich.

Und ganz genau:
https://www.koordinaten-umrechner.de/decimal/48.934820,12.509380?karte=OpenStreetMap&zoom=10

An der Donau, zwischen Regensburg und Straubing.

Christian

[Markus Elsken]

Moin!

Am 20.04.21 um 03:33 schrieb Andreas Kohlbach:
> Wenn wir Wochenende zu viel mit dem Maria-Zeit-Daemon spielten, kam man
> auch auf lustige Ideen. Wie statt der Magnet-Scheibe Sandpapier
> einzulegen. Hätte der Kopfreinigung eine ganz neue Dimension gegeben.

Sowas hat in den 90ern eine Videothek gemacht. Aus der Schale mit den
Leerkassetten fehlten immer wieder welche. Dann wurden einige
präperiert: auf ca. 10cm Kleber und Schleifpulver drauf. Hat ein
ehrlicher Kunde die erwischt "Oh, ich sehe gerade, die hat einen Fehler.
Nehmen Sie sich eine andere". Danach kam die wieder rein. Irgendwann
waren zwei weg und die Diebstähle liessen nach - das brauchte wohl
jemand eine neue teure Kopftrommel.

mfg Markus

[Christian Corti]

Peter Heitzer <peter....@rz.uni-regensburg.de> wrote:
> >Da stehen ja sogar die Buchstaben oben drauf, das könnte man ja
> >schon mit normalem OCR machen.
> Sofern alle Karten so sind, wäre das die einfachere Methode.

Echt? Dann viel Spaß.

Christian

[Hermann Riemann]

Am 20.04.21 um 14:58 schrieb Andreas Kohlbach:

> On Tue, 20 Apr 2021 09:24:21 +0200, Hermann Riemann wrote:
>>
>> Am 20.04.21 um 08:58 schrieb Christian Corti:
>>

>> Früher wollte ich mal Lochkarten effizient benutzen.
>> Da die meisten Plätze normalerweise nicht benutzt werden,
>> habe ich sozusagen senkrecht binär stanzen lassen.
>> Allerdings weigerte sich der Lochkartenleser
>> das wieder einzulesen.
>> So wie bei den Kollegen,
>> die die Lochkarten zum Abheften mit einem Handlocher bearbeitet haben.
>

> Die Abheft-Löcher verursachen einen Prüfsummen-Error? ;-)

Ich habe nur von Ferne die Maschine piepend prostestierend gehört.

Hermann
der als Anwender nur selten an die mainframe durfte.

--
http://www.hermann-riemann.de

[Kay Martinen]

Am 20.04.21 um 16:29 schrieb Andreas Kohlbach:

>
> Hier haben sie leere Boxen in den Regalen. Wer das Produkt will, gibt
> eine solche Box an der Kasse ab und erhält die richtige Ware. Zumindest

Das "war" hier auch üblich. Die klassischen Videotheken (mit VHS
Kasetten) dürften wohl tot sein. Wenn's noch welche gibt dann mit DVD
oder BD.

> vor Corona, da diese Läden derzeit nur verschicken, bzw. "curb pickup"
> (gibt es das auch in Deutschland?) machen.

Vermutlich als Click & Meet Variante "Click and Collect" oder so. Also
nicht Abholung IM laden (was Conrad Elektronik IMHO anbot) sondern
abholung VOR dem Laden.

[Diedrich Ehlerding]

Thomas Koenig meinte:

> Aber du hast recht, in Fortran 66 hieß es
>
> 3.2.1 Comment Line. The letter C in column 1 of a line
> designates that line as a comment line. [...]
>
> Wenn wir hier folkloristisch unterwegs sind, dann ist vermutlich
> schon Fortran 77 nemodisches Zeuchs mit IF/THEN/ELSE und so.
>
> Und Fortran 90... das ist ja erst 30 Jahre her!

Bäh, das ist auch alles neumodisches Zeuchs. Æchte Mænner™ programmieren
in FORTRAN II oder allenfalls FORTRAN IV!

[Thomas Koenig]

Diedrich Ehlerding <diedrich....@t-online.de> schrieb:

> Thomas Koenig meinte:
>
>> Aber du hast recht, in Fortran 66 hieß es
>>
>> 3.2.1 Comment Line. The letter C in column 1 of a line
>> designates that line as a comment line. [...]
>>
>> Wenn wir hier folkloristisch unterwegs sind, dann ist vermutlich
>> schon Fortran 77 nemodisches Zeuchs mit IF/THEN/ELSE und so.
>>
>> Und Fortran 90... das ist ja erst 30 Jahre her!
>
> Bäh, das ist auch alles neumodisches Zeuchs. Æchte Mænner™ programmieren
> in FORTRAN II oder allenfalls FORTRAN IV!

FORTRAN IV war die Basis für Fortran 66, so weit ist das nicht
voneinander weg.

Und bekommt man heute noch Hardware, auf der Fortran II läuft?
Fortran I ist ja leider verlorgengegangen...

[Michael Kreienberg]

Am 20.04.2021 um 14:59 schrieb Christian Corti:
>>> * Vogelart,
>> 080.
>
> Das steht vielleicht in einem Büchlein oder der Verfasser weiß das noch.

In diesem Zusammenhang sind die Codieranweisungen von Alfred Kohlus
evtl. ganz interessant, siehe auch
https://www.ornithologie-hamburg.de/beobachtungen.

Kohlus hat Mitte der 1960er-Jahre auch in verschiedenen Fachaufsätzen
über die elektronische Auswertung berichtet, so in den Fachzeitschriften
"Die Vogelwelt", "Berichte über die wissenschaftliche Biologie". Leider
sind die Bibliotheken Pandemie-bedingt bis auf Weiteres eingeschränkt,
sonst würde ich mal nachschauen.

Viele Grüße
Michael Kreienberg

[Michael Kreienberg]

Am 20.04.2021 um 09:53 schrieb Josef Moellers:
> Mein Brother ADS-2100e hat ohne Probleme erst einmal 10 Karten einlesen
> können. Sie sind auch recht gut ausgerichtet.
> Klar, man müßte dann jemanden davor setzen, der für Nachschub sorgt und
> alle paar zig Karten muß eine Pause, aber es geht!

ich kann mehrere Tausend dieser Lochkarten auf einem professionellen
Ricoh-Multifunktionsgerät bei 600 dpi in wenigen Stunden einscannen.
Selbst bei den dünnen Kontoauszügen in den Maßen 5,5 x 8,5 Zoll auf
Thermopapier hat das als Belegstapel zu je 200 Stück ohne Papierstau gut
geklappt. Oben genannte Multifunktionsgeräte, seien es Ricoh der
IM-/MP-Serie oder Konica Bizhub/Develop Ineo, sind in Büroumgebungen
Standardausstattung.

Dann habe ich habe die niedrig aufgelöste Beispieldatei mal mit
ABBYY-Finereader ausprobiert, die Kopfzeilen mittels OCR zu erfassen ist
bis auf die abgeschnittene Null an der Ecke nicht die Herausforderung.
Das OCR-Ergebnis müsste allerdings danach alles manuell kontrolliert und
nachbearbeitet werden.

Nothing beats of course a punch card reader :).

Viele Grüße
Michael Kreienberg

[Hermann Riemann]

Am 20.04.21 um 23:12 schrieb Thomas Koenig:

> Und bekommt man heute noch Hardware, auf der Fortran II läuft?
> Fortran I ist ja leider verlorgengegangen...

Die hardware ist weniger das Problem.
https://de.wikipedia.org/wiki/Hercules_(Emulator)

Eher die Quellen des compilers zu finden.
Und vielleicht noch den Assembler anzupassen.

Bei hardware gibt es das Problem,
wenn in Spalte 1 eine 0 steht,
wird nicht mehr in die gleiche Spalte gedruckt.

Fortran 77 ist noch erhältlich.
https://www.fujitsu.com/de/products/computing/servers/mainframe/bs2000/concepts/programming/for1.html
https://www.fujitsu.com/de/imagesgig5/RS68110_200121_PortfolioCard_BS2000_D_x3.pdf

Fortran II Programme könnten vielleicht damit noch
übersetzt werden.

Hermann
der früher dies auf diverse Art verwendet hat.

--
http://www.hermann-riemann.de

[Thomas Koenig]

Hermann Riemann <nosp...@hermann-riemann.de> schrieb:

> Am 20.04.21 um 23:12 schrieb Thomas Koenig:
>
>> Und bekommt man heute noch Hardware, auf der Fortran II läuft?
>> Fortran I ist ja leider verlorgengegangen...
>
> Die hardware ist weniger das Problem.

Klar,

https://www.youtube.com/watch?v=uFQ3sajIdaM&vl=de :-)

> https://de.wikipedia.org/wiki/Hercules_(Emulator)

Das würde voraussetzen, dass es für die /360 tatsächlich
Fortran II gab. Soweit ich das in "Abstracthing away the
Machine" lesen kann, gab es dafür Fortran IV (G und H),
die Basis für Fortran 66.

> Eher die Quellen des compilers zu finden.

Die alten Betriebssysteme hat IBM ja gezwungenermaßen in die
Public Domain gestellt. Irgendwo auf meiner Platte habe ich
u.a. die Sourcen zu IEBGENER rumfliegen... ein bisschen gruselig.

> Und vielleicht noch den Assembler anzupassen.

Wenn man ihn findet, sollte der auch verwendbar sein.

>
> Bei hardware gibt es das Problem,
> wenn in Spalte 1 eine 0 steht,
> wird nicht mehr in die gleiche Spalte gedruckt.
>
> Fortran 77 ist noch erhältlich.
> https://www.fujitsu.com/de/products/computing/servers/mainframe/bs2000/concepts/programming/for1.html
> https://www.fujitsu.com/de/imagesgig5/RS68110_200121_PortfolioCard_BS2000_D_x3.pdf

Fortran 77 kann man auch heute noch zum allergrößten Teil mit
einem modernen Compiler übersetzten :-) Und im Zweifelsfall
f2c.

Und VS Fortran, für IBM Mainframes, ist auch fest in der
Vergangenheit verwurzelt - die implementieren nicht mal Fortran 90.

[Josef Moellers]

On 20.04.21 12:34, Hanno Foest wrote:
> Am 20.04.21 um 03:33 schrieb Andreas Kohlbach:
>
>> Wenn wir Wochenende zu viel mit dem Maria-Zeit-Daemon spielten, kam man
>> auch auf lustige Ideen. Wie statt der Magnet-Scheibe Sandpapier
>> einzulegen. Hätte der Kopfreinigung eine ganz neue Dimension gegeben.
>
> Kam gerade kürzlich bei mir vorbei...
>
> https://www.tigress.com/hurga/reinigungsdiskette.jpg

Aua, das tut ja schon beim Hingucken weh!

Josef

[Josef Moellers]

On 20.04.21 17:26, Kay Martinen wrote:

> Vermutlich als Click & Meet Variante "Click and Collect" oder so. Also
> nicht Abholung IM laden (was Conrad Elektronik IMHO anbot) sondern
> abholung VOR dem Laden.

Meist "zwischen Tür und Angel" ;-)

Josef

[Josef Moellers]

On 21.04.21 00:48, Michael Kreienberg wrote:
> Am 20.04.2021 um 09:53 schrieb Josef Moellers:
>> Mein Brother ADS-2100e hat ohne Probleme erst einmal 10 Karten einlesen
>> können. Sie sind auch recht gut ausgerichtet.
>> Klar, man müßte dann jemanden davor setzen, der für Nachschub sorgt und
>> alle paar zig Karten muß eine Pause, aber es geht!
>
> ich kann mehrere Tausend dieser Lochkarten auf einem professionellen
> Ricoh-Multifunktionsgerät bei 600 dpi in wenigen Stunden einscannen.

Der war bei mir gerade mit den Rezepten meiner Frau belegt ;-)

> Selbst bei den dünnen Kontoauszügen in den Maßen 5,5 x 8,5 Zoll auf
> Thermopapier hat das als Belegstapel zu je 200 Stück ohne Papierstau gut
> geklappt.

Ich habe auch einen HP OfficeJet mit Einzugsscanner. Nachdem der zum
zweiten Mal ein Blatt einer BYTE auf eine interne Walze gewickelt hat
(*), habe ich mir den Brother angeschafft. Der kann dann sogar
gleichzeitig zweiseitig! Ein paar Skripte und ein paar Tage später waren
wieder ein paar Meter Regalbrett und ein paar Kartons frei.

(*) Das Teil mußte dann jedes Mal in die Werkstatt. Ich habe keine frei
verfügbare Beschreibung gefunden, wie man es zerstörungsfrei öffnet.

Josef

[Josef Moellers]

On 20.04.21 14:59, Christian Corti wrote:
> Thomas Koenig <tko...@netcologne.de> wrote:
>> Da stehen ja sogar die Buchstaben oben drauf, das könnte man ja
>> schon mit normalem OCR machen.
>
> Viel Spaß ;-)
> Aber endlich mal ein konstruktiver Beitrag :-))

Aaaalso:
1) Michale Kreienbergs Vorschlag, die paar tausend Karten einlesen.
2) Mein Perl-Skript ist ~150 Zeilen lang, der Großteil das Mapping
Loch->Zeichen.
Angebot steht.

Josef

[Diedrich Ehlerding]

Thomas Koenig meinte:

> Und bekommt man heute noch Hardware, auf der Fortran II läuft?

Waren die Fortran-Dialekte nicht aufwärtskompatibel?

[Christian Corti]

Josef Moellers <josef.m...@invalid.invalid> wrote:
> Aaaalso:
> 1) Michale Kreienbergs Vorschlag, die paar tausend Karten einlesen.
> 2) Mein Perl-Skript ist ~150 Zeilen lang, der Großteil das Mapping
> Loch->Zeichen.
> Angebot steht.

Gut, dann ziehe ich ganz offiziel mein Angebot zurück, die Lochkarten in
einem echten Lochkartenleser tutti completti ohne nennenswerten Aufwand
einzulesen.

Christian

[Michael Kreienberg]

Am 21.04.2021 um 08:35 schrieb Josef Moellers:
> 1) Michale Kreienbergs Vorschlag, die paar tausend Karten einlesen.

wahrscheinlich rede ich mich hier gerade um Kopf und Kragen, aber ich
kann die Dinger einscannen, ich mache das gerne. Das hätte zusätzlich
den Vorteil, dass für die Nachwelt eine Sicherheitskopie der physischen
Lochkarten vorhanden ist, falls mit den Dingern mal irgendetwas
mechanisch passiert.

Hierzuthread war aber schon das Angebot, die Lochkarten mit einem
Lochkartenleser einzulesen, dann wäre es doch schön, das zunächst so zu
erledigen und danach optional die von mir skizzierte Sicherheitskopie
anzufertigen.

Wenn da keine Geheimnisse auf den Lochkarten sind, könnte man das Ganze
in die Cloud laden und die dafc-Protagonisten können sich Skript- und
OCR-technisch austoben.

Viele Grüße
Michael Kreienberg

[Michael Kreienberg]

Am 21.04.2021 um 09:42 schrieb Christian Corti:
> Gut, dann ziehe ich ganz offiziel mein Angebot zurück, die Lochkarten in
> einem echten Lochkartenleser tutti completti ohne nennenswerten Aufwand
> einzulesen.

Doch, Christian, mache es bitte - ist doch völlig naheliegend und
authentisch Lochkarten mit einem Lochkartenleser einzulesen.

Wenn du den Einlesevorgang zudem mit einem kleinen Filmchen begleiten
würdest, könnten wir hier eine Menge lernen - das wäre wirklich eine
schöne Sache.

Viele Grüße
Michael Kreienberg

[Thomas Koenig]

Diedrich Ehlerding <diedrich....@t-online.de> schrieb:

> Thomas Koenig meinte:
>
>> Und bekommt man heute noch Hardware, auf der Fortran II läuft?
>
> Waren die Fortran-Dialekte nicht aufwärtskompatibel?

Fortran II war vor der ersten Standardisierung auf Fortran 66 und
inkompatibel dazu (auch wenn die Programme damals gezwungenermaßen
noch nicht so groß waren, dass die Übertragung lange gedauert
haben dürfte). Beispielsweise hatte Fortran II noch SINF für
die Sinus-Funktion (das F nach der Funktion zeigte an, dass es
eine REAL-Funktion war).

Das wurde in Fortran IV und daher auch Fortran 66 zu SIN
geändert.

[Hermann Riemann]

Am 21.04.21 um 07:41 schrieb Thomas Koenig:

> Und VS Fortran, für IBM Mainframes, ist auch fest in der
> Vergangenheit verwurzelt - die implementieren nicht mal Fortran 90.

Für das BS2000 wurde Fortran 90 erstellt.
( Adaptiert vom Fujitsu Fortran 90 compiler. )

Nach meiner Einschätzung war die Syntax von Fortan90 irgendwie kaputt.

Im Nachhinein hätte man eine neue Sprache entwickeln sollen
und einen Konverter und das alte Fortan in die neue Sprache
zu übersetzen.

Hermann
der mehr als jeweils 10 Jahre meist freiwillig
verwendete Programmiersprache
erst Fortran (77 ), dann C und dann Python benutzt hat.

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 21.04.21 um 08:26 schrieb Josef Moellers:

>> https://www.tigress.com/hurga/reinigungsdiskette.jpg

> Aua, das tut ja schon beim Hingucken weh!

Irgendwann habe ich den Begriff Span abhebende Datenverarbeitung
gehört.

Hermann
der sich noch an ein Geschenk von IBM für OS/2 einnert,
eine kleiner CD mit dem Rand eines Sägezahns.

--
http://www.hermann-riemann.de

[Thomas Koenig]

Hermann Riemann <nosp...@hermann-riemann.de> schrieb:

> Am 21.04.21 um 07:41 schrieb Thomas Koenig:
>
>> Und VS Fortran, für IBM Mainframes, ist auch fest in der
>> Vergangenheit verwurzelt - die implementieren nicht mal Fortran 90.
>
> Für das BS2000 wurde Fortran 90 erstellt.
> ( Adaptiert vom Fujitsu Fortran 90 compiler. )

Wie ähnlich ist eigentlich BS2000 zu MVS? Ich hatte damals
unter "BS3000" (a.k.a. der Fujitsu-MVS-Klon) gearbeitet.

> Nach meiner Einschätzung war die Syntax von Fortan90 irgendwie kaputt.

Finde ich gar nicht :-)

Ist halt eine mächtige Sprache, in der man viele Fehler aus pre-90
Tagen hervorragend vermeiden kann.

Wer sich mal mit den 30 Argumenten eines typischen Aufrufs einer
wissenschaftlichen Subroutine herumgeschlagen hat, bei denen
ca. 20 Grenzen von irgendwelchen Arrays sind, der weiß das zu
schätzen :-)

> Im Nachhinein hätte man eine neue Sprache entwickeln sollen
> und einen Konverter und das alte Fortan in die neue Sprache
> zu übersetzen.

Was stattdessen gemacht wurde, ist m.E. besser: Die neue
Sprache hat die alte als Teilmenge drin.

> Hermann
> der mehr als jeweils 10 Jahre meist freiwillig
> verwendete Programmiersprache
> erst Fortran (77 ), dann C und dann Python benutzt hat.

F77: Seit Studienzeiten.
C: Etwa genauso lang.
F90/95/2003/... : Seitdem es gfortran gibt.
Python: Kann man mich mit jagen, wenn Skriptsprache, dann
awk oder Perl.

[Hermann Riemann]

Am 21.04.21 um 13:27 schrieb Thomas Koenig:

> Hermann Riemann <nosp...@hermann-riemann.de> schrieb:
>> Am 21.04.21 um 07:41 schrieb Thomas Koenig:
>>
>>> Und VS Fortran, für IBM Mainframes, ist auch fest in der
>>> Vergangenheit verwurzelt - die implementieren nicht mal Fortran 90.
>>
>> Für das BS2000 wurde Fortran 90 erstellt.
>> ( Adaptiert vom Fujitsu Fortran 90 compiler. )
>
> Wie ähnlich ist eigentlich BS2000 zu MVS? Ich hatte damals
> unter "BS3000" (a.k.a. der Fujitsu-MVS-Klon) gearbeitet.

Ich kenne MVS nicht, BS2000 soll sehr unterschiedlich
und einfacher sein als MVS.
Also andere Kommandos, Editoren,
( $EDOR vermisse ich manchmal )
Dateiaufbau ohne Sektorkenntnisse.
( Dateityp SAM ISAM und noch einer für ausführbare Programme)

> Wer sich mal mit den 30 Argumenten eines typischen Aufrufs einer
> wissenschaftlichen Subroutine herumgeschlagen hat, bei denen
> ca. 20 Grenzen von irgendwelchen Arrays sind, der weiß das zu
> schätzen :-)

Für Spezialfälle wie spezielle array Eigenschaften
und extreme Geschwindigkeiten mag Fortran
besser als C sein.
( C verhindert durch Pointer gewisse Optimierungen. )

30 Argumente würde ich in eine Struktur zusammenlegen.
Die lässt sich dann auch problemlos erweitern.

>> Im Nachhinein hätte man eine neue Sprache entwickeln sollen
>> und einen Konverter und das alte Fortan in die neue Sprache
>> zu übersetzen.

> Was stattdessen gemacht wurde, ist m.E. besser: Die neue
> Sprache hat die alte als Teilmenge drin.

was z.B. bei Strukturen ( @ statt .)
die Sprache weniger gut lesbar machte

>> Hermann
>> der mehr als jeweils 10 Jahre meist freiwillig
>> verwendete Programmiersprache
>> erst Fortran (77 ), dann C und dann Python benutzt hat.
>
> F77: Seit Studienzeiten.
> C: Etwa genauso lang.
> F90/95/2003/... : Seitdem es gfortran gibt.
> Python: Kann man mich mit jagen, wenn Skriptsprache, dann
> awk oder Perl.

Machten nicht Informatiker Algol68?
Fortran war für Physiker vorgesehen.

Python ist aktuell meine Haupt Programmiersprache,
weil es sich meist um Texte mit wenig Berechnungen handelt.

Als Nebenprogrammiersprachen sind C ( Grafik )
Javascript im Zusammenhang mit html,
und etwas bash ( 1 bis 2 Zeilen pro Programm )
im Einsatz.

Den Einsatz von Lua oder Julia mag ich nicht ausschließen.
Das ich mal wieder Lisp verwende, auch nicht.

Allerdings Lisp dann mit Prä Prozessor
der mir Python ähnliche Programme in Lisp Klammergebirge
und reversible Großschreibung umsetzt.
Und dann vileich noch ein Python Programm
zur Aufbereitung der Ergebnise,

Das Nächste wäre dann die Editoren.
In BS2000 hab ich EDT vermieden und EDOR verwendet.
Unter windows editor und später xemacs
Unter Linux was xemacs lange mein Haupteditor.
Leider habe ich in xemacs keinen gut lesbaren Font mehr gefunden,)
Jetzt schwanke ich zwischen emacs und kate.
Gelegentlich benutze ich auch vi.

Als Letztes dann interne Dokumentation.
Ich vermeide office.
Stattdessen verwende ich html.
das macht zwar beimdrucken ein paar Probleme,
aber man kann es gut editieren
und auch mit einer Programmiersprache hantieren.

Statt xls Tabellen, Tabellen in html mit table.

Hermann
der dies so seit den 90-ger Jahre macht.

--
http://www.hermann-riemann.de

[Kay Martinen]

Am 21.04.21 um 08:33 schrieb Josef Moellers:

> On 21.04.21 00:48, Michael Kreienberg wrote:
>> Am 20.04.2021 um 09:53 schrieb Josef Moellers:
>>> Mein Brother ADS-2100e hat ohne Probleme erst einmal 10 Karten einlesen

>> Ricoh-Multifunktionsgerät bei 600 dpi in wenigen Stunden einscannen.

> Ich habe auch einen HP OfficeJet mit Einzugsscanner. Nachdem der zum
> zweiten Mal ein Blatt einer BYTE auf eine interne Walze gewickelt hat
> (*), habe ich mir den Brother angeschafft.
>

> (*) Das Teil mußte dann jedes Mal in die Werkstatt. Ich habe keine frei
> verfügbare Beschreibung gefunden, wie man es zerstörungsfrei öffnet.

Durch Beschreiben von /dev/hammer vermutllich. :-)

Ich hab hier einen Canon MX360 mit Einzugscanner. Ab und an zieht der
mal 1-2 Blatt (bei einem Stapel von 7-15 Blatt) versetzt mit rein und
geht dann aber zuverlässig auf Störung weil er Papierstau durch
fehlendes Papier-ende erkennt. Klappe auf, Papier raus ziehen, OK
drücken und neu einlegen, dann kann man weiter scannen. Der Einzug ist
auch im Deckel des Flachbettscanner montiert und darunter ist eine
Separate Scanfläche (also nicht zum Flachbett-teil gehörig).

Mit Kontoauszügen oder Lochkarten hab ich das aber noch nicht probiert.
1. brauche ich nicht und 2. hab ich nicht (in stückzahlen!).

[Josef Moellers]

On 21.04.21 12:20, Hermann Riemann wrote:
> Am 21.04.21 um 07:41 schrieb Thomas Koenig:
>
>> Und VS Fortran, für IBM Mainframes, ist auch fest in der
>> Vergangenheit verwurzelt - die implementieren nicht mal Fortran 90.
>
> Für das BS2000 wurde Fortran 90 erstellt.
> ( Adaptiert vom Fujitsu Fortran 90 compiler. )
>
> Nach meiner Einschätzung war die Syntax von Fortan90 irgendwie kaputt.
>
> Im Nachhinein hätte man eine neue Sprache entwickeln sollen
> und einen Konverter und das alte Fortan in die neue Sprache
> zu übersetzen.

Es gab da mal "Ratfor" "Rational Fortran". Irgendwo habe ich noch ein
Tape damit 'rumliegen.

Josef

[Nils M Holm]

Josef Moellers <josef.m...@invalid.invalid> wrote:
> On 21.04.21 12:20, Hermann Riemann wrote:

>> Im Nachhinein h?tte man eine neue Sprache entwickeln sollen

>> und einen Konverter und das alte Fortan in die neue Sprache

>> zu ?bersetzen.
>
> Es gab da mal "Ratfor" "Rational Fortran". [...]

Und WATFOR (Waterloo FORTRAN) und WATFIV.

--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org

[Thomas Koenig]

Hermann Riemann <nosp...@hermann-riemann.de> schrieb:
> Am 21.04.21 um 13:27 schrieb Thomas Koenig:
>> Hermann Riemann <nosp...@hermann-riemann.de> schrieb:
>>> Am 21.04.21 um 07:41 schrieb Thomas Koenig:
>>>
>>>> Und VS Fortran, für IBM Mainframes, ist auch fest in der
>>>> Vergangenheit verwurzelt - die implementieren nicht mal Fortran 90.
>>>
>>> Für das BS2000 wurde Fortran 90 erstellt.
>>> ( Adaptiert vom Fujitsu Fortran 90 compiler. )
>>
>> Wie ähnlich ist eigentlich BS2000 zu MVS? Ich hatte damals
>> unter "BS3000" (a.k.a. der Fujitsu-MVS-Klon) gearbeitet.
>
> Ich kenne MVS nicht, BS2000 soll sehr unterschiedlich
> und einfacher sein als MVS.

Davon wäre ich ausgegangen, komplizierter geht es kaum :-)

> Also andere Kommandos, Editoren,
> ( $EDOR vermisse ich manchmal )
> Dateiaufbau ohne Sektorkenntnisse.
> ( Dateityp SAM ISAM und noch einer für ausführbare Programme)
>
>> Wer sich mal mit den 30 Argumenten eines typischen Aufrufs einer
>> wissenschaftlichen Subroutine herumgeschlagen hat, bei denen
>> ca. 20 Grenzen von irgendwelchen Arrays sind, der weiß das zu
>> schätzen :-)
>
> Für Spezialfälle wie spezielle array Eigenschaften
> und extreme Geschwindigkeiten mag Fortran
> besser als C sein.

> ( C verhindert durch Pointer gewisse Optimierungen. )

Nicht nur das, auch mehrdimensionale Arrays waren nicht
wirklich im Fokus der Sprache.

> 30 Argumente würde ich in eine Struktur zusammenlegen.
> Die lässt sich dann auch problemlos erweitern.

Das bezieht sich vor allem auf die Arraygrenzen. Angenommen,
man hat eine Prozedur, die drei zweidimensionale Arrays
verwustelt, mit unterschiedlichen Größen. Man
könnte dazu

subroutine foo(a,b,c)
real, dimension(:,:) :: a, b, c

schreiben, und dann mit

i = size(a,1)

die Größe des Arrays a in der 1. Richtung abfragen.

Oder man macht es wie in altem FORTRAN und schreibt

SUBROUTINE FOO(A,B,C,NA1,NA2,NB1,NB2,NC1,NC2)
REAL A(NA1,NA2), B(NB1,NB2), C(NC1,NC2)

und hat gleich acht Argumente, wo drei reichen würden.

Und in C sieht das auch nicht viel besser aus, mal davon abgesehen,
dass C keinen vernünftigen Datentyp für zweidimensionale
Arrays hat.

[Thomas Koenig]

Josef Moellers <josef.m...@invalid.invalid> schrieb:

Geschrieben von Brian Kernighan (ja, der "K" aus "K&R" von C).

Der konnte auch ganz gut FORTRAN (auch wenn er die Grenzen der
damaligen Sprache nur zu gut kannte) und hatte unter anderem eine
Version des "runoff" - Textformatierers in FORTRAN geschrieben,
um seine Doktorarbeit am Computer ausdrucken zu können. War damals
was total Neues.

Oder ist das eine andere Version?

[Rafael Deliano]

> https://homepages.uni-regensburg.de/~hep09515/dafc/lochkarte.jpg

Lochkartenlesegerät als Hack selberbauen ?
Karte hat leider auch Leerspalten.
Aber dann sind es eben 2x12 Fotodioden geeignet
auf Leiterplatte angeordnet und in A/D-Wandlereingänge
eines Controllers eingelesen. Während die Lochkarte auf
schief gestellter Rutsche drübergleitet.
Und der Controller die quantisierten Binärdaten über
RS232 ausgibt.
Hat vermutlich auch keine Parity. Man kann aber jede
Karte 3x durchlaufen lassen um die Fehlersicherheit zu
verbessern.
Ich hätte wenig Probleme das Ding zu bauen.
Falls Interesse mail schicken.

MfG JRD

[Andreas Kohlbach]

On Wed, 21 Apr 2021 10:28:39 +0200, Michael Kreienberg wrote:
>
> Am 21.04.2021 um 09:42 schrieb Christian Corti:
>> Gut, dann ziehe ich ganz offiziel mein Angebot zurück, die Lochkarten in
>> einem echten Lochkartenleser tutti completti ohne nennenswerten Aufwand
>> einzulesen.
>
> Doch, Christian, mache es bitte - ist doch völlig naheliegend und
> authentisch Lochkarten mit einem Lochkartenleser einzulesen.

Oder beide Möglichkeiten, wenn auf beiden Seiten Zeit und Lust dazu
besteht. Wäre interessant zu sehen,welche (und ob überhaupt) Unterschiede
es in den Ergebnissen gibt.

> Wenn du den Einlesevorgang zudem mit einem kleinen Filmchen begleiten
> würdest, könnten wir hier eine Menge lernen - das wäre wirklich eine
> schöne Sache.

Ja bitte! Nicht nur für hier. Archive.org und Youtube freuen sich. Ich
habe Accounts bei beiden und könnte das hochladen, wenn keiner der
Beteiligten Accounts dort hat.
--
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0

[Kay Martinen]

Am 21.04.21 um 20:15 schrieb Andreas Kohlbach:

> On Wed, 21 Apr 2021 12:24:57 +0200, Hermann Riemann wrote:
>>
>> Irgendwann habe ich den Begriff Span abhebende Datenverarbeitung
>> gehört.
>

> In meiner Ausbildung zum "Maschinenschlosser" Ende in den 80ern war das
> Prunkstück in der Abteilung eine einzelne CNC-Drehbank. Dort hätte der
> Begriff wohl gepasst. :-D

Originär kenne ich den obigen Begriff nur von Festplatten. Bei einem
Headcrash!

> Jeder Azubi hat die bewundert. Der Rest der manuellen Drehbänke sah schon
> in den 80ern sehr alt aus. Einer fragte einen Ausbilder mal, wie alt die
> seien. Er meinte trocken "Als man die bekam, hat man erst die Hakenkreuze
> von ihnen entfernen müssen".
>

Als ich meinen Ersten Lehrlings-Vertrag bekam hatte der Chef auch so ein
Unikum, mit Manueller Drehzahländerung durch Riemenwechsel (aber ohne
Dampfantrieb!) Das Teil war Stabil. Und Sauschwer!

[Kay Martinen]

Am 21.04.21 um 16:19 schrieb Nils M Holm:

> Josef Moellers <josef.m...@invalid.invalid> wrote:
>> On 21.04.21 12:20, Hermann Riemann wrote:
>>> Im Nachhinein h?tte man eine neue Sprache entwickeln sollen
>>> und einen Konverter und das alte Fortan in die neue Sprache
>>> zu ?bersetzen.

Hat das denn mit CP/M Programmen für DOS funktioniert?
Da sollte das doch auch soooo einfach sein.

>> Es gab da mal "Ratfor" "Rational Fortran". [...]
>
> Und WATFOR (Waterloo FORTRAN) und WATFIV.
>

Aha. Und der Papst programmiert in VATICAL 2.0 :-)

Oder ist das ernst gemeint? Wer nennt eine Sprache nach einem
Schlachtfeld (Mein BASIC ist besser als deins, Ätschbätsch)?

[Kay Martinen]

Am 21.04.21 um 20:21 schrieb Andreas Kohlbach:

> On Wed, 21 Apr 2021 14:51:15 +0200, Kay Martinen wrote:
>>
>> Ich hab hier einen Canon MX360 mit Einzugscanner. Ab und an zieht der
>> mal 1-2 Blatt (bei einem Stapel von 7-15 Blatt) versetzt mit rein und
>> geht dann aber zuverlässig auf Störung weil er Papierstau durch
>> fehlendes Papier-ende erkennt. Klappe auf, Papier raus ziehen, OK
>> drücken und neu einlegen, dann kann man weiter scannen. Der Einzug ist
>> auch im Deckel des Flachbettscanner montiert und darunter ist eine
>> Separate Scanfläche (also nicht zum Flachbett-teil gehörig).
>

> Hier bei meinem schon fast folkloristischem HP 6600 auch so, den ich vom
> Bürgersteig (war aber kein Curb Pickup ;-) fischte;

Ja, hier fahren zu bestimmten Zeiten auch einige Fremde in der gegend
herum und laden sich ihr Auto voll mit sachen die draußen rum stehen.
Man könnte es "Analoges eBay" nennen. Immer wenn Sperrmüllsammlung ist!


> der Drucker erkennt
> den Stau und versucht den Druckkopf aus dem Weg zu fahren. Zeigt dann an,
> man sollte die Tür öffnen und das Papier raus ziehen. Ging hier jedes Mal
> gut.

Kommt mir bekannt vor, von einem Officejet K60 (oder so ähnlich) den wir
damals in der Familie hatten. Der hatte auch so eine art Automatischen
Ausrichtungstest bei neuen Patronen. Erst druckte er, dann fiepte er
etwas rum und man sah den Druckkopf hin und her wedeln, dabei waren
beidseitig kleine Blaue Lichtpunkte auf dem Papier zu sehen. Und dann...
war er auch schon fertig. "Faszinierend" würde Mr. Spock sagen. :-)

Hab ich seither bei keinem anderen Drucker gesehen. War wohl zu einfach
für $Benutzer. ;)

[Kay Martinen]

Am 21.04.21 um 17:58 schrieb Rafael Deliano:

>> https://homepages.uni-regensburg.de/~hep09515/dafc/lochkarte.jpg
>
> Lochkartenlesegerät als Hack selberbauen ?

Und ich wollt' grad vorschlagen: Hat nicht einer einen 3D-Drucker und
kann einen Leser damit bauen? :-)

>   Karte hat leider auch Leerspalten.
> Aber dann sind es eben 2x12 Fotodioden geeignet
> auf Leiterplatte angeordnet und in A/D-Wandlereingänge

Analog? Wie umständlich bei Binären Kodierungen (Loch, Kein Loch). Das
kann man doch (Schmidt-Trigger) gleich Digital machen und parallel einlesen.

Ich würde da auch eher in Richtung Reflex-Lichtschranke denken (Pro
Lochreihe eine) oder als eine art Durchzug-streifen mit einem Bügel
drüber hinter dem eine Lichtquelle liegt - und die Fotodioden als Zeile
dahinter. Je nach dem was passt mit den Lochabständen.

Dazu einen Schrittmotor der die Karte immer eine Spalte weiter durch
schiebt. Offenbar gibt es keine Feste Randlochung wie bei Endlospapier,
sonst hätte ich dort noch ein Stachelrad anbringen wollen würden das den
Transport überwacht (Papierstau erkennung).

> eines Controllers eingelesen. Während die Lochkarte auf
> schief gestellter Rutsche drübergleitet.

Wie meinst du das gleiten? Ich würde es horizontal/Seitlich über eine
Schrägstehende Fläche schieben. Das dürfte eher die klassische Bauart
sein und ermöglicht außerdem einen ganzen Stapel karten von dem dann
jeweils die unterste eingezogen werden müsste.

> Und der Controller die quantisierten Binärdaten über
> RS232 ausgibt.

Grob überschlagen brauchst du 12 Digitale Eingänge für die Daten, 1 oder
2 für Kontrollen (Kartenstapel leer, Auswurf blockiert=Kartenstau) und
mindesten einen Ausgang für den Impuls an die Schrittmotor-Steuerung.
Und dazu ein Programm das nicht nur alles ansteuert sondern auch noch
die DCE-DTE Verbindung betreibt. Und ein Protokoll wäre wohl auch noch
hilfreich. Z.b. auf "ATR" eine Karte einlesen und die Daten zurück
liefern und mit einem "OK" o.a. Statuscode quittieren. "ATE" für Eject,
also x Schritte bis Kartenstapel leer gemeldet oder ein Sensor den
Anfang der nächsten Karte zeigt.

Ist jetzt nur mal wild drauf los theoretisiert da ich solche Geräte nur
von Photos kenne. Pers. Bekannt sind mir nur Elektromechanische
Lochstreifen Stanzer und Leser. Und auch die nur aus einer T100 die ich
mal besaß. 5Bit CCITT ist da doch ein bisschen rudimentärer, und wurde
komplett mechanisch abgetastet.

[Hermann Riemann]

Am 21.04.21 um 16:52 schrieb Thomas Koenig:

>> Für Spezialfälle wie spezielle array Eigenschaften
>> und extreme Geschwindigkeiten mag Fortran
>> besser als C sein.

>> ( C verhindert durch Pointer gewisse Optimierungen. )

> Nicht nur das, auch mehrdimensionale Arrays waren nicht
> wirklich im Fokus der Sprache.

Korrekt.
Beispiel Bildausschnitt

int pixel,*bildstart;

pixel =bildstart+x+y*bildbreite;

..

> Das bezieht sich vor allem auf die Arraygrenzen. Angenommen,
> man hat eine Prozedur, die drei zweidimensionale Arrays

> verwurstelt, mit unterschiedlichen Größen. Man

> könnte dazu
>
> subroutine foo(a,b,c)
> real, dimension(:,:) :: a, b, c
>
> schreiben, und dann mit
>
> i = size(a,1)
> die Größe des Arrays a in der 1. Richtung abfragen.

In C geht das direkt nur bei C-strings.
Andernfalls müsste man derartige Verwaltung
"zu Fuß" erledigen.

Fortran kann also endlich auf Descriptor Informationen
teilweise zugreifen.

Eine Frage ist jetzt der Sprachmix.
C könnte vermutlich Fortran array verarbeiten,
weil dazu nur die Anfangsadresse benötigt wird,
Fortran würde einen bei C nicht direkt
vorhandenen Descriptor brauchen,
den C erst noch ( mittels #define ?)
basteln müsste.

Hermann
der in C statt Indices meist pointer verwendet.

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 21.04.21 um 15:56 schrieb Josef Moellers:

Ich habe mal etwas von einem BayFOR gehört
bei dem lediglich die Schlüsselwörter
ins bayerische übersetzt wurden.

Ich denke eher an einen Syntax Übersetzer.

z.B.:
Quelle wie Python:

if a<0: a=-a

nach C
if (a<0) a=-a;
weitgehend lesbar übersetzt

In anderen Sprachen ähnlich.

Wenn kein Unterschied zwischen Groß und
Kleinbuchstaben ist ( z.B. lisp )
vielleicht ein _ Trick

Viele Sprachen habe sich an C angelehnt.
Für mich wären aktuell Python ein Vorbild.

Der nächste Schritt wären utf-Zeichen.

Warum nicht ≠ statt != <> .. ?
Wie man es nicht machen sollte,
habe ich in Julia gesehen.

Ein Hindernis auf diesen Weg sind Tastatur Schnittstellen,
Ich kenne keine Konvention,
mit der man utf-Zeichen > 7 Bit unabhängig
von Tastaturtreiber eingeben könnte.

Vielleicht könnte folgendes gehen:
Etwa die ASCII Wert Interpretationen:

DC1 11 1 byte utf folgt
DC2 12 2 byte utf folgt
DC3 13 reserviert u.a.für diakritische Zeichen
DC4 14 4 byte utf folgt

Hermann
auch an Rückübersetzung
von "Fremdsprachen"
in persönlich bekannte Sprachen denkend.

--
http://www.hermann-riemann.de

[Diedrich Ehlerding]

Kay Martinen meinte:

>>> Irgendwann habe ich den Begriff Span abhebende Datenverarbeitung
>>> gehört.

[...]

>
> Originär kenne ich den obigen Begriff nur von Festplatten. Bei einem
> Headcrash!

Dafür kenne ich den auch, schon seit langem.

[Guido Grohmann]

Diedrich Ehlerding schrieb:

> Kay Martinen meinte:
>
>>>> Irgendwann habe ich den Begriff Span abhebende Datenverarbeitung
>>>> gehört.
> [...]
>>
>> Originär kenne ich den obigen Begriff nur von Festplatten. Bei einem
>> Headcrash!
>
> Dafür kenne ich den auch, schon seit langem.
>

Ich kenne das noch für 5,25" Disketten, die danach eine kreisrunde
(halb)durchsichtige Spur hatten. Da war wohl Dreck am Magnetkopf oder
auf der Diskette.

Guido

[Thomas Koenig]

Hermann Riemann <nosp...@hermann-riemann.de> schrieb:

> Eine Frage ist jetzt der Sprachmix.
> C könnte vermutlich Fortran array verarbeiten,
> weil dazu nur die Anfangsadresse benötigt wird,
> Fortran würde einen bei C nicht direkt
> vorhandenen Descriptor brauchen,
> den C erst noch ( mittels #define ?)
> basteln müsste.

Fortran hat seit der 2003-Version der Norm eine standardisierte
Schnittstelle zu C. Man kann da externe C-Funktionen über
ein INTERFACE deklarieren und dann aufrufen, hier z.B. für
die C-Library-Routine qsort:

use iso_c_binding

interface
subroutine myqsort(array,elem_count,elem_size,compare) &
bind(C,name="qsort")
import
type(c_ptr),value :: array
integer(c_size_t),value :: elem_count
integer(c_size_t),value :: elem_size
type(c_funptr),value :: compare
end subroutine myqsort
end interface

Genauso kann man eine Fortran-Prozedur so schreiben, dass
sie von C aus aufgerufen werden kann, ebenfalls mit BIND(C).

Und für die Deskriptoren gibt es mittlerweile auch eine
standardisierte Lösung: Die Header-Datei ISO_Fortran_binding.h,
seit neuestem in der Norm, spezifiziert einen u.a. einen Typ
CFI_cdesc_t und entsprechende Funktionen, um darauf zuzugreifen.

Ist in gfortran schon drin, kann man also verwenden.

[Stefan Froehlich]

On Thu, 22 Apr 2021 06:50:10 Hermann Riemann wrote:
> Warum nicht ≠ statt != <> .. ?

Weil mein Keyboard keine ≠-Taste hat und ich mir nicht
noch eine Tonne Shortcuts merken möchte.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Neue Schleimer verdient Bayern: Stefan!
(Sloganizer)

[Peter Heitzer]

Halte ich für keine gute Idee, obwohl es in AFAIK Java bereits möglich ist.
Ich will keine Umlaute in Bezeichnern und auch keine Zeichen aus
nichtlateinischen Alphabeten. Lediglich die Einschränkung, daß ein Variablenname
nicht mit einer Ziffer beginnen darf, wäre zu überdenken.
Ich hielte z.B. 100mil=2.54 für lesbarer als mil100=2.54.
(100 mil ist der Abstand zweier Beinchen eines DIP Packages)



--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de

[Nils M Holm]

Kay Martinen <use...@martinen.de> wrote:
> Am 21.04.21 um 16:19 schrieb Nils M Holm:
>> Josef Moellers <josef.m...@invalid.invalid> wrote:
>>> On 21.04.21 12:20, Hermann Riemann wrote:
>>>> Im Nachhinein h?tte man eine neue Sprache entwickeln sollen
>>>> und einen Konverter und das alte Fortan in die neue Sprache
>>>> zu ?bersetzen.
>

> Hat das denn mit CP/M Programmen f?r DOS funktioniert?

> Da sollte das doch auch soooo einfach sein.
>
>>> Es gab da mal "Ratfor" "Rational Fortran". [...]
>>
>> Und WATFOR (Waterloo FORTRAN) und WATFIV.
>
> Aha. Und der Papst programmiert in VATICAL 2.0 :-)
>
> Oder ist das ernst gemeint? Wer nennt eine Sprache nach einem

> Schlachtfeld (Mein BASIC ist besser als deins, ?tschb?tsch)?

University of Waterloo, Canada, nicht Waterloo im Koenigreich
der Vereinigten Niederlande. :)

[Peter Heitzer]

Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
>On Thu, 22 Apr 2021 06:50:10 Hermann Riemann wrote:
>> Warum nicht ≠ statt != <> .. ?

>Weil mein Keyboard keine ≠-Taste hat und ich mir nicht
>noch eine Tonne Shortcuts merken möchte.

Ich hatte vor vielen Jahren mal am Mac mit MPW kleinere Sachen programmiert.
In dem Makefile musste man mit einer Handvoll spezieller Zeichen arbeiten,
die man meist nicht auf der Tastatur aufgedruckt fand. Da ist mir $< und
$^ schon lieber.

[Peter Heitzer]

Wenn es meine Lochkarten wären, täte ich sowas vermutlich.
Man kann auch die Karte senkrecht in den Leser stellen und den Lesekopf
positionieren. Das dürfte mechanisch einfacher sein, z.B. mit einer
Gewindestange.