Hello,
I have a textfile named TEST.TXT, which contains the following text

Hello
Hello, World
World

After I filedef the text file I use -READ to read a line of the file

-*loop implementation here
-READ READFILE, &LINE NOCLOSE;
-TYPE &LINE

but my ouput is

Hello
Hello
World


Anyone have any ideas on why the comma is breaking my string?

----------
WebFocus 7
Windows NT

yes. The comma in your -READ is causing the problem. Try -READ READFILE &LINE NOCLOSE

Darin,

This didn't work. Am I supposed to do something above this?

Try putting a length declaration on it.
-READ READFILE &LINE.A12. NOCLOSE

unfortunatly, that does not work because then I get

Hello Hello,W
orld Hello


Thanks for your replys Darin

If that's the case then your text file does not have end of line indicators. It's got to be something in the way your text file is set up. This code works:

SET HOLDLIST=PRINTONLY
TABLE FILE CAR
PRINT CAR NOPRINT
COMPUTE LINE/A20=IF COUNTRY EQ 'ENGLAND' THEN 'HELLO' ELSE
                 IF COUNTRY EQ 'JAPAN' THEN 'HELLO, WORLD' ELSE 'WORLD';
ON TABLE SAVE AS TEXTFILE FORMAT ALPHA
END
-RUN
-SET &LINE='';
-BEGIN
-READ TEXTFILE &LINE.A12. NOCLOSE
-IF &IORETURN NE 0 GOTO DONE;
-TYPE &LINE
-GOTO BEGIN
-DONE

Jud,

The -READ should have a length associated with the &variable,

-READ READFILE &LINE.12

Then give the APP FI an LRECL (Logical record Length)

APP FI READFILE DISK BASEAPP/READFILE.TXT (LRECL 12

Match the LRECL to the data and the length of the &variable to the LRECL.

The reason that Darin gets his to work is that the file is a fixed length, whereas your file is variable length, that is if you highlighted the data in a text editor, then the rows would show up as different lengths. The default for an APP FI is to have a record format of variable length (V), other option is fixed block (FB). In the older days we would code

FILDEF READFILE DISK D:\PATH\READFILE.TXT (LRECL 12 RECFM V
or
FILDEF READFILE DISK D:\PATH\READFILE.TXT (LRECL 12 RECFM FB

If you were to use FB on your file Jud, the results would go off again as it is variable length, but data from a report is always FB. Variable (V) will work on FB but not vice versa.

The NOCLOSE option is only required under some circumstances, say where you are running a report within the loop, emptying focstack, which closes the file in normal circumstances.

Jud,
You won't be able to read a sequential file with variable length records using -READ when the have commas.
Here is what I would suggest:

  
-* File jud2.fex
-* because I do not have the txt file, i'm creating it within the example
-*
FILEDEF JUD DISK JUD.TXT
-RUN
-* creating the data file
-WRITE JUD Hello
-WRITE JUD Hello, World
-WRITE JUD World
-RUN
!TYPE JUD.TXT
FILEDEF JUDMAS DISK JUD.MAS
-RUN
-creating the master file for the data file
-WRITE JUDMAS FILENAME=JUD, SUFFIX=FIX
-WRITE JUDMAS SEGNAME=JUD
-WRITE JUDMAS FIELDNAME=JUD, USAGE=A12, ACTUAL=A12, $
-RUN
-* reading the data and writing it to a SAVE file. this will make the data have fixed length records
-*
TABLE FILE JUD
PRINT JUD
ON TABLE SAVE
END
-RUN
-SET &L=&LINES;
-REPEAT #JUD &L TIMES;
-READ SAVE &LIN.A12.
-TYPE &LIN
-#JUD

I hope this helps.

Why would you not be able to -READ a file with variable length records with commas' in it, Daniel?

Works for me all the time, try it:

FILEDEF JUD DISK BASEAPP/JUD.TXT (LRECL 12
-RUN
-* creating the data file
-WRITE JUD Hello
-WRITE JUD Hello, World
-WRITE JUD World
-RUN

-REPEAT #JUD 3 TIMES;
-READ JUD &LIN.A12.
-TYPE &LIN
-#JUD

The comma in "Hello, World" is being interpreted as a delimiter, so it sees two dfata items and then READs the next data item from after the end-of-line marker.
You need a "READ" verb that reads to 'end-of-line' to READ the entire sequential record.

I'll look it up and Ah'll be back -

Anyone know what that verb is of-hand ?

Jud - can you provide the relevant part of the code you are using ?

This message has been edited. Last edited by: Charlz,

Charlz,

Have you actually tried this?

The comma CAN be interpreted a delimiter if the file is a comma delimited file, using commas in the -READ, this would be a a free format file, with variable length fields delimited by commas and the same number of fields per record.

This is not the case here, 1 record with 1 comma, read as a fixed format file of variable length.

Alan,

Thanks for the input - I've had similar problems in other languages, and I'm thinking that the comma appears to be what is terminating Jud's READ command.

I know that embedded commas can mess up comma-delimited files, making it look (to WF) like the record has more 'fields' than it actually has.

For example, "123 Maple Street, Apt 4" is one ADDRESS field, but looks like two.

This is not Jud's problem, but it points to a sequential READ problem with misplaced delimiters ?

I'm new to WF and am looking for differences between "READ-ENTIRE-LINE" and "READ-DELIMITED"
(I made the verbs up for illustration)

I'm looking for a distinct READ verb or variation that tells WF to "read to end of record" or "read to next delimiter" - haven't found it in WF yet though.

Is there such a command ?

This message has been edited. Last edited by: Charlz,

Charlz,

DM is simplistic. You can -READ a record with variables of fixed length using

-READ file &var1.a10. &var2.a12. etc.

If the file is variable length give the APP FI an LRECL, the -READ will stop at the end of line marker or the declared length, whichever is first.

For variable format, comma delimited you use

-READ file, &var1, &var2, etc.

the inclusion of the comma in the -READ statement is what declares it as comma delimited.

That's it as far as options go, and the 2 cannot be mixed.

If you have a comma delimited file with a variable number of fields, you are on your own and would have to read it as fixed variables and split the fields with functions.

The important point here is the use of the LRECL parameter, when using none report generated files, to ensure the WF knows what it is dealing with, which seems to be a forgotten part of the documentation.

Alan,

In your example, you pre-defined your file as Fixed with LRECL 12, so when you
-WRITE JUD Hello
in fact you are writing 12 characters.
Since Jud said he had a text file, I assumed his lines were not padded with spaces.
However, when you use a Master and read variable length records, there is no problem. A "feature" of Focus.
Hence my example.

Is your workload somewhat lighter now?

Danny,

Try this:

APP FI HELLO DISK BASEAPP/HELLO.TXT
-RUN
-WRITE HELLO Hello
-WRITE HELLO Hello, World
-WRITE HELLO Hello World
APP FI HELLO CLEAR
APP FI HELLO DISK HELLO.TXT (LRECL 12
-RUN
-REPEAT :LABEL 99999 TIMES
-READ HELLO &WORD.12.
-IF &IORETURN NE 0 GOTO :ENDLAB;
-TYPE &WORD 
-:LABEL
-:ENDLAB

The -WRITE produces a variable length record file whether you define an LRECL or not.

If you were to -READ this without reissuing the FILEDEF with the LRECL, there will be issues as WF WRITEs differently than READs.

You can read the file created in BASEAPP with an editor and it will have variable lengths, not fixed lengths; change the first APP FI to LRECL 12 and you will then not need the second APP FI.

The only way to achieve a fixed length with -WRITE is to have a character in the last position.

In fact you can use an LRECL of 1000 and &var.1000. for a -READ of a file of only 1 character and it will still work.

(And no, still v. busy.)

I think Alan just used 12 as a andom number for his LRECL in his example.

The WRITE section of Alan's example simply creates a file (which you could make with NotePad or whatever) :

Filename : XYZ.TXT
-------------
Goodbye, World
Hello,,,,
Hello,,, Again
-------------

The READ section simply reads commas as characters, not as delimiters.

LRECL just needs to be greater than the longest possible record you're going to READ.

In this case I used LRECL = 13,332 just for fun :

The FILEDEF XYZ DISK BASEAPP/XYZ.TXT (LRECL 13332)
-RUN
-* Note that I commented out this part after the first execution :

-* creating the data file
-*WRITE XYZ Goodbye, World0123456789abcdef
-*WRITE XYZ Hello,,,,0123456789abcdef
-*WRITE XYZ Hello Again0123456789abcdef
-RUN

-* This is the part that does the work :
-*--------------------------------------
-REPEAT #XYZ 3 TIMES;
-READ XYZ &LIN.A13332.
-TYPE &LIN
-#XYZ

That's it Charlz, you've got it down to a tee.

12 was random, but logical as it was the longest record that was in the file.

Alan,

I stand corrected! Thanks.

Thanks guys, it works now!

Recently, had to convert a table's 'email' column into an RCaster external distribution list and encountered similar parsing issues.

MY table's column was A250V and contained 1-6 comma separated email addresses (aaa@bbb.ccc, ...). Each table row had to be converted into 1-6 rows of 'aaa@bbb.ccc',,$' to drive RCaster's email process. A separate RCaster job was processed each row of the initial table.

I TABLE FILEd the initial table into a 1-column table of A250V fields.

I experimented with various FORMATs and found only 3 to be of any use:
- FORMAT COM surrounded the set of e-mail addresses with quotes ("aaa@bbb.ccc,aaa@bbb.ccc, ..."). -READ parsed this on the internal comma, placing a quote prefix on the 1st email and a quote suffix on the last one. The TRIM(,,,,,) function removed the prefix ok. but would not work on the suffex.
- FORMAT ALPHA wrote the set of addresses twice, prefixing the first copy with a 6-digit number representing the length of the string of emails addreses. Nothing but spaces separated the first image of the addresses from the second image. -READ could not parse this successfully, getting confused with the last address of the first image with widely separated first address of the 2nd image.

My solution was to use FORMAT WP, and artificially add 6 extra commas ( DEFINE C/A1=',' ; ) after the A250V field. WP forced the string of email addresses to an A250 that READ could comprehend. I began reading the WP file with enough 'dummy' -READs to skip past WP's rows containing "PAGE n", spaces, and columntitles. The 'good' read statement had 6 &vars which nicely parsed out as many email addresses as existed and filled the remaining ones with blanks values parsed from as many of the extra 6 commas as were necessary to make 6 parsed (sub)strings.

I always found the &var containing the final e-mail address to contain the balance of COM's or WP's 250 wide column, and, as before TRIM(,,,,,) would not shorten that &var, 'sucking' in the distant comma or quote. Fortunately, once each &var containing an email address was -WRITE'n into a line of the RCaster distribution list, RC didn't mind the longer blanks included as the suffix on the final email address.

[I once heard a computer programmer described as "One who makes a computer do things the designers never intended the computer to do."!]

This message has been edited. Last edited by: cburtt,

Not the way I would have approached a solution, but that's the beauty of WF. Lots of options.

I must be a WF programmer then - my FAVORITE thing to do is to make WF and RC do things that they were not intended to do.

I wonder if the OCCURS=VARIABLE could be used here.
I'm not sure if that can be done in combination of a comma delimited file.