"The BEST Postal Software Vendor with
The BEST certified software at
The BEST, if not incredible, prices."
OUR PRESIDENT'S MESSAGE
Our program products are designed and written to be reliable, robust and efficient - allowing us
to focus on customer needs and requests rather than fielding problem calls. On rare "problem" occasions, solutions are quick because each program contains the internal tools to help us find any problem - without compromising performance. Problem resolution is rapid; not distressingly slow.
Software that "performs as expected" for every customer has created our reputation - clearly demonstrated by the numerous testimonials on this site. - - - Jerry McCarthy
It costs HOW much?
One person's opinion on: "What Mainframe mailers easily forget and sadly overlook."
What do you owe for Software Maintenance?
Or, more importantly,
What does your Software Vendor owe you for those charges?!
Think about the following questions.
Then consider the thoughts and history that follow.
Were you offered the option of running your databases in 'native' Data Space(s) - to remove the I/O overhead of VSAM?
Were you offered the option of running your CASS™ processing on a zIIP - to remove GP overhead and eliminate MSU charges for that processing?
Were you offered a significant performance increase or overhead reduction to allow more concurrent tasks to run?
If you’re using our rivals'** software, the answer is “No, never.” For QMSI software, the answer is “From our first design in 2003!” Even if you didn't know QMSI existed back then; it's OK. You know now! There are many questions. And, your opinions count - to us, at least. I'd truly like to know your reactions to these statements and questions.
Why should you pay for Maintenance on a product that really hasn't kept abreast of IBM's incredible hardware changes? Doesn't your software vendor owe you something more than just meeting USPS regulations for the fees you pay for Maintenance?
I think that answer is "Yes!" Which is exactly why I feel getting a more modern, cost-effective CASS™ engine makes the small cost of switching to QMSI’s QCODE software very worthwhile!
Why can QMSI offer such great benefits while others cannot?" It's called platform loyalty; and it's our preference.
QMSI is exclusively IBM Mainframe. Our rivals** are not.
Could it be that more revenue from 'multi-platforms' is preferred over writing better, newer programs on a single platform? You decide.
QMSI has chosen to maximize the performance of our software by concentrating on a single platform and tailoring our software to take maximum advantage of the amazing hardware features offered on the IBM z System hardware.
If you have paid attention to the IBM Operating System releases over the last few decades, it was pretty hard to "miss the changes" that took place. Changes are required in an Operating System when major hardware changes are made. Changes such as adding Virtual Storage to both "DOS" and "OS" or Data Spaces, later, to both environments; and, more recently, zIIP engine support in z/OS. IBM changed their Operating Systems to take advantage of these new advances in computer hardware.
Many Application Software vendors also made major changes to their software in order to take advantage of a new OS release and/or hardware benefits. QMSI software was created with such changes in mind; our rivals'** software was created for cross platform operation - thereby eliminating any hope of those benefits being added to their (your) Mainframe support!
Given that sort of an example, What, then, do you consider a 'New Release' or 'Product Update'?
In the world of Direct Mail, for many years, new releases of CASS™ software were produced on an annual basis ... to meet ever-changing USPS "Cycle x" regulations that improved mail delivery. Every vendor must meet those challenges to be Certified, today. Was meeting those regulations and providing New Releases or Product Updates changing any software architecture or gaining access to new hardware feature?
Do you feel that meeting new USPS regulations creates a change to the
Think about it.
Most often a new routine is added and/or existing routines are altered - in old software.
Do you feel you should be charged a nominal fee for those changes?
Should you be paying additional fees on the basis that those changes constitute a new product?
Or worse, should you be forced to pay 'more' for your CASS™ software when you upgrade a CPU to improve 'online' response time, for example?!!
QMSI customers do not. And, they will not be asked to pay more for our software due to a need to upgrade a licensed CPU!
There is no question that our rivals** have changed their software to accommodate USPS-dictated changes in CASS™ requirements. And some of those changes, such as DPV or LACS or SuiteLink, have been significant in scope. But "did those changes create a new software architecture to handle those changes" or "did they simply adapt the same old architecture they had been using from the beginning?"
Here's the difference as I see it.
Our rivals** provide the same basic software they have offered for years, even decades, while the hardware has gone through incredible changes - creating a more modern, efficient and cost-effective environment. "Have you noticed the processor speed increases and DASD access speed improvements while capacity costs have radically declined?" Luckily for our rivals,** the mainframe Operating Systems have built-in, backward compatibility!
Basically, the architecture of their software, today, is "the same" as it was back in the 1990s! VSAM works fine. COBOL works fine, too. You can still depend on the Assembler to produce the fastest code possible, when done correctly. And, there are clever ways to put DASD access in Virtual Disk(s) or 3rd Party tools to move data to Data Space(s) - making many things
However, none of that creates a change to the architecture of any old programs!
Have any of the callable-interface parameters you use, today, been radically changed ... since you started using them?
Too many "tests," from an era before DPV, LACS and SuiteLink, have their remaining parameters in place, today, even though the USPS cares about just one primary "result" from CASS™ processing:
DPV confirmation ... visibly obvious in address data as the four, appended digits following
the Zip code - commonly known as the Zip+4 data.
When the Zip+4 data is present, the address that gained that DPV confirmation is guaranteed deliverable!
That matters greatly to the USPS ... and it should really matter to you, because it means all those arcane checks for 'the river rising' or 'the moon being full' to determine address validation, are worthless - today. More important, the overhead of that old code, supporting those parameters, takes CPU cycles away from other tasks you are trying to run!
Thus the questions I asked above:
When were you offered the option of running your databases in 'native' Data Space(s)
- removing the I/O overhead of VSAM?
When were you offered the option of running your CASS™ processing on a zIIP - removing 80% of the cost and GP overhead?
When were you offered a significant performance increase or overhead reduction to allow more concurrent tasks to run?
Those opening questions should now have more significance, too.
What do you owe for Software Maintenance?" or, more importantly,
What does your Software Vendor owe you for those charges?!
Why should you pay for Maintenance on a product that really hasn't kept abreast of IBM's incredible hardware changes?
Doesn't your software vendor owe you something more than just meeting regulations for your Maintenance charges?
I feel strongly that answer is "Yes!" Which is exactly why I feel getting a more modern, cost-effective CASS™ engine, from QMSI, makes the small cost of switching very worthwhile!
I invite you to share your perspective on these questions/topics.
Write to me any time using: email@example.com
- - - Tim Gregerson, QMSI VP
Pursuing a reputation of "Great software and support at unbelievable prices!"