Excellent Thanks Rob!! This is exactly I was looking for.
Only drawback that we have is, we don't have the solution for progress version prior to 11.6.
Regards
Thanks Saravana for simple test case.
@Tom Instead changing individual programs for compile purpose, is there a way to change the progress assumption of 80 width screen for a batch mode?
Regards
Yes, I'm emphasizing on the batch compile for automation effort.
Unfortunately I have not been able to find the solution yet. I had exported TERM to vt100 and still didn't resolve the issue.
Regards
Application that I work on is old and the thousands of programs already have the static frames. For the tool need of compiling the programs in the background it doesn't make sense to change the application programs.
Is there are any other way in a batch session, we can compile the bunch...
Agree that static objects will be resolved at compile time. From the perspective of Frames and display does it makes more sense to resolve at run time?
What if I compile a program in a non batch mode and use that .r to run in a batch mode. Vice versa is my scenario .
When I compile a screen program in client session started by mpro. It works fine.
Where as if I compile from _progres -b or mbpro session it gives a warning and doesn't create .r.
** Warning: Cannot fit FILL-IN Applicant with AT within FRAME F1. (4027)
Warning: Ignoring position info for AT...
Giving the sql statement in the file(myscript.sql) works. The reason I was trying to make this in the command line statement is to keep the complete sqlexp statement in a script and to give the user id as an argument to the script(.bat/shell).Any ideas?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.