CA Tuesday Tip: (CA IDMS) GIM30206E FMID has an ERROR HOLD on it

[Edward Gorga]

CA IDMS Tuesday Tip by Edward Gorga, Principal Support Engineer for February 11, 2014.

When applying an FMID for a product with SMP/E you may find that it has a HOLD on it. When a PTF is found to be in error it is now a standard that the whole FMID is placed in error. The error holds are placed in the HOLDDATA file in ftp://ftp.ca.com/pub/HoldData/ALL-HOLDDATA.TXT

The hold is resolved when a correcting PTF is published. Here is an example of one that had an error:

GIM30206E ** APPLY PROCESSING FAILED FOR SYSMOD CAGJI50. HOLD REASON IDS WERE NOT RESOLVED.

GIM35901I    ERROR HOLD DC62134 WAS NOT RESOLVED.

GIM35901I    ERROR HOLD EC62134 WAS NOT RESOLVED.

What you need to is do a search for EC62134 and DC62134. If a correcting PTF is found download it and apply it together with the FMID.

If no correcting PTF is yet available you need run the APPLY with a BYPASS for the errors. 

In this case you would add this to the APPLY:  BYPASS(HOLDERROR(EC62134,DC62134))

  

[Edward Gorga]

In my last post on this topic I made the following statement:

"When a PTF is found to be in error the CA standard that all products must follow is to place the entire FMID in error.  These error holds are placed into the “HOLDDATA” buckets available on CSO.  When the correcting PTF is published the error hold is resolved."

That statement was not correct, this is what reallt happens:

When a PTF is found to be in error the CA standard that all products must follow is to place the PTF causing the error in ERROR HOLD status.  If the problem is serious, it will have CLASS(HIPER); otherwise, it will be CLASS(PE).  However, if an error is discovered  in the base GA code, not a PTF, then there is no PTF to put in ERROR HOLD status.  If a problem in the base code is serious, the whole FMID must be placed in ERROR HOLD with CLASS(HIPER).  If a problem in the base code is not serious, nothing is put in ERROR HOLD status.