RE: QIBM_QZDA_INIT Exit Program

[Kurt Goolsbee <Kurt.Goolsbee@xxxxxxxxx>]

Have you cycled the QSERVER subsystem?  When dealing with exit programs for
the database and file servers you usually have to cycle the subsystem.  Your
previous email indicated confusion about the value of parm 1  - it should be
0xF1 for approve and 0xF0 for reject.

> -----Original Message-----
> From: Smith, Nelson [SMTP:NSmith@lincare.com]
> Sent: Wednesday, January 22, 2003 2:00 PM
> To:   'Midrange Systems Technical Discussion'
> Subject:      RE: QIBM_QZDA_INIT Exit Program
> 
> Thanks for your replies Todd, Vern.  
> 
> Yes, I did stop and start Qzdasoinit (many times).  Program uses adopted
> authority and public *change.  Library also has public *change.  Even
> though
> it is a cl, I'm setting the return parm as you did below.  Is there
> anything
> special to do in registering the exit program? I just added it using
> WrkRegInf.  It seems to be active ok, since it is rejecting attempts to
> sign
> on (I do get the sign on box) in the client program.  The rejection error
> says it is due to my exit program, but I can't get debug to break in it or
> get the exit program to do anything (like send a message), so I don't
> think
> it is actually executing.  I'm using Access as a client program trying to
> connect.  
> 
> I'll see what I can find on the utility.
> 
> 
> > -----Original Message-----
> > From:       Todd kidwell [SMTP:Todd.kidwell@3cc.co.wayne.mi.us]
> > Sent:       Wednesday, January 22, 2003 9:57 AM
> > To: midrange-l@midrange.com
> > Subject:    RE: QIBM_QZDA_INIT Exit Program
> > 
> > Nelson,
> > 
> > The thing to keep in mind with these exit programs is that they stay in
> > effect until the server job (QZDASOINIT)  that used it has ended.  If
> you
> > have changed the program, you will need to end the server jobs before
> your
> > new program gets called.  Someone on this list wrote a great utility
> > called WRKODBCJOBS.  If you are going to be writing exit programs for
> > ODBC, it would definitely be worth your time to get this utility.
> > 
> > Another place to look is user authority.  I run the program using
> adopted
> > authority and public *USE.
> > 
> > My program was written in RPG, but you should be able to get the gist
> ...
> > 
> >   * ****************************************
> >   * Procedure Interface                     
> >   * ****************************************
> >                                             
> >  D EPODBCSIRG      PI                       
> >  D  outRtnCde                     1         
> >  D  inValues                       32    Value
> > 
> >  D dsValues        DS                 
> >  D  vaUsrPrf                       10   
> >  D  vaServerId                   10   
> >  D  vaFormat                        8   
> >  D  vaRequest                    10I 0
> > 
> >  C                   Eval      dsValues = inValues
> > 
> > **** do processing to determine return code *****
> > 
> > **** allow ****
> > 
> >  C                   Eval      outRtnCde = '1'
> > 
> >  C                   Else                                              
> > 
> > **** don't allow ****
> > 
> >  C                   Eval     outRtnCde = '0'
> >                                               
> >  C                   Eval      *InLR = *On    
> >                                             
> > Thanks,                                            
> > 
> > Todd Kidwell (Netstar)
> > AS/400 System Administrator
> > (313) 224-0578
> > 
> > >>> "Smith, Nelson" <NSmith@lincare.com> 01/22/03 08:59AM >>>
> > I'm trying to attach an exit program to the QIBM_QZDA_INIT, using the
> > example CL program from the manual as a guide and am getting nowhere.
> My
> > CL
> > program is written to do nothing at this time but send me a message
> saying
> > it has been called and doing a DMPCLPGM so that I can look at the
> incoming
> > parms.  According to one section of the manual, and the sample program,
> I
> > need to set the first incoming parm to '1' to signify normal and to let
> > the
> > exit point continue without interruption.  Another section of manual
> > states
> > the opposite, that my program needs to set it to '0' to continue.  I
> even
> > found some discussion on one of IBM's sites regarding  the confusion in
> > documentation which said to always use X'F1' to allow and X'F0' to
> reject.
> > 
> > No matter how I try to set this parameter, it appears that the mere act
> of
> > registering the exit program to the exit point causes it to always
> reject
> > without even getting into the program far enough to get to the CHGVAR
> > statement.  The error I get on programs trying to use ODBC is that my
> exit
> > program caused it to reject the connection.  By setting up a breakpoint
> in
> > the program (in batch) and the lack of a message or dump being executed,
> > it
> > appears that my program is never executing, yet the error message on the
> > client side contains my exit program's name. It may only have that
> > information due to the fact that it is registered. 
> > 
> > What am I missing here?  Does anyone have a working sample of an exit
> > program for this exit point?  I'm on V4R5.
> > 
> > >  
> > 
> > 
> >
> **************************************************************************
> >
> **************************************************************************
> > ********************************************************
> > This message originates from Lincare Holdings Inc. It contains
> information
> > which may be confidential or privileged and is intended only for the
> > individual or entity named above.
> > It is prohibited for anyone else to disclose, copy, distribute or use
> the
> > contents of this message. 
> > All personal messages express views solely of the sender, which are not
> to
> > be attributed to Lincare Holdings Inc., and may not be copied or
> > distributed without this disclaimer. 
> > If you received this message in error, please notify us immediately at
> > MailAdmin@lincare.com or (800) 284-2006.
> >
> **************************************************************************
> >
> **************************************************************************
> > ********************************************************
> > 
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > list
> > To post a message email: MIDRANGE-L@midrange.com 
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo.cgi/midrange-l 
> > or email: MIDRANGE-L-request@midrange.com 
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> > 
> > 
> > 
> > 
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > list
> > To post a message email: MIDRANGE-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo.cgi/midrange-l
> > or email: MIDRANGE-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo.cgi/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.