Home > Archive > Cobol > October 2006 > Tab delimiter
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| hmitchell@cc.tt 2006-10-30, 9:55 pm |
| 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
| |
| William M. Klein 2006-10-30, 9:55 pm |
| X"09" is certainly the correct way to specify a HEX character. If that still
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
>
| |
| HeyBub 2006-10-30, 9:55 pm |
|
<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.
| |
| Richard 2006-10-30, 9:55 pm |
|
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
| |
| HeyBub 2006-10-30, 9:55 pm |
|
"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.
| |
| Richard 2006-10-30, 9:55 pm |
|
HeyBub wrote:
> 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.
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 ?
| |
| Donald Tees 2006-10-30, 9:55 pm |
| HeyBub wrote:
> "Richard" <riplin@Azonic.co.nz> wrote in message >
>
> 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.
>
>
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
| |
| Richard 2006-10-30, 9:55 pm |
|
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.
| |
| William M. Klein 2006-10-30, 9:55 pm |
| 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 determined
at the creation of the file and cannot be changed later. The records in a line
sequential file are delimited by delimiters. Each record can contain only
printable characters and record delimiters. One record is counted as one line."
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 User'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 align
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 Processing"
that includes a statement,
"4. If a record read from a line sequential file includes a tab, the tab code 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.
>
| |
| HeyBub 2006-10-30, 9:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:yJF0h.70246$R52.55878@fe07.news.easynews.com...
>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
> determined at the creation of the file and cannot be changed later. The
> records in a line sequential file are delimited by delimiters. Each record
> can contain only printable characters and record delimiters. One record is
> counted as one line."
>
> 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 User'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
> align 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
> Processing" that includes a statement,
>
> "4. If a record read from a line sequential file includes a tab, the tab
> code is not replaced by a blank."
>
>
When in doubt, do not trust the documentation.
So, I tested the above theory and, indeed, Fijutsu COBOL does replace tabs
in input with blanks to force alignment at bytes/columns 8, 12, 16, etc.
The compiler does NOT change other unprintable characters (x'00' x'01'
x'255') to spaces, but does include them as characters for counting purposes
to get to the next tab position.
| |
| Richard 2006-10-30, 9:55 pm |
|
HeyBub wrote:
>
> When in doubt, do not trust the documentation.
>
> So, I tested the above theory and, indeed, Fijutsu COBOL does replace tabs
> in input with blanks to force alignment at bytes/columns 8, 12, 16, etc.
So, you are now saying that you _can_ trust the actual documentation.
| |
| HeyBub 2006-10-30, 9:55 pm |
|
"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.
| |
| Richard 2006-10-30, 9:55 pm |
|
HeyBub wrote:
[color=darkred]
> No. The documentation I have - that pertains to the Fujitsu COBOL 85
> compiler - is completely silent on the above characteristic.
Version 4, that I initially quoted from, is COBOL85.
As it happens I also have a copy of the Cobol97 version 6 on a Windows
machine. Firing that up and looking in the documentation I find, in
just a few seconds, the exact wording that I had also found in the
version 4 and that Bill had found in the latest documents. It is in the
User's Guide on page 378 with examples on page 379 exactly where I
would expect anyone to look for it in Chapter 7 "File Processing",
"Using Line Sequential Files".
> 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.
It seems to me that there are a lot of things that are, to you,
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.
Before I posted the effects I tested them with a small sample program.
If you had done that _before_ you posted it would have saved a lot of
agro.
| |
| Robin Lee 2006-10-30, 9:55 pm |
| Richard wrote:
> 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.
>
As an aside, Microfocus (or at least the Microsoft version of it) had a
(-N) runtime switch to suppress tab expansion, as well as a system call that
could be executed from within the program to do the same. In the long run,
I found these to be so awkward that I instead wrote an assembly language
routine to do the chore of reading sequential files. This proved to be
quite reliable, and also allowed accommodating other non-printable
characters, as well as files with non-DOS line terminations ... files from
other systems with other variation of textual data files.
I haven't had to deal with this yet in Fujitsu... it's good to know ahead of
time that there's no way to work around it, other than perhaps preprocessing
the input file, as my assembly skills aren't what they used to be.
| |
| Richard 2006-10-30, 9:55 pm |
| Robin Lee wrote:
> As an aside, Microfocus (or at least the Microsoft version of it) had a
> (-N) runtime switch to suppress tab expansion,
That's not what it does. Well, not in any way that is useful. The 'N'
(Null) switch has been in Microfocus at least as far back as Level II
Cobol, as is the 'T' (Tab) switch.
But neither does quite what is normally meant by 'suppressing tab
expansion'.
When the Null switch is on (+N) on writing there will be a Null (x"00")
inserted before each hex character in the record less than x"1B". This
will make a tab into a x"00"x"09" pair. On reading these pairs will
not be expanded and the nulls will be stripped so that the record is as
it was when the WRITE was executed. It will still expand solo tabs.
When the Null switch is off (-N) there is no null insertion on writing
and tabs are expanded on reading.
If it is required to read 'tab separated' data from other programs then
it would be required to have the 'tab' preceeded in each case by a
null.
The Tab switch on causes writing to replace runs of spaces with a tab
character where appropriate. Tabs are expnaded on reading regardless of
this setting.
> as well as a system call that
> could be executed from within the program to do the same. In the long run,
> I found these to be so awkward that I instead wrote an assembly language
> routine to do the chore of reading sequential files. This proved to be
> quite reliable, and also allowed accommodating other non-printable
> characters, as well as files with non-DOS line terminations ... files from
> other systems with other variation of textual data files.
> I haven't had to deal with this yet in Fujitsu... it's good to know ahead of
> time that there's no way to work around it, other than perhaps preprocessing
> the input file, as my assembly skills aren't what they used to be.
You could call C routines. Just call fopen, fgets, fclose.
| |
|
|
>
> You could call C routines. Just call fopen, fgets, fclose.
For FUJITSU look for CBL_ IO routines.
| |
| Robin Lee 2006-10-30, 9:55 pm |
| Richard wrote:
> Robin Lee wrote:
>
>
> That's not what it does. Well, not in any way that is useful. The 'N'
> (Null) switch has been in Microfocus at least as far back as Level II
> Cobol, as is the 'T' (Tab) switch.
>
> But neither does quite what is normally meant by 'suppressing tab
> expansion'.
>
> When the Null switch is on (+N) on writing there will be a Null (x"00")
> inserted before each hex character in the record less than x"1B". This
> will make a tab into a x"00"x"09" pair. On reading these pairs will
> not be expanded and the nulls will be stripped so that the record is as
> it was when the WRITE was executed. It will still expand solo tabs.
>
> When the Null switch is off (-N) there is no null insertion on writing
> and tabs are expanded on reading.
>
> If it is required to read 'tab separated' data from other programs then
> it would be required to have the 'tab' preceeded in each case by a
> null.
>
> The Tab switch on causes writing to replace runs of spaces with a tab
> character where appropriate. Tabs are expnaded on reading regardless of
> this setting.
Thank you for the refresher. Of course you are right, and my recall of how
the switches work was blurry. But now I remember that it was the whole null
insertion kludge that made processing line sequential files so awkward. And
even with that you *still* couldn't read a tab delimited file. Truth is,
once I started using my own assembler routines I never again even thought of
the N and T runtime switches.
>
>
>
> You could call C routines. Just call fopen, fgets, fclose.
>
I figured something like that. But now Ski has posted a reference to CBL_IO
routines so I'll look them over in the docs, just in case I run across the
need someday.
Again, thanks for the refresher on MF line files.
| |
| William M. Klein 2006-10-30, 9:55 pm |
| I would be curious exactly what your documentation has. If you go to the LRM
and look at the READ statement, do you find a section called
"RULES FOR LINE SEQUENTIAL FILES"
If so, what does the first rule under that heading say? In the current LRM 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 User's
Guide" for the transfer rules of record data."
This is how I got pointed from the LRM to the USER GUIDE that talks about "tab
expansion". It may not be "supper-clear" - but it certainly IS documented that
"some conversion" may happen.
Again, I would really like to know what your LRM says. (I don't have an old
Fujitsu LRM handy)
--
Bill Klein
wmklein <at> ix.netcom.com
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12k7l6u7n4q375c@news.supernews.com...
>
> "Richard" <riplin@Azonic.co.nz> wrote in message
> news:1162065898.472448.301950@k70g2000cwa.googlegroups.com...
>
> 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.
>
|
|
|
|
|