This is rather uncommon: but it is used in HR for transaction PA30 to hide or show screen fields controlled via customizing. In effect a list of fields that is available on the screen (dynpro) is made available in a customizing table (T588M) and from there the system can hide fields or make them readonly. A special statement is available for this.
I personally find this a bit prehistoric, but nonetheless, statement IMPORT DYNPRO is available and it is not even obsolete. There is however a warning stating "This statement is for internal use only. It must not be used in application programs". There's no need for it's use as all information it is supplying is readily available in tables.
Here's an example of the use of this statement:
DATA: lw_D020S type D020S,
lt_D021S type standard table of D021S,
lt_D022S type standard table of D022S,
lt_D023S type standard table of D023S,
BEGIN OF lw_ACT_DYNP,
PROG LIKE D020S-PROG,
DNUM LIKE D020S-DNUM,
VARKY LIKE T588M-VARKY,
END OF lw_ACT_DYNP.
lw_ACT_DYNP-PROG = 'SAPL0PXV'.
lw_ACT_DYNP-DNUM = '5012'.
* Example use on main program SAPL0PXV Include L0PXVF01
* line 143 (HR, T588M field control)
IMPORT DYNPRO lw_D020S lt_D021S lt_D022S lt_D023S
ID lw_ACT_DYNP.
Next to the IMPORT DYNPRO statement, there's also an EXPORT DYNPRO, DELETE DYNPRO, a SYNTAX-CHECK FOR DYNPRO and a GENERATE DYNPRO. Some of these could come in handy if you are moving applications across systems - where using customer packages is not readily available. These are development matters, not to be used in day-to-day applications (as SAP states in on-line help).