Re: Which C library functions imply dub?

[Charles Mills]

Thank you all for your help and patience with my RACF command ignorance ...

Yes, the explanation for "OMVS auto-create" is of course FACILITY 
BPX.UNIQUE.USER. I RDELETEd that and now the program fails as expected.

Well, more or less as expected. I think I knew this before but I got excited by 
the thread on the MVS-OE list about testing for the OMVS segment and issuing a 
diagnostic. However the program in question is written in C++ and any "no OMVS 
segment" failure occurs before the first line of user (my) code gets executed, 
so there is no diagnosing it in the program. Yes, I could front-end LE 
initialization but I think that is overkill for this particular problem.

Don't get me wrong: BPX.UNIQUE.USER seems to be goodness and I will put that 
back now that testing is completed.

Thanks again,

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, March 8, 2017 7:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which C library functions imply dub?

A snippet from Robert's presentation

To help replace BPX.DEFAULT.USER, z/OS 1.11 introduced the FACILITY class 
profile BPX.UNIQUE.USER. Defining this newer profile causes RACF to 
automatically add OMVS segments and assign ids to users and groups that do not 
already have segments. RACF creates the segments when the user first accesses 
Unix (i.e., dubs). BPX.UNIQUE.USER works in combination with FACILITY class 
profile BPX.NEXT.USER, which defines the uid and gid number ranges to be used 
for automatic id assignment. Use of these profiles requires your databases to 
be in the Application Identity Mapping (AIM) structure.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Wednesday, March 08, 2017 8:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which C library functions imply dub?
> 
> What version of z/OS is this on?
> 
> I am thinking that RACF (or your SAF) is using an auto assign of the UID.
> There was a change when you had to specify the UID in the OMVS 
> Segment, then a change happened and the system went from 
> BPX.UNIQUE.USER To BPX.NEXT.USER
> 
> See Robert H's very nice presentation
> http://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__April
> _2011.pd
> f
> 
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills
> > Sent: Wednesday, March 08, 2017 7:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Which C library functions imply dub?
> >
> > So do OMVS segments get "auto-created?"
> >
> > I run ALU ROMVSNO NOOMVS and then LU ROMVSNO OMVS. I get
> >
> > NO OMVS INFORMATION
> >
> > Then I run a program that ought to require an OMVS segment. It runs 
> > to a normal completion.
> >
> > I then do another LU ROMVSNO OMVS and I get
> >
> > OMVS INFORMATION
> > 
> > UID= 990013
> > HOME= /u
> > PROGRAM= /bin/sh
> > CPUTIMEMAX= NONE
> > ASSIZEMAX= NONE
> > FILEPROCMAX= NONE
> >
> > What gives?
> >
> > Charles
> >

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

Re: Which C library functions imply dub?

[David Crayford]

On 8/03/2017 10:28 PM, David Griffiths1 wrote:

I understood the original question to be how to avoid OMVS and you almost
certainly need OMVS for printf. For Metal C I wrote my own printf subset
that calls WTO - you at least have varargs.


To me Metal/C is best used for system level programming like AR mode 
programs. It's great for that with __far pointers. For LE I wouldn't use 
C at all.
Why use C when you've got a decent C++ compiler with the STL and the 
other goodies? I hope that z/OS V2.3 delivers more C++11 features. It's 
becoming
difficult to port stuff because of the disparity with compilers from 
other platforms.



Cheers,

Dave Griffiths
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
  




From:   David Crayford <dcrayf...@gmail.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/03/2017 13:52
Subject:    Re: Which C library functions imply dub?
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



On 8/03/2017 9:15 PM, David Griffiths1 wrote:

Hi, not sure of the definitive answer but you can probably take a guess

by

comparing with the Metal C library. By definition Metal C calls don't
require access to the unix kernel. In fact if you don't want to connect

to

OMVS why not use Metal C anyway?

That's a no-brainer! For a simple example how about just being able to
use printf().


Cheers,

Dave Griffiths
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK





From:   Charles Mills <charl...@mcn.org>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/03/2017 02:30
Subject:    Which C library functions imply dub?
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



X-posted from a thread on MVS-OE



How would I determine which standard C library functions imply or cause

a

dub? (Other than by trying them without an OMVS segment and seeing if

they

blow up?) Is this documented somewhere? I guess another way of phrasing
the
question is "how would I determine which standard C library functions

are

'UNIX functions'?"



Do most of them? Surely not strlen()? Does fopen()? Only if you

reference

a
UNIX file as opposed to //DD:FOO?



Charles




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




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

Re: Which C library functions imply dub?

[Lizette Koehler]

A snippet from Robert's presentation

To help replace BPX.DEFAULT.USER, z/OS 1.11 introduced the FACILITY class 
profile BPX.UNIQUE.USER. Defining this newer profile causes RACF to 
automatically add OMVS segments and assign ids to users and groups that do not 
already have segments. RACF creates the segments when the user first accesses 
Unix (i.e., dubs). BPX.UNIQUE.USER 
works in combination with FACILITY class profile BPX.NEXT.USER, which defines 
the uid and gid number ranges to be used for automatic id assignment. Use of 
these profiles requires your databases to be in the Application Identity 
Mapping (AIM) structure.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Wednesday, March 08, 2017 8:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which C library functions imply dub?
> 
> What version of z/OS is this on?
> 
> I am thinking that RACF (or your SAF) is using an auto assign of the UID.
> There was a change when you had to specify the UID in the OMVS Segment, then a
> change happened and the system went from BPX.UNIQUE.USER To BPX.NEXT.USER
> 
> See Robert H's very nice presentation
> http://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__April_2011.pd
> f
> 
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Charles Mills
> > Sent: Wednesday, March 08, 2017 7:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Which C library functions imply dub?
> >
> > So do OMVS segments get "auto-created?"
> >
> > I run ALU ROMVSNO NOOMVS and then LU ROMVSNO OMVS. I get
> >
> > NO OMVS INFORMATION
> >
> > Then I run a program that ought to require an OMVS segment. It runs to
> > a normal completion.
> >
> > I then do another LU ROMVSNO OMVS and I get
> >
> > OMVS INFORMATION
> > 
> > UID= 990013
> > HOME= /u
> > PROGRAM= /bin/sh
> > CPUTIMEMAX= NONE
> > ASSIZEMAX= NONE
> > FILEPROCMAX= NONE
> >
> > What gives?
> >
> > Charles
> >

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

Re: Which C library functions imply dub?

[Lizette Koehler]

What version of z/OS is this on?

I am thinking that RACF (or your SAF) is using an auto assign of the UID.  
There was a change when you had to specify the UID in the OMVS Segment, then a 
change happened and the system went from BPX.UNIQUE.USER
To BPX.NEXT.USER

See Robert H's very nice presentation
http://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__April_2011.pdf


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Wednesday, March 08, 2017 7:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which C library functions imply dub?
> 
> So do OMVS segments get "auto-created?"
> 
> I run ALU ROMVSNO NOOMVS and then LU ROMVSNO OMVS. I get
> 
> NO OMVS INFORMATION
> 
> Then I run a program that ought to require an OMVS segment. It runs to a
> normal completion.
> 
> I then do another LU ROMVSNO OMVS and I get
> 
> OMVS INFORMATION
> 
> UID= 990013
> HOME= /u
> PROGRAM= /bin/sh
> CPUTIMEMAX= NONE
> ASSIZEMAX= NONE
> FILEPROCMAX= NONE
> 
> What gives?
> 
> Charles
> 
> --
> 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

Re: Which C library functions imply dub?

[John McKown]

On Wed, Mar 8, 2017 at 8:16 PM, Charles Mills  wrote:

> So do OMVS segments get "auto-created?"
>
> I run ALU ROMVSNO NOOMVS and then LU ROMVSNO OMVS. I get
>
> NO OMVS INFORMATION
>
> Then I run a program that ought to require an OMVS segment. It runs to a
> normal completion.
>
> I then do another LU ROMVSNO OMVS and I get
>
> OMVS INFORMATION
> 
> UID= 990013
> HOME= /u
> PROGRAM= /bin/sh
> CPUTIMEMAX= NONE
> ASSIZEMAX= NONE
> FILEPROCMAX= NONE
>
> What gives?
>

​Automatic creation of the OMVS segment. There are some RACF profiles set
up in the FACILITY class.

ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha700/autosvcs.htm

​You're on the Dallas Innovation Center? I didn't know that IBM set that up
for you. I remember setting it up on a system there for a friend.​


> Charles
>
>

-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

Re: Which C library functions imply dub?

[Charles Mills]

So do OMVS segments get "auto-created?"

I run ALU ROMVSNO NOOMVS and then LU ROMVSNO OMVS. I get

NO OMVS INFORMATION

Then I run a program that ought to require an OMVS segment. It runs to a normal 
completion.

I then do another LU ROMVSNO OMVS and I get

OMVS INFORMATION
   
UID= 990013
HOME= /u   
PROGRAM= /bin/sh   
CPUTIMEMAX= NONE   
ASSIZEMAX= NONE
FILEPROCMAX= NONE  

What gives?

Charles

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

Re: Which C library functions imply dub?

[Charles Mills]

Thank you -- you know who you are -- ALU

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, March 8, 2017 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which C library functions imply dub?

So how do I delete the darned thing? From IBMUSER I enter

AU ROMVSNO NOOMVS

And I get

IKJ56702I INVALID SEGMENT, NOOMVS  
IKJ56703A REENTER THIS OPERAND -   

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, March 8, 2017 5:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which C library functions imply dub?

Sure enough:

OMVS INFORMATION

UID= 990009 
HOME= /u
PROGRAM= /bin/sh
*** 

Have to tell IBM Dallas that there is a defect in their ADDUROM script: creates 
an OMVS segment even if you say No.

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

Re: Which C library functions imply dub?

[Charles Mills]

So how do I delete the darned thing? From IBMUSER I enter

AU ROMVSNO NOOMVS

And I get

IKJ56702I INVALID SEGMENT, NOOMVS  
IKJ56703A REENTER THIS OPERAND -   

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, March 8, 2017 5:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which C library functions imply dub?

Sure enough:

OMVS INFORMATION

UID= 990009 
HOME= /u
PROGRAM= /bin/sh
*** 

Have to tell IBM Dallas that there is a defect in their ADDUROM script: creates 
an OMVS segment even if you say No.

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

Re: Which C library functions imply dub?

[Charles Mills]

Sure enough:

OMVS INFORMATION

UID= 990009 
HOME= /u
PROGRAM= /bin/sh
*** 

Have to tell IBM Dallas that there is a defect in their ADDUROM script: creates 
an OMVS segment even if you say No.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Wednesday, March 8, 2017 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which C library functions imply dub?

Did you use LU userid OMVS to be sure and request the OMVS segment?

I would guess that your installation uses the auto generation of OMVS segments 
that replaced the default omvs segment support.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Charles Mills
> Sent: Wednesday, March 08, 2017 3:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which C library functions imply dub?
> 
> Well, I have created a userid (cleverly named ROMVSNO) with no OMVS 
> segment and I am getting way into the program before terminating 
> due to other things I have not yet set up. More C library functions 
> than I care to count, and TCP/IP sendto().
> 
> Am I confused? This userid has no OMVS segment, right? Why am I having 
> so much success? What am I missing?
> 
> USER=ROMVSNO  NAME= TEST NO OMVS SEG OWNER=GROUP2
> CREATED=17.067
>  DEFAULT-GROUP=GROUP2   PASSDATE=17.067 PASS-INTERVAL= 60
> PHRASEDATE=N/A
>  ATTRIBUTES=NONE
>  REVOKE DATE=NONE   RESUME DATE=NONE
>  LAST-ACCESS=17.067/17:41:41
>  CLASS AUTHORIZATIONS=NONE
>  NO-INSTALLATION-DATA
>  NO-MODEL-NAME
>  LOGON ALLOWED   (DAYS)  (TIME)
>  -
>  ANYDAY  ANYTIME
>   GROUP=GROUP2AUTH=USE  CONNECT-OWNER=GROUP2CONNECT-
> DATE=17.067
> CONNECTS=12  UACC=NONE LAST-CONNECT=17.067/17:41:41
> CONNECT ATTRIBUTES=NONE
> REVOKE DATE=NONE   RESUME DATE=NONE
> SECURITY-LEVEL=NONE SPECIFIED
> CATEGORY-AUTHORIZATION
>  NONE SPECIFIED
> SECURITY-LABEL=NONE SPECIFIED
> ***
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John McKown
> Sent: Wednesday, March 8, 2017 10:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which C library functions imply dub?
> 
> On Wed, Mar 8, 2017 at 11:54 AM, Don Poitras <sas...@sas.com> wrote:
> 
> > And I suppose, you could fail to dub if you don't have a large 
> > enough region or who knows what else? At least querydub is going to 
> > let you gracefully handle a majority of the customer configuration 
> > errors that result in the 2 a.m. calls where your customer support 
> > has to ask, "have you defined an OMVS RACF segment for the user?"
> > While we've had dozens of these issues, I can't remember ever having 
> > to tell a customer how to setup their UID or GID. Could it be better?
> > Sure. Does it at least conform to an 80/20 rule?
> > Certainly.
> 
> --
> 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

Re: Which C library functions imply dub?

[Charles Mills]

No I did not. Thanks. Will re-do.
I am not a RACF command expert, obviously. 
CharlesSent from a mobile; please excuse the brevity.
 Original message From: "Gibney, Dave" <gib...@wsu.edu> Date: 
3/8/17  4:02 PM  (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Which C 
library functions imply dub? 
Did you use LU userid OMVS to be sure and request the OMVS segment?

I would guess that your installation uses the auto generation of OMVS segments 
that replaced the default omvs segment support.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Charles Mills
> Sent: Wednesday, March 08, 2017 3:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which C library functions imply dub?
> 
> Well, I have created a userid (cleverly named ROMVSNO) with no OMVS
> segment and I am getting way into the program before terminating due
> to other things I have not yet set up. More C library functions than I care to
> count, and TCP/IP sendto().
> 
> Am I confused? This userid has no OMVS segment, right? Why am I having so
> much success? What am I missing?
> 
> USER=ROMVSNO  NAME= TEST NO OMVS SEG OWNER=GROUP2
> CREATED=17.067
>  DEFAULT-GROUP=GROUP2   PASSDATE=17.067 PASS-INTERVAL= 60
> PHRASEDATE=N/A
>  ATTRIBUTES=NONE
>  REVOKE DATE=NONE   RESUME DATE=NONE
>  LAST-ACCESS=17.067/17:41:41
>  CLASS AUTHORIZATIONS=NONE
>  NO-INSTALLATION-DATA
>  NO-MODEL-NAME
>  LOGON ALLOWED   (DAYS)  (TIME)
>  -
>  ANYDAY  ANYTIME
>   GROUP=GROUP2    AUTH=USE  CONNECT-OWNER=GROUP2    CONNECT-
> DATE=17.067
> CONNECTS=    12  UACC=NONE LAST-CONNECT=17.067/17:41:41
> CONNECT ATTRIBUTES=NONE
> REVOKE DATE=NONE   RESUME DATE=NONE
> SECURITY-LEVEL=NONE SPECIFIED
> CATEGORY-AUTHORIZATION
>  NONE SPECIFIED
> SECURITY-LABEL=NONE SPECIFIED
> ***
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John McKown
> Sent: Wednesday, March 8, 2017 10:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which C library functions imply dub?
> 
> On Wed, Mar 8, 2017 at 11:54 AM, Don Poitras <sas...@sas.com> wrote:
> 
> > And I suppose, you could fail to dub if you don't have a large enough
> > region or who knows what else? At least querydub is going to let you
> > gracefully handle a majority of the customer configuration errors that
> > result in the 2 a.m. calls where your customer support has to ask,
> > "have you defined an OMVS RACF segment for the user?"
> > While we've had dozens of these issues, I can't remember ever having
> > to tell a customer how to setup their UID or GID. Could it be better?
> > Sure. Does it at least conform to an 80/20 rule?
> > Certainly.
> 
> --
> 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

Re: Which C library functions imply dub?

[Tony Harminc]

On 8 March 2017 at 18:51, Charles Mills  wrote:
> Am I confused? This userid has no OMVS segment, right? Why am I having so 
> much success? What am I missing?

Did you put OMVS on your LU command? When I issue
LU  OMVS
for such a user, the last line is
NO OMVS INFORMATION

You can even say LU  OMVS NORACF to avoid clutter.

Tony H.

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

Re: Which C library functions imply dub?

[Gibney, Dave]

Did you use LU userid OMVS to be sure and request the OMVS segment?

I would guess that your installation uses the auto generation of OMVS segments 
that replaced the default omvs segment support.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Charles Mills
> Sent: Wednesday, March 08, 2017 3:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which C library functions imply dub?
> 
> Well, I have created a userid (cleverly named ROMVSNO) with no OMVS
> segment and I am getting way into the program before terminating due
> to other things I have not yet set up. More C library functions than I care to
> count, and TCP/IP sendto().
> 
> Am I confused? This userid has no OMVS segment, right? Why am I having so
> much success? What am I missing?
> 
> USER=ROMVSNO  NAME= TEST NO OMVS SEG OWNER=GROUP2
> CREATED=17.067
>  DEFAULT-GROUP=GROUP2   PASSDATE=17.067 PASS-INTERVAL= 60
> PHRASEDATE=N/A
>  ATTRIBUTES=NONE
>  REVOKE DATE=NONE   RESUME DATE=NONE
>  LAST-ACCESS=17.067/17:41:41
>  CLASS AUTHORIZATIONS=NONE
>  NO-INSTALLATION-DATA
>  NO-MODEL-NAME
>  LOGON ALLOWED   (DAYS)  (TIME)
>  -
>  ANYDAY  ANYTIME
>   GROUP=GROUP2AUTH=USE  CONNECT-OWNER=GROUP2CONNECT-
> DATE=17.067
> CONNECTS=12  UACC=NONE LAST-CONNECT=17.067/17:41:41
> CONNECT ATTRIBUTES=NONE
> REVOKE DATE=NONE   RESUME DATE=NONE
> SECURITY-LEVEL=NONE SPECIFIED
> CATEGORY-AUTHORIZATION
>  NONE SPECIFIED
> SECURITY-LABEL=NONE SPECIFIED
> ***
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John McKown
> Sent: Wednesday, March 8, 2017 10:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which C library functions imply dub?
> 
> On Wed, Mar 8, 2017 at 11:54 AM, Don Poitras <sas...@sas.com> wrote:
> 
> > And I suppose, you could fail to dub if you don't have a large enough
> > region or who knows what else? At least querydub is going to let you
> > gracefully handle a majority of the customer configuration errors that
> > result in the 2 a.m. calls where your customer support has to ask,
> > "have you defined an OMVS RACF segment for the user?"
> > While we've had dozens of these issues, I can't remember ever having
> > to tell a customer how to setup their UID or GID. Could it be better?
> > Sure. Does it at least conform to an 80/20 rule?
> > Certainly.
> 
> --
> 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

Re: Which C library functions imply dub?

[Charles Mills]

Well, I have created a userid (cleverly named ROMVSNO) with no OMVS segment and 
I am getting way into the program before terminating due to other things I 
have not yet set up. More C library functions than I care to count, and TCP/IP 
sendto().

Am I confused? This userid has no OMVS segment, right? Why am I having so much 
success? What am I missing?

USER=ROMVSNO  NAME= TEST NO OMVS SEG OWNER=GROUP2CREATED=17.067 
 DEFAULT-GROUP=GROUP2   PASSDATE=17.067 PASS-INTERVAL= 60 PHRASEDATE=N/A
 ATTRIBUTES=NONE
 REVOKE DATE=NONE   RESUME DATE=NONE
 LAST-ACCESS=17.067/17:41:41
 CLASS AUTHORIZATIONS=NONE  
 NO-INSTALLATION-DATA   
 NO-MODEL-NAME  
 LOGON ALLOWED   (DAYS)  (TIME) 
 -  
 ANYDAY  ANYTIME
  GROUP=GROUP2AUTH=USE  CONNECT-OWNER=GROUP2CONNECT-DATE=17.067 
CONNECTS=12  UACC=NONE LAST-CONNECT=17.067/17:41:41 
CONNECT ATTRIBUTES=NONE 
REVOKE DATE=NONE   RESUME DATE=NONE 
SECURITY-LEVEL=NONE SPECIFIED   
CATEGORY-AUTHORIZATION  
 NONE SPECIFIED 
SECURITY-LABEL=NONE SPECIFIED   
*** 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, March 8, 2017 10:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which C library functions imply dub?

On Wed, Mar 8, 2017 at 11:54 AM, Don Poitras <sas...@sas.com> wrote:

> And I suppose, you could fail to dub if you don't have a large enough 
> region or who knows what else? At least querydub is going to let you 
> gracefully handle a majority of the customer configuration errors that 
> result in the 2 a.m. calls where your customer support has to ask, 
> "have you defined an OMVS RACF segment for the user?"
> While we've had dozens of these issues, I can't remember ever having 
> to tell a customer how to setup their UID or GID. Could it be better? 
> Sure. Does it at least conform to an 80/20 rule?
> Certainly.

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

Re: Which C library functions imply dub?

[John McKown]

On Wed, Mar 8, 2017 at 11:54 AM, Don Poitras  wrote:

> And I suppose, you could fail to dub if you don't have a large
> enough region or who knows what else? At least querydub is going
> to let you gracefully handle a majority of the customer configuration
> errors that result in the 2 a.m. calls where your customer support
> has to ask, "have you defined an OMVS RACF segment for the user?"
> While we've had dozens of these issues, I can't remember ever
> having to tell a customer how to setup their UID or GID. Could it
> be better? Sure. Does it at least conform to an 80/20 rule?
> Certainly.
>
>
​Good point. I have a similar desire. If I know that I'm going to use UNIX
services, however, my thought is "go ahead and dub right now when I'm do
all my other set up". My LE enabled HLASM startup code in this case looks
like:

 LAR1_32,CALLX
 LARL R15_32,CEE3INF
 CEEPCALL (15),(SYS,ENV,MEMBER,GPID,FC),VL,X
   LINKINST=BASR,  X
   MF=(E,(1))
 TMSYS,X'04'ALREADY UNIX?
 BOISUNIX   YES, DON'T BOTHER
 LAR1_32,CALLX
 LARL R15_32,BPX1SYC
 CEEPCALL (15),($C_VERSION,X
   RETURN_VALUE,   X
   RETURN_CODE,X
   REASON_CODE),VL,X
   LINKINST=BASR,  X
   MF=(E,(1))
ISUNIX   DS0H

I haven't put in the code after the 2nd CEEPCALL and just before the ISUNIX
label to actually handle any failure from the 2nd CEEPCALL trying to do an
SC_VERSION function. Since I am LE enabled, I use the LE service call
CEE3INF to see if I'm already dubbed instead of QUERYDUB. I guess because
it is my generic way to see if I'm running as "UNIX" or "TSO" or "CICS" or
"nothing special - i.e. batch".


-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

Re: Which C library functions imply dub?

[Don Poitras]

And I suppose, you could fail to dub if you don't have a large
enough region or who knows what else? At least querydub is going
to let you gracefully handle a majority of the customer configuration
errors that result in the 2 a.m. calls where your customer support
has to ask, "have you defined an OMVS RACF segment for the user?"
While we've had dozens of these issues, I can't remember ever 
having to tell a customer how to setup their UID or GID. Could it
be better? Sure. Does it at least conform to an 80/20 rule?
Certainly.

In article  
you wrote:
> On 8 March 2017 at 11:20, Don Poitras  wrote:
> > That's what querydub tells you.

> Well, kind of...

> > ---
> > QDB_DUB_MAY_FAIL  The task has not been dubbed; an attempt to dub the
> > task may fail. The most likely reason for failure may be a missing or
> > incomplete user security profile; or the lack of an OMVS segment.

> And for
> QDB_DUB_OKAY The task has not been dubbed; an attempt to dub
> the task will probably succeed. The service has
> determined that an OMVS segment exists for the
> task. However, it has not checked for other
> potential errors. It is possible that the task may not
> have the proper UID and GID set up in the security
> profile, causing a subsequent dub failure.

> So you can get a QDB_DUB_OKAY from querydub(), and then it can fail on
> exactly the kinds of security system setup things that I listed in the
> post on MVS-OE. Have I mentioned how much I dislike this wishy-washy
> approach to code and explanations in the UNIX world...? It took a fair
> bit of complaining before IBM added the _BPX_SHAREAS=MUST option;
> before that you could only set _BPX_SHAREAS=YES, and if it couldn't
> honour it, well it just silently ignored it.

> Tony H.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Which C library functions imply dub?

[Tony Harminc]

On 8 March 2017 at 11:20, Don Poitras  wrote:
> That's what querydub tells you.

Well, kind of...

> ---
> QDB_DUB_MAY_FAIL  The task has not been dubbed; an attempt to dub the
> task may fail. The most likely reason for failure may be a missing or
> incomplete user security profile; or the lack of an OMVS segment.

And for
QDB_DUB_OKAY The task has not been dubbed; an attempt to dub
the task will probably succeed. The service has
determined that an OMVS segment exists for the
task. However, it has not checked for other
potential errors. It is possible that the task may not
have the proper UID and GID set up in the security
profile, causing a subsequent dub failure.

So you can get a QDB_DUB_OKAY from querydub(), and then it can fail on
exactly the kinds of security system setup things that I listed in the
post on MVS-OE. Have I mentioned how much I dislike this wishy-washy
approach to code and explanations in the UNIX world...? It took a fair
bit of complaining before IBM added the _BPX_SHAREAS=MUST option;
before that you could only set _BPX_SHAREAS=YES, and if it couldn't
honour it, well it just silently ignored it.

Tony H.

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

Re: Which C library functions imply dub?

[Don Poitras]

That's what querydub tells you. 

---
QDB_DUB_MAY_FAIL  The task has not been dubbed; an attempt to dub the
task may fail. The most likely reason for failure may be a missing or
incomplete user security profile; or the lack of an OMVS segment.
---

If the spot you put it in reports that the program is already dubbed, 
then you know you need to move it earlier in the program. i.e. wherever
you put it, you want it to report QDB_DUB_OKAY or QDB_DUB_MAY_FAIL and
take some action based on that.


In article <024801d29826$589bf240$09d3d6c0$@mcn.org> you wrote:
> > I understood the original question to be how to avoid OMVS

> Not exactly. (I love OMVS!) For the original requirement I am going to take
> the liberty of quoting here @Tony Harminc's explanation of the problem.

> > Back 10+ years ago our problem was that we'd ship our product to a new 
> > customer, or an existing customer would install it on a new image, and 
> > they'd overlook our (well documented with examples) requirement for a 
> > userid with a UNIX (OMVS) segment. So we'd get running, open config 
> > files, attach various subtasks, initialize a log, etc. etc.and then at 
> > some point we'd go to open a socket, and Bang! We'd issue a lame 
> > message about a TCP/IP return code, and keep retrying at intervals.
> > Eventually the customer would call support, and someone would work 
> > from the TCP/IP error code to the actual problem and then walk them 
> > through fixing up the userid.

> Prodded by that thread I want to add some call to our code for the purpose
> of explicitly diagnosing the lack of an OMVS segment. The initialization
> sequence for a complex product is of course complicated and I wanted to get
> the test call in the right place: as late in the initialization as possible
> so that as many other diagnostic facilities are available as possible
> ("printed" listing, for example) but before any function that would require
> OMVS and spoil the whole intent of this exercise. I can run an experiment
> but of course a particular situation may not exercise every code path
> through initialization.

> I am wondering if this is not worthy of an RCF to the C library reference.
> Here is a significant prerequisite for some fraction of the calls and it is
> at best documented by implication and folklore.

> Charles


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of David Griffiths1
> Sent: Wednesday, March 8, 2017 6:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Which C library functions imply dub?

> I understood the original question to be how to avoid OMVS and you almost
> certainly need OMVS for printf. For Metal C I wrote my own printf subset
> that calls WTO - you at least have varargs.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Which C library functions imply dub?

[Charles Mills]

> I understood the original question to be how to avoid OMVS

Not exactly. (I love OMVS!) For the original requirement I am going to take
the liberty of quoting here @Tony Harminc's explanation of the problem.

> Back 10+ years ago our problem was that we'd ship our product to a new 
> customer, or an existing customer would install it on a new image, and 
> they'd overlook our (well documented with examples) requirement for a 
> userid with a UNIX (OMVS) segment. So we'd get running, open config 
> files, attach various subtasks, initialize a log, etc. etc.and then at 
> some point we'd go to open a socket, and Bang! We'd issue a lame 
> message about a TCP/IP return code, and keep retrying at intervals.
> Eventually the customer would call support, and someone would work 
> from the TCP/IP error code to the actual problem and then walk them 
> through fixing up the userid.

Prodded by that thread I want to add some call to our code for the purpose
of explicitly diagnosing the lack of an OMVS segment. The initialization
sequence for a complex product is of course complicated and I wanted to get
the test call in the right place: as late in the initialization as possible
so that as many other diagnostic facilities are available as possible
("printed" listing, for example) but before any function that would require
OMVS and spoil the whole intent of this exercise. I can run an experiment
but of course a particular situation may not exercise every code path
through initialization.

I am wondering if this is not worthy of an RCF to the C library reference.
Here is a significant prerequisite for some fraction of the calls and it is
at best documented by implication and folklore.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Griffiths1
Sent: Wednesday, March 8, 2017 6:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Which C library functions imply dub?

I understood the original question to be how to avoid OMVS and you almost
certainly need OMVS for printf. For Metal C I wrote my own printf subset
that calls WTO - you at least have varargs.

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

Re: Which C library functions imply dub?

[David Griffiths1]

Long time ago now but I think I had to avoid sprintf because it required 
__cinit and that in turn created a link to the calling TCB..

Cheers,

Dave Griffiths
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
 



From:   John McKown <john.archie.mck...@gmail.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/03/2017 14:56
Subject:    Re: Which C library functions imply dub?
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



On Wed, Mar 8, 2017 at 8:28 AM, David Griffiths1 <
david_griffit...@uk.ibm.com> wrote:

> I understood the original question to be how to avoid OMVS and you 
almost
> certainly need OMVS for printf. For Metal C I wrote my own printf subset
> that calls WTO - you at least have varargs.
>

​Hum, I just use snprintf() to get the formatted string back into my
program. I then "do whatever" using that string. This was what got me to
writing LE enabled HLASM.​



>
> Cheers,
>
> Dave Griffiths
> z/OS Developer
> IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
>
>
-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

Re: Which C library functions imply dub?

[Paul Gilmartin]

On Wed, 8 Mar 2017 14:28:50 +, David Griffiths1 wrote:

>I understood the original question to be how to avoid OMVS and you almost
>certainly need OMVS for printf. For Metal C I wrote my own printf subset
>that calls WTO - you at least have varargs.
> 
I understood the original question (perhaps on MVS-OE) to be how to
ensure that your task is running under an OMVS-enabled ID.

-- gil

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

Re: Which C library functions imply dub?

[Don Poitras]

What Unix service would get called from printf? I was curious, so I
wrote a simple program:

---
#include   
#include
#define _POSIX_SOURCE
#include   
#pragma linkage(callqdb,OS_NOSTACK)  
#pragma map(callqdb, "BPX1QDB")  
 
void callqdb(int * rv,   
 int * rc,   
 int * rsn   
 );  
 
void main(int args, char **argv, char **env) 
{
int rv, rc, rsn; 
char buffer[80]; 
 
  rv = rc = rsn = 0; 
  callqdb(, , );   
  printf("before printf: rv = %08X, rc = %08X, rsn = %08X\n",
 rv, rc, rsn);   
  rv = rc = rsn = 0; 
  callqdb(, , );   
  printf("after printf:  rv = %08X, rc = %08X, rsn = %08X\n",
 rv, rc, rsn);   
  rc = getcwd(buffer, 80);   
  printf("rc = %08X, cwd = %s\n", rc, buffer);   
  rv = rc = rsn = 0; 
  callqdb(, , );   
  printf("after getcwd:  rv = %08X, rc = %08X, rsn = %08X\n",
 rv, rc, rsn);   
}
---

The output shows that the dub only occured after the getcwd() call:

---
before printf: rv = 0008, rc = , rsn = 
after printf:  rv = 0008, rc = , rsn = 
rc = 2187E2FC, cwd = /u/sasdtp 
after getcwd:  rv = 0001, rc = , rsn = 
---


In article 
<of50d25821.e29d6e03-on802580dd.004f2c48-802580dd.004f8...@notes.na.collabserv.com>
 you wrote:
> I understood the original question to be how to avoid OMVS and you almost 
> certainly need OMVS for printf. For Metal C I wrote my own printf subset 
> that calls WTO - you at least have varargs.

> Cheers,

> Dave Griffiths
> z/OS Developer
> IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
>  



> From:   David Crayford <dcrayf...@gmail.com>
> To:     IBM-MAIN@LISTSERV.UA.EDU
> Date:   08/03/2017 13:52
> Subject:Re: Which C library functions imply dub?
> Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



> On 8/03/2017 9:15 PM, David Griffiths1 wrote:
> > Hi, not sure of the definitive answer but you can probably take a guess 
> by
> > comparing with the Metal C library. By definition Metal C calls don't
> > require access to the unix kernel. In fact if you don't want to connect 
> to
> > OMVS why not use Metal C anyway?

> That's a no-brainer! For a simple example how about just being able to 
> use printf().

> > Cheers,
> >
> > Dave Griffiths
> > z/OS Developer
> > IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
> >
> > 
> >
> >
> >
> > From:   Charles Mills <charl...@mcn.org>
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date:   08/03/2017 02:30
> > Subject:Which C library functions imply dub?
> > Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> >
> >
> >
> > X-posted from a thread on MVS-OE
> >
> > 
> >
> > How would I determine which standard C library functions imply or cause 
> a
> > dub? (Other than by trying them without an OMVS segment and seeing if 
> they
> > blow up?) Is this documented somewhere? I guess another way of phrasing
> > the
> > question is "how would I determine which standard C library functions 
> are
> > 'UNIX functions'?"
> >
> > 
> >
> > Do most of them? Surely not strlen()? Does fopen()? Only if you 
> reference
> > a
> > UNIX file as opposed to //DD:FOO?
> >
> > 
> >
> > Charles

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Which C library functions imply dub?

[John McKown]

On Wed, Mar 8, 2017 at 8:28 AM, David Griffiths1 <
david_griffit...@uk.ibm.com> wrote:

> I understood the original question to be how to avoid OMVS and you almost
> certainly need OMVS for printf. For Metal C I wrote my own printf subset
> that calls WTO - you at least have varargs.
>

​Hum, I just use snprintf() to get the formatted string back into my
program. I then "do whatever" using that string. This was what got me to
writing LE enabled HLASM.​



>
> Cheers,
>
> Dave Griffiths
> z/OS Developer
> IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
>
>
-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

Re: Which C library functions imply dub?

[David Griffiths1]

I understood the original question to be how to avoid OMVS and you almost 
certainly need OMVS for printf. For Metal C I wrote my own printf subset 
that calls WTO - you at least have varargs.

Cheers,

Dave Griffiths
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
 



From:   David Crayford <dcrayf...@gmail.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/03/2017 13:52
Subject:    Re: Which C library functions imply dub?
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



On 8/03/2017 9:15 PM, David Griffiths1 wrote:
> Hi, not sure of the definitive answer but you can probably take a guess 
by
> comparing with the Metal C library. By definition Metal C calls don't
> require access to the unix kernel. In fact if you don't want to connect 
to
> OMVS why not use Metal C anyway?

That's a no-brainer! For a simple example how about just being able to 
use printf().

> Cheers,
>
> Dave Griffiths
> z/OS Developer
> IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK
>
> 
>
>
>
> From:   Charles Mills <charl...@mcn.org>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   08/03/2017 02:30
> Subject:Which C library functions imply dub?
> Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
>
>
> X-posted from a thread on MVS-OE
>
> 
>
> How would I determine which standard C library functions imply or cause 
a
> dub? (Other than by trying them without an OMVS segment and seeing if 
they
> blow up?) Is this documented somewhere? I guess another way of phrasing
> the
> question is "how would I determine which standard C library functions 
are
> 'UNIX functions'?"
>
> 
>
> Do most of them? Surely not strlen()? Does fopen()? Only if you 
reference
> a
> UNIX file as opposed to //DD:FOO?
>
> 
>
> Charles
>
> 
>
>
> --
> 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




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

Re: Which C library functions imply dub?

[David Crayford]

On 8/03/2017 9:15 PM, David Griffiths1 wrote:

Hi, not sure of the definitive answer but you can probably take a guess by
comparing with the Metal C library. By definition Metal C calls don't
require access to the unix kernel. In fact if you don't want to connect to
OMVS why not use Metal C anyway?


That's a no-brainer! For a simple example how about just being able to 
use printf().



Cheers,

Dave Griffiths
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK

  




From:   Charles Mills <charl...@mcn.org>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/03/2017 02:30
Subject:    Which C library functions imply dub?
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



X-posted from a thread on MVS-OE

  


How would I determine which standard C library functions imply or cause a
dub? (Other than by trying them without an OMVS segment and seeing if they
blow up?) Is this documented somewhere? I guess another way of phrasing
the
question is "how would I determine which standard C library functions are
'UNIX functions'?"

  


Do most of them? Surely not strlen()? Does fopen()? Only if you reference
a
UNIX file as opposed to //DD:FOO?

  


Charles

  



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

Re: Which C library functions imply dub?

[Tom Marchant]

On Wed, 8 Mar 2017 13:15:39 +, David Griffiths1 wrote:

>By definition Metal C calls don't
>require access to the unix kernel.

Really? I thought that "by definition" Metal C doesn't require LE.

-- 
Tom Marchant

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

Re: Which C library functions imply dub?

[David Griffiths1]

Hi, not sure of the definitive answer but you can probably take a guess by 
comparing with the Metal C library. By definition Metal C calls don't 
require access to the unix kernel. In fact if you don't want to connect to 
OMVS why not use Metal C anyway?

Cheers,

Dave Griffiths
z/OS Developer
IBM United Kingdom Limited, Hursley Park, Winchester, SO21 2JN, UK

 



From:   Charles Mills <charl...@mcn.org>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/03/2017 02:30
Subject:    Which C library functions imply dub?
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



X-posted from a thread on MVS-OE

 

How would I determine which standard C library functions imply or cause a
dub? (Other than by trying them without an OMVS segment and seeing if they
blow up?) Is this documented somewhere? I guess another way of phrasing 
the
question is "how would I determine which standard C library functions are
'UNIX functions'?"

 

Do most of them? Surely not strlen()? Does fopen()? Only if you reference 
a
UNIX file as opposed to //DD:FOO?

 

Charles 

 


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

Re: Which C library functions imply dub?

[Don Poitras]

I'm not sure if this is a comprehensive list, but if you look at:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxb100/callservd.htm

You'll find the Unix System Services assembler callable services listed by
C function name. There's no guarantee that there _is_ such a C function,
but most of them map one for one.


In article <020a01d2979b$9a13a730$ce3af590$@mcn.org> you wrote:
> X-posted from a thread on MVS-OE
>  
> How would I determine which standard C library functions imply or cause a
> dub? (Other than by trying them without an OMVS segment and seeing if they
> blow up?) Is this documented somewhere? I guess another way of phrasing the
> question is "how would I determine which standard C library functions are
> 'UNIX functions'?"
>  
> Do most of them? Surely not strlen()? Does fopen()? Only if you reference a
> UNIX file as opposed to //DD:FOO?
>  
> Charles 

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Which C library functions imply dub?

[Charles Mills]

X-posted from a thread on MVS-OE

 

How would I determine which standard C library functions imply or cause a
dub? (Other than by trying them without an OMVS segment and seeing if they
blow up?) Is this documented somewhere? I guess another way of phrasing the
question is "how would I determine which standard C library functions are
'UNIX functions'?"

 

Do most of them? Surely not strlen()? Does fopen()? Only if you reference a
UNIX file as opposed to //DD:FOO?

 

Charles 

 


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