Ftp fra AS400 Negative værdier bliver forkerte.

Hvis datafelterne på AS/400 ligger pakket er det ikke altid nemt at få dem over som normale tal i en txt-fil. Kan dette være tilfældet ?

Tallene ligger i library på AS/400, som derefter hentes vha. ftp værktøj.

Yes, men felter kan være alfanumeriske, numeriske og så sandelig også pakkede, eksempelvis som her:
ODDCEN    Vis århundrede                A    1    1 
ODDDAT    Vis dato:    format- Job    A    2    6 
ODDTIM    Vis klokkeslæt                A    8    6 
ODLBNM    Bibliotek                    A    14    10 
ODOBNM    Objekt                        A    24    10 
ODOBTP    Objekttype                    A    34    8 
ODOBAT    Objektattribut                A    42    10 
ODOBFR    Frigivet lager: 0-ikke fr    A    52    1 
ODOBSZ    Objekt stør.: 9,999,999,9    P    53    10  0
ODOBTX    Beskrivelse                  A    59    50 
ODOBLK    Låst objekt: 0-ikke låst,    A  109    1 

hvor feltet ODOBSZ er P (pakket) og det giver som regel problemer ved overførsler.
Dem med A (Alfanumeriske) er repræsenteret på korrekt vis.

Så prøv at finde de enkelte felter og se hvordan de er defineret.

Jeg glemte lige at spørge, er det kun de negative værdier der er forkerte ?

Det er kun negative værdier der giver problemer. Det pågældende felt er numerisk.

Pakkede felter er som sådan også numriske felter - altså set fra AS/400. Netop fordi dette format er specielt, bør den ikke anvendes såfremt kommunikation med andre platforme skal finde sted - det være sig UNIX, PC etc.

Du kan lave en DSPFFD på filen og sende det til print - cut/paste det ind - så vi kan se definitionen.

Signed numeric - vil nok være den felttype som du skal bruge.....

Det er sikkert også signed numeric felter der bliver brugt, for ellers ville det ikke kun være de negative tal, der var ramt. Men også signed numeric felter giver problemer, når de konverteres mellem EBCDIC og ASCII tegnsættene.

Antager vi, at et felt er defineret som signed 9,2 (altså 9 cifre, heraf 2 efter decimalpunktet) og indeholder værdien 52.32, så vil det i EBCDIC blive repræsenteret som F0F0F0F0F0F5F2F3F2 (angivet som hex). Når dette bliver konverteret til ASCII ser det sådan ud 303030303035323332 (ligeledes angivet som hex).

Tager vi det samme tal som negativ (altså -52.32) bliver det i filen på AS/400 repræsenteret som F0F0F0F0F0F5F2F3D2. Angivelsen af, at tallet er negativt, gemmer sig således i den sidste byte, hvor en bit er sat anderledes. Når det bliver konverteret til ASCII bliver det helt forkert, for i en typisk ASCII fil vil man jo forvente, at der bliver placeret et minus foran tallet i stedet. Når FTP sender en AS/400 fil fra QLIB filsystemet (det filsystem der bruges af DB2 databasen) sker der en automatisk konvertering til ASCII, men den sker byte for byte og tager ikke hensyn til filens feltdefinitioner (der indsættes dog som standard en LF efter hver record, således at disse vil fremstå som linier i f.eks. Notepad, Excel o.lign.).

At sende en fil, hvor man kan risikere at der er negative tal direkte via FTP er således ikke en farbar vej. Jeg vil foreslå dig, at du i stedet først bruger kommandoen CPYTOIMPF (Copy to Import File) til at konvertere filen til f.eks. en semicolon-separeret CSV-fil på AS/400. Denne fil kan så let overføres og bruges direkte i f.eks. et regnearksprogram.

Signed numeric felter virker fint, når bare man har check på filens codepage på AS/400 - det er nemlig den som bliver brugt - har gjort det igennem flere år :-)

Men lad os første se definitionen...

--> pumba: Selv om en fil er angivet med en korrekt EBCDIC codepage (normalt 277 = dansk) og via FTP bliver oversat til CODEPAGE 819 (standard for FTP = ANSI), ændrer det altså ikke noget ved, at konverteringen sker rækkevist, byte for byte. Derfor vil selv en konvertering af et negativt signed numerisk felt (også kaldet zoned numeric field) ikke blive konverteret til et negativt ascii felt (sådan som de fleste programmer vil opfatte det). Du kan naturligvis skrive et program, som specifikt kan kan forstå det "oversatte" ascii talfelt, men så kan du ligeså godt skrive et program, som kan læse den oprindelige EBCDIC fil.

Mine kommentarer er dog baseret på "rene" numeriske felter, men jeg er ikke helt up-to-date med hensyn til output filer fra Query - det er længe siden jeg har brugt Query. Er det muligt at sætte en editcode på outputfelterne? I så fald bør man bruge editcode P (som placerer minus-tegnet foran tallet) i stedet for f.eks. editcode L, som placerer det bagefter tallet.

I havde ret. Det er et signed numeric felt. Jeg har desværre ikke mulighed for at lave en DSPFFD, da jeg ikke har adgang til en kommando linie.

Som jeg kan læse ud af jeres kommentare, er der ikke det store at gøre, når man ikke har andre muligheder end FTP import.

Du kan måske ikke bruge DSPFFD, men da du har adgang via ODBC kan du f.eks. også udføre følgende SQL, som vil give dig de samme oplysninger (eller i hvert fald de mest betydende i denne sammenhæng):

"SELECT COLUMN_NAME, SYSTEM_COLUMN_NAME, DATA_TYPE, LENGTH, NUMERIC_SCALE, COLUMN_TEXT
FROM QSYS2.SYSCOLUMNS
WHERE TABLE_NAME = '" + strTable + "' AND TABLE_SCHEMA = '" + strSchema + "' ORDER BY COLUMN_NAME"

... hvor strTable er navnet på den tabel hvis format du søger og strSchema er det bibliotek hvor filen befinder sig.

Selv om det ikke er helt det samme som DSPFFD, så smager det da lidt af det... :-)

Hov, du skriver jo faktisk ikke noget om ODBC adgang, men kun om FTP adgang. Det gør det jo unægteligt lidt sværere... :-(

Nej, jeg har desværre ikke ODBC adgang - kun FTP ellers havde det hele været meget nemmere.