[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Mar 2010
    Beiträge
    54

    Aufruf CL Programm via Access

    Hallo ,

    seinerzeit aus dem Forum folgenden Code - jetzt erhalte ich auf unserer neuen Maschine seit gestern (Stromabschaltung) die Fehlermeldung

    CALL QSYS.QCMDEXC ('CALL LIB_CL/SIS@CL7', 0000000019.00000)

    [IBM-ISeries ODBC Treiber ][DB2 UDB ] - Im Befehl ist ein Fehler aufgetreten. #-443

    Der gleiche Befehl auf der alten Maschine läuft jedoch.

    Woran kann das liegen ?

    Danke

    Franz

  2. #2
    Registriert seit
    Aug 2006
    Beiträge
    2.114
    Gibt es kein Joblog dazu?

    GG

  3. #3
    Registriert seit
    Jan 2007
    Beiträge
    70
    Danke - aber die CCSID wurde geändert - jetzt funnktioniert es wieder.

    Mit 65535 .

    Gruss
    Franz

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.695
    65535 wird auch nicht verwendet, SQL nimmt dann 037 an.
    In Objektnamen gehören auch keine Sonderzeichen!
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Jan 2007
    Beiträge
    70
    Vielen Dank für die Information.

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.695
    ODBC vom PC arbeitet in ANSI, d.h., dass ein SQL-Statement ja in EBCDIC umgewandelt werden muss.
    Also geht es nicht ohne CCSID.
    Steht der Systemwert QCCSID auf 65535 wird normalerweise die CCSID aus der Hauptsprache ermittelt.
    Bei DE/DEU ist das dann 273.

    Für Datenfelder gilt die Regel nicht direkt.
    Wird in der ODBC-Konfig das Häkchen für "65535 umsetzen" gesetzt, wird die Umwandlung mit der Default-CCSID durchgeführt. Dies verhindert aber echte Binärdaten.

    CCSID-spezifische Zeichen gehöhren deshalb nicht in einen Objektnamen (also # und @) auch wenn sie erlaubt sind.
    In multinationalen Umgebungen führt das unweigerlich zu Problemen.
    Wird korrekterweise ein Job auf die Sprache des Users eingestellt funktionieren plötzlich die Programmaufrufe nicht mehr.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Feb 2009
    Beiträge
    391
    Das ist eine Sicherheitslücke die gerne ausgenutzt wird, wenn im Userprofil LMTCPB auf *YES steht. SUCKS-Complience
    Weiß jemand zufällig wie man das unterbinden kann?

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.695
    Nur durch Berechtigungen.
    LMTCPB beschränkt sich halt ausschließlich auf den Aufruf aus einer Kommandozeile.

    Wenn das einschränkender wäre könnten die meisten Programme die mit QCMDEXC oder direkt in CLP Kommandos verwenden, diese nicht mehr ausführen.

    Man kann diese Art Aufrufe mittels WRKREGINF auf entsprechenden Schnittstellen prüfen und dann ggf. ablehnen.

    Das Produkt PCSACC/400 unterstützt dieses z.B. nebst vielen anderen Prüfungen bzgl. ODBC/FTP u.v.m.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Similar Threads

  1. Programmbibliothek in einem Cobol oder CL Programm ermitteln
    By schatte in forum NEWSboard Programmierung
    Antworten: 19
    Letzter Beitrag: 10-01-07, 11:32
  2. Hardcopies via Cl. Acc. 5250 Session unmöglich
    By federico in forum NEWSboard Drucker
    Antworten: 6
    Letzter Beitrag: 21-09-06, 09:55
  3. Bibliothekssicherungsliste via CL ändern
    By becama in forum IBM i Hauptforum
    Antworten: 6
    Letzter Beitrag: 23-06-06, 14:46
  4. Rufendes Programm in CL "retrieven"
    By Lichtblitz in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 22-06-06, 09:50

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •