Michael S (already5chosen@yahoo.com) on 3/4/08 wrote:
---------------------------
>
>What is a standard source management solution under MVS? Why it wasn't applicable in your case?
>

The one in use was an in-house written solution. Most source management solutions are more 'production control' than commercial code management.

Production control would be a situation where an IT shop has developers who make changes, and then deploy the change to the users. Everyone runs the production code at whatever level IT deploys it. So you don't have to worry about users running different levels of code. When you get a dump to debug, you only have to keep the current level of the code.

In the commmercial environment under MVS, users may not have certain fixes applied. So, we had to be able to keep the listings for every version of a module. In our environment we ship a new object every time we make a fix, even if a single line of code has changed. Obviously, some macro changes require reassembly of multiple objects. So, when a customer reports a bug, we have to be able to find the specific listing for the level of code he/she is running.

This is important in the MVS world, because a big part of the cost of software is 'maintenance' - which essentially means the vendor will 'guarantee' to fix any serious bugs you encounter. For a 'shop down', the guarantee is that it will be fixed in hours (or at least, a workaround will be given to get you running again). We have 4 defined levels, or severities. Therefore, it is absolutely critical that we have access very quickly to the specific level of code the customer has (source, macros, object), and that we can reassemble it.

I guess the main issue we faced wasn't just source control, but research and recreation. We have to be able to quickly identify what level of code the customer is running, and match it to what we have shipped. This is where the original source/change control system failed - we were getting in dumps where it was very difficult to find the source/listings for, and in some cases it appeared to have been lost. In a shop down situation, that could cost us very big bucks.

The new one tracks every change by its fix number. The published fix has an ID, which is embedded into every object module. The file it is stored under is named with the product code and fix ID, as well as the various pieces (JCL, panels, tables, source, macros, object, listing, etc.) all together. It moves/tracks all of these together from development thru testing/QA/publication, and guarantees that changes are serialized because it is possible that multiple technicians are working on the same module or macro (or other piece), and we don't always have the luxury of being able to spend time sorting out what changes should be included when shipped to a particular customer - it has to be correct (particularly in a 'shop down' situation).

So, we really have two processes - development and maintenance. Development is similar to what most people are familiar with - people work on the code and test it until it is considered complete. You might have multiple people working together, and you have to retrofit changes in from multiple people. But you generally have time (possibly weeks, or even months) before anything has to be delivered to a customer. Maintenance is sort of like being an EMT. You have to keep the customer alive long enough to get the real fix in place (which *could* be your fix). But in our case, we presume that if the bug hits one customer, it could hit anyone - so as soon as a fix is verified to have helped one customer, it is 'published' so any customer calling in has access to it. This is why it is critical to have all documentation for *every* fix - you never know what a customer might have on their system when he/she calls in for service.

Regards,
Dean