Current development Status

[Vincent (Bryan) Coen]

See comments from other subject but now looking at using dbpre (0.4) as well as Jim Curry's software that does similar in order to help convert the MS SQL DALs (Data Access Layers) for each of the Cobol files used within ACAS.

Problem is I need more SQL functions than are currently in these / MySQL so looking for ways around the problem/s.

Would help if I was current on SQL usage but its been over 20+ years ago and that was DB/2 on M/F (mainframes) and with the help of a DBA.

[Vincent (Bryan) Coen]

Progress report:

Moving forwards using Jim Currey's presql tools and have written RDB DAL & FH's for stock control, with some more for Sales & Purchase - more to do. Stock Control has been functional and system tested (within Stock) more needed but as I cannot use existing regression test packs have to run munually - very slow.)

Currently creating new FH and DALS once per two days or so. Sometimes slower, simetimes a little faster. Hopefully will have a testing ready for user testing before the end of the year (2016) but this is NOT cast in stone as I am now retired from Death march projects and that includes my own - Can't take the pressure any more.

Also looking at adding the RDB processing into IRS as that can use different RDB databases for each company or client so is now practical to do all using the same parameter and or RDB set up file.

One problem will be continuing with the manuals although some have been done but much more work on them is needed and that is before the extra RDB changes.

Here the final new documentation will be created during system testing as well as the end to end testing with black box testing to finish off. Remember with RDB processing, the data can be held any where that can be accessed via a LAN, WAN or the internet and this testing may involve changes to the system to improve functionality for remote working.

Volunteers are always welcome to help update these :)

So hopefully all going well should have a update out before too long. Also once they have all been coded I will start making a nightly code updates available on my website at www.applewood.dtdns.net/files/acas/nightlybuilds

[Vincent (Bryan) Coen]

Current status as at 1st Jan 2017.

IRS :
1. Has now had the system param data merged into the normal ACAS system file and is therefore no longer used.

1. Has now been converted to use RDB for all processing other than reading the system param file to pick up the RDB info then doing all remaining processing using the RDB system param table. All updates to that RDB table also go to the Cobol param file as a back up.
   If user has not requested to use RDB then IRS just uses the Cobol param file and likewise all of the other files that are used.

2. For normal use and for data migration the remaining four files need to be renamed with a prefix of 'irs' i.e., dflt.dat becomes irsdflt.dat and all files copied to the ACAS data directory before running (once) the supplied table load programs, one for each of the four files.

3. The IRS system has gone through all basic tests and all reports are showing exactly the same results. However detailed testing from a new year start has not been done as I need to get on with other systems.

4. One step not yet done is to make the existing pre-report sorts redundant but I will visit that for RDB processing but not too sure if it will be any quicker - more a case of clean up and remove the need for any temporary files used. Will try and do that over the next few days. Of course this change is ONLY related to RDB usage.

For those users that are using IRS and possible other of the sub systems to process various clients account processing this can still be done but now you just create a new database for each client by abbreviating the client name to fit the maximum size that a DB name can be. It still requires the use of one directory per client but now all files can just sit in the ACAS directory for that one client but it is only the one file - the system parameter file that exists in that directory if using RDB processing.

It was considered to remove the need for the system param file when doing RDB but there is still a need for one file holding the various connect information so regardless one file would always be needed and as the param file is very small I have left it as is. The other consideration is that I would have to make sure that a similar facility exists for any other RDBMS system that are supported in the future, which is hardly a given.

STOCK Control.
1. Has been migrated over to using RDB tables or Cobol files as well.
2. Has had some testing but more the check that all reports are the same as for files.
3. Still requires full system testing but like IRS I hope you the users will help here until I finish the rest of the ACAS system to do so. I also have to do or redo all of the manuals which is no small task but a lot of that will involve doing through each sub system to help document such.
4. Elements of Stock use various files from Sales, Purchase, IRS and these too have also been created and where possible basic testing completed but more will be needed.

All of the above systems also have new programs that load the RDB tables with data from the existing Cobol files.

Note that the auto back up scripts do not handle backing up the Database/s and this will need to be set up by users although I will try and have a look at this at some point.
In my test environments I have two RDB servers one (Mariadb) on the local machine which is backed up daily via webmin created scripts running under crontab but on the remote server (OK, in the same room) and on a Mac Pro v10.11 I have not found a method of doing this yet - have enough problems trying to work with it and yes I have extremely limited knowledge of OSX !

So far, out of 33 files used 11 are converted to RDB processing supported with the applications. Five files are temporary in nature (sort and or report work files) will will remain as is if I cannot make them redundant by using the selective data facilities of SQL.
So that's 16 done with at least one actually not even used leaving around 16.
Of these six relate to invoicing for sale and purchasing that will require some detailed source examinations so the other 10 will be done next booked for January completion all being well. No doubt there will be some tweaking and more knowledge is added when creating these new one and if needed revisiting the code of ones completed.

Remember for every Cobol file there is one FH (File Handler module) that actually replaces the Cobol verbs for that file, that in turn (if RDB in use) calls one DAL (Data Access Layer module) to process the RDB Database along with the file loader program to convert the Cobol file to the Database. So a bit of work still to do.

So, next is working on Sales which will cover five more files / tables however here I also have to look very closely at the way the three invoicing files works in order to cut it down to two tables and the Cobol file down to one as I am sure the need for three can be removed as this design goes all the way back to limited drive capacity - small removable hard drives and likewise, Floppy drives. There is also examples of these issues with General that will also need to be visited but that one I am leaving to last to work on.

If this should be required by users to be made more urgent please say so and why.
I still have to create the manuals - well at least release of them for the new system changes.

I am not making these source available yet but if any one would like them as a work in progress, I will start to build weekly sets of the sources etc. available from my web or ftp servers.

To run this new version you will need to have a fully working copy of MySQL server at least the totally free community version along with the connector/C support library and include files (also free). It is also recommended to install Mysql-Workbench or at the very least the Phpmyadmin package that works through a web browser - not as good but reasonable for very light use. I use both depending on my needs at the time.

While testing or experimenting with, this rdb server must not be the same one used for production but here and if you have one, your IT support department can help !
I will create more 'howto' instructions as I start to complete this upgrade.

Some of you must wondering why use a database over using Cobol files and the reason is simply that if muiti users are using aspects of the ACAS system using the Cobol file method sharing records and/or files can be a problem. This is fully looked after using a database and you can have as many users in the system at the same time. Also the system resources can be monitored and administrated a lot easier plus the final bonus of only having to back up one system on one server or computer acting as one and yes you only need a PC for this job. Some users have 30 or more users on the system at any one time and the Cobol file system is just not cutting it.

I will look at adding to the list of different RDBMS systems subject to user requests but lets get the first one done as migrating will be a lot easier and less time consuming. At the moment I have on the one development system MySQL, Oracle, MS SQL server for Linux (very experimental), DB/2 and yes they co-exist very well but I am hardly using them.

That it for now.

Apologies for any typos but this SF system does not have any spell checkers available!

[Vincent (Bryan) Coen]

Update progress:

Other than the invoices files for sales & purchase Ledgers all of the FH (File handlers) have now been coded and compile cleanly.

I have omitted the Cobol Cheque file as I am not aware of anyone still paying by check but it is only a temporary file between generation and printing then discarded.

So leave the six invoicing files which I will leave for a bit later but next is the outstanding DAL (Data Access Layer) for the RDB processing to match up with the FH modules now completed. After dealing with these it will be the data load programs for these files and tables.

At which point I will start to deal with the invoice files and hopefully reduce files to one for each ledger (Sales & Purchase) and two tables each for the RDB, one for the main body of invoice data and the other for the invoice line items (sold or bought) there is one record/row for every item on an invoice or purchase order and that for sales links to Stock control if used.

When an invoice is paid the line items records / RDB rows get deleted and the invoice lives for another statement cycle at most (as far as I remember) before being removed from the system.

So a little more complex than most of the other files and rdb tables and I have to look closely at exactly the way the programs deal with this data to see how I can reduce the Invoice file counts. These files are predefined in usage depending on what stage a invoice is at :

File 1 new record is created when an invoice is:
File 2 record created when invoice printed and
file 3 when posted.

Exactly why the number of files/tables should be reduced to one - hopefully.

The proof report is for checking that invoice have been created correctly before printing as against having to create a credit note against an error - just more work for sales department if it can be spotted before hand. How many companies actually use the facility I do not know but I do know that some businesses do run proof / prints every 2 hours so as to keep the dispatch team busy but every business will have their own way of running the process steps and the ACAS system allows for that as well as entering and printing a invoice at a time such as a customer waiting to take item/s away now, etc.

That's enough for now - back to work.

[Vincent (Bryan) Coen]

Update Progress:

Quicky, this time - Other than the invoicing file/tables all File load programs have now been completed.

So that's the LD (file loaders), FH (File Handlers Cobol) & DAL Data Access Layers (RDBMS accessing for MySQL & MariaDB).

For information all programs & modules access Cobol files and tables directly through the File handlers and they call the correct Table DAL and if needed any repeat groups that are converted to a table. Here only one for the Payments file & table but it will act as the modal for invoice processing.

Currently Updating Sales Ledger to use the FH replacing the Cobol verbs etc.

This will also allow me to take a close look at the way the invoicing files are processed so I can see how to program the FH & DAL for these file/tables at which point it should be just a question of migrating Purchase and General and the outstanding invoice processing in Sales.

It is slowly getting there.

More next week.

[Vincent (Bryan) Coen]

Current status as of 11/02/17 12:00 UTC.

Modifying S/L (Sales Ledger) over to using RDB / Cobol files using FH & DAL's has been more or less completed - just sl905 & 960 to do.

Invoicing and the OTM3 (Open Item) files for S/L has been done, the DALs have been completed but need to revisit the code for Invoicing to dry code and test to verify.

Coding has forced me to do a minor change to the file format of Invoicing & OTM3 in that the line field has been changed to pic 99 from a binary-char to help with migration to RDB and this will involve creating convert program/s that will need to be run once on any existing files prior to you testing the new system where the original will be saved as a filename.ext.bak
Also a small change is needed for the ACAS system paramter file to support additional fields used with RDBMS systems. The system convert is done but will need to double check the code before release nad will create the invoicing convert program/s over the next week or two.

Once Sales is completed dry testing I will start of P/L (Purchase Ledger) which hopefully will be a lot quicker to do. At this point I will issue a Beta RC version for every one to test.

Yes this will require you to note all problems but will ask you all to initially test using Cobol files and if that is successsful then re-test using the RDB elements of the systems.

The update for P/L (Purchase Ledger) will now provide an updated that supports RDB for Sales, Purchase, Stock and IRS. G/L (General / Nominal Ledger) will be visited after I have a change to complete some manuals at least as a Beta release but may be without all the pretty pictures of the screen layouts etc. I will then (assuming reported bug issues are not a major distraction), have a go at General to test as current then migrate over to using FH and DALs for Cobol file and RDB processing.

I am sure I need to do some fixes prior to starting on the RDB mods.

For testing this RC release for v3.02 I would like to see you attempting to use a reasonable sized set of data files for the Sale, Purchase, Stock ledgers and link all to IRS making sure you keep back ups of your data files as you go so you can do a restore before retrying any areas that are causing problems.

Any errors/ bugs reported will be fixed ASAP but allow 24 - 48 hours. Source file changes will be made available from my website first asit is easier than me remembering how to update the code base on SF and these changes will have a version number on archives similar to acas-3.02.buildnumber with the bug reporting tool here showing updates / fixes.

I would recommend that all subscribe to the Bug reporting system at SF so that all reported bugs are available to all of you. Remember if it is not there to report it.

The more that test and do this will speed up the test cycle.

If any of you are using it in a dummy or real production environment and can provide your ACAS system files containing the master S/L, P/L, Stock, IRS data files will help on improving the test processes. Remember to change the names/addresses of supplier, customer etc to make them impossible to use other than for testing - I actually change / swap names, address lines, contact phone/email details between all in each file to make it impossible to contact any one etc.
I will go through a telephone directory of local businesses and load up a set myself as soon as time is available - but any thing to help reduce my work flow :)

If you are interested in helping test the new version it would help me if you express interest in the discussion forum.

Thanks.

More later.

[Vincent (Bryan) Coen]

Current status as of 23rd April 2017.

Sorry for the delay in an update.

Sales Ledger now complete, along with irs and stock. This means the FH, DALs and LD (Load modules) are finished and dry tested but need to be tested.

Started on Purchase Ledger today so it will be a week or three - will advise when a little bit closer to finish so that means 2 FH, DALs and LD modules need to be done along with all the programs in this suite to be converted over to using them.
Hopefully quicker than doing Sales.

I am now doing a nightly build archive containing the current sources of the ACAS & IRS systems.

Any one interested in absolutely cutting edge code (with minimal testing) is welcome to play with it but please only do initial testing using Cobol files so that way we can verify operations of the FH (File Handler Cobol) units. All Load modules have been tested but Sales its minimum what ones have been done, Don't forget you will need to :

1. Make a complete back up of your data files and store them in another directory.
2. Useing any of the systems - sales, purchase stock etc run the param set up process nd go the the end where it says Print out and select yes to get a hard copy of the current data.
3. Check the source of acasconvert2 (and may be 1 if using a old ACAS release and compare the system file layout with the system file layout in your current version (see the copybook directory) to ensure you run the correct convert program.
4. Now using the correct version of acasconvert to update the layout of the param file.
5. Make a new directory to contain the new nightly build version that is NOT the same of you current release (should be 3.01) as you might need it. You will for (3).
6. Compile the programs using the comp-all.sh script in the top most source directory but note that you will get errors for many of the programs in Purchase, XL150 in common and possibly a few in General.
7. Make a total back up of your ~/bin directory
8. run install-acas-preinstalled.sh & install-irs-preinstalled.sh.
9. Assuming all the above is good, now go in to stock or sales then into the param option and check all settings. There will be some for the rdbms leave these for the moment but set using Cobol Files to true/1 etc so you only use the Cobol file handling. You can always switch to RDB and run the load modules to transfer your data over they do not overwrite your data files. There is no programs to allow you to go the other way e.g., RDB to files.
10. This is one reason for starting testing using the Cobol file processing.

Report any problem direct or through these forums both is even better but don't forget to mention the problem program and the version that is displayed or printed.

Location for the nightly builds :

http://www.applewood.dtdns.net/files/acas/nightlybuilds/
The above has been replaced by : ---

http://www.applewood.linkpc.net/files/acas/nightlybuilds/

and the file is ACAS-Nightly.zip

More in the next couple of weeks.

[Vincent (Bryan) Coen]

I always seem to forget something :

IRS after making a full back up of all the data files make sure you also
do one for the IRS files.

Having gone through my list of processes you should copy over the IRS
data files /BUT NOT/ the system.dat file and as you do so rename
then with a leading 'irs'.

For example :

dflt.dat -> irsdflt.dat
post.dat -> irspost.dat
final.dat -> irsfinal.dat
acnts.dat -> irsacnts.dat

DO NOT COPY OVER THE system.dat file.

When you first go into stock, sales param setup module there are some
settings for IRS but many will come from the ACAS settings.

When testing initially start by running the report processes and check
the results against one's produced from the older current version (v3.01).
There should not be differences.
Then you can enter say a new sales ledger account likewise enter a new
stock record and even enter some posting into irs.

Check the results via the reporting programs to check that all is OK.

Well that should keep you busy enough while I try and finish off
Purchase Ledger.

Any queries or question ask away

Vince

[iman]

Can I use general ledger module only? At the moment I don't need sales, purchase ledger, etc...just general ledger. Kiss.
How to? Thanks

[Vincent (Bryan) Coen]

If you are a small company I strongly suggest you use IRS.

Two reasons :

IRS is more geared for book keepers and normal users who have some
understanding of double entry book keeping but not to an accountancy
level. Now although you do not need to be an accountant for General Ledger
it will be very helpful when designing your accounts layout.

For IRS, there is supplied, a basic limited company set of accounts and
this is provided in a text format.
Taking a copy of this (having saved the original) change it as
needed for your own use changing the odd description to match up to your
business such as names of the directors for the petty cash accounts etc.
It does not hurt to leave in any accounts that you will not use as they
can be removed later when you are sure having used the system that they will
never be needed.

IRS uses automatically double entry book keeping and there is a brief
introduction to the principals of book keeping in a included document
that you should read if you are not familiar with it as it will help you
understand the way the IRS system works.

Think of IRS as a small companies General/Nominal Ledger system but a
lot easier to use.

General Ledger was originally designed for large businesses and the size
of the accounts number was 10 digits for both the main and the sub
nominal accounts. The Open Source version as it would normally run on
PC's is smaller BUT it does use branch / department accounting.
It is a more complex system for the needs of the smaller business and therefore
harder to fully understand and likewise prone to user mistakes and this
is hardly wanted for a business with a small number of staff.

Another point is that I have not yet fully tested General since
migrating the system over to use GnuCobol so there might still be bugs
in it.
It is on my list of TO DO's but after:
1. Finishing migration of Purchase Ledger.
2, System testing of Sales, Purchase, Stock along with updating the
existing manuals for IRS, Stock & Sales as well as rewriting the manual
for Purchase. -- Ideal time for cleaning them up is while I am running
system testing.

The version that is on the Sourceforge website is v3.01 and that handles
using Cobol files and will work exactly right for you using IRS.

Try it but read the manuals first.

Vince

On 24/04/17 12:11, iman wrote:

Can I use general ledger module only? At the moment I don't need
sales, purchase ledger, etc...just general ledger. Kiss.
How to? Thanks

---

[iman]

Plus..I don't need big database like mysql, flat text db file more than enough for small co, I think

[iman]

I installed IRS module only and succes.
But when I want to set up coa and press N or Y...the following eror result...

Failure to Open Nominal-Ledgeerror code = 35

Anything wrong?

[Vincent (Bryan) Coen]

Please advise :

1. What version you are running (should be displayed on screen with
   program name and version) ?
2. Where in the process you are, e.g., what was the previous two messages?
3. When looking at the working directory what files are present?
4. What version of the Cobol compiler are you using to build the system?
5. What platform are you using and if Linux what distro?

You should always provide 1 & 2.

Vince

On 25/04/17 03:51, iman wrote:

I installed IRS module only and succes.
But when I want to set up coa and press N or Y...the following eror
result...

Failure to Open Nominal-Ledgeerror code = 35

Anything wrong?

---

[Vincent (Bryan) Coen]

Small points :

Follow the manual in using IRS but and assuming here:

If you are in the accounts maintenance program and you have a empty or
not existing accounts file and you have in your working directory the file

coa-archived.txt

Then if it is suitable for you (if not save a copy somewhere else then
change it using a text editor (NOT a word processor).

Then go into accounts maint (option 2) and select option 6 - Import the
chart
You will have to respond to the question about over writing the original
file (if it exists)

So enter Y then and assuming the file name is the same but change the
name to match and press enter.

You will now have a set of accounts ready to use.
You should print the chart off so you have a hard copy of it.

Vince

On 25/04/17 03:51, iman wrote:

I installed IRS module only and succes.
But when I want to set up coa and press N or Y...the following eror
result...

Failure to Open Nominal-Ledgeerror code = 35

Anything wrong?

---

[iman]

I try to explain since I'm new in cobol...

0. Go to bin folder and type irs

1. Irs010 (3.01.11)

2. irs010 (3.01.11) Chart of Accounts Setup 26/04/17

Client - jaya selalu pt Start date - 01/01/17 End date - 31/12/17

Add to Existing Chart (Y/N) ? - [y]

N.B. (1) If first time setup for this client answer no (N)
(2) Answering no (N) destroys the existing chart

I choose Y

then error...
Failure to Open Nominal-Ledgeerror code = 35 Hit return to continue

3 working directory? Bin directory

4 Gnu cobol 2 rc2

5 Linux mint mate 18, 32bit

[Vincent (Bryan) Coen]

Think I responded to this but if not :

You MUST set up the CoA (Chart of Accounts) first and there are two ways of doing so.
For this see my previous responce on 25 April and follow it.

Basically using a simple text editor and having made a copy of the file elseware for safety edit the coa-archived-txt to match your requirements - this will mostly be change the descriptions but remember you are limited in the lengh of the field. When finished save the file and print it out and re-check what you did making any changes as needed.

Then follow the notes of 25th April and import the chart from this file.

The other option is to create the chart from scratch using the CoA entry program but be warned this can be a long-winded process. That is way the import system was created.
This was mostly for accountants and book keepers who have to run irs for many clients and so they can create or modify the supplied one creating different files that handle (for example), Limited Companies, Sole traders, Partnerships etc.

This way they select the right one for the job when starting work for a given business. Now for a business to use it for themselves they use the existing one or amend it to match their needs then import the file into the system and in this case you hopefully only do it once.

Regardless you should now print the Chart out so that you have a hard copy of it as well as checking that it is correct.

Adding new accounts into an existing chart is easy but chaging an existing after posting have been entered is a pain to deal with usually fixed by editing existing postings to have the adjusted and now hopefully correct account.

It is best to avoid having to do this as it is a bit of a time waster :)

[Vincent (Bryan) Coen]

Update on progress:

Well not a lots been done why well when coding Purchase Ledger I noticed a possible major error when processing invoices and that includes the OTM2 & 3 (Open Item) files where it could be working on the wrong copybooks / storage areas.

I need to go thought all of them in all programs that process these invoice files and check them.

Once that is done I can relook at Purchase Ledger and fix those that are done already and make sure I do it the correct way for the rest.

Am I sure that there is an error ? NO but it is best I sort it out now.

Problem has been as there have been a few system and life things that have stopped me working on it but will be getting back to the job shortly. System wise involved upgrading the system to use a SSD for Linux and it has produced some interesting problems mostly my own fault when trying to use another Linux Distribution other than Mageia. Needless to say both distros that I have tried (PClinux and CentOS) are problematic - and thats putting it mildly.

For thoese user who are playing with the current development system can I remond every one that you should be using in the first instance the Cobol file process only so that for each of the systems/ledger used you have a full set of data and when you are happy with that and then back the lot up you can start to use the Mysql system to replace it having run all of the Data Load programs AND produce print outs that you can compare agains the Cobol file reports to confirm that they are exactly the same. <<IMPORTANT>>

Now you can play with the database side of things.

Now one program that I have not yet worked on - waiting until I finish with Purchase Ledger is XL150 and this is the end of period processing and although it is more likely to work with the Cobol file processing there is a few error messages being produced when compiling it as they copybooks have been changed and these are not synced up for this program.

This will affect all statistics used in sales, purchase, stock to one point or another but once sorted out the systems will go back to normal. This does not affect the way each of these systems work other than the stats but sales & purchase the old (paid) invoices will still be in the system and there fore the files will be larger than they need to be.

For modern system with 1TB and larger drives - hardly a problem.

More later.

[Vincent (Bryan) Coen]

Update report (short):

Got back to working on ACAS and going through sales and yes did find a small number of issues and totally down to me using wrong files/tables. Must stop working after 21:00 :(

So sales is complete with more changes to provide better support for multi user mode subject to testing of course, as none done yet.

Now starting on Purchase and rechecking what has been done. as well as adding in logic from Sales that also has to go in.

The nightly builds from my website is being updated with all changes every night at 00:01 local UK time (UTC+1 summer and UTC+0 winter).

Remember the nightly builds is only the current status of the v3.02 source tree.
So some compiles of elements may well fail one way or another with warning or error messages.

Another point to remind people grabbing these is that the mysql libraries MUST be present to compile cleanly (may be) even if you are only running with Cobol files but as they will not be called you should not get a runtime error. This means that you need to install the client libraries and the include headers which most if not all distros have in the repositories but that said I got my headers from the Oracle website and that seems to be working but am using the repo client libraries that match the version of Mysl / mariadb I have installed.

Another bonus is that the headers fwork for both Mysql and Mariadb as I run both.

A point or two for those testing or running the current version:

1. Make sure you ARE running the current version which is v3.01.07.
2. Read the manuals for set up and operations in this order regardless of what sub-system you are playing with :
   A. IRS
   B. Stock
   C. Sales but be aware that this is very incomplete and contains details later in it for a very old version that is not compatable with the current one but it should be apparent where as the information is un formatted and contains the old editing controls from the tex formatting system.

On the above it is very important that you follow the set up processes such as
System Parameters
Analysis records
IRS ledger (chart of accounts) even if it is only the supplied default one for businesses.
and if you are going to produce invoice als Stock set up with some stock but don't forget to have quantities for each one as the Invoicing programs cannot produce an invoice without them, funny that can't sell what you do not have :)

Also remember to run back ups after each run but the supplied scripts will do that if running under Linux, OSX, *nix, but if you are using another operating system you will have to create the .bat or .cmd file yourself.

Please read the preseeding posts here as many are still valid.

More when I have it.

[Vincent (Bryan) Coen]

As of today I have finally completed updating the system over to use both Cobol files or MySQL/ Mariadb tables.

Now unit testing from start to finish using Cobol files to ensure that this still works before moving on to RDB unit testing.

All testing will be using Linux only.

The current nightly builds of source code should create a workable system at alpha status.
Along with the current MySQL ACASDB sql set up file.

If I have missed any needed files please advise.

If you wish to help out, make sure you create at least two new users, one for testing the Cobol file system set up and the other for MySQL RDB but Cobol files first.
Ensure that the old data files and programs are totally seperate from the new system as there is some differences in data files namely: Open item and invoice files for both Sales and Purchase ledgers - there might be some others that I have forgot. Once the system has been tested some what, I will create some upgrade/convert programs for the data files that have changed.,

[John Grillot]

I'm curious how cobol files compare to mysql performance. I'm sure in the case of your software it would make little difference. What is the largest number of users and file sizes are you aware of for clients using this software? I've supported other software packages where we have 20 users & the micosoft sql sever database size is several giga bytes. the speed of sql server databases are impressive. I worked on a IBM mainframe in the 80s. I guess that the cobol files must have used DB2 and the file access was exteremly fast. I never saw any stats on how that compares with modern sql databases.

[Vincent (Bryan) Coen]

I have/had large users for ACAS but not all used all elements however the gain for RDB over Cobol files is that the rdb handles a number of users using the system at the same time a lot better than using the Cobol file system.

Performance wise Mysql like most of the RDB system seems to be fast but clearly using files on users system is a little quicker but unless you are running a large ledger system say 1,000's of sales and/or purchase ledgers customer / suppliers you won't notice any difference. IRS or even General again unless it is a large nominal and here I mean 10,000 nominals etc for a large company again difference is not noticable.

The primary benefit is for multi users all working at the same time say where different users are concurrently using the system for each of the ledgers and may be more than one for sales & purchase which is highly possible.

For small / very small businesses where only one user ever uses the system this is not relevent but here the key is back up and security where the RDB will win out - assuming of course you set up back ups for the application database on a regular basis, say hourly to daily depending on needs.

In my case backs up are done always at midnight and after any major processing e.g., end of cycle (well before in this case - just in case of significant issues such as a bug sitting some where or more likely a hardware failure during EOC) .

EOC = End of Cycle which can be weekly, monthly or quarterly depending on how the system is set up - Most users seem to use monthly and quarterly cycles.

Back to the RDB upgrade I still have to work on the end of cycle program for RDB processing and may well do some minor tweaks to the way it works.
This applies to Sales, Purchase, and may be Stock - have forgotten what is done.

ACAS at least for Cobol files runs a back up after exiting the system or sub-system and as set up does a rsync with the output file having the date/time as the filename so it is up to the user to manually rename it if a significant process has occured such as end of cycle or end of year - pre or post and this is what I do.

I clear down every few months all un-needed back ups or when I remember to do it as the total amount of space used is not a lot as it is compressed.

For small businesses it is recommended to use IRS over General as the later is designed for busineses that need ledger function for Departments, branches and not many have that as a need but it is a pain to use when this is not the case so IRS is the better product and its flow, output can be passed on to an accountant for end of year accounts and the tax people (HMRC for the UK)..

At the moment IRS does not do automatic transmission for VAT returns as it seems to be a bit complecated and may well require updates from year to year and the O/S (Open source) model does not justify the possible work involved where no income is generated but a commitment is required from myself. I will have a think on this after completing testing of the v3.02 release but will depend on how many users say they could use or need the facility.

[Vincent (Bryan) Coen]

Oops, spotted that I had forgot about the General ledger system, so I am updating that as well while I remember what has to be done but that one will need more testing along with some coding changes I am sure so testing will be delayed while I sort it out.

[Vincent (Bryan) Coen]

General has been completed but it archives the postings every quarter and I don't like that so will look at changing it to keep them until end of year. This will be in line with the way IRS does it.
In any event it allows the system to do a check by rerunning all posting to see if they match totals in the nominal a/cs, the same way as in IRS.

[Vincent (Bryan) Coen]

Over the next few weeks I will upgrade the code repo to move the existing code to a v3.01 branch and create a new v3.02 for the new version.

It would be helpfull if users can advise if they will need file convert program/s to update the invoicing files over to the slightly changed layouts - there might some other files so I will have to check on this one.

In any event some of the files were sequential and have been changed to ISAM to support the move to RDB.

[Vincent (Bryan) Coen]

I have now refreshed the code base creating
trunk/v3.01 and
trunk/v3.02

V3.01 hold the previously existing code base that sat on SF for release v3.01 at build 7, but have not checked that it is at build 7.

In the next few days I will be adding the code base for v3.02 as soon as I have finished the end of cycle program xl150 that sits in the common directory. Coming to think about it, I might do this before finishing xl150.

Remember that the 3.02 release version is at stage Alpha - Not Tested.

IF you wish to play with it, please do so using the Cobol file settings as that is the first group of testing that is needed to confirm that it still works as in v3.01.
A lot of this testing will also help to pre-test some of the code that also plays with a RDBMS system but prior to actually doing so.
Any bugs found even if you are not totally sure still report them in the bug tracker.

Once I have finshed it as used within the menu system I want to adjust it to work as a program that can be called with arguments to tell it what to do so it can run as a task using cron, crontab at the end of each month and/or quarter as EOC (End of Cycle). I will think about it also doing EOY (End of year) as their may well be possible issues doing so.

At the same time I will modify the backup script at least for Linux, that will run both before EOC/EOY and after creating a archive file with the same format filename but with the text of Pre-EoC and Post-EoCand likewise Pre/Post-EOY.

There is an issue for backing up a RDB using the script system as it will need admin/root rights to run a SQL step for back ups to a given file name, etc.

Not impossible but a bit tricky.