|
Hi Stu, I was checking something and stumbled upon this under the topic :ILE CEE API Calling Conventions. Note: If you use ILE RPG to call ILE CEE APIs, the following restriction applies: APIs cannot be used if DFTACTGRP(*YES) is specified on the CRTBNDRPG CL command. ILE static binding is not available when a program is created with DFTACTGRP(*YES). This means that your program cannot contain a CALLB operation. (Also, you cannot use the BNDDIR or ACTGRP parameters when creating this program.) Specifying DFTACTGRP(*YES) during the creation of an ILE RPG program means that the program will always run in the default activation group. See the ILE RPG for AS/400 Programmer's Guide for more information about the CRTBNDRPG CL command and the DFTACTGRP parameter. Has your problem something to do with your named activation group? Thanks, Sudha Sudha Ramanujan SunGard Futures Systems sramanujan@xxxxxxxxxxxxxxxxxx (312) 577 6179 (312) 577 6101 - Fax -----Original Message----- From: Bramley, Stu [mailto:stu.bramley@xxxxxxxxxxxxx] Sent: Friday, August 06, 2004 4:02 AM To: 'Midrange Systems Technical Discussion' Subject: CEETREC I have a SQL UDF that needs to call an existing RPG program. This RPG program is defined as a SQL Stored Procedure to enable it to be called from the UDF. The RPG program does a reasonable amount of processing to return a result - part of this processing involves calling into an ILE RPG wrapper that calls into a Service Program procedure. This call takes place in a named activation group. As part of the closedown processing for the wrapper/service program there is a call to CEETREC to clean up the named activation group. So in effect you have the following : SQL UDF RPGPGMA (*DFTACTGRP) RPGPGMB (NAMEDAG) RPGSRVPGM (*CALLER) When the call to CEETREC happens, not only does it end NAMEDAG, it is also causing SQL to, in my best technical terminology, collapse in a great big heap. If I call the SQL UDF from a 5250 STRSQL session then it throws me back to my initial signon program. If I call it from OpsNav then I quickly end up with pages and pages of job logs with the messages 'Error occurred in the OS/400 database server code.' and 'Message key not found in message queue QJOBMSGQ.' My understanding of CEETREC was that it issued a normal of all programs running in the current activation group, back as far as the first control boundary that it encounters - so when it is issued from within NAMEDAG in the instance above it should terminate RPGSRVPGM and RPGPGMB without having any impact on anything running outside of that activation group. Clearly from what is happening to the SQL processing this is not the case. Can anyone explain why? Are there other instances where CEETREC can have impacts outside of the activation group from which it is issued? To further confuse me, I wrote a couple of test programs to try and observe the effects of CEETREC... PGMA ACTGRP(NAMED) calls PGMB *DFTACTGRP calls PGMC ACTGRP(NAMED) which calls CEETREC Using a utility which uses the QWVOLAGP API to display the current job's activation groups I checked to see what was still active in the job. I had expected that PGMA would still be active. However this was not the case - both PGMA and PGMC were still active in the NAMED activation group - despite PGMC having called CEETREC? As a footnote - if I simply call the RPG program from SQL as a stored procedure (not from within the UDF) everything is fine. Cheers, Stu Stuart Bramley Senior Technical Developer Skandia Life::GroupIT Southampton t: 023 80 72 64 29 e: stu.bramley@xxxxxxxxxxxxx IBM Certified Specialist If you are not the intended recipient, please notify the sender by return email and then delete the message from your computer. The Skandia UK Group reserves the right to monitor e-mail communications through its networks. No contract may be concluded on behalf of the Skandia UK Group by email. Skandia Life Assurance (Holdings) Limited Skandia Life Assurance Company Limited Skandia MultiFUNDS Limited, Skandia Investment Management Limited. Registered Nos: 1606702, 1363932, 1680071, 4227837, England Registered Office: Skandia House, Portland Terrace, Southampton SO14 7EJ, United Kingdom Royal Skandia Life Assurance Limited Registered No : 24916 Isle of Man Registered Office: Skandia House, King Edward Road, Onchan, Isle of Man IM99 1NU, British Isles Skandia Life Assurance Company Limited, Skandia MultiFUNDS Limited, Skandia Investment Management Limited and Royal Skandia Life Assurance Limited are authorised and regulated by the Financial Services Authority for UK investment business. Internet: www.skandia.co.uk -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx 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.
midrange.com
