I don't think reusing the DD would be appropriate, since cob2 directs SYSPRINT to a Unix file, not the terminal.
Your suggestion would probably work. Thanks for the thought. Frank ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Farley, Peter x23353 <[email protected]> Sent: Tuesday, January 26, 2021 12:27 PM To: [email protected] <[email protected]> Subject: Re: COBOL cob2 Unix compile and SVC99 (DYNALLOC) Frank, It might be as simple as the DYNALLOC in cob2 is not using the REUSE parameter to reuse an existing DD. You could also simply wrap the invocation of cob2 with a TSO "FREE FI(SYSPRINT)" and after cob2 "ALLOC FI(SYSPRINT) DA(*)". Peter -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Frank Swarbrick Sent: Tuesday, January 26, 2021 1:45 PM To: [email protected] Subject: Re: COBOL cob2 Unix compile and SVC99 (DYNALLOC) EXTERNAL EMAIL Agreed. I will probably do this. Thanks for the input! ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Seymour J Metz <[email protected]> Sent: Tuesday, January 26, 2021 11:37 AM To: [email protected] <[email protected]> Subject: Re: COBOL cob2 Unix compile and SVC99 (DYNALLOC) There are good reasons why it's common to include SYSPRINT in TSO logon procs. I'd advise an RFE for cob2 to work properly when there is a preallocated SYSPRINT. Ideally they should use a ddname list and not allocate with a specific ddname; failing that, invoke the compiler with _BPX_SHAREAS=NO. -- Shmuel (Seymour J.) Metz https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!dU4klXbnQPNWBVc_moR3Y9a6dVr8sQLxVL4lwLXxI2xteNXxj79n171E-4CumQ3nYwydEg$ ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Frank Swarbrick [[email protected]] Sent: Tuesday, January 26, 2021 1:21 PM To: [email protected] Subject: COBOL cob2 Unix compile and SVC99 (DYNALLOC) I put this out in the world in case anyone has the same issue in the future. I've been playing around with the z/OS Unix environment recently. One of the things I've been playing with is the _BPX_SHAREAS environment variable which allows multiple Unix processes to run in the same Unix address space. I added export _BPX_SHAREAS=YES to my .profile script. One effect this has is the MVS data definitions in the address space that invokes the Unix shell are available to that shell. When running processes in a different address space (the default) this is not the case. In general it seems like this is fine, but I have run in to a case where this causes an issue. When using the cob2 script in the TSO OMVS shell to compile a COBOL program, if you have _BPX_SHAREAS=YES set you will get the following error: [-sh]DVFJS:/u/dvfjs/src:>cob2 -v -o test2 test2.cbl compiler: ATTCRCTL PARM=RENT,TERM /u/dvfjs/src/test2.cbl cob2: An error occured when dynamically allocating cob2: pathname: /u/dvfjs/src/test2.lst ddname: SYSPRINT cob2: SVC99 returned rc: 4 errcode: 410 infocode: 0 This seems to be because: 1) TSO allocates (in my environment, in any case) SYSPRINT and SYSTERM (allocated to my terminal) 2) cob2 tries to dynamically allocate these data sets for itself. This causes the SVC99 error 4 reason 410, because the DDNAME of SYSPRINT is already allocated to your address space. You can get around this by specifying _BPX_SHAREAS=NO on the same line ahead of the cob2 command: _BPX_SHAREAS=NO cob2 -v -o test2 test2.cbl Or you can create your own cob2 wrapper script and have it do this for you. Probably this only occurs when using the TSO OMVS shell. I imagine if you telnet or ssh in, the shell would not have SYSPRINT etc. already allocated. Interestingly, the "c89" command that is invoked for the link-edit/binder step doesn't seem to have this issue. Not sure if it's worth opening a ticket for IBM to do something to avoid this issue. Perhaps at the very least they might add _BPX_SHAREAS=NO to the actual cob2 script. Side note, if you are interested to "see" the SHAREAS (share address space) function in action, try the following two commands: _BPX_SHAREAS=NO ps -Aotty,jobname,user,xasid,sid,pid,pgid,ppid,thdcnt,args TT JOBNAME USER ASID SID PID PGID PPID THCNT COMMAND ? DVFJS DVFJS 8d 131875 131875 131875 1 3 OMVS ttyp0000 DVFJS DVFJS 8d 131317 131317 131317 131875 1 -sh ttyp0000 DVFJS9 DVFJS af 131317 33685900 33685900 131317 1 ps -Aotty,jobname,user,xasid,sid,pid,pgid,ppid,thdcnt,args _BPX_SHAREAS=YES ps -Aotty,jobname,user,xasid,sid,pid,pgid,ppid,thdcnt,args TT JOBNAME USER ASID SID PID PGID PPID THCNT COMMAND ? DVFJS DVFJS 8d 131875 131875 131875 1 3 OMVS ttyp0000 DVFJS DVFJS 8d 131317 131317 131317 131875 1 -sh ttyp0000 DVFJS DVFJS 8d 131317 50463116 50463116 131317 1 ps -Aotty,jobname,user,xasid,sid,pid,pgid,ppid,thdcnt,args When _BPX_SHAREAS=NO you can see that the subshell process for the ps command has a different ASID (and jobname) than does the shell itself. With _BPX_SHAREAS=YES, OMVS itself, the shell and the command all have separate processes but the same ASID (and jobname). Frank ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
