copytoimpf die 2.

[Robi]

Hi
ich bin mal wieder auf der AS400 bei der ich das http://newsolutions.de/forum-systemi...cpytoimpf.html
Problem hatte.

Bei einer anderen Datei sollen nun NUR die Blanks entfernt werden
also keine ' oder " nur feld1;feld2,feld3

Numerische Felder die 8,2 def. sind, sollen als 4,25;
geschrieben werden.
Auf der AS400 funktioniert RMVBLANK(*both) nicht.
Habe den selben Befehl bei mir auf der Kiste versucht und alle blanks sind weg.
Also versuche ich die VIEW Lösung von Birgitta.

Nur ...
wie caste ich die Numerischen Felder, das sie

a) keine führenden 0 haben
b) ein Komma an der richtigen Stelle haben

cast(trim(%editc(FELD:'K')) as varchar(10 )) FELD, geht nicht

ich steh aufm schlauch
Danke
Robi

[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