Messages to trigger job scheduler Control-M by Datasets

[Ulrich Schmidt]

Hello,

we are looking for messages to trigger jobs by dataset creation. Our job-schduler Control-M relies on messages rather than on smf-records to get invoked. Unfortunately we don't get these messages from the ssh/sftp-process. It works fine for FTP (where Control-M uses a special apporach).

I thought we would be able to get those messages, if we run SSHD under control of COZBATCH. But I'm really not sure. May I ask you to have a look at the attached doc and make up your mind about it?

brgds,
Ulrich Schmidt


------------------------------------------------------------------------------------


The DSNEVENT process consists of the following parts:

1. When a job, or STC, or TSO user session starts, the system issues either the IEF403I
message or the IEF125I message. CMEM intercepts this message, and checks
whether there is at least one ON DSNEVENT or ON STEP rule for the job. If there
is at least one rule for the job, CMEM creates the DSNEVENT environment in the
address space.

NOTE
A job can only be handled by one CMEM. Therefore, in an environment where more
than one CMEM can be active, for example, TEST and production, you must be
accurate in defining the ON DSEVENT.


2. CMEM intercepts allocation, deallocation, and step termination messages, and
determines whether there is at least one ON DSEVENT or ON STEP event. If so,
CMEM determines
■ whether the DSNEVENT or STEP events fulfil the selection criteria in the rule
■ whether, in the case of a DSNEVENT, the file is a new file or already exists

NOTE
A DSNEVENT can be triggered only on the CONTROL-O/CMEM that runs on the
same z/OS system on which the event occurs. Even a focal CONTROL-O or CMEM
in a Sysplex environment is insufficient. This is because CONTROL-O or CMEM
intercepts the messages written to JESYSMSG while they are being written, which can
be done only on the same system where the event happens.


3. CMEM triggers the rule according to the following principles:

A. An ON STEP rule is always triggered when a STEP ends. However, a STEP is
ignored when a rule is not executed due to one of the following:
■ a JCL error
■ failure to encounter a previous step condition code

B. An ON DSNEVENT can occur when a deallocation message is written, or when
a step terminates. Whether it occurs depends on
■ how the file is deallocated
■ the setting of the STEPRC field in the DSNEVENT criteria, as follows:
—If the value of STEPRC is null, the rule is triggered at the time of deallocation.
—If the value of STEPRC is other than null, the rule is rechecked at the
termination of the step to ascertain the STEPRC criteria.

C. Deallocation occurs when
■ the file is dynamically deallocated
■ the step ends, in the case of all allocated files in this step, whether the files
were allocated by JCL or were dynamically allocated
■ the job terminates, in the case of any file that was not released on step
termination, for example, if DISP is set to PASS

For CMEM actions to be triggered in this way, the following conditions must be satisfied:

■ Either the IEF403I message or the IEF125I message must appear in the job log.
■ The job, STC, or TSO user session must have its MSGLEVEL set to (x,1), to ensure
that allocation, deallocation and step termination messages are written to the
JESYSMSG. It is not sufficient for these messages to appear only in the system log
or job log.
■ At least one ON DSNEVENT or ON STEP rule must be ordered and ready before
the job, STC, or TSO user session starts.

NOTE
If the value of ON DSNEVENT is * (asterisk), every job, STC, or TSO user session is
within the DSNEVENT environment. BMC Software recommends that you do not
use this type of DSNEVENT because of
■ the overhead that results from CMEM analyzing every message written to the
JESYSMSG
■ the CMEM limitation that only one CMEM can handle a DSNEVENT for a job
In an environment where more than one CMEM is active on the same system, this
definition may cause the wrong CMEM to trap the event.


Regular Allocation and Deallocation
In the case of regular files, meaning files not managed by SMS, CMEM traps the
following deallocation messages:

■ IEF283I
■ IEF285I
■ IEF287I

SMS Support
In the case of SMS-managed data sets, CMEM traps the IGD101I and IGD104I
allocation and deallocation messages, and determines whether the file is new
according to the following rules:
■ If both messages are issued, the file is new.
■ If the IGD101I message is not found, CMEM treats the file as not new.

Generation Data Sets (GDG)
For CMEM to support Generation Data Sets (GDG), the following messages must be
found:
■ IGD105I
■ IGD107I
■ IGD108I
■ IGD17101

NOTE
The messages that are required by CMEM for the purposes of this and the preceding
sections are liable to be changed as a result of IBM changes in data set processing.

CMEM Support for FTP
CMEM actions can be triggered by the transfer of files by FTP products.
In order to enable CMEM rules to be triggered by such file transfers, do the following:

1. Use one of the following methods to insert the expression MSGLEVEL=(1,1) in
the STC of the FTP product:
■ Customize the JESxPARM member in the SYS1.PARMLIB library.
■ Modify the job statement in the PROCLIB library member that contains the
procedure JCL for the STC of the FTP product.

2. Start the CMEM monitor with at least one DSNEVENT rule that refers to the STC
of the FTP product. You can use a dummy DSNEVENT rule that forces CMEM to
monitor the STC of the FTP product.
3. Start the FTP product.

4. Modify existing rules, or order new rules (or do both). Rules that have been
modified or ordered before a file reaches the FTP server are applied to all files
subsequently transferred by the FTP product.

CMEM triggers rules when the requirements of an ON DSNEVENT statement are
satisfied. If an FTP product fails to transmit a data set and issues a message relating to
this failure, CMEM cannot react to that message. However, you can use CMEM rules
to react to FTP product messages.

NOTE
Do not use the STEPRC subparameter in conjunction with the FTP* setting for ON
DSNEVENT, because the same FTP procedure can serve many requests before being
terminated.


CMEM Support for IBM FTP
The IBM FTP process is executed under the OMVS address space, which is BPXAS.
BPXAS address spaces do not usually write messages to the JESYSMSG.
In order to enable CMEM DSNEVENT support for IBM FTP, the following occurs:

1. When the CMEM monitor starts, it activates the OpenEdition interface for
processes in the BPXAS. Having done this, CMEM issues the following messages:

CTO782I SUBSYSTEM REGISTERED WITH OPENEDITION INTERFACE

CTO783I INITIALIZATION OF OPENEDITION ENVIRONMENT ENDED SUCCESSFULLY

When CMEM initialization is complete, message CTO147I is displayed. After this,
CMEM gets control every time that an OpenEdition process starts in the BPXAS
address space.

2. When a new process starts in the BPXAS, the interface routine issues the CTO403I
pseudo-message. This pseudo-message causes CMEM to simulate IEF403I
processing, which is described in “Support for ON DSNEVENT and ON STEP” on
page 712.

3. Under z/OS, IBM FTP functions as a UNIX process running under z/OS.
Therefore it follows the UNIX standard, one aspect of which is that the name of the
job is set to the user ID of the person who issued the FTP request. This UNIX
standard creates a problem, because the operator who writes the CMEM rule must
know at that stage which user will issue an FTP request.

The solution to this problem is to use the statement ON DSNEVENT FTP*. The
result is that any FTP process will trigger the rule.

NOTE
Do not use the STEPRC subparameter in conjunction with the FTP* setting for ON
DSNEVENT, because the same FTP procedure can serve many requests before being
terminated.

[dovetail]

Co:Z SFTP supports IBM FTP-compatible user exits, so you always have the option of writing a user exit to trigger special processing.

In addition, you can also write a program that receives SMF 119 records from Co:Z SFTP in real time.

But it may be possible to avoid writing code if we can make it work like "CMEM Support for IBM FTP" as described below. The only change required may be to change the "ON DSNEVENT FTP*" to the name of the SFTP OMVS jobname prefix (normally SSHD).

[Ulrich Schmidt]

Thank you for the update. But I think the FTP*-Expression is kind of a keyword for CTM. We don't have any job/stc on our system with a name starting with prefix "FTP". So telling the name of the SSH-Daemon will not help much.

regards,
Ulrich

[dovetail]

I understand. Have you contacted Control-M support to see if there is any way to get FTP style processing for other z/OS Unix servers?

If not, the best solution may be to write a post-processing exit or maybe an agent that receives real-time SMF 119 records that issues a WTO for transferred datasets.

Since you are also a commercial support customer, we would be happy to help you with this. Please open a support ticket or send us an email offline to suppor@dovetail.com and we can discuss.

[Ulrich Schmidt]

Ok, have opened the ticket and will track this at the commercial sites

[john.milne]

Hello
We have a similar question to this raised a couple of years ago.
Was there is work-around/resolution published?

regards
John Milne

[john.milne]

Answered my own question. Looks like BMC site has a fix/enhancement for CMEM so it works with Co:Z SFTP
"Apply PTF for BMC APAR BO10102 (PA21534 for 6.2 and PC02472 for 6.3). Stop and restart the OE interface."