We wrote last week about how our product modernization efforts (putting a php GUI in front of our products) was stuck due to the php i5_connect function not being persistent. Well it looks like there is hope on the horizon. We noticed a post on the Zend Forums about a similar requirement for performance enhancement, they simply noticed the i5_connect function was taking sometime to complete and wanted a way of allowing the connection to be reused and not have to initialize it everytime. Aura support had mentioned there is a solution in version 3.0.0.7 of the EasyCom extension, I checked the version shipped with the latest ZendCore and its 3.0.0.5. I have spoken with Zend about how to install the newer extension (they didnt even know these guys had a persistent connection available originally?) and they have promised to check out just how viable it is to download and install a new extension to the ZendCore. As soon as they give us an answer we will post it here…
It looks like there are a number of new functions available as well? The biggest problem I have found with the i5_* functions is the lack of documentation and suitable examples on how to use them. I have been using php for sometime yet still find the function documentation lacking in detail and suitability. Again I have requested Zend get more adequate documentation out there, otherwise people will stop looking at php as a viable solution to their application modernization requirements. If you feel the same as I do I would suggest you send a note to Zend Support stating just how the documentation content is affecting your way forward with php… Perhaps we are just so used to having the IBM manuals to work with and the php documentation isnt anywhere near that detailed?
I would also suggest you start to look at the Zend Forums regularly to see what others are encountering on their php projects, it could help you understand what difficulties if any you could encounter. One particular problem is that of record locking by php not being recognized by other i5 language implementations. This means your php lock could be ignored if another application running natively on the system locks and updates the same record. I am trying to understand exactly why this is occurring and having read through the post it seems IBM doesnt want to fix the problem?
We are still intending to publish the phpMyAdmin install instructions next but other things just seem to get in the way… We are also looking at creating a LAMP install for i5 which would create a disk image (CD iso image) that could be downloaded and run to create a basic php website install. If you are interested in helping on this we would appreciate you help…
Chris…