Our site has a number of binary files that were copied from a mainframe running MVS to our AIX system when we ported our Adabas/Natural applications from the mainframe to AIX.
As we now need to read the data in these files, we need to be able to convert them to ASCII. I know the format of the original files.
When I try to read the file, I get a natural error #6220.
This occurs whether the record is defined as B10, A10 etc…
Can I use Natural or do I need to convert the file first using something else?
It really depends on how the files were transferred over to AIX in the first place.
If it is the porting project I think it is, I’m familiar with the database conversion but I wasn’t involved with any of the non-database data.
I suspect that FTP was probably used to transfer the datasets to AIX. You need to find out whether an EBCDIC → ASCII translation was performed at the same time. If you’re lucky, someone from the project team is still around and can help you out. If you are really, really lucky, the process was documented and you can look it up yourself.
The FTP ASCII translation works great if you are only dealing with alphanumeric data but the wheels fall off when packed or binary fields are present. As FTP has no understanding of the data structure, it simply converts as if the field is an alpha and turns each byte into its ASCII equivalent - not very useful. It might be possible to do a reverse conversion but I’m not sure how the FTP ASCII conversion handles non printing characters…
If it was a binary transfer then your packed and binary fields will be fine but you are going to need to translate the alphanumerics. If we are looking at fixed length records, it might be as simple as reading into a redefined binary variable, setting up your own translation table and doing a series of EXAMINE TRANSLATE USINGs. You’d probably need to define the workfile in your program as UNFORMATTED.
Try and have a look at the actual data with some sort of hex viewer to get an idea of what you are dealing with.
Of course in an ideal world, the best method is to convert all the packed & binary fields to alphanumeric before the transfer. Back in the real world where the migration budget isn’t infinite, pragmatic decisions are often made to not bother converting the myriad of files that are unlikely to ever be read again and to deal with the situation if/when it ever arises in the future (using someone else’s budget of course).
if you are translating strings from EBCDIC to ASCII as Graeme mentions for the binary transferred files, try the MOVE ENCODED statement for the string translations. Something like:
MOVE ENCODED #EBCDIC CODEPAGE ‘CP1041’ TO #ASCII
(Your EBCDIC code page may be something other than CP1041, of course)
Do you still have access to the original mainframe files? Translating the original mainframe files would probably be easier than figuring out how they were transferred to your AIX system.
I hadn’t seen the NAT6220 before, and had a little trouble forcing it to occur.
I downloaded (via FTP) a file twice. First, with ASCII conversion, to make it easy to verify that my program would read the file properly. Second, as BINARY, to maintain non-alphanumeric values.
Intending to process the file as text, I used .TXT as the extension. Here’s the program I used to read both files.
define data local
1 #wf1 (a250) init <'c:\ascii.txt'> /* <'c:\ebcdic.txt'>
1 #wrk (a133)
end-define
format ps=50 ls=134
*
define work file 1 #wf1 type 'UNFORMATTED'
read work 1 #wrk
display #wrk
end-work
end
Then I added an EXAMINE #wrk TRANSLATE statement to convert the EBCDIC contents to ASCII. (My files contained only alpha values, so that was simple.)
If you remove the “type ‘UNFORMATTED’” and change the extension to .SAG, you get the NAT6220. You can leave the .SAG extension, but you need the TYPE parameter to avoid the NAT6220.
