Expand all | Collapse all


Jump to Best Answer
  • 1.  T01A

    Posted 04-09-2018 02:38 PM

    Trying to call Assembler module from a DC-COBOL pgm. Getting this:IDMS DC027007 V91 T7430 TASK:ADS2 PROG:P0510 ABENDED WITH CODE T01A Can't find code T01A anywhere. Assembler has an IBM LOCATE macro within.

  • 2.  Re: T01A

    Posted 04-09-2018 02:49 PM

    Just a guess, but DC does SVC screening in order to intercept and simulate SVC calls that COBOL makes (e.g. converting a GETMAIN into a #GETSTG).   If LOCATE is (and I suspect it does) issue an SVC, that is going to run afoul of DC’s screening.


    Don Casey

    Mainframe Service Delivery Manager


    Kaiser Permanente Information Technology

    925 926-5071 (office)

    925 200-7045 (mobile)

    I have already made this paper too long, for which I must crave pardon, not having now time to make it shorter. Benjamin Franklin

  • 3.  Re: T01A

    Posted 04-09-2018 03:13 PM

    LOCATE generates this:

     105          LOCATE GETVOL                . <<-- DO the LOCATE ----------   00560004 
     107+*                                                                 1@L1D          
     108+*                                                                 1@L1D          
     110+         LA    1,GETVOL                          LOAD PARAMETER REG 1   02-IHBIN 
     111+         SVC   26                                LINK TO SERVICE ROUT.  01-LOCAT 


    A rather benign SVC. I have used SVC 99 to great effect inside CA-IDMS so I guess it all depends upon which SVCs are screened. Does CA offer a callable service to determine if a z/OS dataset is cataloged? LOCATE (SVC26) returns the VOL=SER and that is good enough if all you are trying to determine is: "Is this DSN CATLG'd?"


    OBTAIN will pull in all the FORMAT-1 DSCB fields from the VTOC. As of now, we don't need this. Just knowing that a DSN is cataloged is enough for us.

  • 4.  Re: T01A

    Posted 04-09-2018 03:38 PM

    I'm going to try using SVC 99, Verb Code 7 (Return DSN info) for our requirement. I know SVC 99 can be invoked inside CA-IDMS. Especially, VC=7.  

  • 5.  Re: T01A

    Posted 04-09-2018 03:45 PM

    There may be a way to alter the screening table to allow LOCATE (assuming it does not invoke an I/O wait… that would be a bad thing as it will prevent IDMS from doing any work on that TCB until it completes); anyway, I think maybe but I’ve been away from IDMS for close to a decade and the neurons don’t always fire accurately.


    Don Casey

    Mainframe Service Delivery Manager


    Kaiser Permanente Information Technology

    925 926-5071 (office)

    925 200-7045 (mobile)

    I have already made this paper too long, for which I must crave pardon, not having now time to make it shorter. Benjamin Franklin

  • 6.  Re: T01A

    Posted 04-09-2018 04:12 PM

    Yes, the Txxx abend code indicates that an unsupported SVC call was issued where *** is the hexadecimal SVC number, so in your case x'1A' or SVC 26.  

    You can use the SYSIDMS parameter DISABLE_SVC_SCREEN=SVC-number to disable SVC screening for individual SVCs.


    Stephen Franzon

  • 7.  Re: T01A

    Posted 04-10-2018 03:07 PM



    Thank you. However, when I try to use this SYSIDMS parameter, the CV ABENDS on the way up with the infamous U3134:


    SYSIDMS parms --> DISABLE_SVC_SCREEN=SVC-26                                  
    Invalid SYSIDMS parm --> DISABLE_SVC_SCREEN=SVC-26                           
    IDMS DC208001 IDMS job abending with abend code 5054                         
    IDMS DC208001 #ABEND from Module IDMSCONN at Location 006A11C0 Offset 0024E8 


    I copy-and-pasted the parameter straight out of the R18.5 Common Facilities manual and replaced "-number" with "-26".


    Have also tried:

    DISABLE_SVC_SCREEN=SVC-026 (leading zero)

    DISABLE_SVC_SCREEN=SVC26 (no dash)

    DISABLE_SVC_SCREEN=SVC026 (no dash & leading zero)


    Either the manual is wrong (there is no example) or I'm not seeing something. Might have to open a case here. Is anyone else using this SVC_SCREEN parameter?  Could it be that SVC 26 is ineligible for a screen? Documentation lists limits as "0-255".


    Incidentally, we're using the IBM z/OS Catalog Search Interface - IGGCSI00. Well documented and easy to call from COBOL.


    Here's the manual text:



    Specifies the number of an SVC for which screening is to be disabled.

    Limits: 0–255

    Disabling screening of an SVC allows it to be issued by a program executing within the DC/UCF address space.

    The DISABLE_SVC_SCREEN parameter can be specified multiple times.

    Note: Use this parameter with caution, since issuing unscreened SVCs within the DC/UCF system can degrade performance and result in abends. For more information about SVC screening, see DML Reference Guide for Assembler.



  • 8.  Re: T01A
    Best Answer

    Posted 04-10-2018 03:17 PM

    I would try DISABLE_SVC_SCREEN=026



    Good luck,

  • 9.  Re: T01A

    Posted 04-10-2018 03:22 PM

    Laura is correct




    This is not recommended.  Here is the note from the documentation


    Note: Use this parameter with caution, because issuing unscreened SVCs within the DC/UCF system can degrade performance and result in abends. For more information about SVC screening, see DML Reference for Assembler.

  • 10.  Re: T01A

    Posted 04-10-2018 03:27 PM



    Thanks, that did it.




    We're just experimenting with this. We NEED a solution here. Some old ADS/COBOL dialog can generate literally - Are you ready for this? Tens of thousands of "report jobs" that all fail with a "DATASET NOT FOUND" JCL error. I don't like doing this DISABLE at all but we have to try it.


    The question is: Which is worse - eating some performance degradation?  Or taking up huge amounts of spool space?

  • 11.  Re: T01A

    Posted 04-10-2018 03:55 PM

    I would be concerned with anything that resulted in the SVC being called "frequently". I can see it could have serious performance implications. I too have used SVC 99 in IDMS, but it was only called once at startup.  See this from the DML assembler manual for a good description of why.


    SVC Instructions in an Online Program
    You should avoid coding any SVC instructions or macros that generate SVC instructions in an online DC
    /UCF assembler program. While an SVC is in control, no other online task can use the DC/UCF system.
    This prevents the system from allocating resources between tasks as it is designed to do. In addition,
    any error that occurs during the processing of an SVC instruction can cause a hang or abnormal
    termination of the entire DC/UCF system.

  • 12.  Re: T01A

    Posted 04-11-2018 01:29 PM



    I want to thank each one of you for the help and guidance on this issue. We have decided to put together a compromise solution which will vastly reduce the number of "DATASET NOT FOUND" JCL errors - from tens of thousands to likely under 100.

    We are basically going to change the manner that JCL is submitted when an "ALL" function is user-selected, essentially outsourcing the "Is DSN Cataloged?" problem to REXX running under the TSO monitor PGM (IKJEFT1B - batch entry point) in batch. We've already done this with WTOEXIT (we're not allowed to use console automation) whereby a REXX determines which JCL to submit based on the intercepted WTO message.


    How do I contribute to the user-contributed library?


    I have two snazzy Assember programs I wrote (years ago!) that can be very useful. SHOWUSER - display all signed-on users, the DBNAME/dictionary they're DCUFed to, the current task, terminal information, user-id and....if the user is signed-on to the CA-IDMS region though VTAM? Their name (from the ACEE control block). Like DCUF SHOUALL on steroids. Output like this:


    =USER NAME====CV091====DBN/DICT===ID======LTERM==========PTERM/TASK INFO========
    WILLIAM KEANE                  ZCRPWDS  LD000000 NO PTERM ATTACHED             
    DARLA BROWN                D26/LBD8       ZCRPDSH   LTVT01    ADS2           R=0000556 W=0000558  
    MAURICE SPEES             D17/LBD2        ZCRPMKS  LTVT02    ADSR          R=0000147 W=0000150  
    WILLIAM POPPER            D24/LBD4       ZCRPWDS  LTVT03    OLP              R=0000193 W=0000195  
    PAUL LAFARGE               D05/LBD5        ZCRPPEL  LTVT04     ADS2            R=0000013 W=0000014  
    JAMES B MOORE             DB5/SYST      ZCRDJBM  UCFLT01  SHOWUSER R=0000331 W=0002240  

    First line above is a batch job, the rest online tasks. The "R" and "W" numbers are read/write counts (since startup) for that PTERM (if an "Interactive" terminal).


    And SHOWSTOR  - displays all storage amounts, used and available, for 24, 31 and 64 bit storage. Also Scratch usage. Output like this:


    =STORAGE FROM LDA/RAX===CV091======= BYTES ============R1850=GJI50B=============   
     24 BIT MAX FOR CV 091           11,509,760                                        
     24 BIT USED BY CV 091            2,617,344            8,892,416 AVAILABLE         
     31 BIT MAX FOR CV 091        1,737,490,432                                        
     31 BIT USED BY CV 091           94,171,136        1,643,319,296 AVAILABLE         
     64 BIT MAX FOR CV 091   17,592,186,040,320M                                       
     64 BIT USED BY CV 091           63,963,136                                        
     REGION= FROM JCL                         0M                                       
     TOTAL STORAGE USED             160,751,616         (USED 24 + 31 + 64 BIT)        
    =SCRATCH AREA INFORMATION=========== HI-WATER ============ IN-USE ====== TOTAL =   
    SCRATCH IN 64 @  28,672                  413                 306         1,828     


    Data values taken from IBM control blocks IHALDA (Local Data Area - 24 & 31 bit numbers) and the IARRAX (RSM Address Extension - 64 bit numbers). Scratch data from area CSA->SCRW or #SCRWDS.


    No SVCs! Guaranteed. Simple pointer navigation and chain walking. The SHOWSTOR program does use the "G" class of instruction to handle the 64-bit numbers. (e.g.CVDG R4,S64MAX )