Why I can read a file via UDLIST but I can't via cat command

[demecarv]

I went to ISPF Primary Option Menu, typed 3 (Utilities), 17 (UdList), the path (/WebSphere/myCell/myNode/AppServer/profiles/default/logs/ and typed ea (edit/ASCII) on left side of wsadmin.traceout. Then I can see read the file content although I got the warning:
Truncation warning. The data you are editing is variable length data with at
least one record that ends with a blank. Saving the data will result in
removal of any trailing blanks from all records. You can issue the PRESERVE
ON command if you don't want the blanks removed.
If I try read the same file by using the cat command on OMVS shell, I will see the characters messed up.
So my doubt is:
Why can I read the same file via UdList but I can't via OMVS? Should I use a different command in OMVS (e.g. oedit, oget, something like this)? What does the warning "The data you are editing is variable length data with at least one record that ends with a blank" mean? Suppose I want to edit this file safelly, should I type PRESERVE ON and it will garantee I don't corrupt the file format?

[Robert Sample]

What does the warning "The data you are editing is variable length data with at least one record that ends with a blank" mean?

It means that the record lengths vary from record to record (that is, they are not all the same fixed length) and that one (or more) records have one (or more) blanks at the end of the record -- in other words, it means precisely what it says. The warning is put out in case an application is expecting blanks at the end of the record (some applications do use variable-length records and can have spaces at the end of the record). Most logging applications, if they have spaces at the end of the record, don't care whether or not those spaces are preserved (unlike applications where the lack of those spaces may cause unpredictable results up to and including abends within the application).

The characters are NOT "messed up". A z/OS mainframe system uses EBCDIC as its code page. ASCII characters displayed on an EBCDIC system do not appear to be readable text. If you want to see the data in other applications on the mainframe, you'll need to convert the ASCII to EBCDIC before using oedit, obrowse, or even cat. The command to convert the data is

Code: Select all

iconv -f ISO8859-1 -t IBM-1047 input file name >output file name

and then you would use cat, oedit, obrowse (or whatever) on output file name.

oget is a Unix System Services command to transfer files between z/OS and Unix System Services -- you cannot use it to see the contents of a file.

[demecarv]

Thanks for the excellent explanation. A last question: can I use iconv exactly as wrote above to convert from ASCII to EBCDIC, edit it by oedit, and then convert it back to ASCII? The purpose would be to keep in same original format after I have edited it. If so, how could I do this?

[Robert Sample]

You can use the iconv command I provided to convert the file to EBCDIC and then use oedit on it. To convert it back to ASCII requires another iconv:

Code: Select all

iconv -f IBM-1047 -t ISO8859-1 ebcdic_file_name >ascii_file_name

[demecarv]

It worked. Thanks!

[Robert Sample]

Glad to hear its working.