From: John Allen
I am using CPYTOSTMF to copy a file to the IFS
When I look in the file using WRKLNK there are no blank
records
When I open the file using Note Pad on the PC it has a blank
record at the end of the file.
Well, "sort of". First off, I don't use Notepad for _anything_
critical. I use Wordpad.
What you're seeing with the "blank line" is the way NotePad deals with
files whose last line ends on 0D0A. Whether this is really a "blank
line" is kind of an interpretation, really. Most editors will show it
this way.
I thought this might be a Note Pad issue, sent the file to
be processed (to a 3rd party company)
They rejected the file because it has a blank record at the
end
Unusual behavior, but hardly unprecedented. This isn't a data base file
we're dealing with. It's a bucket of bytes. Each application makes up
its own rules.
I asked if they could just ignore it or delete it
Nope their software cannot process blank records, I have to
fix my file.
[snip]
Using WRKLNK Display Hex I do see a 0D0A at the end of each
record.
I do not have a 0D0A in my from file on the CPYTOSTMF
So CPYTOSTMF must add it,
If you specified "PC Text file" kinds of options, especially with *CRLF,
then that's exactly what was asked for.
Would the 0D0A on the last record
cause the blank line on PC applications?
Sort of. As I've noted, the line almost certainly isn't really "blank"
as such. There are no official record boundaries here. It's just the
scheme Notepad (and other editors) use to tell you that the last line
does end in 0D0A.
Is there a way to remove it only from the last record
Of course I get this problem 6:30PM the night before I fly
out to Common
Yes, there is a way to remove it. I assume the file is available in
ASCII on your PC?
First bring up Wordpad (from the Windows Command Line Wordpad is called
WRITE).
Then use Write/Wordpad to open your file.
Then, very carefully, go to the "blank line" at the end, using your
mouse to put the cursor at the beginning of the last "line" (this
supposed extra line we've been discussing). Carefully backspace so that
the cursor is at the very end of the "real last line."
Save the file.
A simple test example of mine, dumped in hex, IBM style, to show the
before-and-after:
Before, with the CR/LF at the end of every line:
61736466 0D0A6173 64660D0A 61736466 *asdf..asdf..asdf*
20616464 63726C66 0D0A * addcrlf..*
After, with the last line not ending in CR/LF:
61736466 0D0A6173 64660D0A 61736466 *asdf..asdf..asdf*
206E6F63 726C66 * nocrlf*
As you can see, the editor removes the trailing *CRLF when you edit it
that way under Wordpad.
The actual file looks like this, visually, in the "after" version:
asdf
asdf
asdf nocrlf<cursor here>
See if your vendor can handle the resulting file.
The only other thing that could somehow be happening is that some old
fashioned bit of code is inserting a Ctl-Z (hex 1A) at the very, very
end of the file. That's a rare DOS relic. Maybe you are doing a
Windows FTP through some old utility? That is now very rare and
unlikely, but I thought I would mention it if my suggestion above fails.
It causes trouble when it happens (the symptoms are just about the
same) and sometimes the Ctl-Z is not visible in editors when it is
present. But, the backspace trick probably works for that, too.
Larry Loen
Application Performance Group
midrange.com
