Re: Where environment variables set for batch POSIX programs?
don't know, if this helps, but we set environment variables in CEEOPTS in batch jobs, for example //CEEOPTS DD * STACK(30M,10M), ENVAR(_CEE_HEAP_MANAGER=CEL4MCHK, _CEE_MEMCHECK_DEPTH=10, ...) the alternate Heap-Manager and its env variables meant just as an example; at the position of the 3 dots you can continue to specify more. Kind regards Bernd Am 06.09.2013 03:09, schrieb Charles Mills: This question is related to my question on timezone_name. I am responsible for a C++ program that runs POSIX(ON) as a started task in conventional MVS. I observe that at some customers the environment variable TZ (time zone) is set correctly, and that at others it is not set at all. I search the USS documentation and all I find is information about setting the environment variables if you are a shell user. For the customers that do not have TZ correctly set (for MVS started tasks), what do I tell them to do? You need to set the TZ environment variable by customizing as documented in _? Thanks, Charles -- 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: Where environment variables set for batch POSIX programs?
Am 06.09.2013 10:45, schrieb Bernd Oppolzer: don't know, if this helps, but we set environment variables in CEEOPTS in batch jobs, for example //CEEOPTS DD * STACK(30M,10M), ENVAR(_CEE_HEAP_MANAGER=CEL4MCHK, _CEE_MEMCHECK_DEPTH=10, ...) the alternate Heap-Manager and its env variables meant just as an example; at the position of the 3 dots you can continue to specify more. Kind regards Bernd I guess this is for an individual setting per job; for a global setting you should use PARMLIB, as suggested in another post. I don't know the details there. CEEOPTS will override the PARMLIB settings (and CEEOPTS is more comfortable than using the first part of the PARM string, in fact, the length of the parm is limited, so this will not work). Kind regards Bernd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where environment variables set for batch POSIX programs?
I think you can get the best to set: ENVAR(_CEE_ENVFILE_S=DD:ENVARS) and in the ENVARS DD define the actual ENVARS : TZ=MEZ-1MESZ-2,M3.5.0/02:00:00,M10.5.0/03:00:00 ISIS_KEY_TRACE=1 ISIS_PCS_LOGMODE=M*C ISIS_PCS_LOCAL_SHM=1 (here blank terminated, in the _CEE_ENVFILE it should be x'00' terminated ) On 06.09.2013 03:09, Charles Mills wrote: This question is related to my question on timezone_name. I am responsible for a C++ program that runs POSIX(ON) as a started task in conventional MVS. I observe that at some customers the environment variable TZ (time zone) is set correctly, and that at others it is not set at all. I search the USS documentation and all I find is information about setting the environment variables if you are a shell user. For the customers that do not have TZ correctly set (for MVS started tasks), what do I tell them to do? You need to set the TZ environment variable by customizing as documented in _? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFHSM ARCLOGx ARCLOGy must be on the same volume.
Hello, We recently 'switched' on the ARCLOGx and ARCLOGy functionality of DFHSM. All working perfectly well. However, apparently it is somewhat required to have both output datasets residing on the same volume. (else messages like ARC0022I may appear at swaplog-time). This is all documented well, however I do not understand why this requirement is there. Does anyone have an idea why DFHSM is unable to handle a rename when both output datasets do not reside on the same volume? Many thanks. -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
What version of Cobol are you running now? I would also look at the migration guides for z/OS V2.1 and COBOL For cobol:http://publibfp.boulder.ibm.com/epubs/pdf/c1473830.pdf For z/OS V2.1: http://www-03.ibm.com/systems/z/os/zos/bkserv/zos_migration_manuals.html Also, see if and when Marna Walle provides a migration presentation for v2.1. And there are many system libraries that are PDS/E datasets. JES2 has some, as well as other products. So you are running PDS/Es at this time. So long as you keep your PDS/E maint up to date, you should not have issues. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 2:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
It is your thread, and I have no wish to hijack it. This will therefore be my last post for it. I chose Australian local times advisedly. They illustrate the differences between Daylight|Summer|Official times and Standard ones in the northern and southern hemispheres. You mentioned that you needed to revise your 'parsing' of such strings as 'AMT4AMST', and I perhaps interpreted this too literally. If you are always handing off such strings to someone else, you need not take any responsibility for 'errors' in them. If you are going to try to make sense of them, then you need to understand such differing conventions as those embodied in MSK, Moscow Standard Time MSD, Moscow Daylight Time WET, Western European Time WEST, Western European Summer Time EST, Eastern Standard Time (United States) EDT, Eastern Daylight Time (United States) I have been down this road; and great care must, for example, be taken to disentangle the 'S' for Summer and the 'S' for Standard, assuming always that you are not delegating the responsibility for doing so to someone else. Good luck! -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dynamic Allocation in COBOL
This might not be the right forum for this question, but... Doing some very limited in initial research I've found three documented methods of performing Dynamic Allocation in COBOL ( Enterprise COBOL 4.2), BPXWDYN, CEEENV or setenv. Q1) Are there any others?We already use a home grown assembler program for dynamic allocation, but our direction is to move as much to the OS as possible. Q2) Is there any reason to pick one over the others? -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
With COBOL 5.1, AFAIK, comes also the requirement of the load libraries to be PDSE. Which we DON'T have today, neither in production or test systems. You have PDSEs on your Sysres. If you run DB2 you have PDSEs. PDSEs don't have to be SMS-managed. The only problem you may have is that PDSEs cannot be shared outside of a Sysplex. They cannot be shared across Sysplexes. Otherwise once you install COBOL the library should remain untouched and should be very stable. Bob Shannon Rocket Software -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
I'm curious about your statement: With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. If you mean the product code comes in PDSE's then that's no big deal. But if you are saying the output of the compiler has to be PDSE's, in other words, all application load libraries have to be PDSE's then I am concerned. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
A quick look in the ENT COB 5.1 migration guide does turn up this jewel... Binding (link-editing) Enterprise COBOL programs What is the difference between an object module, a load module, and a program object? An object module is the output of the compiler and input to the binder. A load module is a non-GOFF executable that is output from the binder with an Enterprise COBOL V4.2 object module. A program object is a new style GOOF executable that is the output from the binder when binding an object module from Enterprise COBOL V5.1. Are PDS and PDSE data sets allowed for object and load modules with Enterprise COBOL V5? Compiler output data sets can be PDS or PDSE, including the object module. The output of the bind step must be a PDSE. When COBOL object modules are linked (bound) they become program objects and must be stored in PDSE data sets. This is going to be a big undertaking for us. We have hundreds of application load libraries that are PDS, NOT PDSE. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. I'm curious about your statement: With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. If you mean the product code comes in PDSE's then that's no big deal. But if you are saying the output of the compiler has to be PDSE's, in other words, all application load libraries have to be PDSE's then I am concerned. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.commailto:david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Don't know for COBOL, but we have some experience with PL/1 here, and as long as you don't use some of the fancier new options like RENT, DLL etc., you don't need your output libraries to be PDSEs, because the resulting load objects don't have the properties that need them to be GOFFs or program objects type 3 (PO3) - I guess, that's the difference. The Binder, AFAIK, does output into normal PDS libraries as well. But it will refuse to do so if the load objects need to be PO3 or GOFF. So I guess you have to check if you need the new options or if you can live without them. At our site, for example, we decided to stay with NORENT - our modules are all naturally reentrant - and we build classical load modules (which are limited to 16 MB in size, BTW), and so we still use normal PDS libraries. But there is a neighbor site in the same company, where all is PDSE - because of compiler options DLL and RENT. Kind regards Bernd Am 06.09.2013 14:01, schrieb Jousma, David: A quick look in the ENT COB 5.1 migration guide does turn up this jewel... Binding (link-editing) Enterprise COBOL programs What is the difference between an object module, a load module, and a program object? An object module is the output of the compiler and input to the binder. A load module is a non-GOFF executable that is output from the binder with an Enterprise COBOL V4.2 object module. A program object is a new style GOOF executable that is the output from the binder when binding an object module from Enterprise COBOL V5.1. Are PDS and PDSE data sets allowed for object and load modules with Enterprise COBOL V5? Compiler output data sets can be PDS or PDSE, including the object module. The output of the bind step must be a PDSE. When COBOL object modules are linked (bound) they become program objects and must be stored in PDSE data sets. This is going to be a big undertaking for us. We have hundreds of application load libraries that are PDS, NOT PDSE. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Dave, I think this redbook may help http://www.redbooks.ibm.com/redbooks/pdfs/sg246106.pdf The binder supports a modified extended object module, produced by the C and C++ compilers, and an entirely new object module format, called GOFF. This new object module type is described in 7.2.5, GOFF If I am reading this correctly, the BINDER would need to use a PDSE output file if there is JAVA, C/C++ type of programs. If you have native cobol, then you might be able to continue the LKED with BINDER to a non PDSE. So any process currently using BINDER for JAVA or C/C++ would most likely already be using a PDSE for the program object output. It might be possible that IBM did not document that section clearly enough (big surprise ) That is just a guess. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 5:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. A quick look in the ENT COB 5.1 migration guide does turn up this jewel... Binding (link-editing) Enterprise COBOL programs What is the difference between an object module, a load module, and a program object? An object module is the output of the compiler and input to the binder. A load module is a non-GOFF executable that is output from the binder with an Enterprise COBOL V4.2 object module. A program object is a new style GOOF executable that is the output from the binder when binding an object module from Enterprise COBOL V5.1. Are PDS and PDSE data sets allowed for object and load modules with Enterprise COBOL V5? Compiler output data sets can be PDS or PDSE, including the object module. The output of the bind step must be a PDSE. When COBOL object modules are linked (bound) they become program objects and must be stored in PDSE data sets. This is going to be a big undertaking for us. We have hundreds of application load libraries that are PDS, NOT PDSE. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. I'm curious about your statement: With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. If you mean the product code comes in PDSE's then that's no big deal. But if you are saying the output of the compiler has to be PDSE's, in other words, all application load libraries have to be PDSE's then I am concerned. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.commailto:david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s)
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
I should have also included this section GOFF stands for Generalized Object File Format . It is an enhanced type of object module introduced by the binder in DFSMS/MVS 1.3 and produced by the High Level Assembler, COBOL, and C++. GOFF supports long names and multipart modules, and provides some other new features. These object modules can be stored as sequential files, as members of PDS or PDSE libraries, or as z/OS UNIX file system files. So unless the new stuff is used, you may be okay Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, September 06, 2013 5:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Dave, I think this redbook may help http://www.redbooks.ibm.com/redbooks/pdfs/sg246106.pdf The binder supports a modified extended object module, produced by the C and C++ compilers, and an entirely new object module format, called GOFF. This new object module type is described in 7.2.5, GOFF If I am reading this correctly, the BINDER would need to use a PDSE output file if there is JAVA, C/C++ type of programs. If you have native cobol, then you might be able to continue the LKED with BINDER to a non PDSE. So any process currently using BINDER for JAVA or C/C++ would most likely already be using a PDSE for the program object output. It might be possible that IBM did not document that section clearly enough (big surprise ) That is just a guess. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 5:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. A quick look in the ENT COB 5.1 migration guide does turn up this jewel... Binding (link-editing) Enterprise COBOL programs What is the difference between an object module, a load module, and a program object? An object module is the output of the compiler and input to the binder. A load module is a non-GOFF executable that is output from the binder with an Enterprise COBOL V4.2 object module. A program object is a new style GOOF executable that is the output from the binder when binding an object module from Enterprise COBOL V5.1. Are PDS and PDSE data sets allowed for object and load modules with Enterprise COBOL V5? Compiler output data sets can be PDS or PDSE, including the object module. The output of the bind step must be a PDSE. When COBOL object modules are linked (bound) they become program objects and must be stored in PDSE data sets. This is going to be a big undertaking for us. We have hundreds of application load libraries that are PDS, NOT PDSE. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. I'm curious about your statement: With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. If you mean the product code comes in PDSE's then that's no big deal. But if you are saying the output of the compiler has to be PDSE's, in other words, all application load libraries have to be PDSE's then I am concerned. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.commailto:david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
I'm talking about application datasets like those in IMS etc. Historically we have bad experience from PDSE... Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Shannon Sent: Friday, September 06, 2013 1:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. With COBOL 5.1, AFAIK, comes also the requirement of the load libraries to be PDSE. Which we DON'T have today, neither in production or test systems. You have PDSEs on your Sysres. If you run DB2 you have PDSEs. PDSEs don't have to be SMS-managed. The only problem you may have is that PDSEs cannot be shared outside of a Sysplex. They cannot be shared across Sysplexes. Otherwise once you install COBOL the library should remain untouched and should be very stable. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Thanks, but we have gone through the documentation. What I'm out for is the *experiences* that people have. There are nearly always surprises in cases like this - at least from our hurtful experience... Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, September 06, 2013 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. What version of Cobol are you running now? I would also look at the migration guides for z/OS V2.1 and COBOL For cobol:http://publibfp.boulder.ibm.com/epubs/pdf/c1473830.pdf For z/OS V2.1: http://www-03.ibm.com/systems/z/os/zos/bkserv/zos_migration_manuals.html Also, see if and when Marna Walle provides a migration presentation for v2.1. And there are many system libraries that are PDS/E datasets. JES2 has some, as well as other products. So you are running PDS/Es at this time. So long as you keep your PDS/E maint up to date, you should not have issues. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 2:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
As always, AFAIK, but it seems that COBOL 5.1 *requires* PDSE due to it using some functionality of PDSE objects. Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 1:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. I'm curious about your statement: With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. If you mean the product code comes in PDSE's then that's no big deal. But if you are saying the output of the compiler has to be PDSE's, in other words, all application load libraries have to be PDSE's then I am concerned. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 5:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We are going to eventually install 2.1 in the future. Besides the OS we have to decide how handle the new COBOL 5.1 and it's dependencies towards Fault Analyzer, Debug Tool and other productivity tools. E g which version/release is required for a certain product to work with another product. And can we upgrade to the latest version of e g Fault Analyzer (that otherwise comes with 2.1) at our z/OS 1.13 and get it working ? As a way to take possible problems in advance of the install of 2.1. With COBOL 5.1, AFAIK, comes also the requirement of the loadlibraries to be PDSE. Which we DON'T have today, neither in production or test systems. Do anyone have experiences of these (potential) problems ? Can you let me take part of them I would be grateful! I understand that some at this list have installed and run z/OS 2.1, but have you used COBOL or the other tools ? Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Regarding PDSE, from migration guide: Link edit/bind changes with Enterprise COBOL Version 5.1 There have been a number of changes to link editing or binding Enterprise COBOL 5.1 programs. * The DFSMS Program Management Binder must be used to bind (link edit) Enterprise COBOL V5 applications. The Language Environment Prelinker is no longer supported. * Executables are Program Objects, not LOAD MODULES. The Program Management Loader (IEWBLDGO) is no longer supported. * Executables can not reside in PDS (only in PDSE ) * NOLOAD segments will not take storage at run time, unless Debug Tool, CEEDUMP, Fault Analyzer, Application Performance Analyzer or a 3rd-party vendor tool that uses DWARF debugging data is used Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Enterprise COBOL V5 uses DRAWF records in an non-loaded class instead of a side file as was used previously. COBOL V5 is the first of the compilers to convert to DRAWF (C already supported it), this is part of IBM's change to have all the compilers share the backend code generator ( same one used by Java JIT). The PD Tools V12 or above ( FA, DB) are required for DRAWF support. The non-loaded class are only supported in the PM3(?) load modules which the binder will only put into a PDSE. So IBM is not saying you have to convert your load libraries to PDSE, you just would be able to use any of the new compilers in the future. -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Do you know if you could use PD v12 in a z/OS 1.13 system ? (If so we could implement PD v12 before taking on z/OS v2.1 and/or COBOL 5.1.) Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bohn, Dale Sent: Friday, September 06, 2013 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Enterprise COBOL V5 uses DRAWF records in an non-loaded class instead of a side file as was used previously. COBOL V5 is the first of the compilers to convert to DRAWF (C already supported it), this is part of IBM's change to have all the compilers share the backend code generator ( same one used by Java JIT). The PD Tools V12 or above ( FA, DB) are required for DRAWF support. The non-loaded class are only supported in the PM3(?) load modules which the binder will only put into a PDSE. So IBM is not saying you have to convert your load libraries to PDSE, you just would be able to use any of the new compilers in the future. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Does anyone have an experience (= have used) with COBOL 5.1 and/or PD Tools under z/OS 2.1 ? Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
On Fri, 6 Sep 2013 05:34:19 -0700, Lizette Koehler wrote: The binder supports ... an entirely new object module format, called GOFF. GOFF is an enhanced form of an object module that HLASM has produced since at least HLASM 1.3 in 1998. AFAIK, GOFF is necessary for the object module (the output from the compiler) to contain things that would require that the resulting executable be a program object, but the use of GOFF does not necessarily mean that the binder can only produce a program object from it. -- Tom Marchant -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
We have all the PD tools at V12 on our z/os 1.12 system now. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Do you know if you could use PD v12 in a z/OS 1.13 system ? (If so we could implement PD v12 before taking on z/OS v2.1 and/or COBOL 5.1.) Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bohn, Dale Sent: Friday, September 06, 2013 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Enterprise COBOL V5 uses DRAWF records in an non-loaded class instead of a side file as was used previously. COBOL V5 is the first of the compilers to convert to DRAWF (C already supported it), this is part of IBM's change to have all the compilers share the backend code generator ( same one used by Java JIT). The PD Tools V12 or above ( FA, DB) are required for DRAWF support. The non-loaded class are only supported in the PM3(?) load modules which the binder will only put into a PDSE. So IBM is not saying you have to convert your load libraries to PDSE, you just would be able to use any of the new compilers in the future. -- 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
While the V12 FA, FM, DB support Enterprise COBOL V5, it will be supported in the NEXT Version of APA (4Q13). -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Thanks. No problems when using them I suppose ? Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, September 06, 2013 3:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. We have all the PD tools at V12 on our z/os 1.12 system now. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Do you know if you could use PD v12 in a z/OS 1.13 system ? (If so we could implement PD v12 before taking on z/OS v2.1 and/or COBOL 5.1.) Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bohn, Dale Sent: Friday, September 06, 2013 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Enterprise COBOL V5 uses DRAWF records in an non-loaded class instead of a side file as was used previously. COBOL V5 is the first of the compilers to convert to DRAWF (C already supported it), this is part of IBM's change to have all the compilers share the backend code generator ( same one used by Java JIT). The PD Tools V12 or above ( FA, DB) are required for DRAWF support. The non-loaded class are only supported in the PM3(?) load modules which the binder will only put into a PDSE. So IBM is not saying you have to convert your load libraries to PDSE, you just would be able to use any of the new compilers in the future. -- 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Thanks! Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bohn, Dale Sent: Friday, September 06, 2013 3:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. While the V12 FA, FM, DB support Enterprise COBOL V5, it will be supported in the NEXT Version of APA (4Q13). -- 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: Dynamic Allocation in COBOL
I don't *think* CEEENV or setenv will do dynamic allocation. That might be a good reason to pick BPXWDYN. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs Sent: Friday, September 06, 2013 4:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic Allocation in COBOL This might not be the right forum for this question, but... Doing some very limited in initial research I've found three documented methods of performing Dynamic Allocation in COBOL ( Enterprise COBOL 4.2), BPXWDYN, CEEENV or setenv. Q1) Are there any others?We already use a home grown assembler program for dynamic allocation, but our direction is to move as much to the OS as possible. Q2) Is there any reason to pick one over the others? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic Allocation in COBOL
Looking at this IBM Technote, it implies they will. http://www-01.ibm.com/support/docview.wss?uid=swg21046577 Mark Jacobs On 09/06/13 09:43, Charles Mills wrote: I don't *think* CEEENV or setenv will do dynamic allocation. That might be a good reason to pick BPXWDYN. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs Sent: Friday, September 06, 2013 4:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic Allocation in COBOL This might not be the right forum for this question, but... Doing some very limited in initial research I've found three documented methods of performing Dynamic Allocation in COBOL ( Enterprise COBOL 4.2), BPXWDYN, CEEENV or setenv. Q1) Are there any others?We already use a home grown assembler program for dynamic allocation, but our direction is to move as much to the OS as possible. Q2) Is there any reason to pick one over the others? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
No John, I was not accusing you of highjacking. But I'm not processing the name portions of the TZ string. I'm not going EDT! Aha! I know what that means... Here's the problem I am trying to solve: What goes in timezone_name? I'm currently sticking the first three characters of TZ or a string such as EST5EDT in timezone_name, and I know that's wrong. What *should* I be doing instead? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, September 06, 2013 4:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: timezone_name? It is your thread, and I have no wish to hijack it. This will therefore be my last post for it. I chose Australian local times advisedly. They illustrate the differences between Daylight|Summer|Official times and Standard ones in the northern and southern hemispheres. You mentioned that you needed to revise your 'parsing' of such strings as 'AMT4AMST', and I perhaps interpreted this too literally. If you are always handing off such strings to someone else, you need not take any responsibility for 'errors' in them. If you are going to try to make sense of them, then you need to understand such differing conventions as those embodied in MSK, Moscow Standard Time MSD, Moscow Daylight Time WET, Western European Time WEST, Western European Summer Time EST, Eastern Standard Time (United States) EDT, Eastern Daylight Time (United States) I have been down this road; and great care must, for example, be taken to disentangle the 'S' for Summer and the 'S' for Standard, assuming always that you are not delegating the responsibility for doing so to someone else. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic Allocation in COBOL
Well I'll be darned! The EC 4.1 P/G has a section called Dynamically creating QSAM files which talks about a run-time option CBLQDA that will take care of missing DD statements and then adds cryptically Do not confuse this implicit allocation mechanism with the explicit dynamic allocation of files by means of environment variables. Explicit dynamic allocation requires that a valid environment variable be set. That seems to be about all they say. ??? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs Sent: Friday, September 06, 2013 6:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic Allocation in COBOL Looking at this IBM Technote, it implies they will. http://www-01.ibm.com/support/docview.wss?uid=swg21046577 Mark Jacobs On 09/06/13 09:43, Charles Mills wrote: I don't *think* CEEENV or setenv will do dynamic allocation. That might be a good reason to pick BPXWDYN. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic Allocation in COBOL
On 9/6/2013 7:43 AM, Charles Mills wrote: I don't *think* CEEENV or setenv will do dynamic allocation. Yes, they can. And we have examples (and a lab) in our 2 day course Enterprise COBOL Update http://www.trainersfriend.com/COBOL_Courses/d704descr.htm as well as in our 3 day course Advanced Topics in COBOL http://www.trainersfriend.com/COBOL_Courses/D725descrpt.htm -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html That might be a good reason to pick BPXWDYN. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs Sent: Friday, September 06, 2013 4:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic Allocation in COBOL This might not be the right forum for this question, but... Doing some very limited in initial research I've found three documented methods of performing Dynamic Allocation in COBOL ( Enterprise COBOL 4.2), BPXWDYN, CEEENV or setenv. Q1) Are there any others?We already use a home grown assembler program for dynamic allocation, but our direction is to move as much to the OS as possible. Q2) Is there any reason to pick one over the others? -- 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: Where environment variables set for batch POSIX programs?
John, yours is the sort of answer I was looking for. I will await your more
tomorrow.
I should have noted what other replies have pointed out: yes, I am familiar
with the various ways of setting LE run-time options. Yes, the CEEOPTS DD
statement route is way preferable IMHO to slashes in PARM=. Also, the
program has its own ability to accept a parameter ZONE('string') and issue
setenv(TZ, string, 1);
So I do have several acceptable solutions to setting TZ.
My question is what do I tell the customers that ask how come you don't get
the time right without us telling you what to do with a parm or DD? Our MVS
programs know what the local time is. What's wrong with your program? I
want to be able to say you need to set TZ in _ as described in
_.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John McKown
Sent: Thursday, September 05, 2013 7:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where environment variables set for batch POSIX programs?
LE parameters in PARMLIB. TZ is a Language Environment variable as well as
UNIX. UNIX will inherit it from LE if not set elsewhere.
At home on tablet. Will reply more from work tomorrow, if nobody else does.
On Sep 5, 2013 8:10 PM, Charles Mills charl...@mcn.org wrote:
This question is related to my question on timezone_name.
I am responsible for a C++ program that runs POSIX(ON) as a started
task in conventional MVS.
I observe that at some customers the environment variable TZ (time
zone) is set correctly, and that at others it is not set at all.
I search the USS documentation and all I find is information about
setting the environment variables if you are a shell user.
For the customers that do not have TZ correctly set (for MVS started
tasks), what do I tell them to do? You need to set the TZ environment
variable by customizing as documented in _?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic Allocation in COBOL
setenv does not _directly_ do a dynamic allocation. It sets up an LE environment variable, which has the same name as what is normally considered the DD name. If the DD name in the SELECT in COBOL is not already allocated, _and_ an LE environment variable is properly set up, _then_ the COBOL run time will do a dynamic allocation. BPXWDYN can be used as already mention. Before either of the above was available, I had code which use IKJTSOEV to set up a TSO environment and then did a TSO ALLOCATE command. I got this from Gilbert Saint-Flour. WORKING-STORAGE SECTION. 01 FILLER. 05 WS-DUMMYPIC S9(8) COMP. 05 WS-RETURN-CODE PIC S9(8) COMP. 05 WS-REASON-CODE PIC S9(8) COMP. 05 WS-INFO-CODEPIC S9(8) COMP. 05 WS-CPPL-ADDRESS PIC S9(8) COMP. 05 WS-FLAGSPIC X(4) VALUE X'00010001'. 05 WS-BUFFER PIC X(256). 05 WS-LENGTH PIC S9(8) COMP VALUE 256. PROCEDURE DIVISION. CALL 'IKJTSOEV' USING WS-DUMMY WS-RETURN-CODE WS-REASON-CODE WS-INFO-CODE WS-CPPL-ADDRESS. IF WS-RETURN-CODE ZERO DISPLAY 'IKJTSOEV FAILED, RETURN-CODE=' WS-RETURN-CODE ' REASON-CODE=' WS-REASON-CODE 'INFO-CODE='WS-INFO-CODE MOVE WS-RETURN-CODE TO RETURN-CODE GOBACK END-IF. MOVE 'ALLOCATE DD(SYSPUNCH) SYSOUT HOLD' TO WS-BUFFER. CALL 'IKJEFTSR' USING WS-FLAGS WS-BUFFER WS-LENGTH WS-RETURN-CODE WS-REASON-CODE WS-DUMMY. IF WS-RETURN-CODE ZERO DISPLAY 'IKJEFTSR FAILED, RETURN-CODE=' WS-RETURN-CODE ' REASON-CODE=' WS-REASON-CODE MOVE WS-RETURN-CODE TO RETURN-CODE GOBACK END-IF. DISPLAY 'ALLOCATE WORKED ! ' UPON SYSPUNCH. I like BPXWDYN best in today's environment. It seems the easiest to understand and code. On Fri, Sep 6, 2013 at 8:45 AM, Mark Jacobs mark.jac...@custserv.comwrote: Looking at this IBM Technote, it implies they will. http://www-01.ibm.com/support/**docview.wss?uid=swg21046577http://www-01.ibm.com/support/docview.wss?uid=swg21046577 Mark Jacobs On 09/06/13 09:43, Charles Mills wrote: I don't *think* CEEENV or setenv will do dynamic allocation. That might be a good reason to pick BPXWDYN. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@listserv.ua.**EDUIBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs Sent: Friday, September 06, 2013 4:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic Allocation in COBOL This might not be the right forum for this question, but... Doing some very limited in initial research I've found three documented methods of performing Dynamic Allocation in COBOL ( Enterprise COBOL 4.2), BPXWDYN, CEEENV or setenv. Q1) Are there any others?We already use a home grown assembler program for dynamic allocation, but our direction is to move as much to the OS as possible. Q2) Is there any reason to pick one over the others? --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
Charles Mills wrote: But I'm not processing the name portions of the TZ string. I'm not going EDT! Aha! I know what that means... Here's the problem I am trying to solve: What goes in timezone_name? One possible solution: use a standard time zone, say Greenwich and base your names on that zone + - your offset. Something like this: use 'Greenwich+2S' for +2 hours Standard Time, or 'Greenwich-5.5D' for -5.5 hours daylight saving and so on. While you're at it, just use 'Greenwich+?' or 'Greenwich-?' or simply 'local' for your local time. Or just Z+2S or Z-5.5D (Z for Zulu Time) This will work if you are not passing in/out the name from/to other people or software, ie, it will only work if you and your software are the only users of those names. Just a lame suggestion of course after watching this thread with interest. :-D 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: Where environment variables set for batch POSIX programs?
The software in question is reporting z/OS security-related events so the one time zone in which the box itself is located (or where its sysprogs think of it as being located) is appropriate and sufficient. Yeah, the fact that z/OS has two completely different systems for specifying the local time zone is annoying, but not my problem to solve today. Customers are not really limited to two time zones, are they? You could in theory run 5 instances of my program with five different TZ settings, right? I hate local time. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, September 06, 2013 7:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where environment variables set for batch POSIX programs? On Fri, 6 Sep 2013 07:05:56 -0700, Charles Mills wrote: My question is what do I tell the customers that ask how come you don't get the time right without us telling you what to do with a parm or DD? Our MVS programs know what the local time is. What's wrong with your program? I want to be able to say you need to set TZ in _ as described in _. Yes, but do your customers' programs know what time it is in Pacific/Apia, e.g. Many enterprises nowadays span multiple time zones; restricting customers to two is pretty harsh. Cite: http://en.wikipedia.org/wiki/Conway%27s_law (Or did I overlook some imputed rhetoric?) Simply, if either the POSIX time or the OS/360 time is set in PARMLIB, but not both, the system should infer the one missing from the one supplied. If both are supplied but incosistent, it should issue an informative message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic Allocation in COBOL
Well I'll be darned. It's a good day. I learned something. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, September 06, 2013 7:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic Allocation in COBOL setenv does not _directly_ do a dynamic allocation. It sets up an LE environment variable, which has the same name as what is normally considered the DD name. If the DD name in the SELECT in COBOL is not already allocated, _and_ an LE environment variable is properly set up, _then_ the COBOL run time will do a dynamic allocation. -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Nope. All working fine. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Thanks. No problems when using them I suppose ? Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where environment variables set for batch POSIX programs?
I have the following in member CEEPRM00 in PARMLIB:
/* NONCICS LE PARMS */
CEEDOPT(
ALL31(OFF),
STACK(,,BELOW)
CBLQDA(OFF),
COUNTRY(US),
DEBUG,
DYNDUMP(*USERID,DYNAMIC,NOTDUMP),
ENVAR('TZ=CST6CDT'),
LIBSTACK(8K,4K,FREE),
STORAGE(NONE,NONE,NONE,8K)
)
/* CICS LE PARMS */
CEECOPT(
ALL31(OFF),
STACK(,,BELOW),
STORAGE(00,NONE,NONE,0K)
)
/* 64 BIT GROUP */
CELQDOPT(
)
On Fri, Sep 6, 2013 at 9:05 AM, Charles Mills charl...@mcn.org wrote:
John, yours is the sort of answer I was looking for. I will await your
more
tomorrow.
I should have noted what other replies have pointed out: yes, I am familiar
with the various ways of setting LE run-time options. Yes, the CEEOPTS DD
statement route is way preferable IMHO to slashes in PARM=. Also, the
program has its own ability to accept a parameter ZONE('string') and issue
setenv(TZ, string, 1);
So I do have several acceptable solutions to setting TZ.
My question is what do I tell the customers that ask how come you don't
get
the time right without us telling you what to do with a parm or DD? Our MVS
programs know what the local time is. What's wrong with your program? I
want to be able to say you need to set TZ in _ as described in
_.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John McKown
Sent: Thursday, September 05, 2013 7:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where environment variables set for batch POSIX programs?
LE parameters in PARMLIB. TZ is a Language Environment variable as well as
UNIX. UNIX will inherit it from LE if not set elsewhere.
At home on tablet. Will reply more from work tomorrow, if nobody else does.
On Sep 5, 2013 8:10 PM, Charles Mills charl...@mcn.org wrote:
This question is related to my question on timezone_name.
I am responsible for a C++ program that runs POSIX(ON) as a started
task in conventional MVS.
I observe that at some customers the environment variable TZ (time
zone) is set correctly, and that at others it is not set at all.
I search the USS documentation and all I find is information about
setting the environment variables if you are a shell user.
For the customers that do not have TZ correctly set (for MVS started
tasks), what do I tell them to do? You need to set the TZ environment
variable by customizing as documented in _?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
As of next week, passwords will be entered in Morse code.
Maranatha!
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where environment variables set for batch POSIX programs?
Charles,
The problem is a lot of customers don't understand LE CEEOPTS. It can be a beast
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Sep 6, 2013, at 10:26 AM, Charles Mills charl...@mcn.org wrote:
Perfect! Much grass.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John McKown
Sent: Friday, September 06, 2013 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where environment variables set for batch POSIX programs?
I have the following in member CEEPRM00 in PARMLIB:
/* NONCICS LE PARMS */
CEEDOPT(
ALL31(OFF),
STACK(,,BELOW)
CBLQDA(OFF),
COUNTRY(US),
DEBUG,
DYNDUMP(*USERID,DYNAMIC,NOTDUMP),
ENVAR('TZ=CST6CDT'),
LIBSTACK(8K,4K,FREE),
STORAGE(NONE,NONE,NONE,8K)
)
/* CICS LE PARMS */
CEECOPT(
ALL31(OFF),
STACK(,,BELOW),
STORAGE(00,NONE,NONE,0K)
)
/* 64 BIT GROUP */
CELQDOPT(
)
--
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: Where environment variables set for batch POSIX programs?
Every address space can run with its own value of TZ or _TZ set. The historic TIME macro does not support different time zones for different address spaces. Since I am now a dedicated user of LE environments, even in HLASM, I would use the CEEGMT subroutine (LE) to get the Lilian date (32 bit integer) and GMT seconds (64 bit float). I would actually store that information (64 bit float) in my data repository. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA31C0/2.2.5.41 You can then use CEEGMTO to get the offset to local time. But this is based on the z/OS TIMEZONE, not the TZ or _TZ environment variable. And CEEDATM to convert whichever you want into a printable character string, for display. Of course, you can convert the GMT time to local using other methods, if you really want to. I agree that local time stinks. I tried to convince my first employer to use GMT. Like to have gotten lynched by Production Control when I printed out the date and time on job output as GMT using 24 hour military notation. They didn't much care for messages like: RAN AT 23:17:05 ON 1981-03-27 (March 27, 1981 at 6:17:05 P.M. local) On Fri, Sep 6, 2013 at 9:32 AM, Charles Mills charl...@mcn.org wrote: The software in question is reporting z/OS security-related events so the one time zone in which the box itself is located (or where its sysprogs think of it as being located) is appropriate and sufficient. Yeah, the fact that z/OS has two completely different systems for specifying the local time zone is annoying, but not my problem to solve today. Customers are not really limited to two time zones, are they? You could in theory run 5 instances of my program with five different TZ settings, right? I hate local time. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, September 06, 2013 7:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where environment variables set for batch POSIX programs? On Fri, 6 Sep 2013 07:05:56 -0700, Charles Mills wrote: My question is what do I tell the customers that ask how come you don't get the time right without us telling you what to do with a parm or DD? Our MVS programs know what the local time is. What's wrong with your program? I want to be able to say you need to set TZ in _ as described in _. Yes, but do your customers' programs know what time it is in Pacific/Apia, e.g. Many enterprises nowadays span multiple time zones; restricting customers to two is pretty harsh. Cite: http://en.wikipedia.org/wiki/Conway%27s_law (Or did I overlook some imputed rhetoric?) Simply, if either the POSIX time or the OS/360 time is set in PARMLIB, but not both, the system should infer the one missing from the one supplied. If both are supplied but incosistent, it should issue an informative message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Comp-3 data defintion
Hello We have a job in which the input file that is comming has one on the field (Location Number) is defined as X(4). This file is comming from a different system. Now here in our programs we are modifying the this field to 5 bytes from the orginal 4 bytes. We are putting transformation step previous to this step and expanding to 5 bytes . We will be removing this process once the other system sends the file with a 5 bye customer number. So now the issue is in some files the data is stored as s9(04) comp-3 here we are planning to make as s9(05) comp-3. Do we need to apply transformations here ? both the data defintions occupy 3 bytes Is there any chance of data getting corrupted ? if data transformations to be applied then how this can be done ? assume that the loaction number starts in the file from 10'th position . Thanks, Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic Allocation in COBOL
Mark, You can also call a svc99 routine in assembler ...we use BPXWDYN and make calls in Cobol..this will be converted to C and it has a dynamic function call ...all ready Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Sep 6, 2013, at 9:45 AM, Mark Jacobs mark.jac...@custserv.com wrote: Looking at this IBM Technote, it implies they will. http://www-01.ibm.com/support/docview.wss?uid=swg21046577 Mark Jacobs On 09/06/13 09:43, Charles Mills wrote: I don't *think* CEEENV or setenv will do dynamic allocation. That might be a good reason to pick BPXWDYN. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs Sent: Friday, September 06, 2013 4:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic Allocation in COBOL This might not be the right forum for this question, but... Doing some very limited in initial research I've found three documented methods of performing Dynamic Allocation in COBOL ( Enterprise COBOL 4.2), BPXWDYN, CEEENV or setenv. Q1) Are there any others?We already use a home grown assembler program for dynamic allocation, but our direction is to move as much to the OS as possible. Q2) Is there any reason to pick one over the others? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- 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: timezone_name?
I haven't specifically looked, but IIRC, TZ can be specified as GMT plus/minus offset HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Comp-3 data defintion
It depends!. When you define a variable in COBOL as PIC S9(4) COMP-3 (aka PACKED-DECIMAL). As you said, PIC S9(5) COMP-3 also takes up 3 bytes of storage. What is actually store in those three bytes in the former case depends on the TRUNC option. TRUNC(STD) will ensure that the PIC S9(4) COMP-3 only has 4 digits of data by unconditionally setting the high order nybble (decimal digit) to zero. I.e. if you do something like 5001 + 5000 the real answer is 10001. With TRUNC(STD), COBOL will ensure the that value stored is 0001 (or 0x1C in hex). IIRC, if you compile TRUNC(OPT) (or was it TRUNC(BIN)?), COBOL does not insert the code to zero out the high digit and it will be stored a 0x10001C). But when DISPLAY'ed or MOVEd to an X(4) field, the high digit will be eliminated. So can you have a problem? Well, maybe. If this S9(4) COMP-3 datum is stored in a data set. And the wrong TRUNC option, then the data in the file might actually have a non-zero high order digit. So when you read the existing data with the S9(5) COMP-3 definition, that high digit _might_ suddenly become significant. I'd judge this as unlikely. But being the paranoid SOB that I am, I would cleanse my data to be sure. I _hate_ this sort of surprise!! event. On Fri, Sep 6, 2013 at 10:22 AM, Ron Thomas ron5...@gmail.com wrote: Hello We have a job in which the input file that is comming has one on the field (Location Number) is defined as X(4). This file is comming from a different system. Now here in our programs we are modifying the this field to 5 bytes from the orginal 4 bytes. We are putting transformation step previous to this step and expanding to 5 bytes . We will be removing this process once the other system sends the file with a 5 bye customer number. So now the issue is in some files the data is stored as s9(04) comp-3 here we are planning to make as s9(05) comp-3. Do we need to apply transformations here ? both the data defintions occupy 3 bytes Is there any chance of data getting corrupted ? if data transformations to be applied then how this can be done ? assume that the loaction number starts in the file from 10'th position . Thanks, Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Comp-3 data defintion
It depends. A Group level move will just move the data, ignoring the differences in field sizes. Move Corresponding, I believe will generate individual move instructions for each pair of fields. Move FIELDA to FIELDB with COMP-3 field descriptions will work just fine. Move FIELDA to FIELDB with X(nn) field descriptions *WILL NOT* provide the desired results. HTH, snip We have a job in which the input file that is comming has one on the field (Location Number) is defined as X(4). This file is comming from a different system. Now here in our programs we are modifying the this field to 5 bytes from the orginal 4 bytes. We are putting transformation step previous to this step and expanding to 5 bytes . We will be removing this process once the other system sends the file with a 5 bye customer number. So now the issue is in some files the data is stored as s9(04) comp-3 here we are planning to make as s9(05) comp-3. Do we need to apply transformations here ? both the data defintions occupy 3 bytes Is there any chance of data getting corrupted ? if data transformations to be applied then how this can be done ? assume that the loaction number starts in the file from 10'th position . /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Comp-3 data defintion
When you convert the data definition to S9(5) COMP-3 and re-compile all programs that use that data definition, the generated compiler code will not force a zero into the high-order nibble of the 3 bytes. COBOL standards require the compiler to force a zero into the high-order nibble when you define a COMP-3 data item with less than the maximum possible digits (i.e., whenever you use an even number of digits for a COMP-3 field). No data transformation should be required. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron Thomas Sent: Friday, September 06, 2013 11:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Comp-3 data defintion Hello We have a job in which the input file that is comming has one on the field (Location Number) is defined as X(4). This file is comming from a different system. Now here in our programs we are modifying the this field to 5 bytes from the orginal 4 bytes. We are putting transformation step previous to this step and expanding to 5 bytes . We will be removing this process once the other system sends the file with a 5 bye customer number. So now the issue is in some files the data is stored as s9(04) comp-3 here we are planning to make as s9(05) comp-3. Do we need to apply transformations here ? both the data defintions occupy 3 bytes Is there any chance of data getting corrupted ? if data transformations to be applied then how this can be done ? assume that the loaction number starts in the file from 10'th position . Thanks, Ron T -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
What perhaps needs a little more emphasis is that, while COBOL is the first, the requirements that binder output be a PDSE-resident program object will obtain for C/C++, PL/I, and LE-compatible HLASM source in the proximate future , Tom Marchant's statement begin extract . . . GOFF does not necessarily mean that the binder can only produce a program object from it. /end extract is entirely correct. It is really only relevant, however, for assembly-language programs. The V1R6 HLASM LR contains the text . . . The program object model can be created only when the GOFF option is specified. The load module option can be created when either the NOGOFF or the GOFF opotion is specified, . . . There is nothing analogous to the HLASM option alternatives NOGOFF|GOFF available for COBOL 5.1. COBOL source libraries can continue to be PDSs, but CPOBOL executables must be stored in PDSEs. This should hold no terrors for anyone. PDSEs can be highly problematic at IPL time: suppoprt for their use is not always available early enough. For COBOL APs they are technically unproblematic. They req On 9/6/13, Jousma, David david.jou...@53.com wrote: Nope. All working fine. _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Berg Sent: Friday, September 06, 2013 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc. Thanks. No problems when using them I suppose ? Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Comp-3 data defintion
And John is right, the zeroing of the high-order nibble does depend on the compile option TRUNC, so do double-check the value of the TRUNC option that was used to compile existing programs that use this data definition. Be especially cautious if the TRUNC option was set differently for different programs when they were last compiled. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, September 06, 2013 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Comp-3 data defintion It depends!. When you define a variable in COBOL as PIC S9(4) COMP-3 (aka PACKED-DECIMAL). As you said, PIC S9(5) COMP-3 also takes up 3 bytes of storage. What is actually store in those three bytes in the former case depends on the TRUNC option. TRUNC(STD) will ensure that the PIC S9(4) COMP-3 only has 4 digits of data by unconditionally setting the high order nybble (decimal digit) to zero. I.e. if you do something like 5001 + 5000 the real answer is 10001. With TRUNC(STD), COBOL will ensure the that value stored is 0001 (or 0x1C in hex). IIRC, if you compile TRUNC(OPT) (or was it TRUNC(BIN)?), COBOL does not insert the code to zero out the high digit and it will be stored a 0x10001C). But when DISPLAY'ed or MOVEd to an X(4) field, the high digit will be eliminated. So can you have a problem? Well, maybe. If this S9(4) COMP-3 datum is stored in a data set. And the wrong TRUNC option, then the data in the file might actually have a non-zero high order digit. So when you read the existing data with the S9(5) COMP-3 definition, that high digit _might_ suddenly become significant. I'd judge this as unlikely. But being the paranoid SOB that I am, I would cleanse my data to be sure. I _hate_ this sort of surprise!! event. On Fri, Sep 6, 2013 at 10:22 AM, Ron Thomas ron5...@gmail.com wrote: Hello We have a job in which the input file that is comming has one on the field (Location Number) is defined as X(4). This file is comming from a different system. Now here in our programs we are modifying the this field to 5 bytes from the orginal 4 bytes. We are putting transformation step previous to this step and expanding to 5 bytes . We will be removing this process once the other system sends the file with a 5 bye customer number. So now the issue is in some files the data is stored as s9(04) comp-3 here we are planning to make as s9(05) comp-3. Do we need to apply transformations here ? both the data defintions occupy 3 bytes Is there any chance of data getting corrupted ? if data transformations to be applied then how this can be done ? assume that the loaction number starts in the file from 10'th position . Thanks, Ron T -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Comp-3 data defintion
I think I goofed up on this. Rereading about the TRUNC option in the book says that it applies only when doing a computation or MOVE _into_ a BINARY (COMP) field. It doesn't say anything about COMP-3 fields. And I can't find anything in any of the manuals about truncating (or not) the high digit on a COMP-3 when the number of digits in the receiving field is even. On Fri, Sep 6, 2013 at 10:49 AM, Farley, Peter x23353 peter.far...@broadridge.com wrote: And John is right, the zeroing of the high-order nibble does depend on the compile option TRUNC, so do double-check the value of the TRUNC option that was used to compile existing programs that use this data definition. Be especially cautious if the TRUNC option was set differently for different programs when they were last compiled. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, September 06, 2013 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Comp-3 data defintion It depends!. When you define a variable in COBOL as PIC S9(4) COMP-3 (aka PACKED-DECIMAL). As you said, PIC S9(5) COMP-3 also takes up 3 bytes of storage. What is actually store in those three bytes in the former case depends on the TRUNC option. TRUNC(STD) will ensure that the PIC S9(4) COMP-3 only has 4 digits of data by unconditionally setting the high order nybble (decimal digit) to zero. I.e. if you do something like 5001 + 5000 the real answer is 10001. With TRUNC(STD), COBOL will ensure the that value stored is 0001 (or 0x1C in hex). IIRC, if you compile TRUNC(OPT) (or was it TRUNC(BIN)?), COBOL does not insert the code to zero out the high digit and it will be stored a 0x10001C). But when DISPLAY'ed or MOVEd to an X(4) field, the high digit will be eliminated. So can you have a problem? Well, maybe. If this S9(4) COMP-3 datum is stored in a data set. And the wrong TRUNC option, then the data in the file might actually have a non-zero high order digit. So when you read the existing data with the S9(5) COMP-3 definition, that high digit _might_ suddenly become significant. I'd judge this as unlikely. But being the paranoid SOB that I am, I would cleanse my data to be sure. I _hate_ this sort of surprise!! event. On Fri, Sep 6, 2013 at 10:22 AM, Ron Thomas ron5...@gmail.com wrote: Hello We have a job in which the input file that is comming has one on the field (Location Number) is defined as X(4). This file is comming from a different system. Now here in our programs we are modifying the this field to 5 bytes from the orginal 4 bytes. We are putting transformation step previous to this step and expanding to 5 bytes . We will be removing this process once the other system sends the file with a 5 bye customer number. So now the issue is in some files the data is stored as s9(04) comp-3 here we are planning to make as s9(05) comp-3. Do we need to apply transformations here ? both the data defintions occupy 3 bytes Is there any chance of data getting corrupted ? if data transformations to be applied then how this can be done ? assume that the loaction number starts in the file from 10'th position . Thanks, Ron T -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- 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.1 and tools like COBOL 5.1, Fault Analyzer, Debug Tool, etc.
Sorry about that. The last two paragraphs of my previous post should be There is nothing analogous to the HLASM option alternatives NOGOFF|GOFF available for COBOL 5.1. COBOL source libraries can continue to be PDSs, but COBOL executables must be stored in PDSEs. This should hold no terrors for anyone. PDSEs can be highly problematic at IPL time: suppoprt for their use is not always available early enough. For COBOL APs they are technically unproblematic. The requirement that PDSEs be used for executables may, of course, pose bureaucratic problems for some large shops, but these problems can be surmounted, and they should anyway have been addressed long ago. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
On Fri, 6 Sep 2013 15:38:05 +, Staller, Allan wrote: I haven't specifically looked, but IIRC, TZ can be specified as GMT plus/minus offset Does the code then need to be changed semiannually? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
It can, but that was not the question. :-) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Friday, September 06, 2013 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: timezone_name? I haven't specifically looked, but IIRC, TZ can be specified as GMT plus/minus offset -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
In the OMVS profile we set timezone like this: TZ=CST6CDT5 -6 for Central Standard and -5 for Central Daylight. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, September 05, 2013 6:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: timezone_name? I'm looking at my C++ code. I wrote it, but I wrote it before I understood as much (?) as I do now, and before GSK surprised me and made me run POSIX(ON). Background: the code runs on many different systems and customers set their machines up the way they set them up. The code uses localtime() and also occasionally strftime() with various format specifiers. I think I have a pretty good handle on the function of the TZ environment variable. But I see code that sets the environment variable timezone_name to a string such as EST or PDT. I don't know exactly why the code is there. I am reading the notes following, for example, localtime() but I don't know what exactly to make of them. 1. I assume I do need to set timezone_name or localtime() may not function correctly, and certainly not strftime %Z. Is that assumption correct? 2. Does setting timezone_name to EST or PDT make sense? Is EST or PDT an appropriate sort of setting? 3. Is setenv() the most reasonable way to set timezone_name? I can see that my parsing of strings such as EST5EDT into a timezone_name is inadequate, but before I re-write it I wanted to see if it was really necessary. Is there a better way to do things? Is there a library function that will parse TZ into among other things timezone_name, so I don't have to re-invent the wheel, possibly badly? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where environment variables set for batch POSIX programs?
This is one area where z/OS UNIX is completely brain-dead (but not the only
one!)
In a rational UNIX environment, all Unix processes are descendants of the
init process. z/OS Unix has an init process, and like other environments
it is configured using /etc/init.options. The z/OS UNIX Init and Tuning
walks you through setting up this file with the important environment
variables, like TZ.
But batch jobs that are dubbed as UNIX processes *don't from the init
process in z/OS UNIX*. So, the environment variables set in
/etc/init.options don't apply.
How stupid is this?IBM is for sure aware of this - they document in
MANY places how to set TZ for a batch job or started task. How nice is it
to define your timezone in a thousand different places?
We have batch C++ utilities as part of our product, and what we do is to
(from the code) read /etc/init.options, parsing the -e lines and loading up
the environment variables. Note that even though Init and Tuning says
that /etc/init.options should be world-readable, a couple of our customers
didn't so we print out a warning message if we can't read it.
Its ugly, but at least you get the environment variables defined in
/etc/init.options, which for most shops includes TZ.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Fri, Sep 6, 2013 at 10:25 AM, Scott Ford scott_j_f...@yahoo.com wrote:
Charles,
The problem is a lot of customers don't understand LE CEEOPTS. It can be a
beast
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
On Sep 6, 2013, at 10:26 AM, Charles Mills charl...@mcn.org wrote:
Perfect! Much grass.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John McKown
Sent: Friday, September 06, 2013 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where environment variables set for batch POSIX programs?
I have the following in member CEEPRM00 in PARMLIB:
/* NONCICS LE PARMS */
CEEDOPT(
ALL31(OFF),
STACK(,,BELOW)
CBLQDA(OFF),
COUNTRY(US),
DEBUG,
DYNDUMP(*USERID,DYNAMIC,NOTDUMP),
ENVAR('TZ=CST6CDT'),
LIBSTACK(8K,4K,FREE),
STORAGE(NONE,NONE,NONE,8K)
)
/* CICS LE PARMS */
CEECOPT(
ALL31(OFF),
STACK(,,BELOW),
STORAGE(00,NONE,NONE,0K)
)
/* 64 BIT GROUP */
CELQDOPT(
)
--
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: Dynamic Allocation in COBOL
On Fri, 6 Sep 2013 09:54:01 -0700, Alan Young wrote: I use BPXWDYN where I can. Unfortunately, with tape datasets all the needed parameters a sometimes not there. ... Bill Schoen has mentioned in MVS-OE that some parameters have been implemented but not yet documented. Guess? Search for strings in the load module? Whatever. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic Allocation in COBOL
Mark Jacobs wrote: This might not be the right forum for this question, but... Doing some very limited in initial research I've found three documented methods of performing Dynamic Allocation in COBOL ( Enterprise COBOL 4.2), BPXWDYN, CEEENV or setenv. Q1) Are there any others?We already use a home grown assembler program for dynamic allocation, but our direction is to move as much to the OS as possible. Q2) Is there any reason to pick one over the others? I use BPXWDYN where I can. Unfortunately, with tape datasets all the needed parameters a sometimes not there. So I have a alternative process for those uses. COBOL can call the C runtime library functions. C has dynalloc() and dynfree() to dynamically allocate and free datasets. The linkage is a bit different. And C doesn't set the high bit in it's parameter lists, so one has to call the function with a extra parameter to keep the high bit in the address from being set like this: CALL 'DYNALLOC' USING BY REFERENCE LS-DYNT BY VALUE ZERO RETURNING WS-RETURN-CODE. A gotcha is being C, character strings need to be NULL terminated (PIC Z). And another is some of the functions in the C runtime have to be statically linked at compile time. I use a small COBOL wrapper that links the C routine statically which I then can call dynamically. The runtime functions also allow text units to be passed which make them flexible. A nice thing is since they are part of the IBM C runtime, you don't have to maintain a routine or distribute one. It's already there with Language Environment. Alan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
On Thu, 5 Sep 2013 16:13:07 -0700, Charles Mills wrote: I'm looking at my C++ code. I wrote it, but I wrote it before I understood as much (?) as I do now, and before GSK surprised me and made me run POSIX(ON). Background: the code runs on many different systems and customers set their machines up the way they set them up. The code uses localtime() and also occasionally strftime() with various format specifiers. I think I have a pretty good handle on the function of the TZ environment variable. But I see code that sets the environment variable timezone_name to a string such as EST or PDT. I don't know exactly why the code is there. Is the code you are referring to using setenv to set timezone_name? Maybe whoever wrote that code didn't know what they were doing. That might be a possibility. I am reading the notes following, for example, localtime() but I don't know what exactly to make of them. Are you referring to this description of localtime in the XL C/C++ Run-Time Library Reference? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/EDCLB1C0/3.561.4 where it says The ctime(), localtime(), and mktime() functions now return Coordinated Universal Time (UTC) unless customized locale information is made available, which includes setting the timezone_name variable. Maybe it doesn't mean an environment variable. Further down that page it refers to Customizing a time zone in the XL C/C++ Programming Guide. That page: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CBCPG1C0/8.4 That page refers to LC_TOD category which is a link to this page: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CBCPG1C0/8.2.3.7 which describes variables timezone_name and daylight_time and others, but they are not environment variables, they are used to customize locales. The POSIX locale was built from CEE.SCEELOCX(EDC$POSX), which does not include a definition of LC_TOD, and I'm not sure if it would be a good idea to change this. But locale definitions for LC_TOD are probably the only place where a variable named timezone_name would be set. 1. I assume I do need to set timezone_name or localtime() may not function correctly, and certainly not strftime %Z. Is that assumption correct? 2. Does setting timezone_name to EST or PDT make sense? Is EST or PDT an appropriate sort of setting? 3. Is setenv() the most reasonable way to set timezone_name? I can see that my parsing of strings such as EST5EDT into a timezone_name is inadequate, but before I re-write it I wanted to see if it was really necessary. Is there a better way to do things? Is there a library function that will parse TZ into among other things timezone_name, so I don't have to re-invent the wheel, possibly badly? It's probably best to forget about timezone_name. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Pre-assigned/invariantASIDs?
My memory tells me that once, a long time ago, I saw a list in some IBM document (possibly one of the MVS Diagnosis manuals) that showed ASIDs for several system address spaces that were pre-assigned and invariant. I can't find this list (if it indeed exists) anywhere now. Does anyone else recall such a list? -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pre-assigned/invariantASIDs?
On 2013-09-06 14:09, Lizette Koehler wrote: You could go into SDSF under DA screen and sort the ASID or ASIDX and take the first 20 or so Or maybe everything up to JES2 but do not include JES2. Lizette Sorry if I wasn't clear enough in my OP. I think there was once a list that indicated, for example, that *MASTER* was always ASID 1, PCAUTH was always ASID 2, etc. I was asking whether I was correct in that recollection. Knowing that a given system address space will always have a certain ASID is a stronger assertion than empirically observing that it appears to always have a certain ASID. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pre-assigned/invariantASIDs?
You could go into SDSF under DA screen and sort the ASID or ASIDX and take the first 20 or so Or maybe everything up to JES2 but do not include JES2. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Friday, September 06, 2013 11:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Pre-assigned/invariantASIDs? My memory tells me that once, a long time ago, I saw a list in some IBM document (possibly one of the MVS Diagnosis manuals) that showed ASIDs for several system address spaces that were pre-assigned and invariant. I can't find this list (if it indeed exists) anywhere now. Does anyone else recall such a list? -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
GETMAIN and LOC=(xx,64)
Hi there, I'm maintaining a larger program written in assembler where GETMAINs have mostly LOC=(BELOW,ANY) or LOC=(ANY,ANY). This program doesn't use anything like PGSER, EXCPVR or the like. My question: In order to give the operating system most flexibility wouldn't it be recommended to change: LOC=(BELOW,ANY) --- LOC=(24,64) LOC=(ANY,ANY)--- LOC=(31,64) ? Any opinion appreciated. -- Manfred -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pre-assigned/invariantASIDs?
Yes there is a specific assignment of ASIDs. However, IBM does have the right to change the order and have different assigned ASIDs at IPL time. There have been times over the last several years where IBM has either added or deleted an ASID and then the list was wrong. And I am not sure that IBM ever kept that documentation up to date over the years. But I will allow better minds than I to weigh in on that. The IBM Manual Problem Management Version 1 Release 13 G325-2564-09 has on page 189 (Chapter 11) a list from IPCS of the ASIDs 0001-0014. I do know that if you take a currently running system. Use SDSF DA screen and sort on the ASID - you will have a fairly accurate listing of what IBM is using right now a IPL time. In IPCS you can Using the IPCS SELECT command Select all Jobname to ASID XREF ASID JOBNAME ASCBADDR SELECTION CRITERIA -- 0001 *MASTER* 00FD1580 ALL 0002 PCAUTH00F7F380 ALL 0003 RASP 00F7F100 ALL 0004 TRACE 00F7EE00 ALL 0005 GRS 00F7EB80 ALL 0006 DUMPSRV 00F7E980 ALL 0008 CONSOLE00F7D080 ALL . 001F JES2 00F5A300 ALL . 0033 CICSFILE 00F4E680 ALL 0034 CICSL202 00F4E400 ALL . 008E CICSJG03 00ED8100 ALL And I think the first 1E address spaces are in solid jello, though IBM could make changes. I have not seen a list presented by IBM in a long time. Only references to IPCS displays or SDSF. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Friday, September 06, 2013 11:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pre-assigned/invariantASIDs? On 2013-09-06 14:09, Lizette Koehler wrote: You could go into SDSF under DA screen and sort the ASID or ASIDX and take the first 20 or so Or maybe everything up to JES2 but do not include JES2. Lizette Sorry if I wasn't clear enough in my OP. I think there was once a list that indicated, for example, that *MASTER* was always ASID 1, PCAUTH was always ASID 2, etc. I was asking whether I was correct in that recollection. Knowing that a given system address space will always have a certain ASID is a stronger assertion than empirically observing that it appears to always have a certain ASID. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- 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
DASD space management
What products are available out there to proactively warn about DASD space issues? I am specifically looking for notification if a VSAM file is reaching the 4GB limit and should be converted to extended addressability, but of course any worthwhile product in this space would warn about any type of file that looks like it soon may run out of space for any of various reasons. If it does other analysis for things such as CA/CI, BUFSP, etc. being poorly defined that would be a plus. z/OS 1.12, if that matters. Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD space management
Frank: As much as I hate to recommend ANY product from CA, I might suggest CA-ASM2. Regards, Mitch McCluhan -Original Message- From: Frank Swarbrick frank.swarbr...@yahoo.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Fri, Sep 6, 2013 12:00 pm Subject: DASD space management What products are available out there to proactively warn about DASD space ssues? am specifically looking for notification if a VSAM file is reaching the 4GB imit and should be converted to extended addressability, but of course any orthwhile product in this space would warn about any type of file that looks ike it soon may run out of space for any of various reasons. If it does ther analysis for things such as CA/CI, BUFSP, etc. being poorly defined that ould be a plus. z/OS 1.12, if that matters. Thanks, rank -- or IBM-MAIN subscribe / signoff / archive access instructions, end 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: DASD space management
Not sure about the pro-active part but Total Storage Facility from Estorian will give you the functionality you're looking for. Thank You, Dave O'Brien From: Mitch [mitc...@aol.com] Sent: Friday, September 06, 2013 3:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DASD space management Frank: As much as I hate to recommend ANY product from CA, I might suggest CA-ASM2. Regards, Mitch McCluhan -Original Message- From: Frank Swarbrick frank.swarbr...@yahoo.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Fri, Sep 6, 2013 12:00 pm Subject: DASD space management What products are available out there to proactively warn about DASD space ssues? am specifically looking for notification if a VSAM file is reaching the 4GB imit and should be converted to extended addressability, but of course any orthwhile product in this space would warn about any type of file that looks ike it soon may run out of space for any of various reasons. If it does ther analysis for things such as CA/CI, BUFSP, etc. being poorly defined that ould be a plus. z/OS 1.12, if that matters. Thanks, rank -- or IBM-MAIN subscribe / signoff / archive access instructions, end 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: DASD space management
W dniu 2013-09-06 21:00, Frank Swarbrick pisze: What products are available out there to proactively warn about DASD space issues? I am specifically looking for notification if a VSAM file is reaching the 4GB limit and should be converted to extended addressability, but of course any worthwhile product in this space would warn about any type of file that looks like it soon may run out of space for any of various reasons. If it does other analysis for things such as CA/CI, BUFSP, etc. being poorly defined that would be a plus. z/OS 1.12, if that matters. Well... DFSMS ? I mean it, DFSMSdfp plus some simple homegrown reports/tools. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pre-assigned/invariantASIDs?
On 2013-09-06 14:46, Lizette Koehler wrote: Yes there is a specific assignment of ASIDs. However, IBM does have the right to change the order and have different assigned ASIDs at IPL time. There have been times over the last several years where IBM has either added or deleted an ASID and then the list was wrong. And I am not sure that IBM ever kept that documentation up to date over the years. But I will allow better minds than I to weigh in on that. The IBM Manual Problem Management Version 1 Release 13 G325-2564-09 has on page 189 (Chapter 11) a list from IPCS of the ASIDs 0001-0014. I do know that if you take a currently running system. Use SDSF DA screen and sort on the ASID - you will have a fairly accurate listing of what IBM is using right now a IPL time. In IPCS you can Using the IPCS SELECT command Select all Jobname to ASID XREF ASID JOBNAME ASCBADDR SELECTION CRITERIA -- 0001*MASTER* 00FD1580 ALL 0002 PCAUTH00F7F380 ALL 0003 RASP 00F7F100 ALL 0004 TRACE 00F7EE00 ALL 0005 GRS 00F7EB80 ALL 0006 DUMPSRV 00F7E980 ALL 0008 CONSOLE00F7D080 ALL . 001F JES2 00F5A300 ALL . 0033 CICSFILE 00F4E680 ALL 0034 CICSL202 00F4E400 ALL . 008E CICSJG03 00ED8100 ALL And I think the first 1E address spaces are in solid jello, though IBM could make changes. I have not seen a list presented by IBM in a long time. Only references to IPCS displays or SDSF. The IPCS listing in that manual is just a sample, and I would not treat it as a guarantee that the ASIDs listed there will always be the ASIDs for the indicated address spaces. In fact, they differ from what I see on a z/OS system here. I like your solid jello analogy, but the jello becomes liquid well before x'1E'! I suspect that IBM's efforts at increasing parallelism in the IPL process have reduced the number of ASIDs that can be considered invariant. And it's probably time for a cautionary note from someone at IBM, rightly stating that relying on an ASID value is not an intended programming interface. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD space management
It depends on how much you want to spend. I could see using MXG/SAS that then sends an email when you have that issue CA Vantage If you can do CBTTAPE.ORG products, find one that lists and extracts vsam info and then you could use SMTPNOTE to send an email You could use the Catalog Search Interface (CSI) to list all vsam and if HU-U-RBA is at a certain point, send an email. TREXX utilities from DINOSoftware, Rocket Software, And so forth. Next question. If you have a concern, why not just set the VSAM datasets to EA/EF to start with - then if they need it they get it rather than the application taking an error. If you set the EA/EF in the dataclass, the next time the file is reorg'd it will get it. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, September 06, 2013 12:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DASD space management What products are available out there to proactively warn about DASD space issues? I am specifically looking for notification if a VSAM file is reaching the 4GB limit and should be converted to extended addressability, but of course any worthwhile product in this space would warn about any type of file that looks like it soon may run out of space for any of various reasons. If it does other analysis for things such as CA/CI, BUFSP, etc. being poorly defined that would be a plus. z/OS 1.12, if that matters. Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pre-assigned/invariantASIDs?
On 6 September 2013 15:39, Gord Tomlin gt.ibm.li...@actionsoftware.com wrote: The IPCS listing in that manual is just a sample, and I would not treat it as a guarantee that the ASIDs listed there will always be the ASIDs for the indicated address spaces. In fact, they differ from what I see on a z/OS system here. I like your solid jello analogy, but the jello becomes liquid well before x'1E'! I suspect that IBM's efforts at increasing parallelism in the IPL process have reduced the number of ASIDs that can be considered invariant. And it's probably time for a cautionary note from someone at IBM, rightly stating that relying on an ASID value is not an intended programming interface. I'm curious about why you would want or need to know anything about hard-coded ASIDs. What aspect of an application or even system program makes it impossible to look up what it needs? (I realize you didn't say you needed to do this, but something surely prompted your question.) Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where environment variables set for batch POSIX programs?
On Fri, 6 Sep 2013 07:05:56 -0700, Charles Mills wrote: My question is what do I tell the customers that ask how come you don't get the time right without us telling you what to do with a parm or DD? Our MVS programs know what the local time is. What's wrong with your program? I want to be able to say you need to set TZ in _ as described in _. Yes, but do your customers' programs know what time it is in Pacific/Apia, e.g. Many enterprises nowadays span multiple time zones; restricting customers to two is pretty harsh. Cite: http://en.wikipedia.org/wiki/Conway%27s_law (Or did I overlook some imputed rhetoric?) Simply, if either the POSIX time or the OS/360 time is set in PARMLIB, but not both, the system should infer the one missing from the one supplied. If both are supplied but incosistent, it should issue an informative message. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM ARCLOGx ARCLOGy must be on the same volume.
Since you have not had an answer, I will give it a try. When DFHSM was developed it was probably the only way that IBM could ENSURE that the two files would be available. Not sure what would happen if one of them went missing. So it is probably something hard coded within DFHSM itself. Is it still needed in today's environment? I am not sure. Maybe someone else will if this answer seems right. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron K. Sent: Friday, September 06, 2013 2:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM ARCLOGx ARCLOGy must be on the same volume. Hello, We recently 'switched' on the ARCLOGx and ARCLOGy functionality of DFHSM. All working perfectly well. However, apparently it is somewhat required to have both output datasets residing on the same volume. (else messages like ARC0022I may appear at swaplog-time). This is all documented well, however I do not understand why this requirement is there. Does anyone have an idea why DFHSM is unable to handle a rename when both output datasets do not reside on the same volume? Many thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pre-assigned/invariantASIDs?
On 2013-09-06 15:58, Tony Harminc wrote: I'm curious about why you would want or need to know anything about hard-coded ASIDs. What aspect of an application or even system program makes it impossible to look up what it needs? (I realize you didn't say you needed to do this, but something surely prompted your question.) I was actually just looking at another table in the Diagnosis Reference (PC services in system function table), and happened to think I wonder what that list of pre-assigned ASIDs looks like now. Pure curiosity, coupled with a wee senility check! -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Job Posting Rules
Darren will chime in when he gets thru with his day job, but in general just a link to the job opening should be sufficient. In a message dated 09/06/13 15:34:52 Central Daylight Time, jeffrey.dea...@securian.com writes: What are the rules for posting links to system engineer jobs on the list these days -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN and LOC=(xx,64)
On 9/6/2013 1:52 PM, Manfred Lotz wrote: I'm maintaining a larger program written in assembler where GETMAINs have mostly LOC=(BELOW,ANY) or LOC=(ANY,ANY). This program doesn't use anything like PGSER, EXCPVR or the like. My question: In order to give the operating system most flexibility wouldn't it be recommended to change: LOC=(BELOW,ANY) --- LOC=(24,64) LOC=(ANY,ANY)--- LOC=(31,64) Any opinion appreciated. You need to verify that nothing in a relocated area uses 3-byte address constants, and that the address of the acquired storage isn't treated as 24-bit anywhere. You can either run with PRINT ON,GEN,DATA and go through the listing line by line, or change everything and hope you get an 0C4 on all bad references. P.S. The program does run in AM31 already? Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
On Fri, Sep 6, 2013 at 8:47 AM, Charles Mills charl...@mcn.org wrote: I'm currently sticking the first three characters of TZ or a string such as EST5EDT in timezone_name, and I know that's wrong. What *should* I be doing instead? Charles You should use the portion in front of the offset digits (5,+5, -2, etc) during standard time (winter) and use the portion after the offset during daylight savings time (summer). Lengths may vary. Date ranges could be specified in the TZ variable. http://en.wikipedia.org/wiki/List_of_tz_database_time_zones has a nice list and a link to a tz database file. -- 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: DFHSM ARCLOGx ARCLOGy must be on the same volume.
If it is an error reported by the RENAME service, there should also be an IEC614I message with the details as described in chapter 6 of the DFSMSdfp Diagnosis manual. Are your log datasets SMS managed? :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Ron K. :: Sent: Friday, September 06, 2013 2:58 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: DFHSM ARCLOGx ARCLOGy must be on the same volume. :: :: Hello, :: :: We recently 'switched' on the ARCLOGx and ARCLOGy functionality of DFHSM. :: All working perfectly well. However, apparently it is somewhat required :: to have both output datasets residing on the same volume. (else messages :: like ARC0022I may appear at swaplog-time). This is all documented well, :: however I do not understand why this requirement is there. :: :: Does anyone have an idea why DFHSM is unable to handle a rename when :: both output datasets do not reside on the same volume? :: :: Many 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: GETMAIN and LOC=(xx,64)
On 6 September 2013 16:53, Gerhard Postpischil gerh...@valley.net wrote: On 9/6/2013 1:52 PM, Manfred Lotz wrote: I'm maintaining a larger program written in assembler where GETMAINs have mostly LOC=(BELOW,ANY) or LOC=(ANY,ANY). This program doesn't use anything like PGSER, EXCPVR or the like. My question: In order to give the operating system most flexibility wouldn't it be recommended to change: LOC=(BELOW,ANY) --- LOC=(24,64) LOC=(ANY,ANY)--- LOC=(31,64) Any opinion appreciated. You need to verify that nothing in a relocated area uses 3-byte address constants, and that the address of the acquired storage isn't treated as 24-bit anywhere. You can either run with PRINT ON,GEN,DATA and go through the listing line by line, or change everything and hope you get an 0C4 on all bad references. Surely Manfred is just asking about the real storage that backs the virtual. Which, except in rare cases such as using EXCPVR or LRA or perhaps some fast-path VTAM operations, is entirely transparent to the application program. I see no problem with the proposed changes, and they should indeed provide some added flexibility to RSM. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic Allocation in COBOL
There are always about 6 ways to do the same thing. Just understand how it works, then fit the solution or method into your design ... Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Sep 6, 2013, at 10:33 AM, Charles Mills charl...@mcn.org wrote: Well I'll be darned. It's a good day. I learned something. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, September 06, 2013 7:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic Allocation in COBOL setenv does not _directly_ do a dynamic allocation. It sets up an LE environment variable, which has the same name as what is normally considered the DD name. If the DD name in the SELECT in COBOL is not already allocated, _and_ an LE environment variable is properly set up, _then_ the COBOL run time will do a dynamic allocation. -- 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: GETMAIN and LOC=(xx,64)
Interesting question, with a number of answers. The second value only comes into play at PAGEFIX time, be that your program doing it explicitly, or the system doing it for you, most often as part of an I/O operation, such as a BSAM READ or WRITE, or a QSAM GET or PUT. Up until that PAGEFIX happens any real page frame can back any virtual page. I have seen 24-bit real backing a 64-bit virtual and the reverse. Only at PAGEFIX does he make sure that the real page backing the virtual is less than or equal to what you specified in the LOC= parameter. When you do a GETAMIN, or STORAGE OBTAIN, or whatever, the system notes your request and sets up some control areas, but no frames are assigned, yet. Once you touch the page, then a real frame is assigned to the virtual page, and the system doesn't care where that real frame is. At PAGEFIX time, then it matters. If you had a LOC=(31,31) and the initial backing frame is a 24-bit frame, it may do nothing or it may move the data to a 31-bit frame. If the initial backing frame is a 64-bit frame, then it will move the data to a 24-bit or 31-bit frame. Now to your question. Unless you are doing something special where you know you need 24 or 31 bit real, you can use LOC=(24,64), or LOC=(31,64). BSAM, QSAM and VSAM all support 64-bit backing frames. Since most normal programs can't do a LRA/LRAG/LRAY, you are probably safe. I can't think of any non-privileged instructions that are real frame sensitive. DCB's can be LOC=(24,64) As with any change, TEST, TEST, TEST. And if I have miss-spoken at any point, I am sure someone will set the record straight. HTH Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com On 9/6/2013 1:52 PM, Manfred Lotz wrote: I'm maintaining a larger program written in assembler where GETMAINs have mostly LOC=(BELOW,ANY) or LOC=(ANY,ANY). This program doesn't use anything like PGSER, EXCPVR or the like. My question: In order to give the operating system most flexibility wouldn't it be recommended to change: LOC=(BELOW,ANY) --- LOC=(24,64) LOC=(ANY,ANY)--- LOC=(31,64) Any opinion appreciated. ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD space management
I'm with Lizette in thinking you could do a this a hundred different ways with DCOLLECT and MXG, and pretty cheaply on a workstation if you have SAS for Windows. I also agree that going ES/EA from the get go would be a benefit. Did that 15 years ago and it worked a treat. Ron Sent via the Samsung Galaxy Note® 8.0, an ATT 4G LTE tablet Original message From: Lizette Koehler stars...@mindspring.com Date: 09/07/2013 03:23 (GMT+08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] DASD space management It depends on how much you want to spend. I could see using MXG/SAS that then sends an email when you have that issue CA Vantage If you can do CBTTAPE.ORG products, find one that lists and extracts vsam info and then you could use SMTPNOTE to send an email You could use the Catalog Search Interface (CSI) to list all vsam and if HU-U-RBA is at a certain point, send an email. TREXX utilities from DINOSoftware, Rocket Software, And so forth. Next question. If you have a concern, why not just set the VSAM datasets to EA/EF to start with - then if they need it they get it rather than the application taking an error. If you set the EA/EF in the dataclass, the next time the file is reorg'd it will get it. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, September 06, 2013 12:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DASD space management What products are available out there to proactively warn about DASD space issues? I am specifically looking for notification if a VSAM file is reaching the 4GB limit and should be converted to extended addressability, but of course any worthwhile product in this space would warn about any type of file that looks like it soon may run out of space for any of various reasons. If it does other analysis for things such as CA/CI, BUFSP, etc. being poorly defined that would be a plus. z/OS 1.12, if that matters. Thanks, Frank -- 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: timezone_name?
Mike Schwab's point is well made. Some of these values are three-character ones, some of them are four-character ones, and five-character ones are obviously in the womb of time. A parse that deals swith this variability is, finally, trivial; but the issue should not be ignored. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where environment variables set for batch POSIX programs?
Interesting approach. Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Friday, September 06, 2013 10:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where environment variables set for batch POSIX programs? This is one area where z/OS UNIX is completely brain-dead (but not the only one!) In a rational UNIX environment, all Unix processes are descendants of the init process. z/OS Unix has an init process, and like other environments it is configured using /etc/init.options. The z/OS UNIX Init and Tuning walks you through setting up this file with the important environment variables, like TZ. But batch jobs that are dubbed as UNIX processes *don't from the init process in z/OS UNIX*. So, the environment variables set in /etc/init.options don't apply. How stupid is this?IBM is for sure aware of this - they document in MANY places how to set TZ for a batch job or started task. How nice is it to define your timezone in a thousand different places? We have batch C++ utilities as part of our product, and what we do is to (from the code) read /etc/init.options, parsing the -e lines and loading up the environment variables. Note that even though Init and Tuning says that /etc/init.options should be world-readable, a couple of our customers didn't so we print out a warning message if we can't read it. Its ugly, but at least you get the environment variables defined in /etc/init.options, which for most shops includes TZ. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: timezone_name?
The specs seem to indicate it may be any number of characters. http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html Five-character time zones are already here. http://www.timeanddate.com/library/abbreviations/timezones/atlantic/azost.ht ml It appears you strip characters until you get to a non-alpha character. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, September 06, 2013 7:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: timezone_name? Mike Schwab's point is well made. Some of these values are three-character ones, some of them are four-character ones, and five-character ones are obviously in the womb of time. A parse that deals swith this variability is, finally, trivial; but the issue should not be ignored. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OT: Obscurity Is Not Security... Or Is It?
http://www.securityweek.com/obscurity-not-security-or-it While obscuring website code, server architecture, and security mechanisms doesn’t provide bullet-proof security on its own, it can be effective... By this point, everyone has probably heard the phrase, “Obscurity is not security.” Or some variation thereof. Technically, it’s true. No matter how obscure you make something, it doesn’t make it impossible to “crack.” It just makes it more difficult. That’s because whatever you do to obscure something, you can always reverse your way out of it to get the clear picture again. The time it takes to achieve clarity just depends on how obscure you make it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pre-assigned/invariantASIDs?
Yes there is a specific assignment of ASIDs. However, IBM does have
the
right to change the order and have different assigned ASIDs at IPL
time.
There have been times over the last several years where IBM has either
added
or deleted an ASID and then the list was wrong.
And I am not sure that IBM ever kept that documentation up to date
over the
years. But I will allow better minds than I to weigh in on that.
The IBM Manual
Problem Management Version 1 Release 13 G325-2564-09 has on page 189
(Chapter 11) a list from IPCS of the ASIDs 0001-0014.
I do know that if you take a currently running system. Use SDSF DA
screen
and sort on the ASID - you will have a fairly accurate listing of what
IBM
is using right now a IPL time.
In IPCS you can
Using the IPCS SELECT command
Select all
Jobname to ASID XREF
ASID JOBNAME ASCBADDR SELECTION CRITERIA
--
0001*MASTER* 00FD1580 ALL
0002 PCAUTH00F7F380 ALL
0003 RASP 00F7F100 ALL
0004 TRACE 00F7EE00 ALL
0005 GRS 00F7EB80 ALL
0006 DUMPSRV 00F7E980 ALL
0008 CONSOLE00F7D080 ALL
.
001F JES2 00F5A300 ALL
And I think the first 1E address spaces are in solid jello, thoughIBM
could
make changes.
I have not seen a list presented by IBM in a long time. Only
references to
IPCS displays or SDSF.
The IPCS listing in that manual is just a sample, and I would not treat
it as a guarantee that the ASIDs listed there will always be the ASIDs
for the indicated address spaces. In fact, they differ from what I see
on a z/OS system here.
I like your solid jello analogy, but the jello becomes liquid well
before x'1E'!
I suspect that IBM's efforts at increasing parallelism in the IPL
process have reduced the number of ASIDs that can be considered
invariant. And it's probably time for a cautionary note from someone at
IBM, rightly stating that relying on an ASID value is not an intended
programming interface.
The only preassigned ASID is 0001 for *MASTER*. Any code which has
dependency on any other ASID assignment should be considered to be
defective.
Up to a certain point is system initialization, there isn't any
parallelism in the things which are creating system address spaces,
so the ordering of ASIDs changes only when we change something in the
design of the system initialization processing.
The example in the IPCS manual is obviously from an MVS/ESA SP3.1.x
system, because there was no RASP prior to MVS/ESA SP3.1.0, and an
SP4.1.0 or higher system would have XCFAS as ASID 0006.
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
