Agreed. I will probably do this. Thanks for the input! ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Seymour J Metz <sme...@gmu.edu> Sent: Tuesday, January 26, 2021 11:37 AM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> 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 http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Tuesday, January 26, 2021 1:21 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
