|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.