25 avril 2012

Putty Connection Manager : pour tabuler entre les sessions telnet

Vous connaissez certainement Putty : cet utilitaire est un client telnet/ssh qui permet d'ouvrir des session en mode ligne de commande sur les machines de type Unix.

Un des reproches que l'on peut faire à putty est qu'il ne sait pas gérer l'affichage de multiples sessions dans des tabulations (comme le font maintenant les navigateurs). PuttyCM pallie à ce manque.


18 avril 2012

BLS-BBAD0015-ERREUR D'ACCES ... : TD12/9N/FJ/FETCH/000000000001002

Si vous rencontrez l'erreur suivante lors d'une NOY
 XXXXXBLS-BBAD0015-ERREUR D'ACCES (TABLE RELATIONNELLE) : TD12/9N/FJ/FETCH/000000000001002

C'est que vous avez sans doute des dossiers vérolés (leur TD12 ne reflète pas la réalité du contenu de la table).
Le programme BLS ne gère pas l'erreur correctement ...

Exécutez une ROL sur les dossiers concernés par l'export (pour corriger la TD12) puis relancez la NOY.

Pour information le message d'erreur Oracle associé :
01002, 00000, "fetch out of sequence"
*Cause: This error means that a fetch has been attempted from a cursor
         which is no longer valid.  Note that a PL/SQL cursor loop
         implicitly does fetches, and thus may also cause this error.
         There are a number of possible causes for this error, including:
         1) Fetching from a cursor after the last row has been retrieved
            and the ORA-1403 error returned.
         2) If the cursor has been opened with the FOR UPDATE clause,
            fetching after a COMMIT has been issued will return the error.
         3) Rebinding any placeholders in the SQL statement, then issuing
            a fetch before reexecuting the statement.
*Action: 1) Do not issue a fetch statement after the last row has been
             retrieved - there are no more rows to fetch.
          2) Do not issue a COMMIT inside a fetch loop for a cursor
             that has been opened FOR UPDATE.
          3) Reexecute the statement after rebinding, then attempt to
             fetch again.

5 avril 2012

java.security.AccessControlException: access denied

Information obtenue de la HotLine : depuis la version 1.6.0_22 de la JVM Sun/Oracle, un "fix" peut provoquer des erreurs sur le démarrage d'une applet dans des configurations réseaux particulière.

Exemple d'erreur :
[ERROR] applt - APPLT???? Error when testing web application's status <java.security.AccessControlException: access denied (java.net.SocketPermission 10.9.8.7:6543 connect,resolve)>
 java.security.AccessControlException: access denied (java.net.SocketPermission 10.9.8.7:6543 connect,resolve)

Voir la release note Oracle : (chapitre CVE-2010-3560).

Il est donc nécessaire, afin que les applets puissent fonctionner avec ces versions de Java , qu'il y ait bijection entre une adresse IP et un nom d'hôte. Dans la pratique, il faut que le "reverse lookup" sur une adresse IP redonne le même nom qu'un "direct lookup" sur le serveur DNS. Cela est résolu en ayant deux entrées dans le DNS de l'entreprise :
  • Première entrée classique "Direct lookup" : résolution d'un nom -> IP
 host    aaa.bbb.ccc.ddd
  • Deuxième entrée "Reverse lookup" : résolution IP -> nom
 aaa.bbb.ccc.ddd    host.auth.ddd.ccc.bbb.aaa.in-addr.arpa

Ces consignes ne sont plus nécessaire à partir de la JVM 1.6.0_25 qualifiée avec la release cliente 7.20.60.