Yesterday we were saddened to learn that the president of a longtime Advanced Accounting user had recently died.
At age 76, Gene Patterson had still been very much active in the business operations of PatCo, Inc. an industrial and contractors supplier specializing in fire safety equipment located in Murfreesboro, Tennessee, and had been its president for the past 28 years. Gene's son Roger, with some 27 years of experience and formerly the vice president of PatCo, will be continuing to lead the company.
Gene also served in the National Guard.
Our first contact with Gene was in July of 1995. His company at that time was using Advanced Accounting 5.0 published by Business Tools, Inc. We were engaged to make a number of custom program modifications which were completed that month. Only a few months later, we held our first ever Advanced Accounting seminar (in St. Louis) and had the privilege of meeting Gene and one of his employees. Gene would later also attend a seminar that we held in Salt Lake City in the fall of 2000.
We continued to provide technical support and custom program services as needed including the software and programming assistance to convert PatCo's system from Advanced Accounting 5.0 to 5.1 by the end of 1998, and continued a relationship through to the present. PatCo continues to use the 5.1 version in 2015.
As is often the case with longtime users, often we would not hear from PatCo for long periods of time. From 2003 to 2008 we would sometimes not hear from them for more than once or twice per year, or sometimes not for an entire year or more. There was a three year period from late 2008 to late 2011 when we had no contact at all. Prior to the call the other day when we learned of Gene's passing, we had not heard from anyone there since July of 2014.
Gene and his staff were always a pleasure to deal with. He typified the hard working, long-lived entrepreneurial spirit of business owners that use Advanced Accounting.
We often don't get the opportunity to say thank you to customers like Gene and to companies like PatCo that we have had the opportunity to work with, in this case over a twenty-year period. Thank you.
And we salute Gene for the hard work he put into his business that unquestionably had a positive impact on the local community and the lives of others.
Addsum Business Software
Wednesday, September 30, 2015
Tuesday, August 11, 2015
Windows 10: Wait
A number of our users have already tested running our software under Windows 10, and the results are all encouraging and we don't anticipate any problems.
Nonetheless, especially if you depend on your PC in running a business, it is too early to update.
If you will be eligible for the free Windows 10 upgrade, then at some point before it is too late (and if Microsoft gets the message that forced automatic updates are not acceptable) you will no doubt want to upgrade.
But as with all new operating systems (and there is no exception to this rule for business users), you should wait for the first service pack to be released before simply forging ahead.
Minor updates/releases can be problematic enough. Seemingly simple updates can cause significant problems. We've written about recent examples including Win 8 updates that do not fully complete (this app cannot be run on your PC in May of 2015) and updates that caused font degradation (Microsoft automatic security update 3013455 released in February of 2015 ).
Apple iOS updates over the past several years have had more than their share of problems showing that Apple users should justifiably have the same fear of even minor updates as Microsoft users have been conditioned to have. In fact iOS 8.4 has for some of us has been a disastrous update (we have an occasionally used iPad that the iOS 8.4 update has rendered useless, even after a full reset).
Yet the fear of not getting the latest, untested security update has been pounded into the minds of computer users.
Jumping to Windows 10 however is an even bigger leap of "forced update" faith. Users need to be able to control when/whether they want to receive those updates. And, regardless of that issue, unless you want to be a part of the Windows 10 testing community and because there are always unknown problems that follow new releases, wait for the first service pack at the very least.
Some recent resources on this topic:
Windows 10 review: Hold off if you use Windows 7 (InfoWorld, July 29, 2015)
Windows 10 Forced Updates Causing Endless Crash Loops (Forbes, Aug. 8, 2015)
Windows 10 Problems: Wait to Upgrade for Now (GottaBe Mobile, Aug. 10, 2015)
An additional side note of interest relates to Microsoft's currently planned support cycles for Windows 7 and Windows 8: Windows lifecyle fact sheet.
While Windows 7 "mainstream" support ended in January of 2015, "extended" support (security updates) are still expected to be provided until January of 2020.
And if you do decide to put Windows 10 on an older computer, keep your expectations low. The upgrade may very well install and work up to a point (and that is perhaps the surprise), but your PC may also become marginally useful.
Can your old PC run Windows 10? The answer will surprise you. Here's how Windows 10 feels on very old hardware. (PCWorld, July 30, 2015)
Win 10 will not be a cure for an older, poor performing PC.
Nonetheless, especially if you depend on your PC in running a business, it is too early to update.
If you will be eligible for the free Windows 10 upgrade, then at some point before it is too late (and if Microsoft gets the message that forced automatic updates are not acceptable) you will no doubt want to upgrade.
But as with all new operating systems (and there is no exception to this rule for business users), you should wait for the first service pack to be released before simply forging ahead.
Minor updates/releases can be problematic enough. Seemingly simple updates can cause significant problems. We've written about recent examples including Win 8 updates that do not fully complete (this app cannot be run on your PC in May of 2015) and updates that caused font degradation (Microsoft automatic security update 3013455 released in February of 2015 ).
Apple iOS updates over the past several years have had more than their share of problems showing that Apple users should justifiably have the same fear of even minor updates as Microsoft users have been conditioned to have. In fact iOS 8.4 has for some of us has been a disastrous update (we have an occasionally used iPad that the iOS 8.4 update has rendered useless, even after a full reset).
Yet the fear of not getting the latest, untested security update has been pounded into the minds of computer users.
Jumping to Windows 10 however is an even bigger leap of "forced update" faith. Users need to be able to control when/whether they want to receive those updates. And, regardless of that issue, unless you want to be a part of the Windows 10 testing community and because there are always unknown problems that follow new releases, wait for the first service pack at the very least.
Some recent resources on this topic:
Windows 10 review: Hold off if you use Windows 7 (InfoWorld, July 29, 2015)
Windows 10 Forced Updates Causing Endless Crash Loops (Forbes, Aug. 8, 2015)
Windows 10 Problems: Wait to Upgrade for Now (GottaBe Mobile, Aug. 10, 2015)
An additional side note of interest relates to Microsoft's currently planned support cycles for Windows 7 and Windows 8: Windows lifecyle fact sheet.
While Windows 7 "mainstream" support ended in January of 2015, "extended" support (security updates) are still expected to be provided until January of 2020.
And if you do decide to put Windows 10 on an older computer, keep your expectations low. The upgrade may very well install and work up to a point (and that is perhaps the surprise), but your PC may also become marginally useful.
Can your old PC run Windows 10? The answer will surprise you. Here's how Windows 10 feels on very old hardware. (PCWorld, July 30, 2015)
Win 10 will not be a cure for an older, poor performing PC.
Friday, July 31, 2015
New California sick leave requirements effective July 1
When we first heard about the final implementation of this law effective July 1 in early to mid-July, last minute changes were still being made. One of the impacts of the law relates to a requirement to notify employees of their sick leave availability, one of the simpler methods being via a paycheck stub or equivalent.
The law states:
246 (h) An employer shall provide an employee with written notice that sets forth the amount of paid sick leave available, or paid time off leave an employer provides in lieu of sick leave, for use on either the employee’s itemized wage statement described in Section 226 or in a separate writing provided on the designated pay date with the employee’s payment of wages.
Section 226(a) outlines how employee wage payment information must be to provided to employees, and what minimum information must be provided.
With few exceptions, starting July 1, 2015 employees who work at least 30 days* for the same California employer within a one year period are entitled to the sick leave at a rate of not less than one hour per every 30 hours (see alternative method however discussed in the next paragraph). Employees who are exempt from overtime are not exempt from receiving this benefit, but their accrual rate can be set based on 40 hours per week (unless they work fewer hours per week than 40).
Accordingly in mid-July, Advanced Accounting 7i paycheck stubs were updated to include that information.
The new law will require potential changes to personnel policies and added administrative burdens.
For employees of employers who would otherwise be entitled to no time-off whatsoever, the new law should be helpful and might make some public policy sense.
But for employers already offering various vacation/sick/holiday plans and for those who may offer paid "leave" for time-off without trying to distinguish as to whether it is for a "sick" day or for vacation, personal day or compensatory leave, etc. does not in our opinion make much sense. Employers should not be placed in the position of having to be watchdogs with respect to the reason an employee might take a day off, whether planned or unplanned. If completely unscheduled, then some reasonable explanation should be provided by the employee and the unplanned absence tracked by the employer at its discretion, but the employer should not then be placed in the position of determining whether the employee was "really" sick or not, nor whether the sick leave was taken in accordance with the type of circumstances that might qualify as sick leave under the act. Mandatory plans that segregate different types of leave tend to lead to abuses. If employers want to combine their sick and vacation and any other paid leave into one package to their employees, they should be allowed to do so. The new law does not regulate nor require vacation or other types of paid leave. For employers who already offer more enlightened and more generous benefit programs, the new law will simply lead to a certain amount of gamesmanship and the changing of certain words in policy manuals simply to comply with the law which in the end will not likely lead to any real benefit for their workers and will simply add to the employer's administrative costs.
Background information:
http://www.jdsupra.com/legalnews/at-last-amendments-to-ca-s-paid-sick-56103/
http://www.natlawreview.com/article/california-enacts-urgent-clarifications-to-california-paid-sick-leave-law
http://www.natlawreview.com/article/emergency-legislation-to-amend-california-s-paid-sick-leave-requirements-signed-gove
http://www.natlawreview.com/article/last-minute-amendments-to-california-s-sick-leave-law
State of California general link:
http://www.business.ca.gov/StartaBusiness/AdministeringEmployees/EmployeeBenefits.aspx
The law states:
246 (h) An employer shall provide an employee with written notice that sets forth the amount of paid sick leave available, or paid time off leave an employer provides in lieu of sick leave, for use on either the employee’s itemized wage statement described in Section 226 or in a separate writing provided on the designated pay date with the employee’s payment of wages.
Section 226(a) outlines how employee wage payment information must be to provided to employees, and what minimum information must be provided.
With few exceptions, starting July 1, 2015 employees who work at least 30 days* for the same California employer within a one year period are entitled to the sick leave at a rate of not less than one hour per every 30 hours (see alternative method however discussed in the next paragraph). Employees who are exempt from overtime are not exempt from receiving this benefit, but their accrual rate can be set based on 40 hours per week (unless they work fewer hours per week than 40).
*Employees can begin taking sick leave after 90 days of employment which can be restricted to a total of 24 hours; in fact, employers can provide 24 hours of sick leave in a lump sum available at the beginning of each year instead of the "one hour per every 30 hours worked" rate. This however may not make sense for a company with a large number of part-time employees.
Various third party sources indicated that employers were required to provide employees with a notice stating sick leave "days" that were available. Not only would that be a very confusing way to to notify employees and difficult to calculate (based on an employee's part-time vs. full-time status for example), it is not what the law states. The law states employees are to be provided with "the amount of paid sick leave available." Logically, that would not be "days" but rather hours.Accordingly in mid-July, Advanced Accounting 7i paycheck stubs were updated to include that information.
The new law will require potential changes to personnel policies and added administrative burdens.
For employees of employers who would otherwise be entitled to no time-off whatsoever, the new law should be helpful and might make some public policy sense.
But for employers already offering various vacation/sick/holiday plans and for those who may offer paid "leave" for time-off without trying to distinguish as to whether it is for a "sick" day or for vacation, personal day or compensatory leave, etc. does not in our opinion make much sense. Employers should not be placed in the position of having to be watchdogs with respect to the reason an employee might take a day off, whether planned or unplanned. If completely unscheduled, then some reasonable explanation should be provided by the employee and the unplanned absence tracked by the employer at its discretion, but the employer should not then be placed in the position of determining whether the employee was "really" sick or not, nor whether the sick leave was taken in accordance with the type of circumstances that might qualify as sick leave under the act. Mandatory plans that segregate different types of leave tend to lead to abuses. If employers want to combine their sick and vacation and any other paid leave into one package to their employees, they should be allowed to do so. The new law does not regulate nor require vacation or other types of paid leave. For employers who already offer more enlightened and more generous benefit programs, the new law will simply lead to a certain amount of gamesmanship and the changing of certain words in policy manuals simply to comply with the law which in the end will not likely lead to any real benefit for their workers and will simply add to the employer's administrative costs.
Background information:
http://www.jdsupra.com/legalnews/at-last-amendments-to-ca-s-paid-sick-56103/
http://www.natlawreview.com/article/california-enacts-urgent-clarifications-to-california-paid-sick-leave-law
http://www.natlawreview.com/article/emergency-legislation-to-amend-california-s-paid-sick-leave-requirements-signed-gove
http://www.natlawreview.com/article/last-minute-amendments-to-california-s-sick-leave-law
State of California general link:
http://www.business.ca.gov/StartaBusiness/AdministeringEmployees/EmployeeBenefits.aspx
Thursday, July 16, 2015
Pervasive 161 (license count status code)
A Pervasive (informally Btrieve, and now owned by Actian) status code 161 as intercepted and returned in an Advanced Accounting environment might appear as:
While most often it is in workgroup installations (i.e. using the Actian/Pervasive workgroup engine, even if installed to a "real" production server) when this error is generated, it can also occur in client-server versions since the 161 means (from Pervasive's status code documentation):
161: The maximum number of user count licenses has been reached
You attempted to open another session when you were at the limit of your user count license. Either close a session or upgrade your user count.
This status code is also returned after a trial or temporary license has expired. If all users receive this error and no one is able to access the database engine, then most likely you have been using a temporary license key and you must now apply a regular license key. Please contact your reseller or Pervasive Software to purchase a regular license.
For more information about purchasing and installing additive user counts, refer to Getting Started With Pervasive PSQL. You can use Monitor to determine which users currently have connections to Pervasive PSQL. For information about Monitor, refer to Advanced Operations Guide.
This utility should be used to assign the PC that "hosts" the software application and needs to point to the data folder where the Pervasive data files are stored. In that folder, it will create a read only file name PVSW (an abbreviation for Pervasive Software) that is enclosed in tildes and that has an LOC extension, i.e.: ~PVSW~.LOC. Designating a PC as gateway then basically allows that designated PC to act more like a server would in a true client-server installation. In other words, the Pervasive workgroup engine has some built-in client-server type capabilities. The locator file can be removed manually only by first removing its read only attribute or by using the Gateway Locator Utility. Removing it would solve the status code 161 but if the gateway locator is not set, then the first PC to open the data files becomes the gateway computer and that can lead to a number of problems (if for example that first PC is then shutdown after other PC's have accessed the data while it was still the "traffic cop"). We would therefore highly recommend always making a gateway assignment when using the Actian/Pervasive workgroup engines.
When migrating the data folder(s) of a system to a new computer, all of the data and related INI files (and usually also the software as well) are naturally going to be copied to that new computer. But this then will pick-up the locator file. Then, when trying to run the software even after deauthorizing and re-authorizing the license via the Pervasive License Administrator, an error 161 may result since it will be the old server/gateway with the deauthorized license that new server/gateway as well as the other workgroup engines will be looking for. If the old server/gateway is off-line, instead of an error/status code 161, a status code 11 (invalid file name) or some other status code might be returned, and it may also take a long time before that error is returned while the database engine/Windows tries to find the old server name.
To resolve, a new gateway assignment needs to be made. The new server name would be entered under "Enter the computer name of the gateway" and this would be run directly on that same computer:
While most often it is in workgroup installations (i.e. using the Actian/Pervasive workgroup engine, even if installed to a "real" production server) when this error is generated, it can also occur in client-server versions since the 161 means (from Pervasive's status code documentation):
161: The maximum number of user count licenses has been reached
You attempted to open another session when you were at the limit of your user count license. Either close a session or upgrade your user count.
This status code is also returned after a trial or temporary license has expired. If all users receive this error and no one is able to access the database engine, then most likely you have been using a temporary license key and you must now apply a regular license key. Please contact your reseller or Pervasive Software to purchase a regular license.
For more information about purchasing and installing additive user counts, refer to Getting Started With Pervasive PSQL. You can use Monitor to determine which users currently have connections to Pervasive PSQL. For information about Monitor, refer to Advanced Operations Guide.
A 161 however can mean something quite different than the explanation above. In a workgroup situation where the gateway locator has been appropriately set using the Pervasive/PSQL Gateway Locator Utility and the accounting or other software is moved to a different server or gateway PC, this can then lead to the user receiving a 161 until a new "server" gateway assignment is made.
The Gateway Locator Utility (which again, only applies to Actian/Pervasive workgroup configurations and not Actian/Pervasive client-server installations) is located under the utilities section (or can be searched for under PSQL Gateway Locator in Win 8 or just search for gateway).
This utility should be used to assign the PC that "hosts" the software application and needs to point to the data folder where the Pervasive data files are stored. In that folder, it will create a read only file name PVSW (an abbreviation for Pervasive Software) that is enclosed in tildes and that has an LOC extension, i.e.: ~PVSW~.LOC. Designating a PC as gateway then basically allows that designated PC to act more like a server would in a true client-server installation. In other words, the Pervasive workgroup engine has some built-in client-server type capabilities. The locator file can be removed manually only by first removing its read only attribute or by using the Gateway Locator Utility. Removing it would solve the status code 161 but if the gateway locator is not set, then the first PC to open the data files becomes the gateway computer and that can lead to a number of problems (if for example that first PC is then shutdown after other PC's have accessed the data while it was still the "traffic cop"). We would therefore highly recommend always making a gateway assignment when using the Actian/Pervasive workgroup engines.
When migrating the data folder(s) of a system to a new computer, all of the data and related INI files (and usually also the software as well) are naturally going to be copied to that new computer. But this then will pick-up the locator file. Then, when trying to run the software even after deauthorizing and re-authorizing the license via the Pervasive License Administrator, an error 161 may result since it will be the old server/gateway with the deauthorized license that new server/gateway as well as the other workgroup engines will be looking for. If the old server/gateway is off-line, instead of an error/status code 161, a status code 11 (invalid file name) or some other status code might be returned, and it may also take a long time before that error is returned while the database engine/Windows tries to find the old server name.
To resolve, a new gateway assignment needs to be made. The new server name would be entered under "Enter the computer name of the gateway" and this would be run directly on that same computer:
Without re-booting, it should then be possible to run the application that accesses the data files without getting a status code 161 or some other error, both from the gateway PC as well as from other computers with an installed Pervasive workgroup engine (and assuming those other PC's have been pointed to the NEWSERVER name in the Pervasive license administrator which needs to be run on each PC in the workgroup).
Tuesday, July 7, 2015
Pervasive 11 status and Windows 10
In light of the release of Pervasive 12 (PSQL v12) late last year (see Actian releases Pervasive 12: first look), Actian has as of June 30, 2015 stopped selling new user copies of PSQL v11.
One day later, however, a v11 patch was issued on July 1, 2015 (Pervasive PSQL V11.30 install build 11.31.073 read me file). Nothing in that patch appears to be of great importance for our user base.
While official support for v11 from Actian is planned to continue until July 1, 2016, Actian does not plan to support v11 on Windows 10, scheduled to be formally released by Microsoft very soon. That timing is awkward. It is nonetheless likely that v11 will work at the very least in connection with Windows 10 clients and in workgroup configurations.
PSQL releases are normally compatible if within one major release of each other and typically do work on the "next" major Windows operating system release (but not always). Whether v11 will also work on "Windows 10 server" remains to be seen, but a release of server technology based on Windows 10 is not yet imminent.
End users are always advised to wait until the first service pack (SP1) of a new operating system or database engine is released before migrating to that release, absent extenuating circumstances.
One day later, however, a v11 patch was issued on July 1, 2015 (Pervasive PSQL V11.30 install build 11.31.073 read me file). Nothing in that patch appears to be of great importance for our user base.
While official support for v11 from Actian is planned to continue until July 1, 2016, Actian does not plan to support v11 on Windows 10, scheduled to be formally released by Microsoft very soon. That timing is awkward. It is nonetheless likely that v11 will work at the very least in connection with Windows 10 clients and in workgroup configurations.
PSQL releases are normally compatible if within one major release of each other and typically do work on the "next" major Windows operating system release (but not always). Whether v11 will also work on "Windows 10 server" remains to be seen, but a release of server technology based on Windows 10 is not yet imminent.
End users are always advised to wait until the first service pack (SP1) of a new operating system or database engine is released before migrating to that release, absent extenuating circumstances.
Thursday, May 14, 2015
Win 8: This app can't run on your PC
A somewhat strange and potentially misleading message can appear on the desktop of Windows 8 PC's:
Most users will probably know that "run" is the same as "execute" or "operate" or "invoke" or "launch." So we do not quibble with that terminology per se.
Use of "app" is for those of us who have been developing software programs and software applications for decades is a little disconcerting, but is now the widely used lingo for anything and everything that runs on "smart technology" (whatever that is). We would however never refer to our accounting software as an "app" no matter how hip that might be.
But, besides use of the informal "can't" in the context of a relatively serious and disconcerting error message like this, our objection is that the problem could well relate to the fact that it is the operating system that cannot execute the program. Thinking that it is the program's fault, or that of its software publisher, immediately leads to potentially errant conclusions, provoking the user to start reinstalling previously working programs in acts of futility, and making a bad problem worse.
If you receive a message like this the very first time you have ever tried to "run" a newly installed program under Windows 8, then, yes, it could relate to the fact that you have a 64-bit program trying to run under a 32-bit operating system version, or perhaps anti-virus software, user permissions or SmartScreen conspiring to block your program and not allow it to run, and potentially any number of other culprits.
But, if this message suddenly appears after programs have already been working (i.e. running), then in fact the problem could be the result of incomplete processing of Microsoft automatic updates (which is why we do NOT like to enable automatic updates).
The actual solution may be to return to a prior system restore point. Or complete the unfinished updates.
This is all sounding eerily familiar. Incomplete automatic update problems that lead to applications not being launchable is not a new problem. We just have now a new unhelpful error message associated with that circumstance.
Another recent example of a problem caused by an automatic update that we wrote about:
Microsoft automatic security update causes font degradation
Problems associated with incomplete XP Pro updates were legendary. The legend continues!
 |
| This app can't run on your PC (much less walk!) |
Use of "app" is for those of us who have been developing software programs and software applications for decades is a little disconcerting, but is now the widely used lingo for anything and everything that runs on "smart technology" (whatever that is). We would however never refer to our accounting software as an "app" no matter how hip that might be.
But, besides use of the informal "can't" in the context of a relatively serious and disconcerting error message like this, our objection is that the problem could well relate to the fact that it is the operating system that cannot execute the program. Thinking that it is the program's fault, or that of its software publisher, immediately leads to potentially errant conclusions, provoking the user to start reinstalling previously working programs in acts of futility, and making a bad problem worse.
If you receive a message like this the very first time you have ever tried to "run" a newly installed program under Windows 8, then, yes, it could relate to the fact that you have a 64-bit program trying to run under a 32-bit operating system version, or perhaps anti-virus software, user permissions or SmartScreen conspiring to block your program and not allow it to run, and potentially any number of other culprits.
The actual solution may be to return to a prior system restore point. Or complete the unfinished updates.
This is all sounding eerily familiar. Incomplete automatic update problems that lead to applications not being launchable is not a new problem. We just have now a new unhelpful error message associated with that circumstance.
Another recent example of a problem caused by an automatic update that we wrote about:
Microsoft automatic security update causes font degradation
Problems associated with incomplete XP Pro updates were legendary. The legend continues!
Thursday, May 7, 2015
The staying power of a 25-year old application development system
While we extensively used the TAS 3.0 system released in the late 1980's by Business Tools, Inc. (the second printing of the manual was in March 1989, and which reached its prime in about 1991) back in that same era, in recent years we have had little reason to use it except in rare situations involving converting data from very old systems. TAS 3.0's short dates were not Y2K compliant and most TAS 3.0 users had migrated their applications forward to newer versions long before the year 2000 for many reasons besides just the date issue.
Yet some users persisted, especially those that were highly customized and also for some that did not want to deal with changes that the Business Tools TAS 4.0 development system brought to the picture in 1993.
Users of some of these older systems (who chose to fight rather than switch) survived the year 2000 by customizing their systems to use "long dates." A conceptually simple change, it nonetheless required making dictionary changes to every file descriptor (similar to a "table"), changing every temporary defined date field to a long date size, then going through every data input screen and report form layout to make placement changes in order to fit the long dates and replace them with the newly permanent field and temporary field changed sizes, and recompiling every affected program. In short, a significant amount of work.
Both TAS 3.0 and 4.0 (and also 5.0 and 5.1) were 16-bit programs, yet they continued to run on every operating system that Microsoft came out with. They survived the Win 95 "scare." Then Win 98. Then NT. They kept on running on XP Pro (in fact, XP Pro was and is an extremely stable and reliable environment for these systems) after another scare that 16-bit programs were not going to function. And they still will run innately on 32-bit Windows 7 including some very old components.
Nonetheless and despite the fact that TAS (and products written in TAS including Advanced Accounting) have long since been migrated into graphical, 32-bit worlds, we have found ourselves in 2015 consulting with several users who have extensive customized systems running on modern operating systems: one case using TAS 3.0 (see screen shot below), and another that until very recently was still using a system developed with TAS 4.0. And we have recently we have had to make some programming changes into these environments. With the 3.0 system, we are making bug fixes to customized source code involving EDT source files (but not using the built-in TAS 3.0 editor) on an ongoing basis, and with the 4.0 system dealing with converting the older program code to the newer TAS Premier 7i.
Predecessor products were actually released long before in the early 1980's, so the TAS development system has it roots that now go back well over 30 years.
And, even in 2015, rarely a day goes by where we don't still use in some context the TAS Professional 5.1 development system (first released by Business Tools, Inc. in August of 1996).
The longevity of these systems is truly remarkable, and largely unprecedented in the computer software industry.
Yet some users persisted, especially those that were highly customized and also for some that did not want to deal with changes that the Business Tools TAS 4.0 development system brought to the picture in 1993.
Users of some of these older systems (who chose to fight rather than switch) survived the year 2000 by customizing their systems to use "long dates." A conceptually simple change, it nonetheless required making dictionary changes to every file descriptor (similar to a "table"), changing every temporary defined date field to a long date size, then going through every data input screen and report form layout to make placement changes in order to fit the long dates and replace them with the newly permanent field and temporary field changed sizes, and recompiling every affected program. In short, a significant amount of work.
Both TAS 3.0 and 4.0 (and also 5.0 and 5.1) were 16-bit programs, yet they continued to run on every operating system that Microsoft came out with. They survived the Win 95 "scare." Then Win 98. Then NT. They kept on running on XP Pro (in fact, XP Pro was and is an extremely stable and reliable environment for these systems) after another scare that 16-bit programs were not going to function. And they still will run innately on 32-bit Windows 7 including some very old components.
Nonetheless and despite the fact that TAS (and products written in TAS including Advanced Accounting) have long since been migrated into graphical, 32-bit worlds, we have found ourselves in 2015 consulting with several users who have extensive customized systems running on modern operating systems: one case using TAS 3.0 (see screen shot below), and another that until very recently was still using a system developed with TAS 4.0. And we have recently we have had to make some programming changes into these environments. With the 3.0 system, we are making bug fixes to customized source code involving EDT source files (but not using the built-in TAS 3.0 editor) on an ongoing basis, and with the 4.0 system dealing with converting the older program code to the newer TAS Premier 7i.
 |
| TAS 3.0 components still running on a modern system on a multi-user basis (May 7, 2015) |
Predecessor products were actually released long before in the early 1980's, so the TAS development system has it roots that now go back well over 30 years.
And, even in 2015, rarely a day goes by where we don't still use in some context the TAS Professional 5.1 development system (first released by Business Tools, Inc. in August of 1996).
Subscribe to:
Posts (Atom)