Joachim Merkel <[EMAIL PROTECTED]> wrote on 27.03.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
>> Danach uebernimmt wieder XP die Kontrolle, konvertiert und liest
>> diese *.MSG ein und benennt sie anschliessend nach *.IN um (siehe
>> auch Netcall-Ablauf in der Hilfe, zu erreichen ueber ?/S/R/<Enter>).
> Der Hinweis auf die Online-Hilfe k�nnte vielleicht auch in
> der Doku zum UKA_FXP.BAT erscheinen.
Ich meine, einen generellen Hinweis auf die Hilfe dort bereits eingebaut
zu haben. Speziell den auf ?/S/R kann man sicher noch erg�nzen.
> Mir ist da gleich noch ein weiteres Szenario zu nichtversandten
> Nachrichten eingefallen.
Was Du im folgenden schreibst, hat aber doch nichts mit unversandten
Nachrichten zu tun? Speziell nicht mit dem Problem, um das es bei
Hullen ging.
> Ich benutze zwei Boxen mit demselben Anbieter gmx unter vd.
> Adressen - zwei vd. Accounts also.
Ok.
> Jetzt kann ich keine zwei gmx-Boxen einrichten,
Warum nicht?
> sondern mu� eine anders nennen,
Wie der Boxname hei�t, ist doch (bei RFC/Client) v�llig egal.
> setze den Absender und den Namen in der MID auf gmx.de durch einen
> Ausgangsfilter um.
Verstehe ich nicht. Warum?
> Besser w�re aber einen FDQN zu setzen, damit bei nicht versandten
> Nachrichten auch die MID: mit der im <box>.PP �bereinstimmt.
Im Moment komme ich nicht ganz mit.
Falls es Dir darum gehen sollte, die Nachrichten mehrerer Boxen mit
einem Anruf versenden zu k�nnen: Probiere doch mal, unter "Zus�tzliche
Server" die Boxen, deren Nachrichten mitversendet werden sollen,
einzutragen. Das war ein Szenario, das ich ohnehin nochmal testen
wollte.
Hmm, wird aber wohl daran scheitern, da� die Batch derzeit nur das Spool
der pollenden Box beachtet. Sie m��te im Grunde diesen Eintrag in der
BFG auswerten und die Nachrichten aller dort eingetragenen Boxen ins
UKA_PPP-Spool kopieren.
K�nnte man sich mal ansehen, wenn ich das Envelope-Handling einbaue, da
mu� ich ohnehin auf BFG-Eintr�ge zugreifen.
Aber zum einen ging der Versand der Nachrichten mehrerer Boxen
gleichzeitig unter ZConnect bisher auch nicht, und zum anderen hat das
immer noch nichts mit den angesprochenen (und nicht von XP
herbeigef�hrten) Unversandt-Problemen zu tun.
> Oder ein anderer Fall f�r die Doku: Wenn ich den 3. Parameter
> f�r die Aufruf-Batch UKA_FXP.BAT setze, um eine abweichende
> <box>.$cf aufzurufen, also mal als Beispiel, wenn statt gmx wie
> der 2. Parameter $CONFIG �bergeben k�nnte, nunmehr als 3. Parameter
> gmx1 steht, also gmx1.$cf erwartet w�rde, dann sollte auch eine
> gmx1.$do und eine gmx1.$pp vorhanden sein,
Auf GMX1.$DO bzw. �berhaupt die Vollst�ndigkeit und Plausibilit�t einer
Konfiguration zu pr�fen, ist wie bisher Aufgabe von UKA_PPP selbst. Es
ist ja �berhaupt nicht gesagt, da� eine GMX1.$CF auch eine GMX1.$DO
verwendet, denn man kann AFAIK in der .$CF ja auch einen ganz anderen
Config-Namen eintragen (und so mehrere Configs die immer gleiche .$DO
verwenden lassen).
Oder vertue ich mich da jetzt?
> denn der Aufruf .\%1X_SCRIPT.EXE FXPNEWS %UKA_CFG%
> �bergibt als $Config ja den Wert aus der Umgebungsvariablen UKA_CFG
> die mit dem 3. Parameter geladen wurde.
Ja, so ist es gedacht und funktioniert es auch.
> BTW ist sonst das Batchfile nach meinem Eindruck stimmig. Ich habe mir
> das mal installiert, und es lief eigentlich alles problemlos. Ich habe
> nur fast einen Tag lang meine Filter angepasst
Bzw. sie einfach unter den Filtern eingetragen, oder?
> und alles ausgetestet, um denselben Zustand wie vorher zu haben (mit
> ein paar netten Features zugegeben) und bin immer noch der Meinung,
> passender f�r eine Standard-Installation w�re vermutlich, das mal in
> ein UKA_PPP-Skript umzuschreiben sich damit auch komplett die Box-
> Daten aus der .bfg zu holen.
Genau das geht aber nicht, weil UKA_PPP - jedenfalls im derzeitigen
Zustand - Parameter wie den Boxnamen gar nicht auswertet und keine
Ahnung hat, wo die Spoolverzeichnisse von XP liegen.
Das w�re ein Totalumbau von UKA_PPP, den ich eigentlich nicht vorhatte.
Es ging erstmal nur um eine L�sung, die der von XP2 in einer RFC/PPP-Box
in nichts nachsteht und dar�ber hinaus noch einen Tick besser und
sicherer ist.
Eher hielte ich es noch f�r sinnvoll, sich mit dem Fixen von ein, zwei
alten Bugs in UKA_PPP zu besch�ftigen.
> Ob man sich mit dem Batch und der Dokumentation wirklich
> neue und bleibende Verbesserungen schafft, wei� ich nicht.
> Ist vielleicht besser als vorher, aber unter einer Standard-
> Installation verstehe ich noch was anderes, als hinterher in
> .$cf und .$do herumzukramen.
Braucht man doch auch gar nicht. Gerade die User, die eine Standard-
Installation von UKA_PPP betreiben, brauchen �berhaupt gar nix
"herumzukramen". Das ist ja gerade das Sch�ne.
Und wer an seinen Scripts herumgeschraubt hat, mu� sich halt �berlegen,
welche dieser Schraubereien durch die erweiterten Funktionen von
RFC/Client gegen�ber ZConnect m�glicherweise inzwischen obsolet geworden
sind. Wenn er das nicht wei�, kann er sich an dieses Forum wenden. :)
> IMHO w�re der Hinweis angebracht, da� man mit dem Batch in der Lage
> ist, eine bereits vorhandene, eingerichtete Standard-Installation von
> UKA_PPP durch XP aufzurufen
Auch eine noch nicht bereits vorhandene, neu eingerichtete Installation
kann man damit aufrufen.
> und nicht mehr.
Doch, das "mehr" steht ja bereits in der Doku, wobei noch ein, zwei
Sachen erg�nzt werden m��ten.
> Alles in allem erscheint es mir dann sinnvoller auf UKAD zu wechseln,
> da� diese einfachen Anspr�che in jeder Hinsicht bedient.
Man mu� zur Kenntnis nehmen, da� es offenbar User gibt, die UKA_PPP
verwenden. Vor dem Hintergrund, da� man dort an die Sourcen rankommt
und es ggf. bis zum Gehtnichtmehr aufbohren und an seine Bed�rfnisse
anpassen kann, macht das u.U. sogar einen gewissen Sinn.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
