[archive] Update program objects in live environment

[Migrated content. Thread originally posted on 13 July 2005]

Surely not a unique problem?

As a software vendor with 1000 platforms that need program updates from time to time (Unix and Linux), we need a safe way of updating the application via modem and VPN connection. Every platform currently has a shell script that will 'install' the objects after they have been down loaded via ftp/uucp into a 'receive' directory.

We have had instances where data files got initialized because a 'install' procedure was done in a live environment. Displaying messages for the users to log out before applying the updates does not work.

The application consists of many objects, called with and without cancel commands.

Objects are kept separate from data files with an entry in the cblconfig file to indicate the directory.

Runtime versions vary from 4.3 thru 6.2.

Systems are rarely rebooted as many users operate 24/7.

Any suggestions will be appreciated.

Ari V N
Cks Systems

Are you running your Acu application under Unix also?

If yes, your shell script could do something like:


RUNTIMES=`ps -e | grep runcbl | wc -l`
if [ $RUNTIMES -gt 0 ]
then
  echo "You cannot update - we TOLD you to log off all users!"
  exit 1
fi
{ do the update }

If the variable $RUNTIMES is set to a value greater than zero, then there are users in Acu applications, so the update is disallowed.

[Migrated content. Thread originally posted on 13 July 2005]

Surely not a unique problem?

As a software vendor with 1000 platforms that need program updates from time to time (Unix and Linux), we need a safe way of updating the application via modem and VPN connection. Every platform currently has a shell script that will 'install' the objects after they have been down loaded via ftp/uucp into a 'receive' directory.

We have had instances where data files got initialized because a 'install' procedure was done in a live environment. Displaying messages for the users to log out before applying the updates does not work.

The application consists of many objects, called with and without cancel commands.

Objects are kept separate from data files with an entry in the cblconfig file to indicate the directory.

Runtime versions vary from 4.3 thru 6.2.

Systems are rarely rebooted as many users operate 24/7.

Any suggestions will be appreciated.

Ari V N
Cks Systems

Thanks JoeD,

Sorry for not telling the full story. The menu option that enables the user to 'fetch' the update from us, is an acu program. The application also consists of various modules (one being a point of sale module) and the update does not always affect all the users. An update procedure that, for instance, only takes affect after a user logs out and back in again would be ideal. What I am not sure about, what will the affect be if an object with the same name but different versions, is run simultaneous by the same runtime? Is this perhaps the reason why we get data corruption?

Ari V N

[Migrated content. Thread originally posted on 13 July 2005]

Surely not a unique problem?

As a software vendor with 1000 platforms that need program updates from time to time (Unix and Linux), we need a safe way of updating the application via modem and VPN connection. Every platform currently has a shell script that will 'install' the objects after they have been down loaded via ftp/uucp into a 'receive' directory.

We have had instances where data files got initialized because a 'install' procedure was done in a live environment. Displaying messages for the users to log out before applying the updates does not work.

The application consists of many objects, called with and without cancel commands.

Objects are kept separate from data files with an entry in the cblconfig file to indicate the directory.

Runtime versions vary from 4.3 thru 6.2.

Systems are rarely rebooted as many users operate 24/7.

Any suggestions will be appreciated.

Ari V N
Cks Systems

Our programs are all individual object code files. We routinely replace them with users in the system (assuming it's not something version specific like a record layout change). The users don't see the new program object code until the program they are running is either cancelled or they exit to our menu system. The menu is executed with CALL PROGRAM "MENU" so the runtime is re-initiated.

brad

[Migrated content. Thread originally posted on 13 July 2005]

Surely not a unique problem?

As a software vendor with 1000 platforms that need program updates from time to time (Unix and Linux), we need a safe way of updating the application via modem and VPN connection. Every platform currently has a shell script that will 'install' the objects after they have been down loaded via ftp/uucp into a 'receive' directory.

We have had instances where data files got initialized because a 'install' procedure was done in a live environment. Displaying messages for the users to log out before applying the updates does not work.

The application consists of many objects, called with and without cancel commands.

Objects are kept separate from data files with an entry in the cblconfig file to indicate the directory.

Runtime versions vary from 4.3 thru 6.2.

Systems are rarely rebooted as many users operate 24/7.

Any suggestions will be appreciated.

Ari V N
Cks Systems

As Brad says, you shouldn't have a problem with updating objects as long as the new objects don't refer to different formats of the same index file.

However, another problem that can arise can be caused by changes to LINKAGEs.

For example, say you have a program A that calls sub-module B using a shared LINKAGE definition. If the linkage is changed, both A and B are affected. But if a 'runcbl' process is running and it has only loaded program A at the time you re-install the new versions of A and B, then the old A in memory may try to call the new B which gets loaded from the disk. If the linkage is a different size then the runtime usually crashes with an error, but if you have changed the 'meaning' of a field within the linkage, then B may not behave as expected.

Does that make any sense?

We have a lot of the same problems that you have, too. We have a lot of customers that are industrial (meat processors) working almost 24/7 on Unix servers. We treat LINKAGE changes with kid-gloves now after some rather unhappy experiences.

Along with our Index file record definitions, we try to have an area of FILLER at the end of a LINKAGE that we can 'eat away' at without disturbing the size (or format).

Hope this helps.

[Migrated content. Thread originally posted on 13 July 2005]

Surely not a unique problem?

As a software vendor with 1000 platforms that need program updates from time to time (Unix and Linux), we need a safe way of updating the application via modem and VPN connection. Every platform currently has a shell script that will 'install' the objects after they have been down loaded via ftp/uucp into a 'receive' directory.

We have had instances where data files got initialized because a 'install' procedure was done in a live environment. Displaying messages for the users to log out before applying the updates does not work.

The application consists of many objects, called with and without cancel commands.

Objects are kept separate from data files with an entry in the cblconfig file to indicate the directory.

Runtime versions vary from 4.3 thru 6.2.

Systems are rarely rebooted as many users operate 24/7.

Any suggestions will be appreciated.

Ari V N
Cks Systems

We are very aware of the file layout and the linkage restriction. If the runtime aborts with an error is would be fine. It is the instance that the runtime does not report any errors but a file gets initialized, that concerns me. Only a small percentage of a global update will result in data loss. I am waiting for the support department to report back on the platforms and runtime versions where this happened. It does seem to be in the 'busy' environments 40 users. The application does open and close files very intensively (historical reasons) and I don't know if that has something to do with it.
Acucorp has a 'meet and greet' seminar in our area today and I intend to discuss this matter if possible.
I am sorry to say that there is no doubt in my mind that the 'live update' was responsible for data loss in our case. Be aware of this. A lot of time and effort goes to waste when this happens.
What I did notice yesterday, is the fact that we have a mix of version 3, 4, 5 and 'converted RM' vision files, (historical reasons) present at the majority of our users. I intend to instruct the support department to rectify this situation as soon as possible.

Ari V N