3

Here's an ISPF panel definition:

)BODY
 Hello, world!
)PROC
*REXX
ADDRESS ISPEXEC "CONTROL ERRORS CANCEL"
*ENDREXX
)END

The panel displays fine, but the imbedded REXX immediately fails:

*-*  ADDRESS ISPEXEC "CONTROL ERRORS CANCEL"
+++ RC(-3) +++

A return code of -3 typically means that the command environment doesn't know what to do with the command.

It seems reasonable that an ISPF panel would be able to cope with an ISPF request. Any idea what's going on?

Steve Ives
  • 7,894
  • 3
  • 24
  • 55
Oh Come On
  • 153
  • 8

3 Answers3

7

*REXX code cannot issue ISPF service requests as per note 5 in the article:

The *REXX statement.

I'd suggest having a good read of the article.

Juergen
  • 63
  • 3
MikeT
  • 51,415
  • 16
  • 49
  • 68
2

MikeT is absolutely correct as is stated in the ISPF Dialog Developer's Guide. I would suggest downloading the ISPF PDF's if you will be maintaining or coding ISPF services

http://www-03.ibm.com/systems/z/os/zos/library/bkserv/v2r2pdf/#ISP

Marv Knight
  • 416
  • 2
  • 4
  • I suppose it comes down to the ISPF TCB chain and invoking services from REXX is out of the mix. REXX exits are a welcome addition to ISPF but it would be so cool if panel logic could be replaced entirely by REXX with a function environment to do stuff like VER. – David Crayford Mar 28 '17 at 12:28
2

As has been stated the ISPF services are not available in Panel REXX. But that shouldn't prevent you from accessing ISPF variables and updating them from REXX.

Before doing the *REXX(.... just do a VGET of the ISPF variable and then code the *REXX thus

REXX( variable1 variable2 ...)

You will have access to many REXX services (listdsi, sysdsn, ...)

You can also set a variable (must be defined in the *REXX) that you can test in ISPF Panel code to do something. One example is to set a variable in REXX, then test in PANEL code to issue an ISPF message.

Hopefully this helps.

Lionel B Dyck
  • 552
  • 2
  • 9