Skip to main content

How do I incorporate the job kill functionality(End process tree) in MFBSI submit script

  • September 2, 2020
  • 7 replies
  • 0 views
A
  • Anonymous

Hello Everyone,

A problem has been identified when killing a job via Control-M EM GUI kill option, Only the job is failing in control m side but the job continues running in Enterprise server.

  1. Is it possible to incorporate the job kill functionally(End process tree) in MFBSI submit script
  2. Is there any other process/sample script to achieve this kill functionality

Kindly assist.

Thanks in Advance!!


#EnterpriseDeveloper

    7 replies

    D
    • Dominique SacreRocketeer
    • Rocketeer
    • 19312 replies
    • September 2, 2020

    Hello Everyone,

    A problem has been identified when killing a job via Control-M EM GUI kill option, Only the job is failing in control m side but the job continues running in Enterprise server.

    1. Is it possible to incorporate the job kill functionally(End process tree) in MFBSI submit script
    2. Is there any other process/sample script to achieve this kill functionality

    Kindly assist.

    Thanks in Advance!!


    #EnterpriseDeveloper

    What version of Enterprise Server are you running on?

    What platform, Windows or Linux?

    What is the typical use case for needing to cancel the job?  There may be some options that will address the majority of cases depending.

    The simplest way to have this happen is to cancel the job in Enterprise Server itself which will cause the cancel to flow back through MFBSI and ultimately through to Control-M

    A
    • Anonymous
    • 0 replies
    • September 2, 2020

    What version of Enterprise Server are you running on?

    What platform, Windows or Linux?

    What is the typical use case for needing to cancel the job?  There may be some options that will address the majority of cases depending.

    The simplest way to have this happen is to cancel the job in Enterprise Server itself which will cause the cancel to flow back through MFBSI and ultimately through to Control-M

    Hello Steve,

    Thank you so much for your response.. Kindly find my answers below

    1. Enterprise Server - ED4.0 PU14B

    2. Platform - Windows

    3. Currently application support reaching out Control M team to kill any long running jobs from scheduling end. when killing a job via control M EM GUI kill option, the job is failing only in client side but the job continues running in Enterprise server active queue (MFC spool) until Micro focus admin manually kill/cancel the corresponding job from active queue.

    As per management, Control M tool itself should handle this kill functionality the way how job submission happens through script. we have been told to find the way how to achieve this through different script/ redefining the existing script.

    4. As a workaround, We are cancelling the long running jobs through enterprise server itself and its working as expected.

    Kindly check and help us how to make this happen from control M GUI kill option

     

    Thanks,

     

     

    D
    • Dominique SacreRocketeer
    • Rocketeer
    • 19312 replies
    • September 2, 2020

    Hello Steve,

    Thank you so much for your response.. Kindly find my answers below

    1. Enterprise Server - ED4.0 PU14B

    2. Platform - Windows

    3. Currently application support reaching out Control M team to kill any long running jobs from scheduling end. when killing a job via control M EM GUI kill option, the job is failing only in client side but the job continues running in Enterprise server active queue (MFC spool) until Micro focus admin manually kill/cancel the corresponding job from active queue.

    As per management, Control M tool itself should handle this kill functionality the way how job submission happens through script. we have been told to find the way how to achieve this through different script/ redefining the existing script.

    4. As a workaround, We are cancelling the long running jobs through enterprise server itself and its working as expected.

    Kindly check and help us how to make this happen from control M GUI kill option

     

    Thanks,

     

     

    Given the architecture and integration between Control-M --> MFBSI --> Enterprise Server (MFBSI Exit) --> JES Dispatcher --> CASSI where the JCL is running it may not be possible to drive the cancellation from Control-M though I'm not certain we can't find a way, though it may be a bit convoluted.



    A simple method might be to use the JCL TIME parameter which is a function of wall time not CPU time in the Micro Focus world. You can add this on the JOB card and once it's exceeded the job is cancelled and it flows back to MFBSI and then Control-M. This can be done at a job level of job class level and it has the ability to apply a multiplier factor to give some level of flexibility.



    I'm assuming your Enterprise Region is secured correct with something like LDAP or Active Directory, is that correct?


    A
    • Anonymous
    • 0 replies
    • September 2, 2020
    Given the architecture and integration between Control-M --> MFBSI --> Enterprise Server (MFBSI Exit) --> JES Dispatcher --> CASSI where the JCL is running it may not be possible to drive the cancellation from Control-M though I'm not certain we can't find a way, though it may be a bit convoluted.



    A simple method might be to use the JCL TIME parameter which is a function of wall time not CPU time in the Micro Focus world. You can add this on the JOB card and once it's exceeded the job is cancelled and it flows back to MFBSI and then Control-M. This can be done at a job level of job class level and it has the ability to apply a multiplier factor to give some level of flexibility.



    I'm assuming your Enterprise Region is secured correct with something like LDAP or Active Directory, is that correct?


    Thanks Steve

    1.During my testing, I have noticed that only MFBSIJCL process PID got terminated in the task manager when the job was killed via control-m Kill EM GUI option but the job was in execution state in MFC spool with CASSI PID.

    MFBSIJCL PID and CASSI PID's are different. I think that might be the reason we are unable to kill the process tree (Child process)

    2. We already have few JCLs with Time parameter and this long running issue only occurs when application support will process the huge volume data.

    3. Yes, you are correct ES secured with LDAP and AD.

     

    As per your valuable inputs and current architecture/integration, I will explain your points with my management and update you.

    D
    • Dominique SacreRocketeer
    • Rocketeer
    • 19312 replies
    • September 2, 2020

    Thanks Steve

    1.During my testing, I have noticed that only MFBSIJCL process PID got terminated in the task manager when the job was killed via control-m Kill EM GUI option but the job was in execution state in MFC spool with CASSI PID.

    MFBSIJCL PID and CASSI PID's are different. I think that might be the reason we are unable to kill the process tree (Child process)

    2. We already have few JCLs with Time parameter and this long running issue only occurs when application support will process the huge volume data.

    3. Yes, you are correct ES secured with LDAP and AD.

     

    As per your valuable inputs and current architecture/integration, I will explain your points with my management and update you.

    You are correct - MFBSI has no direct knowledge of which CASSI will run the jobs. It simply submits the job to JES and the JES dispatcher then schedules the job to run in a CASSI set up to run that particular class of job.

    See if by chance you can run curl localhost:53296/.../casrdo52 where 53296 is the port for your regions Web Service and J2EE listener. You may need to download the curl utility from somewhere. This should return a list of all the SEPs on the SYSTEM and what's running in each. You can also try going direct to that web page without signing on.

    If you can get to it you can write a script to look for the job, you can determine the windows PID for the CASSI where it's running and then kill that PID which will then flow all the way back to Control-M, or should.

    Good luck




    A
    • Anonymous
    • 0 replies
    • September 3, 2020
    You are correct - MFBSI has no direct knowledge of which CASSI will run the jobs. It simply submits the job to JES and the JES dispatcher then schedules the job to run in a CASSI set up to run that particular class of job.

    See if by chance you can run curl localhost:53296/.../casrdo52 where 53296 is the port for your regions Web Service and J2EE listener. You may need to download the curl utility from somewhere. This should return a list of all the SEPs on the SYSTEM and what's running in each. You can also try going direct to that web page without signing on.

    If you can get to it you can write a script to look for the job, you can determine the windows PID for the CASSI where it's running and then kill that PID which will then flow all the way back to Control-M, or should.

    Good luck




    Hello Steve,

    Could you please provide any sample script to proceed further.

    Please assist

    Thanks

    D
    • Dominique SacreRocketeer
    • Rocketeer
    • 19312 replies
    • September 3, 2020

    Hello Steve,

    Could you please provide any sample script to proceed further.

    Please assist

    Thanks

    I'll see if I can find some time but I can't guarantee anything as I'm heads down in a couple different projects



    Terms & ConditionsAccessibility statement