Re: GO TO cobol
On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: GO TO cobol
An alternative is to have e g an 88-type LEAVE item that is checked for every code-block including all iterations and selections. (You set leave to true when wanting to do a leave type jump.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Edward Jaffe Skickat: den 16 april 2012 08:15 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
z/OS V1R13 testing after migration
Sorry if this is a dup.. but I don't find nothing related in the list. Do you know of any presentation or someting similar from SHARE or others that talks about actions taken for testing z/OS V1R13 and products related to the operating system release after migration from V1R11 (or others)? -- Un saludo. Álvaro Guirao -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Detail SMF record processing
Does anyone know where I can find detail information about SMF record processing? For example: SMFEWTM is issued X routine is invoked to do such and such Y routine is invoked to do such and such Etc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Detail SMF record processing
On Mon, 16 Apr 2012 05:58:11 -0500 Donald Likens dlik...@infosecinc.com wrote: :Does anyone know where I can find detail information about SMF record processing? For example: :SMFEWTM is issued :X routine is invoked to do such and such :Y routine is invoked to do such and such :Etc. What are you looking for? From your perspective the only issue is whether U83, U84 or U85 is invoked. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Detail SMF record processing
I am attempting to determine how much processing is performed before the iefu8x exit is invoked. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Detail SMF record processing
On Mon, 16 Apr 2012 06:48:43 -0500 Donald Likens dlik...@infosecinc.com wrote: :I am attempting to determine how much processing is performed before the iefu8x exit is invoked. If so, you also need to include the processing before the SMFEWTM, where the application is gathering the data. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SSH/SCP/SFTP for CMS version 2.0 available
Sine Nomine would like to announce the availability of version 2 of our SSH, SCP and SFTP utilities for z/VM and CMS. This version provides several new features, and fixes a number of minor bugs. If you have a maintenance con- tract with us, the new VMARC file has been copied to your support id download area and is available for download at your convenience. NEW FEATURES IN VERSION 2.0 ___ o Base support for compressed file transfers implemented Version 2 now supports compression during file transfers if compression is enabled on the remote server, and the -C option is supplied on the command line. The delayed compression mode as implemented in OpenSSH is not yet available, but is planned for a future release. o Hardware support for the AES-128 and SHA-1 ciphers is now employed if available. If the Message Security Assist feature is available on the host, the CMS SSH, SCP, and SFTP commands will use it to reduce CPU utilization when transferring data. The system administrator is still responsible for ena- bling and setting up the facility prior to use by commands in the package; the utilities will fall back to software implementations of both algorithms if hardware acceleration support is not available. BUGS FIXED IN VERSION 2.0 _ o Commands operate correctly on z800 systems without crypto processor support The utilities now operate correctly on minimal z800 systems without any crypto processors. o OpenSSH keepalive requests now handled properly The utilities now handle keepalive packets from OpenSSH-based servers when connections are left idle for long periods. o Displayed lines in SSH are split more intelligently Output lines from remote systems are now more intelligently parsed and wrapped. This corrects a reported problem with lines being broken/wrapped unnecessarily when written to the CMS console device. o Screen size is now determined at runtime and negotiated during connection initiation. The screen size and line lengths are now determined at the time of con- nection initiation, and are passed to the remote server as part of con- nection setup. This allows the remote server to segment line writes in a way that behaves more intelligently with 3270 devices. o Recursive file transfers with SCPCMS are now handled more efficiently. The processing of recursive transfers of entire directories to and from CMS SFS and BFS file spaces are now handled in a more efficient way, reducing the amount of processing needed to establish the directory tree and lists of files to be transferred. This results in faster transfer times. o Wildcard file name parsing and processing is now correct. A bug in wildcard name expansion and conversion to CMS file naming con- ventions has been corrected. The bug related to correctly parsing some more obscure SFS and BFS file specifications. o Directory names in SFS and BFS file transfers with SCP are now correctly lower-cased if the '-l' option is specified. The -l option was not processed in version 1. FOR MORE INFORMATION Contact i...@sinenomine.net for more information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, we'd need to do: I-P. READ FILE AT END SET CONDITION TO TRUE END-READ IF NOT CONDITION THEN ... END-IF. I-P-EXIT. EXIT. Which I consider to be worse than the exit, so far as comprehension is concerned. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, April 16, 2012 5:40 AM To: IBM-MAIN@bama.ua.edu Subject: SV: GO TO cobol An alternative is to have e g an 88-type LEAVE item that is checked for every code-block including all iterations and selections. (You set leave to true when wanting to do a leave type jump.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Edward Jaffe Skickat: den 16 april 2012 08:15 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
What??? monopolizes the CPU??? GO TO was made a pariah by an article by Edgar Dijkstra. http://en.wikipedia.org/wiki/Considered_harmful And, of course, management went stupid (again) and came up with you cannot use the GOTO in any code at all. Which actually makes some COBOL more complicated due to the requirement of nesting IF statements within IF statements. And before the END-IF, that could be very complicated. I've see old code like: IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ... IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ELSE ... . Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in it. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jake anderson Sent: Sunday, April 15, 2012 10:49 PM To: IBM-MAIN@bama.ua.edu Subject: GO TO cobol Hi All, Apology for asking a basic question and Being Ignorant. We know that GO TO statments are a big NO in many production sites and one of the reason being it monopolizes the entire CPU. Are there any documentation explaining about the GO TO statements which clearly describes how it effects the System CPU and performances ? Apology again if the question is not really sensible or else it requires more information. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: brand new CF LPAR
Just to add to my previous request, I have to define new coupling facility datasets to enbale support for newer protocols and do not know **yet** how to pouplate them with our exisitng sysplex policies.. May I IPL an LPAR (z/OS 1.13) with the new coupling facility datasets and then definine activate (old) policies.. will it work?.. thanks again.. Munif -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Sun, 15 Apr 2012 23:15:19 -0700, Edward Jaffe wrote: The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. C commits this offense. Shame on C. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. Rexx is a nightmare here. The LEAVE statement, even with a specified target, won't exit a (nest of) procedure(s). The SIGNAL statement trashes the DO nesting at the target level. Shame on Rexx. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Mon, 16 Apr 2012 07:28:10 -0500, McKown, John wrote: Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, ... I don't know COBOL. However any properly designed language should allow incorporating such a test in the loop control expression: while read( ... ); do ... done -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Remember when COBOL was originally designed. We've learned a LOT since then. The only real looping verb is PERFORM. It has an WHILE condition test and an UNTIL condition test. And, in modern COBOLs, the phrases WITH TEST BEFORE or WITH TEST AFTER, to perform the test at the start of the loop (0 or more iterations, like while in C) or at the end of the loop (1 or more iteration, like do while in C). WITH TEST AFTER is the default. But the UNTIL is a condition test and cannot execute something which returns a TRUE/FALSE type value. Also remember that COBOL, at least originally, was supposed to be very English-like and so usable by people at the Army PFC level of training. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, April 16, 2012 8:12 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GO TO cobol On Mon, 16 Apr 2012 07:28:10 -0500, McKown, John wrote: Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, ... I don't know COBOL. However any properly designed language should allow incorporating such a test in the loop control expression: while read( ... ); do ... done -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
John, the READ construct now is much easier with READ FILE AT END Do stuff NOT AT END Do normal processing END-READ This makes it really easy to keep the code tight and all together. By using program switches, I have handled program start and end, abend, and processed 6 or 7 files with no (or very few) paragraphs, and only a couple statements ending with periods. It actually was fun to put together and was easy to maintain. However, it would not always be this streamlined for some large programs with lots of things going on. Billy On Mon, Apr 16, 2012 at 8:28 AM, McKown, John john.mck...@healthmarkets.com wrote: Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, we'd need to do: I-P. READ FILE AT END SET CONDITION TO TRUE END-READ IF NOT CONDITION THEN ... END-IF. I-P-EXIT. EXIT. Which I consider to be worse than the exit, so far as comprehension is concerned. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.comhttp://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, April 16, 2012 5:40 AM To: IBM-MAIN@bama.ua.edu Subject: SV: GO TO cobol An alternative is to have e g an 88-type LEAVE item that is checked for every code-block including all iterations and selections. (You set leave to true when wanting to do a leave type jump.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Edward Jaffe Skickat: den 16 april 2012 08:15 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Thank you and best regards, *Billy Ashton* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Yes, modern COBOL is much better. I don't use COBOL much, and other than the new END-verb constructs, don't do much. But you still need a PERFORM to loop. I.e. you cannot loop in the READ verb itself. Might be nice. I guess you could: PERFORM UNTIL EOF READ ... AT END SET EOF TO TRUE NOT AT END ... END-READ END-PERFORM I haven't looked recently, but we have a lot of old code. So we don't have much with the newer constructs. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bill Ashton Sent: Monday, April 16, 2012 8:36 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GO TO cobol John, the READ construct now is much easier with READ FILE AT END Do stuff NOT AT END Do normal processing END-READ This makes it really easy to keep the code tight and all together. By using program switches, I have handled program start and end, abend, and processed 6 or 7 files with no (or very few) paragraphs, and only a couple statements ending with periods. It actually was fun to put together and was easy to maintain. However, it would not always be this streamlined for some large programs with lots of things going on. Billy On Mon, Apr 16, 2012 at 8:28 AM, McKown, John john.mck...@healthmarkets.com wrote: Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, we'd need to do: I-P. READ FILE AT END SET CONDITION TO TRUE END-READ IF NOT CONDITION THEN ... END-IF. I-P-EXIT. EXIT. Which I consider to be worse than the exit, so far as comprehension is concerned. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.comhttp://www.healthmarkets.com/ Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, April 16, 2012 5:40 AM To: IBM-MAIN@bama.ua.edu Subject: SV: GO TO cobol An alternative is to have e g an 88-type LEAVE item that is checked for every code-block including all iterations and selections. (You set leave to true when wanting to do a leave type jump.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Edward Jaffe Skickat: den 16 april 2012 08:15 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software
SV: GO TO cobol
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul Gilmartin Skickat: den 16 april 2012 15:11 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On Sun, 15 Apr 2012 23:15:19 -0700, Edward Jaffe wrote: The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. C commits this offense. Shame on C. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. Rexx is a nightmare here. The LEAVE statement, even with a specified target, won't exit a (nest of) procedure(s). The SIGNAL statement trashes the DO nesting at the target level. Shame on Rexx. I can see that as a feature. ;) That prohibits some obfuscate like coding. (BTW, How do You imagine the behavior if the Signal DID NOT trash the DO nesting? I mean, of what use would that be? As You have the CALL stmt.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Inexpensive estimate of uncompressed size of PS-E dataset
Bob, Thanks; I should have thought of looking at the LISTCAT output. Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Apr 13, 2012 at 6:59 PM, Bob Rutledge deerh...@ix.netcom.comwrote: Kirk Wolf wrote: I'm trying to understand how to use the catalog fields: COMUDSIZ UDATASIZ COMPIND VVRNFLGS ... in order to get an estimate of the uncompressed size of a compressed, extended-format DSORG=PS dataset. The documentation in Managing Catalogs is a little thin. - is UDATASIZ the uncompressed size? - which flags should I use to determine that the value in UDATASIZ is valid - VVRNFLGS? not bit x'80'? - COMPIND bit x'40'? Pointers to additional documentation or usage information would be appreciated. I'm thinking what's required here is some creative correlation between Managing Catalogs and the Interpreting LISTCAT Output Listings appendix in the Access Method Services for Catalogs book. How about COMP-USER-DATA-SIZE and USER-DATA-SIZE? I'll leave the flags for you. Bob --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
And of course there were languages of the time like FORTRAN, which encouraged unconstrained use of GO TO and the creation of spaghetti code. FORTRAN at that point had very limited support for structured programming: one very restrictive loop construct and a conditional branch which was essentially a three-way GO TO. There were even cases where the conventions being followed might require a GO TO to reach corrective additions which would then use a GO TO to resume the original statement stream, either to preserve statement number sequencing conventions, or to avoid resequencing the entire program deck when all cards had sequence numbers. I think more people interpreted Dijkstra's remarks as a complaint against the unstructured use of GO TO and the lack of language support for structured programming constructs that forced frequent GO TO use, rather than an arbitrary total ban. The complaint was primarily one about use of the GO TO degrading comprehension of the program structure, not about program performance. Ultimately, all code is reduced to the Assembler or machine language level, where the machine-level equivalent of the GO TO is essential and unavoidable. ACM SIGPLAN (Special Interest Group on Programming Languages) Notices tended to publish humor, especially near April 1. One proposal many years ago to totally eliminate the FORTRAN GO TO was to replace it with a COME FROM statement. This totally eliminated the confusion over whether any FORTRAN statement with a statement number might be the target of some unseen remote branch -- and replaced it with the even more confusing concept that every statement with a statement number might actually be a disguised branch to some remote COME FROM statement. JC Ewing On 04/16/2012 07:42 AM, McKown, John wrote: What??? monopolizes the CPU??? GO TO was made a pariah by an article by Edgar Dijkstra. http://en.wikipedia.org/wiki/Considered_harmful And, of course, management went stupid (again) and came up with you cannot use the GOTO in any code at all. Which actually makes some COBOL more complicated due to the requirement of nesting IF statements within IF statements. And before the END-IF, that could be very complicated. I've see old code like: IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ... IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ELSE ... . Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in it. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
This topic I cannot resist... Uggg... Having learned COBOL in the mid 70's, the instructor taught that PERFORM was to be used only in situations where you wanted to do a certain routine at several locations in the program. The teaching was also about straight line programming. Flow Charts were also part of the curriculum. Having said that, I still use GO TO extensively, and have not kept up with the modern programming extensions and constructs. I've had many instances in my career where a structured program has been straight lined with extremely dramatic performance results. Mostly I believe that knowing Assembler language and how the COBOL compiler would generate the assembler code version of the program provided the reasons for my coding techniques. I would write the program as close to what the assembler code would be as possible. This would usually provide some great performance at run time (and at compile time). One example (out of several) was a program which normally took 4-6 hours to do its magic. When I re-wrote it due to the necessity of adding more functionality, I went ahead and straight lined it according to the logic of what the program was supposed to do. When the re-write was finished, the new program took 20 minutes to run the first time it was in production. I have several other examples with these type of results. Also, CICS used to treat the HANDLE CONDITION API as a GO TO, not a perform. Went to the Well in the early-mid 80's over that one with a bunch of certain whiz-kids who were trained under the good doctors premises. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Origins of numeric assignation of z196 z114
I have seeked but found nothing about this, why the new servers have been named z196 z114 and not Z11 EC Z11 BC? -- Un saludo. Álvaro Guirao -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Mon, 2012-04-16 at 09:52 -0400, Joel C. Ewing wrote: One proposal many years ago to totally eliminate the FORTRAN GO TO was to replace it with a COME FROM statement. Ah yes, an old chestnut: http://www.fortran.com/come_from.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: GO TO cobol
On Mon, 16 Apr 2012 15:42:12 +0200, Thomas Berg wrote: Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. Rexx is a nightmare here. The LEAVE statement, even with a specified target, won't exit a (nest of) procedure(s). The SIGNAL statement trashes the DO nesting at the target level. Shame on Rexx. I can see that as a feature. ;) That prohibits some obfuscate like coding. As it stands, the only way to exit a nest of procedures is to set a flag and RETURN, and test that flag and RETURN after each intervening cal; hardly unobfuscated. I'd be delighted to be able to code, instead DO I =1 DO J = 1 DO K= 1 CALL P1 ... END K END J END I P1: CALL P2 P2: PROCEDURE EXPOSE J LEAVE J I forgot to mention that SIGNAL trashes the DO nesting but does not exit _any_ procedures. I was once called on to advise a novice colleague who had used SIGNAL, he thought, to leave a procedure nest. Necessarily, he had coded all his loops with GOTO instead of DO. It worked fine on small data sets; he came to me for help when it overflowed the stack on a large data set. (BTW, How do You imagine the behavior if the Signal DID NOT trash the DO nesting? I mean, of what use would that be? As You have the CALL stmt.) It could be used as a local GOTO. But that would still be of no use to me, because I never use SIGNAL as a GOTO, only in SIGNAL ON NOVALUE/ERROR. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Origins of numeric assignation of z196 z114
W dniu 2012-04-16 16:33, Alvaro Guirao Lopez pisze: I have seeked but found nothing about this, why the new servers have been named z196 z114 and not Z11 EC Z11 BC? Why not z11? I don't know. Why 196 and 114? I heard about it: 1xx means FIRST generation (of what? naming convention?) 96 means number of processors inside. Note, you can buy only 80 of them, but it really contains 96 processors, inlcuidng SAPs and spares. 14 is for M10 model (4 are for spares and SAPs). BTW: I really can't understand marketing names like z196, TS1140, or DS8000. Why don't they use names like Jaguar (ok, it's partially used), MAGSTAR, T-REX, MtBlanc or Cindy Crawford? Last, bit not least: Athlon, or Pentium sounds much better than CMOS 11S. -- 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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Origins of numeric assignation of z196 z114
On 4/16/2012 7:33 AM, Alvaro Guirao Lopez wrote: I have seeked but found nothing about this, why the new servers have been named z196 z114 and not Z11 EC Z11 BC? zEnterprise is an entirely new class of hybrid server (see zBX and Unified Resource Manager) whose traditional mainframe product component designations are currently z1xx where z1 = 'generation 1' and 'xx' = the number of 'cores' on the machine. z196 has 96 cores; z114 has 14 cores. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: SV: GO TO cobol
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul Gilmartin Skickat: den 16 april 2012 16:33 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: GO TO cobol On Mon, 16 Apr 2012 15:42:12 +0200, Thomas Berg wrote: Rexx is a nightmare here. The LEAVE statement, even with a specified target, won't exit a (nest of) procedure(s). The SIGNAL statement trashes the DO nesting at the target level. Shame on Rexx. I can see that as a feature. ;) That prohibits some obfuscate like coding. As it stands, the only way to exit a nest of procedures is to set a flag and RETURN, and test that flag and RETURN after each intervening cal; hardly unobfuscated. I'd be delighted to be able to code, instead DO I =1 DO J = 1 DO K= 1 CALL P1 ... END K END J END I P1: CALL P2 P2: PROCEDURE EXPOSE J LEAVE J Ok, I can see logic in this. Although it makes the code somewhat harder to understand as You have to check the called procedures for those leave's if You want to understand the loops. An existing alternative would perhaps be RETURNing LEAVE J and: DO I =1 DO J = 1 DO K= 1 CALL P1 IF RESULT = 'LEAVE J' THEN LEAVE J ... END K END J END I Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Origins of numeric assignation of z196 z114
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S. Skickat: den 16 april 2012 16:42 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Origins of numeric assignation of z196 z114 W dniu 2012-04-16 16:33, Alvaro Guirao Lopez pisze: I have seeked but found nothing about this, why the new servers have been named z196 z114 and not Z11 EC Z11 BC? Why not z11? I don't know. Why 196 and 114? I heard about it: 1xx means FIRST generation (of what? naming convention?) 96 means number of processors inside. Note, you can buy only 80 of them, but it really contains 96 processors, inlcuidng SAPs and spares. 14 is for M10 model (4 are for spares and SAPs). BTW: I really can't understand marketing names like z196, TS1140, or DS8000. Why don't they use names like Jaguar (ok, it's partially used), MAGSTAR, T-REX, MtBlanc or Cindy Crawford? Last, bit not least: Athlon, or Pentium sounds much better than CMOS 11S. -- Radoslaw Skorupka Lodz, Poland I would then suggest names more like: zEUS, HERA, HERMES, GILGAMESH, etc. :) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Mon, 16 Apr 2012 09:30:47 -0500 Matthew Stitt mathwst...@bellsouth.net wrote: :This topic I cannot resist... Uggg... :Having learned COBOL in the mid 70's, the instructor taught that PERFORM was to be used only in situations where you wanted :to do a certain routine at several locations in the program. The teaching was also about straight line programming. Flow :Charts were also part of the curriculum. :Having said that, I still use GO TO extensively, and have not kept up with the modern programming extensions and constructs. :I've had many instances in my career where a structured program has been straight lined with extremely dramatic performance :results. Mostly I believe that knowing Assembler language and how the COBOL compiler would generate the assembler code version :of the program provided the reasons for my coding techniques. I would write the program as close to what the assembler code :would be as possible. This would usually provide some great performance at run time (and at compile time). :One example (out of several) was a program which normally took 4-6 hours to do its magic. When I re-wrote it due to the necessity :of adding more functionality, I went ahead and straight lined it according to the logic of what the program was supposed to do. :When the re-write was finished, the new program took 20 minutes to run the first time it was in production. I have several other :examples with these type of results. The elimination of GOTOs was to save people time at the cost of CPU time. Obviously, if a procedure was called from several points ALTER GOTO would generate fewer instructions than perform. But with GOTOless programming the logic is easier to read. There is no question about how you got somewhere. :Also, CICS used to treat the HANDLE CONDITION API as a GO TO, not a perform. Went to the Well in the early-mid 80's over that :one with a bunch of certain whiz-kids who were trained under the good doctors premises. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: SV: GO TO cobol
On Mon, 16 Apr 2012 16:51:27 +0200, Thomas Berg wrote: DO I =1 DO J = 1 DO K= 1 CALL P1 ... END K END J END I P1: CALL P2 P2: PROCEDURE EXPOSE J LEAVE J Ok, I can see logic in this. Although it makes the code somewhat harder to understand as You have to check the called procedures for those leave's if You want to understand the loops. An existing alternative would perhaps be RETURNing LEAVE J and: DO I =1 DO J = 1 DO K= 1 CALL P1 IF RESULT = 'LEAVE J' THEN LEAVE J ... END K END J END I Again, if P1 were to do any processing after the call to P2 P1 would need to make the same test. This is just a form or set-a-flag-and-test-after-each-call. It's a trivial exercise to convert any tangle of GOTOs to a DO containing a SELECT with no gain in legibility or in reliability. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
zfs fails to start
Has anyone ever had the problem of zfs not starting? No messages in the log; can't issue any queries, etc. because OMVS is not up - it's waiting on ZFS! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Embrace functional programming and eschew the historic procedural paradigm! You have nothing to lose but your chains! And maybe your mind. There is no GOTO in any pure functional language that I've read up on (basically Haskell and Erlang). Ah, imagine the joys of writing CICS code in LISP (Lots of Insipid, Silly Parentheses). John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: zfs fails to start
I've had problems at IPL due to the RESOLVER address space not starting. I don't remember the ZFS started task failing. On my system, I can still bring up NET and TSO, so I can look in the z/OS SYSLOG. If you have an MAS, can you look at the failing system's SYSLOG? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Betsy Jeffery Sent: Monday, April 16, 2012 10:06 AM To: IBM-MAIN@bama.ua.edu Subject: zfs fails to start Has anyone ever had the problem of zfs not starting? No messages in the log; can't issue any queries, etc. because OMVS is not up - it's waiting on ZFS! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: zfs fails to start
You might want to put a jobcard in SYS1.STCJOBS so that you can look at the JOBLOG. You just create a member called ZFS. //ZFSJOB (acctcode),TIME=NOLIMIT,MSGCLASS=H /*ROUTE PRINT LOCAL //ZFS EXEC ZFS -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Betsy Jeffery Sent: Monday, April 16, 2012 11:06 AM To: IBM-MAIN@bama.ua.edu Subject: zfs fails to start Has anyone ever had the problem of zfs not starting? No messages in the log; can't issue any queries, etc. because OMVS is not up - it's waiting on ZFS! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: zfs fails to start
Syslog has no zfs releated messages at all! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: zfs fails to start
Only a guess, but If you didn't shutdown cleanly, OMVS can take a long time to come up while it cleans up each filesystem. How long did you wait to decide there was a problem? Otherwise, did something get messed up in IEASYSxx? _ Dave Jousma Assistant Vice President, Mainframe Services 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@bama.ua.edu] On Behalf Of Betsy Jeffery Sent: Monday, April 16, 2012 11:06 AM To: IBM-MAIN@bama.ua.edu Subject: zfs fails to start Has anyone ever had the problem of zfs not starting? No messages in the log; can't issue any queries, etc. because OMVS is not up - it's waiting on ZFS! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Mon, 2012-04-16 at 11:08 -0400, McKown, John wrote: Ah, imagine the joys of writing CICS code in LISP (Lots of Insipid, Silly Parentheses). There are more parentheses in Java code than equivalent Clojure. Just sayin'. -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Origins of numeric assignation of z196 z114
Sorry about the title of the post where I said 'assignation' I must say 'assigment'. Thanks to those who correct my BIG mistake (apart from my love to mainframe servers and our 'assignation') 2012/4/16 Thomas Berg thomas.b...@swedbank.se -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S. Skickat: den 16 april 2012 16:42 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Origins of numeric assignation of z196 z114 W dniu 2012-04-16 16:33, Alvaro Guirao Lopez pisze: I have seeked but found nothing about this, why the new servers have been named z196 z114 and not Z11 EC Z11 BC? Why not z11? I don't know. Why 196 and 114? I heard about it: 1xx means FIRST generation (of what? naming convention?) 96 means number of processors inside. Note, you can buy only 80 of them, but it really contains 96 processors, inlcuidng SAPs and spares. 14 is for M10 model (4 are for spares and SAPs). BTW: I really can't understand marketing names like z196, TS1140, or DS8000. Why don't they use names like Jaguar (ok, it's partially used), MAGSTAR, T-REX, MtBlanc or Cindy Crawford? Last, bit not least: Athlon, or Pentium sounds much better than CMOS 11S. -- Radoslaw Skorupka Lodz, Poland I would then suggest names more like: zEUS, HERA, HERMES, GILGAMESH, etc. :) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Un saludo. Álvaro Guirao -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: zfs fails to start
Thanks all. I found (I think) the culprit. The BPXPRMxx SYSPLEX parm had been changed to 'YES'. I reset it to 'NO' (we are a monoplex) and ZFS initialized. My guess (and I emphasize guess) would be that since some of the zfs files are copied from another LPAR they would have the other LPAR's system id. Sysplex yes might have caused it to wait/look for the other system. Each LPAR image is standalone. Regards, Betsy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: zfs fails to start
Yeah, that could have been it. I believe it waits something like 1 minute, and then continues. If your ZFS shutdown wasn't clean, it may have also been checking each ZFS filesystem, which can take a lot of time if you have a lot of ZFS filesystems. You'd see messages on the SYSLOG for this though. I've had issues in the past (not quite had time to find out why) with Resolver starting up too soon - I have to cancel it, which then causes OMVS to spring into life and finish initialising. D OMVS,A=ALL can be useful to see what is going on. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
GO TO cobol
Suppose that I wish to do something to each of the elements of an assembly-time array in turn. In the macro language of the HLASM I must write something like |ne seta n'array |i seta 0 |.traverse_loop anop |i seta i+1 |elements_exhausted setb (i gt ne) | aif (elements_exhausted).traverse_lend | . . . process array(i) | ago.traverse_loop |.traverse_lend anop In other languages I can write functional equivalents more compactly. In all of them I can do this of anything else well or very badly indeed. Positive, chiefly one-on-one, mentoring focused on how to code well can be very helpful. Prohibitions cannot. They are always and everywhere unwise. They never ensure that code written using some notionally virtuous subset of a language will have any positive merit. It used to be thought that all would be well with the world when the last king had been strangled. We know better now, but we continue to seek authoritarian, Orwellian solutions to the problem of programming quality. Our world will not be an improved one when the last explicit GOTO has been excised from the last routine still in use somewhere. Bad code and good code reflect the qualities of mind, training, and experience of the programmers who write them; there are no shortcuts available for producing the good kind. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
The branch execution logic in modern (s/360 or newer. YES s/360 circa 1963) are among the most efficient in the processor. That still has not changed. Forget anyone ever told you that GO TO increases CPU overhead. snip .. GO TO was made a pariah by an article by Edgar Dijkstra. http://en.wikipedia.org/wiki/Considered_harmful And, of course, management went stupid (again) and came up with you cannot use the GOTO in any code at all. Which actually makes some COBOL more complicated due to the requirement of nesting IF statements within IF statements. /snip Just as in many other things, a good idea can be taken to an illogical extreme or out of context. In addition to avoiding GO TO's, Dykstra also proposed limiting each module to 1 page or less of code, that being the upper limit of what could be proven to be correct code. ( I'll bet management forgot about that one!). BTW, I agree w/Dykstra. Maintaining a structured program is far easier than spaghetti code. However, one page of code is a very small routine and will result in excessive overhead due to all of the module calls. (BTDTGTTS). I haven't re-read Dykstra in many years, but I believe that he may have left some loopholes. All of that being said, sometimes a plain old GO TO is far easier to decipher that if/then/else nested ad nauseum. As with most things in this business, it depends! Just my $0.02 (USD) worth. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/16/2012 12:26 PM, John Gilmore wrote: Suppose that I wish to do something to each of the elements of an assembly-time array in turn. In the macro language of the HLASM I must write something like |ne seta n'array |i seta 0 |.traverse_loop anop |i setai+1 |elements_exhausted setb (i gtne) | aif (elements_exhausted).traverse_lend | . . .processarray(i) | ago.traverse_loop |.traverse_lend anop Must you? g In this case I would prefer: .* i seta0 *default* .trvloop aif(i ge n'array).trvend i setai+1 . . .processarray(i) ago .trvloop .trvend anop, That's six statements instead of nine. I was raised in the era of six (ForTran) and eight character variables, and find those easier to read. I'd use ne only for larger array sizes; for small ones the savings are not noticeable. Whether or not code is aesthetically pleasing is very much a matter of nurture. With effective comments, the structure of code isn't all that critical, and discussions of GOTO versus GOTO-less programming are about as useful as religious arguments. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
If we're going to talk about these issues it will be useful to avoid carelessness. There may well be or have been an Edgar Dijkstra, but if so he has been silent about GOTOs. The Dijkstra of interest here was Edsger W. Dijkstra (1930-2002). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS every two years (Official announcment)
Yup - absolutely agree with Mary Anne. Base FTP has been disabled in this shop for years on the Mainframe. Only FTPS is accepted. Outgoing FTP has to be justified to all and sundry why we cannot use a secure method. Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Art Gutowski Sent: Friday, April 13, 2012 5:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS every two years (Official announcment) On Thu, 12 Apr 2012 10:40:30 -0500, Mary Anne Matyaz maryanne4...@gmail.com wrote: In the fourth quarter of 2012, IBM plans to make secure delivery via FTP using Secure Sockets Layer (FTPS) an option for Internet delivery of ServerPac, CBPDO, SystemPac(r), FunctionPac, ProductPac(r), and Internet delivery of PTFs ordered using ShopzSeries and the SMP/E RECEIVE ORDER command. [...] In the fourth quarter of 2013, IBM plans to require the use of FTPS for direct downloads to z/OS systems. Download Director, an alternative download method you can use to download packages to a workstation and transfer them to z/OS later, is not affected by this change and is planned to remain available. This is very good news. Curious. How so? Art, we don't need to go through explaining why we're not using FTP, getting a waiver for using it, etc with the isso's and auditors, every time our lpars are scanned. I see. Anyone else share in Mary Anne's sentiment? In other words, is FTPS (or SFTP?) as much a requirement/priority notwithstanding the impending ShopzSeries / RECEIVE ORDER requirement? If so, and you can respond, please drop me a line off-list. Nothing detailed... just curious. Thanks, Art Gutowski -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
I agree that there is more than one good way to do everything. Gerhard's code is fine. For a loop where it is invariant, I should prefer to save and reuse n'array; and I prefer the boolean assignment statement and AIF |elements_exhausted setb (i gt ne) | aif (elements_exhausted).traversal_lend to his single statement. I even object, but not much, to |.trvend anop , I supply the missing-operand comma for anop, mexit, etc., only when I want to place a comment after it. These, however, are details that are important only as they contribute to coherence. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
A dirty myth about COBOL is the belief the THRU is required and that SECTIONs are a good idea. Unless specifically required by SORT or something, I never used either. It has been 20+ years since I did much COBOL. Haven't had the pleasure of the newer constructs. As to the OP's belief about performance, structured programming has never been about performance, it is about understandability. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, April 16, 2012 5:28 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GO TO cobol Our use of GO TO is generally restricted to usage such as: PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. Otherwise, to avoid the GO TO, we'd need to do: I-P. READ FILE AT END SET CONDITION TO TRUE END-READ IF NOT CONDITION THEN ... END-IF. I-P-EXIT. EXIT. Which I consider to be worse than the exit, so far as comprehension is concerned. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, April 16, 2012 5:40 AM To: IBM-MAIN@bama.ua.edu Subject: SV: GO TO cobol An alternative is to have e g an 88-type LEAVE item that is checked for every code-block including all iterations and selections. (You set leave to true when wanting to do a leave type jump.) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Edward Jaffe Skickat: den 16 april 2012 08:15 Till: IBM-MAIN@bama.ua.edu Ämne: Re: GO TO cobol On 4/15/2012 10:31 PM, Wayne Bickerdike wrote: For devotees of Jackson Structured programming, the GOTO is a must for POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO. The problem with GOTO is that the suitability of the target branch location is not enforced by the compiler according to any structured discipline. Premature terminations (posit/quit/admit) can almost always be handled with LEAVE-type statements or immediate return from a subroutine. Some languages have SIGNAL, EXIT, etc. which can help provide structured premature termination for larger routines without resorting to the dreaded GOTO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ADR938E - PROBLEM WITH FASTREPLICATION
Is that all you got? The messages manual says that there should have been a reason code with the ADR918I message. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Saturday, April 14, 2012 6:18 PM To: IBM-MAIN@bama.ua.edu Subject: ADR938E - PROBLEM WITH FASTREPLICATION G'Day, I am trying to figure out this problem. I checked the error message but I was unable to figure out what I should do or why the problem occurred. ADR918I (052)-DDTFP(01), FAST REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1 ADR938E (052)-DDTFP(01), FASTREPLICATION(REQUIRED) WAS SPECIFIED BUT FAST REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1 ADR006I (052)-STEND(02), 2012.105 02:34:11 EXECUTION ENDS Below is my jcl: //STEP1EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440 //SYSPRINT DD SYSOUT=* //SYSIN DD * COPY FULL INDYNAM(RXTRS1) OUTDYNAM(@@883C) ALLE ALLD(*) - FASTREPLICATION(REQUIRED) FCNOCOPY DUMPCONDITIONING ADMIN PURGE Any suggestions? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 4/16/2012 1:35 PM, John Gilmore wrote: I even object, but not much, to |.trvend anop , I supply the missing-operand comma for anop, mexit, etc., only when I want to place a comment after it. These, however, are details that are important only as they contribute to coherence. The comma is a result of a personal(?) idiosyncrasy. Since the late sixties, I have used columns 65-71 to indicate code changes (author,date); this practice permits detailed identification of modifications that may not be as obvious when provided as paragraph or program comments. Omitting the comma results in assembly errors. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: brand new CF LPAR
When you define your CFRM policy using IXCMIAPU you can point to your newly created CFRM CDS as Such: DATA TYPE(CFRM) REPORT(YES) DSN(Your newly created CFRM CDS name) DEFINE POLICY NAME(policyname here) REPLACE(YES) Etc.. That populates the newly created CFRM CDS with the policy(ies) that point to the new coupling facilities. In your COUPLExx member you can simply specify the new CFRM data sets as well as the POLICY you want to use by specifying CFRMPOL() where is your new policy name as specified by the IXCMIAPU job. The above is an example of only how to populate an inactive CFRM dataset. The DSN keyword on the DATA statement is what you need. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Munif Sadek Sent: Monday, April 16, 2012 09:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: brand new CF LPAR Just to add to my previous request, I have to define new coupling facility datasets to enbale support for newer protocols and do not know **yet** how to pouplate them with our exisitng sysplex policies.. May I IPL an LPAR (z/OS 1.13) with the new coupling facility datasets and then definine activate (old) policies.. will it work?.. thanks again.. Munif -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On 16 April 2012 13:35, John Gilmore johnwgilmore0...@gmail.com wrote: [...] I even object, but not much, to |.trvend anop , I supply the missing-operand comma for anop, mexit, etc., only when I want to place a comment after it. I've found that the risk of later copying (by me or someone else) of such a code segment, and then putting in update markers toward the right of the input field - typically in the mid to high 60s column positions - makes it worth while to always put in the comma. There are a very few IBM macros, but to my knowledge no assembler statements, that have trouble with this, and they must be handled individually. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 0C4 pic 4
On Sun, 15 Apr 2012 22:16:39 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: Exactly. Why overcomplicate? One reason, which was mentioned in another recent thread, is that in general key zero should be avoided if possible to lessen the risk of accidentally clobbering something. Not that the code as shown has much potential to destroy anything other than the alleged ECB. On Sun, 15 Apr 2012 14:48:20 -0400, Micheal Butz michealb...@optonline.net wrote: Being in PSW Key 0 is good for any storage 0 16 Key 16 storage? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ADR938E - PROBLEM WITH FASTREPLICATION
Are the two volumes RXTRS1 and @@883C part of the same SFI (the same DASD box)? If not, then FlashCopy cannot be used for the requested operation. Gerhard Am 16.04.2012 20:10, schrieb Pommier, Rex R.: Is that all you got? The messages manual says that there should have been a reason code with the ADR918I message. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Saturday, April 14, 2012 6:18 PM To: IBM-MAIN@bama.ua.edu Subject: ADR938E - PROBLEM WITH FASTREPLICATION G'Day, I am trying to figure out this problem. I checked the error message but I was unable to figure out what I should do or why the problem occurred. ADR918I (052)-DDTFP(01), FAST REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1 ADR938E (052)-DDTFP(01), FASTREPLICATION(REQUIRED) WAS SPECIFIED BUT FAST REPLICATION COULD NOT BE USED FOR VOLUME RXTRS1 ADR006I (052)-STEND(02), 2012.105 02:34:11 EXECUTION ENDS Below is my jcl: //STEP1EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440 //SYSPRINT DD SYSOUT=* //SYSIN DD * COPY FULL INDYNAM(RXTRS1) OUTDYNAM(@@883C) ALLE ALLD(*) - FASTREPLICATION(REQUIRED) FCNOCOPY DUMPCONDITIONING ADMIN PURGE Any suggestions? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Tue, 17 Apr 2012 02:06:31 +1200, in bit.listserv.ibm-main Peter Dashwood wrote: I'll put most of my comments at the end and have included the postings by Nomen Nescio and Peter Dashwood of New Zealand so that they go to the listserv as well as the newsgroup. Peter has been in the field for many years and has mainframe experience including CICS. I disagree with him in some areas but he is an expert in COBOL so this is a disagreement among those who know data processing and not one where people are quoting airline magazines. My comments apply mainly to IBM z series COBOL because that is the one I know most and the only one in current production that I have seen the code generation for since the RCA 301 bit the dust decades ago. See below Nomen Nescio wrote: justmainfra...@gmail.com (Jake anderson) wrote: Hi All, Apology for asking a basic question and Being Ignorant. We know that GO TO statments are a big NO in many production sites and one of the reason being it monopolizes the entire CPU. Nothing you can do from a COBOL program can monopolize the CPU or even the OS in the z/OS environment. Are there any documentation explaining about the GO TO statements which clearly describes how it effects the System CPU and performances ? Avoiding GO TO is a religious belief and it is wrong. It is not rooted in performance or other real considerations. GO TO is often the best way to code in COBOL. You should not write C like a COBOL programmer but you should also not write COBOL like a C programmer. People should code idiomatically and not try to make everything look like Pascal, C, etc. And let's be honest, by the time your program is compiled all those structured verbs are really nothing more than piles of GO TOs, usually 4 times as many as you would have generated if you simply coded GO TO in the first place because of the extra loops you have to code to be able to say you avoided GO TO. Blind obesance to Dijkstra's idiotic structured programming tenets will get you nowhere in the real world except long wall clock times. Do you really want to code according to the principles of a guy who never delivered anything in his life but reams of paper and diatribes about things he wasn't even involved in? He and his pals did more damage to commercial programming than any other single thing I can think of, maybe with the exception of the H1B program. The alternative to GO TO in COBOL is PERFORM which is much more costly than GO TO and most often contributes to poor program design by making everything a loop. Yes, most commercial processing is a big loop, but it is not necessarily concentric circles of loops. Structured programming assumes everything is algorithmic and consists of concentric loops. This is simply not a valid assumption for commercial COBOL code. Use the LIST option and compare the object code from a small sample program you write in two different ways, one using GO TO sensibly and one using PERFORM and avoiding GO TO entirely. Consider how much overhead those extra 5 instructions will make in a 5 or 10 million record batch run. Then consider how many more loops you had to code to do things you should have handled with GO TO like checking return codes from called routines, VSAM file status, etc. A good program is a good program and branching is part of life. If you can't write good COBOL with GO TO and PERFORM (very sparingly) then yes, you should focus on academic arguments and FUD to cover up the fact you have no idea what the compiler or OS are doing (see your opening question). If being a mindless lemming or meme is considered a virtue where you work and it wouldn't be the first place that was true, by all means avoid GO TO. It is often much safer to do the wrong thing that is now a standard than to do the right thing that isn't popular with the know-nothing generation. I really enjoyed this and it made me smile. Very well written. It made me remember (and God knows, I've been trying to forget it for many years now... :-)) a seminar in London I attended where Michael Jackson (he of Jackson Structured Programming fame, sadly, not the pop star (which would have been much more entertaining and probably cost less...)) vehemently evangelized the power of GOTO-less programming. The only trouble was that anyone who looked at the tangled mess generated by his system would simply be bewildered by it. I raised this point with him and he said it didn't matter because that was generated code and nobody would be maintaining it. Draw your own conclusions. (I can tell you that the code generated from my own generators is not a tangled mess and, while it is complex in places, I'm not ashamed to show it to people...AND, they CAN alter it if they want to (although I don't recommend that)) GO TO is generally one of (if not THE) fastest executing instructions in the set on most platforms. But the issue is not about efficiency, it is about
Re: GO TO cobol
On 16 Apr 2012 05:45:21 -0700, in bit.listserv.ibm-main you wrote: What??? monopolizes the CPU??? GO TO was made a pariah by an article by Edgar Dijkstra. http://en.wikipedia.org/wiki/Considered_harmful And, of course, management went stupid (again) and came up with you cannot use the GOTO in any code at all. Which actually makes some COBOL more complicated due to the requirement of nesting IF statements within IF statements. And before the END-IF, that could be very complicated. I've see old code like: IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ... IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ELSE ... . Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in it. You are thinking of the 1974 standard which doesn't have IF ... END-IF. Nesting becomes easier with the 1985 standard and when the IF statement nesting becomes too complex you can move an IF ... END-IF pair into a separate paragraph with little or no performance penalty due to code movement and the simplified PERFORM code if you eliminate GO TO statements. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS every two years (Official announcment)
On Mon, 16 Apr 2012 11:34:55 -0600, Jerry Whitteridge wrote: Yup - absolutely agree with Mary Anne. Base FTP has been disabled in this shop for years on the Mainframe. Only FTPS is accepted. Outgoing FTP has to be justified to all and sundry why we cannot use a secure method. I believe my employer requires a proxy for all outgoing connections: HTTP, HTTPS, FTP, ... (worse for incoming). I don't know about FTPS or SFTP (variant of ssh). Can someone suggest a publicly accessible site(s) I can experiment with? --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Origins of numeric assignation of z196 z114
W dniu 2012-04-16 16:54, Thomas Berg pisze: -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S. Skickat: den 16 april 2012 16:42 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Origins of numeric assignation of z196 z114 W dniu 2012-04-16 16:33, Alvaro Guirao Lopez pisze: I have seeked but found nothing about this, why the new servers have been named z196 z114 and not Z11 EC Z11 BC? Why not z11? I don't know. Why 196 and 114? I heard about it: 1xx means FIRST generation (of what? naming convention?) 96 means number of processors inside. Note, you can buy only 80 of them, but it really contains 96 processors, inlcuidng SAPs and spares. 14 is for M10 model (4 are for spares and SAPs). BTW: I really can't understand marketing names like z196, TS1140, or DS8000. Why don't they use names like Jaguar (ok, it's partially used), MAGSTAR, T-REX, MtBlanc or Cindy Crawford? Last, bit not least: Athlon, or Pentium sounds much better than CMOS 11S. -- Radoslaw Skorupka Lodz, Poland I would then suggest names more like: zEUS, HERA, HERMES, GILGAMESH, etc. :) Hera? What are you talking about??? Here sounds like a mother. What sounds more attractive: Hera or Jennifer Lopez? Or maybe you like z/OS-BX-8167 ??? Well, sexy name do have different meanings, very different... -- 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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
IBM Cobol provides the structure format: I-P. READ FILE AT END * the at end stuff NOT AT END * the not at end stuff END-READ IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 08:28:10 AM: From: McKown, John john.mck...@healthmarkets.com PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: brand new CF LPAR
I've lost track of the original postings in this thread, but I have this suggestion: never IPL an entire sysplex into a new XCF-anything unless you absolutely have no other choice. It's always preferable to move dynamically into a new XCF-something with at least one member running on the old one. It's (almost always?) possible to define a new thing in advance and migrate to it via SETXCF commands. This may mean defining a currently nonexistent resource ahead of time. XCF will tolerate a new thing it can't find yet as well as later tolerate an old thing it no longer find. Just clean up definitions at the very end to reflect the new environment. In the case of control data sets, create new ones with modern attributes, then SETXCF-migrate to them. By the time an actual hardware replacement occurs, new things should already be defined to the existing sysplex. The danger in cold starting with new components is that there's no way to test the process in advance, and falling back to a known environment may be complicated beyond reasonable resolution. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Jihad Kawkabani jihad_k_kawkab...@progressive.com To: IBM-MAIN@bama.ua.edu Date: 04/16/2012 12:05 PM Subject:Re: brand new CF LPAR Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu When you define your CFRM policy using IXCMIAPU you can point to your newly created CFRM CDS as Such: DATA TYPE(CFRM) REPORT(YES) DSN(Your newly created CFRM CDS name) DEFINE POLICY NAME(policyname here) REPLACE(YES) Etc.. That populates the newly created CFRM CDS with the policy(ies) that point to the new coupling facilities. In your COUPLExx member you can simply specify the new CFRM data sets as well as the POLICY you want to use by specifying CFRMPOL() where is your new policy name as specified by the IXCMIAPU job. The above is an example of only how to populate an inactive CFRM dataset. The DSN keyword on the DATA statement is what you need. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Munif Sadek Sent: Monday, April 16, 2012 09:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: brand new CF LPAR Just to add to my previous request, I have to define new coupling facility datasets to enbale support for newer protocols and do not know **yet** how to pouplate them with our exisitng sysplex policies.. May I IPL an LPAR (z/OS 1.13) with the new coupling facility datasets and then definine activate (old) policies.. will it work?.. thanks again.. Munif -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Use of NEXT SENTENCE is as dangerous as GO TO. Try using CONTINUE. The former takes you to the next period; the latter takes you to the end of the current conditional. One missed period and To replace nested IFs, try using EVALUATE - the most powerful case statement in any language (except structured assembler) according to a friend who does distributed apps. IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 08:42:05 AM: From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@bama.ua.edu, Date: 04/16/2012 08:46 AM Subject: Re: GO TO cobol Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu What??? monopolizes the CPU??? GO TO was made a pariah by an article by Edgar Dijkstra. http://en.wikipedia.org/wiki/Considered_harmful And, of course, management went stupid (again) and came up with you cannot use the GOTO in any code at all. Which actually makes some COBOL more complicated due to the requirement of nesting IF statements within IF statements. And before the END-IF, that could be very complicated. I've see old code like: IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ... IF ... THEN ... IF ... THEN ... ELSE NEXT SENTENCE ELSE ... . Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in it. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid- West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jake anderson Sent: Sunday, April 15, 2012 10:49 PM To: IBM-MAIN@bama.ua.edu Subject: GO TO cobol Hi All, Apology for asking a basic question and Being Ignorant. We know that GO TO statments are a big NO in many production sites and one of the reason being it monopolizes the entire CPU. Are there any documentation explaining about the GO TO statements which clearly describes how it effects the System CPU and performances ? Apology again if the question is not really sensible or else it requires more information. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Well said IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 12:00:13 AM: From: Sam Siegel s...@pscsi.net Typically GO TO statements can be avoided by having a good design. A local GO TO here and there is not so bad. The non-local GO TO statements can make long-term maintenance of a program problematic and expensive. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 10:57:47 AM: From: Binyamin Dissen bdis...@dissensoftware.com The elimination of GOTOs was to save people time at the cost of CPU time. ? Obviously, if a procedure was called from several points ALTER GOTO would generate fewer instructions than perform. The last time I looked at a PMAP, the Cobol compiler implements PERFORM exactly like an ALTERed GO TO, except that all addresses are stored in a table. But with GOTOless programming the logic is easier to read. There is no question about how you got somewhere. agreed - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 01:59:26 PM: From: Gibney, Dave gib...@wsu.edu A dirty myth about COBOL is the belief the THRU is required and that SECTIONs are a good idea. Unless specifically required by SORT or something, I never used either. It has been 20+ years since I did much COBOL. Haven't had the pleasure of the newer constructs. THROUGH is just stupid. But I have used sections. I think of it as a religious preference. As to the OP's belief about performance, structured programming has never been about performance, it is about understandability. yes and maintainability - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Coding standards here are ancient. There is the all out-of-line PERFORMs must be of the form PERFORM name THRU name-EXIT ... END-PERFORM and all paragraphs must be followed by be followed by a name-EXIT. paragraph with the single EXIT verb in it. Or at least, that is how every out-of-line PERFORM verbs are coded. Ancient, like most of our code. If code is updated, it is not modernized. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Kirk Talman Sent: Monday, April 16, 2012 3:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GO TO cobol IBM Cobol provides the structure format: I-P. READ FILE AT END * the at end stuff NOT AT END * the not at end stuff END-READ IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 04/16/2012 08:28:10 AM: From: McKown, John john.mck...@healthmarkets.com PERFORM I-P THRU I-P-EXIT UNTIL CONDITION. I-P. READ FILE AT END SET CONDITION TO TRUE GO TO I-P-EXIT END-READ ... I-P-EXIT. EXIT. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
I have many years' experience writing COBOL code and have used GO TO and THRU only as a means of exiting a paragraph. I frequently code paragraph subroutines that perform a series of related edits, and would use them like this: Perform 2000-Validate-Input thru 2000-exit. *test resultant switch settings here... 2000-Validate-Input. If some-test-here-failed Set indicator-switch to true Go to 2000-exit End-if. If some-other-test-fails Set indicator-different-switch to true Go to 2000-exit End-if. * Blah, blah, blah * When you get here, all tests are good and action can be taken 2000-exit. Exit. The THRU clause is only to support an exit paragraph ability. Because I follow some rules with this technique, it has never caused me a problem. The rules? They are simple: - Only go to the exit point for the current paragraph. I never span. This means that the go to statements are always pointed downward - the same way my perform statements always point. - I verify that this rule is observed by F GO WORD in ISPF (with comments excluded). Each time I find a GO, I then look for P'-' 8 to ensure that the exit paragraph is the next paragraph. I, too, believe that thru and section is a preference that can't be persuaded in most people. I personally hate to use sections and view them as evil. When forced to use sections, such as when performing an internal sort, I just code unreferenced dummy sections around my input and output sections. It would be nice if an exit paragraph statement existed. When it does, I'll never need a THRU or GO TO again - and good riddance! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Use of NEXT SENTENCE is as dangerous as GO TO. Try using CONTINUE. The former takes you to the next period; the latter takes you to the end of the current conditional. One missed period and -- I've seen many programs without a single period. How they work is beyond my comprehension. Of course, a paragraph name does imply a period. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Impossible in my example case. The NEXT SENTENCE is used like an EXIT PARAGRAPH
verb because the entire paragraph is a single sentence. This is needed to
remove the requirement for a GOTO to a name-EXIT. paragraph. It was to
highlight how awkard the COBOL code becomes if the GOTO is totally eliminated.
The awkardness is only slightly reduced if people use the END-verb, which I
highly recommend for all verbs which have it. It specifically delimits the
scope of the verb. Much like I alway use braces ( {} ) if when not absolutely
necessary.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets(r) is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The
MEGA Life and Health Insurance Company.SM
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Matthew Stitt
Sent: Monday, April 16, 2012 4:29 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: GO TO cobol
Use of NEXT SENTENCE is as dangerous as GO TO. Try using CONTINUE.
The former takes you to the next period; the latter takes
you to the end
of the current conditional. One missed period and
--
I've seen many programs without a single period. How they
work is beyond
my comprehension. Of course, a paragraph name does imply a period.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
If some-test-here-failed Set indicator-switch to true Go to 2000-exit End-if. If some-other-test-fails Set indicator-different-switch to true Go to 2000-exit End-if. --- You could have the exact same result by placing a period after the 2000-exit. Then the End-if is not needed. gd,r -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 0C4 pic 4
On Sun, Apr 15, 2012 at 12:29 PM, Micheal Butz michealb...@optonline.netwrote: I am getting S0C4 04 within a wait which leads me to believe that the storage key of the ECB storage key is not the same as the PSW STORAGE KEY 8- 11. Does the following code make sense to resolve this address TESTAUTH FCTN=1 TEST APF AUTORIZATION LTR R15,R5 CHECK R15 BNZ NAPFSYSNDXNOT APF MODESET MODE=SUP,KEY=NZERO TURN ON BIT 15 IN PSW LAR0,REPLY_ECB GET ECB ADDRESS IVSK R1,R0 GET STORAGE KEY MODESET KEYREG=R1,SAVEKEY=OLDKEY SET STORAGE KEY IN PSW WAIT=REPLY_ECB MODESET MODE=PROB,KEY=NZERO back to current TCB key I'm sorry if I seem to be picking on you but there are so many ways that this is wrong. You don't need to be in supervisor state to issue the IVSK instruction, but that's the least of your worries. Overtly changing to key zero just guarantees that the OS is going to vaporize 4 bytes at what ever location you specify - even if it isn't really an ECB at all. In other words, it is another (data) integrity hole. You should never be using an ECB that is in another key than your current PSW key. The system gives you a way to do it, but it assumes you know what you're doing. The only real exception to this is the stop/modify communications ECB for your your address space. The OS has a special case code path that lets you wait on that. There might be other exceptions when you know what you're doing, but this isn't one of them. So to reiterate my earlier advice, you're going in the wrong direction. If you're going to write privileged code that runs entirely within a single APF authorized address space you can do more or less whatever you want. However, if your code might ever get control in a non-APF environment, or you try to share code/data between address spaces, you have a steep hill to climb to avoid compromising integrity. Sorry, them's just the facts. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Anybody use the cob2 command on a UNIX shell to compile COBOL?
On 4/16/2012 3:26 PM, McKown, John wrote: If so, have you figured out how to specify a PDS as an include or copybooksource? The documentation for this command basically stinks. There is an -I switch. But it apparently only accepts UNIX path specifications. The ld command (binder) accepts a PDS name via -L //pds.name. The as command (HLASM) and C compilers accept a -I //pds.name. I may end up writing my own version of the cob2 command, if I really decide that I want to compile COBOL from the UNIX shell. I'll likely model it after the as command. Yes. I discuss this command in our course Developing Applications for z/OS UNIX. But you're right, the doc is very poor. The assumption seems to be that copy books must be in HFS directories and my experiments produce error messages that would support that. In a way, that's too bad. OTOH, I, too, was assuming that copy books would reside in HFS directories so I had never tried to access copy books as members of a PDS before. You would think that if you used the classic clue that a library was a PDS/E, the compiler could figure it out. Maybe: export SYSLIB=//'SCOMSTO.U520.LIBRARY' which I tried, and the message from the compile comes back: LineID Message code Library phase message text 24 IGYLI0049-S The COPY library SCOMSTO.U520.LIBRARY/APODEFS was not found. Skipped to the period terminating the COPY statement. so it was pretty clearly expecting (nay: requiring) a z/OS UNIX file, not a PDS. I'm copying this over to ibm-main, too, as Tom Ross occasionally follows that group so maybe he will chime in with some info. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For MVS-OE subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO MVS-OE -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Mon, 16 Apr 2012 16:45:21 -0500, Matthew Stitt wrote: You could have the exact same result by placing a period after the 2000-exit. Then the End-if is not needed. gd,r I sure am glad that COBOL attained its design objective of being intelligible (intuitively? unambiguously?) to a PFC-level programmer with only an understanding of vernacular English. (Is PFC a Navy rank?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Anybody use the cob2 command on a UNIX shell to compile COBOL?
Has anyone tried (apart from Paul G) exporting the PDSE via NFS and mounting it at a z/Unix mountpoint on the same system ? That should be able to provide your path as well a classic access Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Steve Comstock Sent: Monday, April 16, 2012 3:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Anybody use the cob2 command on a UNIX shell to compile COBOL? On 4/16/2012 3:26 PM, McKown, John wrote: If so, have you figured out how to specify a PDS as an include or copybooksource? The documentation for this command basically stinks. There is an -I switch. But it apparently only accepts UNIX path specifications. The ld command (binder) accepts a PDS name via -L //pds.name. The as command (HLASM) and C compilers accept a -I //pds.name. I may end up writing my own version of the cob2 command, if I really decide that I want to compile COBOL from the UNIX shell. I'll likely model it after the as command. Yes. I discuss this command in our course Developing Applications for z/OS UNIX. But you're right, the doc is very poor. The assumption seems to be that copy books must be in HFS directories and my experiments produce error messages that would support that. In a way, that's too bad. OTOH, I, too, was assuming that copy books would reside in HFS directories so I had never tried to access copy books as members of a PDS before. You would think that if you used the classic clue that a library was a PDS/E, the compiler could figure it out. Maybe: export SYSLIB=//'SCOMSTO.U520.LIBRARY' which I tried, and the message from the compile comes back: LineID Message code Library phase message text 24 IGYLI0049-S The COPY library SCOMSTO.U520.LIBRARY/APODEFS was not found. Skipped to the period terminating the COPY statement. so it was pretty clearly expecting (nay: requiring) a z/OS UNIX file, not a PDS. I'm copying this over to ibm-main, too, as Tom Ross occasionally follows that group so maybe he will chime in with some info. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For MVS-OE subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO MVS-OE -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Anybody use the cob2 command on a UNIX shell to compile COBOL?
On Mon, 16 Apr 2012 17:29:23 -0600, Jerry Whitteridge wrote: Has anyone tried (apart from Paul G) exporting the PDSE via NFS and mounting it at a z/Unix mountpoint on the same system ? That should be able to provide your path as well a classic access We tried and failed. But we didn't try very hard because I couldn't justify expending much systems programmer resource on my largely experimental need. We have legacy data sets exported and mounted on Solaris mountpoints. We have Solaris filesystems exported and mounted on z/OS. If I need something in both places, I keep it on a Solaris server. John M. may have tried; I don't know with what degree of success. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
IEHLIST LISTVTOC inconsistency
I just ran into a situation where IEHLIST is providing different results for the same volume depending upon whether it is run from a z/OS 1.11 system or a z/OS 1.13 system. The JCL looks like this: //jobname JOB etc. //* //LISTEXEC PGM=IEHLIST //SYSPRINT DD SYSOUT=* //SYSLIB DD UNIT=3390,VOL=SER=DSKAA9,DISP=SHR //SYSINDD * LISTVTOC VOL=3390=DSKAA9 /* Under z/OS 1.11, IEHLIST lists the VTOC as expected. Under z/OS 1.13, IEHLIST issues the following message and quits: IEH106I UNAVAILABLE DEVICE TYPE OR VOLUME I.D. SPECIFIED The JCL is identical and the job is being run against the same volume in both cases. The volume is available to both systems. I haven't been able to find any relevant hits. Has anyone else seen the same symptom? -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507, gord.tom...@actionsoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEHLIST LISTVTOC inconsistency
Your JCL will fail on z/OS 1.12 as well. change name of SYSLIB DD to something else //VDSKAA9 DD UNIT=3390,VOL=SER=DSKAA9,DISP=SHR will work. While you would think SYSLIB would qualify as anyname apparently it dose not. z/OS DFSMSdfp Utilities Document Number SC26-7414-07 12.4.1.3 anyname DD Statement A DD statement must be included for each permanently mounted or mountable volume referred to in the job step. These DD statements are used to allocate devices: they are not true data definition statements. Concatenated DD statements are not allowed. Because IEHLIST modifies the internal control blocks created by device allocation DD statements, these DD statements must not include the DSNAME parameter. (All data sets are defined explicitly or implicitly by utility control statements.) The DD statement can be entered: //anyname DD UNIT=,VOLUME=SER=xx,DISP=OLD The UNIT and VOLUME=SER parameters define the device type and volume serial number without requiring that a real data set be allocated on the volume. Dale McCart Senior Systems Programmer / zSeries, z/OS Kawasaki Motors Corp., U.S.A. 9950 Jeronimo Rd. Irvine, California 92618-2084 Telephone: (949) 770-0400 extension 2316 Fax: (949) 460-5576 E-mail: dale.mcc...@kmc-usa.com Visit our website at http://www.kawasaki.com *** This Email is covered by the Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521, and is confidential, legally privileged, and exempt from disclosure. The information contained in this Email is intended only for the use of the individual or entity named above. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons other than the intended recipient is strictly prohibited. If you have received this communication in error, please notify us by replying to this Email and destroy all copies of the original message. Please note that in accordance with Kawasaki Motors Corp., U.S.A.'s signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors, omissions or damage caused by any virus transmitted by this email. The recipient should check this email and any attachments for the presence of viruses. The view and/or opinions of individuals expressed within this document do not necessarily reflect the views of the Kawasaki or it's affiliates. Please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. *** © 1966-2012 Kawasaki Motors Corp., U.S.A. From: Gord Tomlin gt.ibm.li...@actionsoftware.com To: IBM-MAIN@bama.ua.edu, Date: 04/16/2012 04:39 PM Subject:IEHLIST LISTVTOC inconsistency Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu I just ran into a situation where IEHLIST is providing different results for the same volume depending upon whether it is run from a z/OS 1.11 system or a z/OS 1.13 system. The JCL looks like this: //jobname JOB etc. //* //LISTEXEC PGM=IEHLIST //SYSPRINT DD SYSOUT=* //SYSLIB DD UNIT=3390,VOL=SER=DSKAA9,DISP=SHR //SYSINDD * LISTVTOC VOL=3390=DSKAA9 /* Under z/OS 1.11, IEHLIST lists the VTOC as expected. Under z/OS 1.13, IEHLIST issues the following message and quits: IEH106I UNAVAILABLE DEVICE TYPE OR VOLUME I.D. SPECIFIED The JCL is identical and the job is being run against the same volume in both cases. The volume is available to both systems. I haven't been able to find any relevant hits. Has anyone else seen the same symptom? -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507, gord.tom...@actionsoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEHLIST LISTVTOC inconsistency
On Mon, 16 Apr 2012 19:38:44 -0400, Gord Tomlin gt.ibm.li...@actionsoftware.com wrote: I just ran into a situation where IEHLIST is providing different results for the same volume depending upon whether it is run from a z/OS 1.11 system or a z/OS 1.13 system. The JCL looks like this: //jobname JOB etc. //* //LISTEXEC PGM=IEHLIST //SYSPRINT DD SYSOUT=* //SYSLIB DD UNIT=3390,VOL=SER=DSKAA9,DISP=SHR //SYSINDD * LISTVTOC VOL=3390=DSKAA9 /* Under z/OS 1.11, IEHLIST lists the VTOC as expected. Under z/OS 1.13, IEHLIST issues the following message and quits: IEH106I UNAVAILABLE DEVICE TYPE OR VOLUME I.D. SPECIFIED The JCL is identical and the job is being run against the same volume in both cases. The volume is available to both systems. I haven't been able to find any relevant hits. Has anyone else seen the same symptom? What does a D U,VOL=DSKAA9 show from the z/OS 1.13 system? Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEHLIST LISTVTOC inconsistency
On Mon, 16 Apr 2012 17:06:28 -0700, Dale McCart wrote: Your JCL will fail on z/OS 1.12 as well. change name of SYSLIB DD to something else //VDSKAA9 DD UNIT=3390,VOL=SER=DSKAA9,DISP=SHR will work. While you would think SYSLIB would qualify as anyname apparently it dose not. Submit a PMR. Under z/OS 1.11, IEHLIST lists the VTOC as expected. Under z/OS 1.13, IEHLIST issues the following message and quits: IEH106I UNAVAILABLE DEVICE TYPE OR VOLUME I.D. SPECIFIED Even if the doc were to be updated (as it should), the message is totally irrelevant to the syntax error. They might even fix it (they should) by removing the dependency on SYSLIB and using a generated DDNAME. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Mon, Apr 16, 2012 at 6:26 PM, Paul Gilmartin (Is PFC a Navy rank?) -- gil TLA for ARMY Private FIrst Class. http://usmilitary.about.com/od/theorderlyroom/l/blenlrank.htm Navy equivalent is a TLA SN for Seaman. Be sure not to drop the first A and replace the second A with an E. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEHLIST LISTVTOC inconsistency
On Mon, Apr 16, 2012 at 8:29 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 16 Apr 2012 17:06:28 -0700, Dale McCart wrote: Your JCL will fail on z/OS 1.12 as well. change name of SYSLIB DD to something else //VDSKAA9 DD UNIT=3390,VOL=SER=DSKAA9,DISP=SHR will work. While you would think SYSLIB would qualify as anyname apparently it dose not. Submit a PMR. Under z/OS 1.11, IEHLIST lists the VTOC as expected. Under z/OS 1.13, IEHLIST issues the following message and quits: IEH106I UNAVAILABLE DEVICE TYPE OR VOLUME I.D. SPECIFIED Even if the doc were to be updated (as it should), the message is totally irrelevant to the syntax error. They might even fix it (they should) by removing the dependency on SYSLIB and using a generated DDNAME. -- gil Actually, they probrably would document that SYSLIB DD name cannot be used to with z/OS 1.12 and above to allow for testing alternate versions of the program. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEHLIST LISTVTOC inconsistency
Stunning. That's the answer. On z/OS 1.13 (and z/OS 1.12 by your note), SYSLIB does not qualify as anyname, while on z/OS 1.11 it does. Ironically, ANYNAME qualifies as anyname on either level. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-04-16 20:06, Dale McCart wrote: Your JCL will fail on z/OS 1.12 as well. change name of SYSLIB DD to something else //VDSKAA9 DD UNIT=3390,VOL=SER=DSKAA9,DISP=SHR will work. While you would think SYSLIB would qualify as anyname apparently it dose not. z/OS DFSMSdfp Utilities Document Number SC26-7414-07 12.4.1.3 anyname DD Statement A DD statement must be included for each permanently mounted or mountable volume referred to in the job step. These DD statements are used to allocate devices: they are not true data definition statements. Concatenated DD statements are not allowed. Because IEHLIST modifies the internal control blocks created by device allocation DD statements, these DD statements must not include the DSNAME parameter. (All data sets are defined explicitly or implicitly by utility control statements.) The DD statement can be entered: //anyname DD UNIT=,VOLUME=SER=xx,DISP=OLD The UNIT and VOLUME=SER parameters define the device type and volume serial number without requiring that a real data set be allocated on the volume. Dale McCart Senior Systems Programmer / zSeries, z/OS Kawasaki Motors Corp., U.S.A. 9950 Jeronimo Rd. Irvine, California 92618-2084 Telephone: (949) 770-0400 extension 2316 Fax: (949) 460-5576 E-mail: dale.mcc...@kmc-usa.com Visit our website at http://www.kawasaki.com *** This Email is covered by the Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521, and is confidential, legally privileged, and exempt from disclosure. The information contained in this Email is intended only for the use of the individual or entity named above. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons other than the intended recipient is strictly prohibited. If you have received this communication in error, please notify us by replying to this Email and destroy all copies of the original message. Please note that in accordance with Kawasaki Motors Corp., U.S.A.'s signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors, omissions or damage caused by any virus transmitted by this email. The recipient should check this email and any attachments for the presence of viruses. The view and/or opinions of individuals expressed within this document do not necessarily reflect the views of the Kawasaki or it's affiliates. Please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. *** © 1966-2012 Kawasaki Motors Corp., U.S.A. From: Gord Tomlingt.ibm.li...@actionsoftware.com To: IBM-MAIN@bama.ua.edu, Date: 04/16/2012 04:39 PM Subject:IEHLIST LISTVTOC inconsistency Sent by:IBM Mainframe Discussion ListIBM-MAIN@bama.ua.edu I just ran into a situation where IEHLIST is providing different results for the same volume depending upon whether it is run from a z/OS 1.11 system or a z/OS 1.13 system. The JCL looks like this: //jobname JOB etc. //* //LISTEXEC PGM=IEHLIST //SYSPRINT DD SYSOUT=* //SYSLIB DD UNIT=3390,VOL=SER=DSKAA9,DISP=SHR //SYSINDD * LISTVTOC VOL=3390=DSKAA9 /* Under z/OS 1.11, IEHLIST lists the VTOC as expected. Under z/OS 1.13, IEHLIST issues the following message and quits: IEH106I UNAVAILABLE DEVICE TYPE OR VOLUME I.D. SPECIFIED The JCL is identical and the job is being run against the same volume in both cases. The volume is available to both systems. I haven't been able to find any relevant hits. Has anyone else seen the same symptom? -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507, gord.tom...@actionsoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive
Re: IEHLIST LISTVTOC inconsistency
D U,VOL=DSKAA9 shows the same output on both systems: IEE457I 22.41.14 UNIT STATUS 529 UNIT TYPE STATUSVOLSER VOLSTATE 0AA9 3390 O DSKAA9 PRIV/RSDNT Dale identified the cause of the problem. For some reason, IBM has decided that SYSLIB is no longer an acceptable DDname for the DD statement identifying the volume whose VTOC is to be listed. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-04-16 20:07, Mark Zelden wrote: On Mon, 16 Apr 2012 19:38:44 -0400, Gord Tomlingt.ibm.li...@actionsoftware.com wrote: I just ran into a situation where IEHLIST is providing different results for the same volume depending upon whether it is run from a z/OS 1.11 system or a z/OS 1.13 system. The JCL looks like this: //jobname JOB etc. //* //LISTEXEC PGM=IEHLIST //SYSPRINT DD SYSOUT=* //SYSLIB DD UNIT=3390,VOL=SER=DSKAA9,DISP=SHR //SYSINDD * LISTVTOC VOL=3390=DSKAA9 /* Under z/OS 1.11, IEHLIST lists the VTOC as expected. Under z/OS 1.13, IEHLIST issues the following message and quits: IEH106I UNAVAILABLE DEVICE TYPE OR VOLUME I.D. SPECIFIED The JCL is identical and the job is being run against the same volume in both cases. The volume is available to both systems. I haven't been able to find any relevant hits. Has anyone else seen the same symptom? What does a D U,VOL=DSKAA9 show from the z/OS 1.13 system? Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
IEL1CL not found
Hello All, Good Morning !! I am just trying to locate the proc IEL1CL in our newly installed z/os 1.13 within the libraries(SYS1.**, CPAC.**), but unfortunately I am unable to locate the PROC for compiling PL/I programs. Whereas I could get same proc in Z/OS 1.9 1.8 level. Could anyone please point me to the right direction. Jags -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEHLIST LISTVTOC inconsistency
Gil, I think a PMR is indeed appropriate here. SYSLIB is not documented as a DDNAME for any specific purpose for IEHLIST, SYSLIB is not documented as an invalid DDname for the anyname DD statement, and, as you say, the error message issued is thoroughly misleading. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-04-16 21:29, Paul Gilmartin wrote: On Mon, 16 Apr 2012 17:06:28 -0700, Dale McCart wrote: Your JCL will fail on z/OS 1.12 as well. change name of SYSLIB DD to something else //VDSKAA9 DD UNIT=3390,VOL=SER=DSKAA9,DISP=SHR will work. While you would think SYSLIB would qualify as anyname apparently it dose not. Submit a PMR. Under z/OS 1.11, IEHLIST lists the VTOC as expected. Under z/OS 1.13, IEHLIST issues the following message and quits: IEH106I UNAVAILABLE DEVICE TYPE OR VOLUME I.D. SPECIFIED Even if the doc were to be updated (as it should), the message is totally irrelevant to the syntax error. They might even fix it (they should) by removing the dependency on SYSLIB and using a generated DDNAME. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEHLIST LISTVTOC inconsistency
On Mon, 16 Apr 2012 21:37:54 -0500, Mike Schwab wrote: Actually, they probrably would document that SYSLIB DD name cannot be used to with z/OS 1.12 and above to allow for testing alternate versions of the program. Are you thinking, rather, perhaps, of STEPLIB? Its likely that they internally DYNALLOC DD(SYSLIB) REUSE, for whatever purpose. They ought to remove the REUSE key, allowing a IKJ56246I FILE in USE message to appear and use a generated DDNAME (best). A poor second is to document the restriction. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEL1CL not found
Don't have PL/1 here, but a casual search of IBM doco (can't you do this?) shows Enterprise PL/1 for z/OS V4.2 has a SMP/E DDDEF of SIBMPRC. I'd be surprised if it's not there (if IBM still ship it under that name, and I imagine they do). So, whatever dataset that DDDEF points to. Of course, your site may use a local run-time copy of that file, or copy the contents into some generally available proclib. Every site is different in the way they organise things. In general, if I'm looking for a JCL procedure, I just call it with some rubbish parm (e.g. EXEC proc,JCLERROR=YESPLEASE) and look for the IEFC001I msg that reveals what proclib it's found in, if it is found. Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Tuesday, 17 April 2012 12:18 PM To: IBM-MAIN@bama.ua.edu Subject: IEL1CL not found Hello All, Good Morning !! I am just trying to locate the proc IEL1CL in our newly installed z/os 1.13 within the libraries(SYS1.**, CPAC.**), but unfortunately I am unable to locate the PROC for compiling PL/I programs. Whereas I could get same proc in Z/OS 1.9 1.8 level. Could anyone please point me to the right direction. Jags -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
On Apr 16, 2012, at 8:34 AM, McKown, John wrote: SNIP- Also remember that COBOL, at least originally, was supposed to be very English-like and so usable by people at the Army PFC level of training. -- John McKown Systems Engineer IV IT Hmmm... I was in the Army and we got PFC's from the programming school (AZ? its been 40 years so forgive me). We had two groups, one COBOL (batch processing) and one ASM group (essentially sysprogs). The ASM group was by far the best IMO. I was on call quite often and had to fix the cobol programs that went boom in the middle of the night. The COBOL people were semi useless in debugging and when I looked at the code they had produced (except for a few people) it was hopeless to understand. I spent more time trying to figure out the logic and compare what I was seeing in the dump. 1/3 the time I helped the programmer figure out where his problem was and supplying answers to his questions on what was in this field or that field. What was interesting was that as the guys (no female programmers so don't call me sexist blame the Army not me) as they became more experienced the code became easier to follow. As they became became better programmers there were less logic problems. Now having said that most of the programs were smallish and only a few were considered large so the smallish programs there was no excuse for logic issues or mangled code. My memory is foggy here as to goto's but I think the rule no standards if memory serves me that goto's were to be minimized as a result flow was easier to follow and frankly debugging was easier. Ed ps: We had one person who at the time he was drafted was working for IBM and he privately told me about some OS enhancements that when I first heard I couldn't wrap my head around as virtual (at least that I had never heard of) was a nightmare that I couldn't wrap my head around. After I got out of the Army (2 years) IBM announced Virtual and I was able to ask some semi intelligent questions as my preview and the questions helped jump start by job. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEL1CL not found
Oops, typo... DDDEF = SIBMZPRC not SIBMPRC Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Tuesday, 17 April 2012 12:18 PM To: IBM-MAIN@bama.ua.edu Subject: IEL1CL not found Hello All, Good Morning !! I am just trying to locate the proc IEL1CL in our newly installed z/os 1.13 within the libraries(SYS1.**, CPAC.**), but unfortunately I am unable to locate the PROC for compiling PL/I programs. Whereas I could get same proc in Z/OS 1.9 1.8 level. Could anyone please point me to the right direction. Jags -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Origins of numeric assignation of z196 z114
I will throw out a guess here. IBM has been through the years exceedingly cautious in naming anything. The new names are at best a way to confuse people, in my opinion. Ed On Apr 16, 2012, at 9:54 AM, Thomas Berg wrote: -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S. Skickat: den 16 april 2012 16:42 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Origins of numeric assignation of z196 z114 W dniu 2012-04-16 16:33, Alvaro Guirao Lopez pisze: I have seeked but found nothing about this, why the new servers have been named z196 z114 and not Z11 EC Z11 BC? Why not z11? I don't know. Why 196 and 114? I heard about it: 1xx means FIRST generation (of what? naming convention?) 96 means number of processors inside. Note, you can buy only 80 of them, but it really contains 96 processors, inlcuidng SAPs and spares. 14 is for M10 model (4 are for spares and SAPs). BTW: I really can't understand marketing names like z196, TS1140, or DS8000. Why don't they use names like Jaguar (ok, it's partially used), MAGSTAR, T-REX, MtBlanc or Cindy Crawford? Last, bit not least: Athlon, or Pentium sounds much better than CMOS 11S. -- Radoslaw Skorupka Lodz, Poland I would then suggest names more like: zEUS, HERA, HERMES, GILGAMESH, etc. :) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEL1CL not found
Thanks for your email, but as a testing I tried with the ISPF option 4.5 I get the below error message when I give the Source library at Other Partitioned or Sequential Data Set: Name . . . . . . . 'U322501.TEST.PL1(FIRSTCD)' List ID . . . Compiler Password . . 2 1. OS PL/I Version 2 2. PLI for MVS and VM IKJ56479I COMMAND IEL1IKJ5 NOT FOUND OR REXX IDENTIFIER IS MISSING+ : Could not find anything related to IEL1IKJ5 in google. IKJ56479I SUPPLY '/* REXX */' AS THE FIRST RECORD TO EXECUTE AS A REXX EXEC OR, FOR AN EXPLICIT EXEC, SUPPLY THE EXEC KEYWORD ON THE EXEC COMMAND *** Jags On Tue, Apr 17, 2012 at 9:46 AM, Anthony Thompson anthony.thomp...@nt.gov.au wrote: Oops, typo... DDDEF = SIBMZPRC not SIBMPRC Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Tuesday, 17 April 2012 12:18 PM To: IBM-MAIN@bama.ua.edu Subject: IEL1CL not found Hello All, Good Morning !! I am just trying to locate the proc IEL1CL in our newly installed z/os 1.13 within the libraries(SYS1.**, CPAC.**), but unfortunately I am unable to locate the PROC for compiling PL/I programs. Whereas I could get same proc in Z/OS 1.9 1.8 level. Could anyone please point me to the right direction. Jags -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEL1CL not found
Apology for Typo actually its PL/I for MVS VM Installation and Customization under MVS, SC26-3119 On Tue, Apr 17, 2012 at 10:21 AM, jagadishan perumal jagadish...@gmail.comwrote: Hello All, Looks like I need to customize the PL/I for MVS and VM. I have found the manual PL/I for MVS VM Compiler and Run-Time Migration Guidehttp://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ibm3m10/ibm3m101.htm, SC26-3118 but I am unable to open it from http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ceea300%2Fceea31b0183.htm; . Could anyone please help in pointing to the PDF version of the above document. Jags On Tue, Apr 17, 2012 at 9:56 AM, jagadishan perumal jagadish...@gmail.com wrote: Thanks for your email, but as a testing I tried with the ISPF option 4.5 I get the below error message when I give the Source library at Other Partitioned or Sequential Data Set: Name . . . . . . . 'U322501.TEST.PL1(FIRSTCD)' List ID . . . Compiler Password . . 2 1. OS PL/I Version 2 2. PLI for MVS and VM IKJ56479I COMMAND IEL1IKJ5 NOT FOUND OR REXX IDENTIFIER IS MISSING+ : Could not find anything related to IEL1IKJ5 in google. IKJ56479I SUPPLY '/* REXX */' AS THE FIRST RECORD TO EXECUTE AS A REXX EXEC OR, FOR AN EXPLICIT EXEC, SUPPLY THE EXEC KEYWORD ON THE EXEC COMMAND *** Jags On Tue, Apr 17, 2012 at 9:46 AM, Anthony Thompson anthony.thomp...@nt.gov.au wrote: Oops, typo... DDDEF = SIBMZPRC not SIBMPRC Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Tuesday, 17 April 2012 12:18 PM To: IBM-MAIN@bama.ua.edu Subject: IEL1CL not found Hello All, Good Morning !! I am just trying to locate the proc IEL1CL in our newly installed z/os 1.13 within the libraries(SYS1.**, CPAC.**), but unfortunately I am unable to locate the PROC for compiling PL/I programs. Whereas I could get same proc in Z/OS 1.9 1.8 level. Could anyone please point me to the right direction. Jags -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEL1CL not found
Hello All, Looks like I need to customize the PL/I for MVS and VM. I have found the manual PL/I for MVS VM Compiler and Run-Time Migration Guidehttp://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ibm3m10/ibm3m101.htm, SC26-3118 but I am unable to open it from http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ceea300%2Fceea31b0183.htm; . Could anyone please help in pointing to the PDF version of the above document. Jags On Tue, Apr 17, 2012 at 9:56 AM, jagadishan perumal jagadish...@gmail.comwrote: Thanks for your email, but as a testing I tried with the ISPF option 4.5 I get the below error message when I give the Source library at Other Partitioned or Sequential Data Set: Name . . . . . . . 'U322501.TEST.PL1(FIRSTCD)' List ID . . . Compiler Password . . 2 1. OS PL/I Version 2 2. PLI for MVS and VM IKJ56479I COMMAND IEL1IKJ5 NOT FOUND OR REXX IDENTIFIER IS MISSING+ : Could not find anything related to IEL1IKJ5 in google. IKJ56479I SUPPLY '/* REXX */' AS THE FIRST RECORD TO EXECUTE AS A REXX EXEC OR, FOR AN EXPLICIT EXEC, SUPPLY THE EXEC KEYWORD ON THE EXEC COMMAND *** Jags On Tue, Apr 17, 2012 at 9:46 AM, Anthony Thompson anthony.thomp...@nt.gov.au wrote: Oops, typo... DDDEF = SIBMZPRC not SIBMPRC Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Tuesday, 17 April 2012 12:18 PM To: IBM-MAIN@bama.ua.edu Subject: IEL1CL not found Hello All, Good Morning !! I am just trying to locate the proc IEL1CL in our newly installed z/os 1.13 within the libraries(SYS1.**, CPAC.**), but unfortunately I am unable to locate the PROC for compiling PL/I programs. Whereas I could get same proc in Z/OS 1.9 1.8 level. Could anyone please point me to the right direction. Jags -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEL1CL not found
Looks like your ISPF environment is not set up properly, can't find that REXX. Missing a SYSPROC/SYSEXEC/application-level library. Online PL/I doco can be found from here: http://www-01.ibm.com/software/awdtools/pli/ Click on the link for the compiler you have, there are links to doco and a PL/I forum I don't see that manual listed for a download, nor can I see any reference to ISPF customization in program directories or other listed manuals. Might need to talk to your local IBM rep. Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Tuesday, 17 April 2012 2:22 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEL1CL not found Apology for Typo actually its PL/I for MVS VM Installation and Customization under MVS, SC26-3119 On Tue, Apr 17, 2012 at 10:21 AM, jagadishan perumal jagadish...@gmail.comwrote: Hello All, Looks like I need to customize the PL/I for MVS and VM. I have found the manual PL/I for MVS VM Compiler and Run-Time Migration Guidehttp://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm .zos.r12.ibm3m10/ibm3m101.htm, SC26-3118 but I am unable to open it from http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ceea300%2Fceea31b0183.htm; . Could anyone please help in pointing to the PDF version of the above document. Jags On Tue, Apr 17, 2012 at 9:56 AM, jagadishan perumal jagadish...@gmail.com wrote: Thanks for your email, but as a testing I tried with the ISPF option 4.5 I get the below error message when I give the Source library at Other Partitioned or Sequential Data Set: Name . . . . . . . 'U322501.TEST.PL1(FIRSTCD)' List ID . . . Compiler Password . . 2 1. OS PL/I Version 2 2. PLI for MVS and VM IKJ56479I COMMAND IEL1IKJ5 NOT FOUND OR REXX IDENTIFIER IS MISSING+ : Could not find anything related to IEL1IKJ5 in google. IKJ56479I SUPPLY '/* REXX */' AS THE FIRST RECORD TO EXECUTE AS A REXX EXEC OR, FOR AN EXPLICIT EXEC, SUPPLY THE EXEC KEYWORD ON THE EXEC COMMAND *** Jags On Tue, Apr 17, 2012 at 9:46 AM, Anthony Thompson anthony.thomp...@nt.gov.au wrote: Oops, typo... DDDEF = SIBMZPRC not SIBMPRC Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of jagadishan perumal Sent: Tuesday, 17 April 2012 12:18 PM To: IBM-MAIN@bama.ua.edu Subject: IEL1CL not found Hello All, Good Morning !! I am just trying to locate the proc IEL1CL in our newly installed z/os 1.13 within the libraries(SYS1.**, CPAC.**), but unfortunately I am unable to locate the PROC for compiling PL/I programs. Whereas I could get same proc in Z/OS 1.9 1.8 level. Could anyone please point me to the right direction. Jags -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: brand new CF LPAR
Thank you all. Mr Kawkabani, I will use CFRMPOL to refer to newly created policy. What about ARM and SFM policies that I have created using IXCMIAPU and are named differently. How can I use them. Still searching for how to create new CDS, BPXMCDS, LOGR (hundreds of structures)and WLM policies and how to make system to use them right from the IPL.. Mr Robinson, My problem is I have only one ICF partition on each boxes (Old and New) and will not have cross coupling facility links. Both of the CF names are COUPL01. Can I format CFRM Policy with duplicate CF NAME COUPL01 for each process types (2818 and 2086, serial number will remain the same). If it is possible I can use same CFRM policy and before shutting down the last LPAR for processor migration, I can change CF configuration to match the new processor. I am planning to bring in sandbox LPAR in the plex first and should be able to use FORCE command to get the Coupling facility correct before bringing in any proper systems in the PLEX..i do agree its risky and need guidance. Thaks once again for you valuable suggestion, its much appreciated.. Regards, Munif. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
