-
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.
-
Guten Abend in die Runde,
oh weh, da hab ich wohl das Wichtigste versäumt zu posten, aber ist ja logisch, ohne Quellcode keine Hilfe! *Sorry*
Hier zunächst das simple Script, welches im Unterordner dbsamples hinterlegt ist (dbtest.pl).
Das ist das einfachste was es eigentlich gibt:
Code:
use DBI;
use DBD::DB2::Constants;
use DBD::DB2;
$DBI::dbi_debug = 9;
$dbh = DBI->connect("dbi:DB2:*LOCAL", "XXX", "XXX") or die;
$dbh->trace(1);
$stmt = 'SELECT * FROM librkml.tabelle';
$sth = $dbh->prepare($stmt) or die "prepare got error " . $dbh->err;
$sth->execute() or die "execute got error " . $dbh->err;
DBI::dump_results($sth);
1;
Und mit dem eingeschalteten Debug/Tracemodus bekomme ich in der QSH folgendes angezeigt:
***********************************************
Code:
perl -w /web/dbtest2.pl
Subroutine bootstrap redefined at /usr/local/lib/perl5/5.00502/os400/DynaLoad
er.pm line 97.
DBI::db=HASH(0xbcf00) trace level set to 1 (DBI 1.06-nothread)
New DBI::st (for DBD::DB2::st, parent=DBI::db=HASH(0xbcf00), id=)
<- prepare('SELECT * FROM librkml.tabelle')= DBI::st=HASH(0x2272d0) at db
test2.pl line 12.
<- execute= -1 at dbtest2.pl line 14.
<- fetch= ARRAY(0x10560) at DBI.pm line 567.
<- fetch= undef at DBI.pm line 567.
1, undef, undef
1 rows
<- DESTROY= undef during global destruction.
<- DESTROY= 1 during global destruction.
**************************************************
Bei DSPFFD zeigt es mir, das die Felder NAME und VNAME jeweils die codierte Zeichensatz ID 37 verwenden, aber das numerische Feld LFDN gar keine Zeichensatz ID angegeben wird. Ausgerechnet diese wird aber offensichtlich verarbeitet.
-
... du dumpst doch nur das statement handle raus, da fehlt z.B. ein fetchrow-array(), google ist dein Freund, da hilft eine Suche mit Perl DBI eine Menge weiter, z. B. https://de.wikibooks.org/wiki/Perl-Programmierung:_DBI
D*B
-
Ich hab ein weiteres Script, aber auf die gleiche Tabelle mit den Regeln angepasst:
Code:
#!/usr/bin/perl -w
use CGI qw(param);
use DBI;
use DBD::DB2::Constants;
use DBD::DB2;
# Ein Perl-Test f}r die "Info - HTML"
# $ich = param("wer");
# Test der DB Anbindung mit Perl auf AS/400
$dbh = DBI->connect("DBI:DB2:*LOCAL", "XXX", "XXX") or die "Ein Fehler: ".$dbh->err;
$sql = "select * from LIBRKML.TABELLE";
$sth = $dbh->prepare($sql) or die "Fehler: ".$sth->err;
$sth->execute() or die "Fehler bei Ausf}hrung: ".$sth->err;
print <<ENDE_HEAD;
Content-type: text/html
<html>
<head><title>Datenbanktest</title></head>
<body>
<table border='1'>
<tr><th>Name</th> <th>Vorname</th></tr>
ENDE_HEAD
while(my ($spalte1, $spalte2, $spalte3) = $sth->fetchrow_array())
{
print "<tr><td>".$spalte1."</td>\n";
print "<td>".$spalte2."</td>\n";
print "<td>".$spalte3."</td></tr>\n";
}
print "</table>\n";
print "</body>\n";
print "</html>";
und es dennoch gleich im QSH auf der Maschine ausführen lassen, mit dem gleichbleibenden Ergebnis:
Code:
perl -w /web/db2.pl
Subroutine bootstrap redefined at /usr/local/lib/perl5/5.00502/os400/DynaLoader.pm line 97.
Content-type: text/html
<html>
<head><title>Datenbanktest</title></head>
<body>
<table border='1'>
<tr><th>Name</th> <th>Vorname</th></tr>
<tr><td>1</td>
Use of uninitialized value at /web/db2.pl line 30.
<td></td>
Use of uninitialized value at /web/db2.pl line 31.
<td></td></tr>
</table>
</body>
</html>$
Und so sieht die Tabelle aus (ja, ich hab auch CCSID 65535 und 500 schon probiert):
Code:
Daten Feld Puffer Puffer Feld Spalte
Feld Art Länge Länge Position Verwend. Überschrift
LFDN GEPACK 3 0 2 1 Beide LFDN
Nullwert zugelassen
NAME ZCHN 20 20 3 Beide NAME
Nullwert zugelassen
ID des codierten Zeichensatzes . . . . . : 37
VNAME ZCHN 20 22 23 Beide VNAME
Feld variabler Länge -- Zugeordnete Länge: Keine
Nullwert zugelassen
ID des codierten Zeichensatzes . . . . . : 37
-
Ich denke mal "use of uninitialized value at ..." ist der Fehler.
Ggf. ist deine DBI-Version zu neu für deine V4R5-Version und verlangt Sachen, die noch nicht unterstützt werden. Hier musst du eine "Uraltversion" installieren, so aus den Jahren 1999/2000, die zum V4R5 kompatibel ist.
Alles andere macht hier keinen Sinn, da DBI schon vom Grundsatz her scheitert.
Das Problem ist hier, dass du ja DBI debuggen müsstest um den Fehler zu finden.
-
Dann scheint es langsam traurige Gewissheit zu sein.
Ich hab schon von CPAN die Altversion von 1999 herunter geladen und bereit gestellt.
Es gibt da zwar noch unter Source einige Quellen, da schau ich mal ob ein anders oder älteres DBI dabei ist. Ansonsten muss ich nochmal den Googel zu befragen.
Habt erst mall alle hier im Forum vielen Dank, für die Geduld und Hilfe! :-)
-
-
Nachdem wir nun fleißig gesucht und versucht haben bin ich am Ende im Netz "fündig" geworden, was den Misserfolg bestätigt. Zimindest ist das V4R5 eher zu "neu" für die bis dahin angebotenen Perl Versionen.
Aber gut, zumindest ist es Gewissheit, dass ich nicht "allein" bin/war und dieser Effekt auch auf amerikanischen Maschinen zu finden war:
http://computer-programming-forum.co...24050a5656.htm
-
Was hindert dich auf V4R4 zu gehen?
GG
Similar Threads
-
By Frank Hildebrandt in forum NEWSboard Server & Hardware Markt
Antworten: 2
Letzter Beitrag: 02-05-03, 16:32
-
By Matthias.Hayn in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 07-03-02, 14:17
-
By Matthias.Hayn in forum NEWSboard Windows
Antworten: 1
Letzter Beitrag: 07-03-02, 13:13
-
By delphix in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 18-02-02, 13:48
-
By Robi in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 28-01-02, 09:35
Tags for this Thread
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks