ASCII Daten über Socket in RPG einlesen

[weidenhammer]

Hallo allerseits,

ich habe folgende Problemstellung:
Im Produktionsbereich sollen per stationärem Scanner (SICK CLV490) erfasste Barcodes auf der AS/400 weiterverarbeitet werden. Die Scanner geben die Leseresultate über eine RS232-Schnittstelle aus.
Mein erster Gedankenansatz war nun, mittels einer Art Seriell-Socketkonverter die Anlage quasi IP-Fähig zu machen. Das dürfte eher das kleinere Problem sein. Wie bekomme ich so etwas nun aber in meine Anwendung? Daher meine Frage: Hat jemand Tips und/oder Erfahrungen in diesem Bereich? Gibt es da eine Lösung, die man 'Out of the Box' kaufen kann? Oder ist Eigenentwicklung angesagt?

Bin für jeden Hinweis dankbar....

Grüße

Alexander May

[BenderD]

Hallo,

zu Sockets gibt es ein Tutorial von Scott Klement und in dem RPG Redbook stehen ein paar Hinweise. RPG Programme als Socketserver sind allerdings tückisch, da die RPG runtime kein Multithreading kann.

mfg

Dieter Bender

Hallo allerseits,

ich habe folgende Problemstellung:
Im Produktionsbereich sollen per stationärem Scanner (SICK CLV490) erfasste Barcodes auf der AS/400 weiterverarbeitet werden. Die Scanner geben die Leseresultate über eine RS232-Schnittstelle aus.
Mein erster Gedankenansatz war nun, mittels einer Art Seriell-Socketkonverter die Anlage quasi IP-Fähig zu machen. Das dürfte eher das kleinere Problem sein. Wie bekomme ich so etwas nun aber in meine Anwendung? Daher meine Frage: Hat jemand Tips und/oder Erfahrungen in diesem Bereich? Gibt es da eine Lösung, die man 'Out of the Box' kaufen kann? Oder ist Eigenentwicklung angesagt?

Bin für jeden Hinweis dankbar....

Grüße

Alexander May

[weidenhammer]

Hallo Dieter,

Danke erstmal für die Antwort. Mir geht es mehr im die generelle Realisierung RS232-ASCII Ausgabe -> auf AS/400 weiterverarbeiten. Die Idee mit der Socketprogrammierung war nur ein erster Gedankenansatz und sicher so nicht der Beste. Vielleicht hat ja der ein oder Andere hier im Forum ähnliche Anforderungen und sowas in der Richtung schonmal realisiert.


Gruss

Alexander May

[BenderD]

Hallo,

die Dinger hängen ja wohl erstmal an irgendeiner Intelbüchse und wenn ich das richtig verstehe, willst du an dieser Stelle die Daten per noch zu schreibendem Programm packen und über IP an eine AS/400 zur Weiterverarbeitung per RPG Programm transferieren. Der direkteste Weg hierzu sind in diesem Szenario wohl stored Procedures per ODBC oder JDBC, je nach verwendeter Programmiersprache.

D*B

Hallo Dieter,

Danke erstmal für die Antwort. Mir geht es mehr im die generelle Realisierung RS232-ASCII Ausgabe -> auf AS/400 weiterverarbeiten. Die Idee mit der Socketprogrammierung war nur ein erster Gedankenansatz und sicher so nicht der Beste. Vielleicht hat ja der ein oder Andere hier im Forum ähnliche Anforderungen und sowas in der Richtung schonmal realisiert.


Gruss

Alexander May

[Spateneder]

Das klingt schwer nach DTAQ (Datenwarteschlange). DTAQs sind mit RPG und vielen PC-Sprachen einfach anwendbar und haben gegenüber einem Socket bei Deiner Problemstellung den großen Vorteil, daß keine Daten im Nirvana verschwinden, wenn mal ein Programm abschmiert.
Beispiele für Kommunikation via DTAQ gibts bei IBM, u.a. im RPG-Redbook oder auch in einer der letzten Ausgaben von NewSolutions.
Grüße
M. Spateneder

[AS400.lehrling]

Hallo,

die Dinger hängen ja wohl erstmal an irgendeiner Intelbüchse und wenn ich das richtig verstehe, willst du an dieser Stelle die Daten per noch zu schreibendem Programm packen und über IP an eine AS/400 zur Weiterverarbeitung per RPG Programm transferieren. Der direkteste Weg hierzu sind in diesem Szenario wohl stored Procedures per ODBC oder JDBC, je nach verwendeter Programmiersprache.

D*B

Kann man sich da nicht eine Realisierung via Client-Acces konstruieren

Gruß AS400.lehrling

[schatte]

Kann der Scanner nicht einfach als Tastatur eingeschliffen werden?

Ich kenne viele Kunden, bei denen die gescannten Daten einfach im AS/400 Feld angezeigt werden, als würde man diese mit der Tastatur eingeben.

Das wäre doch viel einfacherer und nicht so Fehleranfällig wie mit einer TCP/IP Lösung.

Gruß
Matthias