Tab delimiter

Dear guys,
I used frequently UNSTRING identifier DELIMITED BY "," with success.
Now, it is the first time I am trying to unstring a tab delimited file.
I tried DELIMITED BY X"09"; ...X"9"...X'9'...X'09'...TAB...without
success. In the best scenario, it only unstrings the 1rst. field.
Currently, I am using Fujitsu COBOL85.
When I compile using "X9" or X'9' or X'09' this is the error:
JMN1028I-S  NUMBER OF HEXADECIMAL CHARACTERS(0 THROUGH 9 AND A THROUGH
F) OF HEXADECIMAL NONNUMERIC LITERAL MUST BE MULTIPLE OF 2. ZERO IS
ADDED TO THE LAST CHARACTER.
I will appreciate if anyone can help me.
Thanks

X"09" is certainly the correct way to specify a HEX character.  If that stil
l
doesn't work, you could use the special-names paragraph to define a
special-character.

--
Bill Klein
wmklein <at> ix.netcom.com
<hmitchell@cc.tt> wrote in message
news:1161980352.958560.301300@m73g2000cwd.googlegroups.com...
> Dear guys,
> I used frequently UNSTRING identifier DELIMITED BY "," with success.
> Now, it is the first time I am trying to unstring a tab delimited file.
> I tried DELIMITED BY X"09"; ...X"9"...X'9'...X'09'...TAB...without
> success. In the best scenario, it only unstrings the 1rst. field.
> Currently, I am using Fujitsu COBOL85.
> When I compile using "X9" or X'9' or X'09' this is the error:
> JMN1028I-S  NUMBER OF HEXADECIMAL CHARACTERS(0 THROUGH 9 AND A THROUGH
> F) OF HEXADECIMAL NONNUMERIC LITERAL MUST BE MULTIPLE OF 2. ZERO IS
> ADDED TO THE LAST CHARACTER.
> I will appreciate if anyone can help me.
> Thanks
>

<hmitchell@cc.tt> wrote in message
news:1161980352.958560.301300@m73g2000cwd.googlegroups.com...
> Dear guys,
> I used frequently UNSTRING identifier DELIMITED BY "," with success.
> Now, it is the first time I am trying to unstring a tab delimited file.
> I tried DELIMITED BY X"09"; ...X"9"...X'9'...X'09'...TAB...without
> success. In the best scenario, it only unstrings the 1rst. field.
> Currently, I am using Fujitsu COBOL85.
> When I compile using "X9" or X'9' or X'09' this is the error:
> JMN1028I-S  NUMBER OF HEXADECIMAL CHARACTERS(0 THROUGH 9 AND A THROUGH
> F) OF HEXADECIMAL NONNUMERIC LITERAL MUST BE MULTIPLE OF 2. ZERO IS
> ADDED TO THE LAST CHARACTER.
> I will appreciate if anyone can help me.
> Thanks

Here's the one permutation you evidently didn't try (but that works well):

01  TAB    PIC X VALUE X'09'.

UNSTRING something DELIMITED BY TAB INTO Field-A Field-B etc.

hmitchell@cc.tt wrote:

> I used frequently UNSTRING identifier DELIMITED BY "," with success.
> Now, it is the first time I am trying to unstring a tab delimited file.

It is unlikely to work as Fujitsu, and others, will do tab-expansion
when reading a LINE SEQUENTIAL file.

"""If there are tab characters in an input record, spaces are inserted
to align the following characters to preset tab positions. The tab
positions are 1, 8, 12, 16, ...."""

> I tried DELIMITED BY X"09"; ...X"9"...X'9'...X'09'...TAB...without
> success. In the best scenario, it only unstrings the 1rst. field.

Yes, that will be the exact effect given the tab expansion that is
done.

> Currently, I am using Fujitsu COBOL85.
> When I compile using "X9" or X'9' or X'09' this is the error:
> JMN1028I-S  NUMBER OF HEXADECIMAL CHARACTERS(0 THROUGH 9 AND A THROUGH
> F) OF HEXADECIMAL NONNUMERIC LITERAL MUST BE MULTIPLE OF 2. ZERO IS
> ADDED TO THE LAST CHARACTER.

"X9" is the two characters 'X' and '9'.  X'9' will become hex '90' due
to addition of zero.  X'09' should give the correct tab character, but
you will never see one in an input line sequential file unless you can
find a way with a compiler or runtime option to disable tab expansion.

> I will appreciate if anyone can help me.
> Thanks

"Richard" <riplin@Azonic.co.nz> wrote in message > 
>
> It is unlikely to work as Fujitsu, and others, will do tab-expansion
> when reading a LINE SEQUENTIAL file.

I don't think the presence of a "tab" character [X'09'] makes any difference
to Fijutsu COBOL. The word "TAB" isn't mentioned in their extensive
documentation. Their definition of LINE SEQUENTIAL file simply says "...
consists of records delimited by delimiters(!). ...one line consists of
printable characters and record delimiters...."

And that's about it.

HeyBub wrote:

> I don't think the presence of a "tab" character [X'09'] makes any differen
ce
> to Fijutsu COBOL. The word "TAB" isn't mentioned in their extensive
> documentation. Their definition of LINE SEQUENTIAL file simply says "...
> consists of records delimited by delimiters(!). ...one line consists of
> printable characters and record delimiters...."
>
> And that's about it.

The quote I made was directly from a Fujitsu manual, actual paper
printed copy "Fujitsu COBOL 4.0 User's Guide for Windows Vol 1" pp231.

The exact same wording is in the NetCOBOL for Linux User's Guide on
page 137, with examples. I would be surprised to not find it in the
NetCOBOL for Windows User's Guide.

I had previously determined this was the case some years ago and I
retested this with another Fujitsu compiler, version 7 for Linux,
before posting and found it to be true. What actual testing have you
done to determine how they treat tab characters in line sequential
files ?

HeyBub wrote:
> "Richard" <riplin@Azonic.co.nz> wrote in message > 
>
> I don't think the presence of a "tab" character [X'09'] makes any differen
ce
> to Fijutsu COBOL. The word "TAB" isn't mentioned in their extensive
> documentation. Their definition of LINE SEQUENTIAL file simply says "...
> consists of records delimited by delimiters(!). ...one line consists of
> printable characters and record delimiters...."
>
> And that's about it.
>
>
Fujitsu very definitely expands tabs while reading line sequential
files.  I believe there is a setting that allows you to turn it off, but
the default is to expand tabs.

Donald

Donald Tees wrote:
>
> Fujitsu very definitely expands tabs while reading line sequential
> files.  I believe there is a setting that allows you to turn it off, but
> the default is to expand tabs.

There is no runtime option that I have been able to find.  The is
CBR_TRAILING_BLANK_RECORD to suppress the trailing blanks on writing,
but nothing that I know of for tabs on reading.

There is a TAB compiler option, but this controls what the compiler
does with tabs in the source file, and does not affect the program
running.

I found the following in the current LRM,

"2. The ORGANIZATION IS LINE SEQUENTIAL clause specifies that the logical
organization of the file is line sequential. The file organization is determ
ined
at the creation of the file and cannot be changed later. The records in a li
ne
sequential file are delimited by delimiters. Each record can contain only
printable characters and record delimiters. One record is counted as one lin
e."

that doesn't say what HAPPENS to "non-printable" characters, just that they
aren't supported. Later it says,

"1. When a READ statement has been executed for a line sequential file, some
record data may be transferred to the internal format. Refer to "NetCOBOL Us
er's
Guide" for the transfer rules of record data."

and that lead me to the final answer (in the User Guide),

"If there are tab characters in an input record, spaces are inserted to alig
n
the following characters to preset tab positions. The tab positions are 1, 8
,
12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, 64, 68, and 72. If a tab
 is
present at a character position beyond 72, it is read as a single space."

I have never used it, but there is a reference to "High-Speed File Processin
g"
that includes a statement,

"4. If a record read from a line sequential file includes a tab, the tab cod
e is
not replaced by a blank."


--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1162015308.745215.256280@e3g2000cwe.googlegroups.com...
>
> Donald Tees wrote: 
>
> There is no runtime option that I have been able to find.  The is
> CBR_TRAILING_BLANK_RECORD to suppress the trailing blanks on writing,
> but nothing that I know of for tabs on reading.
>
> There is a TAB compiler option, but this controls what the compiler
> does with tabs in the source file, and does not affect the program
> running.
>

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1162065898.472448.301950@k70g2000cwa.googlegroups.com...
>
> HeyBub wrote:
> 
>
> So, you are now saying that you _can_ trust the actual documentation.

No. The documentation I have - that pertains to the Fujitsu COBOL 85
compiler - is completely silent on the above characteristic. Whether they've
revised the documentation and you have the newer set or whether you
concocted a scam out of whole cloth is, to me, unknown. All I'm saying is
that the results do not match the impression left by the documentation that
came with the compiler I use.