I've often wanted to do systems integration work on Point of Sale (POS) systems and I've finally been given a chance on a short term project. A common POS system used by a bistro chain needs to be wired for a third-party program and, since the system is Progress-based, I was chosen to do the work.
So far there have been a number of challenges appear, but nothing entirely prohibitive. The POS uses Progress's cheapest product available, Personal Database, which is the bare-bones Progress run-time engine. This product alone doesn't allow compilation of normal Progress 4GL code, a development license is required to do that. I don't have a version 9 license, but fortunately there is a "trick" which I'll explain.
You can use a Run-time version of the prowin32.exe executable to compile code encrypted using Progress's source encryption program. This program is not probably not going to be included in a Progress Personal Database install, so you are going to have to find it somewhere else. I have it as a holder of a Progress OpenEdge OE Studio 10.0A license, so that's how I get stuff to compile. The logic hasn't changed between versions 9 and 10 and has never been altered since its inception as far as I know.
This is 100% legal in terms of Progress licensing and has been used as a backdoor for developers since I learned it back in 1994 using Progress RDBMS Version 6. It even works across platforms, and a file encrypted on a Windows PC will compile on an AIX, Linux or other Unix system with a run-time version of the Progress executable (_progres). Just remember that wherever you encrypt your code, the ensuing file is binary so you don't want to use ASCII mode when transferring it using FTP. That's usually trouble-shooting tip #1 in my experience when the code won't compile.
If you would like to know more about how to accomplish POS system integration with Progress when source is not available, please contact us for a quote. We can handle all your Progress DBA and Progress Programming needs.
Post a Comment