ZPTCH improvements

Customer is asking for improvements to zpatch to prevent system issue;
The issue appears to be the possibility of inadvertently applying core updates after filing the 20 allowed ZPTCH patch deck slots. The core
updates happen because the process allows for error path exits that don't maintain “patch mode” status
So the fix would be to maintain “patch mode” status until ZPTCH STOP were entered, which conforms to general expected usage for ZPTCH.

Assumptions/givens:
* ZTPCH is limited to PCRAS only function.
* ZPTCH uses the LEID of an entry to determine if “patch mode' is active verifying the LEID against
slots in the IPTRF table.

Proposed update:
* Update the ZPTCH code to allow the storage of n-1 (n is currently 20) patch decks and keep the
last patch deck slot available as storage for any subsequent alters that are provided in the case
where the table is full, i.e., an item beyond a full table is being added.
* In that full table case, a warning would be given at ZPTCH BEGIN time saying “Patch deck table
full. Patch deck add inhibited. Use ZPTCH STOP to exit patch mode” with patch mode being
maintained.
* Then should the warning not be heeded, any core alters supplied would be added to that last
reserved slot in the patch deck.
* Lastly when ZPTCH STOP was ultimately supplied, any indicated alters would be
disregarded/dropped, “patch mode” would be exited, and a message saying “No alters
saved. Review existing patch decks and delete an entry to create a usable patch deck slot”
would be generated.
* There is actually room for 21 patch deck slots in the record the IPTRF table is kept in. It's a 381
byte record with each patch deck slot being 16 bytes in length and there is 24 spare bytes
following the patch deck table. So we could maintain the current expectation of 20 active patch
deck slots and still allow for a “buffer” slot. However this doesn't coincide with IBM usage of
this record so may lead to future conflicts.

thanks