REXX / z/OS question

Question

Hi, I'm wondering one thing with REXX-language, how it handles data set locks. The situation: - I have sequential data set open in my ISPF-editor - I start REXX-program what updates (makes changes) that data set - it works fine, but how it is possible? Normally if you have data set open in your editor and you try to use that from another program (for example if you submit some job), you'll get message "Data set in use". Why this works with REXX here. Maybe same address space or...? Can anyone tell me?

Answer 1

REXX does not manage dataset locking. REXX calls upon service modules to allocate datasets and perform I/O on them. The I/O service routine under TSO is called EXECIO. Before EXECIO can operate on a dataset it must be allocated under TSO to some DDName. This DDName is then referenced in the EXECIO request.

Datasets may be allocated directly from the TSO command prompt or from inside your REXX exec. Dataset locking level is determined by the DISPosition parameter supplied during dataset allocation.

The significant point to pick up on in your particular example is that you are running an ISPF Edit session and the REXX exec under the same TSO session. Dataset allocations within the same TSO session do not block each other. The DISP parameter specifies how to lock with respect to other processes, not the process itself. Consequently there will never be a dataset locking issue between different programs running under the same TSO session.

The 'Dataset in use' message poped up by the ISPF editor is a function of the editor itself checking for prior allocations under the same TSO session.

Try the following experiment:

Repeat what you described: Open an ISPF Edit session on a dataset. Then run your REXX proc under the same TSO session to update it. Should work without complaint.

Next: Ask a friend to open an ISPF Edit session on the dataset. This time your REXX proc will blow up because of "dataset in use". You can do the same thing yourself by editing the dataset in TSO and submitting the REXX exec as a batch job under your account. The interactive TSO session is one process, the batch TSO session is a second process and dataset locking will occur between them (your batch job will either blow up or will hang until the TSO Edit session is abandoned).

Dataset access conflicts only show up when different processes attempt to allocate the same dataset with incompatible DISP parameters.