i'm running the following piece of code.
define variable memFile as memptr no-undo.
define stream callrec.
set-size(memFile) = 10. /* set the size of the memptr */
import memFile.
output stream callrec to value("/tmp/test.out").
export stream callrec memFile.
output stream callrec close.
set-size(memFile) = 0. /* de-allocate the memory */
input close.
I'm running it with the following command
cat foo.txt | $DLC/bin/_progres -b $DBDIR/$PARM -p foo.p
Foo.txt looks like this
0123456789
My expectation would be that test.out contains 0123456789 however it contains ˆØÈ<NUL>ˆØÈ<NUL><SOH>€ where <NUL> and <SOH> are their respective character codes (ascii 0 and ascii 1).
If I am doing somethign wrong please let me know. I am able to succeed by using readkey's however, they were causing significant performance issues with our clients.
It worked for me on my Visa / DOS box.
are you sure you're not running into some kind of codepage issue?
try:
$DLC/bin/_progres -b $DBDIR/$PARM -p foo.p
and make sure "cat" isn't doing anything odd.
Thanks for the reply Tim.
I tried redirecting stdin as you recommended with similar results.
I'm running on Red Hat Enterprise Linux v4.
If I add output stream myDebug memFile. Statments before and after the import stream foo memFile. line both of the outputs are the same as though memptr is pointing to junk data and is never getting updated with the import stream line.
Something that's probably not in the docs is that strings need an extra byte to store a trailing null, so any memptrs that contain a string need to have one more byte allocated than the max storage size. So, in this case try setting your memptr size to 11 instead of 10.
1) Either way shouldn't it have still read the 10 characters and just not appended the null terminator?
2) Shouldn't it be reading it as binary data? If not is there away to specify to read it as binary.
This was a simplified example of what we were actually trying to accomplish. What I need to do is this. I have a binary file whose contents is being cat'd, piped, however you want to think of it it through standard input. We know ahead of time how many bytes we want to read. Our current implementation uses readkey and works but is slow and pegs the cpu. So if there is a better implementation we would be happy to implement. Data needs to come through standard in.
Thanks,
~Justin
I agree the code you supplied should work on your system - that it's not implies something really strange is going on.
What happens if you do an "import unformatted" into a character variable? Does it get the right information?
BTW - I also provide professional services in ABL development. If you need more responsive help drop me a line at timk at tdkcs dot ca