Welcome to "What I'm Working On (WIWO)" for the Week of 6/19/17

Good morning and happy Monday, CA Workload Automation Community! I want to introduce you to a new program I want to try here in the community that I hope will prove valuable fo each and every one of you.

I'm calling it "What I'm Working On" -- or WIWO for short (I think we'll pronounce it "why-woah"). The idea is that by sharing a bit of what we're working on in any given week, we can find ways to help one another, discover shared needs and/or expertise and share experiences.

Obviously, we can't share anything that is proprietary or sensitive -- but let's see how we can help one another!

I'm not a Workload Automation practitioner, but I can still share some of the stuff I'm working on for this community:

I'm working with the Workload automation team to reboot our community webcast series. Look out for more details this summer. If you have anything that you'd really like us to cover, please let me know!

Support working on reviewing knowledge documents making sure the data is up-to-date and looking to improve the linking of knowledge to cases. This way clients can benefit from self-help finding answers without opening cases. Suggestions on improving this are greatly appreciated..

I'm working on two problems that maybe someone would have insights on.

1. For some reason Nov 11, even though I have it as a holiday, my jobs that see it as a holiday, should back up one day and run on Nov 10. I know it is something I've keyed wrong and am not seeing, I just haven't found it yet.

2. We have a job that has been running daily for years (we will call it JOBT). We receive data from an outside source and because we have gone to a different way of doing some things, we don't have data now everyday. BUT... When the job comes into the queue every morning... there are 5 jobs waiting on it to run. It also triggers in a few jobs that even if JOBT doesn't run we need run.

The optimal way that I see to work this situation is to force complete JOBT so it satisfies the 5 jobs waiting on it AND triggers in the jobs that run after it. BUT if there is no data we don't run the job.... AND CA7 will not let us force complete the job if it didn't run and get an error. SO.... I'm trying to figure out a way of working this out without manual intervention every day. ANY SUGGESTIONS?

Renate

btw Roderick_Woods, Marysue I haven't put an support ticket in cuz, I'm been trying to sorta figure it out on my own. Should I start a couple of tickets or might you have a quick and dirty answer?

1- my first guess is that its either the ROLL=B option (probably not) or Nov 10th on the calendar is not a schedule day....

2- This one is tricking and probably need a case open so we can discuss. I am assuming JOBT is scheduled everyday and is waiting on a dataset? If the dataset does not arrive and we can still run JOBT and get it to fail, we can set an ARFSET to forcecomp JOBT and that will satisfy requirements and triggers will occur. But I am sure its not that simple. So, please open case and we can address...

Self-Service. Devising a process where teams can put machines online/offline, and set their own global variables based on membership in an active directory group. Enabling the teams to do what a scheduler or psa has to do today.

Today we're discussing EEM in a DR scenario for 11.3.6. Out of the box, there does not seem to be a good solution for keeping Prod and DR EEMs in sync with multiwrite, without the DR EEMs taking over when Prod goes down (like a monthly reboot). Unlike the primary/shadow scheduler scenario, when the Prod EEMs come back up, they don't take over the primary role again.

I am working on a project that has one CA7 instance that houses all regions of an application workflow, the project supports extracting all non/production jobs to a Development LPAR/CA7 instance. The workflows are defined with a SYSTEM identified for the application and region, that makes it easy to perform a DBT to extract the current set up and ship the files over to the development lpar.

Step 3 - on Development LPAR - submit the BTI - for the CA7SYS. DELETE.CMDS - that will clean up any previous testing jobs and will support a clean install.

Step 4 - on Development LPAR - submit the DBMADD part 1 and 2

Step 5 - on Development LPAR - submit the CA7SYS.DISABLE - - by disabling the jobs just defined, that gives you time to review and compare the set up on the development LPAR versus the production CA7 instance.

Step 6 - Development LPAR - Update the CA7SYS.DISABLE datasets to reflect 99999 00000, and submit to activate the newly defined set up after validation is completed