SerialLib Klasse für VO 2.8

[lagraf]

Hallo Gerhard,
du hast Recht, die beiden Magnetkartenleser, wo der Absturz stattfindet, werden über Sockets angesprochen. Die beiden Waagen über ser. Schnittstellen. Das wurde mal von 4 ser. Schnittstellen umgestellt, hatte das noch immer so im Kopf.

Dann also so: Kann es daran liegen dass die Sockets mit VO 2.8 nicht funktionieren, weil der Kundenrechner noch ein XP Rechner ist?

[lagraf]

Ich habe das Problem gefunden:

Code: Select all

CLASS dtaSocket INHERIT dtaSerial
	EXPORT  _oSocket AS CSocket

METHOD Setup(nIndex) CLASS dtaSocket
	LOCAL t1 AS TParams
...
	_t1 := MemAlloc(_SIZEOF(TParams))
	RegisterKid(_t1, 1, FALSE)
	_t1.MainDlg := PTR(_CAST, SELF)
	pTask:=CreateVOThread(NULL, 0, @Logging(), _t1, 0, @nID)   // Übergabe an Func Logging _t1 = dtaSocket

ACCESS oSocket CLASS dtaSocket
	RETURN _oSocket

FUNCTION Logging(dwParam AS DWORD) AS INT PASCAL
	LOCAL oDta AS dtaSocket
	LOCAL t1 AS TParams
...
	t1 := dwParam
	oDta := OBJECT(_CAST,t1.MainDlg)
	WHILE TRUE
		oDta:oSocket:listen(1)     // oDta:oSocket über ACCESS bringt Absturz
		oDta:_oSocket:listen(1)     // oDta:_oSocket über EXPORT Var funktioniert

Der Zugriff über ACCESS bringt das Prog zum Absturz, ich weiß allerdings nicht warum. Der direkte Zugriff über die EXPORT Variable funktioniert hingegen.

[ArneOrtlinghaus]

Wenn der Kunde noch XP hat und das Programm sonst nicht testbar ist, dann würde ich sagen:
Keine einzige Änderung, die nicht unbedingt notwendig, also auch unbedingt mit der alten VO-Version weiterarbeiten.
Es werden Threads benutzt und die geben in Zusammenhang mit der GUI und vielen anderen Klassen unter Umständen Fehler in Zusammenhang mit dem Garbage Collector.
Das, was auch sehr gefährlich aussieht, ist das Casten von Objekten aus Pointerstrukturen. Die Frage ist immer, ob der Pointer immer noch auf das korrekte Objekt zeigt, nachdem der Garbage Collector gelaufen ist. Und beim Garbage Collector hat sich viel verändert von VO 2.7 auf VO 2.8 (meistens zum Positiven, aber es reichen hier kleine Veränderungen).
Ich selbst würde hier als erstes die Casts auf die Objekte ändern, indem ich ein globales Array mit Objekten anlegen würde und der Thread nur eine Nummer bekommt und dann aus dem globalen Array das richtige Objekt rausholen kann. Das ist zwar auch nicht schön, aber das verhindert, dass der Garbage Collector durcheinanderkommen kann.
In einem Thread darf es nichts geben, dass den Garbage Collector anstoßen kann. Oder als Ersatzlösung muss so viel dynamischer Speicher bei Programmstart reserviert werden, dass der Garbage Collector (hoffentlich) nicht während der Threadausführung anfängt zu laufen. Das kann man mit AppSetDynMem steuern mit ausreichend großen Werten.
Arne

[lagraf]

Hallo Arne,
danke dir für die Infos! Die Fehlerursache habe ich inzwischen gefunden, hast du mein Posting 15min vor deinem gesehen?

Info über den Kunden:
Es handelt sich um eine weltweite Großfirma mit ca. 3000 Leuten nur an diesem einen Standort. Die haben auch in der nächsten Zeit (also wohl in den nächsten 2 Jahren) vor, den Rechner von XP auf neuere Hardware und OS umzustellen. Aber das ist dort ein Projekt für 4-5 Mann und mind. 2 Wochen Aufwand!

[ArneOrtlinghaus]

Umso besser, dass es jetzt wieder läuft. Aber es läuft ja nur wegen einer kleinen Anpassung, die eigentlich ja nicht der Grund sein sollte.

Da kann man sich nur fragen, welche Bedeutung IT-Sicherheit und -Stabilität bei dem Kunden hat, wenn das dann ein wichtiges Produktivsystem ist.

Ich gebe zu, dass wir bei uns in unserer Entwicklungsabteilung bis Anfang letzten Jahres noch einen virtualisierten Windows Server 2003 hatten (entspricht ja der Windows XP-Zeit). Wir brauchten noch eine alte Datenbankversion aus Kompatibilitätszwecken, weil einige Kunden auch noch so alte Rechner hatten. Da unsere Programme jetzt nicht mehr mit der alten Datenbankversion zu betreiben waren, war automatisch Schluß, sobald sie auf eine aktuelle Programmversion umsteigen wollten.

Gruß
Arne

[g.bunzel@domonet.de]

Hallo Franz,

gut, wenn es jetzt funktioniert.

Ich hätte so einen ACCESS mit 'Strong Typing' erstellt - evtl. macht das einen Unterschied.

ACCESS oSocket AS CSocket CLASS dtaSocket
RETURN SELF:_oSocket

Gruss

Gerhard

[lagraf]

Arne: Ich muss dazu sagen, dass der Rechner nur lokal verwendet wird und nicht im Internet hängt. Aber bei so großen Firmen ist ein Umstieg, vor allem bei 24/7 Betrieb, nicht einfach. Da wollen/müssen viele Leute mitreden und koordiniert werden!

Gerhard: Ich habs mit Strongtyping getestet, aber stürzt auch damit ab.

Ich habe eine Software namens CardServer gefunden, welche die beiden Magnetkartenleser steuert und mit meinem Prog per Socket kommuniziert. Wenn ich die nicht hätte, würde ich beim Test gar nicht bis zu der ursprünglichen Fehlerposition kommen, sondern schon beim Connect scheitern. Gut wenn man auch 25 Jahre alte Software nicht wegwirft!

[lagraf]

Aktueller Stand:
Damit der Kunde arbeiten kann, habe ich ihm die Software mit VO2.7 geändert und ausgeliefert. Ich würde aber interessehalber und um VO2.7 wegzubekommen die Software noch unter VO 2.8 zum Laufen bringen. Da ich aber die Hardware nicht habe, kann ich die Abläufe nicht testen.

Meine Idee zum Test ohne Hardware:
Die beiden Magnetkartenleser werden von einer Software namens crdreader verwaltet. Diese kommuniziert per Socket mit meinem Programm bidirektional. Meine Idee ist jetzt, mir aus dem EchoSrv einen eigenen crdreader zu machen, der mir die Zugriffe auf die Magnetkarten simuliert und die Antworten retourniert.

Dabei habe ich aber das Problem, dass ich die erste Anfrage an den EchoSrv absetzen kann, diese wird dort im Fenster angezeigt, aber jede weitere Anfrage bewirkt nichts mehr. Nachfolgend das Setup für den Thread gekürzt aufs Wesentliche und 2 Dummyanfragen:

Code: Select all

CLASS dtaSocket INHERIT dtaSerial
	EXPORT  _oSocket AS CSocket
	PROTECT _t1 AS TParams
	PROTECT _cIP AS STRING
	PROTECT _nPort AS WORD

METHOD Setup(nIndex) CLASS dtaSocket
	LOCAL nID AS DWORD
	LOCAL pTask AS PTR

	// Socket erstellen
	_oSocket := CSocket{SOCK_STREAM}
	_oSocket:Timeout:=100
	IF _oSocket:connect(_cIP, _nPort)
	
		// Thread starten für Listening
		_lStop := FALSE
		_t1 := MemAlloc(_SIZEOF(TParams))
		RegisterKid(_t1, 1, FALSE)
		_t1.MainDlg := PTR(_CAST, SELF)
		pTask:=CreateVOThread(NULL, 0, @Logging(), _t1, 0, @nID)
		CloseHandle(pTask)

		// Nachricht senden
		_oSocket:SendLine("INFO#1")     // Kommt beim EchoSrv an, Antwort in Func Logging retour
		_oSocket:SendLine("INFO#2")     // Kommt nicht an
	ENDIF
	RETURN SELF

Was könnte das Problem sein, dass nur die erste Anfrage an den EchoSrv dort ankommt?

[ArneOrtlinghaus]

Die serielle Schnittstelle ist extrem tückisch. Wenn dann noch Thread-Programmierung dazukommt, dann wird das noch schwieriger. Meiner Meinung nach müsstest du die Kommunkation mit externen Programmen wie Telnet machen. Es kommt natürlich auf das Protokoll an, wie oft sich Programm und Kartenleser Daten hin- und her- schicken.

Wenn das Programm so schwer zu testen ist, ist die Frage, warum du es auf VO 2.8 zum Laufen bringen willst. Im Grunde ist VO 2.8 auch ein Auslaufmodell.
Gruß
Arne

[lagraf]

Hallo Arne,
die beiden seriellen Schnittstellen bedienen die Waagen, habe aber nichts mit dem Problem zu tun. Die beiden Magnetkartenleser werden über Sockets angesprochen: MeinProg <-> crdreader <-> Hardware. Und da gibt es anscheinend zwischen VO 2.7 und VO 2.8 Unterschiede. Eine Umstellung auf X# ist nicht möglich, der Kunde will das Prog solange laufen lassen, bis eine Alternative gefunden wird. Außerdem wird der Unterschied zwischen VO 2.7 und X# noch größer sein als der zwischen VO 2.7 und VO 2.8.

Alle meine Programme bei den Kunden laufen noch mit VO2.8 und daran wird sich nichts ändern, solange VO auf Windows funktioniert. Nur möchte ich wegen 1 einzigen App nicht noch VO 2.7 mitschleppen müssen.