RE: QIBM_QZDA_INIT Exit Program

["Smith, Nelson" <NSmith@xxxxxxxxxxx>]

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.