CC:Exception Concepts

Exception Concepts

What are exceptions

Exceptions are IBM i commands or programs which have to be executed at a specific point during an Object Transfer when certain conditions are true.

Although TD/OMS contains most of the functionality to manage your software changes, every company has its own specific procedures.

One way to handle these company procedures would have been to extend TD/OMS with all the necessary functionality that any company may need. This would have made TD/OMS a lot more difficult to implement, because the number of parameters would have grown extensively.

TD/OMS provides you with another way of implementing your company procedures; The exceptions.

Exceptions are your own commands or programs executed during an Object Transfer function at certain points of the processing. The definition of these exceptions has to be done by the application manager. Once the exceptions are defined, TD/OMS will execute them automatically and check the result.

The persons, who are actually starting an Object Transfer process, do not need to worry about these exceptions. They are not allowed to change the exceptions being executed.

We thus achieve a great flexibility in a controlled way.

There is another advantage to the exceptions. If new functionality is necessary in TD/OMS, because of interfaces with other products or because of any other reason, you do not need to wait for a new release of TD/OMS in order to work with that functionality. A new function can be implemented first as an exception and later it will be built as a standard feature.

A good way to experiment with the exceptions is to define some SNDMSG (send message) commands as an exception. They can do no harm and the processing of the exceptions will be obvious.

What are exception functions

An exception function contains the definition of the function itself. The function definition contains no information about when the function must be executed. This information is stored in the exception selection definition. An exception function can be defined as a single command or a program to be called.

In a command you can use substitution variables which will be replaced by TD/OMS at the time of execution with the actual values. The exception function

SNDMSG	MSG(’##OBJC is copied from ##FROL to ##TOOL’)
	TOUSR(MYUSER)

Will result at execution time in a message send to user MYUSER e.g.:

"PGM01 is copied from DEVLIB to TESTLIB"

Any valid command which can be executed during Object Transfer can be defined as an exception function. One special TD/OMS command can only be used in an exception function. This is the CHGVAROMS command, used to change a list of internal TD/OMS variables during object transfer processing. With this command you can for instance change the target location which is automatically retrieved by TD/OMS from the environment definitions. You can only use the CHGVAROMS command with the previous interface levels *V2R1M0 or *V3R0M0.

Exception Programs

If a program (also called exception procedure) is defined in an exception function that program is called at the time of execution with a predefined parameter list. An example of such an exception program can be found in file QUSRSRC in your TD/OMS library.

The use of programs as exceptions is preferred if specific messages are to be monitored or if a number of commands are to be executed in a related way. The TD/OMS commands PULLVAROMS and PUSHVAROMS can be used in an exception program to retrieve or store some TD/OMS variables.

In addition to the command or program to be executed, an exception function also contains definitions about the importance of the function (critical or not critical) and at what address the function has to be executed (local, remote or both).

What are exception selections

An exception selection actually activates a predefined function if certain conditions are fulfilled. Each exception selection contains the following information:

User Exit Point

The user exit point (UEP) specifies the exit point during Object Transfer. Exit points are predefined at the start of an object transfer, at the end of an object transfer, at the start and end of the creation of an object, at the creation of an object itself and just before the removal part of the processing procedure.

Sequence

You can specify the sequence of this selection related to other selections for the same objects.

Function

The exception function to be processed.

Conditions

The condition under which an exception is to be executed. Selections can be made on object code, type, attribute, the from location and the to location.

Each application has its own exception selections. The definition of these selections can only be done by the application managers.

What are system exceptions

System exceptions are exception functions defined in one application and available for use in any other application. The use of system exceptions helps you in maintaining the definition of the function. Some additional rules apply to these system exceptions.

A system exception is owned by the application where the function was defined. Such a function can only be changed by the application managers of this application. TD/OMS will also check that the function id of a system exception cannot be defined in another application.

Why exceptions should be used

In fact the question is: What do I need and is this not a standard function in TD/OMS?

You will next find a list of possible use of exceptions. In general you can use the exceptions to further optimize your implementation of TD/OMS in a step by step approach. You start with a standard implementation of TD/OMS and when the time suits you, additional optimization of the object transfer process can be performed.

Changing of Object locations

The location of an object is specified by its object type and attribute. If objects are to be placed in a non standard library you can use an exception to change that location.

Differences per environment

If for instance programs must be optimized when they are created in the production environment you can define the CHGPGM command as an exception function and execute it after an object has been created in the production environment.

Procedural functions

If you use exceptions you will be able to process additional procedural functions, e.g. informing end users about replaced objects.

What about exceptions for remote addresses

If you are using the TD/OMS distribution and receive modules, there are two ways to work with exceptions meant for a remote address. The choice between them depends on the answer on the question: Who is responsible for the definitions at the remote address?

If the users at the remote address are responsible for the processing on that machine and they have a (delegated) TD/OMS or application manager, the exceptions are defined at each address by the responsible application manager. The sending address will only define the exceptions for its own address.

On the other hand, if a central department has overall responsibility for the change management process, the exceptions can be defined in the central machine both for local and remote processing. The maintenance of exception definitions has to be done on that machine only. The distribution definitions must be set to include the exception definitions if objects are sent to a remote address.

Note: TD/OMS will keep track if exception definitions are added or changed at a remote address. Once they are ’locally defined’ they will not be updated automatically.

Exception Substitution Variables

These variables can be used in command strings included in exception functions. Some variables are not filled during the transfer process due to various reasons.

• Request and Release
  These fields are only filled when a transfer process is started from a Request or Release level (see use of TFROBJOMS) . To obtain data of the release in an exception or action use OMQRTVAP API for the current release number or the OMQRTVFI API for the release number assigned to this fix. To get the request number of a fix that is linked to it, use the OMQRTVFR API.

NOTE: Starting from V7R1 you should always use the single & character as variable field prefix instead of the former, double ## notation as prefix symbol. The # character can cause problems when your system language codepage is not CCSID value 037.

Variable	Description	Notes
##ACTO	Actions output
##APPC	Application code
##CATT	Attribute conversion type
##CATS	Attribute conv. scope
##CAUT	Authorization conv. type
##CAUS	Authorization conv. scope
##CHGX	Object Change date
##CJOT	Journal conversion type
##CJOS	Journal conversion scope
##CNVT	Data conversion type
##CNVS	Data conversion scope
##CPGL	Conversion program library (preferred)
##CPGM	Conversion program name (preferred)
##CROB	Related object code (preferred)
##DTLC	Detail code (preferred)
##EXCI	Temporary or virtual object indicator
##ERR#	Request number
##FDIL	Length of From directory
##FDIR	From directory
##FENV	From environment	preferred
##FIX#	Fix number
##FIXR	Replaced Fix number
##FLBI	Fall back indicator
##FPTH	From path
##FPTL	Length of From path
##FROL	From object library
##FRPL	From environment
##FSRF	From source file
##FSRL	From source library
##FSRM	From source member
##IOBC	IFS-object
##IOBL	Length of IFS-object
##JOB#	Job number
##LBLT	To library list type
##LSQ#	To library seq#
##MBRC	Detail code
##MODB	Based-on modification
##MODR	Replaced modific.
##MOD#	New modification
##OBJA	Object attribute
##OBJC	Object code
##OBJR	Replaced object ind
##OBJT	Object type
##OBJX	Object source change date
##OCLS	Object class
##OPTI	'M'=Move 'C'=Copy
##OVRC	Override code
##PGML	Conversion program library
##PGMN	Conversion program name
##QTPI	Quit Processing indicator
##REQ#	Request number	Preferred, not filled when during normal transfer
##RLS#	Release	Not filled during normal transfer
##ROBC	Related object code for conversion
##SEQ#	To library list seq#
##SOLT	Solution type
##SRCF	To source file
##SRCL	To source library
##SRCM	To source member
##SRCP	Source Processing
##SRCS	Source status
##SRCX	Source source change date
##SRTC	Sort code
##STAT	Status
##TDIL	Length of To directory
##TDIR	To directory
##TENV	To environment	(preferred)
##TFRC	Transfer code
##TOOL	To object library
##TOPL	To environment
##TOVI	Temporary or virtual object indicator	(preferred)
##TPTL	Length of To path
##TPTH	To path
##TSB#	Transfer sub-number
##TSRF	To source file	(preferred)
##TSRL	To source library	(preferred)
##TSRM	To source member	(preferred)
##VRSB	Based-on version
##VRS#	New version
##VRSR	Replaced version