IBM Mainframe Forum

Hi,

We have a proclib IRCMNXX.BACT.PROCLIB which used to its 129 cylinders and 5 extends.

JOB A,B,C,D,E,F and G are using the proclib in share mode to call the members. These JOBs are running parrallely without any dependency on each other but the JOBs call different members from the IRCMNXX.BACT.PROCLIB.

The JOB A,B,C,D,E,F and G are initially waiting for the PROCLIB DATASET and ABEND with MODULE NOT FOUND unfortunately the members are exist in the PROCLIB.

I doubt on the IRCMNXX.BACT.PROCLIB as the proclib have used its allocation completely because the JOBs using the PROCLIB in share mode.

Please assist to fix this issue permanently.

My Plan :
1. I am planning to create the new proclib with more number of primary and secondery cylinders than the current proclib.
2. Define the new proclib and use the organization mode as LIBRARY instead of PO.

MODULE NOT FOUND has nothing to do with a PROCLIB. That error message means a LOAD LIBRARY (STEPLIB most likely, or linklist if there's not a STEPLIB) did not contain the program requested by EXEC PGM=???????? in the JCL (be it from the PROCLIB or wherever).

In other words, you have mis-diagnosed the problem and are off chasing wild hares while the real problem remains unresolved and unaddressed.

Hello,

It will help if you post the actual diagnostic messages presented by the problem run. . .

Apart from what Robert and Dick has said, I'm confused if you are really talking about S806 or something totally different?

Hello,

Might the message actually be - NO ACTIVE MODULE FOUND?

I also have no idea how this relates to a SPACE problem . . .

Maybe TS will clarify.

Hi,

Please find below details,


Problematic Step
8 XXSTE01#22 EXEC PGM=RWRDWT
9 XXSBDSETI DD DSN=TRCMNXX.BA16.PROCLIB(BA51MGV1),DISP=SHR
10 XXSBDSETO DD DSN=TRURASQB.PROCLIB(BA51MGV1),DISP=OLD
11 XXSYSPRINT DD SYSOUT=*
12 XXSYSUDUMP DD SYSOUT=*
13 XXSYSOUT DD SYSOUT=*

Message during JCL expansion

TSS7000I BA51 Last-Used 28 Jun 12 00:00 System=RC40 Facility=BATCH
TSS7001I Count=60999 Mode=Fail Locktime=None Name=(T1) - BA (NAMIBIA TEST)
$HASP373 BA51MGV0 STARTED - INIT 17 - CLASS O - SYS RC40
IEF861I FOLLOWING RESERVED DATA SET NAMES UNAVAILABLE TO BA51MGV0
IEF863I DSN = TRURASQB.PROCLIB BA51MGV0 RC = 04
IEF099I JOB BA51MGV0 WAITING FOR DATA SETS
IEF403I BA51MGV0 - STARTED - TIME=01.50.22
IEC212I 414-08,IGG0201B,BA51MGV0,STE01#22,SBDSETO,1525,SBLD00,TRURASQB.PROCLIB(BA51MG51)

Error Message

AB400A ===== ABEND-AID ===== 566
REPORT WRITTEN TO: SYS4.ABENDXLS.SHRDIR
REPORT NUMBER: 0014799
JOB-BA51MGV0 STEP-STE01#22
ABEND CODE=S414
ACCESS YOUR ABEND-AID REPORTS BY EXECUTING SYSTEM
COMMAND "TSO ABENDXLS" FROM ANYWHERE IN ISPF.
IEA995I SYMPTOM DUMP OUTPUT 567
SYSTEM COMPLETION CODE=414 REASON CODE=00000008
TIME=01.50.22 SEQ=44162 CPU=0000 ASID=0169
PSW AT TIME OF ERROR 075C1000 80D6E82E ILC 2 INTC 0D
NO ACTIVE MODULE FOUND
NAME=UNKNOWN

Data set specification

ata Set Name . . . . : TRURASQB.PROCLIB

eneral Data Current Allocation
Management class . . : DEVBKUP Allocated cylinders : 322
Storage class . . . : GSPACE Allocated extents . : 6
Volume serial . . . : SBLD00
Device type . . . . : 3390
Data class . . . . . : **None**
Organization . . . : PO Current Utilization
Record format . . . : FB Used cylinders . . : 295
Record length . . . : 80 Used extents . . . : 6
Block size . . . . : 27920
1st extent cylinders: 182
Secondary cylinders : 30 Dates
Data set name type : PDS Creation date . . . : 2007/02/12
Referenced date . . : 2012/07/06
Expiration date . . : ***None***

Here i got a clue, that the step open the member in OLD mode but the destination dataset have used it is space completely. There might be the chance for the space error but how come the MODULE Not found error is coming.

Please assist

This is the key message in all the stuff you posted:A 414 error code is an error during a CLOSE operation. The NO ACTIVE LOAD MODULE means the system was executing system code (that is, doing the actual close of the data set) and hence no application program (nor system routine) was actively running while the close was underway. This message merely denotes that you cannot use an offset to find the statement in error -- but then, you should only have one place in the program where you are closing the file, so that should be easy to find. And the CLOSE statement may have nothing to do with the problem; you need to identify the cause of your 414-04 error. You continue to look at COMPLETELY IRRELEVANT things and totally ignore the actual error message you are given.

And since your site has Abend Aid, why are you not using it to find the cause of the problem? Why are you asking questions on this forum when Abend Aid will tell you far more about the problem, its possible causes, and possible solutions then we can?

Hello,

Has this particular process ever worked or is this the first attempt?

You need to be sure that what you post is what was presented by the system. There is NO similarity between MODULE NOT FOUND and NO ACTIVE MODULE FOUND. One says the program you tried to run is not in the joblib/steplib/linklib concatenation; the other says you are not actually in "your program".

There are so many misconceptions and incorrect information here it is unbelievable.

• Mr. Sample's interpretation of "NO ACTIVE MODULE FOUND" in the section of the summary dump is incorrect, though I have fallen into this misunderstanding myself, and clearly the topic starter has fallen for this, too. All it means is the ABEND is issued by a module that is not defined in the current list of active load modules for the address space. There are many ways this can happen. OPEN and CLOSE use some code in the z/OS nucleus, and most likely this is where the ABEND was issued. However, the real problem is summary dump is too stupid to locate the module where the CLOSE macro was issued, which is what we really want to know.
• No one bothered to lookup the IEC212i message. For reason code 08 the messages manual says, "For a QSAM data set either an I/O error occurred while flushing the buffers during close processing or a close was issued in the caller's SYNAD routine." Sadly, this is not very helpful. The second clause about a SYSNAD routine is unlikely: few Assembler programmers know how to specify a SYNAD routine much less code one properly, though it is possible this is coming from an incorrect attempt to write a SYNAD routine. What is more likely, however, is something damaged a control block called a DCB or the I/O buffer that caused QSAM to lose it place in the I/O buffer. CLOSE writes any data in I/O buffers that has not be sent to an output dataset. This is very common for QSAM processing, and CLOSE normally handles this flawlessly I've been writing Assembler for more than 40 years and I don't think I ever managed to get this error, so I can't give you war stories about this problem.
• There does not appear to be a space problem as initially reported by the topic starter. The dataset summary reports 322 allocated cylinders and 295 used ctlinders. There should be plenty of space.

This is almost certainly an issue with the RWRDWT program. With no knowledge about the program no one here can provide additional guidance.

Hello,

Some of us did review the IEC212I message and found the description basically useless. . . Bummer.

While i have not been able to cause this, i have seen it when something goes amiss writing to a PDS. Funny creatures those. . .

I'm curious how much was being written to the problem member at the time of the problem - might the pds have filled and then returned to the non-full state after the abend?