To view or edit files on a mobile device you need a viewer, an editor or an application that can read and interpret the content in a file. For example, to view a photo, the LongReach app opens the photo software on the mobile device; it does not read the file content and render the photo image. Safari is the default viewer when no specific viewer or application is available.
LongReach treats files as binary. Therefore, a file on the server is the same as the copy of the file on a mobile device. No encoding conversions occur for files such as images, photos, PDFs, video recordings, audio recordings or Microsoft Word documents.
UTF-8 and CCSID 1208 is the encoding that the LongReach app applies to all files it transfers from a mobile device to a LongReach server. This means that programs on the server can read and interpret the content of these files and the IBM i operating system takes care of encoding conversions.
LongReach is not concerned with file content. The text editor in the LongReach app is the one exception and in this case the LongReach app is, itself, the viewing and editing application.
Creating a text file using the LongReach app and transferring it to the LongReach server will not cause encoding errors as the LongReach app encodes text files it creates or edits as UTF-8 with a CCSID of 1208.
Possible causes of encoding errors are files created by software on IBM i servers are as follows :
• LongReach regards EBCDIC files without a .txt suffix as binary and the file will remain unchanged when transferred to the LongReach app on a mobile device. If no application is available as the file viewer, the LongReach app will use Safari to render the file, and of course what you see is most likely nonsense.
• EBCDIC files with a .txt suffix will be opened by the LongReach app’s text editor and it will try to render the content which is also likely to be nonsense.
The simplest way to use EBCDIC files with the LongReach server is to copy the files, add a .txt suffix and set the encoding as UTF-8 and CCSID 1208. The copy command includes parameters to specify encoding as UTF-8 and CCSID 1208. This method removes the need to amend any software that creates the files and also ensures that the file content is understandable on a mobile device. Alternatively, you could change the software that creates the files to use UTF-8 and CCSID 1208 (assuming you have the source code).
Why not perform the copy automatically? LongReach is not concerned with file content, except for text files it creates on the mobile device and these are encoded correctly. Therefore, LongReach does not need to convert any files. If the LongReach server were to convert files, how does it know which files to convert? The .txt suffix might be an indicator. But then the LongReach server would have to interrogate the encoding properties of each .txt suffixed file to find files that are not UFT-8 and CCSID 1208 (because converting every file with a .txt suffix for every file transfer to a mobile device will generate additional work and slow the file transfer).
Bottom Line …. It’s only .txt files on the server that contain EBCDIC data that need conversion before being written to the IFS. Every other file type is sweet. An RPG program has to do the creation (writing) of each file to the IFS. When it comes time to write the .txt file, get the program to convert the EBCDIC .txt file to UTF-8 on the way in. Simple. Surely.