Re: Re: MVT COBOL under MVS3.8j.

On Fri, 26 Sep 2019, [email protected] [H390-MVS] wrote:

> Been very busy lately but found time to test the zap more.  So I suppose that makes it more official.  So I have tested with 15,000 data division labels (that seems to be limit) and over 20,000 data division labels using the zap.  I've posted the zap in the files section as COBOL_XREF_ZAP.TXT https://xa.yimg.com/df/H390-MVS/COBOL_XREF_ZAP.TXT?token=oEzxjSYDkAVrtuhBsVSDOzG-6t9bJwMtEvJxmVxgcWAcpJeQFxaXdgw6JQbdRnandVvrPejq8DnlBXP58300LXXYm74vNpAyVmKY8sU_yAZD&type=download with these comments:
>
>
> FIX TO ALLOW COBOL COMPILER TO PRODUCE THE CROSS REFERENCE
> COBOL CROSS REFERENCE IS ENABLED VIA PARM=XREF.
> YOU WILL NEED THE REGION AND SIZE AND BUF PARAMETERS BELOW
> THIS WAS RUN WITHOUT A SYSLIB AND WITH SYSIN AND SYSLIN
> USING A BLKSIZE=80.  LARGE BLKSIZES WILL REQUIRE LARGER
> BUF SPECIFICATIONS.
>  //COB     EXEC PGM=IKFCBL00,REGION=9000K,
>  //             PARM='LOAD,SUPMAP,SIZE=6000K,BUF=3000K'
> THIS FIX REMOVES REQUEST FOR MORE MEMORY WHICH TYPICALLY
> IS NOT NEEDED.  I'VE RUN COBOL PROGRAMS WITH 15,000 DATA
> DIVISION LABELS AND 20,000 PLUS PROCEDURE DIVISION LABELS
> SUCCESSFULLY.
>
>
> Dave
>
>
Patch applied succesfully on my personal Moseley SYSGEN:

** HISTORY  IKFCBL00
AMASPZAP UPDATE HISTORY BY CSECT -
PH0TBST1      9/27/19    NO IDENT
USER-SUPPLIED UPDATE HISTORY BY CSECT -
IKFCBL00      3/21/73    RSI30720134
PH0SECT2      3/21/73    RSI30720134
PH0TBST1      3/21/73    RSI30720134
PH0TBST2      3/21/73    RSI30720134
TBDATA        3/21/73    RSI30720134

with one and only one glitch.

There is a mistake, I guess, on the "CBLZAP" JCL code:

//ZAP     EXEC PGM=AMAPSZAP

which has to be, I bet:

//ZAP     EXEC PGM=AMASPZAP

published in the H390-MVS file "COBOL_XREF_ZAP.TXT"
(just for future reference, maybe you may want to upload
again the file).

Beside this "easy to guess" correction, the CBLZAP job
run succesffuly and applied the SYSC.LINKLIB(IKFCBL00)
(Jay Moseley keeps compiler in this PDS) module, as
its history above show.

Now my COBOL test job run correctly with the "XREF" PARM:

*OPTIONS IN EFFECT*     SIZE = 8388608  BUF = 2097152  LINECNT = 57  SPACE1, FLAGW,   SEQ,   SOURCE
*OPTIONS IN EFFECT*       DMAP, NOPMAP,   CLIST,   SUPMAP,   XREF,   LOAD, NODECK, APOST, NOTRUNC,   LIB,   VERB
*OPTIONS IN EFFECT*       ZWB

generating for my short COBOL test code what looks like a correct XREF 
symbol table:
===============================================================================
                                              CROSS-REFERENCE DICTIONARY


DATA NAMES                       DEFN       REFERENCE

ZAZA                             00015      00047  00047  00052  00052 
00060
ZRECORD                          00025      00060
ZREC                             00026      00060
INFILE                           00011      00046  00046  00052  00052 
00057
IRECORD                          00032
IREC                             00033      00059  00060
OUTFILE                          00013      00047  00047  00052  00052 
00059
ORECORD                          00039      00059
OREC                             00040      00059
COUNTER                          00042      00058  00058  00066
COUNT                            00043      00066  00067


PROCEDURE NAMES                  DEFN       REFERENCE

GET-RECORDS                      00056      00049  00061
GET-RECORDS-EXIT                 00062      00057
DISP-COUNT                       00065      00050
DISP-COUNT-EXIT                  00068
=============================================================================

Not anymore RC=0016 return code as soon as XREF is coded in the
compiler PARMS.

Thank you so much for providing us with a so extensively tested
patch (or hack? ;-) ), Dave.

From my side, the problem is CLOSED.

Thank you again, Peppe.