Control-D Delivery Server - When Control-D Delivery tries to read resources from the Main Frame, it fails with message -ERROR CtdDs_Dal_Converter::Convert : Can not read resources from POD resource manager

Version 9
    Share:|

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    Control-D Delivery Server


    COMPONENT:

    Control-D/Delivery Server


    APPLIES TO:

    All Control-D/Delivery Server version



    QUESTION:

    Control-D Delivery Server - When Control-D Delivery tries to read resources from the Main Frame, it fails with message
    -ERROR CtdDs_Dal_Converter::Convert : Can not read resources from POD resource manager

    The following messages appears in ERROR LOG

    ERROR CtdDs_Dal_Converter::Convert : Can not read resources from POD resource manager
    ERROR DeliveryEntry::SendToDestination : DSJOBSB005E: Error during delivery. Id: 29. Report: TESTXXXX TESTING METACODE REPORT. File: E:\Control-D\delivery/reports\16014-092923393-CTDPRINT_5272081.rep. Attributes: DIR=c:\temp original_type=XRX transformer_to=PDF normalize=1


    ANSWER:

    A) Here is a list of possible root cause to verify: 

    1) On the z/OS mainframe side 

    1.1) In the library    : &OLPREFD.PARM
    In the member : CTDSPARM
    Search for parameters:

    USER_NAME=               DEFAULT USER NAME
    PASSWORD=                DEFAULT PASSWORD 


    Define a Userid and its PASSWORD.
    Make sure that the Userid is not in the CTDTREE.


    Refer to the manual:
    INCONTROL for z/OS Administrator Guide
    Control-D and Control-V
    Mainframe – PC File Transfer
    Report Distribution from Control-D using Control-D/Delivery Server
    User Requirements

    Report distribution setup in Control-D for z/OS

    1.2) Does the name defined in the defintion of the external MF repository match the definition of parameter MFR_NAME MF in the CTDSPARM member in &OLPREFD.PARM library?

    1.3) Is the correct RESLIB (RESource LIBrary) allocated to the POD application server?

    Be aware that in case of an upgrade you need to allocate the old RESLIB library,
    as the member names are registered in the resourse records located in the PeRManent User File (PRM file).


    To allocate the old RESLIB on the new installation, you can add the following allocation details in member IOADSNL of the PARM library: &ILPREFA.PARM(IOADSNL) 


     DATASET DARESLIB,             
             SEQ=1,                
             DD=DARESLIB,          
             DSN=OLD_%DBPREFD%.RESLIB  


    or in case you have already decollated such reports in the new version:

     DATASET DARESLIB,             
             SEQ=1,                
             DD=DARESLIB,          
             DSN=OLD_%DBPREFD%.RESLIB
     DATASET DARESLIB,             
             SEQ=2,                
             DD=DARESLIB,          
             DSN=NEW_%DBPREFD%.RESLIB


    the sequence may also differ (if you want the new reslib to be used for new decollations).

    2) On the Control-D Delivery Server Desktop 

    Is the z/OS Mainframe repository defined on Delivery Server?

    In Control-D/Delivery Desktop
    > Root
    > Configurations
    > Distribution Server
    > Distribution_CTD_Delivery
    > Distribution Process
    > Directories
    > CONTROL-D/MF Repositories

    - Check if the TCP>IP Host and TCP>IP Port are correct 
    - Check if the port is opened to the mainframe host

    B) If none of the above allows to fix the problem, activate the POD and Gateway trace and analyze the result: 


    To debug this problem, enable the trace/log on POD and GATEWAY. 
    To do so please do the following: 

    Suggestion: clean-up /LOG folder to have only the pertinent data. 
    Exemple: 
    - at the same level as /log cretae a new folder /log.archive.Dyymmdd (YearMonthDay) 
    - move files from /log to /log.archive.Dyymmdd 


    1) While the Delivery Server is up and running. 
    2) Backup the file:  "<Installation Path>\bin\mf_podcfg.ini" 
    3) Edit      the file:  "<Installation Path>\bin\mf_podcfg.ini" 
    4) Replace sections: [podlog] and [gtwlog] 
    by  

    [podlog] 
    log_buff_level=1 
    log_file_name=C:\Program Files\BMC Software\Control-D\delivery/log/podapi.log          <- replace with your path 
    log_file_on=yes 

    [gtwlog] 
    log_buff_level=2 
    log_buff_max_len=256 
    log_file_on=yes       
    log_file_path=C:\Program Files\BMC Software\Control-D\delivery/log/gtw.log                  <- replace with your path 
      
    5) Recreate issue 
    6) Do the following:
    - Collect and analyze the podapi.log and gtw.log.
    - Check if you can locate an error that your can fix (mostly TCP/IP issues), fix it and retry.
    - If you can't locate any error you can fix by yourself then open a new case, explain the problem and send us ALL the logs from /log folder.
     

    7) Once the problem has been fixed, restore the file mf_podcfg.ini to disable the POD and GATEWAY logs.

     


    Article Number:

    000101770


    Article Type:

    FAQ/Procedural



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles