|
Perhaps one of the rocket scientists knows, I don't know. -----Original Message----- From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On Behalf Of Phil Groschwitz Sent: Wednesday, December 27, 2000 7:14 PM To: RPG400-L@midrange.com Subject: RE: Unix API read() Richard, This looks good. Can I call this from an rpg pgm? It isn't one of the UNIX-like api's. The 400 I'm using doesn't have a c compiler. Without that I don't know if I can some how prototype it. Phil --- Richard Jackson <richardjackson@richardjackson.net> wrote: > Please look at fscanf(). That should help you > properly locate those > strings. > > Richard Jackson > > -----Original Message----- > From: owner-rpg400-l@midrange.com > [mailto:owner-rpg400-l@midrange.com]On > Behalf Of Phil Groschwitz > Sent: Tuesday, December 26, 2000 1:01 PM > To: RPG400-L@midrange.com > Subject: Re: Unix API read() > > > Thanks for all the input! > > I don't think this is my problem, though. > > It is a stream file that I'm reading. I read 1024 > bytes at a time, and scan for x'0D25'. I then > substring the 1024-byte string so that I get one > "record" which I then parse. The length between > x'0D25' should be 119. The problem is apparent upon > reading the stmf - before moving it to a db file > format: There are sometimes fewer spaces within the > record (prior to the x'0D25') although it should be > fixed width. For example, assume position 5 contains > a > 10 position string and position 20 also contains a > 10 > position string. This means position 15 to 19 > should > contain blanks. Usually does, but occasionally > there > are fewer blanks, causing the 10 position that > starts > at 20 to begin at 17. How do I handle that? In > notepad and edtf, the format is correct so I am > hopeful that there is a way to handle it - just have > to find it. > > Here's some snippets of what I'm doing: > > > D bytesRead s 10I 0 > D data s 2048 > D dataRead s 1024 > D dbrec s 200 > > C eval bytesRead = read(fileDesc > C : %addr(dataRead) > C : %size(dataRead)) > ------- > C eval data = %trim(data) + > C %subst(dataRead:1:bytesRead) > C eval length = %scan(x'0D25':data:offset) > ------- > C eval dbrec = %subst(data:offset: > length-offset+2) > > > Thanks again, > Phil > > > --- Ken.Slaugh@cm-inc.com wrote: > > > > Jim, you're right. The OS/400 native data base > > supports variable length > > strings. Compile a file with a DDS member with the > > following line of code: > > > > D VARDTA 5000 A VARLEN > > > > =-=-=-=--= > > > > Does the Unix API return the length of the data > > returned up to a maximum > > buffer length? Most do. If so, then substring the > > data in RPG with some > > thing like: > > > > c eval VarDta = %subst(APIData: 1: APIDataLen) > > > > > > > > Ken Slaugh (707) 795-1512 x118 > > Chouinard & Myhre, Inc. > > AS/400 Professional Administrator/MSE > > Client Access Specialist > > http://www.cm-inc.com/ > > > > > > > > > > Jim Langston > > > > <jimlangston@conexfr > To: > > RPG400-L@midrange.com > > eight.com> > cc: > > > > Sent by: > > Subject: Re: Unix API read() > > owner-rpg400-l@midra > > > > nge.com > > > > > > > > > > > > 12/26/00 09:49 AM > > > > Please respond to > > > > RPG400-L > > > > > > > > > > > > > > > > > > It seems from the data that it is being padded > > *before* the > > OD 25. So each record would be a different > length. > > > > DB2 files all have records of the same length. > > There are no > > variable length records (don't take that as an > > absolute, as I'm > > sure someone could come up with a SQL file that > has > > variable > > length records). > > > > Try creating the record length on the read > function > > to longer > > than the records are. That is, if you are > expecting > > 176 length > > records, actually ask the unix read function to > read > > 255 length > > records. The end of the record should be padded > > with spaces (x40) > > or maybe nulls (x00). > > > > I think the error is probably coming from you > > specifying 176 length > > records, and since the record is longer than 176 > the > > call is complaining > > that it didn't read the entire records, which it > > didn't. > > > > Regards, > > > > Jim Langston > > > > Phil Groschwitz wrote: > > > > > > Do you mean it pads within the record in order > to > > > align the data with the prior record? Or pads > > after > > > the crlf? How does edtf display these two hex > > > examples exactly the same when one has fewer > > blanks > > > before the crlf than the other? > > > > > > Thanks for your help. I want to be able to read > > in > > > this file and parse it but this is causing > > trouble! > > > > > > Thanks, > > > > > > Phil > > > > > > --- Rolf Mittag <rm@r-m-e-d-v.de> wrote: > > > > I think Notepad and EdtF are simply padding > the > > > > records which have > > > > different lengths with blanks. The EBCDIC "0D" > > and > > > > "25" stand for > > > > carriage return = end of line = end of record. > I > > > > marked them with "^" > > > > (caret). > > > > > > > > Rolf > > > > > > > > C1F0F1F2 F0F1F1F6 F0F0F440 F3F4F0F4 :A012 > 0116 > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact copyright@midrange.com.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.