AW: Re: Region size for OMVS tasks
One more thought: Look At he SMF30 records for one such session. You should get an idea of what‘s going on in that process and its child processes. There will be one record for each command, i.e. when a fork()ed or spawd()ed process ends, and at each exec(). You may find the one program eating up all that storage. — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: So much for THAT excuse | Computerworld SHARK TANK
On 11/22/2018 4:06 PM, Phil Smith III wrote: Tom Brennan wrote, in part: Maybe someday everything will be like Google, so I can type DNS= (which I do often enough) and the system will ask me "Did you mean DSN?" 30+ years ago, a friend wrote a CMS ENDCMD NUCEXT (a routine that got control at the end of a console command) called DWIM - Do What I Mean. It would look for failed return codes, analyze the command, and "fix" it. Of course since he'd written it, it worked as he'd expect it to. And he still HATED it. Maybe a lesson? Yeah, on second thought such correction might end up as bad as the auto-correct on cell phone texting programs :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage question
RACF protects datasets, not dataset names. If catalog services has access to the UCAT and the DSNs are catalogued "normally," 3.4 will list the DSNs with no problem. You won't be able to do anything with the datasets but that is a different issue. DSNs that are not catalogued normally, or at all, can still be listed by specifying the specific catalog or volume, as appropriate. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Sankaranarayanan, Vignesh > Sent: Thursday, November 22, 2018 12:28 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Storage question > > Hello again List! > > Is there a way to produce a listing of datasets (given the HLQs) based entirely > on VTOCs? > The assumption would be that the following are no longer available: > > 1. RACF profile HLQ.* > 2. RACF user/group named 'HLQ' > 3. Alias named 'HLQ' defined to some UCAT > > When the above 3 are true, I would think that we can't find the datasets in > 3.4, but can from the ISMF Dataset screen. > My luck with the ISMF Dataset screen is inconsistent.. so would prefer > another scalable or repeatable approach. > > Thanks! > > - Vignesh > Mainframe Infrastructure > > > MARKSANDSPENCER.COM > > Unless otherwise stated above: > Marks and Spencer plc > Registered Office: > Waterside House > 35 North Wharf Road > London > W2 1NW > > Registered No. 214436 in England and Wales. > > Telephone (020) 7935 4422 > Facsimile (020) 7487 2670 > > www.marksandspencer.com > > Please note that electronic mail may be monitored. > > This e-mail is confidential. If you received it by mistake, please let us know > and then delete it from your system; you should not copy, disclose, or > distribute its contents to anyone nor act in reliance on this e-mail, as this is > prohibited and may be unlawful. > > -- > 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: So much for THAT excuse | Computerworld SHARK TANK
Tom Brennan wrote, in part: >Maybe someday everything will be like Google, so I can type DNS= (which >I do often enough) and the system will ask me "Did you mean DSN?" 30+ years ago, a friend wrote a CMS ENDCMD NUCEXT (a routine that got control at the end of a console command) called DWIM - Do What I Mean. It would look for failed return codes, analyze the command, and "fix" it. Of course since he'd written it, it worked as he'd expect it to. And he still HATED it. Maybe a lesson? Gil wrote: >I wanted more to focus on file names than on commands and keywords. I.e. with >STOW I can create members "foobar ", "FooBar ", and "FOOBAR ", all in the >same >PDS directory, but I can can access only one of them with TSO ALLOCATE or JCL >DD >or ... . One of those behaviors has to be wrong. Absolutely. To be blunt, not sure how this relates to whether case sensitivity is good or bad-a badly done *anything* is bad, right? Gil also wrote: >A half-century ago, I saw a magazine article suggesting that FORTRAN > (*the* language then) should treat '0' and 'O' as interchangable. OK. >I can write "C0NTINUE" instead of "CONTINUE". But it restricts the name >space for variables. (And I wondered if '0' and 'O' confusion was the >nub of the SHARK TANK CICS article.) Heh. Another friend once wrote a program using variables that were all named combinations of one, eye, zero, and oh. He gave up trying to debug it. I'd have voted against such a requirement; there are opportunities in pretty well any programming language to get in that sort of trouble. A VERY long time ago-almost 40 years-I was helping a user with a FORTRAN program. We could not figure out why it seemed like it wasn't executing a particular statement. Finally we realized that it followed a block comment with one too many Cs: CThis is C a block C comment that C goes on for a while C X = 3 Oops. Not to be confused with the user who went to great pains to ensure that every comment line started with a C: COMPLETE THE OPERATION, TRANSFERRING CONTROL TO THE OTHER PROGRAM, WHICH CAN THEN... Looked VERY weird, since the brain said, "Those aren't comments!" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for an appropriate system exit
On Thu, 22 Nov 2018 22:53:11 +0200, Steff Gladstone wrote:
>Three questions regarding IEFACTRT:
>
>1. Where is use of IEFYS for writing messages to the JOBLOG documented?
>The example given in the documentation for IEFACTRT is incomplete. Google
>doesn't seem to locate the doc as well.
>
>2. I am abending on S0C4 because getmained areas are automatically being
>freed at end of step, before IEFACTRT gets control. It is not clear to me
>if SUBPOOL alone can solve the problem. Do I need to specify
>TCBADDR=TCBJSTCB on the STORAGE macro so that the "input TCB" is the
>job-step TCB? What course is recommended?
>
>3. The documentation says one can dynamically allocate within IEFACTRT but
>the BPXWDYN routine returns a non-zero return code. (Same code that works
>fine in a regular program.) Is this a limitation of BPXWDYN? Should I code
>an SVC 99 call myself?
>
What was your argument string for BPXWDYN? Return code? Message text?
I have used SYSCALL open /dev/console followed by SYSCALL write.
o This gives no control of routing/descriptor.
o Automation may intercept BPXF024I.
Also possible: SYSCALL writefile /dev/console
Also possible: BPXWDYN( "alloc path('/dev/console') filedata(text) msg(WTP)
..." )
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Peter, Mike: Yes, I remember Peter pointing at Mark's page, but for some reason I moved on past that to some other line of enquiry. I've now done what you said, and the results from REXXSTOR in PuTTY are: V I R T U A LS T O R A G EU S A G E --- REGION REQUESTED: 55296K LIMIT IN-USE AVAIL BELOW 16M: 8168K 4K 8164K ABOVE 16M: 2088984K 840K 2088144K So, the 55296K is that 54M that I've been chasing and the rest of the report shows that I've been given the maximum amount of memory possible - 2G, right? Have you cut some columns? There should be more. The "Limit" is a bit misleading, since you can only have some 1.5G, the rest is in use by the common area. Anyway, this session is not about to run out of storage, because only 840K are in use. But this is you session, not the developer's, who is having the problems, right. Can you have him to run that REXX after login and once he got to the out of storage? Since the problem occurs only with _BPX_SHAREAS=YES, when all the processes share a single address space, what exactly are they trying to do? What has change since it worked? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for an appropriate system exit
Three questions regarding IEFACTRT: 1. Where is use of IEFYS for writing messages to the JOBLOG documented? The example given in the documentation for IEFACTRT is incomplete. Google doesn't seem to locate the doc as well. 2. I am abending on S0C4 because getmained areas are automatically being freed at end of step, before IEFACTRT gets control. It is not clear to me if SUBPOOL alone can solve the problem. Do I need to specify TCBADDR=TCBJSTCB on the STORAGE macro so that the "input TCB" is the job-step TCB? What course is recommended? 3. The documentation says one can dynamically allocate within IEFACTRT but the BPXWDYN routine returns a non-zero return code. (Same code that works fine in a regular program.) Is this a limitation of BPXWDYN? Should I code an SVC 99 call myself? Thank you in advance, Steff Gladstone On Fri, 5 Oct 2018 at 16:17, Charles Mills wrote: > I use the CSVDYNEX interface extensively and it has been nothing but > bulletproof in all of my experience. Kudos! > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Elardus Engelbrecht > Sent: Friday, October 5, 2018 6:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Looking for an appropriate system exit > > Peter Relson wrote: > > >When the facility was developed, we took a stab at which existing exits > that we thought were most likely to be of help to the most customers. And > I'd hope that new exits use it. > > That was one of the best stabs I got from Big Blue. It saved me an > unneeded IPL when one of my SMF exits went down the bit bucket. > > -- > 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
[no subject]
Using the Volume ID. The alias only exists in the catalog. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > If they are on disk, you must be able to find them with 3.4. What makes you > doubt this? > > Kees. > >> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Region size for OMVS tasks
Peter, Mike: Yes, I remember Peter pointing at Mark's page, but for some reason I moved on past that to some other line of enquiry. I've now done what you said, and the results from REXXSTOR in PuTTY are: V I R T U A LS T O R A G EU S A G E --- REGION REQUESTED: 55296K LIMIT IN-USE AVAIL BELOW 16M: 8168K 4K 8164K ABOVE 16M: 2088984K 840K 2088144K So, the 55296K is that 54M that I've been chasing and the rest of the report shows that I've been given the maximum amount of memory possible - 2G, right? So this whole exercise along with the temporary killing of my z/OS system *has* been a waste of time. I'm still left with the two messages though. And further work by one of the developers shows that the problem occurs only when BPX_SHAREAS=YES is defined. Setting BPX_SHAREAS=NO makes the memory problem go away, but run-time increases significantly. Thanks for all your support on this problem, Peter - and everyone else who added their thoughts, too. (I'm not letting this problem go though - this is one of those times when I start behaving like a terrier with a rat) Regards Sean On Thu, 22 Nov 2018 at 15:44, Peter Hunkeler wrote: > > > > >http://mzelden.com/mvsutil.html > > > > Yep, this is the invaluable link. As I wrote before, try the REXXSTOR rexx > found there and run it in a) TSO, b) TSO -> OMVS (shell under TSO), c) > putty (shell vie TCP/IP). If possible run in the environment where you‘re > getting the out of stroage, and run it under the userid that is getting the > problem. This may or may not give you a hint what to do next > > > — > Peter Hunkeler > > > > -- > 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: [EXTERNAL] Re: Storage question
If you have CA (Computer Associates) products like CA1, CA DISK, CA PDSMAN, the list is endless You can probably download the GMI (Graphical Management Interface) no-charge. It is considered SRM (Storage Resource Manager / SAMS) Lite https://docops.ca.com/ca-1-tms/14-0/en/using/ca-vantage-gmi-graphical-management-interface This is a nice way to see datasets and volumes. This is a no-cost version of SRM. I think CA still provides this so long as you have at least one CA Product from the list. CA Vantage GMI is the graphical management interface product that allows you to view and manage mainframe activity from a PC. It consists of user-interface clients which interface with a z/OS server component to allow access to basic z/OS server functions. https://docops.ca.com/ca-1-tms/14-0/en/using/ca-vantage-gmi-graphical-management-interface You would need to verify it is still no-charge. https://support.ca.com/us/product-content/recommended-reading/product-related-technical-information/ca-gmi-ordering-and-download-information.html Several CA products support CA GMI. These are referred to as CA GMI qualified products. If you have a license for one of the CA GMI qualifying products, then you can order and install CA Vantage GMI on the host and its user-interface clients separately, free of charge. CA Vantage GMI cannot be ordered separately unless you have a license for one of the CA GMI qualifying products. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > David Spiegel > Sent: Thursday, November 22, 2018 5:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: Storage question > > It's file 112. BTW, you can run it in batch. > It's allows masking by partial dsname (i.e. CONTAINING) and VOLSER Prefix > (e.g. WORK will match WORK01, WORK02 etc.) It will show which Datasets are > CATLGd (or not) and allows for other selection criteria (e.g. not displaying > VTOCIX and VVDS Datasets). > > On 2018-11-22 07:47, Sankaranarayanan, Vignesh wrote: > > There are some 30 HLQs I need to look at with volume *.. so doing that in > 3.4 gets boring after a while. > > I was hoping there'll be a utility that can help (perhaps the CBTTAPE VTOC > one). > > > > - Vignesh > > Mainframe Infrastructure > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Vernooij, Kees (ITOPT1) - KLM > > Sent: 22 November 2018 12:32 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: [EXTERNAL] Re: Storage question > > > > I mean display with 3.4 with no dsname but a generic volser filled. This > will search the VTOCs. > > > > Kees > > > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >> On Behalf Of Sankaranarayanan, Vignesh > >> Sent: 22 November, 2018 13:03 > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: [EXTERNAL] Re: Storage question > >> > >> Well... the points I've listed below. > >> > >> If an alias is gone before the datasets under it are removed, the > >> UCAT will still have info about the datasets but they won't show up > >> in 3.4 > >> > >> - Vignesh > >> Mainframe Infrastructure > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > >> Behalf Of Vernooij, Kees (ITOPT1) - KLM > >> Sent: 22 November 2018 09:55 > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: [EXTERNAL] Re: Storage question > >> > >> If they are on disk, you must be able to find them with 3.4. What > >> makes you doubt this? > >> > >> Kees. > >> > >>> -Original Message- > >>> From: IBM Mainframe Discussion List > >>> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, > >>> Vignesh > >>> Sent: 22 November, 2018 9:28 > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Storage question > >>> > >>> Hello again List! > >>> > >>> Is there a way to produce a listing of datasets (given the HLQs) > >>> based entirely on VTOCs? > >>> The assumption would be that the following are no longer available: > >>> > >>>1. RACF profile HLQ.* > >>>2. RACF user/group named 'HLQ' > >>>3. Alias named 'HLQ' defined to some UCAT > >>> > >>> When the above 3 are true, I would think that we can't find the > >>> datasets in 3.4, but can from the ISMF Dataset screen. > >>> My luck with the ISMF Dataset screen is inconsistent.. so would > >>> prefer another scalable or repeatable approach. > >>> > >>> Thanks! > >>> > >>> - Vignesh > >>> Mainframe Infrastructure > >>> > >>> > >>> MARKSANDSPENCER.COM > >>> > >>> Unless otherwise stated above: > >>> Marks and Spencer plc > >>> Registered Office: > >>> Waterside House > >>> 35 North Wharf Road > >>> London > >>> W2 1NW > >>> > >>> Registered No. 214436 in England and Wales. > >>> > >>> Telephone (020) 7935 4422 > >>> Facsimile (020) 7487 2670 > >>> > >>> https://apc01.safelinks.protection.outlook.com/?url=www.marksandspen > >>> cer.com&data=02%7C01%7C%7Ce08925043799466d078608d65078c868%7C8
AW: Re: Region size for OMVS tasks
>http://mzelden.com/mvsutil.html Yep, this is the invaluable link. As I wrote before, try the REXXSTOR rexx found there and run it in a) TSO, b) TSO -> OMVS (shell under TSO), c) putty (shell vie TCP/IP). If possible run in the environment where you‘re getting the out of stroage, and run it under the userid that is getting the problem. This may or may not give you a hint what to do next — Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Query on JES3 DJC
Thanks much Steve.. Appreciate your response.. I might need some recommendations as we are planning to migrate to ESP scheduling tool.. Hope to get some inputs.. Many thanks :-) On Thu, Nov 22, 2018 at 5:47 PM Steve Horein wrote: > *I N,ID=,LIST > Check the status character(s) in message IAT8581 > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.iatb300/inqn.htm > > On Thu, Nov 22, 2018 at 4:52 AM RCG wrote: > > > Hello Experts, Quick question if anyone here has expertise on JES3 DJC > > (Dependent Job Control), All I need to know is, How to find the list of > > JOBS running in a given LPAR which uses DJC network please? Any pointers > to > > look at would be much appreciated > > > > Regards, > > RCG > > > > -- > > 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
OT] z/OS (not OS/390) (with apologies to They Might be Giants- Istanbul, not Constantinople)
I have been clearing out a lot of my old stuff recently, and I have 8 pages of songsheets for the HASP sing-a-long. Lord knows how I ever acquired them - my singing skills get me banned from any karaoke within 10 miles. They are available to anyone who wants them. I will even pay the postage. Mike Kerford-Byrnes P.S. anyone interested in MVS and DFP microfiche dating back to the early 80s? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Storage question
Lol.. why didn't I think of that. Thanks! - Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: 22 November 2018 12:55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Storage question Do a 3.4 without dsname and volser * SAVE list to a dataset. Filter the HLQs with edit. Create the required (IDCAMS?) statements from the dsnames. All proposed solutions take some effort and time. Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Sankaranarayanan, Vignesh > Sent: 22 November, 2018 13:47 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: Storage question > > There are some 30 HLQs I need to look at with volume *.. so doing that > in 3.4 gets boring after a while. > I was hoping there'll be a utility that can help (perhaps the CBTTAPE > VTOC one). > > - Vignesh > Mainframe Infrastructure > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Vernooij, Kees (ITOPT1) - KLM > Sent: 22 November 2018 12:32 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: Storage question > > I mean display with 3.4 with no dsname but a generic volser filled. > This will search the VTOCs. > > Kees > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, > > Vignesh > > Sent: 22 November, 2018 13:03 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: [EXTERNAL] Re: Storage question > > > > Well... the points I've listed below. > > > > If an alias is gone before the datasets under it are removed, the > > UCAT will still have info about the datasets but they won't show up > > in 3.4 > > > > - Vignesh > > Mainframe Infrastructure > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Vernooij, Kees (ITOPT1) - KLM > > Sent: 22 November 2018 09:55 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [EXTERNAL] Re: Storage question > > > > If they are on disk, you must be able to find them with 3.4. What > > makes you doubt this? > > > > Kees. > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, > > > Vignesh > > > Sent: 22 November, 2018 9:28 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Storage question > > > > > > Hello again List! > > > > > > Is there a way to produce a listing of datasets (given the HLQs) > > > based entirely on VTOCs? > > > The assumption would be that the following are no longer available: > > > > > > 1. RACF profile HLQ.* > > > 2. RACF user/group named 'HLQ' > > > 3. Alias named 'HLQ' defined to some UCAT > > > > > > When the above 3 are true, I would think that we can't find the > > > datasets in 3.4, but can from the ISMF Dataset screen. > > > My luck with the ISMF Dataset screen is inconsistent.. so would > > > prefer another scalable or repeatable approach. > > > > > > Thanks! > > > > > > - Vignesh > > > Mainframe Infrastructure > > > > > > > > > MARKSANDSPENCER.COM > > > > > > Unless otherwise stated above: > > > Marks and Spencer plc > > > Registered Office: > > > Waterside House > > > 35 North Wharf Road > > > London > > > W2 1NW > > > > > > Registered No. 214436 in England and Wales. > > > > > > Telephone (020) 7935 4422 > > > Facsimile (020) 7487 2670 > > > > > > www.marksandspencer.com > > > > > > Please note that electronic mail may be monitored. > > > > > > This e-mail is confidential. If you received it by mistake, please > > > let us know and then delete it from your system; you should not > > > copy, disclose, or distribute its contents to anyone nor act in > > > reliance on this e-mail, as this is prohibited and may be unlawful. > > > > > > -- > > > -- > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO > > > IBM-MAIN > > > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > > confidential and privileged material intended for the addressee only. > > If you are not the addressee, you are notified that no part of the > > e-mail or any attachment may be disclosed, copied or distributed, > > and that any other action related to this e-mail or attachment is > > strictly prohibited, and may be unlawful. If you have received this > > e-mail by error, please notify the sender immediately by return > > e-mail, and delete this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > and/or its employees shall not be liable for the incorrect or > > incomplete transmission of this
Re: [EXTERNAL] Re: Storage question
It's file 112. BTW, you can run it in batch. It's allows masking by partial dsname (i.e. CONTAINING) and VOLSER Prefix (e.g. WORK will match WORK01, WORK02 etc.) It will show which Datasets are CATLGd (or not) and allows for other selection criteria (e.g. not displaying VTOCIX and VVDS Datasets). On 2018-11-22 07:47, Sankaranarayanan, Vignesh wrote: > There are some 30 HLQs I need to look at with volume *.. so doing that in 3.4 > gets boring after a while. > I was hoping there'll be a utility that can help (perhaps the CBTTAPE VTOC > one). > > - Vignesh > Mainframe Infrastructure > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Vernooij, Kees (ITOPT1) - KLM > Sent: 22 November 2018 12:32 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: Storage question > > I mean display with 3.4 with no dsname but a generic volser filled. This will > search the VTOCs. > > Kees > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Sankaranarayanan, Vignesh >> Sent: 22 November, 2018 13:03 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: [EXTERNAL] Re: Storage question >> >> Well... the points I've listed below. >> >> If an alias is gone before the datasets under it are removed, the UCAT >> will still have info about the datasets but they won't show up in 3.4 >> >> - Vignesh >> Mainframe Infrastructure >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Vernooij, Kees (ITOPT1) - KLM >> Sent: 22 November 2018 09:55 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: [EXTERNAL] Re: Storage question >> >> If they are on disk, you must be able to find them with 3.4. What >> makes you doubt this? >> >> Kees. >> >>> -Original Message- >>> From: IBM Mainframe Discussion List >>> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, >>> Vignesh >>> Sent: 22 November, 2018 9:28 >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Storage question >>> >>> Hello again List! >>> >>> Is there a way to produce a listing of datasets (given the HLQs) >>> based entirely on VTOCs? >>> The assumption would be that the following are no longer available: >>> >>>1. RACF profile HLQ.* >>>2. RACF user/group named 'HLQ' >>>3. Alias named 'HLQ' defined to some UCAT >>> >>> When the above 3 are true, I would think that we can't find the >>> datasets in 3.4, but can from the ISMF Dataset screen. >>> My luck with the ISMF Dataset screen is inconsistent.. so would >>> prefer another scalable or repeatable approach. >>> >>> Thanks! >>> >>> - Vignesh >>> Mainframe Infrastructure >>> >>> >>> MARKSANDSPENCER.COM >>> >>> Unless otherwise stated above: >>> Marks and Spencer plc >>> Registered Office: >>> Waterside House >>> 35 North Wharf Road >>> London >>> W2 1NW >>> >>> Registered No. 214436 in England and Wales. >>> >>> Telephone (020) 7935 4422 >>> Facsimile (020) 7487 2670 >>> >>> https://apc01.safelinks.protection.outlook.com/?url=www.marksandspencer.com&data=02%7C01%7C%7Ce08925043799466d078608d65078c868%7C84df9e7fe9f640afb435%7C1%7C0%7C636784877031299527&sdata=83tEdRtCqQld487lM%2B78i2YG1fX5DXHH1X3QWTwfDvc%3D&reserved=0 >>> >>> Please note that electronic mail may be monitored. >>> >>> This e-mail is confidential. If you received it by mistake, please >>> let us know and then delete it from your system; you should not >>> copy, disclose, or distribute its contents to anyone nor act in >>> reliance on this e-mail, as this is prohibited and may be unlawful. >>> >>> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >> >> For information, services and offers, please visit our web site: >> https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.com&data=02%7C01%7C%7Ce08925043799466d078608d65078c868%7C84df9e7fe9f640afb435%7C1%7C0%7C636784877031299527&sdata=EryQd6VhbUOj4Dt0ZHXjR62GAGsx9hzGX9A6ynwMpn0%3D&reserved=0. >> This e-mail and any attachment may contain >> confidential and privileged material intended for the addressee only. >> If you are not the addressee, you are notified that no part of the >> e-mail or any attachment may be disclosed, copied or distributed, and >> that any other action related to this e-mail or attachment is strictly >> prohibited, and may be unlawful. If you have received this e-mail by >> error, please notify the sender immediately by return e-mail, and >> delete this message. >> >> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or >> its employees shall not be liable for the incorrect or incomplete >> transmission of this e-mail or any attachments, nor responsible for >> any delay in receipt. >> Koninklijke Luchtvaart Maatschappij N.V. (als
Re: [EXTERNAL] Re: Storage question
Do a 3.4 without dsname and volser * SAVE list to a dataset. Filter the HLQs with edit. Create the required (IDCAMS?) statements from the dsnames. All proposed solutions take some effort and time. Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Sankaranarayanan, Vignesh > Sent: 22 November, 2018 13:47 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: Storage question > > There are some 30 HLQs I need to look at with volume *.. so doing that > in 3.4 gets boring after a while. > I was hoping there'll be a utility that can help (perhaps the CBTTAPE > VTOC one). > > - Vignesh > Mainframe Infrastructure > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Vernooij, Kees (ITOPT1) - KLM > Sent: 22 November 2018 12:32 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: Storage question > > I mean display with 3.4 with no dsname but a generic volser filled. This > will search the VTOCs. > > Kees > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Sankaranarayanan, Vignesh > > Sent: 22 November, 2018 13:03 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: [EXTERNAL] Re: Storage question > > > > Well... the points I've listed below. > > > > If an alias is gone before the datasets under it are removed, the UCAT > > will still have info about the datasets but they won't show up in 3.4 > > > > - Vignesh > > Mainframe Infrastructure > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Vernooij, Kees (ITOPT1) - KLM > > Sent: 22 November 2018 09:55 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [EXTERNAL] Re: Storage question > > > > If they are on disk, you must be able to find them with 3.4. What > > makes you doubt this? > > > > Kees. > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, > > > Vignesh > > > Sent: 22 November, 2018 9:28 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Storage question > > > > > > Hello again List! > > > > > > Is there a way to produce a listing of datasets (given the HLQs) > > > based entirely on VTOCs? > > > The assumption would be that the following are no longer available: > > > > > > 1. RACF profile HLQ.* > > > 2. RACF user/group named 'HLQ' > > > 3. Alias named 'HLQ' defined to some UCAT > > > > > > When the above 3 are true, I would think that we can't find the > > > datasets in 3.4, but can from the ISMF Dataset screen. > > > My luck with the ISMF Dataset screen is inconsistent.. so would > > > prefer another scalable or repeatable approach. > > > > > > Thanks! > > > > > > - Vignesh > > > Mainframe Infrastructure > > > > > > > > > MARKSANDSPENCER.COM > > > > > > Unless otherwise stated above: > > > Marks and Spencer plc > > > Registered Office: > > > Waterside House > > > 35 North Wharf Road > > > London > > > W2 1NW > > > > > > Registered No. 214436 in England and Wales. > > > > > > Telephone (020) 7935 4422 > > > Facsimile (020) 7487 2670 > > > > > > www.marksandspencer.com > > > > > > Please note that electronic mail may be monitored. > > > > > > This e-mail is confidential. If you received it by mistake, please > > > let us know and then delete it from your system; you should not > > > copy, disclose, or distribute its contents to anyone nor act in > > > reliance on this e-mail, as this is prohibited and may be unlawful. > > > > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO > > > IBM-MAIN > > > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > > confidential and privileged material intended for the addressee only. > > If you are not the addressee, you are notified that no part of the > > e-mail or any attachment may be disclosed, copied or distributed, and > > that any other action related to this e-mail or attachment is strictly > > prohibited, and may be unlawful. If you have received this e-mail by > > error, please notify the sender immediately by return e-mail, and > > delete this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > > its employees shall not be liable for the incorrect or incomplete > > transmission of this e-mail or any attachments, nor responsible for > > any delay in receipt. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > Dutch > > Airlines) is registered in Amstelveen, The Netherlands, with > > registered number 33014286 > > > > > > -
Re: [EXTERNAL] Re: Storage question
There are some 30 HLQs I need to look at with volume *.. so doing that in 3.4 gets boring after a while. I was hoping there'll be a utility that can help (perhaps the CBTTAPE VTOC one). - Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: 22 November 2018 12:32 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: Storage question I mean display with 3.4 with no dsname but a generic volser filled. This will search the VTOCs. Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Sankaranarayanan, Vignesh > Sent: 22 November, 2018 13:03 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: Storage question > > Well... the points I've listed below. > > If an alias is gone before the datasets under it are removed, the UCAT > will still have info about the datasets but they won't show up in 3.4 > > - Vignesh > Mainframe Infrastructure > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Vernooij, Kees (ITOPT1) - KLM > Sent: 22 November 2018 09:55 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: Storage question > > If they are on disk, you must be able to find them with 3.4. What > makes you doubt this? > > Kees. > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, > > Vignesh > > Sent: 22 November, 2018 9:28 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Storage question > > > > Hello again List! > > > > Is there a way to produce a listing of datasets (given the HLQs) > > based entirely on VTOCs? > > The assumption would be that the following are no longer available: > > > > 1. RACF profile HLQ.* > > 2. RACF user/group named 'HLQ' > > 3. Alias named 'HLQ' defined to some UCAT > > > > When the above 3 are true, I would think that we can't find the > > datasets in 3.4, but can from the ISMF Dataset screen. > > My luck with the ISMF Dataset screen is inconsistent.. so would > > prefer another scalable or repeatable approach. > > > > Thanks! > > > > - Vignesh > > Mainframe Infrastructure > > > > > > MARKSANDSPENCER.COM > > > > Unless otherwise stated above: > > Marks and Spencer plc > > Registered Office: > > Waterside House > > 35 North Wharf Road > > London > > W2 1NW > > > > Registered No. 214436 in England and Wales. > > > > Telephone (020) 7935 4422 > > Facsimile (020) 7487 2670 > > > > www.marksandspencer.com > > > > Please note that electronic mail may be monitored. > > > > This e-mail is confidential. If you received it by mistake, please > > let us know and then delete it from your system; you should not > > copy, disclose, or distribute its contents to anyone nor act in > > reliance on this e-mail, as this is prohibited and may be unlawful. > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. > If you are not the addressee, you are notified that no part of the > e-mail or any attachment may be disclosed, copied or distributed, and > that any other action related to this e-mail or attachment is strictly > prohibited, and may be unlawful. If you have received this e-mail by > error, please notify the sender immediately by return e-mail, and > delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for > any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch > Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > > > -- > 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you a
Re: [EXTERNAL] Re: Storage question
I mean display with 3.4 with no dsname but a generic volser filled. This will search the VTOCs. Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Sankaranarayanan, Vignesh > Sent: 22 November, 2018 13:03 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: Storage question > > Well... the points I've listed below. > > If an alias is gone before the datasets under it are removed, the UCAT > will still have info about the datasets but they won't show up in 3.4 > > - Vignesh > Mainframe Infrastructure > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Vernooij, Kees (ITOPT1) - KLM > Sent: 22 November 2018 09:55 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: Storage question > > If they are on disk, you must be able to find them with 3.4. What makes > you doubt this? > > Kees. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Sankaranarayanan, Vignesh > > Sent: 22 November, 2018 9:28 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Storage question > > > > Hello again List! > > > > Is there a way to produce a listing of datasets (given the HLQs) based > > entirely on VTOCs? > > The assumption would be that the following are no longer available: > > > > 1. RACF profile HLQ.* > > 2. RACF user/group named 'HLQ' > > 3. Alias named 'HLQ' defined to some UCAT > > > > When the above 3 are true, I would think that we can't find the > > datasets in 3.4, but can from the ISMF Dataset screen. > > My luck with the ISMF Dataset screen is inconsistent.. so would prefer > > another scalable or repeatable approach. > > > > Thanks! > > > > - Vignesh > > Mainframe Infrastructure > > > > > > MARKSANDSPENCER.COM > > > > Unless otherwise stated above: > > Marks and Spencer plc > > Registered Office: > > Waterside House > > 35 North Wharf Road > > London > > W2 1NW > > > > Registered No. 214436 in England and Wales. > > > > Telephone (020) 7935 4422 > > Facsimile (020) 7487 2670 > > > > www.marksandspencer.com > > > > Please note that electronic mail may be monitored. > > > > This e-mail is confidential. If you received it by mistake, please let > > us know and then delete it from your system; you should not copy, > > disclose, or distribute its contents to anyone nor act in reliance on > > this e-mail, as this is prohibited and may be unlawful. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. If > you are not the addressee, you are notified that no part of the e-mail > or any attachment may be disclosed, copied or distributed, and that any > other action related to this e-mail or attachment is strictly > prohibited, and may be unlawful. If you have received this e-mail by > error, please notify the sender immediately by return e-mail, and delete > this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for any > delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > > > -- > 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the
Re: Query on JES3 DJC
*I N,ID=,LIST Check the status character(s) in message IAT8581 https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.iatb300/inqn.htm On Thu, Nov 22, 2018 at 4:52 AM RCG wrote: > Hello Experts, Quick question if anyone here has expertise on JES3 DJC > (Dependent Job Control), All I need to know is, How to find the list of > JOBS running in a given LPAR which uses DJC network please? Any pointers to > look at would be much appreciated > > Regards, > RCG > > -- > 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: z/OS 2.3 and WebSphere application server v7
we are running it under 2,2 just fine On Wednesday, November 21, 2018, 9:54:10 AM EST, Brown, Duncan wrote: I am currently running z/OS 2.1 and WebSphere application server for z/OS v7 and want to upgrade to z/OS 2.3. Has anyone run WebSphere application server for z/OS v7 under z/OS 2.3? I know that the 'official' answer from IBM is that WebSphere v7 is not supported under z/OS 2.3, but we will not be off WebSphere application server for z/OS v7 for at least a couple of years. - CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System intends this e-mail message, and any attachments, to be used only by the person(s) or entity to which it is addressed. This message may contain confidential and/or legally privileged information. If the reader is not the intended recipient of this message or an employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are prohibited from printing, copying, storing, disseminating or distributing this communication. If you received this communication in error, please delete it from your computer and notify the sender by reply e-mail. -- 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: [EXTERNAL] Re: Storage question
Well... the points I've listed below. If an alias is gone before the datasets under it are removed, the UCAT will still have info about the datasets but they won't show up in 3.4 - Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: 22 November 2018 09:55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Storage question If they are on disk, you must be able to find them with 3.4. What makes you doubt this? Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Sankaranarayanan, Vignesh > Sent: 22 November, 2018 9:28 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Storage question > > Hello again List! > > Is there a way to produce a listing of datasets (given the HLQs) based > entirely on VTOCs? > The assumption would be that the following are no longer available: > > 1. RACF profile HLQ.* > 2. RACF user/group named 'HLQ' > 3. Alias named 'HLQ' defined to some UCAT > > When the above 3 are true, I would think that we can't find the > datasets in 3.4, but can from the ISMF Dataset screen. > My luck with the ISMF Dataset screen is inconsistent.. so would prefer > another scalable or repeatable approach. > > Thanks! > > - Vignesh > Mainframe Infrastructure > > > MARKSANDSPENCER.COM > > Unless otherwise stated above: > Marks and Spencer plc > Registered Office: > Waterside House > 35 North Wharf Road > London > W2 1NW > > Registered No. 214436 in England and Wales. > > Telephone (020) 7935 4422 > Facsimile (020) 7487 2670 > > www.marksandspencer.com > > Please note that electronic mail may be monitored. > > This e-mail is confidential. If you received it by mistake, please let > us know and then delete it from your system; you should not copy, > disclose, or distribute its contents to anyone nor act in reliance on > this e-mail, as this is prohibited and may be unlawful. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: [EXTERNAL] Re: Storage question
> Don't forget SMS backups and migrated datasets. Hmm.. so a DCOLLECT will show what's where? – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: 22 November 2018 09:45 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Storage question Don't forget SMS backups and migrated datasets. On Thu, Nov 22, 2018 at 2:28 AM Sankaranarayanan, Vignesh wrote: > > Hello again List! > > Is there a way to produce a listing of datasets (given the HLQs) based > entirely on VTOCs? > The assumption would be that the following are no longer available: > > 1. RACF profile HLQ.* > 2. RACF user/group named 'HLQ' > 3. Alias named 'HLQ' defined to some UCAT > > When the above 3 are true, I would think that we can't find the datasets in > 3.4, but can from the ISMF Dataset screen. > My luck with the ISMF Dataset screen is inconsistent.. so would prefer > another scalable or repeatable approach. > > Thanks! > > - Vignesh > Mainframe Infrastructure > > > MARKSANDSPENCER.COM > > Unless otherwise stated above: > Marks and Spencer plc > Registered Office: > Waterside House > 35 North Wharf Road > London > W2 1NW > > Registered No. 214436 in England and Wales. > > Telephone (020) 7935 4422 > Facsimile (020) 7487 2670 > > www.marksandspencer.com > > Please note that electronic mail may be monitored. > > This e-mail is confidential. If you received it by mistake, please let us > know and then delete it from your system; you should not copy, disclose, or > distribute its contents to anyone nor act in reliance on this e-mail, as this > is prohibited and may be unlawful. > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Query on JES3 DJC
Hello Experts, Quick question if anyone here has expertise on JES3 DJC (Dependent Job Control), All I need to know is, How to find the list of JOBS running in a given LPAR which uses DJC network please? Any pointers to look at would be much appreciated Regards, RCG -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage question
And consider multi-volume datasets, you should reconstruct their order. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mike Schwab > Sent: 22 November, 2018 10:45 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Storage question > > Don't forget SMS backups and migrated datasets. > On Thu, Nov 22, 2018 at 2:28 AM Sankaranarayanan, Vignesh > wrote: > > > > Hello again List! > > > > Is there a way to produce a listing of datasets (given the HLQs) based > entirely on VTOCs? > > The assumption would be that the following are no longer available: > > > > 1. RACF profile HLQ.* > > 2. RACF user/group named 'HLQ' > > 3. Alias named 'HLQ' defined to some UCAT > > > > When the above 3 are true, I would think that we can't find the > datasets in 3.4, but can from the ISMF Dataset screen. > > My luck with the ISMF Dataset screen is inconsistent.. so would prefer > another scalable or repeatable approach. > > > > Thanks! > > > > - Vignesh > > Mainframe Infrastructure > > > > > > MARKSANDSPENCER.COM > > > > Unless otherwise stated above: > > Marks and Spencer plc > > Registered Office: > > Waterside House > > 35 North Wharf Road > > London > > W2 1NW > > > > Registered No. 214436 in England and Wales. > > > > Telephone (020) 7935 4422 > > Facsimile (020) 7487 2670 > > > > www.marksandspencer.com > > > > Please note that electronic mail may be monitored. > > > > This e-mail is confidential. If you received it by mistake, please let > us know and then delete it from your system; you should not copy, > disclose, or distribute its contents to anyone nor act in reliance on > this e-mail, as this is prohibited and may be unlawful. > > > > -- > > 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 For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage question
If they are on disk, you must be able to find them with 3.4. What makes you doubt this? Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Sankaranarayanan, Vignesh > Sent: 22 November, 2018 9:28 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Storage question > > Hello again List! > > Is there a way to produce a listing of datasets (given the HLQs) based > entirely on VTOCs? > The assumption would be that the following are no longer available: > > 1. RACF profile HLQ.* > 2. RACF user/group named 'HLQ' > 3. Alias named 'HLQ' defined to some UCAT > > When the above 3 are true, I would think that we can't find the datasets > in 3.4, but can from the ISMF Dataset screen. > My luck with the ISMF Dataset screen is inconsistent.. so would prefer > another scalable or repeatable approach. > > Thanks! > > - Vignesh > Mainframe Infrastructure > > > MARKSANDSPENCER.COM > > Unless otherwise stated above: > Marks and Spencer plc > Registered Office: > Waterside House > 35 North Wharf Road > London > W2 1NW > > Registered No. 214436 in England and Wales. > > Telephone (020) 7935 4422 > Facsimile (020) 7487 2670 > > www.marksandspencer.com > > Please note that electronic mail may be monitored. > > This e-mail is confidential. If you received it by mistake, please let > us know and then delete it from your system; you should not copy, > disclose, or distribute its contents to anyone nor act in reliance on > this e-mail, as this is prohibited and may be unlawful. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage question
Don't forget SMS backups and migrated datasets. On Thu, Nov 22, 2018 at 2:28 AM Sankaranarayanan, Vignesh wrote: > > Hello again List! > > Is there a way to produce a listing of datasets (given the HLQs) based > entirely on VTOCs? > The assumption would be that the following are no longer available: > > 1. RACF profile HLQ.* > 2. RACF user/group named 'HLQ' > 3. Alias named 'HLQ' defined to some UCAT > > When the above 3 are true, I would think that we can't find the datasets in > 3.4, but can from the ISMF Dataset screen. > My luck with the ISMF Dataset screen is inconsistent.. so would prefer > another scalable or repeatable approach. > > Thanks! > > - Vignesh > Mainframe Infrastructure > > > MARKSANDSPENCER.COM > > Unless otherwise stated above: > Marks and Spencer plc > Registered Office: > Waterside House > 35 North Wharf Road > London > W2 1NW > > Registered No. 214436 in England and Wales. > > Telephone (020) 7935 4422 > Facsimile (020) 7487 2670 > > www.marksandspencer.com > > Please note that electronic mail may be monitored. > > This e-mail is confidential. If you received it by mistake, please let us > know and then delete it from your system; you should not copy, disclose, or > distribute its contents to anyone nor act in reliance on this e-mail, as this > is prohibited and may be unlawful. > > -- > 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: Region size for OMVS tasks
http://mzelden.com/mvsutil.html On Thu, Nov 22, 2018 at 2:43 AM Sean Gleann wrote: > > Thanks to all that have responded - we're back and running again, but not > due to any work on my part. > > > > My description of the failed system was not complete, for fear of confusing > the issue - it is a guest z/OS under z/VM that is supplied by a.n. other > party. I contacted them and the bad IEFUSI was renamed by a techie at their > end. > > > > Rob: thanks for the referral to cbttape. I wasn't aware of that particular > file there. I'll take a closer look later. I've had the comfort of a > recovery system in the past. Sadly, that wasn't an option for me in this > case. > > > > Peter: "...[54m value] has no meaning and will later be replaced..." Yes - > Overnight I began to understand that. > > No matter what I've done so far, that SMF30RGN value continues to report > '54M'. I 'new' thought for me in the course of this work is that SMF30RGN > is the REGION size that was _requested_ (as per the documentation). It is > not the size actually _given_ after IEFUSI/SMF/JES, etc have finished their > meddling. As far as I make out, there is no such 'after the fact' value > logged in any part of the type30 record (or any other). > > Which basically means that all this work has been a waste of time, based on > a misconception. > > > > Peter again: [paging space related to the problem]... sorry - my poor > description there. The alternate SYS1.IPLPARM(LOADxx) member leads to an > incomplete definition that does not specify any paging space, so it won't > IPL. > > > > Carmen and Peter: I simply did not think about the possibilities of SETPROG > EXIT..., My mind was chasing itself in circles at the time. And then the > supplier's technician fixed things up. > > > > > > I must re-visit my failed 'back-out' LOADPARM member and make sure it > brings up a minimal system - possibly with whatever I find on the cbttape. > > And abandon this line of effort - I'm pretty certain that SMF30RGN point > above is correct. > > > > Unfortunately, that leaves the cause of the original IEW4000I and CSV031I > messages unsolved. I will have to think of a different way to attack the > problem. > > > Regards > > Sean > > > On Wed, 21 Nov 2018 at 20:23, Peter Hunkeler wrote: > > > Just recognized that the parameter STATE=INACTIVE was missing in my > > previous post > > > > SETPROG EXIT,MODIFY,EXITNAME=SYS.IEFUSI,MODNAME=IEFUSI,STATE=INACTIVE > > > > > > -- > > > > Peter Hunkeler > > > > -- > > 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 -- 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: z/OS 2.3 and WebSphere application server v7
Duncan Brown wrote: >I know that the 'official' answer from IBM is that WebSphere v7 >is not supported under z/OS 2.3, but we will not be off WebSphere >application server for z/OS v7 for at least a couple of years. To my knowledge that statement is correct only because WebSphere Application Server for z/OS Version 7 reached End of Service on April 30, 2018. z/OS 2.3 became generally available on September 29, 2017. As far as I know, that release combination was officially IBM supported between those dates (and could still be officially IBM supported if you have obtained Extended Support for WAS for z/OS V7 from IBM, which might be possible). I don't see anything in the z/OS 2.3 Migration Guide that jumps out as a problem, although there are a couple possible migration tasks that can be indirectly related to WAS. I would strongly recommend applying the latest available fixpack(s) to bring the WAS release level up to 7.0.0.45 along with the corresponding Java fixpacks (which should be included) for both the 31-bit and 64-bit JVMs. The Java release level would then end up as SR16 FP60 with a build date of 20180213. If IBM Extended Support is available and contracted there may potentially be newer builds. (Ordinarily Extended Support is available for up to 3 years, so through April 30, 2021, in this case.) The Version 6 Java SDKs for z/OS reached End of Service on September 30, 2018. FP70 was the final release, and FP70 for z/OS still available for download here (as I write this): https://developer.ibm.com/javasdk/support/zos/ I would go grab all 4 builds (Version 6.0.0 31-bit and 64-bit, and Version 6.0.1 31-bit and 64-bit) *now*, just in case you need them. You might be able to "hack" FP70 onto a WAS 7.0.0.45 installation on z/OS, and that would cure whatever issues were resolved between Java V6 SR16 FP60 and SR16 FP70. However, 7.0.0.45 + FP70 wasn't an officially supported combination, at least not under standard service. Nonetheless, you might decide to run that custom combination, still at your own risk. I'm really not sure why you're held back on WAS V7, though. Ordinarily any "hold back," if it exists, is grounded in the underlying Java version. WAS 8.5.5 supported Java 6 -- the Java 6 part now past tense (see above), but WAS 8.5.5 is still in service. So you should be able to move all the way up as high as 8.5.5.13 with SDK 6.0.1 at the SR8 FP55 level, the very end of the standard service road for the Java 6 line in WAS. Details here: http://www-01.ibm.com/support/docview.wss?uid=swg27005002#WAS855J6 Same thing with "hacking" SR16 FP70 into your WAS 8.5.5 installation -- that might be technically possible, and it would resolve known issues in the SDK up through FP70, but the combination was never officially supported, at least under standard service. If you're indeed sticking on the SDK Version 6 part but can move forward to WAS 8.5.5, that'd be much better. There's no End of Service date announced yet for WAS 8.5.5, and it may be possible to get Extended Support just for the SDK Version 6, a narrower proposition, through September 30, 2021, if you need to go that long. Again, I'm assuming it's the Java version that's holding you back, which is ordinarily the case if anything is holding you back. My recollection is that WAS 8.5.5 + Java 6 was sufficient to run applications in Liberty Profile, and that might be a good idea. Let's suppose for example that you have one lagging application that'll take a couple years to remediate because there's something that breaks with Java 7 or higher, and code changes are required that are taking longer than you'd like. Meanwhile, your other 68 applications (or whatever number) are forging ahead and now run on WAS 9.x for z/OS. Instead of running two full, separate WAS instances (or multi-instances since you're probably clustered) at different release levels, maybe you could reduce the footprint of the laggard by running it in a smaller, backlevel-Java Liberty instance (8.5.5 + Java 6). The laggard application would need to be repackaged and redeployed, but the code wouldn't have to change. Or you might move the laggard into a backlevel-Java CICS Liberty instance. That approach, if viable, should cut down on some memory use if nothing else. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage question
If you check the CBT, there is a VTOC TSO command that can do what you want. Joe On Thu, Nov 22, 2018 at 2:28 AM Sankaranarayanan, Vignesh < vignesh.v.sankaranaraya...@marks-and-spencer.com> wrote: > Hello again List! > > Is there a way to produce a listing of datasets (given the HLQs) based > entirely on VTOCs? > The assumption would be that the following are no longer available: > > 1. RACF profile HLQ.* > 2. RACF user/group named 'HLQ' > 3. Alias named 'HLQ' defined to some UCAT > > When the above 3 are true, I would think that we can't find the datasets > in 3.4, but can from the ISMF Dataset screen. > My luck with the ISMF Dataset screen is inconsistent.. so would prefer > another scalable or repeatable approach. > > Thanks! > > - Vignesh > Mainframe Infrastructure > > > MARKSANDSPENCER.COM > > Unless otherwise stated above: > Marks and Spencer plc > Registered Office: > Waterside House > 35 North Wharf Road > London > W2 1NW > > Registered No. 214436 in England and Wales. > > Telephone (020) 7935 4422 > Facsimile (020) 7487 2670 > > www.marksandspencer.com > > Please note that electronic mail may be monitored. > > This e-mail is confidential. If you received it by mistake, please let us > know and then delete it from your system; you should not copy, disclose, or > distribute its contents to anyone nor act in reliance on this e-mail, as > this is prohibited and may be unlawful. > > -- > 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: Region size for OMVS tasks
Thanks to all that have responded - we're back and running again, but not due to any work on my part. My description of the failed system was not complete, for fear of confusing the issue - it is a guest z/OS under z/VM that is supplied by a.n. other party. I contacted them and the bad IEFUSI was renamed by a techie at their end. Rob: thanks for the referral to cbttape. I wasn't aware of that particular file there. I'll take a closer look later. I've had the comfort of a recovery system in the past. Sadly, that wasn't an option for me in this case. Peter: "...[54m value] has no meaning and will later be replaced..." Yes - Overnight I began to understand that. No matter what I've done so far, that SMF30RGN value continues to report '54M'. I 'new' thought for me in the course of this work is that SMF30RGN is the REGION size that was _requested_ (as per the documentation). It is not the size actually _given_ after IEFUSI/SMF/JES, etc have finished their meddling. As far as I make out, there is no such 'after the fact' value logged in any part of the type30 record (or any other). Which basically means that all this work has been a waste of time, based on a misconception. Peter again: [paging space related to the problem]... sorry - my poor description there. The alternate SYS1.IPLPARM(LOADxx) member leads to an incomplete definition that does not specify any paging space, so it won't IPL. Carmen and Peter: I simply did not think about the possibilities of SETPROG EXIT..., My mind was chasing itself in circles at the time. And then the supplier's technician fixed things up. I must re-visit my failed 'back-out' LOADPARM member and make sure it brings up a minimal system - possibly with whatever I find on the cbttape. And abandon this line of effort - I'm pretty certain that SMF30RGN point above is correct. Unfortunately, that leaves the cause of the original IEW4000I and CSV031I messages unsolved. I will have to think of a different way to attack the problem. Regards Sean On Wed, 21 Nov 2018 at 20:23, Peter Hunkeler wrote: > Just recognized that the parameter STATE=INACTIVE was missing in my > previous post > > SETPROG EXIT,MODIFY,EXITNAME=SYS.IEFUSI,MODNAME=IEFUSI,STATE=INACTIVE > > > -- > > Peter Hunkeler > > -- > 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
Storage question
Hello again List! Is there a way to produce a listing of datasets (given the HLQs) based entirely on VTOCs? The assumption would be that the following are no longer available: 1. RACF profile HLQ.* 2. RACF user/group named 'HLQ' 3. Alias named 'HLQ' defined to some UCAT When the above 3 are true, I would think that we can't find the datasets in 3.4, but can from the ISMF Dataset screen. My luck with the ISMF Dataset screen is inconsistent.. so would prefer another scalable or repeatable approach. Thanks! - Vignesh Mainframe Infrastructure MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
