Tom

For example, you can now specify options for trimming leading/trailing blanks.

In any case, the creation of a view to define how you want columns handled may be your best choice. E.g.,

RIGHT(TRIM('00000' concat CHAR(SEQN)),5)

…should take a 5-digit numeric ‘sequence’ column and convert the significant digits to characters, then add five zeros to the front, trim the result, and take the five rightmost remaining characters.

Rather than coding the “5″ at the end of the RIGHT() function, LENGTH(SEQN) could be used for a NUMERIC column. Using LENGTH(), such a column specification could be generalized more in order to determine how many zeros should be accounted for at the beginning.

The STMFCODPAG() option probably should be *PCASCII, especially when you are creating the streamfile. You have the ability on the AS/400 to do the work in EBCDIC or ASCII, in a bunch of different CCSIDs. Windows can also handle data in most kinds of encoding. But it’s not always clear on how to get the two sides to agree across a network connection.

FTP, for example, commonly transfer in either text or binary mode. In binary, the bits are copied directly. In text, the bit patterns are translated from whatever encoding is on the source system to the encoding on the target system. But FTP handles every record as a single string. It doesn’t recognize when there are different kinds of fields such as packed or binary embedded within the string.

Windows network transfers are similar. If you don’t take care to encode all of each record properly on the AS/400 side, Windows will apply its own rules. By specifying *PCASCII, you are preparing each of the bytes in the expectation that Windows networking (or FTP or some other transfer methods) will be copying the file.

Note that the *PCASCII encoding can also be handled by the AS/400. If you use DSPF to view the streamfile after you create it, it should be perfectly readable.

Tom