Is this still necessary if the same function is done in EDGDEF00, though? On Thu, May 15, 2025 at 9:16 AM rpinion865 < 0000042a019916dd-dmarc-requ...@listserv.ua.edu> wrote:
> I would search for something, might be run as job as opposed to a STC, > that executes this. > > VIEW OS390.PROCLIB(EDGCVRSP) - 01.01 Columns 00001 > 00072 > Command ===> Scroll ===> > CSR > 000038 //LOADUXTB EXEC PGM=EDGCVRSL,REGION=4096K,PARM='&SSN.,&TAB.' > > > > > "Confidentially doc, I am the wabbit." > > Bugs Bunny > > Sent with Proton Mail secure email. > > On Thursday, May 15th, 2025 at 10:10 AM, rpinion865 < > 0000042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > > > Perhaps, the UXTB is being created with a STC that does not use the IBM > EDG* name. From the system > > where a UXTB is created, these are the messages you should see. The > EDGX102I message indicates the UXTB > > has been created. > > > > STC32987 00000090 $HASP373 EDGCVRSP STARTED > > STC32986 00000290 IEF695I START LMSINIT WITH JOBNAME LMSINIT IS ASSIGNED > TO > > , GROUP PROCGRP > > STC32987 00000090 IEF403I EDGCVRSP - STARTED - TIME=11.31.16 > > STC32986 00000090 $HASP373 LMSINIT STARTED > > STC32986 00000090 IEF403I LMSINIT - STARTED - TIME=11.31.16 > > 00000290 IEF196I IEF237I 0301 ALLOCATED TO SYS00002 > > STC32987 00000090 EDGX102I DATA TABLE LOADED O.K. > > > > > > > > "Confidentially doc, I am the wabbit." > > > > Bugs Bunny > > > > Sent with Proton Mail secure email. > > > > > > On Thursday, May 15th, 2025 at 9:57 AM, Jay Maynard > 000005997213d6c2-dmarc-requ...@listserv.ua.edu wrote: > > > > > EDGCVRSP, that is. And no, that doesn't exist either. > > > > > > On Thu, May 15, 2025 at 8:54 AM Jay Maynard jaymayn...@gmail.com > wrote: > > > > > > > The IBM webpage calls for that, in STC EDGVRSP. That started task > proc > > > > doesn't exist on either system. > > > > > > > > On Thu, May 15, 2025 at 8:51 AM rpinion865 < > > > > 0000042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > > > I think you need to run a DFRMM STC which will set up the UXTB. > Off the > > > > > top of my head, I cannot > > > > > remember what STC does that. Maybe my suggestion will ring a bell > for > > > > > you. If not, I can find out > > > > > what STC you need to run. > > > > > > > > > > "Confidentially doc, I am the wabbit." > > > > > > > > > > Bugs Bunny > > > > > > > > > > Sent with Proton Mail secure email. > > > > > > > > > > On Thursday, May 15th, 2025 at 9:47 AM, Jay Maynard < > > > > > 000005997213d6c2-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > > > > > We're having a weird problem. On our QA LPAR, trying to do a > tape mount > > > > > > (for an FDRABR restore operation) results in the following > messages > > > > > > after the IEF455D for the tape mount: > > > > > > > > > > > > EDGI100I SUBSYSTEM UXTB NOT DEFINED OR NO TABLE LOADED > > > > > > EDG2003E ABEND S0C4 U0000 RSN 0017 DURING DFSMSrmm SUBSYSTEM > PROCESSING > > > > > > AT > > > > > > 4C0DFA IN MODULE K j~ > > > > > > EDG4003E DFSMSrmm DETECTED CONTROL BLOCK ERROR 20, 4084 DURING > OPEN FOR > > > > > > VQ0002 BY TXNWABRR, UTABRRES, TAPE# > > > > > > > > > > > > Everything we can find about the EDGI100I message talks about > using > > > > > > EDGUX100 to set up processing for tape expiration. We had, at > some > > > > > > point in > > > > > > the past, had that exit in place and the associated table, but > during > > > > > > the > > > > > > installation of a previous z/OS, converted that to using the > > > > > > EDGDEF00 member to accomplish the same goal and removed the exit > and the > > > > > > table. > > > > > > > > > > > > The annoying thing about this is that this all works perfectly > in our > > > > > > production LPAR. We've compared definitions and modules between > the two > > > > > > LPARs, and they're the same. > > > > > > > > > > > > So...anyone have any suggestions as to where we can look? Why > does RMM > > > > > > issue EDGI100I if the exit is not in use? I've tried looking at > the 0C4 > > > > > > dump, and it wasn't very enlightening. We've contacted BMC just > to make > > > > > > sure it's not FDR that's the culprit, and they found that it's > the > > > > > > victim, > > > > > > and pointed us to the same web page we keep tripping over at > > > > > > https://ibm.com/support/pages/rmm-message-edgi100i-issued . > > > > > > -- > > > > > > Jay Maynard > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > > > send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > > send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > > > > > > > > -- > > > > Jay Maynard > > > > > > -- > > > Jay Maynard > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Jay Maynard ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
