Overview of MIMS for a seasoned DB2/CICS A/P

[intentionspace]

I am a freelancer [Contractor] with years of CICS/DB2/IBM mainframe application development experience. Now I am in a position to support some MIMS programs developers. Unfortunately I lack a generic but concise view of MIMS. Although possibly I may be able to articulate the form of such a generic concise description can possibly take. That is what I shall do below, I shall appreciate if any one, with better MIMS development experience than me, can correct me where I go wrong or fill up the Gaps in this articulation.:
MIMS is an pre generated cluster of application based on some entities called files. These files are very much application specific [e.g. purchasing], however there are some files that belong to functions for system which goes accross the application that is invoked repeatedly in multiple application areas.E.g facilty to submit jobs to produce a report, facilty to inquire on jobs waiting, facilty to set up screen dialogues for categories of function e.g. to list outstanding purchase orders,or unpaid invoice etc.
The files and their functions are listed below:
Sytem:
{ Fule name MSFxxxx is used to do xxxxxxxxxxxxxxx {can some one complete this list or point to some place where I can find this list? }
Application Specific:
Application: xxxxxxxxxxx
File name MSFxxxx is used to do xxxxxxxxxxxxxxx}{Similarly,can some one complete this list or point to some place where I can find this list? }
..
By the nature of the way "Files" are used in MIMS , they are a combination of data elements e.g. inventory item number, quantity etc and other elements which dictate ongoing action to be taken as the application flows; e.g where as in a traditional application one will write code togenerate a purhase order and add an invoice in a data base tables along with a function [program code ] to match invoice and purchase orders, the Mincom file system does provide a place to store the invoice as well as some codified entities which can link a purchase order with the invoice so that the linking becomes a bit transparent and looks like a flow from one screen to the other to the end user; the benifit of this is the analyst do not have to go through the application specific data normalisation task of data analysis - that has been done by the application specialist at Mincom -similarly no programmer is needed to write the linking function.
Thus the File View of MIMS can sit on top of what ever data base the client may happen to have like DB2, Oracle etc. To add any additional functionality one should have the File-view of the application.
Can some one please correct me on the above and fill in the gaps so that I can expose my further thoughts in the similar fashion. Hopefully it will benifit not only me but others who come with loads of application development / use experiences without MIMS in their blood line.

 

[Calator]

HI
and Welcome to the happy MIMS support team
I must say I did not like your expose AT ALL, I found the language difficult, inappropriate, and it does not convey at all the concept of MIMS or what MIMS is. Unfortunately I cannot do it for you. What I'ld like to suggest is:
- check this forum or the Ellipse forum, I think I saw a similar question "What is MIMS" where people gave some good short description
- check Mincom's web site, you'll find a description of the products
- check MIMS user refernce manuals that Mincom supplies with the purchase of the software
- for a full database model check the "data dictionary" supplied with MIMS, there are hundreds of tables ("files&quot you cannot possibly list them all.

Good Luck!

 

[intentionspace]

Hi, yes it is unfortunate we do not understand each other.
Probably we are used to see an application differently -from different points of view.. Looks like I have to dig further - I have browsed the documents you mentioned for version 3 on mainframe [although I must admit I have not seen the dictionary yet]. I guess I am more interested in an architecture of MIMS which remains valid accross different applications .
As you said there are hundreds of tables: that is precisely the point - the architecture should be able to categorise the tables in a handful of types each type with certain roles.

 

[gbell]

As Calator said, your starting point should be the documentation which comes with MIMS. Amongst this doco you will find a html version of the data dictionary and perhaps what you are more interested in, entity relationship diagrams for the various modules such as purchasing, work orders, accounts payable, general ledger etc.