PICS was targeted at small-to-medium sized food distribution and food processing businesses. To provide the ultimate solution for these companies that distribute and/or manufacture food products, PICS needed to address the following business challenges: order cycle times of two hours to two weeks; inventory lot tracking; volatile market costs; complex pricing; credit and pricing controls; JIT purchasing and manufacturing; multiple plant/warehouse/division support; system users ranging from on-the-dock receiving clerks to CFOs; and many other unique food business requirements.
Once we determined the functional requirements, and by using one of the nation's leading seafood distributors as a model, NBS designed PICS with three primary goals: speed, reliability, and flexibility. For speed, PICS uses advanced bandwidth reduction features of the 5250 protocol like PUTOVR and OVRDTA. For reliability, PICS provides automatic session reconnects. For flexibility, PICS incorporates structured, modular programming techniques. NBS also developed a client/server architecture ( yes, even with twinax terminals) and incorporated program-to-program communications throughout PICS.
The 5250 data stream was crucial to the success of PICS. Like all IBM midrange business applications sold during the time, PICS was sold primarily to AS/400 owners using inexpensive twinax terminals. Multiple divisions were supported by remote twinax controllers. PICS was able to provide excellent multi-user response times, even over dial-up connections.
As time went on, PCs became more affordable and Client Access became a bit easier to install and configure, so customers began migrating toward PC-based access to PICS.
On to the Future
Fast forward to the new millennium. Reliable, inexpensive Internet VPN connections have become available that cost considerably less than comparable frame relay configurations. The browser has become the interface of choice for many businesses. However, while the browser may be great for putting up Web pages, it's another matter entirely to deliver industrial-strength business applications via HTML. The thought of this scared the daylights out of us.
NBS was having good success with our 5250-based interface that includes pop-up windows and many other usability features. We had tuned the interface to be as productive as possible for business applications. In fact, despite the mania surrounding Web interfaces, most of our clients are perfectly happy with our reliable, high-speed, colorized, character-based interface, as shown in Figure 1. Installing 5250 emulation software at remote sites has its drawbacks, but not enough to require a move to the browser.
Figure 1: A typical PICS screen, with pop-up windows and colorized text
The final straw came with the pricing of the new iSeries servers. The total price of the interactive "feature" on the 8xx models is often three times the price of the whole box. As NBS will be delivering PICS as an application service provider (ASP) product for many companies, NBS needs pure processing power, which translates to a higher model number. But the cost of the interactive feature would make such a move prohibitive. We needed a solution that would allow us to run PICS programs in batch while still presenting an acceptable user interface.
Our Requirements
Getting our users to accept a new interface is easy--just make sure it works like the old interface! Of course, this means everything from color attributes to command keys to cursor-sensitive pop-up windows.
That wasn't all, though. NBS has spent a long time developing a system designed for throughput. Some of our customers enter over 1,000 multi-line orders a day, by heads-down data entry clerks and salespersons taking orders on the phone. Retraining users who rarely touch a mouse to use a point-and-click interface would be a formidable task. Not only that, we needed an interface that would allow a user to log back in and pick up right where they left off if they lost their session. While this is unusual even in 5250 applications, PICS has provided it from the start, and our customers rely on it.
We needed a product that would be easy to incorporate into our development culture. PICS programmers are experts at using ILE RPG to develop ERP solutions, but they are not HTML gurus. We wanted to find a tool that would be transparent to them: no PC-based tools, no new languages to learn, no new APIs. What we wanted was a 100% automatic conversion, with ongoing maintenance that required no additional programming effort. And under no circumstances did we want to support two different versions of our software just to get the Web interface we desired.
We also realized that our clients will want to extend PICS to their customers, vendors, and remote users. We will probably never need a "pretty" version of the item master maintenance program, but we do want to be able to enhance order entry, order status inquiries, and more as our HTML skills grow.
NBS developed a wish list that we didn't think any product could fully achieve, but which we could use as a basis to compare tools:
Keep the existing functionality of the 5250 interface
- Command keys
- Display attributes
- Pop-up windows
- Cursor field reporting and positioning
- Information data structure (INFDS) support
End-user acceptance
- Generated pages less than 20KB
- Sub-second response time for users on dedicated connections
- Two-second maximum response time for dial-up connections
- Session reconnect using existing 5250 RPG logic
Easy integration
- No HTML knowledge required for RPG programmers
- A simple, fast method for initial conversion
- Easy ongoing deployment from development to production
Performance and functionality
- Converted programs still run normally in 5250 environments
- Browser interface runs in batch
- Can use multiple look-and-feels simultaneously without changing the RPG
- Maintain existing program-to-program communications
Future
- Allow customization of the generated interface
- Make the interface as "standard" as possible (no proprietary HTML)
- Edit the user interface with standard HTML editing tools
- Run with multiple Web servers
What We Found
We quickly found that most tools fell short due to the batch execution requirement. For example, all screen scrapers (including IBM's WebFacing tool) run jobs interactively. The need for an automatically generated 5250-like display also was beyond the capabilities of any products other than true 5250 emulators, but those ran interactively.
A few products claimed the ability to convert RPG software to run in batch, but they all generated a "Web-like" interface that required a point-and-click approach, which simply wouldn't be acceptable to our end-users. Between the lack of function key support and lengthy download times, it became obvious that most of the Web tool developers really didn't understand the requirements of our typical heads-down data entry environments.
Few tools had an automatic generation capability, either. Most required some sort of PC-based GUI development tool, which would completely disrupt our normal development cycle. The CGI RPG options usually required that we heavily modify our existing programs, embedding the HTML code directly into our applications. Once converted, the programs no longer ran in native 5250 mode, which meant we would have to keep two sets of source: one for the 5250 interface, and one for the browser interface. With 1,500+ interactive programs to maintain, we said, "No way!"
It looked like everything available would require a significant retraining of my programmers, my users, or both--and with a significant reduction in performance to boot. The search went on for almost two years.
PSC/400 First Look
Then we looked at PSC/400. As we reviewed PSC/400's feature list, we realized that it met nearly every one of our requirements. The product looked really good on paper.
Pluta Brothers Design (PBD) offered a simple solution to our dilemma. They would come out to our site and do an assessment. They would install the software, get it running with our application, and train our staff, all in just three or four days.
PBD also offered a pilot program, in which they would convert a small library of our software for free and make it available on the Web for review, but after reviewing an online demo of some of their converted screens, we decided to take the plunge and go straight to the assessment.
PBD came to NBS, installed the software, and got the conversion environment going (NBS had previously installed Websphere and performed its basic configuration). Within about an hour, the tool was working and had converted the example programs that come with the PSC/400 Quick Tour documentation. We converted our PICS menu-driver program and immediately saw results.
We had one or two minor issues related to our advanced 5250 techniques. This is one place where PBD really shined. Identification of issues usually took a few minutes, and PBD was quick with a workaround. If defects were uncovered (and only a few were), they were fixed literally overnight.
Next, it was time to convert PICS. PICS has over 1,500 online programs, so we were very interested to see how long this mass conversion would take. The results were pretty astonishing. On our midrange 8xx development server machine, a complete conversion and recompile took approximately five hours. All objects were generated, and everything was ready to run. We were able to immediately access PICS and begin testing the entire application. There was no software that needed to be loaded on any PC, no manual intervention, no HTML knowledge required. We simply converted and ran PICS, as it appears in Figure 2.
Figure 2: The same PICS programs automatically converted by PSC/400 using just a single OS/400 command
Performance
Given the fact that our users are accustomed to highly optimized 5250 screens, we were worried about whether they would accept a browser-based interface. While we knew that PBD had spent a lot of time focusing on designing HTML that would work in a business environment, we still needed to see proof.
We took the show on the road, so to speak, to one of our major clients, and let them pound on the system over a VPN connection. The importance of some of PSC/400's unique features became immediately apparent. The fact that PSC/400 supports all function keys and even the roll keys was crucial. Not only that, unlike any browser application we had seen, PSC/400 allowed users to simply hold down the roll key to page through subfiles. This is something we take for granted in the 5250 interface, but it's highly unusual in a browser interface.
Not only that, response time was sub-second throughout the test. Even with multiple users over a VPN connection, the response time was very acceptable. We were not quite as pleased with the dial-up speed; our first test of a 56Kbps dial-up gave response times of 3-4 seconds. PBD did some tweaking, and we now see speeds of 1-2 seconds. It doesn't compare to a 5250 dial-up session because of the data stream, but we are confident it will be accepted in the field. Besides, what other Web site performs better than that?
Ongoing Development
The final hurdle was going to be ongoing development. Since we are a software company, we couldn't afford to use a tool that would disrupt our development process. NBS has developed a change management system that exactly meets our needs. Radically changing the development process would really hurt any conversion tool's chances of success at NBS.
Because PSC/400's conversion tool is completely OS/400-based, we were able to quickly incorporate PSC/400 object promotion into our own change management system. There were a few PSC/400 enhancements needed, but PBD was willing to work with our staff and make those enhancements in a very timely fashion.
PSC/400's simple design--one panel, one JavaServer Page (JSP)--makes it very easy to perform promotion from one environment to another. We only have to keep track of a couple of objects per program. PBD has a strong focus on ease of use, especially in a real-world development environment.
Summary
We are going live with the PSC/400-converted version of PICS as I write this. It took a total of two man-weeks to completely convert our entire package, and much of this time was spent enhancing the product to make NBS' job easier.
These are the most important points I can relate about PBD and its PSC/400 product:
- The product delivers what it advertises
- Any defects are fixed quickly and competently
- PBD incorporated several enhancements into the product at no charge
- NBS-specific needs were delivered in a timely manner and at a reasonable cost
- NBS is excited about the future Web-based features PSC/400 will provide PICS
As I said earlier, the product looked really good on paper. I can now tell you that it looks even better on our customers' screens.
Kenneth J. Hare is the president of NBS Consultants, Inc., a solution provider to the food service industry. He can be reached at
Pluta Brothers Design, Inc.
47 W. Wilson Street
Palatine, IL 60067
Tel: 847-359-2657
Email:
Web: www.plutabrothers.com
LATEST COMMENTS
MC Press Online