× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Srinath,

There are far too many possibilities than can be answered with a simple email.  
The amount of work will depend on thins like how well the model was maintained 
to begin with and the magnitude of the changes that were made manually.

For instance, it might be a good idea to modify the model and then generate the 
code unless your ultimate goal would include  removing the dependency on the 
run-time objects.  Even then, that is dependant on the quality of the model's 
original maintenance.  If the model was built correctly it should be very easy 
to quickly get it into sync with the current files and to get the functions 
rebuilt.

Once you get the files setup the way you want them in the model you don't have 
to generate them since the functions are built based on the model values not 
the live files.

It might help to clean up the unused fields (F7, F11 from database relations).  
If fields were built based on reference fields instead of stand-alone and it 
still matches your current files the field length problems should be easy to 
change.

The ultimate test is to gem them and watch for the fallout.  Once you begin 
that process you could have generation errors or compile errors.  Generation 
errors can be found by searching the source for 'y* e' the messages are usually 
straight forward.

This may seem a bit scattered but the differences between the model and the 
current system is a significant issue.  If you have specific questions about 
what you are doing I would be glad to try to answer them directly (quantity 
within reason).

If you have been keeping up the maintenance I have to question why not just 
switch the model to generate the ILE and continue to maintain it?  It would 
make it a lot easier in the long run.

Bill


----- Original Message -----
From: "Srinath R , Gurgaon" <srinathr@ggn.hcltech.com>
To: <midrange-l@midrange.com>
Sent: Tuesday, October 22, 2002 2:27 PM
Subject: Help - Synon


> Hi,
>
> We are working on shifting the Synon code  to RPGLE.
> There have been numerous changes to the database (PF) like increment/
> decrement of the length of the fields and addition/ deletion of certain
> fields.
> We have a task on hand for which we need to change the external functions
> generated by Synon accordingly.
> By generating the Synon code (Action Diagrams), we are trying to modify the
> RPG programs.
> But we feel that sometimes we are missing or overdoing certain things.
> What we felt was that, if we can modify the PF in Synon (by adding new
> fields or increasing/decreasing the length) and by modifying the Synon code
> accordingly our task should become much simpler and efficient.
> But we have no hands on experience on Synon, we are right now doing some R&D
> and finding out some methods to go about the same.
> Can you please show us a way to go about this. If you can give us some link
> where we could get useful information on the same it will be very helpful.
>
> Please kindly give your comments on the same or any other better approach.
> Thanks and regards.
>
>
> regards
> Srinath




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.