UKA_PPP in RFC/Client-Box

[Michael Heydekamp]

Helmut Hullen <HHullen_BS at t-online.de> wrote on 18.03.04:

> Du meintest am 18.03.04 zum Thema Re: UKA_PPP in RFC/Client-Box:

>> Es geht um Beispiele um von XP erzeugte Dubletten.  Nicht um das,
>> was Du selbst verursachst.

> Hmmm - willst Du damit sagen, dass Crosspoint auch dann etwas macht,
> wenn ich das Programm nicht starte?

Du glaubst doch wohl nicht, daß ich diese Frage ernst nehme?

>> Du lieferst Beweise und reproduzierbare Szenarien.  Aber das
>> konntest Du ja damals schon nicht und Du wirst es auch jetzt nicht
>> können.

> Du forderst schon wieder etwas, was ich schon damals nicht in einer
> Dich befriedigenden Form liefern konnte.

In einer a) objektiv nicht und b) weder mich noch vor allem aber Markus
Kämmerer befriedigenden Form.

> Du scheinst immer noch zu meinen, Dich damit drücken zu können.

Wieso sprichst Du mit mir?  Wenn überhaupt, wäre Markus für diesen
Vorwurf die richtige Adresse gewesen.  Hab' ich etwa damals entwickelt?
Ich war User, Betatester und hab' ein bißchen Hilfe geschrieben.

Aber er wäre insofern natürlich auch die falsche Adresse gewesen, weil
auch er für Deine Unkenntnis und Unfähigkeit zur Problemanalyse nichts
kann.

> Die von mir damals beschriebenen Fehler waren real,

Ja klar, wenn Du real Mist baust.  Garbage in, garbage out.

Oder Dein Client, was weiß ich.  XP jedenfalls nicht.

> einige der möglichen Auslöser habe ich schon damals genannt,

Waren aber halt alle falsch und mit einem korrekt installierten XP und
einem korrekt arbeitenden Client nicht reproduzierbar.

> Denn ein möglicher Auslöser waren die vom RFC-Client pro Box
> angelegten Spool-Verzeichnisse, die bei erfolgreichem Netcall
> sicherlich bereinigt werden sollten.

Was passieren sollte (und auch passiert), steht in der Hilfe.  Zeige mir
die Stelle, wo FreeXP nicht das tut, was da steht.  Bin gespannt.  Wenn
Du was findest, wird's gefixt und ich krieche zu Kreuze.  Aber Du wirst
nix finden und daher entweder diese Aufforderung ignorieren oder Dich
blamieren.

Hint: Das Spool-Verzeichnis wird vom Client "bereinigt", nicht von XP.
Der entscheidet, ob etwas versandt wurde oder nicht und löscht die
Datei(en) anschließend oder auch nicht.

Wenn da was nicht funktioniert, magst Du Dich an den Entwickler des
Clients wenden, XP ist da nicht zuständig.  Oder ersetze den defekten
durch einen funktionierenden Client, oder schreibe sauber
funktionierende Batches.

Jedenfalls offenbart Deine Aussage die völlige Unkenntnis über die
Abläufe (auch über die in einer ZConnect-Box).

> Aber bei nicht sauber abgewickeltem Netcall

Aha?  Was ist denn ein "nicht sauber abgewickelter Netcall" und wie
kommt der zustande?

> Sie werden gelöscht, obwohl sie nicht verschickt worden sind, oder
> aber andere Nachrichten werden immer wieder verschickt, weil sie nach
> erfolgreichem Versand nicht gelöscht worden sind.

Dann hast Du entweder in Deiner Batch Mist gebaut oder einen nicht
korrekt arbeitenden Client verwendet.  Aber das hast Du IIRC schon
damals nicht kapiert.  Ich kann das ja leider nicht sehen, was Du da
machst.  Ich kann aber sehen, was XP macht, und das macht alles richtig.

Ich sag' ja, daß Du nicht in der Lage bist, Ursachen zu analysieren.

Was reden wir lange herum, niemand hat dieses Problem.  Du behauptest,
es gehabt zu haben, also suche die Ursache bei Dir oder bei dem Client,
mit dem Du damals gearbeitet hast.

> Wir können selbstverständlich die alten Beiträge hier rezyklieren.

Ich suche da nicht herum, aber wenn Du möchtest, bitte.

> "ZConnect"-Boxen verfahren in dem Bereich anders.

Ach ja?  Dann erzähl doch mal präzise, wie.

Ist nur ein Test, ob Du's verstanden hast, ich weiß es ja.  Hint #1: Mit
der ZConnect-Box hat's rein gar nix zu tun.

Hint #2: Wenn ein Client *.OUT nicht löscht, obwohl die Nachricht
versandt wurde, gibt's dort logischerweise exakt dasselbe Problem.
Anderenfalls könnten unversandte Nachrichten nämlich auch beim nächsten
Netcall nicht mehr versandt werden, weil sie von inzwischen neu
erstellten Nachrichten überschrieben würden.

Mag wohl sein, daß Du mit dem Umstieg von RFC/Client auf ZConnect
gleichzeitig den Client gewechselt hast - das würde dann einiges
erklären.

Your turn.

Und wenn Du nicht mehr weiter weißt - die Adresse von khweis hast Du ja
wohl, vielleicht erklärt er's Dir.  Alternativ guckst Du einfach mal in
Deine Verzeichnisse, was da so rumliegt und wie es entsteht.

>> Du hast immer nur Behauptungen aufgestellt, Deine Batches oder was
>> weiß ich für Konstrukte hast Du Dich nie rauszurücken getraut.

> Auch das ist falsch.
> Ich hatte sie veröffentlicht.

MID?

>> Über welchen Client reden wir eigentlich?

> Jetzt fragst Du plötzlich?

Jo.  Und?  Ich kann mich nicht mehr an *jedes* Detail erinnern, hab'
keine Lust rumzukramen und mir wegen Dir mehr Arbeit zu machen als
nötig, und da ich annehme, daß Du das noch weißt, frag' ich.  Wo ist das
Problem?

Also: Über welchen Client reden wir eigentlich?

>> Keine von OpenXP v3.40 erzeugten.

> Das wurde in einigen Newsgroups anders wahrgenommen.

Seit wann können "Newsgroups" bei mehreren beteiligten Programmen die
*Ursache* des von Dir lokal produzierten Mists "wahrnehmen" und wissen,
wieso Du Dupes produzierst?

Was waren das für Gruppen?  de.glaskugel.*?

> Die ZConnect-Box funktioniert zuverlässig.

Gegen die ZConnect-Box als ZConnect-Box sagt ja keiner was.  Nur ist sie
nicht für den Betrieb mit externen RFC-Clients ausgelegt und geeignet,
und welche Probleme damit (und mit den für sie vorgesehenen Lösungen)
entstehen können, haben wir doch erst kürzlich wieder bei Dir gesehen -
schon wieder vergessen?

Peter wußte wohl schon, wieso er mich vor langer Zeit mal davor gewarnt
hat.


        Michael