Automatic generation of ADS Procedures and COBOL Table Procedures

[Margaret Sliming]

Do any of you work for companies that would be interested in keeping the mainframe and converting dialogs to procedures that can be called by any web language?  If so, can I get access to an IDMS dictionary and a dialog that I can use for a proof of concept?   The conversion programs should just need the dialog name and maybe a few parameters.  I'm still in feasibility mode but access to the dictionary would guaranty success.  I only need read access.  Instead of requiring a web program to call the procedure, we can use OCF to verify results.  

The business code isn't touched other than things like checking a code passed from the web program to the procedure to perform actions such as ADD, CHANGE and DELETE.  Response Processes become mapless dialogs.  Because we can't use PFKeys, the web program has to tell the procedure what to do.

Of course, someone would have to create the web screen and program to call the IDMS procedures, which are just like called modules.  They are like any other relational data source.

Thanks,  Maggie

[Chalce Dony Herbertson Santhosha Rajan]

Hi Maggie, I have done something similar - expose the ADS dialog process as procedure - this enables the web application (in our case, .net application passing the data to IDMS through an SQL Query) to use the ADS processes as backed to store the data, while allowing users (who prefer) to use the Mainframe Black and Green screens.

unfortunately, I will not be able to give you access to the code or the dictionary. But i would be happy to walk you through the process and guide you trough the PoC.

Kind regards,

Dony

[Margaret Sliming]

I have been looking at the ADS procedures created from dialogs and they should be relatively straight forward to automate.  The first step is to create the ADS Procedure result set definition from the ADS map record.  The Procedure definition must be in relational format.  This is the data that gets passed between the web and the ADS Procedure.  When the ADS procedure is initiated, the data is copied from the Procedure definition to what were the Map record fields. Before the procedure is exited, the fields are moved from the ‘map’ record back to the procedure fields.  The biggest change to the dialog code is replacing ‘Modify Map’ commands with setting indicators that will notify the web programmer how to display the field on the web screen.  The conversion software will be COBOL and it will run against IDD on the mainframe.  With Broadcom’s tool to create a web screen from a map, I can use the same naming conventions in the dialog code so the tools work together.  I need a beta site. Any IDMS installation that can provide me with a work environment can have the software for free.  I can create a working example within a month or two providing I’m not battling security issues.  I just need a sample dialog, read access to the dictionary and help from a web programmer.  I’m starting with ADS procedures but I am going to do Table Procedures (multiple rows of data) next.  
How it will work is dialog names will be fed into a program that will get all of its associated information from the dictionary.  The program will create the procedure definition from the map record, so the field names will be the same except for the prefix.  Code will be appended to the existing dialog to populate the map record from the procedure definition and vice versa.  The Modify Map commands will also be replaced.  This method of accessing information in real time is more efficient than ADSO because it doesn’t have the overhead.  This also increases the performance of batch cycles because batch programs are not competing with dialogs for resources.  

[John Abell]

We have a different approach to this that requires no application code conversion.  If this is of interest to you, please contact me directly at [e-mail].