copytoimpf die 2.

[Fuerchau]

RMVBLANK ist leider Releaseabhängig.

In SQL einfach

char(myNum)

liefert linksbündig ohne Vornull den Dezimalwert als VARCHAR.
Ob "0,12" oder ".12" hängt vom aktuellen Jobwert Dezimaledit (I/J/*BLANK) ab.

[BenderD]

... wem das noch nicht reicht, der kann auch eine eigene Function schreiben, die kann ihm noch eine Währung dahinterschreiben, führende Nullen User abhängig zu- und weglassen (damit sich keiner weggelassen fühlt) und bis auf Deckchen drumherumhäkeln manches mehr. UDFs lassen sich wie SQL Functions verwenden, also auch in Views einbinden und für einige Huddeldatums Formate, ob Huddel raus oder Huddel rein, ist das manchmal das schickste.

D*B

RMVBLANK ist leider Releaseabhängig.

In SQL einfach

char(myNum)

liefert linksbündig ohne Vornull den Dezimalwert als VARCHAR.
Ob "0,12" oder ".12" hängt vom aktuellen Jobwert Dezimaledit (I/J/*BLANK) ab.

[Robi]

@beide
Danke

@Fuerchau
V5R4M0 in W. sollte aber identisch sein wie V5R4M0 in Rehburg-Loccum

Aber ...
Ich hab nun auch die Lösung !!

Es gibt auf der KD.AS400 eine DTAARA QCPTOIMPF
in der steht CPV5R2

Warum auch immer
Wenn die weg ist, funktioniert es !!

Info @alle

Wenn mal ein Befehl nicht wie beschrieben funktioniert,
sucht nach einer DTAARA die so ähnlich heist.

IBM scheint mit solchen Taschenspielertricks sich manchmal selber auf die Füße zu treten.

Gruß
Robi

[Fuerchau]

Vorsicht!
Diese DTAARA wird als Tipp für das Verhalten angegeben und muss explizit gesetzt werden.
Wenn also die DTAARA gesetzt ist, scheint es ggf. andere Programme zu geben, die dies benötigen.

Wenn du nun diesen Wert veränderst, kann es sein, dass andere Programme nun Schwierigkeiten bekommen.
Meistens läuft ja doch mehr als eine Software auf dem System.

Leider gibts da keinen Pauschalweg, da diese DTAARA in der QSYS und nicht in *LIBL gesucht wird.
Dadurch gilt diese Einstellung Systemweit.
Da CPYFRMIMPF aber durchaus parallel von verschiedenen Programmen verwendet werden kann, gibts leider keinen Weg, Probleme zu vermeiden.

Man könnte zwar mit ALCOBJ eine Exclusiv-Sperre setzen (falls berechtigt) und den Inhalt temporär verändern, allerdings kann eine DTAARA immer gelesen werden , hilft also nicht wirklich.

Ausserdem gilt dies nur als temporäre Lösung.

[Robi]

Hi,
das mit der dtaara ist schon klar, da denkt der Edv'er grade drüber nach (Ich glaube die wurde eingeführt beim Übergang von V5R2 auf V5R3, da es anfänglich Prob. mit den CCSID's bei V5R3 gab.)

aber noch was anderes ..
ein komplett leeres Feld wird nun als ein Blank dargestellt.
Ich (und vor allem der Empfänger) hätte 'nix' erwartet.

hat da noch einer ne Idee?
Thx
Robi

Nachtrag: selbst bei Birgittas View Lösung bleibt 1 blank in leeren Feldern

[Fuerchau]

Das würde ich nun doch mal der IBM melden und ansonsten auf SQL umstellen.

Das geht eigentlich ganz einfach:
Erstelle einen QMQRY mit
Select trim(CFeld) concat ";" concat char(NFeld) concat ";"
Concat """" concat trim(DelimitedCFeld) concat """;" ...
from Myfile
where ....

Per STRQMQRY in eine Ausgabedatei
Per CPYTOSTMF ins IFS

Dann bist du alle Sorgen los und kannst dich ganz auf die Formate konzentrieren.

Wenn du dann noch die Feldnamen für CSV vorne weg haben willst:

select distinct "Feld1;Feld2;..." from myfile
union all
select ......

[Robi]

Das würde ich nun doch mal der IBM melden und ansonsten auf SQL umstellen.

Hmm,
ich hab grade das gefunden.
Es liest sich wie "das ist Absicht mit dem einen Blank"
andererseits steht weiter unten, das variable Felder nicht so behandelt werden.
Ist hier jemand des Englischen mächtiger als ich und kann mir mal meinen Übersetzungsfehler zeigen ?

Sql umstellen ist schon klar aber ...
7 Dateien mit 100-150 Feldern Ich leide nicht an Lagweile ..

Gruß
Robi

[Fuerchau]

Arbeitest du mit oder ohne STRDLM ?
Wenn ohne, dann gibts mindestens 1 Blank:

A field of all blanks is interpreted as a field of one single blank character unless RMVBLANK *NONE is specified

Wenn mit, dann gibts auch leere Felder:

An empty string is defined as two string delimiters with no data between them

[Robi]

Ohne STRDLM

Es ist also, wie befürchtet.

it's not a bug, it's a Feature

also fleißig Feldnamen erfassen/kopiern

Danke
Robi

[Fuerchau]

Nunja, der Unterschied ist ggf. noch das NULL-Flag.
Je nach DB (z.B. MS-Access), wird eine leere Zeichenkette auch als NULL interpretiert.
Wenn das Feld ALWNULL nicht hat, muss ja mindestens ein Zeichen erscheinen.
VARLEN-Felder dürfen auch leer sein, nur CHAR-Felder ohne NULL werden wohl so behandelt.

Wenn mit STRDLM, ist das Ergebnis ja quasi nicht leer, nämlich ...;"";...
Ist zwar ein wenig inkonsequent, aber da hätte ich jetzt auch ein Leerzeichen erwartet.

Warum stört denn das eigentlich ?

Was das Erfassen angeht:
Lass dir doch vom OpsNav die Create-DDL's erstellen.
Dann benötigst du nur noch die Tipparbeit mit dem Drumherum.
Mach am besten direkt ein CREATE VIEW daraus und der OpsNav erstellt dir diese dann auch.

[Robi]

Warum stört denn das eigentlich ?

Phase 1: Muttergeselschaft des Kunden (MdK) : wir brauchen informationen als CSV Datei
Phase 2: Ich: hier, bitte
Phase 3: MdK: nein so nicht. Keine Trennzeichen und keine Blank in leeren Feldern

Phase 4: Fuerchau fragt: warum
Phase 5 bis ... keine Antwort

Ich danke Dir,
werde den OpsNav mal versuchen

Gruß
Robi

[Khholm]

Man könnte zwar mit ALCOBJ eine Exclusiv-Sperre setzen (falls berechtigt) und den Inhalt temporär verändern, allerdings kann eine DTAARA immer gelesen werden , hilft also nicht wirklich.


kann die wirklich immer gelesen werden, habe mal folgendes versucht:

ALCOBJ OBJ((HOLM/TESTDTA *DTAARA *EXCL))

und dann in einer anderen Sitzung:
===> dspdtaara holm/testdta

F3=Verlassen F4=Bedienerführung F9=Auffinden F12=Abbrechen
F13=Unterstützende Informationen F23=Anfangsmenü festlegen
Datenbereich TESTDTA in Bibliothek HOLM kann nicht zugeordnet werden.

das bedeutet aber doch, dass die DTAARA nicht gelesen wird, oder bin ich da jetzt auf dem Holzweg?

Karl-Heinz