Re: rename a dataset in acs routine?
They are mifrofiche tapes, and they are not sent out for processing any more. They exist only on the off chance that "someday" they might be needed to recreate something. When they are needed, they use the DSN=,VOL= to use them. On Sat, 19 Sep 2020 08:50:50 -0500, Paul Gilmartin wrote: >On Fri, 18 Sep 2020 23:10:24 -0500, Brian Westerman wrote: > >>I don't see that you can do that with tapes, the hdr1 won't match the new DSN. >> >So the tapes are labeled. Alas. > >I'm curious: how do the users access those data sets in subsequent jobs? >Examine the logs of the creating jobs for allocation messages and code >VOL=SER in the later jobs? > >Cataloging unique DSNs hardly alleviates the problem -- it might >aggravate it: 3 times as many keystrokes to modify -- two DSN >qualifiers versus one volser. > >How would you deal with DSN collisions? With "thousands" of >generated names this is highly likely: >https://en.wikipedia.org/wiki/Birthday_problem > >If you do nothing, one job with DISP=(NEW,CATLG) will wait for the >other to complete; write the data set then get NOT CATALOGUED. > >There's a meta-process problem here. At some point programmers >should have been instructed not to create thousands of uncatalogued >data sets with identical names. > >If you adopt unique catalogued DSNs, might DASD be a medium >preferable to tape? > >-- gil > >-- >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
Re: Substituting SYSIN variables via EXPORT SYMLIST containing mixed-case values
Thanks for all the detail Gil! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXP018I message when STC cancelled
Try mvsprocclp: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxb100/mpc.htm In article <4960377789730171.wa.prf51videotron...@listserv.ua.edu> you wrote: > I have an authorized STC that shuts down normally when it is stopped (/P). > When I cancel the STC, my ESTAEs are driven from newest to oldest. > But I get the message shown below after the ESTAEs are finished. > I do TCP/IP calls using IEZASMI in 2 sub-tasks. > The 2 sub-tasks that do TCPIP cleanup and issue TERMAPI in their ESTAEs. > The thread id is for the JOB STEP TCB. > I'd like to undub my address space but don't know what to do. > The Unix Callable Services doesn't seem to have a function to do that. > I'd set a SLIP trap but this situation doesn't seem slipable. > Any help would be appreciated. > Thanks in advance, Pierre. > 14.33.43 STC00663 BPXP018I THREAD 1B216000, IN PROCESS 33620001, > ENDED 039 >039 WITHOUT BEING UNDUBBED WITH COMPLETION CODE 40222000 >039 , AND REASON CODE . -- Don Poitras -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
BPXP018I message when STC cancelled
I have an authorized STC that shuts down normally when it is stopped (/P). When I cancel the STC, my ESTAEs are driven from newest to oldest. But I get the message shown below after the ESTAEs are finished. I do TCP/IP calls using IEZASMI in 2 sub-tasks. The 2 sub-tasks that do TCPIP cleanup and issue TERMAPI in their ESTAEs. The thread id is for the JOB STEP TCB. I'd like to undub my address space but don't know what to do. The Unix Callable Services doesn't seem to have a function to do that. I'd set a SLIP trap but this situation doesn't seem slipable. Any help would be appreciated. Thanks in advance, Pierre. 14.33.43 STC00663 BPXP018I THREAD 1B216000, IN PROCESS 33620001, ENDED 039 039 WITHOUT BEING UNDUBBED WITH COMPLETION CODE 40222000 039 , AND REASON CODE . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Searching MLPA module
The command is used to load modules into the Dynamic LPA that resies in (e)csa. *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sat, Sep 19, 2020 at 8:41 PM Peter wrote: > So MLPA module can be loaded using SETPROG LPA ? > > > > On Sat, 19 Sep, 2020, 4:32 pm Peter Relson, wrote: > > > > > We have a MLPA module from adabas which got loaded But we aren't able to > > trace from which dataset it was loaded. > > > > Is there a way to know the dataset name from which or where it is saved ? > > > > > > If it is truly in "MLPA" then it was specified in your IEALPAxx parmlib > > member which identifies the data set. > > > > If it is not truly in MLPA but is in dynamic LPA then there is no > > programming interface available to provide that information. > > Why don't you ask adabas what they specified to add it? The module is > > almost certainly in some data set that is in the LNKLST or that you > placed > > into their joblib/steplib or otherwise identified to them. (DISPLAY > > PROG,LNKLST,NAME=CURRENT,MOD= can be used to locate in which LNKLST > > data set a module exists). If they did add it via dynamic LPA services > > without using BYADDR=YES, then there is some information about the data > > set from which it was fetched, but the format of that information is > > intentionally not documented. That information can be retrieved by the > > OUTDSKEY of the CSVQUERY macro or the MODI_DSKEY area for each module via > > the CSVINFO macro. That information happens currently to consist of the > > UCB address and the CCHH information of the data set on that volume. > > > > > > MLPA is in CSA > > > > that is not correct. Dynamic LPA modules do come from (E)CSA. > > > > 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
Re: rename a dataset in acs routine?
Is fiche still a thing? On Sat, Sep 19, 2020 at 11:34 AM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Sat, 19 Sep 2020 09:24:32 -0500, Mike Schwab wrote: > > > > >As a microfische job, it is a collection of printouts, not used for input. > > > > > ??? > > Write-only memory? Why bother? And why keep them? > > Would a temp DSN be suitable? > > > > >On Sat, Sep 19, 2020 at 8:51 AM Paul Gilmartin wrote: > > >> > > >> On Fri, 18 Sep 2020 23:10:24 -0500, Brian Westerman wrote: > > >> > > >> >I don't see that you can do that with tapes, the hdr1 won't match the > new DSN. > > >> > > > >> So the tapes are labeled. Alas. > > >> > > >> I'm curious: how do the users access those data sets in subsequent jobs? > > >> Examine the logs of the creating jobs for allocation messages and code > > >> VOL=SER in the later jobs? > > >> > > >> Cataloging unique DSNs hardly alleviates the problem -- it might > > >> aggravate it: 3 times as many keystrokes to modify -- two DSN > > >> qualifiers versus one volser. > > >> > > >> How would you deal with DSN collisions? With "thousands" of > > >> generated names this is highly likely: > > >> https://en.wikipedia.org/wiki/Birthday_problem > > >> > > >> If you do nothing, one job with DISP=(NEW,CATLG) will wait for the > > >> other to complete; write the data set then get NOT CATALOGUED. > > >> > > >> There's a meta-process problem here. At some point programmers > > >> should have been instructed not to create thousands of uncatalogued > > >> data sets with identical names. > > >> > > >> If you adopt unique catalogued DSNs, might DASD be a medium > > >> preferable to tape? > > > > -- gil > > > > -- > > 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
Re: Searching MLPA module
So MLPA module can be loaded using SETPROG LPA ? On Sat, 19 Sep, 2020, 4:32 pm Peter Relson, wrote: > > We have a MLPA module from adabas which got loaded But we aren't able to > trace from which dataset it was loaded. > > Is there a way to know the dataset name from which or where it is saved ? > > > If it is truly in "MLPA" then it was specified in your IEALPAxx parmlib > member which identifies the data set. > > If it is not truly in MLPA but is in dynamic LPA then there is no > programming interface available to provide that information. > Why don't you ask adabas what they specified to add it? The module is > almost certainly in some data set that is in the LNKLST or that you placed > into their joblib/steplib or otherwise identified to them. (DISPLAY > PROG,LNKLST,NAME=CURRENT,MOD= can be used to locate in which LNKLST > data set a module exists). If they did add it via dynamic LPA services > without using BYADDR=YES, then there is some information about the data > set from which it was fetched, but the format of that information is > intentionally not documented. That information can be retrieved by the > OUTDSKEY of the CSVQUERY macro or the MODI_DSKEY area for each module via > the CSVINFO macro. That information happens currently to consist of the > UCB address and the CCHH information of the data set on that volume. > > > MLPA is in CSA > > that is not correct. Dynamic LPA modules do come from (E)CSA. > > 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
Re: rename a dataset in acs routine?
On Sat, 19 Sep 2020 09:24:32 -0500, Mike Schwab wrote: >As a microfische job, it is a collection of printouts, not used for input. > ??? Write-only memory? Why bother? And why keep them? Would a temp DSN be suitable? >On Sat, Sep 19, 2020 at 8:51 AM Paul Gilmartin wrote: >> >> On Fri, 18 Sep 2020 23:10:24 -0500, Brian Westerman wrote: >> >> >I don't see that you can do that with tapes, the hdr1 won't match the new >> >DSN. >> > >> So the tapes are labeled. Alas. >> >> I'm curious: how do the users access those data sets in subsequent jobs? >> Examine the logs of the creating jobs for allocation messages and code >> VOL=SER in the later jobs? >> >> Cataloging unique DSNs hardly alleviates the problem -- it might >> aggravate it: 3 times as many keystrokes to modify -- two DSN >> qualifiers versus one volser. >> >> How would you deal with DSN collisions? With "thousands" of >> generated names this is highly likely: >> https://en.wikipedia.org/wiki/Birthday_problem >> >> If you do nothing, one job with DISP=(NEW,CATLG) will wait for the >> other to complete; write the data set then get NOT CATALOGUED. >> >> There's a meta-process problem here. At some point programmers >> should have been instructed not to create thousands of uncatalogued >> data sets with identical names. >> >> If you adopt unique catalogued DSNs, might DASD be a medium >> preferable to tape? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: rename a dataset in acs routine?
As a microfische job, it is a collection of printouts, not used for input. On Sat, Sep 19, 2020 at 8:51 AM Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > On Fri, 18 Sep 2020 23:10:24 -0500, Brian Westerman wrote: > > >I don't see that you can do that with tapes, the hdr1 won't match the new > >DSN. > > > So the tapes are labeled. Alas. > > I'm curious: how do the users access those data sets in subsequent jobs? > Examine the logs of the creating jobs for allocation messages and code > VOL=SER in the later jobs? > > Cataloging unique DSNs hardly alleviates the problem -- it might > aggravate it: 3 times as many keystrokes to modify -- two DSN > qualifiers versus one volser. > > How would you deal with DSN collisions? With "thousands" of > generated names this is highly likely: > https://en.wikipedia.org/wiki/Birthday_problem > > If you do nothing, one job with DISP=(NEW,CATLG) will wait for the > other to complete; write the data set then get NOT CATALOGUED. > > There's a meta-process problem here. At some point programmers > should have been instructed not to create thousands of uncatalogued > data sets with identical names. > > If you adopt unique catalogued DSNs, might DASD be a medium > preferable to tape? > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: rename a dataset in acs routine?
On Fri, 18 Sep 2020 23:10:24 -0500, Brian Westerman wrote: >I don't see that you can do that with tapes, the hdr1 won't match the new DSN. > So the tapes are labeled. Alas. I'm curious: how do the users access those data sets in subsequent jobs? Examine the logs of the creating jobs for allocation messages and code VOL=SER in the later jobs? Cataloging unique DSNs hardly alleviates the problem -- it might aggravate it: 3 times as many keystrokes to modify -- two DSN qualifiers versus one volser. How would you deal with DSN collisions? With "thousands" of generated names this is highly likely: https://en.wikipedia.org/wiki/Birthday_problem If you do nothing, one job with DISP=(NEW,CATLG) will wait for the other to complete; write the data set then get NOT CATALOGUED. There's a meta-process problem here. At some point programmers should have been instructed not to create thousands of uncatalogued data sets with identical names. If you adopt unique catalogued DSNs, might DASD be a medium preferable to tape? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Searching MLPA module
We have a MLPA module from adabas which got loaded But we aren't able to trace from which dataset it was loaded. Is there a way to know the dataset name from which or where it is saved ? If it is truly in "MLPA" then it was specified in your IEALPAxx parmlib member which identifies the data set. If it is not truly in MLPA but is in dynamic LPA then there is no programming interface available to provide that information. Why don't you ask adabas what they specified to add it? The module is almost certainly in some data set that is in the LNKLST or that you placed into their joblib/steplib or otherwise identified to them. (DISPLAY PROG,LNKLST,NAME=CURRENT,MOD= can be used to locate in which LNKLST data set a module exists). If they did add it via dynamic LPA services without using BYADDR=YES, then there is some information about the data set from which it was fetched, but the format of that information is intentionally not documented. That information can be retrieved by the OUTDSKEY of the CSVQUERY macro or the MODI_DSKEY area for each module via the CSVINFO macro. That information happens currently to consist of the UCB address and the CCHH information of the data set on that volume. MLPA is in CSA that is not correct. Dynamic LPA modules do come from (E)CSA. 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
