IBM Mainframe Forum

I am using REGION=0M, file is FB, ; LRECL=40, and I've increased the following to:

SORTWK01 DD UNIT=WORK,SPACE=(CYL,(90,100),RLSE)
SORTWK02 DD UNIT=WORK,SPACE=(CYL,(90,100),RLSE)
SORTWK03 DD UNIT=WORK,SPACE=(CYL,(90,100),RLSE)
EZTVFM DD UNIT=WORK,SPACE=(CYL,(550,150),RLSE)

FILE TBLGRP TABLE (290000)
ARG 1 18 N
DESC 20 21 A

How can I get around the insufficient core storage, can I add additional buffers somewhere?

Please see this thread. Note that "core" is an obsolete term for main memory; your region is too small.

Hello,

Please post the diagnostic info presented by the problem run.

You mention "core storage" but then also mention some dcb attributes for Easytrieve standard datasets

This is all the info I get from the abend - *******A003 INSUFFICIENT CORE STORAGE AVAILABLE - 00 00AC9400 D020 0538.

The other info was to help identify what I have added to try to get around the abend.

Hello,

Hmmmm . . .

Please post the 1st and 3rd sysout files (preferable only the info relating to the problem step). If the job is only one step, please post the whole of these outputs. Also it may help to see the JCL for the problem step.

Below is the JCL and the beginning of the easytrieve, the line number that gets the error is highlighted in red - the job statement. Actual file, program and field names have been changed. This is from the latest that I tried.

ddname 4 started with 'FILE ddname4 TABLE (300000)' and worked fine until I expanded the DESC from 39 2 N to DESC 20 21 A.

//stepname EXEC PGM=pgmname
//*
//SYSABOUT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//*
//SORTWK01 DD UNIT=WORK,SPACE=(CYL,(200,50),RLSE)
//SORTWK02 DD UNIT=WORK,SPACE=(CYL,(200,50),RLSE)
//SORTWK03 DD UNIT=WORK,SPACE=(CYL,(200,50),RLSE)
//EZTVFM DD UNIT=WORK,SPACE=(CYL,(200,50),RLSE)
//*
//ddname1 DD DSN=filename,DISP=SHR,
// AMP=('BUFNI=20','BUFND=10')
//ddname2 DD DSN=filename,DISP=SHR,
// AMP=('BUFNI=20','BUFND=10')
//ddname3 DD DSN=filename,DISP=SHR,BUFNO=30
//ddname4 DD DSN=flename,DISP=SHR,BUFNO=30
//*
//ddname5 DD DSN=filename,
// DISP=(,CATLG,DELETE),
// UNIT=WORK,SPACE=(CYL,(1,1),RLSE),
// DCB=(RECFM=FB,LRECL=120,BLKSIZE=0,BUFNO=30)
//*



PARM LINK(pgmname R) ABEXIT SNAP DEBUG(STATE FLDCHK NOXREF) +
ENVIRONMENT (COBOL) LIST (PARM FILE) +
VFM (4096)

FILE ddname1 VS(NOVERIFY)
%EZcopy1
*
FILE ddname2 VS(NOVERIFY)
%EZcopy2
*
FILE ddname3 FB(40 0)
SUB-RECORD 1 18 N
SUB-KEY 1 18 N
SUB-f1 1 3 N
SUB-f2 4 15 N
SUB-f3 19 1 A
SUB-f4 20 3 N
SUB-f5 23 15 N
SUB-f6 38 1 A
SUB-f7 39 2 N
*
FILE ddname4 FB(40 0) VIRTUAL TABLE 300000
ARG 1 18 N
DESC 20 21 A
*
FILE ddnamre FB(120 0)
GM-RECORD 1 120 A
GM-f1 1 2 N
GM-f2 3 3 N
GM-f3 6 2 N
GM-f4 8 15 N
GM-f5 24 2 N
GM-f6 26 2 N
GM-f7 28 3 N
GM-f8 31 2 N
*
WS-KEY W 18 N
WS-table W 21 A
WS-table-f1 WS-table 3 N
WS-table-f2 WS-table +3 15 N
WS-table-f3 WS-table +18 1 A
WS-table-f4 WS-table +19 2 N

*
**
JOB INPUT (ddname3)
*
IF EOF ddname
STOP
END-IF
*
key-f4 EQ SUB-f4
key-f EQ 00
key-f5 EQ SUB-f5
*
READ ddname2 KEY key STATUS
IF FILE-STATUS(ddname2) NE 0
DISPLAY 'READ ERROR ON ddname2 - KEY = ' key STOP
END-IF
*
WS-KEY EQ SUB-KEY
*
SEARCH ddname4 WITH WS-KEY, GIVING WS-table

*

ddname3 has 45177 records
ddname4 has 265039 records

On your PARM you are allocating "core" for the VFM (Virtual File Manager). You have allocated four megabytes. You DDNAME4 is over ten megabytes.

You don't show how you create DDNAME4, presumably with a SORT in the program?

Your IF EOF is pointless (with JOB INPUT filename Easytrieve Plus handles all the IO and status checking for that file).

Why don't you use "=" in the assignments instead of EQ, helps to make them stand out from IFs?

Do you know the difference between STOP and STOP EXECUTE? I think you want the latter.

I am just modifying an existing program. I need the extra data that is in ddname4. ddname4 is a sequential flat file created in a previous step. According to the documentation the max value for VFM is 4096. At this point I am assuming I am going to need to convert ddname4 to a vsam file, which I was trying to avoid.

The VFM also has "overspill" to DASD, which I see you have defined. I know it gets used for "standard" VFM files, but I don't know specifically if it gets used for TABLE files. You could experiment by reducing your DESC until it "just fits" and then remove the VFM on DASD and see if your dummy program then blows.

You could try the TABLE as a permanent sequential file, although I've not done it myself, I've seen a couple of examples.

You might consider a "double-search". First is your key plus a "number" (binary, for instance). Then the second table is referenced by the "number" and has the DESC you need as its DESC.

You could code your own binary search.

Lots of possibilities. Remember, if you just get it wedged in, it'll blow if the file grows, so you need to understand why it is happening. Perhaps a call to CA support after your initial investigation?