Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #544020 > unrolled thread

Reaktivierung von COBOL-Rentnern

Back to article view | Back to ger.ct

Contents

  Reaktivierung von COBOL-Rentnern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-02-19 18:16 +0100
    Re: Reaktivierung von COBOL-Rentnern Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-02-19 20:34 +0100
      Re: Reaktivierung von COBOL-Rentnern Andreas Bockelmann <xotzil@gmx.de> - 2022-02-19 20:46 +0100
      Re: Reaktivierung von COBOL-Rentnern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-02-20 07:16 +0100
        Re: Reaktivierung von COBOL-Rentnern Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-02-20 08:13 +0100
          Re: Reaktivierung von COBOL-Rentnern Martin Ebert <mx300@gmx.net> - 2022-02-20 08:27 +0100
            Re: Reaktivierung von COBOL-Rentnern Wolfgang Kynast <wky@gmx.de> - 2022-02-20 11:25 +0100
          Re: Reaktivierung von COBOL-Rentnern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-02-20 10:46 +0100
            Re: Reaktivierung von COBOL-Rentnern Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-02-20 11:13 +0100
              Re: Reaktivierung von COBOL-Rentnern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-02-20 11:19 +0100
        Re: Reaktivierung von COBOL-Rentnern Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-02-20 11:29 +0100
          Re: Reaktivierung von COBOL-Rentnern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-02-20 11:43 +0100
            Re: Reaktivierung von COBOL-Rentnern Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-02-20 12:17 +0100
    Re: Reaktivierung von COBOL-Rentnern Herwig <herwig.huener@t-online.de> - 2022-02-19 15:38 -0800
      Re: Reaktivierung von COBOL-Rentnern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-02-20 07:28 +0100
        Re: Reaktivierung von COBOL-Rentnern Dr. Joachim Neudert <neudert@5sl.org> - 2022-02-20 06:45 +0000
        Re: Reaktivierung von COBOL-Rentnern Dr. Joachim Neudert <neudert@5sl.org> - 2022-02-20 06:49 +0000
          Re: Reaktivierung von COBOL-Rentnern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-02-20 10:40 +0100
        Re: Reaktivierung von COBOL-Rentnern Herwig <herwig.huener@t-online.de> - 2022-02-20 05:07 -0800
          Re: Reaktivierung von COBOL-Rentnern Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-02-20 15:27 +0100
            Re: Reaktivierung von COBOL-Rentnern "Wendelin Uez" <wuez@online.de> - 2022-02-21 17:56 +0100

Page 1 of 2  [1] 2  Next page →

#544020 — Reaktivierung von COBOL-Rentnern

https://www.heise.de/news/Fujitsu-Ein-offener-und-anpassungsfaehiger-Mainframe-Dino-stirbt-nicht-aus-6495833.html?seite=all

Es geht um Fujitsu und BS2000

In den USA mussten Banken oder auch Behörden schon über 70-jährige 
COBOL-Rentner reaktivieren,

Hermann
    dessen seit 1978 geschriebener code noch angeboten wird.

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

[toc] | [next] | [standalone]

#544027

Hermann Riemann meinte:

> In den USA mussten Banken oder auch Behörden schon über 70-jährige
> COBOL-Rentner reaktivieren,

Ja, war schon beim Y2K-Hype so. (Hoffst du etwa auf ein gutes Angeboit, 
deine Rente aufbessern zu dürfen?)

Warte mal ab - 2038 platzt die Uhr der 32bit-Systeme.  Ich wette, dass 
da dann noch etliche Systeme und Anwendungen  - insbesondere von 
Mainframes quick+dirty anno 1999 mal eben schnell auf  "offene Systeme"¹ 
portierte Anwendungen, die schon damals keiner mehr verstand und die 
nach der Methode Reimdichoderichfressdich konvertiert wurden - ein 
Problem bekommen. Und dann sind die alten Cobol-Rentner nicht mehr 
reaktivierbar ...

¹F: warum heißen die "offene Systeme"? 
 A: Es ist offen, was an denen so gut ist. 
-- 
 gpg-Key (DSA 1024) D36AD663E6DB91A4
 fingerprint = 2983 4D54 E00B 8483 B5B8  C7D1 D36A D663 E6DB 91A4
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#544028

Diedrich Ehlerding schrieb:
> Hermann Riemann meinte:
> 
>> In den USA mussten Banken oder auch Behörden schon über 70-jährige
>> COBOL-Rentner reaktivieren,
> 
> Ja, war schon beim Y2K-Hype so.

In weniger als 18 Jahren geht es ja wieder los ;-)



-- 
  Mit freundlichen Grüßen
    Andreas Bockelmann

[toc] | [prev] | [next] | [standalone]

#544043

Am 19.02.22 um 20:34 schrieb Diedrich Ehlerding:
> Hermann Riemann meinte:
> 
>> In den USA mussten Banken oder auch Behörden schon über 70-jährige
>> COBOL-Rentner reaktivieren,
> 
> Ja, war schon beim Y2K-Hype so. (Hoffst du etwa auf ein gutes Angebot,
> deine Rente aufbessern zu dürfen?)

Eher nicht aber:
Pierer & Co haben vorgesorgt:
Die haben Siemens BS2000 nach Fujitsu verkauft,
um Betriebsrentenansprüche von Mitarbeiter loszuwerden.
Fujitsu zahlt keinen Inflationsausgleich mehr,
so dass irgendwann die Betriebsrenten nicht mehr ausreichen,
sofern man lange? genug lebt.

> Warte mal ab - 2038 platzt die Uhr der 32bit-Systeme.

Auf Unix Systeme.
Ich bin nicht sicher ob mainframes ihre Urzeit dezimal
haben so dass erst 31.12.9999 da ein Problem auftaucht.
Etwas sf:
Was vielleicht passieren kann, weil computer
vielleicht besser an Umweltveränderungen angepasst werden
können als Menschen, sie aber wie Menschen Probleme
mit alter software ( BIOS.. statt genetischer code ) haben.

> Ich wette, dass
> da dann noch etliche Systeme und Anwendungen  - insbesondere von
> Mainframes quick+dirty anno 1999 mal eben schnell auf  "offene Systeme"¹
> portierte Anwendungen, die schon damals keiner mehr verstand und die
> nach der Methode Reimdichoderichfressdich konvertiert wurden - ein
> Problem bekommen.

Du meinst Adapter, bei denen man replace (19,20) gemacht hat?
(Oder früher: if Zahl < 70 dann Jahr Zahl+2000 sonst Jahr=Zahl+1900)

 > Und dann sind die alten Cobol-Rentner nicht mehr
 > reaktivierbar ..

https://www.deutschlandfunk.de/tolle-idee-was-wurde-daraus-kryokonservierung-verspricht-100.html
..


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

[toc] | [prev] | [next] | [standalone]

#544047

On 2/20/22 07:16, Hermann Riemann wrote:
> 
> Du meinst Adapter, bei denen man replace (19,20) gemacht hat?
> (Oder früher: if Zahl < 70 dann Jahr Zahl+2000 sonst Jahr=Zahl+1900)

Letzteres gäbe einigen Ärger mit den Geburtstagen vieler hier. So 
einfach hat man sich das hoffentlich nicht gemacht.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#544049

Am 20.02.22 um 08:13 schrieb Gerrit Heitsch:
> On 2/20/22 07:16, Hermann Riemann wrote:

>> Du meinst Adapter, bei denen man replace (19,20) gemacht hat? (Oder
>> früher: if Zahl < 70 dann Jahr Zahl+2000 sonst Jahr=Zahl+1900)

> Letzteres gäbe einigen Ärger mit den Geburtstagen vieler hier. So
> einfach hat man sich das hoffentlich nicht gemacht.

Bei vernünftigen alten Cobol-Programmen hat das Jahr nur eine
Stelle, derzeit "2". Und von denen laufen noch so einige produktiv,
bei Banken und Versicherungen. Zum Teil ohne Quelltext.

An meinen lieben Freund Dietz:
Da Du gleich über mich herfällst: Du hat genau ein Problem:
Du kannst nicht zuhören. - Und nachdem Du hier das Rumpel-
stilzchen gibst, besteht auch nicht die Gefahr, dass ich es
Dir auch nur vertraulich erkläre.

[toc] | [prev] | [next] | [standalone]

#544104

On Sun, 20 Feb 2022 08:27:16 +0100, "Martin Ebert" posted:

>Am 20.02.22 um 08:13 schrieb Gerrit Heitsch:
>> On 2/20/22 07:16, Hermann Riemann wrote:
>
>>> Du meinst Adapter, bei denen man replace (19,20) gemacht hat? (Oder
>>> früher: if Zahl < 70 dann Jahr Zahl+2000 sonst Jahr=Zahl+1900)
>
>> Letzteres gäbe einigen Ärger mit den Geburtstagen vieler hier. So
>> einfach hat man sich das hoffentlich nicht gemacht.
>
>Bei vernünftigen alten Cobol-Programmen hat das Jahr nur eine
>Stelle, derzeit "2". 

Universalgenie: weiß von allem nichts.

[toc] | [prev] | [next] | [standalone]

#544085

Am 20.02.22 um 08:13 schrieb Gerrit Heitsch:
> On 2/20/22 07:16, Hermann Riemann wrote:
>>
>> Du meinst Adapter, bei denen man replace (19,20) gemacht hat?
>> (Oder früher: if Zahl < 70 dann Jahr Zahl+2000 sonst Jahr=Zahl+1900)
> 
> Letzteres gäbe einigen Ärger mit den Geburtstagen vieler hier. So 
> einfach hat man sich das hoffentlich nicht gemacht.

Damals vielleicht 20 statt 70?

Man könnte die Grenze ja auf aktuelles Jahr Modulo 100 stellen.

Hermann
    der mal etwas von einem Einberufungsbefehl
    für einen 118 Jährigen gelesen hat.

p.s. Bei Lebensdaten wäre derzeit noch Modulo 128 (2**5) angebracht,
da derzeit keine Technik bekannt ist,
  bei Menschen diese Grenze zu durchbrechen.

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

[toc] | [prev] | [next] | [standalone]

#544097

On 2/20/22 10:46, Hermann Riemann wrote:
> Am 20.02.22 um 08:13 schrieb Gerrit Heitsch:
>> On 2/20/22 07:16, Hermann Riemann wrote:
>>>
>>> Du meinst Adapter, bei denen man replace (19,20) gemacht hat?
>>> (Oder früher: if Zahl < 70 dann Jahr Zahl+2000 sonst Jahr=Zahl+1900)
>>
>> Letzteres gäbe einigen Ärger mit den Geburtstagen vieler hier. So 
>> einfach hat man sich das hoffentlich nicht gemacht.
> 
> Damals vielleicht 20 statt 70?
> 
> Man könnte die Grenze ja auf aktuelles Jahr Modulo 100 stellen.
> 
> Hermann
>     der mal etwas von einem Einberufungsbefehl
>     für einen 118 Jährigen gelesen hat.
> 
> p.s. Bei Lebensdaten wäre derzeit noch Modulo 128 (2**5) angebracht,

Meinst du nicht 2**7?

  Gerrit

[toc] | [prev] | [next] | [standalone]

#544100

Am 20.02.22 um 11:13 schrieb Gerrit Heitsch:
> On 2/20/22 10:46, Hermann Riemann wrote:
>> Am 20.02.22 um 08:13 schrieb Gerrit Heitsch:
>>> On 2/20/22 07:16, Hermann Riemann wrote:
>>>>
>>>> Du meinst Adapter, bei denen man replace (19,20) gemacht hat?
>>>> (Oder früher: if Zahl < 70 dann Jahr Zahl+2000 sonst Jahr=Zahl+1900)
>>>
>>> Letzteres gäbe einigen Ärger mit den Geburtstagen vieler hier. So 
>>> einfach hat man sich das hoffentlich nicht gemacht.
>>
>> Damals vielleicht 20 statt 70?
>>
>> Man könnte die Grenze ja auf aktuelles Jahr Modulo 100 stellen.
>>
>> Hermann
>>     der mal etwas von einem Einberufungsbefehl
>>     für einen 118 Jährigen gelesen hat.
>>
>> p.s. Bei Lebensdaten wäre derzeit noch Modulo 128 (2**5) angebracht,
> 
> Meinst du nicht 2**7?

ok, mal wieder unachtsam gewesen.

Hermann
    dessen symbolischer Logikanalysator sich noch
    in der Entwurfsphase befindet.

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

[toc] | [prev] | [next] | [standalone]

#544105

Hermann Riemann meinte:

>> Warte mal ab - 2038 platzt die Uhr der 32bit-Systeme.
> 
> Auf Unix Systeme.
> Ich bin nicht sicher ob mainframes ihre Urzeit dezimal
> haben 

Natürlich nicht; die haben auch eine Hardware-Uhr, die  in kleinen 
Einheiten (Seklundenbruchteilen) tickt. Und die kann man im 
nichtprivilegierten Modus abfragen. 

> so dass erst 31.12.9999 da ein Problem auftaucht.

Soweit du von IBM/370, /390, /z-Systemen redest, schon eher, aber 
jedenfalls erst etwas später als die 32bit-Unixe:

<https://groups.google.com/g/bit.listserv.ibm-main/c/qWWkdociQMQ>

| John Gilmore| 
| 31.01.12
|
| Regrettably, the current PrOp in not specific about the time horizon
| of the STCK instruction.
| 
| At 23:58:43 on 17 September 2042 the IBM mainframe TOD clock, 64-bit
| STCK value overflows.
| 
| STCKE values do not have this defect. Effectively, they are 14-byte,
| 8 x 14 = 112-bit [unsigned] values. (The rightmost two bytes of the
| full sixteen-byte value ensure uniqueness when there are multiple TOD
| clocks in an environment, but they are not part of the TOD value
| proper.) 

Mit anderen Worten, die Hardware-Uhr dieser Systeme wäre inzwischen kein 
Problem mehr - aber  ich wette, dass auch 2042 noch irgendwelche Uralt-
Programme herumdümpeln, die die "kurze" Hardware-Uhr per STCK-Befehl 
abfragen ... 
-- 
 gpg-Key (DSA 1024) D36AD663E6DB91A4
 fingerprint = 2983 4D54 E00B 8483 B5B8  C7D1 D36A D663 E6DB 91A4
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#544107

Am 20.02.22 um 11:29 schrieb Diedrich Ehlerding:
> Mit anderen Worten, die Hardware-Uhr dieser Systeme wäre inzwischen kein
> Problem mehr - aber  ich wette, dass auch 2042 noch irgendwelche Uralt-
> Programme herumdümpeln, die die "kurze" Hardware-Uhr per STCK-Befehl
> abfragen ...


Wie ist das eigentlich bei den Zeitstempel in den Dateien?

Hermann
    bei Ausgrabungen aus alten Sicherungen Probleme vermutend.

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

[toc] | [prev] | [next] | [standalone]

#544110

Hermann Riemann meinte:

>> Mit anderen Worten, die Hardware-Uhr dieser Systeme wäre inzwischen
>> kein Problem mehr - aber  ich wette, dass auch 2042 noch irgendwelche
>> Uralt- Programme herumdümpeln, die die "kurze" Hardware-Uhr per
>> STCK-Befehl abfragen ...
> 
> 
> Wie ist das eigentlich bei den Zeitstempel in den Dateien?

Genauso wie beim Y2K - wenn da ein kurzer Zeitstempel in welchem Format 
auch immer (dezimal mit zweistelliger Jahreszahl wie anno Y2K, in 
Mikrosekunden seit $IRGENDWANN als 32- oder 64-bit-Zahl, wie auch immer)  
noch in irgendwelchen Dateien oder Datenbakfeldern steht und nach dem 
Stichtag, an dem das Format überläuft,  noch verarbeitet werden soll, 
kann das zu Problemen führen. Jegliche Arithmetik mit solchen  
Zeitstempeln, jeglicher Vergleich auf > oder <  von 
Datümern/Zeitstempelnn von vor und nach dem Stichtag führt zu Problemen; 
allerdings unabhängig davon, ob das wieder eingespielte Sicherungen sind 
oder durchaus aktuelle Datebankinhalte. Insofern muss man natürlich 
eigentlich  schon $RECHTLICHE_AUFBEWAHRUNGSFRIST (zB 7 Jahre) vor dem 
Stichtag mit der Beseitigung solcher Altlasten fertig sein. 
-- 
 gpg-Key (DSA 1024) D36AD663E6DB91A4
 fingerprint = 2983 4D54 E00B 8483 B5B8  C7D1 D36A D663 E6DB 91A4
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#544034

2022-02-20 00:39:00 +0100

> ...

> Es geht um Fujitsu und BS2000 
> 
> In den USA mussten Banken oder auch Behörden schon über 70-jährige 
> COBOL-Rentner reaktivieren, 

Dass das passiert, darauf warte ich schon lange.

Ein völlig unverfänglicher Tipp: Man sehe sich auf der WebSite
von Fujitsu und BS2000 die VersionsAngaben der verschiedenen
Produkte an und verfolge das über die Zeit. Welche Schlüsse
kann man daraus wohl ziehen?

Herwig

[toc] | [prev] | [next] | [standalone]

#544044

Am 20.02.22 um 00:38 schrieb Herwig:

>> Es geht um Fujitsu und BS2000
>>
>> In den USA mussten Banken oder auch Behörden schon über 70-jährige
>> COBOL-Rentner reaktivieren,
> 
> Dass das passiert, darauf warte ich schon lange.

Zu lange im monotonen Flusi gesessen?

> Ein völlig unverfänglicher Tipp: Man sehe sich auf der WebSite
> von Fujitsu und BS2000 die VersionsAngaben der verschiedenen
> Produkte an und verfolge das über die Zeit.

Oder schaut

https://www.fujitsu.com/de/products/computing/servers/mainframe/bs2000/software/programming/

Pascal aber kein Python.

 > Welche Schlüsse kann man daraus wohl ziehen?

Zuverlässige alte software?

Hermann
    vermutend, dass ein Netz aus 32 Bit Rechner
    für viele Anwendungen schneller und Energie sparender ist,
    als 64 bit Systeme mit hohen Taktfrequenzen.

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

[toc] | [prev] | [next] | [standalone]

#544045

Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
> Am 20.02.22 um 00:38 schrieb Herwig:
> 
>>> Es geht um Fujitsu und BS2000
>>> 
>>> In den USA mussten Banken oder auch Behörden schon über 70-jährige
>>> COBOL-Rentner reaktivieren,
>> 
>> Dass das passiert, darauf warte ich schon lange.
> 
> Zu lange im monotonen Flusi gesessen?

Hermann! Et tu, Brutus?





-- 
please forgive my iPhone typos

[toc] | [prev] | [next] | [standalone]

#544046

Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
> Am 20.02.22 um 00:38 schrieb Herwig:
> 
>>> Es geht um Fujitsu und BS2000
>>> 
>>> In den USA mussten Banken oder auch Behörden schon über 70-jährige
>>> COBOL-Rentner reaktivieren,
>> 
>> Dass das passiert, darauf warte ich schon lange.
> 
> Zu lange im monotonen Flusi gesessen?

Hermann! Et tu, Brute?


-- 
please forgive my iPhone typos

[toc] | [prev] | [next] | [standalone]

#544081

Am 20.02.22 um 07:49 schrieb Dr. Joachim Neudert:

> Et tu, Brute

Bisher habe ich nur an 3 Flugsimulatoren mehr als 1 Std Zeit verbracht.

Der Flugsimulator Falcon F16 für Atari ST
Der MS-Flugsimulator für (DR)DOS
der Comanche Hubschrauber Simulator für (DR)DOS

Hermann
    der allerdings keinen Wert auf Flugkünste
    oder Punkte gelegt hat.

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

[toc] | [prev] | [next] | [standalone]

#544124

2022-02-20 14:07:00 +0100

> ...

> Zuverlässige alte software?

Es war zu keinem ZeitPunkt geboten, seine
Arbeit zuverlässig und qualitativ hochwertig
zu machen. Wenn an einem Stück Software
keine Probleme mehr auftauchen, kriegt man
eine andere Software zur Wartung zugewiesen.
Das ist über die Jahre ein Abstieg - zum Schluss
sitzt man mit den ProblemSpielWiesen da und
ist natürlich auch für alle Probleme verantwortlich.

Wenn man so beschimpft wird, ist die Motivation,
im RentenAlter den Firmen zur Hilfe zu eilen,
natürlich gering.

Zusätzlicher Verlust von Know-How durch
CoVid? Ich kenne einzelne Fälle, aber ich kann
es nicht quantifizieren. In den StatusBerichten
des Managements wird das natürlich als
Grund für Probleme zitiert werden - da muss
man nehmen, was man hat und was sich
anbietet.

Herwig

[toc] | [prev] | [next] | [standalone]

#544138

Am 20.02.22 um 14:07 schrieb Herwig:

>> Zuverlässige alte software?

> Es war zu keinem ZeitPunkt geboten, seine
> Arbeit zuverlässig und qualitativ hochwertig
> zu machen.

Kann ich nicht bestätigen.
Ich habe ein software Produkt stabilisiert und erweitert.
Ich gebe zu dass ich dafür möglicherweise überdurchschnittlich
gebraucht habe.

> Wenn an einem Stück Software
> keine Probleme mehr auftauchen, kriegt man
> eine andere Software zur Wartung zugewiesen.

Einmal durfte ich auch etwas ganz neues entwickeln.

> Das ist über die Jahre ein Abstieg - zum Schluss
> sitzt man mit den ProblemSpielWiesen da und
> ist natürlich auch für alle Probleme verantwortlich.

Soweit ich mich erinnere, habe ich alle mir zugewiesene
software Fehler behoben.
Lediglich das mir zuletzt zugewiesen Produkt
konnte ich so hochwertig machen,
das das Grundgerüst instabil war.

> Wenn man so beschimpft wird, ist die Motivation,
> im RentenAlter den Firmen zur Hilfe zu eilen,
> natürlich gering.

Eine gewisse Bereitschaft ist zwar da, aber:
Ich habe heute altersbedingte Schwierigkeiten
wie noch schlechteres Gedächtnis, höherer Fehlerrate beim Tippen ..

Zudem möchte ich eigene Vorstellungen bearbeiten.

> Zusätzlicher Verlust von Know-How durch CoVid?

know-how geht noch, ich kann noch improvisieren.
Französisch ( vom Gymnasium) und COBOL ( von der Arbeit )
ist bis auf Fragmente wie PICTURE gelöscht.
(PICTURE ist beschränkter Platz für Text
  Was das mit Bild zu tun haben soll,. )
Und das man in COBOL statt wie LET in Basic
halt COMPUTE tippen soll.
Oder so ähnlich.

> Ich kenne einzelne Fälle, aber ich kann
> es nicht quantifizieren.

Ich musste mal ein kleines COBOL Programm schreiben
Ich habe es erst in Fortran notiert
und dann anhand von Vorlagen und Manuale übersetzt.

> In den StatusBerichten
> des Managements wird das natürlich als
> Grund für Probleme zitiert werden - da muss
> man nehmen, was man hat und was sich anbietet.

Ich habe versucht, soweit es mir erlaubt war,
meine Arbeiten vernünftig zu machen,
ansonsten den Spruch:
"Du hast es so gewollt, da hast Du es"
verwendet.
Das Geld war ausreichend für das,
was mir wichtig war.
Damit konnte ich leben.


Hermann
    der auf dem Gymnasium in Fremdsprachen Unterricht
    ( Deutsch Englisch Französisch) schlimmeres als COBOL ..
    erlebt hat.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | ger.ct

csiph-web