Aufruf CL Programm via Access

[Franz Karl]

Danke - aber die CCSID wurde geändert - jetzt funnktioniert es wieder.

Mit 65535 .

Gruss
Franz

[Fuerchau]

65535 wird auch nicht verwendet, SQL nimmt dann 037 an.
In Objektnamen gehören auch keine Sonderzeichen!

[Franz Karl]

Vielen Dank für die Information.

[Fuerchau]

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.

[Chris.jan]

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?

[Fuerchau]

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.