It’s a batch program called from a started task
> On Dec 24, 2020, at 11:18 AM, Joe Monk <joemon...@gmail.com> wrote: > > Still not sure why you have a WSA... Youre not using CICS, right? > > Joe > >> On Thu, Dec 24, 2020 at 10:11 AM Joseph Reichman <reichman...@gmail.com> >> wrote: >> >> This code is right after my prologue >> >> >> ST 0,#WSA_1 >> >> So I have to somehow make sure that register 0 has the right value >> >> Thanks >> >> -----Original Message----- >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf >> Of Joe Monk >> Sent: Thursday, December 24, 2020 11:04 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Size of the Writable Static Area >> >> OK but I dont think you need a WSA. >> >> Joe >> >> On Thu, Dec 24, 2020 at 10:00 AM Joseph Reichman <reichman...@gmail.com> >> wrote: >> >>> Thanks I think the problem is my main program is called OPENFILE In >>> this program I load sysadata to a dataspace >>> >>> Why did I use metal C because I have similar C code in windows and >>> thought with #pragma if __MVS I could save coding I found it easier to >>> work with Metal then LE as it gives me more options >>> >>> I think some where there is a way to have alternate main name I think >>> I have to follow that path >>> >>> >>>> On Dec 24, 2020, at 10:46 AM, Joe Monk <joemon...@gmail.com> wrote: >>>> >>>> No. If you are calling METAL C from assembler, METAL C will take >>>> care >>> of >>>> the WSA... >>>> >>>> "The RENT environment initialization and termination routines are >>>> called >>> to >>>> establish and terminate the dynamically allocated WSA storage with >>>> the static initialization data applied. For the AMODE 31 "main" >>>> function, CCNZINIT and CCNZTERM are the names of these routines. >>>> While for the >>> AMODE >>>> 64 "main" function, CCNZQINI and CCNZQTRM are the function names ... >>>> The actual WSA storage management is done by user supplied plug-in >>>> routines called from CCNZINIT and CCNZTERM." >>>> >>>> Joe >>>> >>>>> On Thu, Dec 24, 2020 at 9:42 AM Joseph Reichman >>>>> <reichman...@gmail.com> >>>>> wrote: >>>>> >>>>> Just read it FYI I am Calling Metal C from Assembler (via Link) Me >>> thinks >>>>> I have to init The WSA area Binyamin Dessin suggested I use a CXD >>> variable >>>>> to get the size of the WSA >>>>> >>>>> -----Original Message----- >>>>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On >>> Behalf >>>>> Of Joe Monk >>>>> Sent: Thursday, December 24, 2020 10:01 AM >>>>> To: IBM-MAIN@LISTSERV.UA.EDU >>>>> Subject: Re: Size of the Writable Static Area >>>>> >>>>> Check page 31 in this: >>>>> >>>>> >>> https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r3 >>> sc147313/$file/ccrug00_v2r3.pdf >>>>> >>>>> Joe >>>>> >>>>> On Thu, Dec 24, 2020 at 8:39 AM Joseph Reichman >>>>> <reichman...@gmail.com> >>>>> wrote: >>>>> >>>>>> I’m writing a prolog for a metal C program I noticed that after >>>>>> the prolog code Registers 0 is stored in #WSA_1 seems like storage >>>>>> has to be allocated for it ( writable static area ) in addition to >>>>>> the dynamic storage ( register save + auto variables ) >>>>>> >>>>>> >>>>>>> On Dec 24, 2020, at 9:32 AM, Peter Relson <rel...@us.ibm.com> >> wrote: >>>>>>> >>>>>>> I think of the writeable static area as an area that LE >>>>>>> instantiates on your behalf. >>>>>>> As far as I know, there is no interface provided by which you can >>>>>>> do >>>>>> this. >>>>>>> >>>>>>> If LE is going to do this for you, using loader services that >>>>>>> rely on information within the program object itself (and there >>>>>>> is such information), how is knowing the size of the area of help >> to you? >>>>>>> >>>>>>> Peter Relson >>>>>>> z/OS Core Technology Design >>>>>>> >>>>>>> >>>>>>> ----------------------------------------------------------------- >>>>>>> --- >>>>>>> -- 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 >>>>> >>>> >>>> -------------------------------------------------------------------- >>>> -- 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 >> > > ---------------------------------------------------------------------- > 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
