Differences in report output data after applying PTFs in Linux

Products

• Easytrieve Report Generator

Issue/Introduction

After applied Easytrieve for Linux PTFs LU02928 and LU02929, the report output data appears to be different compared to previous versions.

Previously, report data was output as x'00', but now it seems you can choose between x'20'(space character) or x'30' (number zero).
Has the report data that was previously output as x'00' changed?

Environment

Easytrieve for Linux

Release 11.6

Cause

LU02928 and LU02929 caused this incompatibilities.
Regarding x'30' bytes in their report certainly not a fill artifact at all.
It's a genuine computed value. 
On distributed(ASCII) platforms, a real numeric display/zoned field holding an actual value of zero legitimately renders each zero digit as x'30'(ASCII '0').

Resolution

How to make it work as before

To restore the original x'00' fill behavior for uninitialized report fields, explicitly set the runtime option:

 FILEFILL(Z)

This is an execution-time option. Set it via the site's options-table mechanism used to control Easytrieve runtime options, on the Linux/distributed system where the report programs run.

Also stop relying on the runtime's default fill behavior at all: explicitly initialize every field (e.g., MOVE ZEROS/MOVE SPACES or an INITIAL value) before it's written to a report. That makes the output deterministic and immune to any future changes to FILEFILL or its default.