SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


IBM Hierarchical IMS Database model to RDBMS, options ?


IBM Hierarchical IMS Database model to RDBMS, options ?

Author
Message
Rankerg
Rankerg
SSChasing Mays
SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)

Group: General Forum Members
Points: 639 Visits: 59
Hi

COBOL / IMS Db migration to SQL Server / .NET, Need help on how to DATA Model from segments to tables, that too relational data model ?

It seems the referential integrity and other relations are maintained via code in Cobol app so how should I go about understanding the current Cobol IMS DB and design RDBMS ?

I was thinking of SIMPLY extract the Data in flat file/ excel and import it to SQL Server and design the relations from scratch, in order to do that, I need to understand the logic and queries of the IMS/DB I guess, I do NOT know COBOL so

step 1: have to rely on IN-HOUSE Cobol programmers

step 2: Understand the UI of the cobol app and with the extracted Data, build the design from scratch.
frederico_fonseca
frederico_fonseca
SSCertifiable
SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)

Group: General Forum Members
Points: 5224 Visits: 2640
I've done such a migration 4 years ago - migrate a IMS db to Sql server and mainframe cobol to Microfocus COBOL. we kept the core code in COBOL but the db interface was converted to C# using sql client calls.

http://www.tutorialspoint.com/ims_db/ims_db_quick_guide.htm contains information about IMS but you better off asking the developers as implementation can change depending on the application.

In order to understand how the records link to each other you should ask the client developers to see if they have a common ims access cobol program where all calls are executed through.
And ask them how do you call it when they wish to do the following operations
1 - read single record directly
2 - position a record pointer to a record on the chain
3 - read first or last record on a chain
4 - read next or prior record on the chain

In most cases the cobol program will setup the "key" to access the dataset and then call one of the IMS functions to access the data as per above.
Possible examples
MOVE 123 to invoice-number
call IMS using get-first
Invoice-record-line
...process record
then on a loop until eof or invoice-number not equal required number
call IMS using get-next
Invoice-record-line
process record


It is likely that your client has cobol copybooks that define each individual IMS record they deal with - those copybooks may have indication of which are the key fields for each record.

You will also need to consider that it is highly likely that a IMS dataset contains several type of records and that you will need to create a sql table for each type of record.

Adding to this it will also be highly likely that a IMS record will contain COBOL packed/binary data - you can't just extract the record as is and load to SQL - you will need to convert it to a edited version of of the fields prior to loading to SQL.

And... you said you are migration from cobol to sqlserver/.net - has your client considered the possibility of keeping part of the COBOL code?
Rankerg
Rankerg
SSChasing Mays
SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)

Group: General Forum Members
Points: 639 Visits: 59
Thank you so much

Please see my INLINE response below

frederico_fonseca (5/2/2016)
I've done such a migration 4 years ago - migrate a IMS db to Sql server and mainframe cobol to Microfocus COBOL. we kept the core code in COBOL but the db interface was converted to C# using sql client calls.

-- which db interface ? for IMS DB you created C# CODE ? How using client calls ? please explain and Do we have to migrate to MICROFOCUS Cobol first ?

http://www.tutorialspoint.com/ims_db/ims_db_quick_guide.htm contains information about IMS but you better off asking the developers as implementation can change depending on the application.

In order to understand how the records link to each other you should ask the client developers to see if they have a common ims access cobol program where all calls are executed through.
And ask them how do you call it when they wish to do the following operations
1 - read single record directly
2 - position a record pointer to a record on the chain
3 - read first or last record on a chain
4 - read next or prior record on the chain

In most cases the cobol program will setup the "key" to access the dataset and then call one of the IMS functions to access the data as per above.
Possible examples
MOVE 123 to invoice-number
call IMS using get-first
Invoice-record-line
...process record
then on a loop until eof or invoice-number not equal required number
call IMS using get-next
Invoice-record-line
process record


It is likely that your client has cobol copybooks that define each individual IMS record they deal with - those copybooks may have indication of which are the key fields for each record.

You will also need to consider that it is highly likely that a IMS dataset contains several type of records and that you will need to create a sql table for each type of record.

-- finding it difficult to comprehend above :-)

Adding to this it will also be highly likely that a IMS record will contain COBOL packed/binary data - you can't just extract the record as is and load to SQL - you will need to convert it to a edited version of of the fields prior to loading to SQL.

- - Well, the cobol developer already extracted some segment data into flat file first and then to excel.

And... you said you are migration from cobol to sqlserver/.net - has your client considered the possibility of keeping part of the COBOL code?

-- why keep COBOL Code ?

frederico_fonseca
frederico_fonseca
SSCertifiable
SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)

Group: General Forum Members
Points: 5224 Visits: 2640
going to reply to your 4 comments.
1 - you do not need to migrate to Microfocus - I was just stating what we did on our project.
regarding the using client calls this goes to application design.
. application layer
. data layer
the above apply to any language being it Cobol or C#
In our case we had
. cobol application -> core IO Module (Cobol) -> IMS DB calls
and we converted to
. cobol application -> core IO Module (C#) -> Sql statements using SQL Client

2 - Show this to your cobol developers - they will most likely understand it and explain to you what I mean

3 - Any cobol developer will know what to do and the one that supplied the file has probably done it already, but depending on volumes of data it may be better to do it differently - but this is outside the help I can give here.

4 - to that I ask "Why not?"
possible reasons why
. keep extensive business logic intact
. avoid making same mistakes on code that have already been fixed on cobol
. reuse cobol developers that know the application without the need for a full retraining in another language

Obviously all this is going to be highly dependent on what the application does, how extensive it is in terms of both business logic and volumes of data and how it is processed.

But for me as an Architect it would require that all possibilities are put on the table and then pros and cons analyzed and all alternatives are given so a decision can be taken on the way to go.

And my question here was not to suggest in any way that the decision is wrong - was only to confirm that the client has indeed taken this option in consideration - seen many that were not even aware they could do it.
Rankerg
Rankerg
SSChasing Mays
SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)

Group: General Forum Members
Points: 639 Visits: 59
Thanks Again and see my inline response

frederico_fonseca (5/3/2016)
going to reply to your 4 comments.
1 - you do not need to migrate to Microfocus - I was just stating what we did on our project.
regarding the using client calls this goes to application design.
. application layer
. data layer
the above apply to any language being it Cobol or C#
In our case we had
. cobol application -> core IO Module (Cobol) -> IMS DB calls
and we converted to
. cobol application -> core IO Module (C#) -> Sql statements using SQL Client
So you converted CORE IO MODULE to C# and IMS DB calls to SQL Statements in the SQL Server, IF yes, then I did not know that IMS DB calls are segregated / Separate like a Client - Server app.

Now, the IMS DB calls are written in COBOL or any other language like SQL ? because if I ask the COBOL Developer to separate IMS DB calls and show it to me, can he ?


2 - Show this to your cobol developers - they will most likely understand it and explain to you what I mean

3 - Any cobol developer will know what to do and the one that supplied the file has probably done it already, but depending on volumes of data it may be better to do it differently - but this is outside the help I can give here. -How else can we meet ?

4 - to that I ask "Why not?"
possible reasons why
. keep extensive business logic intact
. avoid making same mistakes on code that have already been fixed on cobol
. reuse cobol developers that know the application without the need for a full retraining in another language

Obviously all this is going to be highly dependent on what the application does, how extensive it is in terms of both business logic and volumes of data and how it is processed.

But for me as an Architect it would require that all possibilities are put on the table and then pros and cons analyzed and all alternatives are given so a decision can be taken on the way to go.

And my question here was not to suggest in any way that the decision is wrong - was only to confirm that the client has indeed taken this option in consideration - seen many that were not even aware they could do it.
Yes at an Architect Level, I am contemplating what MIGRATION route to go, as I only have 10 months left

1. Since not much data 500k records, I wask thinking MS Access
2. PHP and any DB
3. OO Java / .NET and any DB

frederico_fonseca
frederico_fonseca
SSCertifiable
SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)

Group: General Forum Members
Points: 5224 Visits: 2640
Rankerg (5/3/2016)
Thanks Again and see my inline response

frederico_fonseca (5/3/2016)
going to reply to your 4 comments.
1 - you do not need to migrate to Microfocus - I was just stating what we did on our project.
regarding the using client calls this goes to application design.
. application layer
. data layer
the above apply to any language being it Cobol or C#
In our case we had
. cobol application -> core IO Module (Cobol) -> IMS DB calls
and we converted to
. cobol application -> core IO Module (C#) -> Sql statements using SQL Client
So you converted CORE IO MODULE to C# and IMS DB calls to SQL Statements in the SQL Server, IF yes, then I did not know that IMS DB calls are segregated / Separate like a Client - Server app.

Now, the IMS DB calls are written in COBOL or any other language like SQL ? because if I ask the COBOL Developer to separate IMS DB calls and show it to me, can he ?


2 - Show this to your cobol developers - they will most likely understand it and explain to you what I mean

3 - Any cobol developer will know what to do and the one that supplied the file has probably done it already, but depending on volumes of data it may be better to do it differently - but this is outside the help I can give here. -How else can we meet ?

4 - to that I ask "Why not?"
possible reasons why
. keep extensive business logic intact
. avoid making same mistakes on code that have already been fixed on cobol
. reuse cobol developers that know the application without the need for a full retraining in another language

Obviously all this is going to be highly dependent on what the application does, how extensive it is in terms of both business logic and volumes of data and how it is processed.

But for me as an Architect it would require that all possibilities are put on the table and then pros and cons analyzed and all alternatives are given so a decision can be taken on the way to go.

And my question here was not to suggest in any way that the decision is wrong - was only to confirm that the client has indeed taken this option in consideration - seen many that were not even aware they could do it.
Yes at an Architect Level, I am contemplating what MIGRATION route to go, as I only have 10 months left

1. Since not much data 500k records, I wask thinking MS Access
2. PHP and any DB
3. OO Java / .NET and any DB


yes the Cobol developer should know what to show you once you give him all my replies to this thread.
IMS calls can be segregated or not - it all depends on what the developer of the application did.

Regarding db to store those 500k record.. DO NOT use MsAccess for data storage - for that volume you can go with Sql Server Express (free) and it will be better than Access.

With such small volume you may also choose one of the other free database vendors - but I can't advise in any as I haven't used any other recently to know they capabilities.

As for interface anything will do so not giving any advice here.
Rankerg
Rankerg
SSChasing Mays
SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)

Group: General Forum Members
Points: 639 Visits: 59
Ok, thanks

1. I will ask Cobol Developer if DB calls are segregated like Client Server app ? But in the Cobol source code, how the DB calls are separated?, perhaps sample code will help Smile

2. My Bad it is 12,000,000 12 million records, Perhaps Oracle is better suited.

3. As far as understanding how the records link to each other, how will it help me ? because want to be careful on bugging Cobol developer ? Smile
frederico_fonseca
frederico_fonseca
SSCertifiable
SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)

Group: General Forum Members
Points: 5224 Visits: 2640
no Oracle isn't better suitable - and SQL Server Express will still hold with that volume. what you need to find out is exactly how many records each table that you need to create will have - and if any single table after you load all records will have more than 10GB.

For the other 2 questions you do need to ask the other developer as there is nothing I can do there as it is application dependent.
Rankerg
Rankerg
SSChasing Mays
SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)

Group: General Forum Members
Points: 639 Visits: 59
Oops I missed your quote "You will also need to consider that it is highly likely that a IMS dataset contains several type of records and that you will need to create a sql table for each type of record."

Yes, I am in verge of DATA Modeling and Cobol guy sent me for 3 MENU screens and the segments each Menu screen is used, so based on segments used I was planning to Datamodel by

1. create SUPERTYPE based on common data and SUBTYPE based on uncommon data
2. Based on your comment, I have to create a SQL TABLE for each type of record in a IMS Dataset ?

However, I am considering this project as a project, where client has given me EXCEL SHEETS and UI Mock screens, build everything from scratch - your comments ? because I cant spend my time learning COBOL or HIERARCHIAL Data model of IMS.

So, any guidance on HOW TO Datamodel an IMS DB to RDBMS will be immense help ?
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (681K reputation)SSC Guru (681K reputation)SSC Guru (681K reputation)SSC Guru (681K reputation)SSC Guru (681K reputation)SSC Guru (681K reputation)SSC Guru (681K reputation)SSC Guru (681K reputation)

Group: General Forum Members
Points: 681315 Visits: 45603
frederico_fonseca (5/3/2016)
no Oracle isn't better suitable - and SQL Server Express will still hold with that volume. what you need to find out is exactly how many records each table that you need to create will have - and if any single table after you load all records will have more than 10GB.

For the other 2 questions you do need to ask the other developer as there is nothing I can do there as it is application dependent.


You can even beat the 10GB limit of Express by using multiple databases and partitioned views.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum








































































































































































SQLServerCentral


Search