× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I sent this to the Midrange list on Friday, but it didn't attract any
responses... I wondered if this list might have been a more appropriate
place to ask the question..

Cheers,
Stu

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bramley, Stu
Sent: Friday 06 August 2004 10:02
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.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.