Connecting to another system

[David]

Hi all,

I don't know if this question will be accepted here, but I could do with a
few pointers. I had considered the sql server groups, but they don't really
match either.

I have to get (and send) data from / to a cobol application on a sco unix
system.

I am writing in C#, .net 3.5 with asp.net.

The flat file data looks a bit awkward and as yet, I don't know what data I
require. There will be a lot of various bits of data I need.

Now, I had considered running a telnet type of session within code and
sending keystrokes but this could be extremely complicated to handle.

Talking with the client, we have agreed that they will send me a CSV file of
specific data and I will send them a CSV file with update data. However,
what I currently have is the flat file DB schema, which at the moment, I am
not sure I understand. (The schema looks like it is heavily nested and as
yet, I don't know how I would transfer that into a Sql DB).

While investigating this, I have seen talk of ODBC to connect to cobol flat
file. I checked my ODBC but there are no drivers, so it will be a specific
driver. Not knowing anything about cobol though, will the ODBC present the
data in a form that I am more used to? Also, does anyone know where I can
get an ODBC driver and what I need to do on the unix system as well in order
for me to connect to it?

The project I am working on was a reasonable sized project to start with,
but as I am getting more into it, the bigger problems we are finding. The
connectivity to the cobol data is the biggest problem and I sure could do
with more information on how to break this problem down into manageable
chunks.

Thanks.
--
Best regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Local franchises available

 

[Mr. Arnold]

Hi all,

I don't know if this question will be accepted here, but I could do with a
few pointers. I had considered the sql server groups, but they don't
really match either.

I have to get (and send) data from / to a cobol application on a sco unix
system.

I am writing in C#, .net 3.5 with asp.net.

The flat file data looks a bit awkward and as yet, I don't know what data
I require. There will be a lot of various bits of data I need.

Now, I had considered running a telnet type of session within code and
sending keystrokes but this could be extremely complicated to handle.

Talking with the client, we have agreed that they will send me a CSV file
of specific data and I will send them a CSV file with update data.
However, what I currently have is the flat file DB schema, which at the
moment, I am not sure I understand. (The schema looks like it is heavily
nested and as yet, I don't know how I would transfer that into a Sql DB).

While investigating this, I have seen talk of ODBC to connect to cobol
flat file. I checked my ODBC but there are no drivers, so it will be a
specific driver. Not knowing anything about cobol though, will the ODBC
present the data in a form that I am more used to? Also, does anyone know
where I can get an ODBC driver and what I need to do on the unix system as
well in order for me to connect to it?

The project I am working on was a reasonable sized project to start with,
but as I am getting more into it, the bigger problems we are finding. The
connectivity to the cobol data is the biggest problem and I sure could do
with more information on how to break this problem down into manageable
chunks.

Why don't you just keep it simple.

http://www.codeproject.com/KB/vbscript/xml2csv.aspx

There are good books on Linq.

http://sqldud.blogspot.com/

You can load the XML into a SQL server 2005 message queue and use SQL Server
Service Broker to load data to do CRUD operations to tables. There are good
books out there for SQL Server 2005/2008 Service Broker.

http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx

http://www.codeplex.com/ssbwcf

cvs-2-xml-2-sql server
sql server-2-xml-cvs

You have .Net 3.5 Framework, so use the power that's there.

So why can't the client send/receive XML?

What does ODBC have to do with this?







__________ Information from ESET NOD32 Antivirus, version of virus signature database 4292 (20090730) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[David]

Why don't you just keep it simple.

http://www.codeproject.com/KB/vbscript/xml2csv.aspx

There are good books on Linq.

http://sqldud.blogspot.com/

You can load the XML into a SQL server 2005 message queue and use SQL
Server Service Broker to load data to do CRUD operations to tables. There
are good books out there for SQL Server 2005/2008 Service Broker.

http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx

http://www.codeplex.com/ssbwcf

cvs-2-xml-2-sql server
sql server-2-xml-cvs

You have .Net 3.5 Framework, so use the power that's there.

So why can't the client send/receive XML?

What does ODBC have to do with this?

I don't think it is that simple...

As yet, I don't have the CSV to see it, but it could just be about the
interpretation of it. I don't know what the cobol data looks like... I have
been given a schema like...

01 agr-rec
03 agr-status-key
05 agr-rec-status pic 9.
05 agr-cus-key
07 agr-cus-branch
09 agr-cus-code pic x(5)
09 agr-cus-br-code pic x(5)
07 agr-ck-agr-no.
09 agr-ck-depot pic xx
09 agr-ak-agr-num pic 9(6).
03 agr-fn-key.

Number at start of line is "level number". All level 09 fields are contained
within 07 field, all 07's within 05, all 05's with 03 and all 03's within
01. So 01 is a "record"

a 9 is a number field. an x is an alphanumeric. The number in brackets are
the width of the field, if no bracketted number, then is is the count of
characters, for example, xx = two alphanumeric characters in the field.

This is just a sample schema that was given to me to explain how it works.
The result format could be as simple as:
9 aaaaa aaaaa 99 999999 (9 = number, a = alphanumeric)

The ODBC side of it... I was hoping that there might be an ODBC driver that
will talk to cobol based data... however, it seems like it might be the
other way around, i.e. there is an ODBC driver that allows COBOL to talk to
databases like MySQL, SQL Server etc.

To do the import, I was just going to write a service or scheduled task. It
will only be done at certain times of the day and is not too ctitical. (The
data cycle is about 6 weeks... i.e. it will normally be 6 weeks before the
data for a particular item is likely to be called upon again)


--
Best regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Local franchises available

 

[David]

It would take me too long to learn .Net Cobol. I had thought about this but
have dismissed it due to the time to learn it and the possible lack of
future use of the skillset.

--
Best regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Local franchises available

 

[Travis Long]

Let's look at that file description you provided earlier

01 agr-rec
03 agr-status-key
05 agr-rec-status pic 9.
05 agr-cus-key
07 agr-cus-branch
09 agr-cus-code pic x(5)
09 agr-cus-br-code pic x(5)
07 agr-ck-agr-no.
09 agr-ck-depot pic xx
09 agr-ak-agr-num pic 9(6).


Note I removed "03 agr-fn-key." from the bottom because without the levels
below it that contain "pic" clauses it is irrelevant.

You have it right David, except no spaces to separate the data in COBOL =>
9aaaaaaaaaa99999999

Now that's really an ugly bit of data to just look at so it's good that your
client is providing you with a CSV
text file for you to read in. The nesting here really isn't important to
you. As long as you return them the
same CSV format with the data in the same order etc., all you have to do is
create one field for each 'pic'
clause that has the same constraints on the data as the 'pic' clause. (ie:
pic 9 could only be a single digit,
pic x(5) could only be 5 alpha-numeric chars). I'm pretty sure sqlServer
can import CSV files directly into
a table and vice-versa, export a table to CSV.