topic Re: EXPORT/IMPORT SHARED BUFFER in Application Development and Automation Discussions

EXPORT/IMPORT SHARED BUFFER

antony_paul2 — Fri, 03 Jul 2009 13:33:38 GMT

Dear all,

I am using the following statments in my 2 programs. I will briefly explain the scenario..

Here from the first program I am Creating & Submiting a Job. Before creating & submitting the job am trying to

export a ITAB so that it can be used in the JOB. Please find the below 2 statements .

Statment 1. ( Used to Export ITAB from 1st program )

EXPORT it_itab to SHARED BUFFER indx(st) id 'ZIBT'.

Statement 2. ( Used in the 2nd Program whose job I am creating from the 1st after EXPORT )

IMPORT it_itab = it_itab FROM SHARED BUFFER indx(st) ID 'ZIBT'.

This was working perfectly working in DEV & QAS ..

But in the PRD when I ran this for the First time no processing where carried out in the SECOND program I suspect the EXPORT/IMPORT statement Failed.. But the strangest part is when I ran the Program for 2nd time it went perfectly fine i.e 2nd program worked perfectly well......

Questions:

1. Can some sort of time lag happen between EXPORT / IMPORT ... ( will a statment like WAIT UPTO 1 SECOND help ?? )

2. I have not used any statement to remove data from the BUFFER after processing in the 2nd program is it necessary ???

3. Or this can be some other problem ??

Regards,

Antony

Re: EXPORT/IMPORT SHARED BUFFER

Former Member — Fri, 03 Jul 2009 15:52:50 GMT

Hello Antony,

may it be that your DEV&QAS system consists only of one application server, but your PRD lies on several application servers ? SHARED MEMORY means the memory of the specific application server.

So if you export something into shared memory in program 1, you have to be sure, that program 2 runs on the same application server.

But in batch processing (if you don't define a batch job to a specific application server) it's a dynamic scheduling to all application server with have batch work processes. So, if you are lucky, Program2 runs on the same application server as program 1; if not, program2 finds nothing.

Regards Wolfgang

Re: EXPORT/IMPORT SHARED BUFFER

antony_paul2 — Fri, 03 Jul 2009 16:05:50 GMT

Dear Wolfgang,

Thanks for the reply. I guess there is no better explanation for this than what you have already suggested.

May be I can specify the HOST name, in which my DIA runs, as the target HOST for the Background JOB.

Can I Use the system variable SY-HOST. for the below assignment which i will do from my dialog instance ?????


CALL FUNCTION 'JOB_SUBMIT'
     EXPORTING
    ....................................................................
    EXTPGM_SYSTEM                     =  sy-host
    ....................................................................

Regards,

Antony

Re: EXPORT/IMPORT SHARED BUFFER

Former Member — Mon, 06 Jul 2009 07:22:55 GMT

Hello Antony,

think it would be rather the parameter 'Targetserver' in Function 'JOB_CLOSE'. The sequence would be

'JOB_OPEN' - Submit Program ... -JOB_CLOSE . At least on the Rel.4.7 where i'm working.

Regards Wolfgang

Re: EXPORT/IMPORT SHARED BUFFER

vigneshyeram — Thu, 21 Feb 2013 10:09:08 GMT

Hi Antony, Hi Wolfgang,

I think it is not a good idea to force program2 to run on same application server that of program1 is running because it might happen that all the work process of the application server on which program1 is running are all occupied, means no work process of the application server is free. In this case if we try to force the program2 on same application server it might go in wait in production system, for forcing the job on same application server sy-host of program1 should be passed to FM JOB_SUBMIT parameter Targetsystem not Targetserver.I checked with targetserver it fails and it works when you pass sy-host to Targetsystem.

Instead we have another solution to use DATABASE instead of SHARED BUFFER in EXPORT and IMPORT statements.

EXPORT itab FROM itab TO DATABASE indx(ar) CLIENT sy-mandt ID job_number in program1 where job number is unique.

Then
IMPORT itab TO itab FROM DATABASE indx(ar) CLIENT sy-mandt ID job_number in program2 where job number is passed from program1 to program2 while submit job.

Then DELETE FROM DATABASE indx(ar) CLIENT sy-mandt ID job_number.

Regards,

Vignesh Yeram

Re: EXPORT/IMPORT SHARED BUFFER

vigneshyeram — Thu, 21 Feb 2013 10:09:35 GMT

Hi Antony, Hi Wolfgang,

I think it is not a good idea to force program2 to run on same application server that of program1 is running because it might happen that all the work process of the application server on which program1 is running are all occupied, means no work process of the application server is free. In this case if we try to force the program2 on same application server it might go in wait in production system, for forcing the job on same application server sy-host of program1( SY-HOST returns only the first part (<host name>), This value (<host name>_<SAP system name>_<SAP system number>) can be find with the FM SBUF_PARAMETER_GET should be passed to FM JOB_SUBMIT parameter Targetsystem not Targetserver.I checked with targetserver it fails and it works when you pass sy-host to Targetsystem.

Instead we have another solution to use DATABASE instead of SHARED BUFFER in EXPORT and IMPORT statements.

EXPORT itab FROM itab TO DATABASE indx(ar) CLIENT sy-mandt ID job_number in program1 where job number is unique.

Then
IMPORT itab TO itab FROM DATABASE indx(ar) CLIENT sy-mandt ID job_number in program2 where job number is passed from program1 to program2 while submit job.

Then DELETE FROM DATABASE indx(ar) CLIENT sy-mandt ID job_number.

Regards,

Vignesh Yeram

Message was edited by: Vignesh Yeram

Re: EXPORT/IMPORT SHARED BUFFER

vigneshyeram — Tue, 26 Feb 2013 16:17:56 GMT

Hi Antony, Hi Wolfgang,

EXPORT itab FROM itab TO DATABASE indx(ar) CLIENT sy-mandt ID job_number in program1 where job number is unique.

Then
IMPORT itab TO itab FROM DATABASE indx(ar) CLIENT sy-mandt ID job_number in program2 where job number is passed from program1 to program2 while submit job.

Then DELETE FROM DATABASE indx(ar) CLIENT sy-mandt ID job_number.

Regards,

Vignesh Yeram