As defined by Wiki - A naming convention is a convention for naming things. The intent is to allow useful information to be deduced from the names based on regularities. Well-chosen naming conventions aid the casual user in navigating larger structures.

Control-M batch streams are no exception to this fundamental need to quickly identify the use of the job in question. Below are some examples of commonly used, but by no means the only way to accomplish a standard. First there is an obvious old style naming convention carried over from the mainframe days. This standard can be used for distributed system batch, but not necessary.

Mainframe

Location(1), application(2,3), schedule(4,5), sequence(6) and function(7,8).

1. Location is single character for which LPAR (or unix, windows, etc. if distributed systems are used with this convention)
2. Application has two identifiers and is pretty self-explanatory
3. Schedule has two characters, DL for daily, WK for weekly, etc
(I think this is over kill and can be reduced to one character)
4. Sequence is pretty simple, numerical order of similar jobs
5. Function is just what it implies, BU for backup, EX for extract, etc

Distributed Systems

Then there is the Control-M distributed world version which allows for more characters. However in an effort to maintain short and quick evaluation, we’ve made the naming convention as such.

Location(1), application(2,3), function(4,5), schedule(6) and sequence (7,8,9,10)

1. Location again is a single character, which also identifies the operating system (unix, windows, linux, AS/400, other)
2. Application takes the next two slots and again is self-explanatory.
3. Function is pretty simple and takes the next two spots.
4. Schedule is a single character which makes sense and saves room. (D=daily, W=weekly, M=monthly, U=unique,
   H=holiday, etc.)
5. Sequence order finishes up the naming convention with four characters. This is mainly because we’ve found there are more jobs in the distributed world. We start with two, but if needed we expand. So the last two are optional if you're trying to stand within the 8 character mainframe limit..   

Production vs other jobs

One other important thing to note, test environments have the same naming convention but are created in “lower case”. Anything in “UPPER CASE” is considered production and requires immediate attention upon failure or issue. Making the naming convention case sensitive helps to sort the “view points”, eliminating non-production jobs from the display.

Also, when building and testing the production jobs (or soon to be production), when testing we add in lower caser “qa_” prior to the upper case naming convention of the job. These can be quickly adjusted to remove the “qa_” from the naming convention prior to releasing to production. Again, this helps to sort the display utilizing the view point manager and separate production jobs from testing jobs.

Schedule Table names need their own naming convention to quickly identify the jobs associated with the schedule and it may utilize more characters to assist in identification.

Environment(1 t0 4 char.), application(3 to 6 char.), location(1 to 3 char) and frequency(1 to 2 char.)

This should be more then enough, but again it’s not limited to these. The idea behind it is:

1. Environment (Prod, QA, test, Dev) can quickly sort and identify
2. Application is understandable (CTM, Exch, Lotus, TSM, Oracle, etc.)
3. Location can be a physical one, (NY=New York office, U=unix, etc.)
4. Frequency is roughly when the schedule runs ( D=daily, H=Holiday, T=multiple)

Note that I specified “ T “ for multiple schedules in a table. Keep in mind the identifier can be anything, could make it MU=multiple. Point is to make a standard and stick to it.

Application naming convention should resemble the scheduling table name. This will make things easier when you need to load a schedule and the requester only knows it by the Application/Group name seen in the GUI. They typically don’t consider the Scheduling Table name of any great importance, until they need you to run it out of it’s normally scheduled time frame.

Group naming convention I feel is best broken down to functional areas. The application may have maintenance jobs that run, putting them into their own "Maintenance" group is helpful. Streams that are independent can be placed in their own group(s). Day time streams from night time streams. Large schedules that may benefit from separating into phased groups (Phase1 should complete by “X” time.)

So how do we put it all together and what reference can a new "Scheduler" use to understand the naming convention?

“Decoder Rings” are a helpful tool and a web based decoder is a great place to put it. If you’re savvy enough you can build one with funtionality around it or flat. You can use Word, Excel, etc. to convert to html.

Here’s an example on how to create a Naming Convention decoder in Word (click here) .

Conditions perhaps the most critical aspect of the naming convention that is often over looked is the IN/OUT conditions. The standard that works best for navigating the GUI and the job stream is JOBNAME-to-JOBNAME. When building the Control-M Desktop Skeleton Condition Format, it should look like this:

{Job Name}-TO-{ToJob{Job Name}}

This will allow for quick up stream review of the predicessor job(s) and if you're bold enough to build your own flows, the data feeding your query can be built using conditions.

Another aspect of the conditions naming convention is the Global Conditons. Assuming you have more then one Control-M server, you should consider adding a prefix to your conditions. This will assist you in making sure certain conditions work across servers. This prefix can be any number of things, as long as it makes sense to you and your orginization and of course standing by that naming standard and enforcing it's use.

USER_DAILY I know it's debatable, but I think it warrants mentioning that eveything should not be listed as "SYSTEM" in the USER_DAILY (UD). The only schedules/jobs listed as SYSTEM should be those jobs that load the rest of the schedule. At this point you can go crazy and have a bunch of UD jobs or make it simple and have one or two UD jobs to load the schedule. The point is to make a standard that works for you and your company and stick to it.

It's a helpful little tid bit of info I hope you can use.