MVSFORUMS.com

[mfjin]

This question has apparently been asked in an interview

You are about to create a database to store data. What are the factors you would consider to decide whether to create the db in ims db or in a db2 table?

i thought of this and th only thing that came to my mind is if the db shall have a lot of online txns against it, it would make better sense to go for a db2 table...as sql is fairly easier to use to access data in a db2 table than ims-dc .(i know this sounds too daft a thing to answer in an interview)

Can any of you throw some light on this?

[kolusu]

mfjin,

The Main advantage of storing the data in a DB2 table is that

1. It supports Adhoc queries,
2. You can access the data using standard SQL (instead of non-standard DL/1)
3. Maintanence of the data is easier as you can find people to support the DB2 Environment.(there are more DB2 folks out there than IMS folks now-a-days).

on the flip side DB2 will consume more CPU than IMS. DB2 optimizes queries internally whereas IMS programs construct access paths to data. This additional requirement will cause DB2 to consume more CPU.

Hope this helps...

Cheers

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

[mfjin]

Kolusu,
Does the quantity of data in any way determine the type of database to be designed??

[kolusu]

mfjin,

[digitalnirmal]

what about security?
i heard ppl are shifting to IMS cause it is more secure???

[Bithead]

I would think that DB2 is more secure than IMS as it allows for column level security where IMS secures down to the segment.

Additionally, IMS is faster than DB2 because DB2 uses MVS supplied I/O routines where IMS uses a lot of its own. This does, however, make it less adaptive to new features of the OS.

[Manas Biswal]

mfjin,

A major factor that I would consider in favour of DB2 whenever designing a new database is its compatibility with other open systems and interfaces.
A v7 DB2 installation (thats the one I have worked in) supports a wide variety of interfaces with other databases and systems. Apart from the obvious advantage of it being relational and thus ensuring that all standard SQL procedures and routines are portable across systems and technologies, it also supports live replication using DB2 data propagator or Sybase Rep server from a number of different databases.
No offense to any die-hard IMS fans, but that DBMS is simply not scalable to the demands of today's systems.
And as far as performance is concerned, my personal opinion is that almost all performance bottlenecks are caused due to improper coded applications and poorly tuned database configuration parameters.
A well tuned DB2 database with an optimum application running on it is as good as any other DBMS in the market today.
Just my 2 cents worth.

Regards,
Manas
_________________
There is no path to peace. Peace is the path.
- Mahatma Gandhi (1869-1948)

[Bithead]

I support both IMS and DB2 databases so I try not to be biased. Both IMS and DB2 are accessible from non-mainframe platforms so I would not call that an issue.
IMS also supports live replication using data propagator.

Each database is better than the other depending on the type of processing. For heirarchically sequential processing, IMS probably beats DB2. For non-keyed and ad-hoc processing, such as data mining, DB2 is better.

It all depends on how you intend to use the information that determines which database to use.

[MikeBaker]

IMS secures down to field level (ie: column) through the use of the SENFLD statement.

IMS V9 allows Java to use SQL in order to access the IMS databases.

Way back in the early 1990s, IBM stated that "IMS Fastpath" processed 4000 transactions per second. One would assume that this has since improved.

95% of the Fortune 1000 companies use IMS.

As Bithead says, "It depends on how..."

Lastly, one other thing I have noticed (an aside). Lots of people feel comfortable in playing around with DB2, but they don't feel nearly so happy to tinker with IMS. So in a shop where the security is less than perfect (too many unfortunately), you are much more likely to have a non-DBA person stuffing up the DB2 environment, than you are with IMS.

[kolusu]

Here is an excellent article which discusses about Hierarchical versus Relational Databases

http://www.dbazine.com/ofinterest/oi-articles/ims1#databases

Hope this helps...

Cheers

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

[Manas Biswal]

Bithead,

[MikeBaker]

Oracle/Solaris can write to an MQ, therefore it is accessible, or write your own Socket program. I'm not sure what you mean when you say "not scalable", but with HALDB you can (effectively) make your IMS databases as large as you want. And in the IMS book published last year, it says, "IMS can process 21,000 transactions per second (over 1 billion per day) using IMS data sharing and shared queues. A single IMS has processed over 6000 transactions per second over a single TCP/IP connection." Whatever the capabilities of IMS Connect, one thing is certain - IBM is enhancing this product all the time.

Considering the huge investment that IBM has in IMS, and the fact that over 95% of the Fortune 1000 companies rely on IMS for their business critical applications, I would imagine that if the customers need something "extra" from IMS, then IBM will be only too glad to comply.

There is very little that cannot be achieved technologically. However, often the reasons why certain things are not done, is because (1) there is a management agenda specifically NOT to do it, (2) the IT staff say "its not possible", without realising that down the road (in another shop), it has already been achieved.

Just as aside on this, here's an amusing anecdote about one guy I will never forget. When I was a trainee programmer, I once asked one of the local gurus, "What are you? Would you call yourself an Assembler programmer, a COBOL programmer, a C programmer or what?" This guy had a shocked look on his face as if he had just been insulted, and said, "I am a Programmer!!, and I code in WHATEVER language is most suitable for the task." And indeed, that is exactly what this fellow did. On one occasion he even wrote his own mainframe I/O routines for a disk (bloody tricky stuff). This means he didn't use the Assembler GET, READ, WRITE, PUT macros. When asked why on earth he needed to do this, his answer (spoken with disdain) was that the IBM supplied routines were "just simply too slow!!" In certain situations every milli-second can be critical. This type of attitude is an absolute world away from the one which is so predominant today, where these days if you ask someone what they are, they will say, "I am a COBOL CICS DB2 programmer" or "I am an Easytrieve programmer", and thus they set limits on themselves, as does management (ie: "He's only a DB2 Programmer."). Virtually ANYTHING can be done, but whether or not the local in-house IT team is capable of making it happen, is a whole 'nother story.

The DBAs in our company all work/have worked with multiple databases. We have Sybase, IMS, IDMS, DB2, Oracle, and SQL Server. Our most experienced DBAs all basically refer to SQL Server as a "toy database" because it is so easy to administer. However, I would not let this guide me in choosing a new database for a company, simply because its alot easier for programmers to play with (ie: a toy database), rather than a more complex database (ie: IMS) which requires a specialist to administer it. However, I do symphatize with what you're saying about feeling comfortable in using a database, because it certainly can help the company in many ways.

[astro]

Hi Kollusu,
I have seen your link: http://www.dbazine.com/ofinterest/oi-articles/ims1#databases

Do you know such links that deals with Network & RDBMS models?
Or a high level information on on network model will do.

Thanks
astro