The software industry has certainly changed a lot over the years. In the early days software was produced by enthusiasts for enthusiasts; it was delivered on a diskette or two; a manual would be a few pages of typewritten and photocopied notes; and support meant trying to contact the developers by phone or letter.
IBM revolutionised the industry, introducing reliable hardware, professionally produced documentation and proper structures for installation and support.
Still, the software industry was growing so quickly that it could be financed from new licences and new versions. Since customers relied on new versions to fix bugs and add valuable features, they were forced to upgrade frequently. They often suffered due to version incompatibilities, new features to learn and new bugs to avoid.
Times change and the industry is maturing. Software is now a critical part of our lives and our businesses. Customers no longer want to upgrade so often, but they still want to get support if they need it, have problems fixed and progressively get the new features and functions they need.
The industry too is moving towards a different model, one based on enduring relationships, subscriptions, maintenance and incremental updates. We are committed to this trend.
The Powerflex Value Added Reseller (VAR) and Maintenance and Support (MSP) Programmes are our commitment to the long term development of our products and first-class support for our valued customers. The details are explained elsewhere in this issue, and I would encourage all our customers to read it carefully.
We have a host of new features and new products in the wings to release next year. PFXweb is rapidly approaching the point where it is ready for general release. PFXplus Service Pack 3 is about to undergo its final beta testing. We have powerful new features to add to the PFXplus runtime.
In each case, the VAR and MSP programmes are an integral part of our plans for continuing to develop PFXplus and provide support for our valued customers. I would encourage all our customers to familiarise themselves with the programme, and to join up as soon as possible.
The Powerflex Value Added Reseller and Maintenance and Support Programmes are now our principal means of supporting and adding value to all Powerflex customers.
All purchasers of PFXplus development products are eligible to join the Value Added Reseller (VAR) Programme.
By joining the VAR Programme PFXplus developers get the comfort of complete security of their Powerflex licence agreements for both themselves and their customers.
Among the benefits you enjoy as a Powerflex VAR are
Membership of the Maintenance and Support Programme (MSP) is essential for any serious Powerflex developer. Membership is automatic when you join the VAR program, but customers who have purchased Powerflex companion products can also join for those products.
As a member of the MSP you will receive the following valuable benefits.
Members of the VAR programme automatically receive MSP support for PFXplus runtimes along with the corresponding development system. For example, when you register your Windows development system in the Support and Maintenance Programme, then all the Windows runtimes that you have distributed to your customers are also included for support and service packs.
Support is only provided for the registered products on the specified platforms. For example, to receive support for a Linux runtime, a Linux development system must be registered in the Support and Maintenance Programme.
All customers are required to comply with the terms of their licences and with the Deployment Rules which can be viewed here.
All purchasers of new products are automatically entitled to 30 day free installation support. It is recommended to join either the VAR or MSP programme to receive full and continuous support and other benefits.
Access to our popular dev-list remains open to all developers whether or not they have joined the other programs.
If you have any questions or wish to become a VAR or join the MSP then contact us by phone on +61 3 9548 9006 or email at email@example.com.
Technical support is provided to all members of the VAR Programme in accordance with the Maintenance and Support Programme. This means unlimited email/fax support, software updates, service packs and hot fixes for the specified development and runtime platforms for the period covered in the VAR agreement. If you wish to report a problem, please do the following:
PFCN /spfx.ini program
PFLN /spfx.ini program
For the past 18 years I have been working on a system for order entry, invoicing and related routines. Conversion to Windows has become more and more inevitable during the last few years.
There are some 500,000 lines of source code in a central library. 50-100 customers, each one having his own extract, based on 500 available options plus customer specific code. Changes are only made to the central library and a customer's changed program is extracted by a precompiler, essentially a filtering process.
Customers run DOS, Unix and Linux. All code is reusable down to line level and could be shared between options. Because of this, all changes to the source code necessary for the conversion had to be done in the central library, without affecting systems running DOS, Unix or Linux. Normal development had to go on in the same code, even for the system being converted.
To ease the problem I wrote a second precompiler, which takes the source code for DOS produced by the first one, and makes the most obvious changes needed for Windows, so the new source could be compiled with pfcn. What could not be handled this way had to be written in the central library, and assigned to a "win" option.
I read the manual on "Migrating to Windows" a couple of times, and decided to go the CCA way. I looked through some of the examples, but I really had to apply it to a real problem to understand it. I listed possible problem areas that came to mind in random order:
How to deal with key.print, open printer, close printer, selecting subprograms from many alternatives, Yes/No selections, help system, error handling, screen/printer listings, report generator, what to have in a toolbar, should there be a Save button on screens in addition to the toolbar, and a lot more.
So I started writing precompiler 2, and it does much the same work as would otherwise have to be done manually, and without it I would do it in the same order. I start by examining the screens in the source code to build the CCA-definitions, insert "// PROBLEM" at the beginning of all lines containing KEY., CLEARXY, GOTOXY, GET_SCREEN, SET_SCREEN, INKEY, INPUT, KEYCHECK, CLEARSCREEN, SHOW.
I haven't used panels, so I have no problems with those. Selections between subprograms are converted to buttons. Screen/printer selections are converted to radiobuttons and an OK-button is added. Yes/No selections are changed to QueryYesNo statements. Most buttons get value=key.user and action in the key procedure is determined via Ifwindow==button name.
A number of other conversions are made, often based on the rather uniform way the programs are written initially. If a problem could not be solved fairly easy in the precompiler 2, and was likely to occur several times, I tried to write down a manual procedure.
The help system required a different approach. So far I had tried to maintain help screens in the programs, not because someone asked for it, but as a source for documentation. I didn't wish to spend much time on help, as no one has asked for it yet, but in Windows with the ever present ?-button I felt something had to be done.
For that purpose I wrote a program that reads all the source files produced by precompiler 1 and copies the text from the help screens into a text file, with the program names as subheaders. Clicking the help button in a program will then load a program that reads the text file and shows the text related to the calling program.
If the customer wants, he can edit the text file and add his own comments and instructions to the operator, but later I will give him a separate file so I can update without destroying his text. Precompiler 2 removes all the help screens from the source code.
All the precompiling and compiling is handled by a batch file as the first effort to convert a system would typically affect 100-150 programs.
I thought the toughest part would be to make the programs mouse-driven, allowing the user to jump back and forth in the screens. However, I had almost no problem with that. Another problem would be the few larger programs with lots of functions like order entry, but what took most of the time was to apply the possibilities made available by CCA. When you get an idea of what could be done, you can't let it go. Most other programs are file maintenance and listings and they are very much the same.
The report generator was a problem. Many years ago I bought source code for a Dataflex-like program from Powerflex and have done some work on it. I was not looking forward to the conversion of that. My idea was that if a customer wouldn't like to run it in DOS, he could buy Crystal Reports. However, after some months I spent a week on it and got it working.
Apart from these, I didn't think much about expected problems, they would show up anyway.
Finding out whether a word in the samples was a PFXplus keyword, a procedure, a function or a variable. And for a procedure or a function, where it could be found. I still have Norton's text search from the 80's and used it a lot.
Understanding that ccamenu.dat had to be in the customer's filelist.
How to position popups is still a subject to be understood.
Printing, I thought Windows would make it easier. I copied parts of the samples into my programs which did not use procedures. Ended up with a total mess, finally understood some of it, scrapped one week's work and started all over. Put some WINLST and PREVIEW in my old printer routine and the problem was gone.
Much time was spent with PFXDRE to make screens look good, not because each screen takes time, but there are 800-3000 screens in one system. Many of them do not need work, they are either very simple, or just for internal purposes in the program. Adding and deleting screens, keeping DLG files synchronized with the programs caused some headache.
Some questions were sent to Powerflex support and to my surprise were often answered overnight. More than once it turned out that the answer was in the manual or in the samples, I just didn't know where to look.
The total effort spent to get the first customer running was somewhat like what I had anticipated. I think the cost of conversion could be calculated roughly as a price per screen. It is impossible to determine how many hours were spent on the specific customer and how much was of general use. Also most of the time was learning and creating tools.
Considering the programming environment with the precompilers and the rather uniformly written programs I would give the next customer a price for conversion based on maximum 30 screens per hour. Future changes in these programs will still have the possibility to be implemented across operating systems, as the logic mostly remains the same.
Initially I believed that we would convert the programs first to character oriented in PFXplus 5.0, and then change the programs one by one to Windows. Instead, we converted all programs to Windows, but installed them on just two PCs, so the rest of the company ran the old programs using the same database, and if the Windows version would crash, they could continue with the old version. Some changes were made during this period, in both versions. No double work, as they were both extracts from the same source. We had some rather minor errors but there was no crash, and now everyone is using the new version.
The nightmare scenario was that making so many changes in a running system could introduce some error causing everything in the customer file to be lost, or something like that. It didn't happen, and I feel rather confident in further conversions.
This is the second in a series of articles on various aspects of using PFXplus in the Linux environment. It is recommended that the previous article (see POWERlines March 2004 issue) be read in conjunction with this material.
Whilst our previous article dealt with running PFXplus programs on a single stand alone Linux PC, the following material discusses issues of sharing your application with other users . Only character based systems are discussed in detail, although some thought provoking material on GUI is included.
Assuming you have set up a working database and maintenance utilities, there are a number of options for deployment, as follows:
All four methods have their various pros and cons and depending upon the preferences on site, one will usually clearly outweigh the other. For new installations serial terminals have now largely been replaced with networked PCs running emulator software or thin clients, however, as our previous article notes, serial terminals are still around, i.e. the Termtek terminals at Hungry Jack's restaurants. They are becoming expensive relative to thin clients or recycled PCs, so I expect it will only be a matter of time before we see yet another perfectly good piece of technology made redundant by the "need for speed" that seems so prevalent today.
Serial terminals are important to us, however, because regardless of how the thin client or PC/terminal emulator is connected, i.e. serial line or network, it still relies on the serial character drivers in the Linux kernel to do the dirty work of converting the incoming stream of bytes to something the host computer can understand. With PC/terminal emulation this becomes a very complicated problem as emulators have varying degrees of accuracy of keyboard interpretation and screen display emulation. As our previous article notes, one of the issues with a Linux implementation of PFXplus is the accurate display of line drawing characters. With emulators on client machines this problem grows exponentially as you try to pinpoint exactly where the inaccuracy is coming from. The only way to debug it was to decode the hex traffic on the network, an arduous process indeed. Despite this complication we found some good workarounds as discussed below.
After first seeing the Termtek units in action at Hungry Jacks we started trials on this unit. It showed a lot of initial promise with both serial connection and a 10/100 network port which would simplify installation in our existing TCP/IP network and eliminate the need for an expansion card. It was also compact, and whilst not harsh environment proof, it would be easy to house in a protective case and didn't generate much heat. As we got into it in detail, however, the limitations of the device became evident. In VT100 mode it would only display monochrome and any attempt to run extended colour modes were not encouraging. After trying every type of emulation it supported, 8 types in all, with countless experiments with pfx.ini variables and built in bios defaults we finally conceded defeat. The unit just wasn't what we were looking for to reproduce our two colour screen displays - white lettering on blue background with reverse video highlights. For mono applications like display of race results or train times they would be ideal. Cursor control was another issue and after several rehashes of the terminfo file we concluded it was not supported as well as the documentation suggested.
Just about every office and most homes these days have a few old Pentium166s or similar lying about. Ours was no different so we started to tinker with the idea of using some sort of terminal emulation software running on these Win98 machines. I was against this in principle from the outset. Win98 is inherently unstable and these machines were going to need ongoing maintenance just to keep them working. In addition, the hardware was ageing and not reliable enough for a demanding factory environment. We persevered with this approach thinking it would be pretty neat to have some type of multimedia demos available to our factory staff to go with their newly deployed on-line recipe database, so a GUI interface with some serious local processing power had a lot of appeal. The idea was to get a really good emulation working and then build some new Win98 based PCs to a harsh environment standard.
Emulation over a network relies on an age old network protocol from the Unix world called "Telnet". This is a communication protocol designed for displaying a login prompt/password screen to a remotely networked computer. It is strictly character based and once connected Telnet transports the keyboard/screen data back and forth between the host and the remote machine. No actual processing takes place on the remote machine other than screen and keyboard character handling via the network port, so it imposes only minimal load on the client machine and only a very small network load - just keystroke characters and an 80x24 character cell screen refresh. If your server has plenty of grunt, the screen refreshes are really fast! Win98 has a Telnet program, although it gives such poor emulation of the terminals it represents that you wouldn't use it for a serious application. It is handy for testing a Telnet link, though. I had previously deployed emulations on PCs connected to Linux using Console Telnet, a freeware program available from the Internet. For reasons which I never got to the bottom of, I couldn't get rid of a small bug which caused corruption of the last two columns of the 80 column display only on our site. I had never experienced this bug before and concluded it may have had something to do with the various versions of Telnet and Linux. I once again conceded defeat but undeterred the search began for a better emulator.
After trialing fourteen programs including commercial releases, shareware and freeware, we finally found what we were looking for - Eric's Telnet 98. This is an outstanding piece of Windows shareware available from www.Telnet98.com. It supports full character and keyboard re-mapping and has some default re-map sets including one called "Linux". Once set to a terminal of type "Linux", our emulation problems were over. We still use this emulator in the office because it is convenient to just hot-key over to a Telnet session to access the database and then jump back into the Windows world of word processing and spread-sheeting. No doubt you have seen emulators running on PCs connected to some variant of Unix in the past.
A note about security: In order to get the emulation working over Telnet you have to relax security policies on the server. For this reason Telnet should only be used in a friendly subnet and never over dial-up or Internet connections. Telnet passes login and password characters as clear text and it is very easy to pick them up with a network sniffer. Other Telnet variants using encryption, such as ssh - the "secure shell", are better able to deal with security issues than the original Telnet. We are not too bothered with this in our friendly subnet. If you are having trouble logging into a server running Red Hat 7.1 or later, it may be due to the default setting in the /etc/xinetd.d/Telnet config file which disables Telnet as a security measure. Just change the disable = yes line to no and it will work fine. Other than that, it needs no additional configuration other than the default multi-user network installation. If you can ping a Linux host from a Win98 machine, you should be able to log in using a valid username/password pair. Telnet is one of those things which just seems to work.
About the time we got the Win98 emulation running properly we started to tinker with bootable network cards. I was interested in reducing the cost of the client machines and removing the primary source of failure, the hard drive. A network boot seemed ideal but that would mean the machine would have to boot as Linux and run in full screen Telnet character mode. So much for our multimedia sessions for the factory, but that was a trade-off we were prepared to make in order to see some progress with the project. Our first attempts were using PCs with 3Com bootable cards. During these tests I found out about PXE or the "pre-boot execution environment". This was too good to be true, someone had already done all the hard work! The last time I visited bootable network cards I had to burn my own roms and it was a very arcane process.
Your average thin client these days has an "embedded" operating system like Windows CE or even Linux, but PXE boot uses a different process whereby the operating system comes from the host in its entirety. Once the self check is over, it hands control to the boot rom and loads all of the operating system over the network. This has a lot of advantages, including ease of maintenance and centralization of the configuration. In order to use PXE bootable clients with Linux there are three components which must be functioning correctly on the host, as follows:
In summary, the PXE boot process goes something like this:
It is very fast, needs no moving disk drives and looks great on the screen. Even better, there are no emulation issues because it is Linux talking to Linux via Telnet. Whatever you see at the host you can exactly duplicate at the remote terminal. Having gotten a couple of these to work as PCs using network cards we went looking for better hardware and soon found it. The VIA EPIA 5000-ML is the best bit of hardware I have seen in years, and cool too with a fanless 500Mhz processor. It has features far too numerous to list here, but let's say for a mini-ITX form factor it is impressive. And the cost? At $155.00 for a mainboard and processor it was cheaper than using second hand PCs so we deployed one of these in our factory straight away using the on-board PXE boot.
We have had problems due to dust ingress from the power supply fan and this is what we are working on now, a fanless, ruggedised thin client with a fanless power supply. Eventually, I want to build a wash down version using a harsh environment keyboard. In the meantime our chefs just wrapped the keyboard in glad wrap to keep the dust out! It worked surprisingly well and now they no longer use recipe books in the kitchen. Our system has improved our product costing, reduced batch variations and centralised control of recipe versions. The users tell me the best feature we included was a little recalculation routine in a pop-up window which allows them to scale the quantities of ingredients up or down based on the finished quantity of items to be made. It required about fifty lines of code and has eliminated the use of calculators in the kitchen.
Our next development will be to connect this system to a weigh scale and do real time batch logging for our food safety records. The plan is to interface the PFXplus application to a C program and communicate over an RS-485 multi-drop network which will include the weigh scale. We already log temperatures in our cold rooms directly to text files on our Linux server using addressable thermocouple amplifiers on a similar network. The serial port C-coding was a bit hairy, but it now works really well and saves us lots of paper based manual recording. I would very much like to extend our PFXplus application to include these records in the future.
For more information on getting PXE boot to hum check out the Linux Terminal Server Project at www.ltsp.org where there is extensive documentation. Be sure to research the three elements of NFS, DHCP and TFTP in advance and have these working before you start ... you will save yourself lots of headaches. These are well documented separately and need to be installed and tested individually. It takes a bit of setting up, but when you finally see your database application magically appear on a remote diskless Linux machine with no moving parts it is truly remarkable!
This is a world of its own. The most popular windowing system for Unix is the X Window System or X for short. So called "display managers", such as Gnome or KDE, run on top of X, but it is the X system which causes the windows to open and close on the remote machines. The RedHat distribution includes X11, Gnome and KDE, and it is a matter of preference which display manager you use. My prototype starts using Gnome and has all the KDE menus available, but ultimately we will probably use neither and generate the windows from our own scripts directly via X, but that is a little way off yet.
If you have a diskless client booting to run-level 4 (character mode) and correctly displaying a Telnet session, then the next step involves setting up the X startup parameters and calling the display manager. The major thing to watch when booting to runlevel 5 (full graphical mode) is that the X server settings are correct for the monitor connected to the workstation. Avoid the temptation to use that old monitor from the dead PC in the corner. Use a mainstream brand monitor that you have a manual for or can get the data on horizontal and vertical sync frequencies. This cannot be overstated. There are so many different combinations possible if you try the hit and miss approach that you will either fry the monitor (no, I am not kidding) or it will just look weird. Worst is when nothing happens at all and you cannot see which way to head next. I have given up using recycled PC monitors on anything attached to Linux, they are simply not worth the trouble.
Once the GUI is running you can open a terminal screen and access the character mode database application in a terminal window. For the time being that is about all I can hope for as PFXplus does not support the X windowing environment, however we have come up with some novel approaches to this dilemma. The latest version of the LTSP, Linux Terminal Server Project, allows a workstation to boot to different run levels in different virtual consoles. For those unfamiliar with the Linux console, you open new virtual consoles as if you were using a totally separate terminal, using Alt-F1, Alt-F2, etc. Until recently, the LTSP would support either runlevel 4 (character) or 5 (GUI), but once booted, all virtual terminals had to run the same runlevel.
Since version 4.0 it is possible to have a full-screen character application running in one console (e.g.. our recipe database) and hotkey over to a full GUI screen in another (e.g.. to display a photo of the product to be made, or a short multimedia demonstrating the production process). A current project is to have a real time graph displaying our temperature logs in GUI after five minutes of keyboard inactivity, like a screen saver. There is a great program called gnuplot which I am trialing for this purpose. Eventually, I want to log and display everything in the place, including oven cooking temperatures.
One suggestion has been to issue each staff member with an RFID (radio frequency identification) wristband and put a receiver next to the terminal. With a wave of the arm (no cross contamination from one operator to the next via a keyboard) a new virtual console will appear, allowing several users to simultaneously access different recipes via the one terminal. This will be fairly easily done using a purpose coded PIC chip to decode the incoming RFID and output a character stream on the keyboard lines to emulate the Alt F2 keypress.
Ultimately the success or failure of any system is defined by the users' willingness to adopt it into their daily work roles. A good database is a good start, getting people to use it is an excellent finish! You should see the look on a new chef's face when they realise "our recipes are on a what - a computer?". But they get used to it on the first day. Our real objective is to give our staff tools which help them work more effectively. If the combination of a good operating system like Linux, an efficient database like PFXplus and a few well placed intuitive leaps to tie the bits together give us that result, then we have won this round of the game and get to play again.
The Linux world is full of surprises and a huge amount of functionality is available in exchange for a few hours of your time to learn some new systems. The dollar cost is almost nil and as illustrated above, once familiar with the virtues and limitations of the various components it is possible to build highly integrated and functional systems from common PCs and software downloaded from the Internet.
And reliability? In six years of using Linux in all sorts of applications I have yet to see it crash. Our best uptime record was five and a half months without a reboot and that shutdown was scheduled to replace a failing cooling fan. I have yet to see another operating system match Linux for stability.
If you need pointers to further information or wish to know more about any aspect of our projects, please email me on firstname.lastname@example.org .
PFXsort is well known for its speed when reindexing. Did you know that you can reindex every file in the filelist even faster if you execute reindexing with multiple workstations? To do that is really quite simple.
PFXSORTT /allThis workstation will become a master. It reads all the files in the filelist, selects the largest and starts reindexing.
PFXSORTT /allEach additional workstation will start reindexing the next largest file, and all will continue until there are no more files left.
PFXSORTT /all stop
PFXSORTT /allto continue or
PFXSORTT /all newto start again from the first file.
2004 has been a busy year for everyone at Powerflex. From moving offices, new product development, implementation of the VAR Programme and an ever increasing number of Dataflex developers converting their character based applications to Windows using PFXplus, we have been kept on our toes.
For those developers who are still running their PFXplus or Dataflex applications in character mode, we have included a brochure detailing how easy it is to convert to Windows with PFXplus version 5.0. We recommend you read it carefully and take up our offer for a free no-obligation evaluation of your current application.
In mid-2004 Powerflex moved to new offices and in case you haven't had a chance to catch up with our new details, they are
Powerflex Corporation Pty Ltd
Suite D1, 758 Blackburn Road
Clayton VIC 3168
PO Box 624
Mount Waverley VIC 3149
Tel +61 3 9548-9006 Fax +61 3 9548-9003
The latest beta version of PFXplus for the Web is being tested by an increasing number of PFXplus developers. Their feedback has proved invaluable in the development of this innovative product and the final production release date is drawing ever closer. PFXplus developers who are interested in joining the beta testing programme should contact us at the telephone number or email above.
Service Pack 3 for PFXplus (Developer and End User Runtimes) version 5.0 is currently in beta testing. It contains fixes and enhancements to the compiler, runtime, toolbox, debugger and samples. Some of the more interesting features include support for wide screens, flat toolbar and support for case insensitive indexes on Btrieve files.
If you are a PFXplus version 5.0 developer, and are interested in beta testing the latest service pack then please contact us on the telephone number or email above.
The new version of PFXcrystal to support Crystal Reports versions 9 and 10 is currently in beta testing. If you wish to join this programme and own a PFXcrystal version 5.0 licence then please contact us on the telephone number or email above.
|PFXplus Developer's Kit 32-bit for Windows/Btrieve/SQL incl SP2||5.0|
|PFXplus Runtimes 32-bit for Windows/Btrieve/SQL incl SP2||5.0|
|PFXplus for UnixWare incl SP2||5.0|
|PFXplus for Open Unix||5.0|
|PFXplus for AIX incl. SP2||5.0|
|PFXplus for SCO Unix||5.0|
|PFXplus for Linux||5.0|
|PFX C-lib 32 bit for Windows/SQL incl SP2||5.0|
|PFX C-lib for Linux||4.41|
|PFX C-lib for SCO Unix||4.41|
|PFXsort for 32 bit Windows/SQL incl SP2||5.0|
|PFXsort for UnixWare||5.0|
|PFXsort for SCO Unix||4.41|
|PFXsort for Linux||4.41|
|PFXbrowse 32-bit Windows/Btrieve/SQL Developer version incl SP2||5.0|
|PFXbrowse 32-bit Windows/Btrieve/SQL End-user version incl SP2||5.0|
|PFXbrowse Developer for Linux||4.41|
|PFXbrowse Developer for SCO Unix||2.10|
|PFXodbc 32-bit for Windows||5.0|
|PFXcrystal 32-bit for Windows||5.0|
|PFXplus HTML Help||5.0|