Conference dssdev::application-generator

    Hi there John,
    
    Re your questions:
    
>>>1. Can I import some or all of the existing application into the
>>>   App-Gen repository?
    
     As a general import I would have to say No. There is no way to take a
     Decforms (and I presume Cobol), RDB application and translate it to VB
     UNIX and Oracle. Thats simply the nature of changing from Decforms to
     a PC GUI like VB with associated 3 Gl logic.
    
     HOWEVER What we can do is the following. We can take the existing RDB
     schema and automatically generate an Oracle database script. This can
     then be imported into an ORACLE database based schema.
     (I did this recently..its a pretty uncomplicaated step.
    
       (1) Point AppGen at the RDB database via an ODBC datasource and
           use the "generate database script for ORACLE" option.
    
       (2) Create an Empty ORACLE database 
    
       (3) Run The generated script from step 1 and you will then have
           a loaded Oracle database with Schema as you had for RDB (ie
           Tables/Columns etc etc 
     
       (4) Create a New DATASET from APPGEN (pointing APPGEN at this new
           ORACLE database via an ORACLE ODBC driver)
    
       RESULT : An APPGNEN Oracle based  repository with schema as you had
                for RDB. Plus a Development enviornment with directories
                for VB source, Project files, VB exes etc etc.
    
           YOU are basically ready to start Building/generating your
           application screens 
     
>>>>  2. Can App-Gen generate the new VB, Unix, Oracle application without
         using a TP monitor?
    
         Yes. (TP monitor definitely not needed)
    
         The connection from application to Database would be via ODBC.
         (note we utilize ODBC api as the programming model which is the
         more efficient way of ODBC database access..fast and efficient)
    
         Also you would get the VB application automatically split into
         COM objects  (ie Thin client and Businness COM object(s).
    
>>>      3. When will VB 5.0 support be available?
    
         I use it all the time.. V3.1 offers V5.0 support (its going
         through the release process at the moment).
    
    Let me know if you want more information or a Kit to play around with
    
    rgs
    
    Mick
    
    
    

Mick,

Thanks for your quick reply.  Right now we are in the selling stage with 
the customer.  Oracle is the competition and they are offering their 
designer/developer tool set as the way to migrate the application to 
Oracle/UNIX.

I believe that we can position App Gen against designer/developer by 
stating that

  1. App Gen can salvage as much of the current application as      
     designer/developer, 

  2. App Gen generates more efficient VB code by its use of COM objects and 
     OLE,

  3. VB is a recent add-on to designer/developer, Oracle's focus is 
     SQL*Forms,

  4. Cost of ownership of App Gen is a lot lower.

Are there other advantages that I am missing here?  

Some other questions.  More than likely the customer will want to stay with 
a TP monitor.  

  1. Will App Gen be able to savage some of the ACMS server code (COBOL) if 
     we propose ACMSxp on Unix?  

  2. Any difference if they stay with ACMS/Rdb on VMS?

  3. How about ACMS/Oracle on VMS?

Thanks in advance for your help,
-John
	

John,

Advantages you state are good.. (especially the cost one as there is NO runtime
license)

The automatic split into COM objects is a VERY big advantage...It really is
an ideal solution which would make future maintenance much easier..Also from
an efficiency solution it makes database access faster..

Also the VB code we produce ( ODBC api is the model) is database independent
This means that if they ever want to switch databases sometime in the future
they can simply re direct the ODBC driver to say a SQLSERVER database...without
changing any of the code. 

I mention SQLSERVER as they may thing about MTS/SQLSERVER sometime in the future
We also generate for full MTS/SQLSERVER/VB solutions. (This is becoming a very
"HOT" topic).

Another main advantage is that all code we use is Modifiable..In that you can
modify the code by adding in your own..These modifications are kept intact
when you RE-generate

RE TP monitor.

>Some other questions.  More than likely the customer will want to stay with
>a TP monitor.

Our (favorite) solution is Acmsxp -)

Our solution for UNIX is ACMSXP/COBOL based. As for reusing the COBOL server 
code I would have to say we would have a problem there. We could regenerate it
automatically based on the VB forms. (ie we would build the VB clients and 
the COBOL/ACMSXP code for the UNIX box..Ie the Total solution). As you can 
imagine a combination of a DCOM based split  VB application connecting
with an ACMSXP/COBOL server is a very highly efficient solution. Cost effective
also as it reduces the need for the TP runtime components on the clients.

 
If they stay with RDB/VMS..we will build the ACMS/COBOL and acmsdesktop
based Vb clients for you.

RE: ACMS/Oracle on VMS?. Here I must check for you as Its not a solution we
   have experience in.


I Know what people would like is for us to be able to utilize the existing old
application..But this is not so easy. We have found that from a productivity 
point of view its better to use the tool to generate all the new code. This
can be painful to accept as sometimes there are literally millions of lines of 
actual COBOL/Decforms/Acms code built up over the years. 

What we are offering is a solid development environment which is very flexible
once you initially design it with the tool. from one design you have many solutions
..be it now VMS based..you can move to UNIX/ORACLE...or to a total NT solution
with MTS/SQLSERVER..or indeed ACMSXP/SQLSERVER on NT. 

Something else you may want to consider is a new  ACMSXP solution talking with
the old ACMS one  (i will check that out for you in the interest of been
accurate
    
Let us know if you need any more information

rgs

mick

Mick,

I understand what you're saying.  If you're going to input the information 
into App Gen to generate the VB, why not let it generate the server code as 
well.  Use the existing database design as leverage.  You're not really 
losing any of your current investment.  Now you can maintain the application 
through the tool. That will be more cost effective and allow the greatest 
flexibility in deployment.  

Just have to get the customer over their emotional attachment to all that 
COBOL. :^)

Thanks again,
-John 

    
    Yes we often find that folk with sometimes 100's of thousands of lines
    of code get nervous of throwing it all out. One line to take is around
    the YEAR 2000 issue. We would enusre that the code is fully
    compliant..saving them much expense in investigating and possibly
    correcting possible problems
    
    rgs
    
    mick