Einträge in QHST

[KM]

Ja, es gibt die Unterscheidung zwischen connect() und pconnect() (=permanenter connect). Das können wir aber leider nicht verwenden, da wir je nach Sprachraum (Latin-1 oder Latin-2) unterschiedliche Umgebungen brauchen und somit die Locale und die Job-CCSID bei Bedarf ändern müssen. Und beim pconnect() hätte ich dann keine genaue Zuordnung mehr welcher Request welchen ODBC-Serverjob benutzt. Deshalb müssen wir alles mit connect() machen. Das geht zwar auch auf die Performance. Aber uns bleibt nichts anderes übrig.

Gruß,
KM

[TARASIK]

Hallo KM,
dann würde ich doch einmal in den Log des QZDASOINIT schauen,
warum diese Meldung geloggt wird. Das sieht doch nach einem
Berechtigungsproblem aus.

[KM]

Nein, das ist kein Berechtigungsproblem. Standardmäßig werden offenbar alle ODBC-Zugriffe protokolliert. Die Nachricht hat ja auch nur die Bewertung 00. Ist also nur ein Hinweis.

Gruß,
KM

[Fuerchau]

Also das mit den unterschiedlichen Umgebungen müsstest du noch mal erklären.
Ggf. kannst du doch unterschiedliche LF's/Views nutzen die die Daten auf Unicode casten, so dass du hier flexibler wirst.

[pwrdwnsys]

Die Nachrichten kommen doch über die MSGQ QHST in das Log. Nun ist das eine spezielle MSGQ, welche sich nicht so einfach bearbeiten läßt. Kann das leider derzeit nicht testen, aber ein CHGMSGQ QHST SEV(XX) sollte doch dazu führen, das nur Nachrichten protokolliert werden, welche eine Bewertung enthalten, die der angegebenen Stufe entspricht. Damit würde nich jede MSG eingetragen werden.
Ist leider nur eine theoretische Betrachtung, probioere ich aus, wenn ich wieder auf einem Testsytem bin.

Gruß Karsten

[Fuerchau]

Ein Ändern der MSGQ QHST (und auch jeder anderen) in dieser Weise ändert nichts an der Aufzeichnung.

Bewertungscodefilter (SEV) - Hilfetext

Gibt die niedrigstmögliche Bewertung einer Nachricht an, die an einen
Benutzer im Durchbruchs- oder Hinweismodus übermittelt wird. Nachrichten
mit einer niedrigeren Bewertung als die hier angegebene unterbrechen
weder den Job, noch leuchtet wegen ihnen die Nachrichtenlampe auf, wenn
sie in der Nachrichtenwarteschlange ankommen; sie werden dort
angehalten, bis sie durch den Befehl DSPMSG (Nachricht anzeigen)
angezeigt werden.

[KM]

Also das mit den unterschiedlichen Umgebungen müsstest du noch mal erklären.
Ggf. kannst du doch unterschiedliche LF's/Views nutzen die die Daten auf Unicode casten, so dass du hier flexibler wirst.

Unser Web-Server läuft auf einem Linux-Server. Und der Zugriff auf die iSeries-Datenbanken somit über den iSeries-Access ODBC-Treiber für Linux. Dieser ist jedoch kein Unicode-Treiber, sondern ein ANSI-Treiber. Deshalb können Strings als Parameter auch nicht im Unicode-Format übergeben werden. Wir müssen also die UTF-8 Texte, die der Kunde im Internet eingibt, immer erst ins (single-byte) ISO-Format konvertieren und dann als Parameter an die iSeries schicken. Dafür ist es natürlich notwendig, dass die Locale auf das entsprechende Land eingestellt ist. Und je nach Locale wird dann ein connect() unter PHP durchgeführt. Dieser connect() gilt dann auch nur für diesen Aufruf mit der jeweiligen Ländereinstellung. Wenn wir eine pconnect() verwenden würden, könnte es theoretisch sein, dass ein polnischer Kunde mit der Locale PL_pl eine Verbindung benutzen würde, die unter der Locale DE_de erstellt wurde. Dann gäbe es falsche Zeichen. Ich brauche also eine eindeutige Zuordnung zwischen dem Kunden und der Verbindung mit der richtigen Locale.

Ein Cast auf Unicode bringt also in dem Fall nichts. Außerdem bräuchte ich ja dann pro Sprachraum eine LF.

Gruß,
KM

[Fuerchau]

Ist die Locale nicht Sache des Scripts ?
Wird im Connect eine Locale angegeben ?

Ansonsten würde ich mal nach einem UNICODE-fähigen Treiber für Linux suchen, die müsse es ja auch geben.

Und was den Cast angeht, so kann man das schon dynamisieren wenn an Hand der Daten die CCSID erkennbar ist.

[KM]

Ist die Locale nicht Sache des Scripts ?
Wird im Connect eine Locale angegeben ?

Beim connect() selbst kann man keine Locale angeben. Jedoch kommen die Verbindungen, die mit pconnect() erstellt wurden, durcheinander, wenn man im PHP-Script ständig die Locale umschaltet. Deshalb gibt es pro Request eine eindeutige Verbindung, die danach wieder beendet wird. Wir haben damals in alle möglichen Richtungen getestet. Und es blieb nichts anderes übrig.

Ansonsten würde ich mal nach einem UNICODE-fähigen Treiber für Linux suchen, die müsse es ja auch geben.

Von IBM gibt's keinen. Gab's damals zumindest noch nicht.

Und was den Cast angeht, so kann man das schon dynamisieren wenn an Hand der Daten die CCSID erkennbar ist.

Anhand der Daten ist das ja nicht erkennbar. Es muß immer ein separater Parameter mit übergeben werden, der die Sprache kennzeichnet.

[BenderD]

Hallo,

was nicht ist, könnte aber wohl doch werden, sprich ein zusätzliches Attribut, das den Ländercode beinhaltet, dann wäre das mit einer entsprechenden View und Cast leistbar. Ob das natürlich Aufwands technisch rentiert, wenn das einzige Problem die vermüllte QHST ist...

mfg

Dieter Bender

Beim connect() selbst kann man keine Locale angeben. Jedoch kommen die Verbindungen, die mit pconnect() erstellt wurden, durcheinander, wenn man im PHP-Script ständig die Locale umschaltet. Deshalb gibt es pro Request eine eindeutige Verbindung, die danach wieder beendet wird. Wir haben damals in alle möglichen Richtungen getestet. Und es blieb nichts anderes übrig.


Von IBM gibt's keinen. Gab's damals zumindest noch nicht.


Anhand der Daten ist das ja nicht erkennbar. Es muß immer ein separater Parameter mit übergeben werden, der die Sprache kennzeichnet.

[Fuerchau]

Naja, ein Performance-Problem ist das allemal (Connect Open/Close).
Wenn zusätzlich noch die Wiederverwendung der QZDA-Job's ausgeschlossen ist, dann kann man ja die Antwortzeiten wohl vergessen.

Ausserdem können durch PConnect auch ODP's wiederverwendet werden. Ich denke auch hier sollte man mal überlegen.

Ggf. kann man doch Java aus PHP aufrufen um das Unicode-Problem zu lösen ?