Right. Thanks. I have since looked up the relevant return codes.

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. 

I would probably log any "unexpected" return code and proceed, hoping for the 
best. I would rather U4093 than not try in a situation where I might have 
succeeded.

I've never used the BPX1xxxx services that I recall. They seem to be intended 
for assembler programs but I would hope I can find C calling instructions 
somewhere. Worst case I can just code up my own extern "OS" ...

I don't know exactly where I fail. My test userid has an OMVS segment. I just 
saw it fail ugly (U4093/90 I think) at a customer. The customer inexplicably 
(why do customers do these things to themselves?) has his system set up so all 
output from an STC is automatically and instantly purged, so whatever evidence 
of where I was has gone to bit heaven. Hopefully LE does not try the dub and 
fail before my "user" C code gets going, leaving me with no chance to diagnose 
the problem in a user-friendly manner.

I can get a userid set up on my system that does not have an OVMS segment but 
that is obviously a small chore of its own.       

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Tony Harminc
Sent: Wednesday, September 10, 2014 5:36 PM
To: [email protected]
Subject: Re: How tell if have OMVS Segment

On 10 September 2014 19:17, Charles Mills <[email protected]> wrote:
> Am I correct in assuming that "cannot be dubbed ..." == lacking an OMVS 
> segment?

Close, but not exactly. There are several more subtle reasons that may cause a 
dub to fail. What I've done (in assembler code, but it could be in C and 
probably others) is to call a harmless and fast UNIX service (I use sysconf() 
BPX1SYC) early in startup that will fail with return and reason codes if UNIX 
services in general won't work. Then I put out a message, rather than have 
TCP/IP or some other service I need fail later on.

But there is a chicken & egg problem, in that the UNIX kernel service to 
retrieve message text from return and/or reason codes itself requires that your 
process be dubbed. (I complained about this years ago, but at least back then 
IBM had no plans to change this
behaviour.) So I have a short list of hardcoded return and reason codes taken 
from the book, and I issue a hopefully useful message to explain the detailed 
reason rather then a generic "dub failed"
message. You can look up return code EMVSINITIAL and see what the possible 
reason codes are - things like:
JRSAFNOUSER: The user ID is not defined to the security product
JRSAFNOGID: The user ID is in a group that has no GID and so on. EMVSINITIAL is 
the common problem, but there might also be other return codes that indicate 
startup problems: EMVSNOTUP, EMVSERR, EMVSSAF2ERR, and maybe others.

Of course you'll want to show the actual return and reason codes so that if IBM 
has added one since you checked, the end user can look it up.

Your situation may well have a different chicken & egg issue; I don't know what 
provokes LE to issue its U4093 abend, but it may be that it tries to get dubbed 
on its own initiative and that's its polite way of saying that the attempt 
failed. In which case you may be too late to do what I suggested, or even to 
use querydub() as Bob did.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to