I may have gotten the name wrong; memory is the second thing to go. Also, in VS1 the SVC transient areas were 2 Ki rather than 1 Ki.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Spiegel [00000468385049d1-dmarc-requ...@listserv.ua.edu] Sent: Thursday, June 1, 2023 9:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Q: Transient SVC ? Hi Shmuel AMV"SH, In OS/VS1 it was IEHIOSUP. Regards, David On 2023-06-01 08:33, Seymour J Metz wrote: > It's C0 in code pages 37 and 1047. > > Transient SVC routines are supposed to be refreshable. That's important both > for OS/360 SVC transient areas and for the paging of the PLPA in MVS (SVS was > able to write back altered PLPA pages.) > > IECIOSUP was the TTR update utility, and as I recall it was only relevant for > O/C/EOV. The magic word is Where To Go (WTG) table. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Michael Stein [m...@zlvfc.com] > Sent: Thursday, June 1, 2023 12:28 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Q: Transient SVC ? > >> 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 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
