HELP - ABAP Program Cancelled After Running for 2.5 Hours in Background

[Former Member]

I have an ABAP report program that was being tested in our QA system and it died after running for 2.5 hours with the status of "Cancelled" (which, I assume, means it was terminated by SAP for exceeding some type of governor).

I ran Code Analyzer and no performance issues were recognized.

I am running several SELECT statements during program execution. These are a list of all the SELECT statements used in my program. Also, I'm using PNPCE to get a list of pernrs for which to pull data at the beginning of the program.

SELECT *
      INTO CORRESPONDING FIELDS OF TABLE gt_p0167
      FROM pa0167
      WHERE pernr EQ gt_selected_pernrs
        AND bplan IN s_bplan
        AND begda LE pn-endda
        AND endda GE pn-begda.

          SELECT SINGLE fgbdt fasex
            INTO (lv_dob, lv_gender)
            FROM pa0021
            WHERE pernr EQ gt_selected_pernrs
              AND subty EQ <fs_dtyxx>
              AND objps EQ <fs_didxx>
              AND begda LE pn-endda
              AND endda GE pn-begda.

  SELECT SINGLE agency ansvh
    INTO (p_agency_out, lv_ansvh)
    FROM pa0001
    WHERE pernr EQ p_pernr_in
      AND begda LE pn-endda
      AND endda GE pn-begda.

  SELECT SINGLE vorna nachn gbdat perid gesch
    INTO (gt_control_table-fname, gt_control_table-lname, gt_control_table-dob, gt_control_table-mskssn, gt_control_table-gender)
    FROM pa0002
    WHERE pernr EQ p_pernr_in
      AND begda LE pn-endda
      AND endda GE pn-begda.

  SELECT SINGLE perid
    INTO (lv_ssn)
    FROM pa0106
    WHERE pernr EQ p_pernr_in
      AND subty EQ p_subty_in
      AND objps EQ p_objps_in
      AND begda LE pn-endda
      AND endda GE pn-begda.

  SELECT SINGLE smoke
    INTO (p_smoker_out)
    FROM pa0376
    WHERE pernr = p_pernr_in
      AND begda LE pn-endda
      AND endda GE pn-begda.

  SELECT SINGLE state pstlz zcounty
    INTO (p_state_out, lv_zip, p_county_out)
    FROM pa0006
    WHERE pernr EQ p_pernr_in
      AND begda LE pn-endda
      AND endda GE pn-begda.

  SELECT SINGLE werks btrtl
    INTO (lv_werks, lv_btrtl)
    FROM pa0001
    WHERE pernr EQ p_pernr_in
      AND begda LE pn-endda
      AND endda GE pn-begda.

    SELECT SINGLE region
      INTO (p_region_out)
      FROM zpat_county_code
      WHERE county EQ p_county_in.

      SELECT SINGLE pernr
        INTO lv_pernr
        FROM pa0002
        WHERE perid EQ gt_cobra_table-l_essn.

  SELECT SINGLE eecst ercst
    INTO (lv_eecst, lv_ercst)
    FROM t5ubi
    WHERE barea EQ '01'
      AND bplan EQ lv_bplan
      AND bcost EQ p_bcost_in
      AND cstv1 EQ '0001'
      AND smoke EQ p_smoker_in
      AND begda LE pn-endda
      AND endda GE pn-begda.

    SELECT SINGLE kwert
      INTO lv_kwert
      FROM t511k
      WHERE molga EQ '10'
        AND konst EQ 'ZCOB1'
        AND begda LE pn-endda
        AND endda GE pn-begda.

[Former Member]

The SELECTs don't seem too bad. What was the exact error message?

And the portion of the code where it dumped.

Rob

Edited by: Rob Burbank on Sep 18, 2008 9:36 AM

[Former Member]

The screen shot the tester sent me only says that it was canceled. However, the log shows the following:

09/17/2008 16:54:32 Job Started

09/17/2008 16:54:32 Step 001 started (program ZBNI001...

09/17/2008 19:22:09 ABAP/4 processor: DATASET_NOT_OPEN

09/17/2008 19:22:09 Job cancelled

I'm not sure it was an error, per se, but maybe SAP canceled it because it had been running too long? The "DATASET_NOT_OPEN" is curious although I've no idea what it means.

Thanks for your help.

[Former Member]

Use transaction ST22 to look at the dump. I think you'll see that the problem is that you were trying to write to a dataset on the application server that was not opened.

This has nothing to do with how long the program was running.

Rob

[Former Member]

OK, well, that's good to know (that it's not timing out). Although 2.5 hours seems awfully long for this program although I don't know what period the user was running it for so I suppose it's not all that unusual.

Yes, I think this may have to do with permissions to the application server's file system; the program may not have access to write the file. I'll check on that.

Thanks!

[Former Member]

The user who set this job up to run entered a local path on the selection screen. Obviously, that wasn't going to work in background mode.