Einträge in QHST

[KM]

Hallo,

kann man irgendwie verhindern, dass bestimmte Meldungen (wie z.B. CPIAD09) ins History Log (QHST) geschrieben werden ? Hintergrund ist, dass man über das Internet per PHP/ODBC auf unsere iSeries zugreifen kann. Und offenbar werden durch Suchmaschinen-Robots (z.B. Google) alle paar Sekunden ODBC-Jobs (QZDASOINIT) gestartet und zugehörige Einträge in QHST geschrieben, was uns natürlich dieses Log zumüllt. Kann man das verhindern ?

Gruß,
KM

[Fuerchau]

Das geht leider nicht, da das Schreiben in QHST durch SNDPGMMSG ausgelöst wird.
Ohne Programmänderung (und hier ist es ein Systemprogramm) kann man das nicht abschalten.

[TARASIK]

Hallo KM,
hier eine Antwort von IBM:

Problem Summary:
The History Log contains several instances of the following messages:

CPIAD09 - User &4 from client &8 connected to job &3/&2/&1 in subsystem &6 in &7 on &5.
CPE3426 - A connection with a remote socket was reset by that socket.
CPIAD08 - Host server communications error occurred on &1.

These messages reference various QNPSERVS jobs. Why are these messages generated and what can be done to get rid of them?

Resolution:
These are messages that are generated each time an iSeries NetServer connection is opened and closed when using iSeries NetServer print shares. Microsoft Windows XP causes more of these messages than other versions of Windows. These messages are normal and cannot be turned off or moved to another message queue.

[KM]

Hallo Tarasik,

das hat leider nichts mit meinem Problem zu tun. Hier geht es um QNPSERVS und Netserver. Bei mir handelt es sich um ODBC-Zugriffe.

Außerdem können hier die Nachrichten ja auch nicht unterdrückt werden.

Trotzdem danke,
KM

[Fuerchau]

Ggf. unterstützt PHP Connection-Pools.
Dadurch wird nicht jedesmal eine neue ODBC-Verbindung aufgemacht sondern bestehende wiederverwendet.

[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