IDMS

 View Only
  • 1.  Security vexation on IDMS employee demo database

    Posted Jan 06, 2025 10:53 AM

    Hi,

    As part of learning about IDMS I set myself a challenge of setting up the employee demo database that is optionally installed with the base software.  Following the job in SMP/E installation datasets HLQ.GJR190.CAISAG.CONFIG(JOB14) I have successfully restored the EMPDEMO Segment, EMPSCHM Schema, EMPSS01 SubSchema and all required definitions, finally compiling and running successfully the sample programs EMPLOAD and EMPRPT.  It's been an interesting process with lots of blind alleys, lots or reading the fine documentation, and some help from colleagues better versed in IDMS basics than I am, but we now have a working EMPDEMO database which is something I'm very happy to see.

    One question still vexes us though.  Near the final stages of building the database, prior to loading the database from the supplied sample input data, we had to FORMAT the AREAs using the JCL supplied in step FORMEMP of the JOB14 previously mentioned.  We could not get this to work without 'hacking' by temporarily disabling the SRTT processing for database/area security completely.

    I am not the security administrator of this system, but the person who is assures me they have done what they understand to be the correct setup to allow us to issue the FORMAT command successfully.  Below is some JCL excerpts and results we are getting.

    //IDMSEXEC EXEC PGM=IDMSBCF                                  
    //*  various DD's removed for brevity
    //SYSIPT   DD *                                              
      CONNECT TO SYSTEM;                                         
     GRANT DBAWRITE ON AREA EMPDEMO.EMP_DEMO_REGION TO PUBLIC;   
     GRANT DBAWRITE ON AREA EMPDEMO.INS_DEMO_REGION TO PUBLIC;   
     GRANT DBAWRITE ON AREA EMPDEMO.ORG_DEMO_REGION TO PUBLIC;   
    /*                                                           
    //SYSIDMS  DD *                                              
      ECHO=ON                                                    
      DMCL=live dmcl                                              
    /*                                                           
    //SYSCTL   DD DISP=SHR,DSN=appropriate-dataset-here

    this returns a healthy seeming:

      CONNECT TO SYSTEM;                                         
     GRANT DBAWRITE ON AREA EMPDEMO.EMP_DEMO_REGION TO PUBLIC;   
    Status = 0        SQLSTATE = 00000                           
     GRANT DBAWRITE ON AREA EMPDEMO.INS_DEMO_REGION TO PUBLIC;   
    Status = 0        SQLSTATE = 00000                           
     GRANT DBAWRITE ON AREA EMPDEMO.ORG_DEMO_REGION TO PUBLIC;   
    Status = 0        SQLSTATE = 00000                           
                                                                 
    AutoCommit will COMMIT transaction                           
                                                                 
    Command Facility ended with no errors or warnings            

    However we've been unable to get past this:

    CONNECT TO SYSTEM;                                         
    Status = 0        SQLSTATE = 00000                         
    FORMAT FILE EMPDEMO.EMPDEMO;                               
                                                               
    Status = -4       SQLSTATE = 42503        Messages follow: 
    DB002365 C-4M353: Access denied to resource EMP-DEMO-REGION
    FORMAT FILE EMPDEMO.INSDEMO;                               
                                                               
    Status = -4       SQLSTATE = 42503        Messages follow: 
    DB002365 C-4M353: Access denied to resource INS-DEMO-REGION
    FORMAT FILE EMPDEMO.ORGDEMO;                               
                                                               
    Status = -4       SQLSTATE = 42503        Messages follow: 
    DB002365 C-4M353: Access denied to resource ORG-DEMO-REGION

    The JCL for which is a little more convoluted owing to the requirement that FORMAT FILE is not supported under CV mode:

    //FORMEMP  EXEC PGM=IDMSBCF,REGION=4096K,COND=(0,LT)        
    //*  various DD's removed for brevity
    //EMPDEMO  DD DISP=OLD,DSN=userid.USER.IDMS.EMPDEMO.EMPDEMO 
    //INSDEMO  DD DISP=OLD,DSN=userid.USER.IDMS.EMPDEMO.INSDEMO 
    //ORGDEMO  DD DISP=OLD,DSN=userid.USER.IDMS.EMPDEMO.ORGDEMO 
    //SYSIDMS  DD *                                             
    ECHO=ON                                                     
    LOCAL=ON                                                    
    DMCL= live dmcl                                               
    USERCAT=OFF                                                 
    /*                                                          
    //SYSIPT   DD *                                             
    CONNECT TO SYSTEM;                                          
    FORMAT FILE EMPDEMO.EMPDEMO;                                
    FORMAT FILE EMPDEMO.INSDEMO;                                
    FORMAT FILE EMPDEMO.ORGDEMO;                                
    /*                                                          
    //SYSCTL   DD DISP=SHR,DSN=appropriate-dataset-here             
    //*        *************************************            
    //* NEEDED FOR PHYSICAL DDL STATEMENTS                 
    //DDLCAT   DD DISP=SHR,DSN=appropriate-dataset-here     
    //DDLCATL  DD DISP=SHR,DSN=appropriate-dataset-here  
    //DDLCATX  DD DISP=SHR,DSN=appropriate-dataset-here  
    //*                                                    
    //* NEEDED FOR LOCAL MODE                              
    //DDLSEC   DD DISP=SHR,DSN=appropriate-dataset-here 
    //DCLSCR   DD DUMMY                                    
    //DDLDML   DD DISP=SHR,DSN=appropriate-dataset-here
    //DDLDCLOD DD DISP=SHR,DSN=appropriate-dataset-here
    //*                                                    
    //* ADDED JUST IN CASE                              
    //E1CATT1  DD DISP=SHR,DSN=appropriate-dataset-here
    //E1CATLT1 DD DISP=SHR,DSN=appropriate-dataset-here
    //E1CATXT1 DD DISP=SHR,DSN=appropriate-dataset-here
    //DCCATT1  DD DISP=SHR,DSN=appropriate-dataset-here
    //DCCATLT1 DD DISP=SHR,DSN=appropriate-dataset-here
    //DCCATXT1 DD DISP=SHR,DSN=appropriate-dataset-here
    //E1LODT1  DD DISP=SHR,DSN=appropriate-dataset-here
    //E1DMLT1  DD DISP=SHR,DSN=appropriate-dataset-here
    //DCLOGT1  DD DISP=SHR,DSN=appropriate-dataset-here
    //DCRUNT1  DD DISP=SHR,DSN=appropriate-dataset-here
    //DCSECT1  DD DISP=SHR,DSN=appropriate-dataset-here
    //DCMSGT1  DD DISP=SHR,DSN=appropriate-dataset-here
    //PUBLIC   DD DISP=SHR,DSN=appropriate-dataset-here
    //DDLODT1  DD DISP=SHR,DSN=appropriate-dataset-here
    //DDDMLT1  DD DISP=SHR,DSN=appropriate-dataset-here
    //SGLODT1  DD DISP=SHR,DSN=appropriate-dataset-here
    //SGDMLT1  DD DISP=SHR,DSN=appropriate-dataset-here

    Any suggestions on how we can properly grant the necessary access to allow the FORMAT AREA commands to process would be greatly appreciated.

    Thanks and regards - Mike





  • 2.  RE: Security vexation on IDMS employee demo database

    Posted Jan 06, 2025 03:15 PM


    I think you also need DBAREAD, the security documentation says that DBAWRITE does not imply DBAREAD.

    "DBAWRITE
    Specifies that you are giving DBAWRITE privilege on the area identified in the ON parameter to the users or groups specified in the TO parameter.
    A user with DBAWRITE privilege can execute database utilities that perform read-write functions in the specified area.
    Note: DBAWRITE privilege does not imply DBAREAD privilege. You must give both privileges to users or groups who need to execute all utilities."



    ------------------------------
    Tommy Petersen
    ------------------------------



  • 3.  RE: Security vexation on IDMS employee demo database

    Posted Jan 07, 2025 02:28 AM

    Hi Tommy, thanks very much for taking a look and your reply.  Unfortunately we had already tried that also after reviewing the documentation and the results are exactly the same.  Apologies I should have added this detail.

    Cheers - Mike




  • 4.  RE: Security vexation on IDMS employee demo database

    Posted Jan 07, 2025 10:55 AM

    //SYSIDMS DD *

    DICTNAME=SYSTEM

    DMCL=live dmcl

    LOCAL=ON 

    //SYSIPT DD *

    FORMAT FILE EMPDEMO.EMPDEMO;

    FORMAT FILE EMPDEMO.INSDEMO;

    FORMAT FILE EMPDEMO.ORGDEMO;




  • 5.  RE: Security vexation on IDMS employee demo database

    Posted Jan 07, 2025 11:29 AM

    Hi @EAF ILS, thanks for the attempt, but adding the DICTNAME=SYSTEM still results in the security error.  My understanding was that the CONNECT TO SYSTEM; in DD SYSIPT and the DICTNAME=SYSTEM in DD SYSIDMS provide the same functionality, with one over-riding the other in case of both being specified (I forget which one, but I recall reading about it in the fine manual).

    One of my colleagues suggested our next step might be to open a support request with Broadcom formally for advice on how to proceed, especially for how to better diagnose the underlying issue.

    Cheers - Mike




  • 6.  RE: Security vexation on IDMS employee demo database

    Posted Jan 07, 2025 12:30 PM
    Mike,

    Can you check to see if RACF or Top Secret put any corresponding messages into your JES log?


    Tom Hebert

    Mobile: +1 (480) 788-6601


    [ObjEx,Inc.]
    Thomas Hebert
    Connect your IDMS apps to any system in the world<https: www.obj-ex.com>
    co-founder * phoenix metro * +1 480 588 7776




  • 7.  RE: Security vexation on IDMS employee demo database

    Posted Jan 08, 2025 02:49 AM

    Thanks @Tom Herbert for the suggestion.  We don't use the external security system for IDMS resources, hence the attempted use of the GRANT DBAWRITE's above.  I did take a look at the SYSLOG again though while my job executed, and there's no messages associated with the processing at all unfortunately.

    Cheers - Mike




  • 8.  RE: Security vexation on IDMS employee demo database

    Posted Jan 09, 2025 04:10 AM

    Thanks to everyone for taking a look and the assistance offered.  With some help from Broadcom technical support via an official ticket we have been able to get to the bottom of this and fix our problem.  Most embarrassingly it turned out to be a rookie error on our behalf, the resource we were granting access to was EMPDEMO.EMP_DEMO_REGION whereas the resource in the error message from the security system was EMPDEMO.EMP-DEMO-REGION - note the difference of underscores (*_*) vs hyphens (*-*) embedded in the resource name(s).  For reference, in the end the correct format of the GRANT needed to be something like:

    GRANT DBAWRITE ON EMPDEMO."EMP-DEMO-REGION" TO PUBLIC;

    (The double-quotes around the AREA name are needed due to the presence of the embedded hyphen in the resource name).

    Thanks again to everyone for taking a look.

    Cheers - Mike 




  • 9.  RE: Security vexation on IDMS employee demo database

    Posted Jan 10, 2025 01:10 PM

    "Rookie Mistake"? 
    It is all there in the post.  You provided the grants, and the messages.  But nobody caught the error, and some of us have been doing this for a long time.

    I was once given the advice:  When you read something, read it as if it is worth 50% on the final exam.

    I should try that.  LOL.



    ------------------------------
    Tommy Petersen
    ------------------------------