× 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 thought I sent this last night but I didn't see it on this list so I'm sending it again.

Rob


On 2/1/2018 12:12 AM, Robert Rogerson wrote:
Hi Buck, I did as you suggested and started two new sessions.  In each I executed the following script.

cl: set2221 c ;    -- This set my library list for test data.
call getstoredocs(cast(23 as int), 'NEW', ' ');     -- Call the stored procedure
cl: dspjob output(*print);    - print the job log

I then saved the two job logs to txt files and used RDi to compare the two text files.  There were a few differences (page headings, times, job numbers) which were to be expected.  There was also a difference in the job stack (although as I said I ran exactly the same  script in both sessions after starting new sessions).  The job Call stack page was...

                                               Job Call Stack

Module or              Ctl
 Type Program                 Statement Identifiers Instruction      Activation Group            Expanded Type          Bdy

      QZDASOINIT QSYS *DFTACTGRP 0000000000000001 QZDASOIT QBUILDSS1    Y
         Procedure: _CXX_PEP__Fv

      QZDASOINIT QSYS 4 *DFTACTGRP 0000000000000001 QZDASOIT   QBUILDSS1    N
         Procedure: main

      QZDASRV    QSYS 10962 *DFTACTGRP 0000000000000001 QZDACMDP   QBUILDSS1    N
         Procedure: QZDACMDP

      QZDASRV    QSYS 24722 *DFTACTGRP 0000000000000001 QZDACMDP   QBUILDSS1    N
         Procedure: SQL_CODE

      QZDASRV    QSYS 25636 *DFTACTGRP 0000000000000001 QZDACMDP   QBUILDSS1    N
         Procedure: SQL_EXTPGM

      QZDASRV    QSYS 24909 *DFTACTGRP 0000000000000001 QZDACMDP   QBUILDSS1    N
         Procedure: SQL_ECALL

      QZDASRV    QSYS 18050 *DFTACTGRP 0000000000000001 QZDASQL    QBUILDSS1    N
         Procedure: QZDASQL

      QZDASRV    QSYS 20811 *DFTACTGRP 0000000000000001 QZDASQL    QBUILDSS1    N
         Procedure: EXECIMD

      QZDASRV    QSYS 20996 *DFTACTGRP 0000000000000001 QZDASQL    QBUILDSS1    N
         Procedure: DOEXECI

      QSQROUTX   QSYS 12437 *DFTACTGRP 0000000000000001 QSQROUTX   QBUILDSS1    N
         Procedure: QSQROUTX

      QSQRUN4    QSYS 18560 *DFTACTGRP 0000000000000001 QSQCALLSP  QBUILDSS1    N
         Procedure: SQL_Call

      QSQRUN4    QSYS 43225 *DFTACTGRP 0000000000000001 QSQCALLSP  QBUILDSS1    N
         Procedure: CALLPROGRAM

*** Both sessions were identical to this point then only the ACS version had the following entries ****

      QCMDEXC1 QSYS2 *DFTACTGRP 0000000000000006 QCMDEXC1 QTEMP        Y
         Procedure: _C_pep

      QCMDEXC1   QSYS2 22 *DFTACTGRP 0000000000000006 QCMDEXC1   QTEMP        N
         Procedure: main

      QSQROUTQ   QSYS 13426 *DFTACTGRP 0000000000000001 QSQROUTQ   QBUILDSS1    Y
         Procedure: SQL_Route3

      QSQRUN4    QSYS 18560 *DFTACTGRP 0000000000000001 QSQCALLSP  QBUILDSS1    N
         Procedure: SQL_Call

      QSQRUN4    QSYS 43225 *DFTACTGRP 0000000000000001 QSQCALLSP  QBUILDSS1    N
         Procedure: CALLPROGRAM

*** At this point the job stack once again became identical ***

      QCMDEXC QSYS 012F *DFTACTGRP 0000000000000001                         N

Other than this I didn't really see anything which I thought may make a difference.  At least it didn't jump out at me.

I have attached links to the two spool files on Dropbox if you want to see for yourself.

https://www.dropbox.com/preview/Public/QPDSPJOB%20ACS.txt?role=personal

https://www.dropbox.com/preview/Public/QPDSPJOB%20iNav.txt?role=personal

Please let me know if you have any other ideas.  This was a great idea and I thought as you suggested something would stand out.

Thanks,

Rob



On 1/31/2018 5:14 PM, Buck Calabro wrote:
On 1/31/2018 4:21 PM, Robert Rogerson wrote:
If I understand you correctly I sign on to all three sessions with the
same user id (RROGERSON).

As for your original suggestion I did check that and both sql sessions
were calling the same procedure and external program.

In the SEP the user id specified is RROGERSON.  When I call I the stored
procedure from ACS and then System i Nav and don't make any changes at
all to the SEP but only the iNav session stop in the debugger.
Well, /something/ is different.
Let's see if we can tease it out.
In both ACS and iNav, run this:

cl: dspjob output(*print);

Something should say Aha! when you compare the two.
I hope.

Maybe I should add that I use ACS exclusively and I have a colleague who
uses iNav exclusively, and neither of us has seen any difference
whatsoever in SEP debug with RDi.




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.