>>Ok Guys! Sorry I was off the thread for a few days, but I wanted to answer Doris' question, "Why am I reprogramming Fox?" Well Doris you must be aware of some SET command or APPEND FROM argument which has of yet eluded me. Do me a favor and try this little test out. 1) Create a text file by opening a text editor and just typing into it WITHOUT inserting hard returns (No CRLF characters). Make sure to type a couple hundred characters in there for good measure. 2) Create a small .dbf table with 3 or four fields of 2 or three characters each. 3) Now use our highly esteem APPEND FROM command, APPEND FROM test.txt SDF.
>>
>>Doris and/or Dave, what happend on your machine? Do you know of some undocumented aurgument that tells Fox to break the strings according to the character length of the .dbf table. Not that this would change my reasons for using low-level file functions, I do things like input audits and conditionally post incoming tape data and un-packing 'packed binary' data from its original EBCDIC format. APPEND FROM is limited. Yes your right Doris, Low-level file functions can be a big performance hit. Sometimes I use a langauge a little closer to the hardware. But in many cases Fox's LL File functions allow me to read in, interpret and audit incoming data as it would normally come to me form an Standard 9 Track Tape.
>>
>>Dave, I never said you were a lazy programmer.
>>
>>JP
>
>You didn't say it, HE did! But I see your problem now, APPEND FROM will not handle Binary data or EBCDIC data format. You didn't mention that you were dealing with that type of data.
>
>As for your little test, I really didn't need to run it since we get files that vary from 800K to 80Meg from the Comptroller's office every >day (size depends on number of transactions for a given day) that only has a LF (a 'soft' return) at the end of the record line. Fox has >no problems handling this while the UNISYS-COBOL mainframe herfs all over itself. In fact, it is becoming apparent that the best way >for us to fix the problem is to run it through Fox BEFORE we upline to the MF.

Doris - Well, that explains it! The LF is the record delimiter that many mainframe files do not have. In most cases when mainframe data is written to tape it is intended for another mainframe. Typically these systems do not rely on CR or LF to delimit records. When data is transferred to a PC, the transfer script often inserts the CR or LF or both. My guess is the file you are getting has the LF inserted for YOUR benefit.

My tape data source comes from a third-party and I have no control over the way the data is supplied on the tape. So I have to accept it exactly as the IBM Standard for unlabeled 9 Track or 9400 Cartridge tape drives. Actually I have encountered many files with no record delimiters. I have seen lots of utilities on the PC which insert CRLF in files that need them for unsophisticated databases with APPEND functions but no low-level file functions. I need the LL file functions for reasons other than dealing with packed binary data, while APPEND from may be quicker when reading in an entire file using LL, if you are only posting a small portion of each record or only selected records, it often makes sense to interpret the records directly from LL rather that read in every record and then have to pass the file a second time just to post it.

Well this discussion has been fun but I think the 'horse is dead' Not much left to do but bury it! Have a great weekend Doris!

JP