assign to name doesn't match ddname, but program doesn't bomb 1

[legacy370]

Here is a strange case, where we expect the program to abend, but it doesn't. Can anyone explain why?
The program has
SELECT RPTFILE ASSIGN TO RPTFILE.

The JCL, by mistake, had
//prtfile dd dsn=<whatever>.

The program does an OPEN OUTPUT RPTFILE, and even writes records to the file, and ends with condition code 00. Shouldn't it abend upon trying to open the file?

 

[rasETL]

My experience says it should not work.

It is possible the object code and source code are not in sync. The program may have been compiled with the prtfile select/ddname. Check the Object Module to see what is in there.

Second option...re-compile the program in its current state and then try to execute it with the current ddname.

 

[legacy370]

I'm certain that the source and load are in synch, because I just compiled it as a test case. In other words, every program is behaving like this, even those compiled years ago.
In looking at the sysout, I see that SMS is somehow allocating the file dynamically:

IGD101I SMS ALLOCATED TO DDNAME WRONGPRT
DSN NBDNMS0.BADPRINT.RPTFILE)

where, in this case WRONGPRT is the ddname in the JCL, and

IGD101I SMS ALLOCATED TO DDNAME (BADOOOO )
DSN(SYS05014.T132359.RA000.NBDNMS0P.R0155741)

where BADOOOO is in the "assign to" clause in the Cobol program.
SELECT RPTFILE ASSIGN TO BADOOOO

 

[COBOLKenny]

You are right. That file is getting dynamically allocated. That happens for output files. You no longer get a missing DD error message. The disposition of the file matches the defaults set up by your tech people. Our default is (NEW,DELETE) so the file gets created and deleted at the end of the job. The DD you created in your JCL gets allocated but never used. You can spend a long time trying to figure out why your program did not write any data.

 

[WMK]

For IBM mainframe (LE conforming) compilers, please see the

CBLQDA

run-time option, e.g.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea3130/2.3.11

With the ANSI/ISO '85 Standard, a "conforming" compiler *must* allocate an output file (in most cases). This is VERY unpopular with many/most IBM mainframe shops and the the

NOCBLQDA

run-time option is usually turned on for "desirable" (but not ANSI conforming) behavior.

Bill Klein

 

[legacy370]

Right on, WMK. With the information you've supplied, I tried running the program with a runtime option, as follows:

//JS0100 EXEC PGM=BADPRINT,PARM='/CBLQDA(OFF)'
//WRONGPRT DD DSN=NBDNMS0.BADPRINT.RPTFILE,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSALLDA,
// SPACE=(TRK,(1,1))
//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*

and, sure enough, the program bombed with a S0C4, the typical symptom when a DD is misspelled. I shall now endeavor to find out when the default changed within my organization.

 

[Vencedor]

Hey mates!
I tried this, & in my installation the CBLQDA is off by default. Hence I got the S0C4 on the first go.

Cheers.