Home > Archive > Cobol > February 2007 > Creating tab delimited files
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]
| Author |
Creating tab delimited files
|
|
| jmoore207@gmail.com 2007-02-21, 6:55 pm |
| I need a little help with imports and exports programs. I have created
many comma delimited programs, I am having an issue with tab delimited
files and numeric fields. I have written an export program that
creates a tab delimited file from an indexed file. I have also written
an import that would use the tab delimited file and update or create
an index field. I am having an issue with numeric fields. Does anyone
have any good examples of these. I am using Acucobol in a Solaris
environment. Thank you
| |
| HeyBub 2007-02-21, 6:55 pm |
| jmoore207@gmail.com wrote:
> I need a little help with imports and exports programs. I have created
> many comma delimited programs, I am having an issue with tab delimited
> files and numeric fields. I have written an export program that
> creates a tab delimited file from an indexed file. I have also written
> an import that would use the tab delimited file and update or create
> an index field. I am having an issue with numeric fields. Does anyone
> have any good examples of these. I am using Acucobol in a Solaris
> environment. Thank you
What kind of problem?
Wouldn't you:
1. Move the numeric value to an editted field
2. STRING value1 TAB value2 TAB... DELIMITED SIZE INTO
OUTPUT-REC
3. Write OUTPUT-REC
| |
| foodman 2007-02-21, 6:55 pm |
| In the Olden Days, there may have been a reason for using such
delimited files.
Why bother? Just make it fixed-field format and save yourself the
headaches.
Surely, you cannot have a space or speed problem.
tony dilworth
| |
| Donald Tees 2007-02-21, 6:55 pm |
| jmoore207@gmail.com wrote:
> I need a little help with imports and exports programs. I have created
> many comma delimited programs, I am having an issue with tab delimited
> files and numeric fields. I have written an export program that
> creates a tab delimited file from an indexed file. I have also written
> an import that would use the tab delimited file and update or create
> an index field. I am having an issue with numeric fields. Does anyone
> have any good examples of these. I am using Acucobol in a Solaris
> environment. Thank you
>
I'd advise putting quotes around each field before stringing with tabs.
If you do not, then tabs inside fields will screw up, as well as certain
dates.
| |
| Howard Brazee 2007-02-21, 6:55 pm |
| On 21 Feb 2007 06:55:36 -0800, "foodman" <foodman123@aol.com> wrote:
>In the Olden Days, there may have been a reason for using such
>delimited files.
>Why bother? Just make it fixed-field format and save yourself the
>headaches.
>Surely, you cannot have a space or speed problem.
I create files that are downloaded to PCs and are read into Excel.
Until this w , I was unaware that I should have created them as .CSV
file, making it easier to load. (I created them as .txt files)
| |
| Pete Dashwood 2007-02-21, 6:55 pm |
|
"foodman" <foodman123@aol.com> wrote in message
news:1172069732.072448.274790@j27g2000cwj.googlegroups.com...
> In the Olden Days, there may have been a reason for using such
> delimited files.
> Why bother? Just make it fixed-field format and save yourself the
> headaches.
> Surely, you cannot have a space or speed problem.
>
> tony dilworth
>
On Planet Dilworth the villagers know that their COBOL lord has provided the
one true path for them.
Problems are resolved quickly and effectively by directives from the
Department of COBOL Solutions, empowered by the Holy Church of Fundamental
COBOL, under the pastorage of Lord Tony. Dissent or questioning are not
tolerated and any attempt at original thought is punishable by
excommunication.
The heretical idea that sometimes systems may need to communicate with other
systems that are NOT written in the Holy Scripture, would not even occur to
any right-thinking Dilworthian.
And yet, sometimes, when sleeping huddled for warmth around the fires at the
back of their caves, the people are troubled by strange dreams...
Dreams of spreadsheets and databases and computers that can talk to each
other. Computers that can fit in a pocket, or rest on a lap, without wires
or plugs. Computers that DON'T have green screens and can show pictures, in
COLOUR.... Strange mystical networks that can connect computers across the
entire planet and transfer information instantly to precisely where it is
needed.
Of course, the Thought Police diligently trace anyone having recurrent
nightmares of this nature and they are extracted for "re-orientation".
Fixed fields. Fixed solutions. Fixed approaches.
So it has been, and so shall it always be.
"Blessed be Lord Tony and the Holy Scriptures from whence cometh our
Solution."
Pete (the Heretic)
| |
| Howard Brazee 2007-02-21, 6:55 pm |
| On Thu, 22 Feb 2007 10:34:07 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>On Planet Dilworth the villagers know that their COBOL lord has provided the
>one true path for them.
The rest of your fun post clipped.
I see a real life compromise - the CoBOL passing fixed field format
XML data to a compressor routine. This would be easy in an OO
environment, but sufficiently complex in my environment that I created
a CoBOL paragraph(s) that I clone as needed.
| |
| Pete Dashwood 2007-02-21, 6:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:ogfpt2t8ufber5hakc4bjt7l3u94nivfa5@
4ax.com...
> On Thu, 22 Feb 2007 10:34:07 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> The rest of your fun post clipped.
>
> I see a real life compromise - the CoBOL passing fixed field format
> XML data to a compressor routine. This would be easy in an OO
> environment, but sufficiently complex in my environment that I created
> a CoBOL paragraph(s) that I clone as needed.
Yes, as usual, Howard, you make good sense.
It is pretty trivial to create XML from a COBOL program (assuming you can't
simply plug in an existing XML component as you probably would in an OO
environment). There has been some discussion on this in the "Bridging the
Gap" topic, where both Richard and I have advocated using a a templated
approach for XML generation.
Of course, XML for the Dilworthians would be like teaching shorthand to an
orang-utan...
Pete.
| |
| Alistair 2007-02-21, 6:55 pm |
| On 21 Feb, 22:36, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> "Howard Brazee" <how...@brazee.net> wrote in message
>
> news:ogfpt2t8ufber5hakc4bjt7l3u94nivfa5@
4ax.com...
>
>
>
>
>
>
>
>
>
>
>
> Yes, as usual, Howard, you make good sense.
>
> It is pretty trivial to create XML from a COBOL program (assuming you can't
> simply plug in an existing XML component as you probably would in an OO
> environment). There has been some discussion on this in the "Bridging the
> Gap" topic, where both Richard and I have advocated using a a templated
> approach for XML generation.
>
> Of course, XML for the Dilworthians would be like teaching shorthand to an
> orang-utan...
>
The Librarian has no need for shorthand (see the Discworld series)
other than the occasional modular bunch of fives.
| |
| Richard 2007-02-21, 6:55 pm |
| On Feb 22, 11:36 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> Yes, as usual, Howard, you make good sense.
>
> It is pretty trivial to create XML from a COBOL program (assuming you can't
> simply plug in an existing XML component as you probably would in an OO
> environment). There has been some discussion on this in the "Bridging the
> Gap" topic, where both Richard and I have advocated using a a templated
> approach for XML generation.
Guess how I output CSV files
# template acreport.file for writing file
#
# ----------------------------------------------------------
*CSV
*ADDCR
:header
Content-Type: application/csv; charset=ISO-8859-1;
Content-Disposition: attachment; filename="<!%extract%>";
<head><title><!%extract%></title></head><body><pre>
:glcoderow
"<!%glcode%>","<!%po%>","<!%supplier%>","<!%loc%>","<!%costcent%>",<!
%amount%>,<!%accrue%>,"<!%user%>","<!%date%>","<!%name%>"
:trailer
</pre></body></html>
:end
This one is from a web based system. It get thrown at the browser for
saving on their local machine, or directly into
Excel^H^H^H^H^HOpenOffice.org Calc.
If they want an XML file or HTML, or EDIFAC or TAB separated, just
change the template.
| |
| Richard 2007-02-21, 6:55 pm |
| On Feb 22, 3:04 am, jmoore...@gmail.com wrote:
> I need a little help with imports and exports programs. I have created
> many comma delimited programs, I am having an issue with tab delimited
> files and numeric fields.
What particular 'issues' are you having ? Is it just the wrong value
you are getting or is it a problem that you need to align the
numerics. Try FUNCTION NUMVAL USING csvfield.
> I have written an export program that
> creates a tab delimited file from an indexed file. I have also written
> an import that would use the tab delimited file and update or create
> an index field. I am having an issue with numeric fields. Does anyone
> have any good examples of these.
What does the 'these' refer to: TAB delimited files or programs that
read them ?
> I am using Acucobol in a Solaris
> environment. Thank you
Thank you for indicating your environment, that saves having to do a
discourse on the problems of TABs with Microfocus.
| |
| Louis Krupp 2007-02-21, 6:55 pm |
| Donald Tees wrote:
> jmoore207@gmail.com wrote:
>
> I'd advise putting quotes around each field before stringing with tabs.
> If you do not, then tabs inside fields will screw up, as well as certain
> dates.
Also be sure to escape quotes within the fields, because *those* will
screw things up.
Louis
| |
| jmoore207@gmail.com 2007-02-22, 6:55 pm |
| Thank you for all your replies. I got it working correctly. I have
always created .csv files for exports. The requirement is for the user
to be able to run the export program and open in Excel/StarOffice and
make necessary changes in the spreadsheet to price fields etc. (Non-
Key) fields and save the spreadsheet and import it back into the Index
File. The fun thing is making sure that the data is formatted
correctly when written back to the index file. I have written .csv
programs for all the "important" index files already. So far so good.
Thanks again for all your replies.
|
|
|
|
|