Re: How to specify logical SYSLIB when linking with xclang++ under uss

[Richard Way]

Yup, this did exactly what I needed.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richard Way
Sent: Friday, April 30, 2021 9:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to specify logical SYSLIB when linking with xclang++ under uss

Thanks! I believe this is exactly what I need to do, and in fact I had an edit 
session going on a config customization for syslib_x when I spotted your reply!

Much appreciated.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Thursday, April 29, 2021 5:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to specify logical SYSLIB when linking with xclang++ under uss

I would use a configuration file. Copy
/usr/lpp/cbclib/xlclang/etc/xlclang.cfg into one of your directories and either 
set the XL_CONFIG environment variable or include it with the -F compiler 
option. Add your data set to the syslib_x concatenation.

  VIEW   /RZ204Y/usr/lpp/cbclib/xlclang/etc/xlclang.cfg
  Command ===>
  **
*
Top of Data **
  01 *
  02 * FUNCTION: z/OS V2.4.1 XL C/C++ Compiler Configuration file
  03 *
  04 * Licensed Materials - Property of IBM
  05 * 5650-ZOS Copyright IBM Corp. 2019.
  06 * US Government Users Restricted Rights - Use, duplication or
  07 * disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
  08 *
  09
  10 * Clang C compiler
  11 clang:    use   = DEFLT
  12
  13 * Clang C++ compiler
  14 clang++:  use   = DEFLT
  15   options   = 
-D_XOPEN_SOURCE=600,-D__static_assert=static_assert,-Wno-parentheses,-Wno-unused-value
  16
  17 * common definitions
  18 DEFLT:    cppcomp   = /usr/lpp/cbclib/xlclang/exe/clcdrvr
  19   ccomp = /usr/lpp/cbclib/xlclang/exe/clcdrvr
  20   as    = /bin/c89
  21   ld_c  = /bin/c89
  22   ld_cpp    = /bin/cxx
  23   xlC   = /usr/lpp/cbclib/xlclang/bin/xlclang
  24   xlCcopt   = -D_XOPEN_SOURCE
  25   sysobj    = cee.sceeobj:cee.sceecpp
  26   syslib_x  = cee.sceebnd2:sys1.csslib
  27   exportlist_c_x    = cee.sceelib(celhs003,celhs001)
  28   exportlist_cpp_x  =
cee.sceelib(celhs003,celhs001,celhscpp)
  29   exportlist_c_64   = cee.sceelib(celqs003)
  30   exportlist_cpp_64 =
cee.sceelib(celqs003,celqscpp,cxxrt64)
  31   cinc  = -isystem/usr/include/le
  32   cppinc    = -isystem/usr/include/c++
  33   options   = 
-D_UNIX03_WITHDRAWN,-L/usr/lpp/cbclib/lib
  34   libraries = -libmcmp
  35   steplib   = cbc.sclccmp
  **

Bottom of Data 


On 29/04/2021 3:23 am, Richard Way wrote:
> I don't know how the xclang++ line got mangled, but it's really just one line 
> - NOT three invocations of xclang++!
>
> Guessing it's something about the ++ and the listserv, let's try it again 
> substituting "FRED" for "xclang++"
>
> FRED -v -Wl,MAP,LIST=ALL,XREF -obin/zprotect 
> obj/zprotect/zprotect.cpp.o lib/libsapi.a lib/libvtk-core.a 
> /usr/lib/GSKCMS64.x /usr/lib/GSKSSL64.x
>
> Rich Way
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Richard Way
> Sent: Wednesday, April 28, 2021 11:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How to specify logical SYSLIB when linking with xclang++ 
> under uss
>
> I am having a problem using xlclang++ to link my program on uss. I have 
> unresolved references, but I actually know where the modules that are needed 
> are located - I am just unable to express that information to the binder.
> As an example, CSNERNG is located in "CSF.SCSFMOD0", but isn't found because 
> the default SYSLIB is just the concatenation of CEE.SCEEBND2 with 
> SYS1.CSSLIB.  I need to logically add CSF.SCSFMOD0 to that concatenation.
>
> I discovered that with the '-v' switch, I can get xlclang++ to emit 
> both the pseudo-JCL it would use and the "export"s of environment 
> variables, and, from that output, I discovered that the variable 
> _CXX_L6SYSLIB is what I supposedly need to set - but setting it and 
> exporting it prior to issuing my make command doesn't have any effect
> -

Re: How to specify logical SYSLIB when linking with xclang++ under uss

[Richard Way]

Thanks! I believe this is exactly what I need to do, and in fact I had an edit 
session going on a config customization for syslib_x when I spotted your reply!

Much appreciated.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Thursday, April 29, 2021 5:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to specify logical SYSLIB when linking with xclang++ under uss

I would use a configuration file. Copy
/usr/lpp/cbclib/xlclang/etc/xlclang.cfg into one of your directories and either 
set the XL_CONFIG environment variable or include it with the -F compiler 
option. Add your data set to the syslib_x concatenation.

  VIEW   /RZ204Y/usr/lpp/cbclib/xlclang/etc/xlclang.cfg
  Command ===>
  **
*
Top of Data **
  01 *
  02 * FUNCTION: z/OS V2.4.1 XL C/C++ Compiler Configuration file
  03 *
  04 * Licensed Materials - Property of IBM
  05 * 5650-ZOS Copyright IBM Corp. 2019.
  06 * US Government Users Restricted Rights - Use, duplication or
  07 * disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
  08 *
  09
  10 * Clang C compiler
  11 clang:    use   = DEFLT
  12
  13 * Clang C++ compiler
  14 clang++:  use   = DEFLT
  15   options   = 
-D_XOPEN_SOURCE=600,-D__static_assert=static_assert,-Wno-parentheses,-Wno-unused-value
  16
  17 * common definitions
  18 DEFLT:    cppcomp   = /usr/lpp/cbclib/xlclang/exe/clcdrvr
  19   ccomp = /usr/lpp/cbclib/xlclang/exe/clcdrvr
  20   as    = /bin/c89
  21   ld_c  = /bin/c89
  22   ld_cpp    = /bin/cxx
  23   xlC   = /usr/lpp/cbclib/xlclang/bin/xlclang
  24   xlCcopt   = -D_XOPEN_SOURCE
  25   sysobj    = cee.sceeobj:cee.sceecpp
  26   syslib_x  = cee.sceebnd2:sys1.csslib
  27   exportlist_c_x    = cee.sceelib(celhs003,celhs001)
  28   exportlist_cpp_x  =
cee.sceelib(celhs003,celhs001,celhscpp)
  29   exportlist_c_64   = cee.sceelib(celqs003)
  30   exportlist_cpp_64 =
cee.sceelib(celqs003,celqscpp,cxxrt64)
  31   cinc  = -isystem/usr/include/le
  32   cppinc    = -isystem/usr/include/c++
  33   options   = 
-D_UNIX03_WITHDRAWN,-L/usr/lpp/cbclib/lib
  34   libraries = -libmcmp
  35   steplib   = cbc.sclccmp
  **

Bottom of Data 


On 29/04/2021 3:23 am, Richard Way wrote:
> I don't know how the xclang++ line got mangled, but it's really just one line 
> - NOT three invocations of xclang++!
>
> Guessing it's something about the ++ and the listserv, let's try it again 
> substituting "FRED" for "xclang++"
>
> FRED -v -Wl,MAP,LIST=ALL,XREF -obin/zprotect 
> obj/zprotect/zprotect.cpp.o lib/libsapi.a lib/libvtk-core.a 
> /usr/lib/GSKCMS64.x /usr/lib/GSKSSL64.x
>
> Rich Way
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Richard Way
> Sent: Wednesday, April 28, 2021 11:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How to specify logical SYSLIB when linking with xclang++ 
> under uss
>
> I am having a problem using xlclang++ to link my program on uss. I have 
> unresolved references, but I actually know where the modules that are needed 
> are located - I am just unable to express that information to the binder.
> As an example, CSNERNG is located in "CSF.SCSFMOD0", but isn't found because 
> the default SYSLIB is just the concatenation of CEE.SCEEBND2 with 
> SYS1.CSSLIB.  I need to logically add CSF.SCSFMOD0 to that concatenation.
>
> I discovered that with the '-v' switch, I can get xlclang++ to emit 
> both the pseudo-JCL it would use and the "export"s of environment 
> variables, and, from that output, I discovered that the variable 
> _CXX_L6SYSLIB is what I supposedly need to set - but setting it and 
> exporting it prior to issuing my make command doesn't have any effect 
> - the unresolved reference still occurs, and the generated pseudo-JCL 
> does not include my addition to the concatenation. (BTW the Unix 
> System Services Command Reference confirms that _CXX_L6SYSLIB is the 
> correct variable for an lp64 invocation.)
>
> The command that I am using for th

Re: How to specify logical SYSLIB when linking with xclang++ under uss

[Richard Way]

I don't know how the xclang++ line got mangled, but it's really just one line - 
NOT three invocations of xclang++!

Guessing it's something about the ++ and the listserv, let's try it again 
substituting "FRED" for "xclang++"

FRED -v -Wl,MAP,LIST=ALL,XREF -obin/zprotect obj/zprotect/zprotect.cpp.o 
lib/libsapi.a lib/libvtk-core.a /usr/lib/GSKCMS64.x /usr/lib/GSKSSL64.x

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richard Way
Sent: Wednesday, April 28, 2021 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to specify logical SYSLIB when linking with xclang++ under uss

I am having a problem using xlclang++ to link my program on uss. I have 
unresolved references, but I actually know where the modules that are needed 
are located - I am just unable to express that information to the binder.
As an example, CSNERNG is located in "CSF.SCSFMOD0", but isn't found because 
the default SYSLIB is just the concatenation of CEE.SCEEBND2 with SYS1.CSSLIB.  
I need to logically add CSF.SCSFMOD0 to that concatenation.

I discovered that with the '-v' switch, I can get xlclang++ to emit both the 
pseudo-JCL it would use and the "export"s of environment variables, and, from 
that output, I discovered that the variable _CXX_L6SYSLIB is what I supposedly 
need to set - but setting it and exporting it prior to issuing my make command 
doesn't have any effect - the unresolved reference still occurs, and the 
generated pseudo-JCL does not include my addition to the concatenation. (BTW 
the Unix System Services Command Reference confirms that _CXX_L6SYSLIB is the 
correct variable for an lp64 invocation.)

The command that I am using for the link is:
xlclang++ -v  -Wl,MAP,LIST=ALL,XREF -obin/zprotect 
xlclang++ obj/zprotect/zprotect.cpp.o lib/libsapi.a lib/libvtk-core.a 
xlclang++ /usr/lib/GSKCMS64.x /usr/lib/GSKSSL64.x

The export I am doing first is:
export _CXX_L6SYSLIB=CEE.SCEEBND2:SYS1.CSSLIB:CSF.SCSFMOD0

and yet my generated pseudo-JCL is still:
...
//LINKEDIT  EXEC  PGM=LINKEDIT,
//  PARM='AMODE=64,TERM=YES,
//  DYNAM=DLL,ALIASES=NO,UPCASE=NO,
//  LIST=OFF,MAP=NO,XREF=NO,INFO=NO,MSGLEVEL=4,
//  REUS=RENT,EDIT=YES,AC=0,CALL=YES,CASE=MIXED
//  ,MAP,LIST=ALL,XREF
//  ,LP64'
//SYSLIB   DD  DSN='CEE.SCEEBND2',DISP=SHR,DCB=DSORG=DIR
// DD  DSN='SYS1.CSSLIB',DISP=SHR,DCB=DSORG=DIR   <==note missing 
CSF.SCSFMOD0 concatenation attempt here.
...

Any thoughts or ideas on what I could try next?

Thanks

Rich Way, CISSP
Security Lead, Voltage Portfolio
Micro Focus
4555 Great America Parkway
Santa Clara, CA 95054
+1 408 857 0216
richard@microfocus.com<mailto:richard@microfocus.com>

--
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

How to specify logical SYSLIB when linking with xclang++ under uss

[Richard Way]

I am having a problem using xlclang++ to link my program on uss. I have 
unresolved references, but I actually know where the modules that are needed 
are located - I am just unable to express that information to the binder.
As an example, CSNERNG is located in "CSF.SCSFMOD0", but isn't found because 
the default SYSLIB is just the concatenation of CEE.SCEEBND2 with SYS1.CSSLIB.  
I need to logically add CSF.SCSFMOD0 to that concatenation.

I discovered that with the '-v' switch, I can get xlclang++ to emit both the 
pseudo-JCL it would use and the "export"s of environment variables, and, from 
that output, I discovered that the variable _CXX_L6SYSLIB is what I supposedly 
need to set - but setting it and exporting it prior to issuing my make command 
doesn't have any effect - the unresolved reference still occurs, and the 
generated pseudo-JCL does not include my addition to the concatenation. (BTW 
the Unix System Services Command Reference confirms that _CXX_L6SYSLIB is the 
correct variable for an lp64 invocation.)

The command that I am using for the link is:
xlclang++ -v  -Wl,MAP,LIST=ALL,XREF -obin/zprotect obj/zprotect/zprotect.cpp.o 
lib/libsapi.a lib/libvtk-core.a /usr/lib/GSKCMS64.x /usr/lib/GSKSSL64.x

The export I am doing first is:
export _CXX_L6SYSLIB=CEE.SCEEBND2:SYS1.CSSLIB:CSF.SCSFMOD0

and yet my generated pseudo-JCL is still:
...
//LINKEDIT  EXEC  PGM=LINKEDIT,
//  PARM='AMODE=64,TERM=YES,
//  DYNAM=DLL,ALIASES=NO,UPCASE=NO,
//  LIST=OFF,MAP=NO,XREF=NO,INFO=NO,MSGLEVEL=4,
//  REUS=RENT,EDIT=YES,AC=0,CALL=YES,CASE=MIXED
//  ,MAP,LIST=ALL,XREF
//  ,LP64'
//SYSLIB   DD  DSN='CEE.SCEEBND2',DISP=SHR,DCB=DSORG=DIR
// DD  DSN='SYS1.CSSLIB',DISP=SHR,DCB=DSORG=DIR   <==note missing 
CSF.SCSFMOD0 concatenation attempt here.
...

Any thoughts or ideas on what I could try next?

Thanks

Rich Way, CISSP
Security Lead, Voltage Portfolio
Micro Focus
4555 Great America Parkway
Santa Clara, CA 95054
+1 408 857 0216
richard@microfocus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Code vulnerability

[Richard Way]

I currently work for Micro Focus, and we have the "Fortify" product line. I am 
NOT in that group, however, and I really don't know if it does what you are 
looking for or not - although I know it does have support for scanning 
mainframe COBOL for vulnerabilities. I don't know about HLASM.

Something you may want to explore, if you haven't already investigated it.

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Friday, December 07, 2018 2:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Code vulnerability

Depends on what kind of vulnerability you're looking for.  z/OS itself isn't 
the only valuable thing you have.

sas

On Fri, Dec 7, 2018 at 2:11 PM Charles Mills  wrote:

> Ray Overby at Key Resources, Inc.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of scott Ford
> Sent: Friday, December 7, 2018 10:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Code vulnerability
>
> All,
>
> We write in Enterprise Cobol and HLASM and had a reseller asked us if 
> we scanned our Cobol code and HLASM code for vulnerabilities ..Does 
> software for this exist ?  I know according to one of our people 
> Sonarcube can do Cobol scans, but is expensive , like $5.
>
> Has anyone heard on any other software does this function and what 
> would they be looking for since we dont use and third party libraries ?
>
> Best Regards,
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning 
> a friend or collegue you demean yourself”
>
>
>
> www.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: www.idmworks.com/blog
>
>
>
>
>
> *The information contained in this email message and any attachment 
> may be privileged, confidential, proprietary or otherwise protected 
> from disclosure. If the reader of this message is not the intended 
> recipient, you are hereby notified that any dissemination, 
> distribution, copying or use of this message and any attachment is 
> strictly prohibited. If you have received this message in error, 
> please notify us immediately by replying to the message and 
> permanently delete it from your computer and destroy any printout 
> thereof.*
>
> --
> 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
>


--
sas

--
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