Re: VLF caching
-can I use VLF trimming statistics as a good measure to determine if my CSVLLA cache is large enough? -If not, what measure does tell me this, besides the LLAFETCH/PGMFETCH measures I get from CSVLLIX1/2? Provided by the VLF owner: Since LLA expects VLF to trim as needed to make room for new caching candidates over time, trimming itself is not a bad thing. What -is- bad is trimming 'too soon' so that you do not get as much benefit from caching a program object (module) as you otherwise might. As of z/OS 2.1, you can use the verbose output of the VLF Health Check to see the youngest age of a trimmed object (since the VLF class was activated), and the current minimum trimmed age of objects (since the check last ran) for the CSVLLA class. The output also shows the current MaxVirt value. You also can set an alert for a minimum age, so that the check will raise an exception if objects are being trimmed sooner than you would like (the default is 60 seconds - sufficient to tell whether there is a potentially serious issue). And you can dynamically change the size of the cache via the MODIFY VLF,REPLACE,NN=xx command by supplying a parmlib member with a new MaxVirt (and possibly AlertAge) parm for the CSVLLA class. I can not say whether there is some trimming statistic that would also be useful for older releases, but I doubt it. And the modify to change the size of the cache is available only as of z/OS 2.1 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: VLF caching
Peter, Thanks, this is valuable information how to manage the CSVLLA cache size. When we go to 2.1 next year I will use it, probably eliminating CSVLLIX1/2. Is this / will this be documented somewhere with LLA and/or VLF? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: 02 December, 2014 13:55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VLF caching -can I use VLF trimming statistics as a good measure to determine if my CSVLLA cache is large enough? -If not, what measure does tell me this, besides the LLAFETCH/PGMFETCH measures I get from CSVLLIX1/2? Provided by the VLF owner: Since LLA expects VLF to trim as needed to make room for new caching candidates over time, trimming itself is not a bad thing. What -is- bad is trimming 'too soon' so that you do not get as much benefit from caching a program object (module) as you otherwise might. As of z/OS 2.1, you can use the verbose output of the VLF Health Check to see the youngest age of a trimmed object (since the VLF class was activated), and the current minimum trimmed age of objects (since the check last ran) for the CSVLLA class. The output also shows the current MaxVirt value. You also can set an alert for a minimum age, so that the check will raise an exception if objects are being trimmed sooner than you would like (the default is 60 seconds - sufficient to tell whether there is a potentially serious issue). And you can dynamically change the size of the cache via the MODIFY VLF,REPLACE,NN=xx command by supplying a parmlib member with a new MaxVirt (and possibly AlertAge) parm for the CSVLLA class. I can not say whether there is some trimming statistic that would also be useful for older releases, but I doubt it. And the modify to change the size of the cache is available only as of z/OS 2.1 Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For 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: SMP/E and IDR (was: Binder SETSSI ...?)
OTOH, we're already digesting SYSLIN to generate CSECT parameters for SMP/E ++MOD MCS. It would be quite natural to append Binder IDENTIFY commands at that point. But I believe SMP/E doesn't recognize Binder commands appearing in SYSLIN. Huh? I assume you're talking about the SYSLIN for a link edit step in JCLIN. SMP/E recognizes some binder control statements, and some it does not. INCLUDE, NAME, CHANGE, REPLACE, and ALIAS are recognized and processed very specifically. Any other control statements found in the JCLIN, including IDENTIFY, are not recognized by SMP/E, but rather are simply saved and passed somewhat blindly to the binder when the load module (or program object) is linked. Passing IDENTIFY blindly to the binder would likely give you incorrect results, because as I think someone already mentioned, IDENTIFY must follow the module it is associated with, and SMP/E does not preserve this association for IDENTIFY. If you want to use IDENTIFY, you should append it to the module object deck described by ++MOD. This is how IBM does it for many (all?) of its PTFS. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU UNZIP space issue.
Well, you'll have to make space on TESTG storage group. This might be accomplished by either cleaning up (deleting) unused datasets or by adding more volumes to that storage group. It says that OMVS.SYS5.RSU.SLE is 88% full. Is that before or after running the unpax job? Maybe you could delete unused files from that filesystem to make room inside it, then you wouldn't have to allocate a new filesystem. Regards, --- *Lucas Rosalen* rosalen.lu...@gmail.com +55 19 9-8146-7633 2014-12-02 8:49 GMT-02:00 Mainframe Mainframe mainframe1...@gmail.com: Hello Group, I am in the process of applying RSU1410 but while unzipping it I am facing space issue . /bin/pax -zvrf /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z ./GIMFAF.XML ./GIMFAF.XML --- DATE 11/19/14 TIME 22:19:47 SMP/E 36.13 UNIX COMMAND OUTPUT /bin/pax -zvrf /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z ./GIMFAF.XML ./SMPPTFIN pax: FSUM6260 write error on file ./SMPPTFIN: EDC5133I No space left on device GIM68200E ** PROCESSING FAILED FOR THE /bin/pax UNIX SYSTEM SERVICE COMMAND. GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z. GIM20501IGIMUNZIP PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMP1) FILENAME IS (/u/SLE/RSU1410/temp/smpe2014323221642624191/GIMFAF.XML) IEF142I UNZIPRSU UNZIP - STEP WAS EXECUTED - COND CODE 0012 --- # df -Pk /u/SLE/RSU1410/ Filesystem 1024-blocksUsed Available Capacity Mounted on OMVS.SYS5.RSU.SLE 3072048 2696780 375152 88% /u/SLE/RSU1410 # exit As RSU size is really big, So I am trying to allocate bigger space of HFS dataset with 4000MB and multi volume and which i will be mounting at /u/SLE/RSU1410//temp but I am getting below issue. I think we have space constraint of allocating these dataset. IKJ56893I DATA SET OMVS.SYS5.RSU.TEMP NOT ALLOCATED+ IGD17281I ALLOCATION FOR DATA SET OMVS.SYS5.RSU.TEMP FAILED, VOLUME (ABL056) WAS EXPLICITLY SPECIFIED FOR A GUARANTEED SPACE REQUEST BUT WAS REJECTED IGD17273I ALLOCATION HAS FAILED FOR ALL VOLUMES SELECTED FOR DATA SET OMVS.SYS5.RSU.TEMP IGD17277I THERE ARE (8) CANDIDATE VOLUMES OF WHICH (8) ARE ENABLED OR QUIESCED IGD17290I THERE WERE 1 CANDIDATE STORAGE GROUPS OF WHICH THE FIRST 1 WERE ELIGIBLE FOR VOLUME SELECTION. THE CANDIDATE STORAGE GROUPS WERE:TESTG IGD17279I 6 VOLUMES WERE REJECTED BECAUSE THEY WERE NOT ON THE INCLUDE LIST IGD17279I 1 VOLUMES WERE REJECTED BECAUSE OF A DADSM FAILURE (044E0097) *** Can anybody help me to come out of this issue. -- 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: RSU UNZIP space issue.
Any messages in SYSLOG like IGD, IOE, IEC or other at the time of this issue? Application that quickly creates many small files and then deletes them in a small zfs aggregate, eventually begins receiving EDC5133I No space left on device. The ls -al output shows NO files in the filesystem, however, a df -vKp shows the filesystem is full. Further info obtained by issuing F ZFS,AGGRINFO aggregatename verifies the filesystem INODE table is full. This condition persists until the filesystem is unmounted and remounted. It may not be your primary zFS file but the workPath folder, check using the df command. 4000MB may not be enough. You will need a /tmp file that is roughly the same size as the HFS you used to download your serverpac. When I downloaded my 1.8 serverpac, I allocated a zFS twice the size of the order size, and pointed the work directory back to that mountpoint, rather than taking the /tmp default. Depending on which system you are running this on, filling up /tmp may cause you a little heartburn. This process is not easy to diagnose. Sometimes the out of space is not the one you suspect it is. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Mainframe Sent: Tuesday, December 02, 2014 3:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RSU UNZIP space issue. Hello Group, I am in the process of applying RSU1410 but while unzipping it I am facing space issue . /bin/pax -zvrf /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z ./GIMFAF.XML ./GIMFAF.XML --- DATE 11/19/14 TIME 22:19:47 SMP/E 36.13 UNIX COMMAND OUTPUT /bin/pax -zvrf /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z ./GIMFAF.XML ./SMPPTFIN pax: FSUM6260 write error on file ./SMPPTFIN: EDC5133I No space left on device GIM68200E ** PROCESSING FAILED FOR THE /bin/pax UNIX SYSTEM SERVICE COMMAND. GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z. GIM20501IGIMUNZIP PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMP1) FILENAME IS (/u/SLE/RSU1410/temp/smpe2014323221642624191/GIMFAF.XML) IEF142I UNZIPRSU UNZIP - STEP WAS EXECUTED - COND CODE 0012 --- # df -Pk /u/SLE/RSU1410/ Filesystem 1024-blocksUsed Available Capacity Mounted on OMVS.SYS5.RSU.SLE 3072048 2696780 375152 88% /u/SLE/RSU1410 # exit As RSU size is really big, So I am trying to allocate bigger space of HFS dataset with 4000MB and multi volume and which i will be mounting at /u/SLE/RSU1410//temp but I am getting below issue. I think we have space constraint of allocating these dataset. IKJ56893I DATA SET OMVS.SYS5.RSU.TEMP NOT ALLOCATED+ IGD17281I ALLOCATION FOR DATA SET OMVS.SYS5.RSU.TEMP FAILED, VOLUME (ABL056) WAS EXPLICITLY SPECIFIED FOR A GUARANTEED SPACE REQUEST BUT WAS REJECTED IGD17273I ALLOCATION HAS FAILED FOR ALL VOLUMES SELECTED FOR DATA SET OMVS.SYS5.RSU.TEMP IGD17277I THERE ARE (8) CANDIDATE VOLUMES OF WHICH (8) ARE ENABLED OR QUIESCED IGD17290I THERE WERE 1 CANDIDATE STORAGE GROUPS OF WHICH THE FIRST 1 WERE ELIGIBLE FOR VOLUME SELECTION. THE CANDIDATE STORAGE GROUPS WERE:TESTG IGD17279I 6 VOLUMES WERE REJECTED BECAUSE THEY WERE NOT ON THE INCLUDE LIST IGD17279I 1 VOLUMES WERE REJECTED BECAUSE OF A DADSM FAILURE (044E0097) *** Can anybody help me to come out of this issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU UNZIP space issue.
Hi Lucus, The dadsm error DADSM FAILURE (044E0097) means requested space exceeds 65535 tracks for a data set type that is limited to 65535 tracks per volume. I would work with the person or group that handles SMS to get the proper allocation request. Doug On Tue, 2 Dec 2014 12:21:14 -0200, Lucas Rosalen rosalen.lu...@gmail.com wrote: Well, you'll have to make space on TESTG storage group. This might be accomplished by either cleaning up (deleting) unused datasets or by adding more volumes to that storage group. It says that OMVS.SYS5.RSU.SLE is 88% full. Is that before or after running the unpax job? Maybe you could delete unused files from that filesystem to make room inside it, then you wouldn't have to allocate a new filesystem. Regards, --- *Lucas Rosalen* rosalen.lu...@gmail.com +55 19 9-8146-7633 2014-12-02 8:49 GMT-02:00 Mainframe Mainframe mainframe1...@gmail.com: Hello Group, I am in the process of applying RSU1410 but while unzipping it I am facing space issue . /bin/pax -zvrf /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z ./GIMFAF.XML ./GIMFAF.XML --- DATE 11/19/14 TIME 22:19:47 SMP/E 36.13 UNIX COMMAND OUTPUT /bin/pax -zvrf /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z ./GIMFAF.XML ./SMPPTFIN pax: FSUM6260 write error on file ./SMPPTFIN: EDC5133I No space left on device GIM68200E ** PROCESSING FAILED FOR THE /bin/pax UNIX SYSTEM SERVICE COMMAND. GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z. GIM20501IGIMUNZIP PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMP1) FILENAME IS (/u/SLE/RSU1410/temp/smpe2014323221642624191/GIMFAF.XML) IEF142I UNZIPRSU UNZIP - STEP WAS EXECUTED - COND CODE 0012 --- # df -Pk /u/SLE/RSU1410/ Filesystem 1024-blocksUsed Available Capacity Mounted on OMVS.SYS5.RSU.SLE 3072048 2696780 375152 88% /u/SLE/RSU1410 # exit As RSU size is really big, So I am trying to allocate bigger space of HFS dataset with 4000MB and multi volume and which i will be mounting at /u/SLE/RSU1410//temp but I am getting below issue. I think we have space constraint of allocating these dataset. IKJ56893I DATA SET OMVS.SYS5.RSU.TEMP NOT ALLOCATED+ IGD17281I ALLOCATION FOR DATA SET OMVS.SYS5.RSU.TEMP FAILED, VOLUME (ABL056) WAS EXPLICITLY SPECIFIED FOR A GUARANTEED SPACE REQUEST BUT WAS REJECTED IGD17273I ALLOCATION HAS FAILED FOR ALL VOLUMES SELECTED FOR DATA SET OMVS.SYS5.RSU.TEMP IGD17277I THERE ARE (8) CANDIDATE VOLUMES OF WHICH (8) ARE ENABLED OR QUIESCED IGD17290I THERE WERE 1 CANDIDATE STORAGE GROUPS OF WHICH THE FIRST 1 WERE ELIGIBLE FOR VOLUME SELECTION. THE CANDIDATE STORAGE GROUPS WERE:TESTG IGD17279I 6 VOLUMES WERE REJECTED BECAUSE THEY WERE NOT ON THE INCLUDE LIST IGD17279I 1 VOLUMES WERE REJECTED BECAUSE OF A DADSM FAILURE (044E0097) *** Can anybody help me to come out of this issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VLF caching
I liked the health check. If you have access to MXG, here is a sample of what I have used to manage VLF: /* // JCLLIB ORDER=ZELDEN.MXG.SOURCLIB //STEP010 EXEC MXGSAS,WORK='50,50' //*SMF DD DSN=ZELDEN.SMF41,DISP=SHR //SMF DD DSN=SMF.SYSA.DAILY(-0),DISP=SHR //SYSIN DD * OPTIONS SOURCE LS=132; %INCLUDE SOURCLIB(TYPE41); RUN; PROC SORT NODUP DATA=TYPE41VF OUT=T41; BY SYSTEM SMF41CLS SMFTIME; PROC PRINT LABEL SPLIT='*'; VAR SMFTIME SYSTEM SMF41LRG SMF41MVT SMF41USD SMF41ADD SMF41DEL SMF41TRM VLFHITPC; BY SYSTEM SMF41CLS; ID SMF41CLS; FORMAT SMFTIME DATETIME18.; TITLE 'VITUAL LOOKASIDE FACILITY'; TITLE2 'AS REDUCED FROM SMF TYPE41'; FOOTNOTE 'ZELDEN-(MXG41VLF)'; -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and IDR (was: Binder SETSSI ...?)
On Tue, 2 Dec 2014 09:13:56 -0500, Kurt Quackenbush wrote: OTOH, we're already digesting SYSLIN to generate CSECT parameters for SMP/E ++MOD MCS. It would be quite natural to append Binder IDENTIFY commands at that point. But I believe SMP/E doesn't recognize Binder commands appearing in SYSLIN. Huh? I assume you're talking about the SYSLIN for a link edit step in JCLIN. For my first use of SYSLIN I meant the DDNAME output from HLASM; I could/should have said SYSPUNCH. For the second, I meant, and should have said, ... Binder commands in instream MOD elements. ... SMP/E recognizes some binder control statements, and some it does not. INCLUDE, NAME, CHANGE, REPLACE, and ALIAS are recognized and processed very specifically. Any other control statements found in the JCLIN, including IDENTIFY, are not recognized by SMP/E, but rather are simply saved and passed somewhat blindly to the binder when the load module (or program object) is linked. Passing IDENTIFY blindly to the binder would likely give you incorrect results, because as I think someone already mentioned, IDENTIFY must follow the module it is associated with, and SMP/E does not preserve this association for IDENTIFY. It probably gets worse with RESTORE. If you want to use IDENTIFY, you should append it to the module object deck described by ++MOD. This is how IBM does it for many (all?) of its PTFS. I have known SMP/E to report errors on finding junk in inline ++MOD elements. But today, I can't force the error; junk lines are simply RECEIVEd intact into the SMPPTS. I see no evidence of them in the SYSPRINT from APPLY; my test lines should have caused errors. How would this work for ++MOD elements in RELFILE format. Should I supply the IDENTIFY as input to Binder when I link the ++MOD element so Binder will imbed it in the IDR? Same for ACCEPT into DLIB? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SyzMAIL/z new features
In 0765937696197027.wa.brianwestermansyzygyinc@listserv.ua.edu, on 12/01/2014 at 01:25 AM, Brian Westerman brian_wester...@syzygyinc.com said: I wondered how you might look at this request? Sending related SYSOUT seems reasonable, even if it takes a little more work, but sending arbitrary legacy or Unix files seems excessive. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU UNZIP space issue.
Thanks Doug, I really overlooked that error code. In this case, you could try allocating the OMVS dataset as multi-volume I guess. --- *Lucas Rosalen* rosalen.lu...@gmail.com / *lrosa...@br.ibm.com lrosa...@br.ibm.com* +55 19 9-8146-7633 2014-12-02 13:55 GMT-02:00 Doug Henry doug_he...@usbank.com: Hi Lucus, The dadsm error DADSM FAILURE (044E0097) means requested space exceeds 65535 tracks for a data set type that is limited to 65535 tracks per volume. I would work with the person or group that handles SMS to get the proper allocation request. Doug On Tue, 2 Dec 2014 12:21:14 -0200, Lucas Rosalen rosalen.lu...@gmail.com wrote: Well, you'll have to make space on TESTG storage group. This might be accomplished by either cleaning up (deleting) unused datasets or by adding more volumes to that storage group. It says that OMVS.SYS5.RSU.SLE is 88% full. Is that before or after running the unpax job? Maybe you could delete unused files from that filesystem to make room inside it, then you wouldn't have to allocate a new filesystem. Regards, --- *Lucas Rosalen* rosalen.lu...@gmail.com +55 19 9-8146-7633 2014-12-02 8:49 GMT-02:00 Mainframe Mainframe mainframe1...@gmail.com: Hello Group, I am in the process of applying RSU1410 but while unzipping it I am facing space issue . /bin/pax -zvrf /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z ./GIMFAF.XML ./GIMFAF.XML --- DATE 11/19/14 TIME 22:19:47 SMP/E 36.13 UNIX COMMAND OUTPUT /bin/pax -zvrf /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z ./GIMFAF.XML ./SMPPTFIN pax: FSUM6260 write error on file ./SMPPTFIN: EDC5133I No space left on device GIM68200E ** PROCESSING FAILED FOR THE /bin/pax UNIX SYSTEM SERVICE COMMAND. GIM47800S ** AN ERROR OCCURRED WHILE GIMUNZIP WAS PROCESSING ARCHIVE /u/SLE/RSU1410/SMPPTFIN/S0001.SHOPZ.S2654213.SMPMCS.pax.Z. GIM20501IGIMUNZIP PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. IGD104I HFS FILE WAS RETAINED, DDNAME IS (SMP1) FILENAME IS (/u/SLE/RSU1410/temp/smpe2014323221642624191/GIMFAF.XML) IEF142I UNZIPRSU UNZIP - STEP WAS EXECUTED - COND CODE 0012 --- # df -Pk /u/SLE/RSU1410/ Filesystem 1024-blocksUsed Available Capacity Mounted on OMVS.SYS5.RSU.SLE 3072048 2696780 375152 88% /u/SLE/RSU1410 # exit As RSU size is really big, So I am trying to allocate bigger space of HFS dataset with 4000MB and multi volume and which i will be mounting at /u/SLE/RSU1410//temp but I am getting below issue. I think we have space constraint of allocating these dataset. IKJ56893I DATA SET OMVS.SYS5.RSU.TEMP NOT ALLOCATED+ IGD17281I ALLOCATION FOR DATA SET OMVS.SYS5.RSU.TEMP FAILED, VOLUME (ABL056) WAS EXPLICITLY SPECIFIED FOR A GUARANTEED SPACE REQUEST BUT WAS REJECTED IGD17273I ALLOCATION HAS FAILED FOR ALL VOLUMES SELECTED FOR DATA SET OMVS.SYS5.RSU.TEMP IGD17277I THERE ARE (8) CANDIDATE VOLUMES OF WHICH (8) ARE ENABLED OR QUIESCED IGD17290I THERE WERE 1 CANDIDATE STORAGE GROUPS OF WHICH THE FIRST 1 WERE ELIGIBLE FOR VOLUME SELECTION. THE CANDIDATE STORAGE GROUPS WERE:TESTG IGD17279I 6 VOLUMES WERE REJECTED BECAUSE THEY WERE NOT ON THE INCLUDE LIST IGD17279I 1 VOLUMES WERE REJECTED BECAUSE OF A DADSM FAILURE (044E0097) *** Can anybody help me to come out of this issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Check out These Cool Robots Are Processing Your Amazon Orders | TechCrunch
_These Cool Robots Are Processing Your Amazon Orders | TechCrunch_ (http://techcrunch.com/2014/12/01/these-cool-robots-are-processing-your-amazon-order s/) Wonder how much horsepower is driving the data? Still fascinating -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Check out The Imitation Game - Wikipedia, the free encyclopedia
_The Imitation Game - Wikipedia, the free encyclopedia_ (http://en.wikipedia.org/wiki/The_Imitation_Game) Something for the holidays... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VLF caching
On 12/02/2014 11:00 AM, Mark Zelden wrote: I liked the health check. If you have access to MXG, here is a sample of what I have used to manage VLF: SNIPPAGE Thanks. I ran a quick test of this. I likes it. It gave me some ideas... Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out These Cool Robots Are Processing Your Amazon Orders | TechCrunch
and they arent doing a very good job;) http://www.reveal.co.uk/real-life-stories/news/a613837/student-receives-over-gbp3k-of-gifts-from-amazon-thanks-to-tech-glitch.html On 2 December 2014 at 20:43, Ed Finnell 000248cce9f3-dmarc-requ...@listserv.ua.edu wrote: _These Cool Robots Are Processing Your Amazon Orders | TechCrunch_ ( http://techcrunch.com/2014/12/01/these-cool-robots-are-processing-your-amazon-order s/) Wonder how much horsepower is driving the data? Still fascinating -- 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
Migrate CTC ESCON channels to CTC FICON channels
Hi all We are migrating CTC ESCON channels to CTC FICON channels. We want to use HCD Option 2.10 to build I/O configurations ,then we change some parameters to migrate CTC from ESCON to FICON. Could you share your any experience to do it ? Thanks a lot! Best Regards, Jason Cai -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SyzMAIL/z new features
I want to thank all of you who responded to me on the list and via private email. I compiled the suggestions and we had a strategy meeting today to discuss it. The results were that we will provide any one (or all) of the JES system datasets, or the entire job, but not specific user SYSOUT datasets within the job. Sending the individual USER sysout, MVS datasets (sequential, PDS, VSAM, etc.) and Unix files will instead be added as a feature of SyzCMD/z (the command scripting product). Again, I really do want to thank those of you who responded for the assistance, I actually used a lot of what was said verbatim, because it was describe much more eloquently than I could have. Thanks, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out The Imitation Game - Wikipedia, the free encyclopedia
Ed Finnell wrote: _The Imitation Game - Wikipedia, the free encyclopedia_ (http://en.wikipedia.org/wiki/The_Imitation_Game) Pity that Turing commited suicide at age of 41... Radoslaw Skorupka wrote: Check the hackers of Enigma: http://en.wikipedia.org/wiki/Enigma_machine This success was a result of efforts by three Polish cryptologists, Marian Rejewski, Jerzy Różycki and Henryk Zygalski, working for Polish military intelligence. Rejewski reverse-engineered the device, using theoretical mathematics and material supplied by French military intelligence. Subsequently the three mathematicians designed mechanical devices for breaking Enigma ciphers, including the cryptologic bomb. Interesting. If you have lots of free time - there are online Enigma emulators available. Just check above URL. 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
Re: Check out These Cool Robots Are Processing Your Amazon Orders | TechCrunch
Ed Finnell wrote: _These Cool Robots Are Processing Your Amazon Orders | TechCrunch_ (http://techcrunch.com/2014/12/01/these-cool-robots-are-processing-your-amazon-orders/) Those fast warehouse critters have route analyzers, avoidance technology, etc to do running around without any collisions at all. Just look at YouTube for some videos about those workhorses. Wonder how much horsepower is driving the data? Still fascinating I don't now, but they will charge themselves when running out of juice. After charging they resume their work. Now I want one of these to bring me hot coffee or ice cold beer. ;-) 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
