Thursday, October 2, 2014
Size really doesn't matter...
Sometimes it seems difficult for a small or medium sized business to compete with the Big Dogs. But patience, persistence and a commitment to excellence can pay off dramatically. Our latest client was really convinced that we were the right fit, not only because our software is top-notch, but also because of the responsiveness of our entire team.
Here is what Colby Domingue, CFO of America's Pizza Company had to say about us - "Our implementation of Mlink.com's Data Resource Manager solution has been seamless due to the team's unparalleled responsiveness and concern for their client. If you are searching for a polling solution that is secure, effective and easy to use, look no further than Data Resource Manager."
Hey Big Dogs, move over!
Here's more of the story: http://www.prweb.com/releases/2014/09/prweb12168195.htm
Wednesday, March 27, 2013
A Short History Lesson
Did you know that the Mlink Data Communications system is 30 years old in 2013! Yup, Mlink has been transferring files and other data since 1983.
What else was going on then?
Many of the products, movies and political figures of the time
were household names. Arguably, Mlink should be as famous. It
came out at the same time and is still in use by a surprising
number of small and very large corporations for all of their
enterprise data transport requirements. And when it comes down
down to sheer "Gotta have it to survive", I think our slogan
says it all, "Because Information Is Business Critical"
Mlink has easily been as important to the business community
as MS Word, if not more so.
One of the absolutely brilliant features of Mlink that has
enhanced it's longevity is it's own proprietary script
programming language. This facilitated the creation of server
based automated polling systems. The first was called the
Polling Manager. PM seems somewhat crude by today's standards,
but it was cutting edge when it was released. In fact, just
a few weeks ago I worked with a very recognizable restaurant
chain who is still using it! The second server polling system
was ACM. The Advanced Communications Manager. ACM was heads
above PM and is currently used by retail and restaurant chains
as well as franchisors that I guarantee you'd all recognize by
name.
Mlink can't last forever, but I think I'll be gone before it's
gone. The writing is on the wall nonetheless. Mlink is no
longer being ported to new OS versions which means it will
eventually stop running on currently supported platforms. But
until then, Happy Birthday Mlink!
What else was going on then?
- Ronald Regan was the U.S. President.
- Motorola introduced the first mobile phones
- Sally Ride became the first American woman in space.
- ARPANET began using Internet Protocol, thus inventing the Internet
- Lotus 1-2-3 and Microsoft Word were released
- IBM released the PC XT
- Starwars Episode VI and Flashdance were hits at the box office
- Michael Jackson and David Bowie were filling arenas
Many of the products, movies and political figures of the time
were household names. Arguably, Mlink should be as famous. It
came out at the same time and is still in use by a surprising
number of small and very large corporations for all of their
enterprise data transport requirements. And when it comes down
down to sheer "Gotta have it to survive", I think our slogan
says it all, "Because Information Is Business Critical"
Mlink has easily been as important to the business community
as MS Word, if not more so.
One of the absolutely brilliant features of Mlink that has
enhanced it's longevity is it's own proprietary script
programming language. This facilitated the creation of server
based automated polling systems. The first was called the
Polling Manager. PM seems somewhat crude by today's standards,
but it was cutting edge when it was released. In fact, just
a few weeks ago I worked with a very recognizable restaurant
chain who is still using it! The second server polling system
was ACM. The Advanced Communications Manager. ACM was heads
above PM and is currently used by retail and restaurant chains
as well as franchisors that I guarantee you'd all recognize by
name.
Mlink can't last forever, but I think I'll be gone before it's
gone. The writing is on the wall nonetheless. Mlink is no
longer being ported to new OS versions which means it will
eventually stop running on currently supported platforms. But
until then, Happy Birthday Mlink!
Thursday, March 21, 2013
We're back!
Hi! We haven't blogged for quite a while, but we have an excuse. We've been hard at work producing the Data Resource Manager. DRM is a state-of-the-art data transport and polling system.
"Why would you build DRM when there are already polling systems out there?".
Pretty simple, really. Changing technology, new government and private mandates, new security threats and the constantly evolving business environment demand that software systems change as well. We didn't see that happening in the industry so we did something about it.
DRM is the product of marathon design sessions, cutting edge development environments and best practices coding methodology. It's scalable, extendible, intuitive and easy to maintain. It allows your staff to have the ability to do their jobs without permitting access to functionality they don't need. It gives management the ability to monitor staff activity and thus affords training opportunities when mistakes are made. And speaking of end user errors, DRM is designed to limit the ability for employees to enter the wrong stuff. Choices are selected from drop-down menus and text fields are checked for length, unpermitted characters and proper content.
There are a number of reasons why these features are important to you.
As our motto says, "Information is Business Critical." These days you can't run your business without the information generated every day. Broken, problematic software means no data or incomplete data. Reliability in a data transport system is job number one.
Insecure data communications is an open door to hackers. This is well known. Legacy systems transmit plain text files, clear text IDs and passwords. A hack just waiting to happen. But an insecure system at headquarters can also be a time bomb. Insider data breaches account for about 35% of all breaches. And hacked data costs money. A lot of money. In 2011 the average cost of a data breach per organization was $5.5 million. Securing communications is a no-brainer. It is also interesting to note that 39% of those insider breaches were due to negligence! Is your data transport system an open book? Or does it implement role based access as DRM does? An employee who only runs reports doesn't need to have the ability to change login credentials. Fine-tuning employee access is peace of mind.
Many software developers ignore database security, focusing on the application itself. But the data, the stuff that hackers value, is in the database. The DRM database and application are designed to deny rogue access, SQL Injection attacks, etc. We monitor current events in the hacker world and review published breaches to ensure that our software is as robust as it can be.
We'll be blogging more about DRM because we're very excited about it. It's good software! And we'll also be talking about data security, good software design and maybe even the endless snow in New Hampshire.
Stay tuned!
"Why would you build DRM when there are already polling systems out there?".
Pretty simple, really. Changing technology, new government and private mandates, new security threats and the constantly evolving business environment demand that software systems change as well. We didn't see that happening in the industry so we did something about it.
DRM is the product of marathon design sessions, cutting edge development environments and best practices coding methodology. It's scalable, extendible, intuitive and easy to maintain. It allows your staff to have the ability to do their jobs without permitting access to functionality they don't need. It gives management the ability to monitor staff activity and thus affords training opportunities when mistakes are made. And speaking of end user errors, DRM is designed to limit the ability for employees to enter the wrong stuff. Choices are selected from drop-down menus and text fields are checked for length, unpermitted characters and proper content.
There are a number of reasons why these features are important to you.
As our motto says, "Information is Business Critical." These days you can't run your business without the information generated every day. Broken, problematic software means no data or incomplete data. Reliability in a data transport system is job number one.
Insecure data communications is an open door to hackers. This is well known. Legacy systems transmit plain text files, clear text IDs and passwords. A hack just waiting to happen. But an insecure system at headquarters can also be a time bomb. Insider data breaches account for about 35% of all breaches. And hacked data costs money. A lot of money. In 2011 the average cost of a data breach per organization was $5.5 million. Securing communications is a no-brainer. It is also interesting to note that 39% of those insider breaches were due to negligence! Is your data transport system an open book? Or does it implement role based access as DRM does? An employee who only runs reports doesn't need to have the ability to change login credentials. Fine-tuning employee access is peace of mind.
Many software developers ignore database security, focusing on the application itself. But the data, the stuff that hackers value, is in the database. The DRM database and application are designed to deny rogue access, SQL Injection attacks, etc. We monitor current events in the hacker world and review published breaches to ensure that our software is as robust as it can be.
We'll be blogging more about DRM because we're very excited about it. It's good software! And we'll also be talking about data security, good software design and maybe even the endless snow in New Hampshire.
Stay tuned!
Monday, March 31, 2008
Are Mlink and ACM Secure?
The recent Hannaford data breach sent a shockwave through the IT community because Hannaford was PCI Compliance Certified. Anybody involved in data security should be constantly reviewing the strength of their efforts. This is especially true with communications and data transport.
So, no doubt the Mlink faithful have asked themselves, "Is my data safe?" The answer to that question is, as you might have guessed, "Yes and no." There are two primary areas where security might be compromised - data format and access control. Lets deal with the data first.
Mlink transmits data via the Mlink Protocol, which is unique and proprietary. The protocol uses a number of methods to cram as much information into as small a space as possible, to expedite and streamline protocol chatter and to compress the processed packets. Mlink Compression is also proprietary and unlike anything else in use today. By combining the Mlink Protocol with Mlink Compression, a relatively high degree of data "encryption" is achieved. I am unaware of any method for interpreting and reconstructing data that has been processed by Mlink other than another copy of MLink. In fact, in the late 90's one highly vaunted US military penetration testing team gave Mlink an encryption waiver as long as the compression feature was also used. I will also point out that encryption algorithms, even really good ones, have been broken before. Eternal vigilance is the name of this game.
How about access control? There are two weak points in an Mlink/ACM data transport system, and they are both insider attack weaknesses. The first is storage of login IDs and passwords in a clear text format in a file and the second is transmission of ID and password in clear text. This might not seem like much until you realize that possession of the ID and password can provide a hacker with complete access to remote Windows systems because of the interface provided by the remote Mlink.
My shameless plug is this: we've developed an encryption system that eliminates both the clear text storage and transmission problems. It's an easy plug-in and is invisible to the end user after installation. And it should be no surprize to anyone, you use Mlink and ACM to transfer and install the system.
So, yes, MLink and ACM are relatively secure but could be more secure. My advise is to always watch your six!
So, no doubt the Mlink faithful have asked themselves, "Is my data safe?" The answer to that question is, as you might have guessed, "Yes and no." There are two primary areas where security might be compromised - data format and access control. Lets deal with the data first.
Mlink transmits data via the Mlink Protocol, which is unique and proprietary. The protocol uses a number of methods to cram as much information into as small a space as possible, to expedite and streamline protocol chatter and to compress the processed packets. Mlink Compression is also proprietary and unlike anything else in use today. By combining the Mlink Protocol with Mlink Compression, a relatively high degree of data "encryption" is achieved. I am unaware of any method for interpreting and reconstructing data that has been processed by Mlink other than another copy of MLink. In fact, in the late 90's one highly vaunted US military penetration testing team gave Mlink an encryption waiver as long as the compression feature was also used. I will also point out that encryption algorithms, even really good ones, have been broken before. Eternal vigilance is the name of this game.
How about access control? There are two weak points in an Mlink/ACM data transport system, and they are both insider attack weaknesses. The first is storage of login IDs and passwords in a clear text format in a file and the second is transmission of ID and password in clear text. This might not seem like much until you realize that possession of the ID and password can provide a hacker with complete access to remote Windows systems because of the interface provided by the remote Mlink.
My shameless plug is this: we've developed an encryption system that eliminates both the clear text storage and transmission problems. It's an easy plug-in and is invisible to the end user after installation. And it should be no surprize to anyone, you use Mlink and ACM to transfer and install the system.
So, yes, MLink and ACM are relatively secure but could be more secure. My advise is to always watch your six!
Monday, February 25, 2008
Upgrading Unix OS Mlink problem
For those of you who have or are contemplating an upgrade to your Unix operating system, you should be aware of a problem that arises when you do so.
When Mlink transfers a file, by default it uses a "temporary receive file" until the transfer is completed. It then renames the temporary file to it's permanent name. In order to prevent temporary file name conflicts, Mlink uses a unique numeric naming convention. This name is derived from the 5 left justified characters of the Unix process ID of the process transferring the file. This scheme worked fine since the process ID was only 5 characters in length. 64 bit Unix operating systems can have substantially longer process IDs, which means that two Mlink processes can end up trying to use the same temporary file name during a transfer. This doesn't happen very often, but when it does, the contents of two files from separate remote locations ends up in the same file on the receiving system. The second transfer to complete reports a "Local File I/O error. #FILE = 1" error and fails the transfer.
Note that we've seen this problem occur even though the upgraded Unix kernal was built as 32 bit.
Send us an email at drmlink at mlink dot com and we'll tell you how to get the patch that fixes this problem.
When Mlink transfers a file, by default it uses a "temporary receive file" until the transfer is completed. It then renames the temporary file to it's permanent name. In order to prevent temporary file name conflicts, Mlink uses a unique numeric naming convention. This name is derived from the 5 left justified characters of the Unix process ID of the process transferring the file. This scheme worked fine since the process ID was only 5 characters in length. 64 bit Unix operating systems can have substantially longer process IDs, which means that two Mlink processes can end up trying to use the same temporary file name during a transfer. This doesn't happen very often, but when it does, the contents of two files from separate remote locations ends up in the same file on the receiving system. The second transfer to complete reports a "Local File I/O error. #FILE = 1" error and fails the transfer.
Note that we've seen this problem occur even though the upgraded Unix kernal was built as 32 bit.
Send us an email at drmlink at mlink dot com and we'll tell you how to get the patch that fixes this problem.
Welcome to the Mlink Guru blog
Hello, this is Dr. Mlink, owner and President of Mlink.com LLC - welcome to the Mlink user's blog. I hope to make this a place where Mlink and ACM users can converse about data transport issues, polling system design, modems, networks, security and anything else we can help you with.
Mlink and ACM are legacy products, yet they are still in use by mom 'n pop shops as well as Fortune 500 corporations worldwide. Mlink is still actively sold and new clients are being added all the time.
I welcome your questions and comments - Mlink and ACM have needed a user's group for quite some time!
Mlink and ACM are legacy products, yet they are still in use by mom 'n pop shops as well as Fortune 500 corporations worldwide. Mlink is still actively sold and new clients are being added all the time.
I welcome your questions and comments - Mlink and ACM have needed a user's group for quite some time!
Subscribe to:
Posts (Atom)