Re: Using CPYTOSTMF to TXT file PC sees extra record

John Allen wrote:

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.

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

I asked if they could just ignore it or delete it
Nope their software cannot process blank records, I have to
fix my file.

Here is what the end of the file looks like with WRKLNK
5501750007109397588696XXXXXXNE 7,730.34 01

5501750007109392541782XXXXXXN 24,796.35 01 5501750007109391907528XXXXXXANY 2,042.31 01 5501750007109392824989XXXXXXNE 10,353.27 01

5501750007109396666959XXXXXXNICA 6,555.63 01

************End of Data********************


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, Would the 0D0A on the last record
cause the blank line on PC applications?
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

It is not helpful to state this, but /technically/ there is no blank line\record. Every /record/ of data is terminated by a *CRLF, and it is the choice of the program that reads that stream, how it wants to project that information to the user. Presumably that was what was requested; i.e. ENDLINFMT(*CRLF) where *CRLF requests that a "Carriage-return followed by line-feed is appended to the end of each line."

For a program which does not present the data, just reads the data for another purpose, it is really inexcusable that the program does not recognize a null string followed by end of file as equivalent to just an end of file condition. This is not an extremely common complaint as I recall [albeit familiar], but I am surprised there is [still] no parameter and\or special value to request that the last record should not include the end of record designation, solely to appease the poorly programmed readers of the data. There are some invocations of tools like /sed/ which rewrite the file without the last two bytes; maybe even some programs specific to the task of /cutting the tail/ of the stream. I did a quick web search, but I did not find a link right away. I believe this same issue has been a topic on this group\list in the past; i.e. should also be search-capable directly on the archives.

I am not sure if CPY will work any differently or even able to make a desirable copy. However if the file.mbr from which the data is copied using CPYTOSTMF includes the EBCDIC version of the *CRLF when it is generated, the last row is not similarly suffixed, then I believe ENDLINFMT(*FIXED) will resolve the issue. Hmmm... I am now thinking this is also what is required to get CPY to work instead of CPYTOSTMF.

Regards, Chuck