> Back before SYS1.LPALIB, Nucleus-resident SVC routines were named IGCxxx
> and were linked into IEANUC00; transient SVC routines were named IGC00xxx
> with a C zone on the last digit, resided is SYS1.SVCLIB and ran out of
> 1 KiB SVC transient areas.
> The EBCDIC code pages I've used had C) as "{".
The name was generated by CVD (convert to decimal) which resulted in bytes
of dd and dC with C being the decimal sign zone. The UNPK instruction
changed this to Fd Fd Cd. So any SVC number ending in 0 resulted in a
last character of x'c0' or '{'.
from: MVT source pds AAPVT member IEATRANS
TRANSVC LH RWORK3,SVCID(RRB) . GET SVCID
CVD RWORK3,SVCNAME . CONVERT SVC NUMBER TO DECIMAL
UNPK SVCLPANM+4(4),SVCNAME+5(3) .UNPACK TO 4 DIGITS
In MVT the transient areas were each 1K and the transient SVC load modules
were created and linked to have no relocation needed and a maximum length
of 1K. There was a lot of support to wait for a transient are to be
avaiable, get the correct module in it and run it (as well as release
it when done).
Also some SVCs took more than one 1K module and were implemented by
having multiple 1K modules which transfered control between them via XCTL.
So there were a lot of IGCxxnnn modules (and IGG and other prefixes).
While SVCLIB was a PDS with a directory as normal, for performance
reasons, modules were NOT usually locaed by name. Instead a module which
transfered control to another had the name along with a place for the TTR
(disk address) of the target module. There was a program which had to
be run anytime SVCLIB was reorganized which used the names to update
all the TTRs in the SVC modules. Also the SVC table entry for SVCs
not in link pack contained the TTR of the module.
So transient area "program fetch" just had to read the block
(at most 1K) from the specified TTR...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
