Why I can read a file via UDLIST but I can't via cat command
Why I can read a file via UDLIST but I can't via cat command
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?
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
- Global Moderator
- Posts: 1895
- Joined: Fri Jun 28, 2013 1:22 am
- Location: Dubuque Iowa
Re: Why I can read a file via UDLIST but I can't via cat command
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).What does the warning "The data you are editing is variable length data with at least one record that ends with a blank" mean?
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
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.
Re: Why I can read a file via UDLIST but I can't via cat command
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
- Global Moderator
- Posts: 1895
- Joined: Fri Jun 28, 2013 1:22 am
- Location: Dubuque Iowa
Re: Why I can read a file via UDLIST but I can't via cat command
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
- Robert Sample
- Global Moderator
- Posts: 1895
- Joined: Fri Jun 28, 2013 1:22 am
- Location: Dubuque Iowa
Create an account or sign in to join the discussion
You need to be a member in order to post a reply
Create an account
Not a member? register to join our community
Members can start their own topics & subscribe to topics
It’s free and only takes a minute