This sounds like an error in whatever "filter" software they are using on the
remote UNIX side to convert the UNIX file (in which X'0C' is a FormFeed) to
whatever you are accepting. It sounds like they have a custom filter there.
Without knowning more about their UNIX/Linux setup, it is really difficult to
tell. For example, if they are using "dd" to convert the file to EBCDIC, is
that conversion the culprit?
Or do they have a custom filter program that converts X'0A' to a X'40' (space)
and should convert X'0C' to a X'41' ? That could explain your X'400C' pattern.
Without knowing details however, those are just guesses.
But the chances are good your problem is somewhere on the UNIX system.
Yours,
-Paul
--- Begin Message ---
Hi,
I have a customer whos is sending files from their VAX system to PSF on my
z/VM system via LPSERVE to the appropriate printer queue. When the files
come from their old VAX system I grab them from the SPOOL and they have
the appropriate ANSI CC (1 in byte one, column one to skip to top of
page). The same file sent from their Linux system has the correct
ANSI "1" in the first record, but later records that should have the ANSI
CC instead have x'400C' instead.
Since both versions of the file are coming to the same queue on my side,
I'm assuming the problem is on their end, but they are stumped, saying
when they send the file there are no ANSI CC "1"s anywhere on either.
Where is this FF translation handled? Are there Linux LPD settings that
will help?
Thanks in advance,
Peter
--- End Message ---
