Re: z/OS 2.2 announcement
Just one problem with your implementation plan. Most sites I know would not want to recompile every COBOL program they run into a PDSE, then do a rename swap to implement. IEFOPZxx is great solution to this problem. You don't need to recompile them to store them in a PDSE. You can just reallocate a new PDSE, use IEBCOPY to copy them from the old PDS to the new PDSE. IEBCOPY will invoke the binder to relink them to the new format but the code remains unchanged. Then you can rename to new PDSE to replace the old PDS. No JCL changes needed. We just did that a few months ago on all our LPARs. - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.2 announcement
IEFOPZxx allows you to define pairs of libraries, where the paired library is concatenated ahead of the original. F'rinstance: //STEPLIB DD DISP=SHR,DSN=GOODOLD.COBOLPDS.LOADLIB In IEFOPZxx, we define DUMBNEW.COBOL5.PDSELOAD as a pair to GOODOLD.COBOLPDS.LOADLIB. So whenever the system sees GOODOLD in a STEPLIB or JOBLIB, allocation will automagically concatenate DUMBNEW ahead of it, and VIOLA! Conversion to COBOL 5 PDSE's, without changing the STEPLIB in thousands of jobs. No need to recompile everything at once, you can phase in the new compiler. This also works great for new ARCH levels, so if you have multiple CEC's, you can upgrade each CEC to the new ARCH level, again without recompiling everything. There are other uses, but if I told you, I'd have to kill you. Sounds like an excellent opportunity to thoroughly confuse developers, testers and probably every else in the IT department: I applied the change to this program, but the tests just won't reflect the change. I checked the JCL again and again but don't understand why it isn't working..? Or: We changed the program and scanned all the JCL to find every job that allocates the library the program is on and we changed those jobs too so we are confident we can bring this to production now. I'm not sure I would recommend using this feature to anyone or in any situation that isn't already desperate. Fred! - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.2 announcement
This was discussed at the vendor TDM but I think I am not talking out of school here now that this is announced ... One obstacle to customers converting to COBOL 5 is the requirement that the resulting executable programs reside in a PDSE. The customer presumably has thousands of jobs that say //STEPLIB DD DSN=OLD.PDS and no manpower to change them all. This would let them catalog COBOL 5 programs in NEW.PDSE and have it be automagically searched first whenever the JCL said DSN=OLD.PDS. AFAIR ... Charles Why would that require JCL changes? You could just replace OLD.PDS by a PDSE. I will admit that 'OLD.PDS' is a silly name for a PDSE but adding a .PDS suffix to a PDS seems silly to begin with. But is is an easy fix. Fred! - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Central Florida z/OS people
Just Principles of Operations I think... :) Sent from my new iPad On May 19, 2015, at 19:22, Ed Finnell 000248cce9f3-dmarc-requ...@listserv.ua.edu wrote: But a principal should have principles? In a message dated 5/19/2015 7:48:51 P.M. Central Daylight Time, t...@vse2pdf.com writes: spelling skills, otherwise I would be living on the streets. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Primary allocation of a dataset
I want to retrieve the primary allocation of a dataset. Sofar I've used OBTAIN to retrieve the DCSBs for the dataset. The DSCB1 contains information about the secondary allocation size for the dataset but does not contain any information about the primary allocation. If the dataset had a primary allocation in tracks or cylinders I can retrieve the necessary information from the extent information in the DSCB1: the first extent can be converted back to tracks or cylinders and that should be the primary allocation. But how can one recreate the primary allocation if some other form was used, for instance an amount in blocks, records or KB or something like that? Is this documented anywhere? Fred! - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Primary allocation of a dataset
You will never be able to determine the original primary allocation amount, because it is not recorded. When the primary allocation is done, it can be done in one or more extents and adjacent secondary extents can be merged together into 1 extent. Furthermore after close of the dataset, idle space can be released. From that moment on, all what is left is the status of the dataset at that moment, which is the result of any or all of the above actions, but you cannot determine the requested primary allocation from it. The strange part is that TSO 3.2 option seems to be able to recreate this info. If I allocate a dataset with a recordlength and blocksize of 100 bytes, a primary allocation of 14 KB and a secondary allocation of 2KB it is reported as: 1st extent kilobytes: 14 Secondary kilobytes : 2 Current Allocation Allocated kilobytes : 14 Allocated extents . : 1 The DSCBs in the VTOC contains a secondary allocation of 2K and an allocation in one extent of 2 tracks. Where did 3.2 find my primary allocation of 14K? Fred! - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Primary allocation of a dataset
When you allocatie a dataset you specify space (blocks, tracks cylinders, MB or whatever) and a primary and secondary amount. The space and secondary amount is preserved in The DSCB1/8. The space was also used to allocate the primary extent(s). It is just the primary amount (as specified in the allocation command) that does not seem to be available anymore. Fred! Sent from my new iPad On May 6, 2015, at 22:19, Tony Harminc t...@harminc.net wrote: On 6 May 2015 at 15:07, John Eells ee...@us.ibm.com wrote: I never actually checked, but I assume that ISPF and other things that show used space in allocation request units other than tracks or cylinders use the DS1DSPAC fields and track length to calculate space in those original request units. But how does it know what those original units were? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
