Job control loosing control of running child job

[luca]

Hi all,

I have a problem with some of the jobs controls that launches child jobs.

The Error Message is:
J0CmdSrcCla..JobControl (fatal error from UtilityAbortToLog): USER INFO: CMD/SRC/CLA : Source Clarify Extraction Failed JOB=> J0CmdSrcCla STAGE=> JobControl LINK=> -8

The jobs controls are jobs sequencers which have the following activities:
- run one or a few jobs,
- call a routine after this (UtilityMessageToLog in case the child finished OK, or UtilityAbortToLog otherwise).
When I run the sequence, the job control sometimes stops with an error, although the child job is still running. This doesn't happen each time, seems to happen by chance.
I am using 2 levels of job control (sequencer) before the lowest level child job, could this cause some problem? could this error be linked with this? I don't think so.
Is there a timout to modify somewhere to increase the time the job control look for his child job ?

Thanks for your comments and suggestions.

[ray.wurlod]

It's interesting that you are getting a message from UtilityAbortToLog. This suggests that something has gone wrong either with the trigger that gets you to that point, ot that you have an Exception Handler that has been fired by something (in which case it may be worth checking in the job log and in &PH& for additional information), or that one of the child jobs or a before/after subroutine has triggered an abort situation.

Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518

[luca]

Hi all,

I still have this problem by random.
When looking in this forum, I found a topic about the &PH& type, advising to change the &PH& type to 19 when meeting problems with job control launching a child job which starts by a before job subroutine and for that reason do not log any event in its log file.
I'm wondering if this could be linked with the problem we are meeting here and if the following command could maybe solve this problem.
Do you think this could help?

The 2 commands suggested:

CLEAR.FILE &PH&
RESIZE &PH& 19

Thanks for your answers.

[ray.wurlod]

They may help, they definitely will not do any harm. &PH& is created as Type 1 by default, and this carries overheads when the file name is more than 14 characters. Type 19 does not carry this overhead. I won't bore you with the details.

It should be a regular part of DataStage maintenance to purge &PH& of older files, which are the log files of "phantom" (background) DataStage processes. Most of these are only two lines long (started, finished). CLEAR.FILE is overkill, but not wrong. It removes all files from the &PH& directory.

I prefer to delete anything older than, say, seven days. For example;
find &PH& -atime +7 -exec rm {};

[UPS]

I am trying to create a basic program that will purge this &PH& directory of all files older than a certain date. Support gave me a template basic program to work with but I am having trouble getting it going. In one post Ray.wurlord says he uses a unix find command to clean out the directory. I thought I had to do this through uvsh with a basic program? The find command would be much easier. Can I do this safely?

[ray.wurlod]

Provided that you have used RESIZE to convert &PH& to type 19 you can use the find command with impunity.

If you're using a BASIC routine you can use the STATUS statement to determine the date/time modified and render your deletion decision on that basis. But find will be faster.

[UPS]

Thanks Ray. So with the default file type of 1 is this an unsafe operation? I really don't understand the implications of changing the file type to 19. I have many projects and since I will need to keep &PH& clean on all of them I would have to go and change them all.

WHat is the downside to leaving them as type 1?