I am trying the following COZBATCH on a file with RECFM=FB LRECL=59 and it abends with S0C4 ( I even upgraded o 1.7.5), the abend information is given at the end here.
All I need is to add a X'0D' at the end of every record and other options like -l crlf etc don't seem to work.
//STDIN DD *
export LC_ALL=Ar_AA
export _BIDION=TRUE
export _BIDIATTR="@ls ×
orientation=ltr:ltr, typeoftext=visual:implicit, ×
shaping=shaped:nominal, numerals=national"
env
fromdsn -s IBM-420 -t IBM-420 -l rdw //DD:MYIN |
iconv -f IBM-420 -t UCS-2 |
iconv -f UCS-2 -t UTF-8 |
todsn -s UTF-8 -t UTF-8 -l rdw //DD:MYOUT
Abend Information
------------------
+IDI0002I Module /bin/iconv, program *@3@conv, offset X'240E': Abe
S0C4-X'4' (Protection Exception)
IEA995I SYMPTOM DUMP OUTPUT 965
USER COMPLETION CODE=4039 REASON CODE=00000000
TIME=14.51.08 SEQ=11574 CPU=0000 ASID=003C
PSW AT TIME OF ERROR 078D1400 862543D6 ILC 2 INTC 0D
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 062543D0 - 00181610 0A0D58D0 D00498EC
AR/GR 0: A6AB3EDE/84000000 1: 00000000/84000FC7
2: 00000000/0014EAA0 3: 00000000/00040004
4: 00000000/06214A38 5: 00000000/0014E604
6: 00000000/00000000 7: 00000000/27B2C2A8
8: 01FF000B/0014EAA0 9: 00000000/0015017E
A: 01FF000B/0014E604 B: 00000000/06254300
C: 00000000/0002FB58 D: 00000000/001512A0
E: 00000000/86213B1C F: 00000002/00000000
END OF SYMPTOM DUMP
COZBATCH -l rdw abends S0C4
The ABEND is occuring in "/bin/iconv", so you would need to report this problem to IBM.
But, since you are using "-l rdw", your input to iconv will have IBM RDW record prefixes, which aren't valid characters. Nevertheless, iconv shouldn't ABEND IMO.
BTW: in your fromdsn command, since you are using the same charset as source and target, it is unnecessary to specify one. Instead, you can use:
fromdsn -b -l rdw //DD:MYIN
If you just want to copy the data from the dataset without respect to records, just use:
fromdsn -b //DD:MYIN
If you want to copy the data from the dataset and replace record boundaries with a newline character (from the IBM-420 character set), then use this:
fromdsn -s IBM-420 -t IBM-420 //DD:MYIN
But, since you are using "-l rdw", your input to iconv will have IBM RDW record prefixes, which aren't valid characters. Nevertheless, iconv shouldn't ABEND IMO.
BTW: in your fromdsn command, since you are using the same charset as source and target, it is unnecessary to specify one. Instead, you can use:
fromdsn -b -l rdw //DD:MYIN
If you just want to copy the data from the dataset without respect to records, just use:
fromdsn -b //DD:MYIN
If you want to copy the data from the dataset and replace record boundaries with a newline character (from the IBM-420 character set), then use this:
fromdsn -s IBM-420 -t IBM-420 //DD:MYIN
Difference between COZBATCH and EDCICONV
There are differences in the output when EDCICONV and COZBATCH are run with comparable parameters.
For example an output produced by the EDCICONV utility produces correct output whereas the outpot from COZBATCH has some differences such as some data being incorrectly flipped.
This is probably not a problem with COZBATCH but with the underlying z/OS features. Do these two Utiities use same the same z/OS features to do the coversion?
For example an output produced by the EDCICONV utility produces correct output whereas the outpot from COZBATCH has some differences such as some data being incorrectly flipped.
This is probably not a problem with COZBATCH but with the underlying z/OS features. Do these two Utiities use same the same z/OS features to do the coversion?
Again, COZBATCH doesn't do any of this.
I think that you are referring to the fromdsn command (part of Dataset Pipes).
fromdsn uses iconv(), but because of the way that it handles records/lines and line terminators, it doesn't support multi bye encodings, except for UTF-8.
So, it seems reasonable to pipe fromdsn into iconv as you are doing, but NOT with "-l RDW", since this inserts 4-byte binary record length prefixes before each record.
I think that you are referring to the fromdsn command (part of Dataset Pipes).
fromdsn uses iconv(), but because of the way that it handles records/lines and line terminators, it doesn't support multi bye encodings, except for UTF-8.
So, it seems reasonable to pipe fromdsn into iconv as you are doing, but NOT with "-l RDW", since this inserts 4-byte binary record length prefixes before each record.