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

[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

[Robi]

Hi,
ich hab's nun so

 CHGVAR VAR(&QSH) VALUE('SED s/''; ;''/'';;''/g' *BCAT &von *BCAT '>' *CAT &nach)
             STRQSH     CMD(&QSH)

gelöst

Gruß
Robi