Re: Dataset in use on shared DASD
Opened of just ENQueued? Not on the same LPAR? Within the same Sysplex? If within the same Sysplex, just open it and the system will let you know if it succeded. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of George Shedlock Sent: 31 August, 2015 22:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dataset in use on shared DASD How can I tell from a REXX program if a dataset is open on another LPAR? The dataset resides on shared dasd. George Shedlock -- 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: how to know the length and blocksize of each member in dataset
I do this with SAS, to know the blocklength distribution of PDSs, e.g. of CLIST or PARMLIB PDSs to determine an optimal blocksize. Read it with RECFM=U,BLKSIZE=32767 and check the length of each block. Sum the blocks per member to know its size. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ibmmain Sent: 01 September, 2015 7:57 To: IBM-MAIN@LISTSERV.UA.EDU Subject: how to know the length and blocksize of each member in dataset Hi all Is there any utility to know the length and blocksize of each member (modules) in dataset ? Thanks a lot! Jason Cai -- 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
AW: Re: Dataset in use on shared DASD
> D GRS,C This is of no value when there is no contention. Nothing will be returned. You might have been thinking of this command: D GRS,RES=(SYSDSN,data.set.of.interrest) But even this command will at most tell you something about whether the dataset is currently allocated or not. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: ENQ rname_addr description
> The RNAME must be from 1 to 255 bytes long, and can contain any hexadecimal
> character from X'00' to
X'FF'.
To me a character is a character, thus a "hexadecimal character" would be one
of {C'a', ..., C'f', C'A', ..., C'F', C'0', ..., C'9' }. Why not "... 255 bytes
long, and can contain bytes of any value, i.e. x'00' to x'FF'"
--
Peter Hunkeler
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
how to know the length and blocksize of each member in dataset
Hi all Is there any utility to know the length and blocksize of each member (modules) in dataset ? Thanks a lot! Jason Cai -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe hyperlink
To my knowledge all IBM host access software supports clickable URLs,
a.k.a. URL hotspots. That includes Personal Communications, Host On-Demand
("HOD"), and Host Access Transformation Services ("HATS").
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
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: ENQ rname_addr description
On Mon, 31 Aug 2015 18:14:10 -0400, Joseph W Gentile wrote: >I think the description of RNAME= in the ISGENQ macro doc is more clear. I >could potentially use the wording in the last sentence "The RNAME must be >from 1 to 255 bytes long, and can contain any hexadecimal character from >X'00' to X'FF'" to update the ENQ rname_addr doc. What do you think? Also, >I encourage you to check out the newer ISGENQ macro, in case it has >features you might find useful. > Much better. Thanks. In: z/OS 2.1.0>z/OS MVS>z/OS MVS Planning: Global Resource Serialization>Global Resource Serialization>Introduction>ISGENQ macro I also see: ... ISGENQ includes parameter checking to ensure that authorized callers use authorized qnames. ... I'd prefer: "ISGENQ includes parameter checking to ensure that *only* authorized callers use authorized qnames." As it stands, it seems to imply that authorized callers are restricted to using authorized qnames (I suppose that may be true) and non-authorized callers are not so restricted. ... REQUEST=CHANGE Change the status of an ISGENQ request from shared to exclusive. ... Doesn't z/OS 2.1 also support changing from exclusive to shared? Want an RCF (or two)? Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe hyperlink
I just learned from the man himself that Vista3270 also has this capability. There is a built-in macro call hotspot, i.e. hotspot.mac, that performs this function. For convenience, pick a keyboard function to assign hotspot.mac to. In Keyboard edit, I chose mouse-left-click with CTRL. So position the cursor on a URL on the screen, then CTRL-left-click. This opens your default browser to the URL. Thanks Tom. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chambers, David W. Sent: Monday, August 31, 2015 11:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe hyperlink Actually, PCOM will do this if you happen to have it. If PCOM can interpret what you double click on as a URL it will fire it off to your default browser. Try typing: http://www.google.com or whatever your favorite web site might be on a mainframe screen somewhere: ISPF edit screen, TSO ready, etc. and double click it. Not sure if there's a configuration setting to allow/disallow this behavior. Our Security folks used to use this facility to link to user docs for one of their ISPF applications. No reason the URL couldn't point to a mainframe web page/CGI script/what-have-you. Might need to run a URL shortener somewhere in your enterprise. The Security docs link pointed to Sharepoint and those links tend to get very long very fast. Least ways, that's my experience. At the time I ran something called SURL on Linux for z for them. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Eamon C Sent: Friday, August 28, 2015 9:41 AM To: IBM-MAIN@listserv.ua.edu Subject: [EXTERNAL] Re: Mainframe hyperlink z/OS -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ENQ rname_addr description
I think the description of RNAME= in the ISGENQ macro doc is more clear. I could potentially use the wording in the last sentence "The RNAME must be from 1 to 255 bytes long, and can contain any hexadecimal character from X'00' to X'FF'" to update the ENQ rname_addr doc. What do you think? Also, I encourage you to check out the newer ISGENQ macro, in case it has features you might find useful. RNAME=rname When RESLIST=NO and REQUEST=OBTAIN are specified, a required input parameter that is the RNAME for the resource. The RNAME must be from 1 to 255 bytes long, and can contain any hexadecimal character from X'00' to X'FF'. To code: Specify the RS-type address, or address in register (2)-(12), of a character field. -Joe Joe Gentile z/OS GRS Lead (845)435-2184 (T/L 295-2184) jwgen...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataset in use on shared DASD
This looks like a better idea. I was overthinking the analysis side.
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Monday, August 31, 2015 2:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset in use on shared DASD
On 2015-08-31 15:21, J O Skip Robinson wrote:
> Gil right about the difficulty of determining opened vs. allocated,
> but maybe that does not matter. As for Rexx, being a simple minded
> person, I would issue the OS command
>
> D GRS,C
>
> and parse the output returned to the Rexx. You can see whether the data set
> is 'in use' on another system. I hope that all sharing systems are in a
> single GRS-plex...
>
... Which still leaves the timing window. That tells you only whether the DSN
*was* in use when the Display command was issued. I'd prefer:
user@OS/390.24.00: rexx "trace R; \
> DSN = foo.bar; \
> say BPXWDYN( 'alloc rtddn(D) dsn('DSN') new delete msg(2)' ); \
> say 'Do whatever is needed with' DSN 'and' D'.'; \
> say BPXWDYN( 'freedd('D') msg(2)' ); \
> "
1 *-* DSN = foo.bar
>>>"FOO.BAR"
*-* say BPXWDYN( 'alloc rtddn(D) dsn('DSN') new delete msg(2)' )
>>>"0"
0
*-* say 'Do whatever is needed with' DSN 'and' D'.'
>>>"Do whatever is needed with FOO.BAR and SYS1."
Do whatever is needed with FOO.BAR and SYS1.
*-* say BPXWDYN( 'freedd('D') msg(2)' )
>>>"0"
0
... The ENQ EXC guarantees that the DSN is not in use for the duration.
-- gil
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lizette Koehler
> Sent: Monday, August 31, 2015 2:05 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Dataset in use on shared DASD
>
> If you were not aware, there is a list dedicated to all things REXX To
> join, if you have not done so, you can do the following
>
> http://www2.marist.edu/htbin/wlvindex?tso-rexx
> go to the bottom of the webpage
>
> Lizette
>
>
> -Original Message-
>> From: George Shedlock
>> Sent: Aug 31, 2015 1:37 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Dataset in use on shared DASD
>>
>> How can I tell from a REXX program if a dataset is open on another LPAR? The
>> dataset resides on shared dasd.
>>
>> George Shedlock
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend jobs not showing on Console
You might try some of these functions from CBTTAPE.ORG File # 447 ENQMON from Rick Fochtman - GRS displays like MIM's File # 626 EN (display enqueues), JI (JES2 inits), CSA execs File # 732 A familiar version of the WHOHAS command Lizette -Original Message- >From: "Roach, Dennis" >Sent: Aug 31, 2015 12:40 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Abend jobs not showing on Console > >Check your console route codes. > >Also check any automation, message processing products, or MPF exits to make >sure they are not suppressing the messages. > >Dennis Roach, CISSP, PMP >IT Security Administration Senior Analyst >2727 Allen Parkway, Wortham Building 3rd Floor, Houston, TX 77019 >Work: 713-831-8799 >Cell: 713-591-1059 >Email: dennis.ro...@aig.com >Report information security incidents to: aiglr_security_incide...@aig.com and >(818) 673-4030 > >All opinions expressed by me are mine and may not agree with my employer or >any person, company, or thing, living or dead, on or near this or any other >planet, moon, asteroid, or other spatial object, natural or manufactured, >since the beginning of time. > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Chandramohan, Harish - CW >Sent: Monday, August 31, 2015 12:47 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Abend jobs not showing on Console > >Am not sure why I don't see any of the abended jobs on my console all of a >sudden. > >Thanks! > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataset in use on shared DASD
On 2015-08-31 15:21, J O Skip Robinson wrote:
> Gil right about the difficulty of determining opened vs. allocated, but maybe
> that does not matter. As for Rexx, being a simple minded person, I would
> issue the OS command
>
> D GRS,C
>
> and parse the output returned to the Rexx. You can see whether the data set
> is 'in use' on another system. I hope that all sharing systems are in a
> single GRS-plex...
>
... Which still leaves the timing window. That tells you only whether
the DSN *was* in use when the Display command was issued. I'd prefer:
user@OS/390.24.00: rexx "trace R; \
> DSN = foo.bar; \
> say BPXWDYN( 'alloc rtddn(D) dsn('DSN') new delete msg(2)' ); \
> say 'Do whatever is needed with' DSN 'and' D'.'; \
> say BPXWDYN( 'freedd('D') msg(2)' ); \
> "
1 *-* DSN = foo.bar
>>>"FOO.BAR"
*-* say BPXWDYN( 'alloc rtddn(D) dsn('DSN') new delete msg(2)' )
>>>"0"
0
*-* say 'Do whatever is needed with' DSN 'and' D'.'
>>>"Do whatever is needed with FOO.BAR and SYS1."
Do whatever is needed with FOO.BAR and SYS1.
*-* say BPXWDYN( 'freedd('D') msg(2)' )
>>>"0"
0
... The ENQ EXC guarantees that the DSN is not in use for the duration.
-- gil
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Monday, August 31, 2015 2:05 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Dataset in use on shared DASD
>
> If you were not aware, there is a list dedicated to all things REXX To join,
> if you have not done so, you can do the following
>
> http://www2.marist.edu/htbin/wlvindex?tso-rexx
> go to the bottom of the webpage
>
> Lizette
>
>
> -Original Message-
>> From: George Shedlock
>> Sent: Aug 31, 2015 1:37 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Dataset in use on shared DASD
>>
>> How can I tell from a REXX program if a dataset is open on another LPAR? The
>> dataset resides on shared dasd.
>>
>> George Shedlock
>
>
> --
> 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: Abend jobs not showing on Console
Check your console route codes. Also check any automation, message processing products, or MPF exits to make sure they are not suppressing the messages. Dennis Roach, CISSP, PMP IT Security Administration Senior Analyst 2727 Allen Parkway, Wortham Building 3rd Floor, Houston, TX 77019 Work: 713-831-8799 Cell: 713-591-1059 Email: dennis.ro...@aig.com Report information security incidents to: aiglr_security_incide...@aig.com and (818) 673-4030 All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chandramohan, Harish - CW Sent: Monday, August 31, 2015 12:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Abend jobs not showing on Console Am not sure why I don't see any of the abended jobs on my console all of a sudden. Thanks! -- 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: Dataset in use on shared DASD
Gil right about the difficulty of determining opened vs. allocated, but maybe that does not matter. As for Rexx, being a simple minded person, I would issue the OS command D GRS,C and parse the output returned to the Rexx. You can see whether the data set is 'in use' on another system. I hope that all sharing systems are in a single GRS-plex... . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, August 31, 2015 2:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dataset in use on shared DASD If you were not aware, there is a list dedicated to all things REXX To join, if you have not done so, you can do the following http://www2.marist.edu/htbin/wlvindex?tso-rexx go to the bottom of the webpage Lizette -Original Message- >From: George Shedlock >Sent: Aug 31, 2015 1:37 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Dataset in use on shared DASD > >How can I tell from a REXX program if a dataset is open on another LPAR? The >dataset resides on shared dasd. > >George Shedlock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe hyperlink
Actually, PCOM will do this if you happen to have it. If PCOM can interpret what you double click on as a URL it will fire it off to your default browser. Try typing: http://www.google.com or whatever your favorite web site might be on a mainframe screen somewhere: ISPF edit screen, TSO ready, etc. and double click it. Not sure if there's a configuration setting to allow/disallow this behavior. Our Security folks used to use this facility to link to user docs for one of their ISPF applications. No reason the URL couldn't point to a mainframe web page/CGI script/what-have-you. Might need to run a URL shortener somewhere in your enterprise. The Security docs link pointed to Sharepoint and those links tend to get very long very fast. Least ways, that's my experience. At the time I ran something called SURL on Linux for z for them. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Eamon C Sent: Friday, August 28, 2015 9:41 AM To: IBM-MAIN@listserv.ua.edu Subject: [EXTERNAL] Re: Mainframe hyperlink z/OS -- 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: Dataset in use on shared DASD
If you were not aware, there is a list dedicated to all things REXX To join, if you have not done so, you can do the following http://www2.marist.edu/htbin/wlvindex?tso-rexx go to the bottom of the webpage Lizette -Original Message- >From: George Shedlock >Sent: Aug 31, 2015 1:37 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Dataset in use on shared DASD > >How can I tell from a REXX program if a dataset is open on another LPAR? The >dataset resides on shared dasd. > >George Shedlock > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataset in use on shared DASD
On Mon, 31 Aug 2015 20:37:19 +, George Shedlock wrote: >How can I tell from a REXX program if a dataset is open on another LPAR? The >dataset resides on shared dasd. > ALLOCATEd is easy; OPEN is harder (or at least I don't know). What is your objective? (How will you behave differently if the data set is OPEN?) If you can make the determination, is there yet a timing window? You might issue whatever query and get the reply, "not OPEN" and act accordingly, but that other LPAR might OPEN it in the interim. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dataset in use on shared DASD
How can I tell from a REXX program if a dataset is open on another LPAR? The dataset resides on shared dasd. George Shedlock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend jobs not showing on Console
It would help to have more information. 1) What consoled? SDSF, MSTCON, etc 2) When did it disappear? 3) Any changes implemented when the messages disappeared? 4) Do you have any automation tools that might be suppressing the message? 5) Can you see the messages in SYSLOG? 6) See how the console is defined. Any changes? 7) What messages specifically are your missing? IEE, IGD, home grown message ID? This will probably be unique to your ID, console and/or shop. Have you contacted your System Programmers to see what has changed? Lizette -Original Message- >From: "Chandramohan, Harish - CW" >Sent: Aug 31, 2015 10:46 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Abend jobs not showing on Console > >Am not sure why I don't see any of the abended jobs on my console all of a >sudden. > >Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Abend jobs not showing on Console
Am not sure why I don't see any of the abended jobs on my console all of a sudden. Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Smaller Private Area in DR
I think a lot of shops use this strategy for managing the common/private boundary. 1. Look at a running system. 2. Verify that the system is happy with defined CSA/SQA. 3. Verify that the private area is 'satisfactory', i.e. not too small nor needlessly large. 4. Calculate the contribution to CSA/SQA that IEASYSxx values have added to the z/OS requirement. 5. Adjust the IEASYSxx values to the midpoint of the final 1M portion. Since the user specification will tweak the 1M boundary placement, we aim to maximize any possible fluctuation that will preserve the private area sweet spot. That is, allow for 512K up or down in z/OS calculation without changing private area, which many (most?) systems are most sensitive to. OP's problem after all is to explain a 1M drop in private, not a change to common. BTW I looked at my VSM health checks but did not see this information displayed starkly. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Saturday, August 29, 2015 6:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Smaller Private Area in DR The real question is when the COMMON/PRIVATE boundary gets set. IODF must be read and digested very early in IPL, certainly before SYS1.PARMLIB is opened. By the time IEASYSxx is processed, do below-the-line UCBs figure into the boundary calculation? It works something like this: -- Load the nucleus. Thus we have a definition for where that starts and ends. -- Build things such as UCB's that require common storage (think of that as initial SQA) -- Read system parameters to see the definitions of SQA, CSA -- Now determine the boundary of SQA (multiple of 64K?) based on the initial SQA and the SQA specification -- Now build LPA -- Use the LPA boundaries and the CSA size to define the CSA boundaries (1M multiple?) -- That is when the Common/Private boundary is set Any differences in the "earlier" areas can affect the Common/Private boundary. I seem to recall (but might be wrong) that one of the VSM health checks reports on how close you are to the point where you will lose 1M of private. 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
Re: LE Condition Handler
Peter Hunkeler wrote: >And this very fact disqualifies an x22 recovery routine as the solution for >such an important task as writing data out to disk. Indeed. Such a job is probably busy with a messy loop... (been there, seen that. Stop the thing and you lose goodies... g) >Been there seen that: Operators issuing "C SOMEJOB" some 50 times within 10 >minutes or so (no joke, and that's not the whole story) against some hanging >address space which did not get cancelled. I doubt if today's command flooding things may stop that Operator, but you could perhaps setup your automation software to sit in a counter somewhere, wait for exceeding a set value and then alert some top-brass to kick that operator [ and his/her fingers ] out. John McKown wrote: >Evil thought. I am reminded of something that I saw back in college (1970s) >when I was an RJE operator. I could do the MVT equivalent of an "D A,L" >command. And I say one job in execution with the name like "NOT/ME" Yes, there >was a slash in the name! So how to stop somebody from doing a CANCEL operator >command on your job? I have RTFM now to review the P, C and FORCE commands. Still in 2015 today, you can't use A= only... How did they start it in the first place? [ Forget for now the RACF and its STARTED+JESSPOOL classes which were not available then... ] >Go key 0, ... Of course, it might be easier to simply flip on the >non-cancelable bit in whatever control block that keeps it (I don't know / >remember). I believe that field is hidden pretty good these OCO days. I could not find it in my books and macros, just a little note in SCHEDxx. >Even easier is to do what I have done for some specific STC names: use >CA-OPS/MVS command rules to "just say 'No!' ". We had to do this for range >commands because we had some dyslexic(?) operators who meant to vary off 1 >device and somehow varied off hundreds. Automation is a blessing in such cases. Some commands like start/stop printers or other devices can be intercepted. Other just check the parameters and if it falls in a 'correct' range, the command is passed on. Or use Automation to translate a [custom] word typed on console into a full syntax valid command+parameters and off you go. >But I'm going very far afield from what the OP was talking about, now. Hahaha. Define 'far'... ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: SMF Type 30
>I believe I have seen it discussed that "task" is more closely akin to >"thread". Threads also need TCBs under the hood. Processes and threads are both ways to perform multitasking, so both need TCBs. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: SMF Type 30
> I believe I have seen it discussed that "task" is more closely akin to > "thread". Regardless of the packaging, there are only two types of dispatchable work in z/OS: Tasks and SRBs. Bob Shannon Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: SMF Type 30
On Mon, 31 Aug 2015 13:46:26 +0200, Peter Hunkeler wrote: >>My belief is that the IBM developers know what a task is and would not have >>included "task" in the field name if the field applied to anything other than >>a task. > > >They sure know and they sure know that a UNIX processs is just a standard MVS >task with some additional attributes. If a program running as a UNIX process >does, for example, a local spawn(), it creates a new process in the very same >address space. But this process needs to be tied to a TCB in order to be >dispatchable, so a new task is created as part of spwn() processing. > I believe I have seen it discussed that "task" is more closely akin to "thread". -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Anyone Using...PSF-Managed, Channel-Attached Printers?
A former employer of mine was heavily using a couple of ESCON channel attached Océ printers under PSF. They changed the interface to TCP/IP around 2011 (roughly). Still heavy PSF users but only with TCP/IP attached printers. --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: LE Condition Handler
> Retry is not possible, though, and if the operator issues a second cancel > command the non-APF program cannot trap that one, but the first one can be > handled. And this very fact disqualifies an x22 recovery routine as the solution for such an important task as writing data out to disk. Been there seen that: Operators issuing "C SOMEJOB" some 50 times within 10 minutes or so (no joke, and that's not the whole story) against some hanging address space which did not get cancelled. With this experience in mind, I would never consider an ESTAE exit to be able to reliably do lengthy actions on a x22 abend. And I consider writing important data out to disk to be an endless lengthy operation. Alternatives: - Could you change the code to use a coupling factility structure to keep that index data? - Could you change the code to use a system logger logstream? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: SMF Type 30
>My belief is that the IBM developers know what a task is and would not have >included "task" in the field name if the field applied to anything other than >a task. They sure know and they sure know that a UNIX processs is just a standard MVS task with some additional attributes. If a program running as a UNIX process does, for example, a local spawn(), it creates a new process in the very same address space. But this process needs to be tied to a TCB in order to be dispatchable, so a new task is created as part of spwn() processing. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
