× 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.


  1.  Home
  2. RPG400-L
  3. March 2006

Re: Help in Call Stack Entires.

 
  Hi Scott,
  Thanks a bunch for your elaborate answer.
  I will explain you what is the issue. There is a monitor job which ran fine 
till a week back. But suddently it errors out with MCH0601  (This I can see 
from the QPRGDMP). The error message says
   
   MESSAGE ID-                   MCH0601 
MESSAGE FILE-                 QCPFMSG 
SEVERITY-                     40      
MSGTYPE-                      0F      
   
  Space offset X'00001E16' or teraspace offset X'0000000000000000' is
outside current limit for object QSCPROBLEM
   
  QSCPROBLEM is a user space which resides in some system library (Starting 
with Q, I don have the job log now)
   
  I checked the call stack entry in the job-log when the error occured: That 
reads as below (XRPG1124 is an ILE program)
   
  XRPG124 PRODLIB1 10800 008E 000
> QCMDEXC QSYS 0129 000
> XCL127 PRODLIB2 128 0051 000
> QCATRS QSYS 01EE 000
> EXECHKR SEQUEL 0005 000
> < SQLSERVERV SEQUEL 000
> Procedure: _QRNP_PEP_SQLSERVERV
> < vationInit QSYS 0000001534 000
> Procedure: Q LE leActivationInit
> < InitRouter QSYS 0000001567 000
> Procedure: Q LE leActivationInitRouter
> < initlocale QSYS 0000000004 000
> Procedure: _C_PSX_initlocale
> < _setlocale QSYS 0000001114 000
> Procedure: _C_PSX_setlocale
> < lex__FiPCc QSYS 0000001169 000
   Procedure: setlocalex__FiPCc                                                 
  < _setlocale   QSYS       0000001114                                  000 
   Procedure: _C_PSX_setlocale                                           
< lex__FiPCc   QSYS       0000001189                                  000 
   Procedure: setlocalex__FiPCc                                          
< a_from_API   QSYS       0000002446                                  000 
   Procedure: _C_get_locale_data_from_API                                
 < _space_ptr   QSYS       0000002371                                  000 
   Procedure: _C_Get_temp_space_ptr                                      
 < formation2   QSYS       0000001536                                  000 
  Procedure: QlgRetrieveLocaleInformation2                              
 < FP7Globe_v   QSYS       0000001787                                  000 
  Procedure: Get_Pointer_to_object__FP7Globe_v                          
< riP6Qus_EC   QSYS       0000000484                                  000 
  Procedure: Qp0lGetObjectAttr__FP12qlg_pathnameP5vattrP12qp0l_sysattri 
< l_sysattri   QSYS       0000002130                                  000 
< _nameidata   QSYS       0000003019                                  000 
  Procedure: qp0l_lookupv__FP13qp0l_pathnameiP14qp0l_nameidata                  
  < curdir__Fv   QSYS       0000000796                                  000 
  Procedure: qp0l_set_curdir__Fv                                          
_CXX_PEP     QSYS       0000000583                                  000 
  main         QSYS       0000000564                                  000 
< twareError   QSYS       0000000499                                  000 
  Procedure: QpdReportSoftwareError                                     

  Finally the call ends in the API, QpdReportSoftwareError and thus the error 
MCH0601 comes. I really confused how the call comes to this API. (I searched 
about the API and I found out that this will log all the spool files related to 
any software problem and system qdministrator has to look into this using 
WRKPRB.)
   
  I believe that this API tries to report the some software error and write 
into the user space QSCPROBLEM. And all on a sudden MCH0601 occurs. 
   
  So I want to learn about the call stack and particularly how the call gets 
diverted to leActivationInit. Thereby atleast I can track what is the problem 
(if any bug in my code or I need to report IBM and get the PTF applied to my 
OS).
   
  I noted one thing. I gave WRKOBJ and checked the QSCPROBLEM and it seemed to 
be created on the day Feb 26. And this issues started occuring after that. Also 
the thing to note that this error is not occuring always at some point of time 
After that when the job gets restarted, it runs fine.
   
  There are other two jobs also ended with the same error and at random time. 
They also do have call identical call stack entries  with the call starting 
with leActivationInit.
   
   
  Really this issue kills us and makes  us baffled. Please help me if you have 
any clue

Thanks
  Avis.
   
   
  
Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:
  
If you look further over to the right-hand side of this call stack, you 
should see ILE program and module names as well, which might help make it 
easier to understand.

The idea of a call stack is that each time a program or procedure calls 
another program or procedure, the new one gets added to the stack. When a 
program or procedure finishes, it gets removed from the stack.

This includes routines in the operating system that get called as a result 
of you performing an opcode or BIF as well as program or procedure calls 
that you've made explicitly in your program.

So in the example you've provided, a program called XRPG124 (which is NOT 
ILE, unless you've left part of the call stack out!) is calling a program 
called QCMDEXC. As you may know, QCMDEXC is an API that allows you to 
submit a command string to be interpreted and run. QCMDEXC calls XCL127, 
which appears to be an OPM CL program. That program must run a SEQUEL 
command of some sort. QCATRS is the operating system program that calls 
(among other things) validity checking programs (VCP). Based on the name, 
I'm guessing the SEQUEL has a validity checking program named EXECHKR. 
EXECHKR then calls another program (this one is ILE) named SQLSERVERV.

__QRNP_PEP_SQLSERVERV is the "Program Entry Procedure" for SQLSERVERV. 
This is not a procedure that a programmer wrote, but rather one that's 
generated by the ILE program creation tools to give the program a place to 
start processing.

Apparently, this PEP also calls an operating system routine called "Q LE 
leActivationInit", which in turn calls "Q LE leActivationInitRouter", etc.

Why do you ask this? Are you having trouble with these programs?


On Wed, 1 Mar 2006, Avis Ramuk wrote:

> Hi,
>
>
> I have a RPGLE pogram named XRPG which gets executed as a job. At some point, 
> this CLP calls another CLP program XCL127. In this program, Execute command 
> is used to run a SQL query. Now the call stack read as below:
>
> XRPG124 PRODLIB1 10800 008E 000
> QCMDEXC QSYS 0129 000
> XCL127 PRODLIB2 128 0051 000
> QCATRS QSYS 01EE 000
> EXECHKR SEQUEL 0005 000
> < SQLSERVERV SEQUEL 000
> Procedure: _QRNP_PEP_SQLSERVERV
> < vationInit QSYS 0000001534 000
> Procedure: Q LE leActivationInit
> < InitRouter QSYS 0000001567 000
> Procedure: Q LE leActivationInitRouter
> < initlocale QSYS 0000000004 000
> Procedure: _C_PSX_initlocale
> < _setlocale QSYS 0000001114 000
> Procedure: _C_PSX_setlocale
> < lex__FiPCc QSYS 0000001169 000
> ..continues..
>
> I want someone to help me in explaining how and why this call happens. 
> Especially I want to know when/why leactivationinit gets called. Can 
> anyone please explain this?.

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Replies:
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.