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.
I would try DISABLE_SVC_SCREEN=026
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.
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
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.
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.
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.
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.
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.
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.
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.
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?
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 ProgramYou 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 abnormaltermination of the entire DC/UCF system.
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 )
Retrieving data ...