RE: CEETREC

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.