Actually the stream file gets transferred to the Wintel server using the
Connect:Direct utility. It is transferred from i5 to Wintel via a
mainframe. Somewhere along the line, C:D interprets the ending "null
line" as a line of "@" characters and this is what causes the problem
with the Wintel app as the app sees the "@" string as the last record
and so fails validation.
I don't know how the 3rd party app will handle the trailing x'0000' -
it's possible that it will be ignored but it rightly objects to an extra
row of garbage. I'll see how the testing goes.
Thanks,
Keith
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: 15 July 2009 15:43
To: RPG programming on the IBM i / System i
Subject: Re: Updating Text Data in a Stream File
It's a "stream file"...just a stream of bytes. You can't insert data or
delete data from it.
You'd have to read the data from one file and write it out to another
taking care to not write the final two bytes.
You'd probably be better off simply creating the file yourself. Plus
it'd perform better.
I'm surprised your Windows app has a problem with the final CRLF, there
really isn't a "null line" as displayed by your text editor, look at the
file in hex to see that it simply ends after the final x'0D0A'
I'd be very surprised if an app that can't handle a final CRLF can
handle having those two bytes being x'0000'
You might check with the app, but perhaps it would work with a different
record delimiter. Or perhaps you can use DTAFMT(*FIXED)
HTH,
Charles
On Wed, Jul 15, 2009 at 10:06 AM, McCully, Keith (Insurance, Technology
Services)<Keith.McCully@xxxxxxxxx> wrote:
I have an ASCII Text File in the IFS (Code Page 819) populated by
CPYTOIMPF. A feature of this command is that line endings CR & LF are
created (ASCII 0D & OA). However, this creates a null line at the end
of the text file caused by the LF on the final 'real' line. The lines
in this file are in variable length CSV format and the file will be
sent to the Wintel platform.
Looking back through the archives shows a number of postings on this
topic and suggestions on how to resolve the problem. One way that I'm
following, is to remove the CRLF from the final row but my question is
how to achieve this using a combination of RPG and QC2LE APIs?
So far, using RPG, I have been able to replace the CR & LF by 2 null
(00) bytes by using a combination of the lseek and write APIs. Lseek
is used to get the offset of the CRLF bytes for the last line and
write to replace the CRLF with nulls. This works in as much as I lose
the null line but, ideally, I would like just to delete the CRLF from
the final line rather than replace it but I'm not sure if this is
possible?
It may well be that my replacement with double null will work for the
Wintel application but, due to certain factors, I'm unable to test
that right now.
Thanks,
Keith
The Royal Bank of Scotland plc, Registered in Scotland No. 90312.
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Authorised and regulated by the Financial Services Authority.
This e-mail message is confidential and for use by the addressee only.
If the message is received by anyone other than the addressee, please
return the message to the sender by replying to it and then delete the
message from your computer. Internet e-mails are not necessarily secure.
The Royal Bank of Scotland plc does not accept responsibility for
changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by The Royal Bank of Scotland plc in this regard and the
recipient should carry out such virus and other checks as it considers
appropriate.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
*** WARNING : This message originates from the Internet ***
The Royal Bank of Scotland plc, Registered in Scotland No. 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Authorised and regulated by the Financial Services Authority.
This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
midrange.com
