Home > Archive > Cobol > July 2004 > Layout Hell.
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]
|
|
|
| Hi,
Could I have some help with this layout?
I am new to the layout scene, but if I could see some real examples, I might
get it. Then again, I might club myself with a shovel.
Thank you.
I just need to convert this file to Access or something normal.
Do you have any thoughts?
Thanks you.
77 FILLER PIC X(16) VALUE 'CTLG==(ANDERA)===='.
01 WWICTLG.
10 CTLGOP-CO-NO PIC X(3).
10 CTLGCONTROL-SET-SEQ-NO PIC S9(9) USAGE COMP.
10 CTLGINVOICE-SEQ-NO PIC S9(4) USAGE COMP.
10 CTLGAP-CNTRL-ENTITY-CD PIC X(4).
10 CTLGINVOICE-TYPE-CD PIC X(2).
10 CTLGLEGACY-VENDOR-NO PIC X(10).
10 CTLGAP-VENDOR-NO PIC X(30).
10 CTLGAP-PO-NO PIC X(30).
10 CTLGAP-INVOICE-NO PIC X(30).
10 CTLGINVOICE-DT PIC X(10).
10 CTLGTOTAL-INVOICE-AM PIC S9(11)V9(2) USAGE COMP-3.
10 CTLGTOTAL-MERCH-AM PIC S9(11)V9(2) USAGE COMP-3.
10 CTLGTERMS-CD PIC X(2).
10 CTLGCARRIER-CD PIC X(10).
10 CTLGCARRIER-PRO-NO PIC X(10).
10 CTLGSHIP-DT PIC X(10).
10 CTLGSHIP-VIA-CD PIC X(3).
10 CTLGSHIP-LOC-NO PIC X(3).
10 CTLGSHIP-WT PIC X(10).
10 CTLGSHIP-UNITS-DC PIC X(10).
10 CTLGSHIP-TY PIC X(2).
77 POSBOP-CO-NO PIC S9(4) COMP.
77 POSBCONTROL-SET-SEQ-NO PIC S9(4) COMP.
77 POSBINVOICE-SEQ-NO PIC S9(4) COMP.
77 POSBAP-CNTRL-ENTITY-CD PIC S9(4) COMP.
77 POSBINVOICE-TYPE-CD PIC S9(4) COMP.
77 POSBLEGACY-VENDOR-NO PIC S9(4) COMP.
77 POSBAP-VENDOR-NO PIC S9(4) COMP.
77 POSBAP-PO-NO PIC S9(4) COMP.
77 POSBAP-INVOICE-NO PIC S9(4) COMP.
77 POSBINVOICE-DT PIC S9(4) COMP.
77 POSBTOTAL-INVOICE-AM PIC S9(4) COMP.
77 POSBTOTAL-MERCH-AM PIC S9(4) COMP.
77 POSBTERMS-CD PIC S9(4) COMP.
77 POSBCARRIER-CD PIC S9(4) COMP.
77 POSBCARRIER-PRO-NO PIC S9(4) COMP.
77 POSBSHIP-DT PIC S9(4) COMP.
77 POSBSHIP-VIA-CD PIC S9(4) COMP.
77 POSBSHIP-LOC-NO PIC S9(4) COMP.
77 POSBSHIP-WT PIC S9(4) COMP.
77 POSBSHIP-UNITS-DC PIC S9(4) COMP.
77 POSBSHIP-TY PIC S9(4) COMP.
| |
| Michael Mattias 2004-07-15, 8:55 pm |
| "Carol" <kgdg@helkusa.com> wrote in message
news:JZCdnZ690pjbiWrd4p2dnA@comcast.com...
> Could I have some help with this layout?
> I am new to the layout scene, but if I could see some real examples, I
might
> get it. Then again, I might club myself with a shovel.
> Thank you.
> I just need to convert this file to Access or something normal.
Um, if by "convert this file" you mean "convert the record layout" then your
X fields are alpha, your PIC 9 fields are numeric, usage immaterial...
CREATE TABLE tablename (co_no VARCHAR(3), set_seq_no INTEGER,
....total_invoice_am NUMBER(11,2) (although specifically with MS-Access or
other engines based on Jet, CURRENCY might be a better choice for the
decimal money fields.).....
Or did you mean, convert some DATA currently residing in a file described by
this layout?
Well, that's a horse of another color; as well as a current topic here....
witnesseth this clip and my response, equally applicable.....
== BEGIN QUOTEe===
Scott Hooper" <shooper@rxworks.com> wrote in message
news:a8341757.0407142138.560efc01@posting.google.com...
> I have read through all the newsgroups I could find and am getting
> very  about what to do with my files. I have a heaps of
> FILExxxx.DAT files, some with matching .CTL files, that I need to read
> into something like Access, dBase or delimited text. The files were
> created using a custom program written in RM/COBOL-85. I have all the
> .COB files. What I can't do is spend any money on a one-off tool. I'm
> hoping that somebody can offer me a VB, VB.NET or C# code solution for
> reading these.
Tutorial: Using COBOL-created data with non-COBOL programs.
http://www.talsystems.com/tsihome_h...oads/C2IEEE.htm
The price is right (free for use).
Basically that will tell you you MUST have the COBOL FD or other record
layout documentation - but if you have the *.COB files, you have these
descriptions, so you are probably beyond the most frequent barrier to
success.
I have a Win/32 DLL which uses the FD info and then converts the data to
IEEE format; and several "base" conversion programs (BASIC language). Sounds
like that software would probably be exactly what you want.... except the
part where you say, " What I can't do is spend any money on a one-off tool."
But if you change your mind and are interested in a package of BASIC
language source/executable (PowerBASIC/Windows, very usable with Microsoft
Visual BASIC or any "C" for Windows) - with the understanding it is not
free - please contact my office.
== END QUOTE ===
--
Michael Mattias
Tal Systems, Inc.
Racine WI
mmattias@talsystems.com
| |
| Charles W. Cribbs II 2004-07-15, 8:55 pm |
| You are not making yourself clear at all. You have provided one record:
01 WWICTLG.
> 10 CTLGOP-CO-NO PIC X(3).
> 10 CTLGCONTROL-SET-SEQ-NO PIC S9(9) USAGE COMP.
> 10 CTLGINVOICE-SEQ-NO PIC S9(4) USAGE COMP.
> 10 CTLGAP-CNTRL-ENTITY-CD PIC X(4).
> 10 CTLGINVOICE-TYPE-CD PIC X(2).
> 10 CTLGLEGACY-VENDOR-NO PIC X(10).
> 10 CTLGAP-VENDOR-NO PIC X(30).
> 10 CTLGAP-PO-NO PIC X(30).
> 10 CTLGAP-INVOICE-NO PIC X(30).
> 10 CTLGINVOICE-DT PIC X(10).
> 10 CTLGTOTAL-INVOICE-AM PIC S9(11)V9(2) USAGE COMP-3.
> 10 CTLGTOTAL-MERCH-AM PIC S9(11)V9(2) USAGE COMP-3.
> 10 CTLGTERMS-CD PIC X(2).
> 10 CTLGCARRIER-CD PIC X(10).
> 10 CTLGCARRIER-PRO-NO PIC X(10).
> 10 CTLGSHIP-DT PIC X(10).
> 10 CTLGSHIP-VIA-CD PIC X(3).
> 10 CTLGSHIP-LOC-NO PIC X(3).
> 10 CTLGSHIP-WT PIC X(10).
> 10 CTLGSHIP-UNITS-DC PIC X(10).
> 10 CTLGSHIP-TY PIC X(2).
>
I looked up what the 77 levels are used for and the book says, "You use 77
level to define an independent data item -- one that is not related in any
way to any of the data around it. There is nothing you can do with a 77
level you can't do with an 01 level."
So what you have here is one record, the part under the 01 to the next 77
level and a series of independent data variable names marked with the 77
levels.
A record layout is just an expression of a data record and its component
parts. Say if I wanted to do something like the following:
01 test-record pic x(132).
01 test-record-parts redefines
test-record.
05 alpha-data pic x(30).
05 date-data pic 9(10).
05 more-alpha-data pic x(30).
05 numeric-data pic 9(20).
05 some-more-numeric-data pic 9(20).
05 filler pic x(22).
You can break the record down to each individual byte of the record if you
want but typically you have information taking more than one byte and you
are just telling the the program by the use of the variable name what bytes
belong with what variable.
Don't get all bound up in the "comp" fields they are just a way of defining
a storage method for the data. A record is not required to use comp fields
but as you get more experience with cobol you will find out that you want to
store data in the most efficient way you can so you save disk/tape space and
programs can do certain tasks faster when stored with comp fields.
The stuff dealing with 77 levels don't appear to function as part of the
record layout listed in the 01 level.
"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:FTEJc.1591$4L7.319@newssvr33.news.prodigy.com...
> "Carol" <kgdg@helkusa.com> wrote in message
> news:JZCdnZ690pjbiWrd4p2dnA@comcast.com...
> might
>
> Um, if by "convert this file" you mean "convert the record layout" then
your
> X fields are alpha, your PIC 9 fields are numeric, usage immaterial...
> CREATE TABLE tablename (co_no VARCHAR(3), set_seq_no INTEGER,
> ...total_invoice_am NUMBER(11,2) (although specifically with MS-Access or
> other engines based on Jet, CURRENCY might be a better choice for the
> decimal money fields.).....
>
> Or did you mean, convert some DATA currently residing in a file described
by
> this layout?
>
> Well, that's a horse of another color; as well as a current topic here....
> witnesseth this clip and my response, equally applicable.....
>
> == BEGIN QUOTEe===
> Scott Hooper" <shooper@rxworks.com> wrote in message
> news:a8341757.0407142138.560efc01@posting.google.com...
>
> Tutorial: Using COBOL-created data with non-COBOL programs.
>
> http://www.talsystems.com/tsihome_h...oads/C2IEEE.htm
>
> The price is right (free for use).
>
> Basically that will tell you you MUST have the COBOL FD or other record
> layout documentation - but if you have the *.COB files, you have these
> descriptions, so you are probably beyond the most frequent barrier to
> success.
>
> I have a Win/32 DLL which uses the FD info and then converts the data to
> IEEE format; and several "base" conversion programs (BASIC language).
Sounds
> like that software would probably be exactly what you want.... except the
> part where you say, " What I can't do is spend any money on a one-off
tool."
>
> But if you change your mind and are interested in a package of BASIC
> language source/executable (PowerBASIC/Windows, very usable with Microsoft
> Visual BASIC or any "C" for Windows) - with the understanding it is not
> free - please contact my office.
>
> == END QUOTE ===
>
>
> --
> Michael Mattias
> Tal Systems, Inc.
> Racine WI
> mmattias@talsystems.com
>
>
>
>
| |
|
| You are right.
I am not making myslef clear at all.
Still, the info you sent is helping me.
I have a job to convert these tapes form cobol to ascii text.
I have a program to do this, but as you know I have to script it with the
file layout.
| |
| The Family 2004-07-16, 3:55 am |
|
77's always precede 01-99's. Other than that, I didn't really look
at the definition detail.
Gary
"Carol" <kgdg@helkusa.com> wrote in message
news:JZCdnZ690pjbiWrd4p2dnA@comcast.com...
> Hi,
> Could I have some help with this layout?
> I am new to the layout scene, but if I could see some real examples, I
might
> get it. Then again, I might club myself with a shovel.
> Thank you.
> I just need to convert this file to Access or something normal.
> Do you have any thoughts?
> Thanks you.
>
> 77 FILLER PIC X(16) VALUE 'CTLG==(ANDERA)===='.
> 01 WWICTLG.
> 10 CTLGOP-CO-NO PIC X(3).
> 10 CTLGCONTROL-SET-SEQ-NO PIC S9(9) USAGE COMP.
> 10 CTLGINVOICE-SEQ-NO PIC S9(4) USAGE COMP.
> 10 CTLGAP-CNTRL-ENTITY-CD PIC X(4).
> 10 CTLGINVOICE-TYPE-CD PIC X(2).
> 10 CTLGLEGACY-VENDOR-NO PIC X(10).
> 10 CTLGAP-VENDOR-NO PIC X(30).
> 10 CTLGAP-PO-NO PIC X(30).
> 10 CTLGAP-INVOICE-NO PIC X(30).
> 10 CTLGINVOICE-DT PIC X(10).
> 10 CTLGTOTAL-INVOICE-AM PIC S9(11)V9(2) USAGE COMP-3.
> 10 CTLGTOTAL-MERCH-AM PIC S9(11)V9(2) USAGE COMP-3.
> 10 CTLGTERMS-CD PIC X(2).
> 10 CTLGCARRIER-CD PIC X(10).
> 10 CTLGCARRIER-PRO-NO PIC X(10).
> 10 CTLGSHIP-DT PIC X(10).
> 10 CTLGSHIP-VIA-CD PIC X(3).
> 10 CTLGSHIP-LOC-NO PIC X(3).
> 10 CTLGSHIP-WT PIC X(10).
> 10 CTLGSHIP-UNITS-DC PIC X(10).
> 10 CTLGSHIP-TY PIC X(2).
> 77 POSBOP-CO-NO PIC S9(4) COMP.
> 77 POSBCONTROL-SET-SEQ-NO PIC S9(4) COMP.
> 77 POSBINVOICE-SEQ-NO PIC S9(4) COMP.
> 77 POSBAP-CNTRL-ENTITY-CD PIC S9(4) COMP.
> 77 POSBINVOICE-TYPE-CD PIC S9(4) COMP.
> 77 POSBLEGACY-VENDOR-NO PIC S9(4) COMP.
> 77 POSBAP-VENDOR-NO PIC S9(4) COMP.
> 77 POSBAP-PO-NO PIC S9(4) COMP.
> 77 POSBAP-INVOICE-NO PIC S9(4) COMP.
> 77 POSBINVOICE-DT PIC S9(4) COMP.
> 77 POSBTOTAL-INVOICE-AM PIC S9(4) COMP.
> 77 POSBTOTAL-MERCH-AM PIC S9(4) COMP.
> 77 POSBTERMS-CD PIC S9(4) COMP.
> 77 POSBCARRIER-CD PIC S9(4) COMP.
> 77 POSBCARRIER-PRO-NO PIC S9(4) COMP.
> 77 POSBSHIP-DT PIC S9(4) COMP.
> 77 POSBSHIP-VIA-CD PIC S9(4) COMP.
> 77 POSBSHIP-LOC-NO PIC S9(4) COMP.
> 77 POSBSHIP-WT PIC S9(4) COMP.
> 77 POSBSHIP-UNITS-DC PIC S9(4) COMP.
> 77 POSBSHIP-TY PIC S9(4) COMP.
>
>
| |
| Charles W. Cribbs II 2004-07-16, 3:55 am |
| Well that will be pretty simple then.
Take that record layout and for the fields with comp in them just make your
text file show a pic 9(same length as what comp field specifies).
"Carol" <kgdg@helkusa.com> wrote in message
news:VLSdnUGwEp_EumrdRVn-ig@comcast.com...
> You are right.
> I am not making myslef clear at all.
> Still, the info you sent is helping me.
>
> I have a job to convert these tapes form cobol to ascii text.
> I have a program to do this, but as you know I have to script it with the
> file layout.
>
>
>
| |
| William M. Klein 2004-07-16, 3:55 am |
| Huh ???
I think that MAY have been required by the '68 Standard - but not since. Is
there a compiler still supported that requires 77 levels to be coded before
01-levels?
--
Bill Klein
wmklein <at> ix.netcom.com
"The Family" <lgvwalk@swbell.net> wrote in message
news:P0GJc.8950$OA6.6225@newssvr23.news.prodigy.com...
>
> 77's always precede 01-99's. Other than that, I didn't really look
> at the definition detail.
>
>
> Gary
>
>
>
>
> "Carol" <kgdg@helkusa.com> wrote in message
> news:JZCdnZ690pjbiWrd4p2dnA@comcast.com...
> might
>
>
| |
| JerryMouse 2004-07-16, 3:55 am |
| Carol wrote:
> Hi,
> Could I have some help with this layout?
> I am new to the layout scene, but if I could see some real examples,
> I might get it. Then again, I might club myself with a shovel.
> Thank you.
> I just need to convert this file to Access or something normal.
No you don't. It's already more normal than anything to which you could
convert it.
> Do you have any thoughts?
I have placed the number of bytes each field uses (usually, beware of
compiler dependencies) in square brackets. If that's insufficient, come back
with more specific questions.
(P.S., "77" levels are not involved in the record. They may be ignored for
this purpose.)
> Thanks you.
>
> 01 WWICTLG.
> 10 CTLGOP-CO-NO PIC X(3). [3]
> 10 CTLGCONTROL-SET-SEQ-NO PIC S9(9) USAGE COMP. [4]*
> 10 CTLGINVOICE-SEQ-NO PIC S9(4) USAGE COMP. [4]*
> 10 CTLGAP-CNTRL-ENTITY-CD PIC X(4). [4]
> 10 CTLGINVOICE-TYPE-CD PIC X(2). [2]
> 10 CTLGLEGACY-VENDOR-NO PIC X(10). [10]
> 10 CTLGAP-VENDOR-NO PIC X(30). [30]
> 10 CTLGAP-PO-NO PIC X(30). [30]
> 10 CTLGAP-INVOICE-NO PIC X(30). [30]
> 10 CTLGINVOICE-DT PIC X(10). [10]
> 10 CTLGTOTAL-INVOICE-AM PIC S9(11)V9(2) USAGE COMP-3.
[7]**
> 10 CTLGTOTAL-MERCH-AM PIC S9(11)V9(2) USAGE COMP-3. [7]
> 10 CTLGTERMS-CD PIC X(2). [2]
> 10 CTLGCARRIER-CD PIC X(10). [10]
> 10 CTLGCARRIER-PRO-NO PIC X(10). [10]
> 10 CTLGSHIP-DT PIC X(10). [10]
> 10 CTLGSHIP-VIA-CD PIC X(3). [3]
> 10 CTLGSHIP-LOC-NO PIC X(3). [3]
> 10 CTLGSHIP-WT PIC X(10). [10]
> 10 CTLGSHIP-UNITS-DC PIC X(10). [10]
> 10 CTLGSHIP-TY PIC X(2). [2]
* = Binary Fullword, 4 bytes because of its size (>4 digits)
** = Packed Decimal (number-of-digits + 1) / 2. No other database system
uses Packed Decimal. You have your work cut out to convert to a "normal"
number.
| |
| Peter Lacey 2004-07-16, 3:55 am |
| Carol wrote:
>
> Hi,
> Could I have some help with this layout?
> I am new to the layout scene, but if I could see some real examples, I might
> get it. Then again, I might club myself with a shovel.
> Thank you.
> I just need to convert this file to Access or something normal.
> Do you have any thoughts?
> Thanks you.
>
>
As I suggested to someone else - get a Cobol programmer to write a Q & D
program to blat out the data in comma-seperated field format (which
will change the COMP fields to normal numbers on the fly) and then just
import it into Access.
Piece of cake.
PL
| |
|
| Thanks, but what is Q & D
"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:40F75BA6.95D2BD15@mb.sympatico.ca...
> Carol wrote:
might[color=darkred]
>
> As I suggested to someone else - get a Cobol programmer to write a Q & D
> program to blat out the data in comma-seperated field format (which
> will change the COMP fields to normal numbers on the fly) and then just
> import it into Access.
>
> Piece of cake.
>
> PL
| |
|
| You guys are great.
Still, what do i do with this Filler field at the beginning?
Second what then, is the record length?
I see that all the 10s are repeated as 77s as PIC S9(4)
why?
You guys are great, man
> 77 FILLER PIC X(16) VALUE 'CTLG==(ANDERA)===='.
> 01 WWICTLG.
> 10 CTLGOP-CO-NO PIC X(3).
> 10 CTLGCONTROL-SET-SEQ-NO PIC S9(9) USAGE COMP.
> 10 CTLGINVOICE-SEQ-NO PIC S9(4) USAGE COMP.
> 10 CTLGAP-CNTRL-ENTITY-CD PIC X(4).
> 10 CTLGINVOICE-TYPE-CD PIC X(2).
> 10 CTLGLEGACY-VENDOR-NO PIC X(10).
> 10 CTLGAP-VENDOR-NO PIC X(30).
> 10 CTLGAP-PO-NO PIC X(30).
> 10 CTLGAP-INVOICE-NO PIC X(30).
> 10 CTLGINVOICE-DT PIC X(10).
> 10 CTLGTOTAL-INVOICE-AM PIC S9(11)V9(2) USAGE COMP-3.
> 10 CTLGTOTAL-MERCH-AM PIC S9(11)V9(2) USAGE COMP-3.
> 10 CTLGTERMS-CD PIC X(2).
> 10 CTLGCARRIER-CD PIC X(10).
> 10 CTLGCARRIER-PRO-NO PIC X(10).
> 10 CTLGSHIP-DT PIC X(10).
> 10 CTLGSHIP-VIA-CD PIC X(3).
> 10 CTLGSHIP-LOC-NO PIC X(3).
> 10 CTLGSHIP-WT PIC X(10).
> 10 CTLGSHIP-UNITS-DC PIC X(10).
> 10 CTLGSHIP-TY PIC X(2).
> 77 POSBOP-CO-NO PIC S9(4) COMP.
> 77 POSBCONTROL-SET-SEQ-NO PIC S9(4) COMP.
> 77 POSBINVOICE-SEQ-NO PIC S9(4) COMP.
> 77 POSBAP-CNTRL-ENTITY-CD PIC S9(4) COMP.
> 77 POSBINVOICE-TYPE-CD PIC S9(4) COMP.
> 77 POSBLEGACY-VENDOR-NO PIC S9(4) COMP.
> 77 POSBAP-VENDOR-NO PIC S9(4) COMP.
> 77 POSBAP-PO-NO PIC S9(4) COMP.
> 77 POSBAP-INVOICE-NO PIC S9(4) COMP.
> 77 POSBINVOICE-DT PIC S9(4) COMP.
> 77 POSBTOTAL-INVOICE-AM PIC S9(4) COMP.
> 77 POSBTOTAL-MERCH-AM PIC S9(4) COMP.
> 77 POSBTERMS-CD PIC S9(4) COMP.
> 77 POSBCARRIER-CD PIC S9(4) COMP.
> 77 POSBCARRIER-PRO-NO PIC S9(4) COMP.
> 77 POSBSHIP-DT PIC S9(4) COMP.
> 77 POSBSHIP-VIA-CD PIC S9(4) COMP.
> 77 POSBSHIP-LOC-NO PIC S9(4) COMP.
> 77 POSBSHIP-WT PIC S9(4) COMP.
> 77 POSBSHIP-UNITS-DC PIC S9(4) COMP.
> 77 POSBSHIP-TY PIC S9(4) COMP.
>
>
| |
|
| I guess the progblem is that it does not work.
I have 20 tapes and 20 file layoiuts. Maybe this file layout does not go
with this tape?
"JerryMouse" <nospam@bisusa.com> wrote in message
news:FfWdnajyuePaoGrdRVn-hw@giganews.com...
> Carol wrote:
>
> No you don't. It's already more normal than anything to which you could
> convert it.
>
>
> I have placed the number of bytes each field uses (usually, beware of
> compiler dependencies) in square brackets. If that's insufficient, come
back
> with more specific questions.
>
> (P.S., "77" levels are not involved in the record. They may be ignored for
> this purpose.)
>
> [7]**
[7][color=darkred]
>
> * = Binary Fullword, 4 bytes because of its size (>4 digits)
> ** = Packed Decimal (number-of-digits + 1) / 2. No other database system
> uses Packed Decimal. You have your work cut out to convert to a "normal"
> number.
>
>
| |
|
| Thanks a lot that is neat.
"JerryMouse" <nospam@bisusa.com> wrote in message
news:FfWdnajyuePaoGrdRVn-hw@giganews.com...
> Carol wrote:
>
> No you don't. It's already more normal than anything to which you could
> convert it.
>
>
> I have placed the number of bytes each field uses (usually, beware of
> compiler dependencies) in square brackets. If that's insufficient, come
back
> with more specific questions.
>
> (P.S., "77" levels are not involved in the record. They may be ignored for
> this purpose.)
>
> [7]**
[7][color=darkred]
>
> * = Binary Fullword, 4 bytes because of its size (>4 digits)
> ** = Packed Decimal (number-of-digits + 1) / 2. No other database system
> uses Packed Decimal. You have your work cut out to convert to a "normal"
> number.
>
>
| |
|
| Jerry, is there some table out there that lists all possible COBOL fields
( PIC X(3),PIC S9(9) ) and the number of bytes they take up, so that I can
just copy and paste or even write a little script?
thanks
"JerryMouse" <nospam@bisusa.com> wrote in message
news:FfWdnajyuePaoGrdRVn-hw@giganews.com...
> Carol wrote:
>
> No you don't. It's already more normal than anything to which you could
> convert it.
>
>
> I have placed the number of bytes each field uses (usually, beware of
> compiler dependencies) in square brackets. If that's insufficient, come
back
> with more specific questions.
>
> (P.S., "77" levels are not involved in the record. They may be ignored for
> this purpose.)
>
> [7]**
[7][color=darkred]
>
> * = Binary Fullword, 4 bytes because of its size (>4 digits)
> ** = Packed Decimal (number-of-digits + 1) / 2. No other database system
> uses Packed Decimal. You have your work cut out to convert to a "normal"
> number.
>
>
| |
| The Family 2004-07-16, 3:55 am |
|
Perhaps not. I thought about that just as I was making that post.
But, I still was not aware that 77's & 01-99's could be mixed,
and further, why would someone want to? Frankly, I haven't
seen much use in 77's in some time anyway.
Thanks, for the update....
Gary
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:0IGJc.4104$mL5.2263@newsread1.news.pas.earthlink.net...
> Huh ???
>
> I think that MAY have been required by the '68 Standard - but not since.
Is
> there a compiler still supported that requires 77 levels to be coded
before
> 01-levels?
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "The Family" <lgvwalk@swbell.net> wrote in message
> news:P0GJc.8950$OA6.6225@newssvr23.news.prodigy.com...
>
>
| |
|
| I add these up and I get 201.
My block length is 32600 for sure.
that divides by 200 * 163
but not 201
what do I do?
"JerryMouse" <nospam@bisusa.com> wrote in message
news:FfWdnajyuePaoGrdRVn-hw@giganews.com...
> Carol wrote:
>
> No you don't. It's already more normal than anything to which you could
> convert it.
>
>
> I have placed the number of bytes each field uses (usually, beware of
> compiler dependencies) in square brackets. If that's insufficient, come
back
> with more specific questions.
>
> (P.S., "77" levels are not involved in the record. They may be ignored for
> this purpose.)
>
> [7]**
[7][color=darkred]
>
> * = Binary Fullword, 4 bytes because of its size (>4 digits)
> ** = Packed Decimal (number-of-digits + 1) / 2. No other database system
> uses Packed Decimal. You have your work cut out to convert to a "normal"
> number.
>
>
| |
| Michael Mattias 2004-07-16, 8:55 am |
| "Carol" <kgdg@helkusa.com> wrote in message
news:T8KdnQfCif1T9mrd4p2dnA@comcast.com...
> I add these up and I get 201.
>
> My block length is 32600 for sure.
> that divides by 200 * 163
> but not 201
>
> what do I do?
>
Create a report showing size of all elementary and group items, with
documentation:
http://www.flexus.com/ftp/cobfd.zip
Be aware: the size of COMP[-n] fields may vary with operating system and/or
compiler directives!
Text/graphics tutorial on COBOL data:
http://www.flexus.com/ftp/cobdata.zip
Tips/techniques for converting COBOL-created data for use with other
software (link previously supplied):
http://www.talsystems.com/tsihome_h...oads/C2IEEE.htm
That ain't enough? Consider outside help.
--
Michael Mattias
Tal Systems, Inc.
Racine WI
mmattias@talsystems.com
Author/Contributor of all above.
| |
| JerryMouse 2004-07-16, 3:55 pm |
| Carol wrote:
> You guys are great.
>
> Still, what do i do with this Filler field at the beginning?
Ignore it. This is a common technique to find the begining of program
storage in a memory dump.
>
> Second what then, is the record length?
This cannot be answered without knowing how YOUR compiler treats various
data definitions. For example, PIC S9(9) COMP could be several different
lengths (from 4 to 10 bytes) depending on the compiler and operating system.
"COMP" fields are implementor-defined.
>
> I see that all the 10s are repeated as 77s as PIC S9(4)
> why?
They are not repeated. They have different names. You'll have to ask the
original programmer why, but I suspect it's for temporary storage of the
previous record.
[color=darkred]
>
> You guys are great, man
>
>
>
>
| |
| B Hobbs 2004-07-16, 3:55 pm |
| In article <FfWdnajyuePaoGrdRVn-hw@giganews.com>,
"JerryMouse" <nospam@bisusa.com> wrote:
> I have placed the number of bytes each field uses (usually, beware of
> compiler dependencies) in square brackets. If that's insufficient, come back
> with more specific questions.
May I suggest that one specify what hardware, operating system, compiler
combination was used?
[color=darkred]
The last data item would be two bytes on DEC/Compaq/HP Alpha, VMS 7.2,
Compaq COBOL 2.8.
http://h71000.www7.hp.com/doc/73fin...5.html#data_typ
es_unscaled_tab
I agree with an earlier poster about developing a COBOL program using
the specified record layout to read the data and then spit it out in a
format the lesser program will find agreeable. There still could be a
problem using different compilers, or possibly different compiler
versions, on the same hw/os. Heck, the data and program he found could
have been left over from a Honeywell 6000 and GCOS, which I vaguely
recall as being a bit peculiar ... was it a 36 bit word?
A few blocks from the data tape should probably be dumped to hex or
octal and analyzed to try to determine overall record size, fixed or
variable length records, if there are multiple record types, and if the
character set is ASCII, EBCDIC, or something else. The tape headers and
trailers may have a few clues also.
Hmmm, just how important is this data? If its been rotting for a few
years and just now its "value" has been discovered, how do they know it
is the correct data?
--
-- B Hobbs
-- mailto:bdhobbs18@yahoo.com
| |
| JerryMouse 2004-07-16, 3:55 pm |
| Carol wrote:
> Jerry, is there some table out there that lists all possible COBOL
> fields ( PIC X(3),PIC S9(9) ) and the number of bytes they take up,
> so that I can just copy and paste or even write a little script?
> thanks
No.
It's terribly confusing for the neophyte. Several CHAPTERS are necessary in
a COBOL manual to go through all the permutations. For your purposes,
though, you may consider:
PIC ("Picture") X(nn) to be "nn" bytes long.
If the picture line ends in COMP-something, you have to be attuned to your
operating system and compiler. In general:
COMP 9(1) through 9(4) use two bytes (binary half-word)
COMP 9(5) through 9(9) use four bytes (binary full-word)
With each of these, you must be aware of whether your machine stores the
data as big-endian or little-endian.
COMP-3 is Packed Decimal. The last half-byte stores the sign and the
least-significant digit (usually). All other bytes store two digits each.
Viz:
123 = 12 3+
1234 = 01 23 4+
12345 = 12 34 5+
123.45 = 12 34 5+
0.12345 = 12 34 5+
So! Where's the decimal point stored? There is no decimal point stored in
COMP fields. The program just has to KNOW where the decimal point belongs.
| |
| JerryMouse 2004-07-16, 3:55 pm |
| Carol wrote:
> Thanks, but what is Q & D
Pick from list:
Quick and Dirty
Quadriceps and Deltoids
Quaker Oats and Decaf
Quintuplets and Diapers
| |
| docdwarf@panix.com 2004-07-16, 3:55 pm |
| In article <bdhobbs18-DEB6D3.07101016072004@news2.west.earthlink.net>,
B Hobbs <bdhobbs18@yahoo.com> wrote:
[snip]
>Hmmm, just how important is this data? If its been rotting for a few
>years and just now its "value" has been discovered, how do they know it
>is the correct data?
For trend-analysis or other historical purposes it should be 'correct'; if
one is looking to see how many widgets were used by the company during (x)
period it should be just fine.
If one is looking, say, to put together a mailing-list of widget-users
from (x) period then it might be a bit more dicey; at least in the USA
folks have a tendency to change addresses rather frequently.
DD
| |
|
| good. thank you very much Mr. Mouse.
"JerryMouse" <nospam@bisusa.com> wrote in message
news:IsKdnWvHOZOIfmrd4p2dnA@giganews.com...
> Carol wrote:
>
> No.
>
> It's terribly confusing for the neophyte. Several CHAPTERS are necessary
in
> a COBOL manual to go through all the permutations. For your purposes,
> though, you may consider:
>
> PIC ("Picture") X(nn) to be "nn" bytes long.
>
> If the picture line ends in COMP-something, you have to be attuned to your
> operating system and compiler. In general:
>
> COMP 9(1) through 9(4) use two bytes (binary half-word)
> COMP 9(5) through 9(9) use four bytes (binary full-word)
>
> With each of these, you must be aware of whether your machine stores the
> data as big-endian or little-endian.
>
> COMP-3 is Packed Decimal. The last half-byte stores the sign and the
> least-significant digit (usually). All other bytes store two digits each.
> Viz:
>
> 123 = 12 3+
> 1234 = 01 23 4+
> 12345 = 12 34 5+
> 123.45 = 12 34 5+
> 0.12345 = 12 34 5+
>
> So! Where's the decimal point stored? There is no decimal point stored in
> COMP fields. The program just has to KNOW where the decimal point belongs.
>
>
| |
|
| The data is current.
This data came from another company.
I do not have access to the people at that company because of political
stuff.
All I have are 20 tapes and 20 file layouts and no experience.
Plus I am supposed to represent our company as being real smart .tee hee.
When you guys ask what compiler is used..
Do you mean what machine dumped the data?
Or what machine do I have that is reading the data.
"B Hobbs" <bdhobbs18@yahoo.com> wrote in message
news:bdhobbs18-DEB6D3.07101016072004@news2.west.earthlink.net...
> In article <FfWdnajyuePaoGrdRVn-hw@giganews.com>,
> "JerryMouse" <nospam@bisusa.com> wrote:
>
back[color=darkred]
>
> May I suggest that one specify what hardware, operating system, compiler
> combination was used?
>
>
> The last data item would be two bytes on DEC/Compaq/HP Alpha, VMS 7.2,
> Compaq COBOL 2.8.
>
> http://h71000.www7.hp.com/doc/73fin...5.html#data_typ
> es_unscaled_tab
>
> I agree with an earlier poster about developing a COBOL program using
> the specified record layout to read the data and then spit it out in a
> format the lesser program will find agreeable. There still could be a
> problem using different compilers, or possibly different compiler
> versions, on the same hw/os. Heck, the data and program he found could
> have been left over from a Honeywell 6000 and GCOS, which I vaguely
> recall as being a bit peculiar ... was it a 36 bit word?
>
> A few blocks from the data tape should probably be dumped to hex or
> octal and analyzed to try to determine overall record size, fixed or
> variable length records, if there are multiple record types, and if the
> character set is ASCII, EBCDIC, or something else. The tape headers and
> trailers may have a few clues also.
>
> Hmmm, just how important is this data? If its been rotting for a few
> years and just now its "value" has been discovered, how do they know it
> is the correct data?
>
> --
> -- B Hobbs
> -- mailto:bdhobbs18@yahoo.com
| |
|
|
Quite a Dufus
"JerryMouse" <nospam@bisusa.com> wrote in message
news:4OadnU6hlNMgeWrdRVn-sA@giganews.com...
> Carol wrote:
>
> Pick from list:
>
> Quick and Dirty
> Quadriceps and Deltoids
> Quaker Oats and Decaf
> Quintuplets and Diapers
>
>
| |
| William M. Klein 2004-07-16, 3:55 pm |
| What we need to know is the "vendor", operating system, and specific compiler
(and possibly the compiler options) where the program was run that CREATED the
tape).
For example,
With the Micro Focus compiler when run on an Intel (Windows) type
environment - if the IBM-COMP compiler option is turned on
Pic S9 COMP
will take 2 bytes
but if the same program were compiled with the NOIBM-COMP compiler option, then
it would take one byte.
Given you other note about the "political issues" in getting information about
the "creation" of the data, then this may be very difficult to get.
Similarly, if you have PIC XX data - and don't know if the program that created
the data was in an ASCII or EBCDIC environment, you may be able to figure out
how many bytes you need but you won't be able to make ANY sense of the data.
Using the tool at:
http://www.flexus.com/ftp/cobfd.zip
mentioned elsewhere may be able to HELP you figure out what you have, but you
really REALLY need to know how (what compiler, what operating system, and what
compiler options/directives) were in effect WHEN THE DATA WAS FIRST created.
(Nothing to do with making a "tape copy" of existing data - but the actual
creation of the data)
--
Bill Klein
wmklein <at> ix.netcom.com
"Carol" <kgdg@helkusa.com> wrote in message
news:e9idnSfgcbiTlGXdRVn-hA@comcast.com...
> The data is current.
> This data came from another company.
> I do not have access to the people at that company because of political
> stuff.
> All I have are 20 tapes and 20 file layouts and no experience.
> Plus I am supposed to represent our company as being real smart .tee hee.
>
>
> When you guys ask what compiler is used..
>
> Do you mean what machine dumped the data?
> Or what machine do I have that is reading the data.
>
>
>
> "B Hobbs" <bdhobbs18@yahoo.com> wrote in message
> news:bdhobbs18-DEB6D3.07101016072004@news2.west.earthlink.net...
> back
>
>
| |
| Richard 2004-07-16, 3:55 pm |
| "JerryMouse" <nospam@bisusa.com> wrote
>
> They are not repeated. They have different names. You'll have to ask the
> original programmer why, but I suspect it's for temporary storage of the
> previous record.
All the following 77s are named POS.. and are 4 digit numbers. They
are probably POSitions. Either set to being the offsets in the
record, or screen I/O positions, or something.
| |
| Robert Wagner 2004-07-16, 8:55 pm |
| "Carol" <kgdg@helkusa.com> wrote:
>I add these up and I get 201.
>
>My block length is 32600 for sure.
>that divides by 200 * 163
>but not 201
>
>what do I do?
Length of the third field is 2, not 4, so the record length is 199. Look at the
data to see how long records are. It should be easy to spot CO-NO, which appears
to be a constant or at least the same for several records.
I used to process 1-10 requests per w for such conversions. I charged a flat
rate of $50 per, with possible discount to $25 if they could supply a copybook.
They almost never could. Instead they sent a text document that management
thought was usable.
>"JerryMouse" <nospam@bisusa.com> wrote in message
>news:FfWdnajyuePaoGrdRVn-hw@giganews.com...
>back
>[7]
>
>
| |
|
| Thank you very much. I will take a look. I really appreciate it.
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:D4VJc.4629$mL5.1575@newsread1.news.pas.earthlink.net...
> What we need to know is the "vendor", operating system, and specific
compiler
> (and possibly the compiler options) where the program was run that CREATED
the
> tape).
>
> For example,
> With the Micro Focus compiler when run on an Intel (Windows) type
> environment - if the IBM-COMP compiler option is turned on
> Pic S9 COMP
> will take 2 bytes
> but if the same program were compiled with the NOIBM-COMP compiler option,
then
> it would take one byte.
>
> Given you other note about the "political issues" in getting information
about
> the "creation" of the data, then this may be very difficult to get.
>
> Similarly, if you have PIC XX data - and don't know if the program that
created
> the data was in an ASCII or EBCDIC environment, you may be able to figure
out
> how many bytes you need but you won't be able to make ANY sense of the
data.
>
> Using the tool at:
> http://www.flexus.com/ftp/cobfd.zip
>
> mentioned elsewhere may be able to HELP you figure out what you have, but
you
> really REALLY need to know how (what compiler, what operating system, and
what
> compiler options/directives) were in effect WHEN THE DATA WAS FIRST
created.
> (Nothing to do with making a "tape copy" of existing data - but the actual
> creation of the data)
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Carol" <kgdg@helkusa.com> wrote in message
> news:e9idnSfgcbiTlGXdRVn-hA@comcast.com...
hee.[color=darkred]
of[color=darkred]
come[color=darkred]
compiler[color=darkred]
http://h71000.www7.hp.com/doc/73fin...5.html#data_typ[color=darkred]
could[color=darkred]
the[color=darkred]
and[color=darkred]
it[color=darkred]
>
>
| |
|
| Thanks, yet 199 does not go into the block length 32600 evenly.
I thought that was a requirement.
Is that a problem?
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40f86929.445252074@news.optonline.net...
> "Carol" <kgdg@helkusa.com> wrote:
>
>
> Length of the third field is 2, not 4, so the record length is 199. Look
at the
> data to see how long records are. It should be easy to spot CO-NO, which
appears
> to be a constant or at least the same for several records.
>
> I used to process 1-10 requests per w for such conversions. I charged a
flat
> rate of $50 per, with possible discount to $25 if they could supply a
copybook.
> They almost never could. Instead they sent a text document that management
> thought was usable.
>
>
for[color=darkred]
system[color=darkred]
"normal"[color=darkred]
>
| |
| William M. Klein 2004-07-17, 3:55 am |
| IBM (and possibly other vendors) allow for SPANNED records - that span multiple
blocks. I *doubt* this is your case, but it at least represents a possibility.
The other is that the copy-book you have was used in the COBOL working-storage
and the data was MOVED to a file bugger - where records were larger, e.g.
working-storage was 199 - but the file defined a record of 200. In that case
you should see some "filler" (hex-zeroes, spaces, or even JUNK) at the end of
each individual record.
--
Bill Klein
wmklein <at> ix.netcom.com
"Carol" <kgdg@helkusa.com> wrote in message
news:o7idnWV4PcqYEGXdRVn-tw@comcast.com...
> Thanks, yet 199 does not go into the block length 32600 evenly.
>
> I thought that was a requirement.
> Is that a problem?
>
>
>
> "Robert Wagner" <robert.deletethis@wagner.net> wrote in message
> news:40f86929.445252074@news.optonline.net...
> at the
> appears
> flat
> copybook.
> for
> system
> "normal"
>
>
| |
|
| The Family wrote:
> Perhaps not. I thought about that just as I was making that post.
>
> But, I still was not aware that 77's & 01-99's could be mixed,
01-99? Try 01-49, 66, 77, 88. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Lueko Willms 2004-07-20, 3:55 am |
| .. Am 16.07.04
schrieb kgdg@helkusa.com (Carol)
auf /COMP/LANG/COBOL
in e9idnSfgcbiTlGXdRVn-hA@comcast.com
ueber Re: Layout Hell.
k> The data is current.
k> This data came from another company.
k> I do not have access to the people at that company because of
k> political stuff.
Then you have to figure it out all by yourself -- and with the help
of some friends.
k> All I have are 20 tapes and 20 file layouts and no experience.
Having no experience is a challenge to acquire it.
And this apparently goes well with this:
k> Plus I am supposed to represent our company as being real smart
k> .tee hee.
Sure, having no experience at all is very smart, but only if you
figure out what you don't know yet.
I think under these circumstances your best way forward is to get a
dump of a couple of records of each of those tapes, use the COBOL
record descriptions you have, and apply your best guess as to what is
what in the record layout.
When the COBOL description says "PIC X(somenumber)" it is easy --
you will typically have one byte per character, and depending on the
source machine, you will have a choice of EBCDIC or ASCII.
COMP-3 is nearly always packed-decimal, i.e. a numeric format where
each digit of a 10-based-system (i.e. decimal) is represented by one
half byte of a byte, and (normally) the last half byte does represent
the sign of the number (if it is a hex "C". i.e. binary 1100, this
means it is positive, and another value says the number is negative,
but people with more current acquaintance with those big iron
following the IBM byte architecture will know it better).
Other COMP-USAGEs are probably some kind of machine-dependent
representation -- and which n of those COMP-n does mean byte, 16-bit-
entity, 32-bit-word, or more, is something you know better if you have
some idea of the originating hardware and operating system, and also
if it uses the regular bit sequence -- the most significant coming
first -- or that peculiar Intel shuffeling of the more and less
significant bytes or half-words...
k> When you guys ask what compiler is used..
k>
k> Do you mean what machine dumped the data?
This is number 1 in the equation.
k> Or what machine do I have that is reading the data.
Also, but you have already the main part when you can dump some
records of those tapes using some tape analasys utility of the machine
wehre you are supposed to get the data from those tapes.
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
"Nach meiner Ansicht besitzt die Presse _das_ _Recht_,
Schriftsteller, Politiker, Komödianten und andere öffentliche
Charaktere zu _beleidigen_. Achtete ich [so einen Angriff gegen mich]
einer Notiz wert, so galt mir in solchen Fällen der Wahlspruch: à
corsaire, corsaire et demi [auf einen Schelmen anderthalben]."
- Karl Marx 17.11.1860 (Herr Vogt, Kapitel XI)
| |
|
| thanks, my friend
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9DAk-RieflB@jpberlin-l.willms.jpberlin.de...
> . Am 16.07.04
> schrieb kgdg@helkusa.com (Carol)
> auf /COMP/LANG/COBOL
> in e9idnSfgcbiTlGXdRVn-hA@comcast.com
> ueber Re: Layout Hell.
>
> k> The data is current.
> k> This data came from another company.
> k> I do not have access to the people at that company because of
> k> political stuff.
>
> Then you have to figure it out all by yourself -- and with the help
> of some friends.
>
> k> All I have are 20 tapes and 20 file layouts and no experience.
>
> Having no experience is a challenge to acquire it.
>
> And this apparently goes well with this:
>
> k> Plus I am supposed to represent our company as being real smart
> k> .tee hee.
>
> Sure, having no experience at all is very smart, but only if you
> figure out what you don't know yet.
>
>
> I think under these circumstances your best way forward is to get a
> dump of a couple of records of each of those tapes, use the COBOL
> record descriptions you have, and apply your best guess as to what is
> what in the record layout.
>
> When the COBOL description says "PIC X(somenumber)" it is easy --
> you will typically have one byte per character, and depending on the
> source machine, you will have a choice of EBCDIC or ASCII.
>
> COMP-3 is nearly always packed-decimal, i.e. a numeric format where
> each digit of a 10-based-system (i.e. decimal) is represented by one
> half byte of a byte, and (normally) the last half byte does represent
> the sign of the number (if it is a hex "C". i.e. binary 1100, this
> means it is positive, and another value says the number is negative,
> but people with more current acquaintance with those big iron
> following the IBM byte architecture will know it better).
>
> Other COMP-USAGEs are probably some kind of machine-dependent
> representation -- and which n of those COMP-n does mean byte, 16-bit-
> entity, 32-bit-word, or more, is something you know better if you have
> some idea of the originating hardware and operating system, and also
> if it uses the regular bit sequence -- the most significant coming
> first -- or that peculiar Intel shuffeling of the more and less
> significant bytes or half-words...
>
>
> k> When you guys ask what compiler is used..
> k>
> k> Do you mean what machine dumped the data?
>
> This is number 1 in the equation.
>
> k> Or what machine do I have that is reading the data.
>
> Also, but you have already the main part when you can dump some
> records of those tapes using some tape analasys utility of the machine
> wehre you are supposed to get the data from those tapes.
>
>
> Yours,
> Lüko Willms http://www.mlwerke.de
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
> "Nach meiner Ansicht besitzt die Presse _das_ _Recht_,
> Schriftsteller, Politiker, Komödianten und andere öffentliche
> Charaktere zu _beleidigen_. Achtete ich [so einen Angriff gegen mich]
> einer Notiz wert, so galt mir in solchen Fällen der Wahlspruch: à
> corsaire, corsaire et demi [auf einen Schelmen anderthalben]."
> - Karl Marx 17.11.1860 (Herr Vogt, Kapitel XI)
| |
| Robert Wagner 2004-07-22, 3:55 pm |
| "Carol" <kgdg@helkusa.com> wrote:
>Could I have some help with this layout?
>I am new to the layout scene, but if I could see some real examples, I might
>get it. Then again, I might club myself with a shovel.
>Thank you.
>I just need to convert this file to Access or something normal.
>Do you have any thoughts?
>Thanks you.
See one solution in a new thread -- Demo: convert Cobol file to csv
| |
|
| Thanks, man!
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40ffe8da.70647174@news.optonline.net...
> "Carol" <kgdg@helkusa.com> wrote:
>
might[color=darkred]
>
> See one solution in a new thread -- Demo: convert Cobol file to csv
| |
| Richard 2004-07-22, 8:55 pm |
| robert.deletethis@wagner.net (Robert Wagner) wrote
>
> See one solution in a new thread -- Demo: convert Cobol file to csv
I think that you _completely_ miss the point Robert.
| |
| Robert Wagner 2004-07-22, 8:55 pm |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>
>I think that you _completely_ miss the point Robert.
The point was to convert Carol's file to a format that Access (or Excel) could
handle.
I'm not into 'Zen wisdom' so just say what you think the point was. Hint: she
wasn't looking for an education in 'the idiosyncrasies of Cobol that only we
geniuses can understand'. She just wanted to get the damn file converted and
move on. I gave her and the numerous others who post similar queries a free tool
to get the job done. I spent four (billable) hours writing it. It worked the
third time. I love writing this type software.
| |
| William M. Klein 2004-07-22, 8:55 pm |
| Robert,
In this thread, Carol stated,
"When you guys ask what compiler is used..
Do you mean what machine dumped the data?
Or what machine do I have that is reading the data."
This lead some of us to believe that Carol neither has, nor has access to a
COBOL compiler.
She also stated,
"I do not have access to the people at that company because of political
stuff.
All I have are 20 tapes and 20 file layouts and no experience.
Plus I am supposed to represent our company as being real smart .tee hee."
which makes it look as if anyone trying to get the original provider to do the
conversion, is not providing an adequate solution.
This is why I (and possibly others) didn't think that your "COBOL program to do
the conversion" solution - was a responsive solution. However, the thread has
gone on long enough that you may have missed these "restrictions" on what
solution would be viable.
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:410042b5.93653409@news.optonline.net...
> riplin@Azonic.co.nz (Richard) wrote:
>
might[color=darkred]
>
> The point was to convert Carol's file to a format that Access (or Excel) could
> handle.
>
> I'm not into 'Zen wisdom' so just say what you think the point was. Hint: she
> wasn't looking for an education in 'the idiosyncrasies of Cobol that only we
> geniuses can understand'. She just wanted to get the damn file converted and
> move on. I gave her and the numerous others who post similar queries a free
tool
> to get the job done. I spent four (billable) hours writing it. It worked the
> third time. I love writing this type software.
| |
| Frederico Fonseca 2004-07-22, 8:55 pm |
| On Thu, 22 Jul 2004 23:35:44 GMT, robert.deletethis@wagner.net (Robert
Wagner) wrote:
>riplin@Azonic.co.nz (Richard) wrote:
>
>
>The point was to convert Carol's file to a format that Access (or Excel) could
>handle.
>
>I'm not into 'Zen wisdom' so just say what you think the point was. Hint: she
>wasn't looking for an education in 'the idiosyncrasies of Cobol that only we
>geniuses can understand'. She just wanted to get the damn file converted and
>move on. I gave her and the numerous others who post similar queries a free tool
>to get the job done. I spent four (billable) hours writing it. It worked the
>third time. I love writing this type software.
YOU DID miss the point.
She does not have the FD for the file, so your program is useless to
her unless she can find the missing info.
Even if she does have a FD, if it contains redefines she will still be
unable to figure out how to deal with them.
I have customers that on the same file have hundreds of different
record layouts. Having a FD that says
01 tbl-record.
05 tbl-key pic x(50).
05 tbl-data pic x(2000).
does not help anyone. This type of information can be normally
retrieved by program rmpmapinx.cob that is supplied with the RM/COBOL
runtime/compiler. Other compilers have similar tools (e.g. Acucobol
has VUTIL).
So although your program may work very well on some situations, and
can also be a base for someone to build their own converters, it is
not A tool for every job, and certainly not for this one.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
| |
| Richard 2004-07-23, 3:55 am |
| robert.deletethis@wagner.net (Robert Wagner) wrote
>
> The point was to convert Carol's file to a format that Access (or Excel) could
> handle.
>
> I'm not into 'Zen wisdom'
That had been noticed.
> so just say what you think the point was.
If she had a Cobol compiler and an FD that provably matched the data
_tapes_ then she wouldn't have the problem.
C >> I have 20 tapes and 20 file layoiuts. Maybe this file layout does
C >> not go with this tape?
C>> I have a job to convert these tapes form cobol to ascii text.
C>> I have a program to do this, but as you know I have to script it
C>> with the file layout.
> Hint: she
> wasn't looking for an education in 'the idiosyncrasies of Cobol that only we
> geniuses can understand'.
Yet you sent her something that required her to know things that 'only
we geniuses' could so something with, such as compile. And BTW how
would Fujitsu v3 read a _tape_ ?
> She just wanted to get the damn file converted and
> move on. I gave her and the numerous others who post similar queries a free
> tool
> to get the job done.
She already had a tool, what she didn't have was an FD that made
sense.
I'll repeat that bit, you probably missed it _again_:
C>> I have a program to do this, but as you know I have to script it
C>> with the file layout.
Given that your 'solution' required a usable FD it doesn't make any
progress at all. As I said you _completely_ missed the point, as you
seem to do so frequently.
> I spent four (billable) hours writing it. It worked the third time. I love
> writing this type software.
Yes and you grab every opportunity to try to show how you are one of
"we geniuses" when a few minutes of reading the actual problem domain
would have gone a lot further in doing that.
BTW, I thought the problem _might_ be that it is in EBCDIC on an ASCII
machine, or vice versa, and thus nonsense is coming out of her
converter program. There is no evidence either way in this thread.
| |
| Michael Mattias 2004-07-23, 8:55 am |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:rAYLc.10317$mL5.8164@newsread1.news.pas.earthlink.net...
> This is why I (and possibly others) didn't think that your "COBOL program
to do
> the conversion" solution - was a responsive solution. However, the thread
has
> gone on long enough that you may have missed these "restrictions" on what
> solution would be viable.
Threads in _this_ newsgroup which get so long they wander from the original
question and forget stated restrictions?
I'm shocked, shocked.
MCM
| |
| docdwarf@panix.com 2004-07-23, 8:55 am |
| In article <J07Mc.2722$5U2.1954@newssvr15.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:
>"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
>news:rAYLc.10317$mL5.8164@newsread1.news.pas.earthlink.net...
>
>Threads in _this_ newsgroup which get so long they wander from the original
>question and forget stated restrictions?
>
>I'm shocked, shocked.
Your winnings, Sir?
DD
| |
| Robert Wagner 2004-07-23, 3:55 pm |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>Robert,
> In this thread, Carol stated,
>
>"When you guys ask what compiler is used..
>
>Do you mean what machine dumped the data?
>Or what machine do I have that is reading the data."
>
>This lead some of us to believe that Carol neither has, nor has access to a
>COBOL compiler.
I acknowledged that, followed by suggestions of enlisting a Cobol programmer and
downloading a free compiler.
>She also stated,
>
>"I do not have access to the people at that company because of political
>stuff.
>All I have are 20 tapes and 20 file layouts and no experience.
>Plus I am supposed to represent our company as being real smart .tee hee."
>
>which makes it look as if anyone trying to get the original provider to do the
>conversion, is not providing an adequate solution.
You're right. I'd forgotten the part about "political stuff".
>This is why I (and possibly others) didn't think that your "COBOL program to do
>the conversion" solution - was a responsive solution. However, the thread has
>gone on long enough that you may have missed these "restrictions" on what
>solution would be viable.
A Cobol solution is easy because of packed decimal. Outside the mainframe world,
few languages can handle that format. It can be done with shifts or division by
256, but the code would be ugly and inappropriate to this Cobol newsgroup.
I used to bristle when people used the phrase 'Cobol file'. I'd say, 'Cobol
doesn't define unique data types, they are universal to all languages.' That
used to be true when mainframes ruled the land. In today's world of PCs and Unix
machines, Cobol is the last bastion of packed decimal.
The best solution would be an Excel plugin written in Cobol as a COM object.
That would be interesting. It would take (me) longer than four hours to write.
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:410042b5.93653409@news.optonline.net...
>might
could[color=darkred]
>tool
>
>
| |
| Robert Wagner 2004-07-23, 3:55 pm |
| Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:
>On Thu, 22 Jul 2004 23:35:44 GMT, robert.deletethis@wagner.net (Robert
>Wagner) wrote:
>
[color=darkred]
tool[color=darkred]
>YOU DID miss the point.
>
>She does not have the FD for the file, so your program is useless to
>her unless she can find the missing info.
What information? When I write an FD, it says 'fd input-file.' Examples are in
the demo.
>Even if she does have a FD, if it contains redefines she will still be
>unable to figure out how to deal with them.
She posted a single copybook, which means all records have that format.
>I have customers that on the same file have hundreds of different
>record layouts. Having a FD that says
>01 tbl-record.
> 05 tbl-key pic x(50).
> 05 tbl-data pic x(2000).
>
>does not help anyone. This type of information can be normally
>retrieved by program rmpmapinx.cob that is supplied with the RM/COBOL
>runtime/compiler. Other compilers have similar tools (e.g. Acucobol
>has VUTIL).
>
>So although your program may work very well on some situations, and
>can also be a base for someone to build their own converters, it is
>not A tool for every job, and certainly not for this one.
Granted, there are files with complex record formats. I've written tools to
handle them. But in this case, which is typical of most, records have a single
format defined in the copybook.
You are taking a simple problem and trying to make it complicated.
| |
|
| I do not have a cobol compiler. I have colbol tapes, and i sit waiting at a
windows computer.
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:410042b5.93653409@news.optonline.net...
> riplin@Azonic.co.nz (Richard) wrote:
>
might[color=darkred]
>
> The point was to convert Carol's file to a format that Access (or Excel)
could
> handle.
>
> I'm not into 'Zen wisdom' so just say what you think the point was. Hint:
she
> wasn't looking for an education in 'the idiosyncrasies of Cobol that only
we
> geniuses can understand'. She just wanted to get the damn file converted
and
> move on. I gave her and the numerous others who post similar queries a
free tool
> to get the job done. I spent four (billable) hours writing it. It worked
the
> third time. I love writing this type software.
| |
|
| just ask me!
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0407222332.538d74c5@posting.google.com...
> robert.deletethis@wagner.net (Robert Wagner) wrote
>
could[color=darkred]
>
> That had been noticed.
>
>
> If she had a Cobol compiler and an FD that provably matched the data
> _tapes_ then she wouldn't have the problem.
>
> C >> I have 20 tapes and 20 file layoiuts. Maybe this file layout does
> C >> not go with this tape?
>
> C>> I have a job to convert these tapes form cobol to ascii text.
> C>> I have a program to do this, but as you know I have to script it
> C>> with the file layout.
>
only we[color=darkred]
>
> Yet you sent her something that required her to know things that 'only
> we geniuses' could so something with, such as compile. And BTW how
> would Fujitsu v3 read a _tape_ ?
>
free[color=darkred]
>
> She already had a tool, what she didn't have was an FD that made
> sense.
>
> I'll repeat that bit, you probably missed it _again_:
>
> C>> I have a program to do this, but as you know I have to script it
> C>> with the file layout.
>
> Given that your 'solution' required a usable FD it doesn't make any
> progress at all. As I said you _completely_ missed the point, as you
> seem to do so frequently.
>
love[color=darkred]
>
> Yes and you grab every opportunity to try to show how you are one of
> "we geniuses" when a few minutes of reading the actual problem domain
> would have gone a lot further in doing that.
>
> BTW, I thought the problem _might_ be that it is in EBCDIC on an ASCII
> machine, or vice versa, and thus nonsense is coming out of her
> converter program. There is no evidence either way in this thread.
| |
| Frederico Fonseca 2004-07-23, 3:55 pm |
| On Fri, 23 Jul 2004 12:04:37 -0600, "Carol" <kgdg@helkusa.com> wrote:
>just ask me!
Carol,
If you still haven't solved your problem please contact me by email.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
| |
| Richard 2004-07-23, 8:55 pm |
| "Carol" <kgdg@helkusa.com> wrote
> just ask me!
[color=darkred]
Do you 20 different file layouts, one for each tape ? Are the tapes
supposed to be of 20 different files or of one file for 20 different
time periods ?
Are these reel to reel or cartridge tapes ?
What machine and operating system were used to write the tapes ?
Can you physically read them on some machine ?
Are they data tapes or archive tapes ?
A data tape is likely to have just one file on it, an archive tape may
have one or more data files 'bundled' using, say tar, or similar, and
may be data compressed.
Are the tapes (or the files within) in EBCDIC or ASCII or some other ?
[color=darkred]
[color=darkred]
What particular program is that ? What results has it given ?
Probably the most useful thing would be if you could provide a hex
dump of the first 1000 bytes of the tape and what you believe to be
the record description.
| |
| Robert Wagner 2004-07-23, 8:55 pm |
| riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>If she had a Cobol compiler and an FD that provably matched the data
>_tapes_ then she wouldn't have the problem.
She has a way of reading tapes. I took that to mean she has access to a
mainframe. She cannot write 20 conversion programs because she doesn't know
Cobol. Whether she has access to a Cobol compiler isn't clear. Most mainframes
do. Getting a programmer, even one from another shop, to compile my program *one
time* would give her the tool she needs.
>C>> I have a job to convert these tapes from cobol to ascii text.
>C>> I have a program to do this, but as you know I have to script it
>C>> with the file layout.
Again, "to ascii text" sounds like the conversion is running on a mainframe. My
program 'writes its own script'.
>Yet you sent her something that required her to know things that 'only
>we geniuses' could so something with, such as compile.
Companies with mainframes have programmers capable of compiling a program. If
she asks nicely, they'll do it 'under the radar'. If she asks them to write 20
programs, they'll require paperwork and approvals.
> And BTW how would Fujitsu v3 read a _tape_ ?
She could FTP (or NDM) the files to a PC in Binary mode and do the conversion
there. That would require a one-statement EBCDIC-to-ASCII conversion in my
convert-string paragraph. Someone here could easily provide that statement ..
and start another long thread.
>C>> I have a program to do this, but as you know I have to script it
>C>> with the file layout.
>
>Given that your 'solution' required a usable FD it doesn't make any
>progress at all. As I said you _completely_ missed the point, as you
>seem to do so frequently.
I 'wrote the script' internally, then used it to convert the file. If she
prefers to use her own tool and is willing to describe its scripting language,
I'll modify my program to spit script into a text file. It seems pointless to
run two tools rather than one.
>BTW, I thought the problem _might_ be that it is in EBCDIC on an ASCII
>machine, or vice versa, and thus nonsense is coming out of her
>converter program. There is no evidence either way in this thread.
The data is very likely in EBCDIC. Unix and PC shops do not exchange data via
tape. They do it with FTP, NFS Mount, Samba, email, etc. Worst case, they'd
write the files to a CD, not a tape.
| |
| Robert Wagner 2004-07-23, 8:55 pm |
| "Carol" <kgdg@helkusa.com> wrote:
>just ask me!
OK.
Is the conversion running on a mainframe?
Does the machine have a Cobol compiler?
Could you move the file to a PC (by FTP, NDM or email) and convert it there?
| |
|
| 20 different tapes. 20 different piles of data.
All in the Same year.
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0407231420.40ce2e5e@posting.google.com...
> "Carol" <kgdg@helkusa.com> wrote
>
>
>
> Do you 20 different file layouts, one for each tape ? Are the tapes
> supposed to be of 20 different files or of one file for 20 different
> time periods ?
>
> Are these reel to reel or cartridge tapes ?
> What machine and operating system were used to write the tapes ?
> Can you physically read them on some machine ?
> Are they data tapes or archive tapes ?
>
> A data tape is likely to have just one file on it, an archive tape may
> have one or more data files 'bundled' using, say tar, or similar, and
> may be data compressed.
>
> Are the tapes (or the files within) in EBCDIC or ASCII or some other ?
>
>
>
> What particular program is that ? What results has it given ?
>
> Probably the most useful thing would be if you could provide a hex
> dump of the first 1000 bytes of the tape and what you believe to be
> the record description.
| |
|
| The files are being read by Novastor tape drive and software.
This software converts the data, if only it knew how to read the copybooks.
I have to do all the parameters by hand.
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:4101922c.20784546@news.optonline.net...
> "Carol" <kgdg@helkusa.com> wrote:
>
>
> OK.
>
> Is the conversion running on a mainframe?
>
> Does the machine have a Cobol compiler?
>
> Could you move the file to a PC (by FTP, NDM or email) and convert it
there?
>
>
>
| |
|
| CD is not big enough.
We are talking mabye 200 gig of data.,
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:41018a1d.18721187@news.optonline.net...
> riplin@Azonic.co.nz (Richard) wrote:
>
>
>
> She has a way of reading tapes. I took that to mean she has access to a
> mainframe. She cannot write 20 conversion programs because she doesn't
know
> Cobol. Whether she has access to a Cobol compiler isn't clear. Most
mainframes
> do. Getting a programmer, even one from another shop, to compile my
program *one
> time* would give her the tool she needs.
>
>
> Again, "to ascii text" sounds like the conversion is running on a
mainframe. My
> program 'writes its own script'.
>
>
> Companies with mainframes have programmers capable of compiling a program.
If
> she asks nicely, they'll do it 'under the radar'. If she asks them to
write 20
> programs, they'll require paperwork and approvals.
>
>
> She could FTP (or NDM) the files to a PC in Binary mode and do the
conversion
> there. That would require a one-statement EBCDIC-to-ASCII conversion in my
> convert-string paragraph. Someone here could easily provide that statement
...
> and start another long thread.
>
>
> I 'wrote the script' internally, then used it to convert the file. If she
> prefers to use her own tool and is willing to describe its scripting
language,
> I'll modify my program to spit script into a text file. It seems pointless
to
> run two tools rather than one.
>
>
> The data is very likely in EBCDIC. Unix and PC shops do not exchange data
via
> tape. They do it with FTP, NFS Mount, Samba, email, etc. Worst case,
they'd
> write the files to a CD, not a tape.
>
| |
| Robert Wagner 2004-07-24, 3:55 pm |
| "Carol" <kgdg@helkusa.com> wrote:
>The files are being read by Novastor tape drive and software.
>This software converts the data, if only it knew how to read the copybooks.
>I have to do all the parameters by hand.
The NovaXchange manual is at
http://www.novastor.com/pub/docs/NovaXchange3.pdf
Go to Tape Inspector and select View to use the Hex Editor.
Toggle between ASCII and EBCDIC. Pic x fields will be readable in one, not the
other. That will be the type for pic x in your script.
Next look at comp-3 fields. On the hex screen, you should see a digit 0-9 in
each position (half byte) except the rightmost, which should have a C positive
sign. If you see anything different, post it here and someone will figure it
out.
Finally, look at comp fields to see whether zero values are predominantly on the
left or right side. These are called small-endian and big-endian, respectively.
If text is EBCDIC, the file was created on a mainframe, where comp is always
small-endian.
Now you are ready to write the script, where types will be:
Pic x -- EBCDIC or ASCII
Comp-3 -- pack_lowsign
Comp -- bin_msb if zeros were on left or bin_lsb if they were on the right
Pic 9 without comp -- ebc_zon_ls if text is EBCDIC. If text is ASCII and sign is
'zoned', you are out of luck. NovaXchange doesn't support that format.
Examples:
field = CTLGOP-CO-NO EBCDIC pic xxx
field = CTLGCONTROL-SET-SEQ-NO bin_msg pic 999999999.
field = CTLGINVOICE-SEQ-NO bin_msb pic 9999
....
field = CTLGAP-VENDOR-NO EBCDIC * 30
field = CTLGTOTAL-INVOICE-AM pack_lowsign pic 99999999999v99
field = DUE-DATE pack_lowsign date pic yymmdd -20
(sliding date window of current year - 20)
If there are large comp fields, observe carefully how many bytes NovaXchange
allocates. Mathematically, pic s9(15) requires seven bytes for representation.
Most, but not all, Cobol compilers will allocate eight.
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:4101922c.20784546@news.optonline.net...
>there?
| |
| Robert Wagner 2004-07-24, 3:55 pm |
| "Carol" <kgdg@helkusa.com> wrote:
>CD is not big enough.
>We are talking mabye 200 gig of data.,
For Expenses Payable? You are going to load 200G into a Jet (Access) database?
| |
|
| hoily moly robert . That's great
!
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:4102600c.1996735@news.optonline.net...
> "Carol" <kgdg@helkusa.com> wrote:
>
copybooks.[color=darkred]
>
> The NovaXchange manual is at
> http://www.novastor.com/pub/docs/NovaXchange3.pdf
>
> Go to Tape Inspector and select View to use the Hex Editor.
>
> Toggle between ASCII and EBCDIC. Pic x fields will be readable in one, not
the
> other. That will be the type for pic x in your script.
>
> Next look at comp-3 fields. On the hex screen, you should see a digit 0-9
in
> each position (half byte) except the rightmost, which should have a C
positive
> sign. If you see anything different, post it here and someone will figure
it
> out.
>
> Finally, look at comp fields to see whether zero values are predominantly
on the
> left or right side. These are called small-endian and big-endian,
respectively.
> If text is EBCDIC, the file was created on a mainframe, where comp is
always
> small-endian.
>
> Now you are ready to write the script, where types will be:
>
> Pic x -- EBCDIC or ASCII
> Comp-3 -- pack_lowsign
> Comp -- bin_msb if zeros were on left or bin_lsb if they were on the right
> Pic 9 without comp -- ebc_zon_ls if text is EBCDIC. If text is ASCII and
sign is
> 'zoned', you are out of luck. NovaXchange doesn't support that format.
>
> Examples:
>
> field = CTLGOP-CO-NO EBCDIC pic xxx
> field = CTLGCONTROL-SET-SEQ-NO bin_msg pic 999999999.
> field = CTLGINVOICE-SEQ-NO bin_msb pic 9999
> ...
> field = CTLGAP-VENDOR-NO EBCDIC * 30
> field = CTLGTOTAL-INVOICE-AM pack_lowsign pic 99999999999v99
>
> field = DUE-DATE pack_lowsign date pic yymmdd -20
> (sliding date window of current year - 20)
>
> If there are large comp fields, observe carefully how many bytes
NovaXchange
> allocates. Mathematically, pic s9(15) requires seven bytes for
representation.
> Most, but not all, Cobol compilers will allocate eight.
>
>
>
| |
|
| A whole bunch of them.
The whole thing is pointless, isn't it!!!
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:4102890f.12497045@news.optonline.net...
> "Carol" <kgdg@helkusa.com> wrote:
>
>
> For Expenses Payable? You are going to load 200G into a Jet (Access)
database?
>
>
>
| |
| Robert Wagner 2004-07-24, 3:55 pm |
| "Carol" <kgdg@helkusa.com> wrote:
>A whole bunch of them.
>The whole thing is pointless, isn't it!!!
I haven't worked with Jet much, but have seen MANY reports on the Web
complaining about corruption and slow performance when loaded with 1G tables.
Google and Yahoo use MySQL for databases much larger than yours. It's free, very
fast and reported to be reliable.
I fear you're setting yourself up for failure by using Jet.
The _point_ is doing something 'they' thought you couldn't. Even if the project
is poorly managed from a business point of view, getting it done would be a
personal success. It'll look good on your resume, and will probably make sense
at the next company.
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:4102890f.12497045@news.optonline.net...
>database?
|
|
|
|
|