Menu

Tree [r1] /
 History

HTTPS access


File Date Author Commit
 ACAS-Manuals 2023-07-28 vcoen [r1] Initial commit
 Experimental-Stuff 2023-07-28 vcoen [r1] Initial commit
 common 2023-07-28 vcoen [r1] Initial commit
 copybooks 2023-07-28 vcoen [r1] Initial commit
 general 2023-07-28 vcoen [r1] Initial commit
 irs 2023-07-28 vcoen [r1] Initial commit
 purchase 2023-07-28 vcoen [r1] Initial commit
 sales 2023-07-28 vcoen [r1] Initial commit
 stock 2023-07-28 vcoen [r1] Initial commit
 1-README.TXT 2023-07-28 vcoen [r1] Initial commit
 Changelog 2023-07-28 vcoen [r1] Initial commit
 Dykegrove.sh 2023-07-28 vcoen [r1] Initial commit
 README.SVN 2023-07-28 vcoen [r1] Initial commit
 README.nightly 2023-07-28 vcoen [r1] Initial commit
 acasbkup-Post-EOY.sh 2023-07-28 vcoen [r1] Initial commit
 acasbkup-Pre-EOY.sh 2023-07-28 vcoen [r1] Initial commit
 acasbkup.sh 2023-07-28 vcoen [r1] Initial commit
 comp-all-diags.sh 2023-07-28 vcoen [r1] Initial commit
 comp-all-no-rdbms.sh 2023-07-28 vcoen [r1] Initial commit
 comp-all.sh 2023-07-28 vcoen [r1] Initial commit
 dykegrove.sh 2023-07-28 vcoen [r1] Initial commit
 install-ACAS-preinstalled.sh 2023-07-28 vcoen [r1] Initial commit
 install-ACAS.sh 2023-07-28 vcoen [r1] Initial commit
 presql2-222.zip 2023-07-28 vcoen [r1] Initial commit
 prtpdf-A4.sh 2023-07-28 vcoen [r1] Initial commit
 prtpdf-Letter.sh 2023-07-28 vcoen [r1] Initial commit
 prtpdf.sh 2023-07-28 vcoen [r1] Initial commit
 readme 2023-07-28 vcoen [r1] Initial commit

Read Me

This readme file is supplied with the ACAS-nightly builds.

Also read README.SVN for more up to date information and how to build information
and details of specific code changes by system.
Note that individual programs have their own change log within the source and
this is near the start of each and here it is by date and version and build numbers,

The nightly builds are created every night at midnight or there about with
the ACAS source code for the new release v3.02.

This is the release that supports RDBMS along with the normal Cobol file
processing.  Currently only MySQL is supported.

Updated - again 03-03-2018.
With updates from 10th Feb 2018 including as of 29th January 2018.
With the completion of XL150 the SL & PL End of Cycle processing module all base
programming has now finished and testing can start.

Of course during testing bugs may be found that involve some coding changes.

All initial testing will use Cobol files and this for three reasons:

1.  There are load programs created to transfer data from Cobol files to tables
    with one load program per file but not the other way round. Many of these
    programs have been tested with test data but not all.

    This has helped to test many of the FH (File Handlers) on open, close, read logic
    and the DALs (Data Access Layer) that control access to a table and have also had
    some testing for open, close, write, rewrite logic.

2.  Existing system flows using files have had (hopefully) minimum logic changes and
    this will help for system testing.

3.  Reduces time for testing as work within MySql is not needed.


That said, when compiling ACAS v3.02 it WILL require that you have installed the MySql
or mariadb client package so that the its routine hooks can be found by the linker which
is called by the Cobol compiler after compiling the resultant C code.

It is a recommended practice to also install the MySql server service as well.
This is regardless as to it being used.

This has now changed as there is new scripts to build a non rdbms ACAS system so use
comp-all-no-rdbms.sh instead of comp-all.sh and therefore the need to install Mysql
is removed.

I have created a module that can be used in place of the RDB libraries that just have
the entry points for the DAL modules that in turn call RDB libraries. Hopefully this
way users can test Cobol only system without having to install MySQL or MariaDB server
and client libraries.   HOWEVER I have not tested it yet - (in progress).

In-house testing platform actually uses two or more drives, the first is a SSD and this
is for booting the O/S (operating system) along with its components but as there can be
more than one version of the O/S present of the SSD - often three or more so that the
second drive which is a hard drive contains all of the user areas mounted as /home.

For this reason the Mysql parameter file that sits in /etc as my.cfg is changed to use
a different directory point for the databases etc from /var/lib/Mysql to /home/Mysql.

This way, regardless of the version of Linux in use the data in use for MySql is always
the same. NOTE - This is based on the fact that the SAME version of MySQL is always
used.  VERY IMPORTANT POINT. As different version may not have the same system
structure or content.

SO in a nut shell even compiling for only testing Cobol files you MUST have installed
the MySql (or mariadb) client package.  See the experimental module called
dummy-rdbmsMT.cbl.

This module just has a entry point for each of the DAL modules.
I HAVE NOT completed ANY TESTING WITH IT SO FAR. In progress.

A bit of background in the way the various ACAS sub systems work :

In all cases (using Cobol files or tables) the system will start by reading the Cobol
parameter file and this consists of four records :
1.  Parameters for the entire system, IRS, GL, SL, PL, Stock etc.
2.  GL Default record. - Used or not.
3.  Final Account settings record holding new description for 26 headings for GL
    but not implemented - No one has requested it so on the back burner.
4.  Sales and Purchase ledger totals for this and last month.

Records 2 and 3 may not be used depending on system settings in record 1.
All cases there is only one record for each type and yes records 2, 3 & 4 could be in
a file of their own but as they are only one record for each it is in the system file.

Having read in each of these records, the systems checks if RDBMS is in use having looked
at record 1 and if so re-reads the RDB tables for each of these records over writing the
Cobol file records.
THIS HAS NOW CHANGED (24/04/18) and will not read system tables as not needed because the
cobol file will always be present and be maintained but will update tables at EOJ. See
next block.

At the end of processing for any of the sub systems (Sales,
Purchase, Stock, IRS etc) it will write out all of these records to the Cobol systems
file and if used, the RDB tables.  This is to ensure that both are always up to date.

Clearly the Cobol file parameter system record must always be used at least initially
to determine what data system is being used and if rdbms, what system setting to use to
access it. A copy is therefore also made to the rdb system table to match.
This is to future proof the process as it may be changed in that the system parameter
file is not need if using RDBMS as a file can be used to read in the rdbms connect
information, how ever as there is password information present this might be a
security risk if user sites do not fully make use of multi Linux users who can run
specific elements of ACAS and correctly set the file attributes to prevent users
reading this file. IT would involve being very specific on these attributes.

Hopefully the above background helps to explain the logic of needing the RDB client
routines being present within the ACAS executables (programs) as in some cases the O/S
will complain when loading the ACAS programs or modules that the linked rdb client
routines are not present.

WITH the creation of the dummy module and separate build script see above, this
is no longer required.

My order of testing both by system logic / requirements and minimum changes made for
this update :

1.  IRS - Data needed by the other system to post data to for accounting and audit.
    Here using the default CoA (Chart of Accounts) file that is included with the
    ACAS distribution including the nightly build. File name is coa-archived.txt
    This is a limited type company set of accounts suitable for most businesses of any
    type but will require some fine tuning to suit an individual business but good
    enough for testing. This is a text file that can be edited (having made a back up
    first) to change if needed, see lines starting with :

    T00145002450A - Dividends

    through to

    T00145002545D - Dividends

    Where A to D can be changed to directors names.

    Likewise
    T00186002860Dir - A

    through

    T00186005860Dir - D

    Also look at lines starting :
    T0017900
    T0018200
    T0019300
    T0019900

    Unless you need to change the descriptions of any others just leave them as is,
    as if there is no data posted to any they will not print out except when printing
    the full CoA. This said you might want to add some new entries both nominal
    and sub nominal accounts.

    For reference the supplied CoA can be used as a model to create bespoke versions
    for various different types of organisations such as limited liability
    (as supplied), sole trader, partnerships, charities, local governments such as
    parish councils.

    For testing purposes the current settings are fine unless your country requirements
    require it.

    This file is used to create the CoA using IRS through menu options -
    3->6 (Import  the Chart).

    This will save you having to enter a lot of chart entries.

    Don't forget to specify in the system params that you are using IRS (setting Y or
    B for Both).  IF set to B (both) then the same and purchase system will create
    posting records for each system IRS and GL even if you are not going to use one
    for a short time.  Note that here when using both you will have to be very careful
    to make use of the same account numbers for both that applies to the same type of
    account - allowing for the fact that the account number for GL can be 6 digits
    again IRS using 5 (exclusing leading zeros).

2.  For both Sales and Purchase, set up the analysis codes the default ones will be
    created even if no others are set up but you may want to set up 2 or 3 for each
    ledger. If nothing else to check that analysis processes are working.

3.  Stock, create some stock - Here I will raid the kitchen cupboards for cans and enter
    these as stock products as all have bar codes and it is easy to create abbreviated
    codes for them.  Later you can enter a few WIP type products such as ready made
    meals - Oh, beef, peas, beans, vegetables etc where each has a specific weight amount
    used for a set meal such as 30 gm's ?

    If you don't like this as an example use you own but remember each element must be
    created as a stock item in their own right before creating the end product.

    One of the uses that some stores utilise this function for is where products arrive
    in volume such as Cans of baked beans 60 to a case where the can has a bar code and
    the case holding them also has a bar code that is not the same as the individual cans.

    In this case by accepting in a full case of 60 the system will end up registering
    all 60 cans in one hit. This needs to be tested any way.

    During this you will have to create in conjunction with Purchase Ledger some
    suppliers for each stock product but create at least two per stock item.

4.  Sales ledger with invoicing, create some customers say 5 - 10. create invoices 1 -3
    per customer, proof, print, post. Do same a little down the line for payments on
    some.

5.  Purchase ledger do the same for a few suppliers linked to stock vendors/suppliers.
    Raise some orders against stocked items.

Well that will do for initial testing.

=======================================================================================

As of 11th January 2018.
With pl180 - pl960 completed All programs have now been converted to use RDB / Cobol files.

That was the easy bit - Next week for unit testing and some manual updates as I go along.


As of 10th January 2018.
The ACASDB.sql has been updated with new structures and 1 or 2 replacements for
PUOTM5-REC PUINV-LINES-REC PUINVOICE-REC. After these the following tables/s have been
dropped:

PUOIFILE5-REC,  So in sql or via Mysql workbench issue

DROP TABLE IF EXISTS `PUOIFILE5-REC`;

This will delete this unused table - it may not be the last.

I am working through Purchase Ledger system along with the source from Sales
and this has made changes to the sales ledger code at the same time of updating
Purchase ledger, i.e., found some bugs or other issue types.
At the same time changes are occurring to ./copybooks and ../common including new
individual build scripts that start with 'comp-'

I have said it else where but I will again - Do all initial testing using Cobol
files and leave testing with RDB till later. As there are load programs for each Cobol
file used in the system it is a simple affair to load the RDB from the Cobol test files
BUT NOT THE OTHER WAY ROUND.

More importantly testing with the Cobol files will help iron out any basic bugs.

If you find any bugs even with the nightly build please report them on the sourceforge
website using the bug tracking feature remember to specify the program version that is
the culprit.

Yes I will be testing but coding takes priority and all my testing will be under Linux.
At the moment when coding I am managing 4 - 6 programs per day but I am not coding every day.

As of now 23:00 (UTC) I am finished with purchase, pl000 to pl170.
So around 10 to go.

My comments of 2nd June are well founded as I have found problems with using the wrong
data areas - hopefully now fixed - so far but testing will find the rest.


As of 2nd June 2017.
Items for 27 & 25th still valid.
While working on PL (purchase) noticed I may have made some coding errors when
replacing FD's with a WS version for all of the Invoice files and there is a
smaller possibility for the other files within Sales as well.

This means that it is possible that the wrong WS data area/s are used to send &
receive data between processes or in other words garbage data.
There fore need to go through work done to check for this on invoice and
possibly all other files before restarting on purchase.

This needs to be done slowly to minimise risk of coding errors.

What should have happened is that for each FD copybook a new one is created but
without the FD statement as it will go into the WS area along with a redefines
for the pre-named group names used in the calls to the acas0nn modules etc.



As of 27th April 2017.
See least comments at foot of doc. for status on individual systems etc,


As of 25th April 2017.
Found a small bug in the param set up modules that shows up as not finding the
file - caused by 'assuming that opening a file as I/O would NOT create it if it
does not exist - it does. A GC change that I had not previously spotted.
They do not document the changes in any form of a clear process.

Some new code for PL010 & 015 but much more to do.

---

As of 21st April 2017.
Current history (but also see readme file for list of general changes) is
that the following sub system have been coded:

IRS      - A General/Nominal Ledger system that links with all elements
           coding complete and part tested.
Stock    - Stock Control/Inventory Coding completed and part tested.
Sales    - Sales Ledger/Accounts Receivable that links to stock minimal testing.
Purchase - Some coding but a lot more to do - Starting this week.
General  - No work since migrating code to GnuCobol compiler. NOT TESTED at all.



TODO:
Purchase - Coding the new FH & DALs to process files and RDBMS.
           Many of these are complete but there are 6 or so to do before
           changing the sources to use them and creating the missing load
           programs - See below for more info.

Manuals  - Need to go through Sales, IRS & Stock to update them and for Sales
           to include missing/incomplete sections including an updated
           information of each system and HOWTO for the Cobol compiler
           under Linux. User using Windows should go to the Compiler website
           for such information as I do not develop using it.
           Purchase manual will be formed in part from the Sales manual.
           General - When getting around to testing, this manual will be
           updated. How ever uses wishing to use this system should use IRS
           instead as it is easier to use and is geared for the smaller company
           that does not have a requirement for branch / Department processing.
           Monetary values are not less than 6 digits with many larger.

           ACAS System manual to be written using material from all of the
           others so that all system can be found within one document.

Note the nightly build archive is ONLY created (I hope) if there has been any
changes to the sources that result in a larger archive file. This should cover
most if not all changes but..

You are warned that this version has not yet been tested other than at a basic
level at most.

Programs that load the rdbms (MySQL or Mariadb):

Most have been created, done are Stock, IRS, Sales with some for Purchase.
The rest are being created as the missing FH (Cobol File Handlers) & DAL
(Data Access Layer for RDB) are built.

Tested Load Modules:
IRS      - Fairly well but not complete.
Stock    - Not complete other than basic unit testing.
Sales    - Same as above
Purchase - None and system update is not yet completed.

Note that at the moment these are all independent programs that in the main
load one table from one existing Cobol file. There are two (invoice file) that
create two tables.

There is NOT any process to reverse this, i.e., you cannot go from RDB to file.
So, it is recommended that any testing is done using the Cobol files for at
least one complete cycle making sure you have a back up after each data entry
process for all systems.  Then when you are happy that the Cobol file processing
works you can run the load programs (one at a time at the moment) for all Cobol
files that exist in your test/work directory.

I will later create a master load program that will call each of these current
load programs having created them as modules that will run each if its Cobol
file exists in the ACAS working directory.
This assumes that you have a working copy of MySQL running and that the ACAS
database has been created with a suitable user to access it and as set up in
the ACAS parameter system file. This file will ALWAYS exist regardless of using
Cobol files or RDBMS tables as it is needed to work out what system is being
used. In the case of this file a table is also used and this is the primary
location for the param data during ACAS running however the Cobol file is updated
with the current settings before ACAS terminates normally.

Nightly Builds comments:
By using the nightly build it gives you, the user a chance to look at the next
version very early on, but the code may well not be complete or tested.

Known compile issues as of 19/04/2017 :

Directory     	Name          	Problem

common		xl150		Produces many errors - Expected as not been RDB
 				updated. TO do after purchase completed.
				This program is responsible for handling end of
				period and cycle processing for most of the ACAS
				systems (not irs) so has to be done :)
purchase        sl020}		As above.
		sl040}

general 	All		Has not yet been updated for RDB or tested.

manuals		All		Still to be updated/rewritten but will do during
system and UAT testing.

                ACASDB.sql	This is a dump from my dev. system only running
				MariaDB  and can include basic test data with
 				the RDB structures and these are still subject
			 	to change as the outstanding DAL units are
				being developed that could mean changes to the
				row names and sizes.
				There might even be some more tables added.
				Depending on testing there is also another RDB
				system held on a OSX platform running MySql
				that could be added with more data present.
				If you will use these dumps using an editor
				remove the Data blocks saving the file to a
				newly named file and run that to populate
				your Mysql system. However it is strongly
				recommended you stick to using the Cobol file
				processing settings in the parameter file at
				least for initial testing that way you have
				data that can be loaded into the ACAS database.
				There is no process to do this in reverse.

Initial testing using the Load programs (but not all of them) has shown that the
F.H. (Cobol File Handlers) can open, close & Read data.
The DAL (RDB table Data Access Layer) can open, close, write, rewrite data to
the tables.

Clearly there is more testing needed for the outstanding functions of both
types and this would need to be tested within the applications and therefore
could result in bugs being found.

All file processing - both Cobol files and the RDB will create a text file in
the ACAS production directory where the system.dat file resides that contains
the history of all accesses to files and RDB tables and this is set by a switch
in one of the copybook files (Test-Data-Flags.cob) field is SW-Testing and is
currently set to 1. To turn this off set to zero. I do not recommend you do
this at the moment during Alpha and Beta functional testing.


Last updated: vbc - 27th April 2017.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.