WebFacing QQF* Jobs/DEVD IP-Adresse ermitteln

[ExAzubi]

Hallo Andreas,

hab ich auch probiert (Format600) brachte aber auch nichts.

Viele Grüße

David

[Fuerchau]

Das Problem ist, dass WebFacing ja ein Umsetzer von 5250 in HTML und umgekehrt ist. Der Client ist also irgendwo ein Webbrowser.
Deshalb kann es auf AS/400-5250-Seite nur einen Client geben, nämlich die AS/400 selber.
Wenn du mit einem Twinax-Terminal verbunden bist, gibts ja auch keine Client-IP, da die Verbindung nicht über IP stattfindet. Genauso ist das leider auch bei WebFacing, die Verbindung ist ein lokales virtuelles Terminal, dass nicht über IP verbunden ist.

[ExAzubi]

Hallo Furchau,

das war mir ja klar, aber irgendwoher muss die AS400 ja auch wissen, mit welchem Client sie kommuniziert, soll heißen, wenn ich das Bild 10 ausgeben will auf dem Job QQFxxxxx dann "leitet" Sie die Informationen ja auch an den richtigen PC. Daher dachte ich, man kann vielleicht irgendeine API aufrufen, die "im Webserver" nachschaut, welche IP sich hinter QQFxxx verbirgt.

Viele Grüße

David

[Fuerchau]

Hinter dem QQF-Terminal verbirgt sich keine IP sondern nur der WebFacing-Service.

Mittels Terminal-API's kann man sich virtuelle Terminals schaffen.
Auf der einen Seite ist dein Programm, dass mittels Read/Write auf der DSPF mit der anderen Seite, die Terminal-API's verwendet kommuniziert.

Was die andere Seite dann tut, bleibt dieser überlassen.
So verwendet WebFacing diese virtuellen Terminals und leitet ggf. die generierten HTML's wiederum an den Web-Service weiter. Hat also ggf. selber auch keinen Kontakt zum eigentlichen Client.

Für die AS/400 sind daher diese Terminals lokal und nicht per IP verbunden.

Die Terminal-API's sind dokumentiert und können von jedem Verwendet werden, wenn du also möchtest ...

Übrigens: Bei STRPASTHR gibts auch keine IP, da das Terminal ja über SNA verbunden ist.

Das selbe Problem hast du auch mit z.B. Dateizugriffen bzw. Triggern.
Ob das nun lokal oder über ODBC oder DRDA passiert läßt sich fast garnicht mehr feststellen.

Jetzt kannst du ja sagen, man kann über den Callstack ja die Ebene prüfen.
Allerdings erlaubt z.B. der Zugriff per CLI-API's (SQLConnect, SQLExecute, ...) auch das Starten eines Batchservers, der dann wiederum die SQL's erst ausführt. Da weiß man gar nicht mehr wo der Zugriff denn nun her ist.

Mal gefragt: Warum benötigst du die Info überhaupt ?

[ExAzubi]

Hallo Furchau,

also die Infos benötige ich dafür, da wir in der Produktion Rechner haben dort melden man sich mit "Gruppennamen" an, z.B. Schicht3

Anhand der IP möchte ich den "zugeordneten" Drucker für den OVRPRTF verwenden. Damit meine ich Rechenr mit der IP 111.111.11.1 hat den Drucker "PRINTER1" zugeordnet. Vor WebFacing habe ich das mit dem WSID gemacht, DEV4711 hat PRINTER1 zugeordnet. Da die QQF* Namen immer wieder frei wechseln, kann ich das nicht mehr machen, da heute so und morgen so. Somit habe ich mir gedacht, machen wir das über die IP-Adressen.

Eine Verständnisfrage wie der genaue Ablauf beim WebFacing so ist, da ich dort nicht allzutief im Thema bin.

Die Kommunikation läuft doch über den WebFacing-Server, d.h. das dieser Server das Bindeglied zwischen Client und AS400 ist, oder? D.h. wenn man am Cleint enter drückt, muss doch irgendwer dem Job das mitteilen, das Enter gedrückt wurde? Also so ganz habe ich das halt erhlich gesagt auch nicht verstanden.

Trotzdem Danke

Viele Grüße

David

[Fuerchau]

Ich denke, da musst du dir eine andere Lösung ausdenken.
IBM wird dir da sicherlich nicht weiterhelfen können.

Warum kann der Gruppenname nicht eindeutig einen "Gruppendrucker" zuordnen ?
Da reicht doch eigentlich ein Eintrag im Userprofil (OUTQ/DEVD).
Ein Drucker kann schließlich nicht übers WebFacing laufen. Da gibts nur PDF-Ausgaben.

[ExAzubi]

Hallo Furchau,

es gibt ja die API QTVOPNVT. Dieses API ist ja dafür da die VRT-DEV zu erstellen, somit denke ich, das auch IBM selber dieses API nutzt, um die QQF DEVD zu erstellen. Diese bieten auch an, die IP-Adresse des Clients in der DEVD zu hinterlegen, um diese per QDCRDEVD wieder auszulesen.

Vielecith gibt es ja irgendeinen Systemwert, damit er diese beim erstellen nimmt?

Dies Lösung mit den Userprofilen geht leider nicht, da in einer Halle ggf. mehrere PC stehen, und die Prozesse zu ändern (Cleintanmeldenamen etc.) will ich als letzten Weg gehen.

Die Informationen welcher PC welche IP und welcherm QQF* zugeordnet ist schwirrt ja irgendwo in dieser großen schwarzen Kiste herum

[Fuerchau]

Ohne Nachbearbeitung gehts nicht:
Using Web Settings with your DDS source

Du kannst jedem Feld ein Javascript zuordnen. Ebenso kannst du ein H-Feld definieren, dass die IP-Adresse zurückliefern kann.
Allerdings schweigt sich hier die Doku aus, wie der JSP-Befehl hier direkt aussieht.

Eine andere Chance sehe ich hier nicht, als sich mit obigen Link vertraut zu machen.

Es reicht ja, sich die IP-Adresse dann beim 1. Anwendungsbild zu merken. Man muss es ja nicht in jede DSPF einbauen.

Bzgl. JSP hilft das ja vielleicht weiter:
http://www.easywayserver.com/blog/js...lient-machine/

[ExAzubi]

Danke Furchau,

nachbearbeiten ist kein Problem. Werde ich mir mal anschauen.

Viele Grüße

David

[Fuerchau]

Wäre schön, wenn du eine Lösung findest, diese dann hier für alle zu präsentieren.