View Full Version : Perl CGI (auf OS/400 V4R5M0)
Super, genau das Uninteressante, das was funktioniert, sagst Du uns. :-)
Und wenn Du in ein Textfeld Deiner Datei z.B. mal "Test" hineinschreibst, kriegst Du dann x'E385A2A3' (worauf ich tippe) oder x'54657374' oder etwas ganz Anderes?
Alle Werte gleich deuten schon auf die Default-Funktion Hash für ein Objekt.
Vielleicht hilft dir ja diese Seite weiter:
http://search.cpan.org/dist/DBD-DB2/DB2.pod
Kannst du nicht Perl auf dem PC ausführen?
Ggf. kann man dann dort besser debuggen als im Nebel stochern.
Denn wo die DB im Endeffekt ist ist doch egal, Hauptsache sie ist erreichbar.
Welche Art von Schnittstelle verwendet wird lässt sich relativ einfach feststellen:
Bau eine "Sleep"-Funktion im Script ein während die Verbindung geöffent ist.
Auf der AS/400 kannst du dann per
WRKOBJLCK CONNECTUSER *USRPRF
den Verbindungsjob herausfinden.
Zu "connectuser" sagte meine Maschine das er das Objekt nicht finden konnte.
Perl hab ich auch lokal auf einem PC laufen. Ich muss nur zusehen wie ich den DB2 Treiber installiert bekomme, dann werd ich mal schauen.
Die Hash Werte ändern sich jedoch pro Zeile. Also pro Zeile eine neue Gruppe Hash Werte die aber für alle Zellen gleich sind.
Ich muss mich vielleicht auch entschuldigen, viele Kenntnisse sind leider noch recht rudimentär, darum auch einige Fragen und ggf. unverständliche Antworten hier im Forum :-)
Entschuldigung, aber mit CONNECTUSER meine ich deinen Usernamen, mit dem du dich in Perl an der DB anmeldest.
Dass du mit jeder Zeile einen anderen Hash bekommst ist normal, da ja neue Strings angelegt werden und diese dann auch eine andere Adresse bzw. Inhalt haben.
Ohne Debugger wirst du das Problem glaube ich nicht lösen können.
Ich dachte der DBI-DB2-Treiber ist auch nur eine Perl-Bibliohek?
Das stimmt, man muss erst mal vernünftig debuggen können.
OK, das mit dem Benutzer werd ich noch machen, danke daüfr :-)
Der DB2 ist leider nicht standardmäßig bei Perl dabei und einfach nur rein kopieren funktioniert nicht so ohne weiteres. Es ist schon eine Perl Bibliothek, aber man muss dem Perl noch was dazu sagen, bevor es damit arbeiten kann.
Schade das es nicht einfach eine SQL Funktion z.Bsp. EBCDIC to ASCII gibt. Von mir aus auch im alten ILE Perl.
Ich denke, ich werde das Projekt doch erst mal auf Eis legen. Dabei ist es erstaunlich, dass Perl mit der AS/400 harmoniert und sich sogar Daten schreiben lassen. Nur eben nicht lesen, obwohl sie vorhanden sind und mir ein Hashwert (Debugstufe im Perlscript) angibt.
*Humor* Offensichtlich möchte meine AS/400 nicht alle Informationen preis geben die sie gerne aufsaugt ;-) *
In SQL geschieht die Codewandlung vollautomatisch.
Wichtig ist, dass die PF auf Feld oder Satzebene eine gültige CCSID hat.
Dies kann man per DSPFFD, bzw. DSPFD mit CCSID-Suche prüfen.
Alle Zeichenfelder die keine CCSID haben werden per Default als Binär behandelt.
Beim CREATE TABLE bekommen Zeichenfelder (char, varchar, nchar, ...) automtisch die CCSID des Systems (indirekt durch die Sprache).
Zeichenfelder ohne CCSID (65535, *HEX) werden nicht codegewandelt.
Erstelle eine Tabelle mit CREATE TABLE an Stelle von DDS, das muss auch mit V4R5 funktionieren.
Ansonsten must du mal die möglichen Verbindungseigenschaften des DBI-Treibers prüfen.
Der SQL-Servicejob (meist QZDASOINIT) lässt sich auch per DSPJOB anzeigen. Hier lassen sich die CCSID-Attribute prüfen.
Ggf hier:
http://www.ibm.com/developerworks/data/library/techarticle/dm-0512greenstein/
(nicht alles funktioniert mit V4R5)
Ich kann bzgl. Perl und CCSID bzw. Character Set überhaupt nichts finden, das scheint etwas lückenhaft.
Also der Job läuft mit CCSID 37
Ich hab eine Tabelle mit 3 Feldern erstellt. Im DSPFFD bekomme ich nur für die Zeichenfelder den CCSID 37 angezeigt. Das Numerische ist außen vor. Ich wollte noch ein Screenshot anhängen, bekomme aber leider einen 500er Fehler hier im Forum.
Es mag jetzt vielleicht amateurhaft und albern klingen, aber mir scheint es, als würde mein Perl hier gerade nur diesen einen Feldtyp (Numerisch) auslesen weil er keine codierte Zeichensatz ID besitzt?
... eine nicht passende CCSID führt allenfalls zu verhunzten Daten, "weg" sind die deshalb keineswegs und keinesfalls. Anstatt wilde Hypothesen aufzustellen, solltest Du vielleicht mal klipp und klar beschreiben, was Du da genau treibst, dann wird Dir eher jemand sagen können, was Du falsch machst - das Problem sitzt meistens vor (!) dem Bildschirm.
D*B
der sich fragt, wie man auf die Idee kommen kann, auf einer historischen RPG Maschine mit einem historischen Betriebssystem Perl zu versuchen, das man selber auch kaum kann. Das kommt mir vor, wie ein Fahranfänger, der mit einer NSU Quickly mit Gepäck über die Alpen fahren will.
Der SQL-Job behandelt das automatisch!
Schließlich wandelt der ja auch dein ASCII-SQL in EBCDIC-SQL um.
Also muss nur deine Feldabfrage falsch sein, dass du nur den Hashwert statt des Inhaltes bekommst.
Da du das Perl-Script ja nicht postest (wie übrigens in einem anderen Forum in dem du die selbe Frage gestellt hast), kann dir auch keiner sagen, was du da falsch abfragst.