VERIFIED SOLUTION i

Customer's program that follows MailStream Plus has problem with hex(0A) that POSTBI is posting,

Product affected: MailStream Plus™, all versions.
Operating System: Linux

Issue

After running a job though MailStream Plus™ (MSP) a user sends the output Name-Address file (DD MSNAON) to a subsequent program of theirs.

On their UNIX machine, the process worked fine, but on his Linux machine their program was having a problem because of a hex(0A) that is in the records.  
The program was seeing it as an end-of-record Line Feed indicator.  (Hex '0A' is a LineFeed in ASCII.)

The customer asked if there was a setting in MSP to change the 'file type'  somehow to solve the problem.

Cause

The reason for the hex(0A) in the output files was that there was a POSTBI parameter in the job, and it had a B in position 19 which tells MSP to post the batch number into the output records in a 2-byte binary format.  That is what was putting the 0A in the records.

(But that does not explain the reason his Linux machine has the problem, while his UNIX didn't.)

There is no option to change the 'file type'  as the customer was wondering, to define it somehow so that his Operating System would not read the hex(0A) as a delimiter.
MSP just writes the file out as a text file.
The FILEDF MSNAON parameter can have either a F in position 17 for 'Fixed length' with no record delimiters, or an L there for Line Sequential with delimiter(s).
The user's job had an 'F'.

Resolution

UPDATED: May 14, 2019
User needs to determine why the Linux machine behaves differently than the UNIX machine, using the same file. Or, he can change the POSTBI position 19 to a D, so the batch code will be written in 5-byte Display (ASCII) format.

The POSTBI and FILEDF parameters, as well as all MSP parameters, are discussed in the MSP Reference Guide.   The Guide is available here-
https://www.pitneybowes.com/us/support/products/software/mailstream-plus-support.html