Re: Recovery routines
Your AUTHxxx cmdproc runs under the parallel authorized TMP whilst all other tasks in the address space are STATUS STOPed. The ESTAE environment established by the caller will NOT be invoked for any abends in the cmdproc running on the parallel task structure. To handle abends in the AUTHxxx cmdproc - it must establish its own recovery environment. You can read the documentation about IKJEFTSR in the TSO/E Programming Services manual for more information in this area. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Butz Sent: 28 August 2014 13:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Recovery routines ISPF is not part of the equation Is plain vanilla TSO The second program is loaded and balr'ed to The library is APF authorized My question is the abend occurs in a different environment then from where the estae(x) was established E.g XMEM authorized etc does the recovery rtn get control Thanks Sent from my iPhone On Aug 28, 2014, at 1:27 AM, Jon Perryman jperr...@pacbell.net wrote: TSO CMDPGM is how your program was invoked from the ISPF display. How did your program call the next program? Was it thru ISPEXEC SELECT PGM or assembler LINK or ??? If it was ISPEXEC, then your problem is that ISPF is setting an ESTAE. If it's thru LINK then maybe ISPF is intercepting the SVC. If the problem is ISPF setting the ESTAE then calling ISPEXEC CONTROL SUBTASK CLEAR from the second program may resolve your problem. TSO is complicating your question and causing your confusion. TSO violates the restriction when you run authorized programs when unauthorized libraries are in the steplib/joblib/calllib concatenations. To ensure unauthorized programs never have access to an authorized environment, TSO must take extraordinary measures to make sure these programs never have access to an authorized environment. You see this by the use of authpgm and authcmd. I bring this up as a WARNING because you somehow call another program from under AUTHCMD authorized program. You must take extreme care not to allow a program from an UNAUTHORIZED library otherwise you expose your entire system. If you don't use standard call methods (e.g. LINK), then you have an exposure that must be fixed. In TSO, authorized programs are executed under a special authorized task. This will cause programs to run authorized to execute in another TCB. But for your ESTAE, this is not specifically important. What's important is where the called program executes versus your program. Set a slip for the abend to take a dump. In the trace table, you estae and the the abend should have the same TCB. If not, then TSO is probably at fault. If not, you can see who sets an estae after your ESTAE. If ISPF is setting it, then You can look where your both programs are running. If they are under the same TCB then maybe you can see if which ISPF function is somehow setting the ESTAE.. Jon Perryman On Wednesday, August 27, 2014 3:02 PM, Micheal Butz michealb...@comcast.net wrote: I want to accomplish to have complete coverage for my program By that I mean anytime I get an abend in any state I want my recovery routine to get control Sent from my iPhone On Aug 27, 2014, at 5:56 PM, Tony Harminc t...@harminc.net wrote: On 27 August 2014 16:48, Micheal Butz michealb...@comcast.net wrote: I have question I understand that an authorized command run under a different tmp Well, a different task structure. Is that always meaning the same program while in problem state runs Under one tmp and when I switch to Supervisor under another No - it doesn't work that way at all. Once it's been decided that a command will run APF authorized, it is dispatched under a different task structure, while the unauthorized stuff is all status stopped. If you are able to switch to supervisor state, you were authorized by definition (or IBM will fix it PDQ!), so you won't be running under the unauthorized branch. If so I established my estae(x) In Problems state and I abended in supervisor state my recovery rtn wouldn't get control Well, sort-of. But it's both stronger and more subtle than that. -- 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 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe
Re: Is there a CPU cost to using key9 storage while running with key8
-Original Message- From: IBM Mainframe Discussion List On Behalf Of David Price What hardware are you on? I ask because a z196 has some high CPU costs for certain PSW Key-related instructions. For example, SPKA (Set PSW Key from Address) on a z196 shows up in CICS CPU figures because it stalls the pipeline when changing PSW keys between key 8 and key 9 -- or even when it doesn't change keys e.g. it is just 'going' from key 8 to key 8! SPKA may be executed in CICS more than you think (consider User Exits -- GLUEs and TRUEs -- some of which may have been inserted by your monitoring software). An interesting observation. I'd have thought that CICS (in particular), in an early stage of startup when it runs authorized, would set the Storage-Protection-Override Control (bit 39 of CR0) if STGPROT=YES was specified as a DFHSIT parm. See z/Architecture Principles of Operation, 10th Edition, at page 3-12 for details of Storage-Protection-Override Control. This would seem to obviate any need for CICS, post-initialization when running unauthorized, to issue SPKA or similar key-related instructions. -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a CPU cost to using key9 storage while running with key8
Sorry: ... key-related instructions simply to access key9 storage. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chase, John Sent: Friday, August 29, 2014 7:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there a CPU cost to using key9 storage while running with key8 -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Price What hardware are you on? I ask because a z196 has some high CPU costs for certain PSW Key-related instructions. For example, SPKA (Set PSW Key from Address) on a z196 shows up in CICS CPU figures because it stalls the pipeline when changing PSW keys between key 8 and key 9 -- or even when it doesn't change keys e.g. it is just 'going' from key 8 to key 8! SPKA may be executed in CICS more than you think (consider User Exits -- GLUEs and TRUEs -- some of which may have been inserted by your monitoring software). An interesting observation. I'd have thought that CICS (in particular), in an early stage of startup when it runs authorized, would set the Storage-Protection-Override Control (bit 39 of CR0) if STGPROT=YES was specified as a DFHSIT parm. See z/Architecture Principles of Operation, 10th Edition, at page 3-12 for details of Storage-Protection-Override Control. This would seem to obviate any need for CICS, post-initialization when running unauthorized, to issue SPKA or similar key-related instructions. -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- 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: Is there a CPU cost to using key9 storage while running with key8
On Thu, 28 Aug 2014 12:15:57 -0700, Ed Jaffe wrote: ISTR it used to be that prefetched cache lines were thrown away on a key change. I'm not sure if that's true any more. That might be a design decision, that it's less costly to discard the entire cache line infrequently than to verify the key on every access. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a CPU cost to using key9 storage while running with key8
On 8/29/2014 6:41 AM, Paul Gilmartin wrote: On Thu, 28 Aug 2014 12:15:57 -0700, Ed Jaffe wrote: ISTR it used to be that prefetched cache lines were thrown away on a key change. I'm not sure if that's true any more. That might be a design decision, that it's less costly to discard the entire cache line infrequently than to verify the key on every access. The key value for SPKA is provided in a register (more accurately, by a base+displacement calculation), so the target key cannot be known early unless the base register is coded as GPR0. Even then, the instruction might be updated in storage before it executes. If there has been an optimization in this processing over the years, it's likely to assume, at prefetch time, that SPKAs coded with GPR0 are exactly what they appear to be... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COMPILING A REPORT USING FDREPORT
G'Day I am trying to run a report using FDREPORT to know what dsns are using a specific DATACLAS. In this case the DATACLAS is for VTS. The example in the doc is for disk dsns. Can this be done for dsns on tape or VTS? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COMPILING A REPORT USING FDREPORT
I thnk the good folks at Innovations can help. On Fri, 8/29/14, John Dawes jhn_da...@yahoo.com.au wrote: Subject: COMPILING A REPORT USING FDREPORT To: IBM-MAIN@LISTSERV.UA.EDU Received: Friday, August 29, 2014, 10:27 AM G'Day I am trying to run a report using FDREPORT to know what dsns are using a specific DATACLAS. In this case the DATACLAS is for VTS. The example in the doc is for disk dsns. Can this be done for dsns on tape or VTS? -- 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: Recovery routines
I do establish the estaex in the cmdproc the authorized program at the time it is in problem state ASC primary I load a program BALR to it at the time of the abend Iam in Supervisor state ASC AR storage key 0 does that matter For my recovery routine to get control What I wll do under TESTAUTH is do a LISTTCB at the time I establish the esate(x) and another LISTTCB when I am in ASC AR supervisor state storage key 0 and see it thr TCB is the same Thankx -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Friday, August 29, 2014 5:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Recovery routines Your AUTHxxx cmdproc runs under the parallel authorized TMP whilst all other tasks in the address space are STATUS STOPed. The ESTAE environment established by the caller will NOT be invoked for any abends in the cmdproc running on the parallel task structure. To handle abends in the AUTHxxx cmdproc - it must establish its own recovery environment. You can read the documentation about IKJEFTSR in the TSO/E Programming Services manual for more information in this area. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Butz Sent: 28 August 2014 13:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Recovery routines ISPF is not part of the equation Is plain vanilla TSO The second program is loaded and balr'ed to The library is APF authorized My question is the abend occurs in a different environment then from where the estae(x) was established E.g XMEM authorized etc does the recovery rtn get control Thanks Sent from my iPhone On Aug 28, 2014, at 1:27 AM, Jon Perryman jperr...@pacbell.net wrote: TSO CMDPGM is how your program was invoked from the ISPF display. How did your program call the next program? Was it thru ISPEXEC SELECT PGM or assembler LINK or ??? If it was ISPEXEC, then your problem is that ISPF is setting an ESTAE. If it's thru LINK then maybe ISPF is intercepting the SVC. If the problem is ISPF setting the ESTAE then calling ISPEXEC CONTROL SUBTASK CLEAR from the second program may resolve your problem. TSO is complicating your question and causing your confusion. TSO violates the restriction when you run authorized programs when unauthorized libraries are in the steplib/joblib/calllib concatenations. To ensure unauthorized programs never have access to an authorized environment, TSO must take extraordinary measures to make sure these programs never have access to an authorized environment. You see this by the use of authpgm and authcmd. I bring this up as a WARNING because you somehow call another program from under AUTHCMD authorized program. You must take extreme care not to allow a program from an UNAUTHORIZED library otherwise you expose your entire system. If you don't use standard call methods (e.g. LINK), then you have an exposure that must be fixed. In TSO, authorized programs are executed under a special authorized task. This will cause programs to run authorized to execute in another TCB. But for your ESTAE, this is not specifically important. What's important is where the called program executes versus your program. Set a slip for the abend to take a dump. In the trace table, you estae and the the abend should have the same TCB. If not, then TSO is probably at fault. If not, you can see who sets an estae after your ESTAE. If ISPF is setting it, then You can look where your both programs are running. If they are under the same TCB then maybe you can see if which ISPF function is somehow setting the ESTAE.. Jon Perryman On Wednesday, August 27, 2014 3:02 PM, Micheal Butz michealb...@comcast.net wrote: I want to accomplish to have complete coverage for my program By that I mean anytime I get an abend in any state I want my recovery routine to get control Sent from my iPhone On Aug 27, 2014, at 5:56 PM, Tony Harminc t...@harminc.net wrote: On 27 August 2014 16:48, Micheal Butz michealb...@comcast.net wrote: I have question I understand that an authorized command run under a different tmp Well, a different task structure. Is that always meaning the same program while in problem state runs Under one tmp and when I switch to Supervisor under another No - it doesn't work that way at all. Once it's been decided that a command will run APF authorized, it is dispatched under a different task structure, while the unauthorized stuff is all status stopped. If you are able to switch to supervisor state, you were authorized by definition (or IBM will fix it PDQ!), so you won't be running under the unauthorized branch. If so I established my estae(x) In Problems state and I abended in
Re: COMPILING A REPORT USING FDREPORT
Do you have any of the following CA Products you can install CA GMI (Graphical Manager Interface) A LITE version of CA VANTAGE The following are CA GMI qualified CA products: CA 1 CA TLMS CA ASTEX CA CREWS CA Datacom/DB CA Disk CA IDMS/DB CA MasterCat CA SYSVIEW CA PDSMAN CA Vtape CA Tape Encryption CA Encryption Key Manager Next, look at ISMF. Either Option 2.3 or maybe option 1 Or download the IBM TAPETOOLS and use it for reporting on your tapes. It does not matter if the VTS is IBM's or some other vendor. It does reporting on the SMF records ftp://ftp.software.ibm.com/storage/tapetool/ If you have an IBM VTS, then check out this link http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS4717 I am not sure FDR provides reporting on TAPE this way. However, if you contact them, I am sure they can answer your question. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes Sent: Friday, August 29, 2014 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: COMPILING A REPORT USING FDREPORT G'Day I am trying to run a report using FDREPORT to know what dsns are using a specific DATACLAS. In this case the DATACLAS is for VTS. The example in the doc is for disk dsns. Can this be done for dsns on tape or VTS? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COMPILING A REPORT USING FDREPORT
We have CA-1. I will take a look at that option. Thanks for the tip. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Understanding Data Set Information?
My command was (after deleting the output data set): _UNIX03=NO cp -B -P'SPACE=(1,(0,300)),BLKSIZE=0' /dev/fd/0 //TEMP.CBT854.ZIP ISPF DSLIST Information tells me: Data Set Information Data Set Name . . . . : user.TEMP.CBT854.ZIP General Data Current Allocation Management class . . : **None**Allocated blocks . : 240 Storage class . . . : **None**Allocated extents . : 2 Volume serial . . . : 00 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : VB Used blocks . . . . : 211 Record length . . . : 1028Used extents . . . : 2 Block size . . . . : 27998 1st extent blocks . : 120 Secondary blocks . : 300Dates Data set name type : Creation date . . . : 2014/08/29 SMS Compressible. . : NO Referenced date . . : 2014/08/29 Expiration date . . : ***None*** OK. I understand the 27998. That's SDB doing what it should. Where does the 120 come from? Where does the 240 come from? How is the 1 I coded reflected in the Info display? Did the C RTL second guess me? Is this the 3390-pretending-to-be-a-3380? Does Info show that if so? Are the Primary, Secondary, Allocated, and Used in units of 1 or 27998 or other? How can I tell? I can never get my head around this stuff. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a CPU cost to using key9 storage while running with key8
What hardware are you on? I ask because a z196 has some high CPU costs for certain PSW Key- related instructions. For example, SPKA (Set PSW Key from Address) on a z196 shows up in CICS CPU figures because it stalls the pipeline when changing PSW keys between key 8 and key 9 -- or even when it doesn't change keys e.g. it is just 'going' from key 8 to key 8! SPKA may be executed in CICS more than you think (consider User Exits -- GLUEs and TRUEs -- some of which may have been inserted by your monitoring software). Older (z10) and newer (zEC12) hardware does not have this SPKA problem. https://listserv.ua.edu/cgi-bin/wa?A2=ind1211L=IBM-MAINP=R24496I=-3X=-Y=d10jhm1%40us.ibm.comd=No+Match%3BMatch%3BMatches Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Understanding Data Set Information?
This looks like it might be buried in your ALLOCXX member in SYS1.PARMLIB. If you have no MGT Class or Storage Class, then your ACS routines probably did not do anything to the file. To find your ACS routines, you need to access the ISPF Application called ISMF and go to Option 7 or 8, I forget which one. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, August 29, 2014 4:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Understanding Data Set Information? On Fri, 29 Aug 2014 18:04:59 -0500, Ed Gould wrote: Look at your ACS routines. How do I find those? Management class . . : **None**Allocated blocks . : 240 Storage class . . . : **None**Allocated extents . : 2 Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Understanding Data Set Information?
The other area to check out is your ISPF Configuration information. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, August 29, 2014 4:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Understanding Data Set Information? This looks like it might be buried in your ALLOCXX member in SYS1.PARMLIB. If you have no MGT Class or Storage Class, then your ACS routines probably did not do anything to the file. To find your ACS routines, you need to access the ISPF Application called ISMF and go to Option 7 or 8, I forget which one. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, August 29, 2014 4:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Understanding Data Set Information? On Fri, 29 Aug 2014 18:04:59 -0500, Ed Gould wrote: Look at your ACS routines. How do I find those? Management class . . : **None**Allocated blocks . : 240 Storage class . . . : **None**Allocated extents . : 2 Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Understanding Data Set Information?
On Fri, 29 Aug 2014 16:48:31 -0700, Lizette Koehler wrote: The other area to check out is your ISPF Configuration information. I used ISPF only to inspect the data set attributes after the job(s) ran. Is ISPF able somehow to reach back in time and affect the result of a job that ran earlier? Or is the displayed result somehow fictitious, depending on ISPF configuration? (Well, OK. ISPF was active at the moment the job(s) ran. Might I expect different results if I were to exit ISPF and TSO before submitting the job(s)/command(s) so they have no chance to molest?) -Original Message- From: Lizette Koehler Sent: Friday, August 29, 2014 4:46 PM This looks like it might be buried in your ALLOCXX member in SYS1.PARMLIB. If you have no MGT Class or Storage Class, then your ACS routines probably did not do anything to the file. To find your ACS routines, you need to access the ISPF Application called ISMF and go to Option 7 or 8, I forget which one. Lizette -Original Message- From: Paul Gilmartin Sent: Friday, August 29, 2014 4:25 PM On Fri, 29 Aug 2014 18:04:59 -0500, Ed Gould wrote: Look at your ACS routines. How do I find those? Management class . . : **None**Allocated blocks . : 240 Storage class . . . : **None**Allocated extents . : 2 Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Understanding Data Set Information?
1/2 track blocking factor, so 2 blocks per track in actual usage. 1 cyl = 15 tracks or 30 blocks, so allocation units are in cylinders. 240 blocks is 120 tracks is 8 cylinders, so looks like it did a release. Blksize of 1-22 bytes occurs 86 per track. 10,000 / 86 = 116.27 tracks, rounded up to cylinder boundary of 120 track. 300 blocks secondary is 4 tracks rounded up to 1 cylinder. http://bitsavers.trailing-edge.com/pdf/ibm/dasd/reference_summary/GX26-4577-0_3390_Reference_Summary_Jun89.pdf On Fri, Aug 29, 2014 at 5:47 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: My command was (after deleting the output data set): _UNIX03=NO cp -B -P'SPACE=(1,(0,300)),BLKSIZE=0' /dev/fd/0 //TEMP.CBT854.ZIP ISPF DSLIST Information tells me: Data Set Information Data Set Name . . . . : user.TEMP.CBT854.ZIP General Data Current Allocation Management class . . : **None**Allocated blocks . : 240 Storage class . . . : **None**Allocated extents . : 2 Volume serial . . . : 00 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : VB Used blocks . . . . : 211 Record length . . . : 1028Used extents . . . : 2 Block size . . . . : 27998 1st extent blocks . : 120 Secondary blocks . : 300Dates Data set name type : Creation date . . . : 2014/08/29 SMS Compressible. . : NO Referenced date . . : 2014/08/29 Expiration date . . : ***None*** OK. I understand the 27998. That's SDB doing what it should. Where does the 120 come from? Where does the 240 come from? How is the 1 I coded reflected in the Info display? Did the C RTL second guess me? Is this the 3390-pretending-to-be-a-3380? Does Info show that if so? Are the Primary, Secondary, Allocated, and Used in units of 1 or 27998 or other? How can I tell? I can never get my head around this stuff. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Understanding Data Set Information?
On Fri, 29 Aug 2014 22:18:46 -0500, Bill Godfrey bgodfrey...@gmail.com wrote: On Fri, 29 Aug 2014 17:47:03 -0500, Paul Gilmartin wrote: My command was (after deleting the output data set): _UNIX03=NO cp -B -P'SPACE=(1,(0,300)),BLKSIZE=0' /dev/fd/0 //TEMP.CBT854.ZIP ISPF DSLIST Information tells me: Data Set Information Data Set Name . . . . : user.TEMP.CBT854.ZIP General Data Current Allocation Management class . . : **None**Allocated blocks . : 240 Storage class . . . : **None**Allocated extents . : 2 Volume serial . . . : 00 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : VB Used blocks . . . . : 211 Record length . . . : 1028Used extents . . . : 2 Block size . . . . : 27998 1st extent blocks . : 120 Secondary blocks . : 300Dates Data set name type : Creation date . . . : 2014/08/29 SMS Compressible. . : NO Referenced date . . : 2014/08/29 Expiration date . . : ***None*** OK. I understand the 27998. That's SDB doing what it should. Where does the 120 come from? Where does the 240 come from? How is the 1 I coded reflected in the Info display? Did the C RTL second guess me? Is this the 3390-pretending-to-be-a-3380? Does Info show that if so? Are the Primary, Secondary, Allocated, and Used in units of 1 or 27998 or other? How can I tell? I can never get my head around this stuff. 1st extent blocks, allocated blocks, and used blocks are all in units of 27998. Secondary blocks are in units of 1. This value is kept in the DS1SCXTV field of the Format 1 DSCB, but is not shown by ISPF. The LISTDS command with the LABEL keyword will show the DSCB in hex, and the last 4 hex digits of the 14-digit value (there is only one that is 14 digits long) would be hex 2710 for 1, preceded by a hex 80. You requested space for 300 blocks of size 1 bytes. Self-correction: actually you requested space for 0 blocks, but when data was written it used the secondary allocation of 300 blocks to create the first extent. A track holds 5 blocks of size 1, so you got 300/5 or 60 tracks as your first extent. ISPF DSLIST computed 1st extent blocks as the number of 27998-byte blocks in the first extent. At 2 blocks per track, that is 120 blocks. More than 120 blocks were written, and a second extent was created, so Allocated blocks is 240 and Used blocks is 211. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Question regarding sharing of CF
Hello, Is it possible to share a CF (CF LPAR) between two different sysplex (the structure names will of course be different for the sysplex-es)? In other words, if there are two CFs - CFA CFB, and two sysplex - PLEXY and PLEXZ, can PLEXY and PLEXZ access different structures defined in CFA and CFB simultaneously ? e.g JES2 primary and duplex checkpoint structures - Primary for PLEXY in CFA, Duplex for PLEXY in CFB Primary for PLEXZ in CFB, Duplex for PLEXZ in CFA And is sharing of CFs among sysplex (or monoplex) , a good practice to follow? Thanks you! P.Mukhopadhyay -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Understanding Data Set Information?
The ACS routines once existed in source somewhere. When they are compiled into an SCDS the DSN and member names are saved in the SCDS also. However, nothing prevents them from being modified after compilation. (This is no different than any other source library. It is a management responsibility, not the compiler's, to insure that a copy of the source corresponding to the current object module is available for reference and future modification.) If your sysprog is doing his job, he can tell you where the current source modules are or give you a copy. Since your dataset is not SMS managed, only the DATACLAS routine has significance. Once you know which data class was assigned, you will need to get the attributes specified by that class (probably also from your sysprog). If you have the proper authority, you can acquire this information for yourself from ISMF. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, August 29, 2014 4:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Understanding Data Set Information? On Fri, 29 Aug 2014 18:04:59 -0500, Ed Gould wrote: Look at your ACS routines. How do I find those? Management class . . : **None**Allocated blocks . : 240 Storage class . . . : **None**Allocated extents . : 2 Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
