In keeping with the theme of the cover story this month, I thought I would tell you the tale of when we switched our document management solutions. Initially, we had been running a package from Optio. It was a reasonably basic package that had been in place for quite a few years, it was native to the iSeries and at the time was seen to be the best solution.

There was a way of using a GUI-based designer to create our output but since we didn’t really do much designing at the time, we tended to use the green screen designer. This was nothing more than a text editor, set up to allow us to create lines by defining start positions and lengths and to insert variables from a spooled file into the finished design. The application then put the two together and produced a finished document. The system was initially used for our purchase orders, which were then printed off an AS/400 (as it was still known at the time) printer and faxed to our factories in the Far East.

My initial introduction to Optio came when we were upgrading our main iSeries and we had to go about finding out what was going to be involved in upgrading our Optio licence. Because the application was native to the iSeries, every time we upgraded (anything from 18 months to three years) we had to buy a new licence and sort out the new codes to apply. Normally, this would have been pretty straightforward but the company had decided to close its UK-based support office, and all calls had to be made to America.

At the time, we were also in the middle of a project, building a new system to replace an existing paper-based Goods In solution. This required some nifty new designs to be made for the paperwork and trying to do them in Optio took some effort as all the documentation was way out of date and there were no tutorials. So we had a look around and the IT manager came up with a solution.

SolutionX, as we shall call it, was a print and output management solution that allowed you to create templates. The templates were created by taking a spooled file from an output queue and by the power of TCP/IP and some Visual Basic it was then presented on a PC in simple text format. The design tool then presented you with three screens showing your raw data (the spooled file) and which allowed you to create fields containing the data which you could then position on another screen. This second screen was your template which was identified by a unique ID. The unique ID was passed as a piece of text within your spooled file and was used to identify the template that would be used to display the data.

The design tool also allowed you to create other fields and shapes which, in turn, could be used to build tables, graphs, barcodes, perform substitution of text for images (which could then be used to insert pre-scanned signatures at the end of letters or purchase orders), and there was even a scripting language to allow you to specify (for example) the shading on a table for different rows.

All in all, it was quite a clever little tool and added to this designer was the server which you could configure for different users and printers. There was an archiving facility, cheque printing facility, fax capability and even a way to automatically email PDF files from the server. So with all these capabilities, we thought we’d give it a try. The man from SolutionX (let’s call him Steve) duly arrived and set about telling us all the wonderful things that SolutionX could do, none of which were really what we wanted it for. We had no real need for cheque printing, no need for archiving document, and definitely no need for any fax capabilities. But no matter how hard we tried to tell him that we were moving away from faxing our purchase orders, he still pushed the fax solutions. It was almost as if he was on commission from an unnamed fax software manufacturer. We even decided to count the number of times he mentioned it in one visit and, from memory, I think he said it 41 times on the day he came to deliver our training.

However, I digress. Mr Fax or, rather, Steve, was a really nice guy who just happened to end up selling and supporting a product that was still in the early iterations of development. A lot of the bugs hadn’t been ironed out of the application and we happened to chance on several of them. As I said before, we were looking at SolutionX primarily as a development solution to allow us to move our document design system away from the iSeries and onto a PC server, and that wouldn’t end up costing us a fortune every time we upgraded our iSeries. We also wanted something that was readily supported and wouldn’t have to be farmed out to the USA whenever we had a problem. 

What we didn’t realise, though, was that the way we had configured our sites was going to cause problems with our document management system. The first major bug we happened to find was that sometimes the system didn’t produce prints at all, but this was only after we worked our way through some of the smaller bugs. 

I’ll explain a little about how SolutionX was meant to operate. An output queue would be defined on the iSeries and all the prints we wanted to send were to be directed to this queue. This output queue would be defined as an IP address and would feed the spooled files into the SolutionX server which in turn was assigned the fixed IP address that we set up on the output queue. For each output queue we needed to have a folder on the PC that held the configuration data for that particular queue and once the spooled file arrived, the SolutionX server would check for the unique ID, find the template with the corresponding ID, join the two together and create two files -- one containing the data to be sent out to the printer and one containing the job data, such as which printer to send it to, the job number and other pieces of information necessary to the application. 

The printers were all set up within SolutionX (we were licensed to use up to 10 different printers) using the configuration utility I mentioned previously and we also had to enter every person who would be likely to use SolutionX. This wasn’t expected. We had to go through our entire list of user profiles on the iSeries, decide whether each person would now or in the future ever be likely to use SolutionX to produce documents and then add their user profile and a password to the system. It was rather time-consuming but not as time-consuming as when we had to re-enter them twice because there was a bug in the configuration facility.

Each user and each printer was stored within a key in the registry and somehow they were getting deleted when we did something. Suffice to say that we eventually got them all on and working but it was a little soul-destroying having to re-enter 150 names three times.

Next, we had to convert our existing reports from Optio to SolutionX. This was a lengthy process over a few weeks and involved a lot of digging through old options on our ERP system and trying to decide whether we really needed to keep them or whether we had we done enough development to render them useless. Our main re-design was for our purchase orders and, luckily, we had the developer on site who had done the original design in Optio so he was tasked with converting these to SolutionX. Sadly, the tutorials within the new system only covered less than half the functionality and we spent days and days trying to align our fields, only to find out weeks later that there was a formatting system.

Steve had got sidetracked during our installation and spent most of the time trying to configure the email server (which we didn’t yet need) and trying to telling us about how great the fax solution was (he almost talked us into letting him set up a demonstration, just to keep him happy) and he didn’t quite get the time to teach us what we needed to know about formatting and aligning fields and lines and creating grids and tables. However, through a combination of luck, skill and sheer bloody-mindedness we managed to get through the changes we had to make and finally we were able to decommission the Optio software. Little did we know that we were in for nearly two years of problems as we found bug after bug in SolutionX and our support contract was left unpaid due to the vendor’s inability to fix the bugs.

The problems started with the purchase orders. The site that produced the spooled files was based in Surrey, while our SolutionX server was based in Yorkshire. Sometimes we would have a scenario where up to 200 purchase orders hit the systems at one go which then meant that they all went through the SolutionX server at once.  This caused severe problems because each order was taking up to 30 seconds to process, leading to delays of nearly two hours before we could use the system again. 

Naturally, we decided that the best way round this was to put the orders on HLD on the output queue and release them overnight, thus allowing our day-to-day processing to carry on unaffected and then the inventory staff would still have their orders ready to fax the next day. The thought of all those orders being printed off and then faxed caused Steve some problems, though, as SolutionX could happily fax them all off if we’d chosen to purchase the fax and archiving capabilities and the additional fax software he’d especially liked to have recommended. Still, the boys in inventory had always faxed off their orders and they weren’t really interested in what Steve had to say, especially when it appeared that SolutionX was losing their purchase orders.

We were obviously a bit surprised when they said they had lost some orders because they were definitely on the system as having been sent to SolutionX and SolutionX had definitely said they had been printed. But then other departments began to have the same problems. Spooled files were definitely being produced but there was no end result. Things came to a head when it transpired we had nearly £100,000 worth of goods sitting in the warehouse that had arrived over four weeks earlier but the paperwork to get it put onto the system had never come off.

Steve came back onsite looking very worried. He went through the entire installation again, only with a newer version. Some bugs had been ironed out (including one that blacked out your designer when your PC was set to use the silver colour scheme in Windows XP). Admittedly, there was less mention of the unnamed fax software but then again it was hard for him to sell us the secondary product when we were having so many problems with the primary one.

In the meantime, we had developed software solutions to our hardware problems. We added flags to files to say that documents had been printed and we integrated the printing process into the flow of the systems so that we could see if we had sent something to print but it hadn’t been actioned. We enabled the users to reprint documents and we added clean up routines to the output queues. We did everything we could to support SolutionX and at the same time its creators tasked their developers to dial in and see if they could help us.

Eventually, we got tired of chasing them up and they got tired of trying to find solutions for us and in the midst of all the claims for support and claims for payment for support we got used to the errors and we took it for granted that we would lose some prints. Anyway, we weren’t losing so many now and as we had upgraded some offices, we replaced Twinax and HP Jet Direct boxes with direct IP connections to better printers. We’d basically given up on the support we’d been asked to pay for and the users had a system that mostly worked, so they were as happy as they were ever going to be. All until the vendor sold SolutionX to another company and due to the problems we’d been having, representatives of the new company were coming to see us. 

We were pleasantly surprised to see Steve again as he’d done so much to help us and we were glad he wasn’t quite so focused on the fax solutions. We sat down and they tried to go through the problems we’d been having, and one of the first things they did was try and map how our connection was running to our Surrey location.   And then things got fun. It appeared that we when we had switched from the token ring network to Ethernet we hadn’t really designed our network to take advantage of what Ethernet could do. We’d upgraded some printers to Ethernet, but they were still connected to the iSeries via Twinax through  a Twinax controller. We had set the output queues up via NetServer and all the iSeries printing was being done via this. Our documents were generated via a terminal on one site that connected to our main site to run the programs to produce the spooled file. It was then sent to an iSeries output queue that connected to a PC via TCP/IP. This PC would then send the created document via TCP/IP to a printer which should really just have been an IP address. 

However, our ‘printers’ were really output queues attached via NetServer, so the spooled file was then sent to the iSeries again, which directed the file to the Twinax controller, which in turn sent it to another iSeries and subsequently to an output queue with an Ethernet printer attached. No wonder we were having problems with the time it took to print an order. We simply reconfigured the printer to have its own unique IP address and, hey presto!, the orders arrived much faster, no documents were missing and the support contract began to get paid. 

It appeared that one of the fixes we’d had put in years ago was to query the status of a printer before the document was sent there. That way, the SolutionX system would know whether to send it or to keep it for later. This was getting confused with the responses it was getting from our network and somewhere along the line the prints were getting lost. Now, if only we’d listened to Steve and faxed the orders off, then we would never have found out what was causing our problems!

This article originally appeared in the March, 2007, edition of System i NEWS UK magazine.