Re: Dump Defaults (Was: SLIP IF Trap?)
CD SET,SDUMP=(RGN,CSA,LPA),ADD,MAXSPACE=5000M ... probably inherited from something someone did before the last millennium. Does anyone have any other (21st-century) recommendations for improving this? I have set this: CD SET,SDUMP=(ALLPSA,CSA,SQA,GRSQ,LPA,NUC,RGN,SUM,SWA,TRT) In our installation there is no need to increase maxspace, the dumps I'm interested in all fit the 500MB limit (well, except when someone initialized a 1GB data space to hex zeroes :-) ). We're a monoplex, so XESDATA is something I son't care about, either. Given that I cannot open z/OS problems to IBM, anyway, there would probably be no need to even include NUC and ALLPSA. Now what I still don't quite 'get' is how to dump everything needed above the bar automatically. RGN does not seem to cover that, so any program experiencing a problem would need to explicitly specify ranges of storage above the bar in its own dump invocation. Or am I missing something? Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Defaults (Was: SLIP IF Trap?)
Ed Jaffe wrote: I noticed our most important systems issue the following command in COMMNDxx: CD SET,SDUMP=(RGN,CSA,LPA),ADD,MAXSPACE=5000M Just only that? What about LSQA, NUC, PSA, SUMDUMP and other friends? Beside MAXSPACE, what is the size of BUFFERS? (We got it at 8M) ... probably inherited from something someone did before the last millennium. Someone TRACE-able must have SLIPped up and DUMPed something... :-D Does anyone have any other (21st-century) recommendations for improving this? I'm also curious about those recommendations. What about settings for SYSMDUMP? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Refer Back in JCL
Hi All, I have been trying the REFER Back statement in JCL to take multiple backups on a 3592 tape using a JCL such as below. However, for some reason this doesn't seem to be working. //STEP1EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD1DD UNIT=3390,VOL=SER=RSDV01,DISP=SHR //TAPE1DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV01, // UNIT=3592ATLC,DISP=(NEW,CATLG),LABEL=(1,SL), // RETPD=1,VOL=(,RETAIN) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) /* //STEP2EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD2DD UNIT=3390,VOL=SER=RSDV02,DISP=SHR //TAPE2DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV02, // UNIT=3592ATLC,DISP=(,CATLG),LABEL=(2,SL), // RETPD=1,VOL=(,RETAIN,REF=*.STEP1.TAPE1) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) I keep getting an error such as : IGD306I UNEXPECTED ERROR DURING CBRXLCS PROCESSING 326 RETURN CODE 12 REASON CODE 67 THE MODULE THAT DETECTED THE ERROR IS IGDIDMUS SMS MODULE TRACE BACK - IDMUS IDMSU IDM00 SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00148 The backups work fine if I try only one backup at a time. Does anybody see any errors with my JCL or have any suggestions on what should I look at? Thanks Varun -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Fwd: Refer Back in JCL
I think the previous post didn't work due to incorrect email. Trying it again on another email. Sorry if it gets posted twice! -- Forwarded message -- From: Mainframe Sysprog mainframe.sysp...@gmail.com Date: Thu, Sep 25, 2014 at 6:06 PM Subject: Refer Back in JCL To: IBM Mainframe Discussion List ibm-m...@bama.ua.edu Hi All, I have been trying the REFER Back statement in JCL to take multiple backups on a 3592 tape using a JCL such as below. However, for some reason this doesn't seem to be working. //STEP1EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD1DD UNIT=3390,VOL=SER=RSDV01,DISP=SHR //TAPE1DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV01, // UNIT=3592ATLC,DISP=(NEW,CATLG),LABEL=(1,SL), // RETPD=1,VOL=(,RETAIN) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) /* //STEP2EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD2DD UNIT=3390,VOL=SER=RSDV02,DISP=SHR //TAPE2DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV02, // UNIT=3592ATLC,DISP=(,CATLG),LABEL=(2,SL), // RETPD=1,VOL=(,RETAIN,REF=*.STEP1.TAPE1) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) I keep getting an error such as : IGD306I UNEXPECTED ERROR DURING CBRXLCS PROCESSING 326 RETURN CODE 12 REASON CODE 67 THE MODULE THAT DETECTED THE ERROR IS IGDIDMUS SMS MODULE TRACE BACK - IDMUS IDMSU IDM00 SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00148 The backups work fine if I try only one backup at a time. Does anybody see any errors with my JCL or have any suggestions on what should I look at? Thanks Varun -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Refer Back in JCL
Your ODD statements do not specify the correct DDNAME of TAPE1 or TAPE2 _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Sysprog Sent: Thursday, September 25, 2014 8:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Fwd: Refer Back in JCL I think the previous post didn't work due to incorrect email. Trying it again on another email. Sorry if it gets posted twice! -- Forwarded message -- From: Mainframe Sysprog mainframe.sysp...@gmail.com Date: Thu, Sep 25, 2014 at 6:06 PM Subject: Refer Back in JCL To: IBM Mainframe Discussion List ibm-m...@bama.ua.edu Hi All, I have been trying the REFER Back statement in JCL to take multiple backups on a 3592 tape using a JCL such as below. However, for some reason this doesn't seem to be working. //STEP1EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD1DD UNIT=3390,VOL=SER=RSDV01,DISP=SHR //TAPE1DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV01, // UNIT=3592ATLC,DISP=(NEW,CATLG),LABEL=(1,SL), // RETPD=1,VOL=(,RETAIN) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) /* //STEP2EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD2DD UNIT=3390,VOL=SER=RSDV02,DISP=SHR //TAPE2DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV02, // UNIT=3592ATLC,DISP=(,CATLG),LABEL=(2,SL), // RETPD=1,VOL=(,RETAIN,REF=*.STEP1.TAPE1) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) I keep getting an error such as : IGD306I UNEXPECTED ERROR DURING CBRXLCS PROCESSING 326 RETURN CODE 12 REASON CODE 67 THE MODULE THAT DETECTED THE ERROR IS IGDIDMUS SMS MODULE TRACE BACK - IDMUS IDMSU IDM00 SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00148 The backups work fine if I try only one backup at a time. Does anybody see any errors with my JCL or have any suggestions on what should I look at? Thanks Varun -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Refer Back in JCL
67No device pools exist to fulfill request for media type. On Thu, Sep 25, 2014 at 6:10 PM, Mainframe Sysprog mainframe.sysp...@gmail.com wrote: I think the previous post didn't work due to incorrect email. Trying it again on another email. Sorry if it gets posted twice! -- Forwarded message -- From: Mainframe Sysprog mainframe.sysp...@gmail.com Date: Thu, Sep 25, 2014 at 6:06 PM Subject: Refer Back in JCL To: IBM Mainframe Discussion List ibm-m...@bama.ua.edu Hi All, I have been trying the REFER Back statement in JCL to take multiple backups on a 3592 tape using a JCL such as below. However, for some reason this doesn't seem to be working. //STEP1EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD1DD UNIT=3390,VOL=SER=RSDV01,DISP=SHR //TAPE1DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV01, // UNIT=3592ATLC,DISP=(NEW,CATLG),LABEL=(1,SL), // RETPD=1,VOL=(,RETAIN) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) /* //STEP2EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD2DD UNIT=3390,VOL=SER=RSDV02,DISP=SHR //TAPE2DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV02, // UNIT=3592ATLC,DISP=(,CATLG),LABEL=(2,SL), // RETPD=1,VOL=(,RETAIN,REF=*.STEP1.TAPE1) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) I keep getting an error such as : IGD306I UNEXPECTED ERROR DURING CBRXLCS PROCESSING 326 RETURN CODE 12 REASON CODE 67 THE MODULE THAT DETECTED THE ERROR IS IGDIDMUS SMS MODULE TRACE BACK - IDMUS IDMSU IDM00 SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00148 The backups work fine if I try only one backup at a time. Does anybody see any errors with my JCL or have any suggestions on what should I look at? Thanks Varun -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Refer Back in JCL
Hi Varun, have you tried to refer back to the dataset name? I have a similar JCL with the output vol specified like this (on the second and subsequent steps): //TAPE2DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV02, // UNIT=3592ATLC,DISP=(,CATLG),LABEL=(2,SL), // RETPD=1,VOL=(,RETAIN,REF=CIMSSP.TAPE3592.BACKUP.RSDV01) Regards, Edgard IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU gravou em 25/09/2014 09:36:23: De: Mainframe Sysprog mainframe.sysp...@gmail.com Para: IBM-MAIN@LISTSERV.UA.EDU Data: 25/09/2014 09:36 Assunto: Refer Back in JCL Enviado por: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi All, I have been trying the REFER Back statement in JCL to take multiple backups on a 3592 tape using a JCL such as below. However, for some reason this doesn't seem to be working. //STEP1EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD1DD UNIT=3390,VOL=SER=RSDV01,DISP=SHR //TAPE1DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV01, // UNIT=3592ATLC,DISP=(NEW,CATLG),LABEL=(1,SL), // RETPD=1,VOL=(,RETAIN) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) /* //STEP2EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD2DD UNIT=3390,VOL=SER=RSDV02,DISP=SHR //TAPE2DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV02, // UNIT=3592ATLC,DISP=(,CATLG),LABEL=(2,SL), // RETPD=1,VOL=(,RETAIN,REF=*.STEP1.TAPE1) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) I keep getting an error such as : IGD306I UNEXPECTED ERROR DURING CBRXLCS PROCESSING 326 RETURN CODE 12 REASON CODE 67 THE MODULE THAT DETECTED THE ERROR IS IGDIDMUS SMS MODULE TRACE BACK - IDMUS IDMSU IDM00 SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00148 The backups work fine if I try only one backup at a time. Does anybody see any errors with my JCL or have any suggestions on what should I look at? Thanks Varun -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Refer Back in JCL
And in STEP2, your IDD should be: IDD(DASD2) From: Jousma, David david.jou...@53.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 09/25/2014 07:48 AM Subject:Re: Refer Back in JCL Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Your ODD statements do not specify the correct DDNAME of TAPE1 or TAPE2 _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mainframe Sysprog Sent: Thursday, September 25, 2014 8:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Fwd: Refer Back in JCL I think the previous post didn't work due to incorrect email. Trying it again on another email. Sorry if it gets posted twice! -- Forwarded message -- From: Mainframe Sysprog mainframe.sysp...@gmail.com Date: Thu, Sep 25, 2014 at 6:06 PM Subject: Refer Back in JCL To: IBM Mainframe Discussion List ibm-m...@bama.ua.edu Hi All, I have been trying the REFER Back statement in JCL to take multiple backups on a 3592 tape using a JCL such as below. However, for some reason this doesn't seem to be working. //STEP1EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD1DD UNIT=3390,VOL=SER=RSDV01,DISP=SHR //TAPE1DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV01, // UNIT=3592ATLC,DISP=(NEW,CATLG),LABEL=(1,SL), // RETPD=1,VOL=(,RETAIN) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) /* //STEP2EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DASD2DD UNIT=3390,VOL=SER=RSDV02,DISP=SHR //TAPE2DD DSN=CIMSSP.TAPE3592.BACKUP.RSDV02, // UNIT=3592ATLC,DISP=(,CATLG),LABEL=(2,SL), // RETPD=1,VOL=(,RETAIN,REF=*.STEP1.TAPE1) //SYSINDD * DUMP IDD(DASD1) ODD(TAPE) - DATASET(INCLUDE(**)) I keep getting an error such as : IGD306I UNEXPECTED ERROR DURING CBRXLCS PROCESSING 326 RETURN CODE 12 REASON CODE 67 THE MODULE THAT DETECTED THE ERROR IS IGDIDMUS SMS MODULE TRACE BACK - IDMUS IDMSU IDM00 SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00148 The backups work fine if I try only one backup at a time. Does anybody see any errors with my JCL or have any suggestions on what should I look at? Thanks Varun -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help finding CICS Application Programming Primer
GIYF -Original Message- From: IBM Mainframe Discussion List On Behalf Of Hansen, Dave L - Eagan, MN Dear Group, (Still waiting on the CICS-L Listserv) Back when my hair was a younger color I used to write online CICS programs. I found a sample CICS program shown below. I found the JCL for Batch compilation for COBOL programs documented in the CICS Application Programming Guide (SC34-2844). I was looking for more information on building a test transaction for CICS. From the infocenter I did find The general insurance application under the samples. Also I could find Batch compilation for COBOL programs documented at the infocenter. The CICS TS for z/OS V5 R1 Application Programming Reference (SC34-2845) describes What you need to know to understand this manual on page vii. It lists the CICS Application Programming Primer. Q). Where is the CICS Application Programming Primer? I did not find it in the bibliography. I didn't find a link like that at the infocenter. Just trying to find what information is available and where. Thanks, Dave IDENTIFICATION DIVISION. PROGRAM-ID.SAMCICS. * ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE DIVISION. * 01 WS-INPUT. 05 WS-TRAN-ID PIC X(4). 05 WS-MESSAGE-I PIC X(70). * 01 WS-OUTPUT. 05 WS-TEXT PIC X(8). 05 WS-MESSAGE-O PIC X(70). * 01 WS-MSG-LENGTH PIC S9(4) COMP. * PROCEDURE DIVISION. * MOVE 74TO WS-MSG-LENGTH. * EXEC CICS RECEIVE INTO(WS-INPUT) LENGTH(WS-MSG-LENGTH) END-EXEC. * MOVE WS-MESSAGE-ITO WS-MESSAGE-O. MOVE 'OUTPUT: ' TO WS-TEXT. MOVE 78 TO WS-MSG-LENGTH. * EXEC CICS SEND FROM(WS-OUTPUT) LENGTH(WS-MSG-LENGTH) ERASE END-EXEC. * EXEC CICS RETURN END-EXEC. * GOBACK. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help finding CICS Application Programming Primer
I would do internet searches in CICS TS5 APPLICATION and see what pops up. Second go on redbooks.ibm.com/ And do a similar search. Third. You should have received a confirmation back to join CICS-L. Go back to the URL and signup again. https://listserv.uga.edu/cgi-bin/wa?A0=CICS-L If that still does not help you sign up, then contact the UGA help desk in the upper right hand corner of the webpage Lastly search the IBMMAIN archives for Frank swarbrick cics He has good postings on CICS Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hansen, Dave L - Eagan, MN Sent: Thursday, September 25, 2014 7:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Help finding CICS Application Programming Primer Dear Group, (Still waiting on the CICS-L Listserv) Back when my hair was a younger color I used to write online CICS programs. I found a sample CICS program shown below. I found the JCL for Batch compilation for COBOL programs documented in the CICS Application Programming Guide (SC34-2844). I was looking for more information on building a test transaction for CICS. From the infocenter I did find The general insurance application under the samples. Also I could find Batch compilation for COBOL programs documented at the infocenter. The CICS TS for z/OS V5 R1 Application Programming Reference (SC34-2845) describes What you need to know to understand this manual on page vii. It lists the CICS Application Programming Primer. Q). Where is the CICS Application Programming Primer? I did not find it in the bibliography. I didn't find a link like that at the infocenter. Just trying to find what information is available and where. Thanks, Dave IDENTIFICATION DIVISION. PROGRAM-ID.SAMCICS. * ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE DIVISION. * 01 WS-INPUT. 05 WS-TRAN-ID PIC X(4). 05 WS-MESSAGE-I PIC X(70). * 01 WS-OUTPUT. 05 WS-TEXT PIC X(8). 05 WS-MESSAGE-O PIC X(70). * 01 WS-MSG-LENGTH PIC S9(4) COMP. * PROCEDURE DIVISION. * MOVE 74TO WS-MSG-LENGTH. * EXEC CICS RECEIVE INTO(WS-INPUT) LENGTH(WS-MSG-LENGTH) END-EXEC. * MOVE WS-MESSAGE-ITO WS-MESSAGE-O. MOVE 'OUTPUT: ' TO WS-TEXT. MOVE 78 TO WS-MSG-LENGTH. * EXEC CICS SEND FROM(WS-OUTPUT) LENGTH(WS-MSG-LENGTH) ERASE END-EXEC. * EXEC CICS RETURN END-EXEC. * GOBACK. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help finding CICS Application Programming Primer
Good idea. A very fast search on Redbooks found this: http://publib-b.boulder.ibm.com/abstracts/sg247952.html?Open abstract In this IBM® Redbooks® publication, we discuss CICS®, which stands for Customer Information Control System. It is a general-purpose transaction processing subsystem for the z/OS® operating system. CICS provides services for running an application online where, users submit requests to run applications simultaneously. CICS manages sharing resources, the integrity of data, and prioritizes execution with fast response. CICS authorizes users, allocates resources (real storage and cycles), and passes on database requests by the application to the appropriate database manager, such as DB2®. We review the history of CICS and why it was created. We review the CICS architecture and discuss how to create an application in CICS. CICS provides a secure, transactional environment for applications that are written in several languages. We discuss the CICS-supported languages and each language's advantages in this Redbooks publication. We analyze situations from a system programmer's viewpoint, including how the systems programmer can use CICS facilities and services to customize the system, design CICS for recovery, and manage performance. CICS Data access and where the data is stored, including Temporary storage queues, VSAM RLS, DB2, IMS™, and many others are also discussed. /abstract On Thu, Sep 25, 2014 at 10:07 AM, Lizette Koehler stars...@mindspring.com wrote: I would do internet searches in CICS TS5 APPLICATION and see what pops up. Second go on redbooks.ibm.com/ And do a similar search. Third. You should have received a confirmation back to join CICS-L. Go back to the URL and signup again. https://listserv.uga.edu/cgi-bin/wa?A0=CICS-L If that still does not help you sign up, then contact the UGA help desk in the upper right hand corner of the webpage Lastly search the IBMMAIN archives for Frank swarbrick cics He has good postings on CICS Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hansen, Dave L - Eagan, MN Sent: Thursday, September 25, 2014 7:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Help finding CICS Application Programming Primer Dear Group, (Still waiting on the CICS-L Listserv) Back when my hair was a younger color I used to write online CICS programs. I found a sample CICS program shown below. I found the JCL for Batch compilation for COBOL programs documented in the CICS Application Programming Guide (SC34-2844). I was looking for more information on building a test transaction for CICS. From the infocenter I did find The general insurance application under the samples. Also I could find Batch compilation for COBOL programs documented at the infocenter. The CICS TS for z/OS V5 R1 Application Programming Reference (SC34-2845) describes What you need to know to understand this manual on page vii. It lists the CICS Application Programming Primer. Q). Where is the CICS Application Programming Primer? I did not find it in the bibliography. I didn't find a link like that at the infocenter. Just trying to find what information is available and where. Thanks, Dave IDENTIFICATION DIVISION. PROGRAM-ID.SAMCICS. * ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE DIVISION. * 01 WS-INPUT. 05 WS-TRAN-ID PIC X(4). 05 WS-MESSAGE-I PIC X(70). * 01 WS-OUTPUT. 05 WS-TEXT PIC X(8). 05 WS-MESSAGE-O PIC X(70). * 01 WS-MSG-LENGTH PIC S9(4) COMP. * PROCEDURE DIVISION. * MOVE 74TO WS-MSG-LENGTH. * EXEC CICS RECEIVE INTO(WS-INPUT) LENGTH(WS-MSG-LENGTH) END-EXEC. * MOVE WS-MESSAGE-ITO WS-MESSAGE-O. MOVE 'OUTPUT: ' TO WS-TEXT. MOVE 78 TO WS-MSG-LENGTH. * EXEC CICS SEND FROM(WS-OUTPUT) LENGTH(WS-MSG-LENGTH) ERASE END-EXEC. * EXEC CICS RETURN END-EXEC. * GOBACK. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help finding CICS Application Programming Primer
Yeah, either they're blocking you or you're blocking them. Should only take a few minutes. Since it is a listserv list can send to us(_lists...@listserv.ua.edu_ (mailto:lists...@listserv.ua.edu) ) with sub cics-l your name as the text of you message. In a message dated 9/25/2014 10:07:30 A.M. Central Daylight Time, stars...@mindspring.com writes: Third. You should have received a confirmation back to join CICS-L. Go back to the URL and signup again. https://listserv.uga.edu/cgi-bin/wa?A0=CICS-L -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help finding CICS Application Programming Primer
John McKown wrote: Looks like a really _old_ manual. Old? Unless I'm mistaken, but the version I see is copyrighted in year 1989 and again 2013 and book refers to CICS TS 5.1 at http://pic.dhe.ibm.com/infocenter/cicsts/v5r1/topic/com.ibm.cics.ts.applicationprogramming.doc/dfhp4_pdf.pdf I used Google to search Application Programming Reference (SC34-2845) and above URL is the very first search result amongst a lot of other useful links. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help finding CICS Application Programming Primer
Elardus Engelbrecht wrote: John McKown wrote: Looks like a really _old_ manual. Old? Unless I'm mistaken, ... Groan. Sorry. I got a little mixed up in my last post. Yes, I eventually found that ld book and it seemed there is not a more recent copy. Please accept my apology. Too many holiday days... Yesterday we have a 'Braai Dag' (Afrikaans for Barbeque Day) to celebrate that thing we call 'heritage' or something like that... ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?!
Discovered this unpleasant fact today: Editing or Viewing an existing RECFM=VB UTF-8 file or PDS(E) member uses X'40' for the trailing spaces on screen (i.e., the part of each record past the end of the actual record contents). Editing a new file or PDS(E) member using ASCII or UTF-8 mode uses X'20' for spaces as expected. Edit a new PDS member in ASCII or UTF-8 mode (HEX ON to show actual characters) and you get this, which is good and what you would expect to see: EDIT TDPEFAR.CBT391.XPDFTEXT(TEMP) - 01.00 Columns 1 00072 Command === Scroll === CSR ** * Top of Data ** 01 Qwertyuiop Asdfghjkl Zxcvbnm 1234567890-= 5766672476662576766623323222 17524959F00134678ABC0A8362ED01234567890DD000 -- 02 Qwertyuiop Asdfghjkl Zxcvbnm 1234567890-= 5766672476662576766623323222 17524959F00134678ABC0A8362ED01234567890DD000 -- However, edit an existing ASCII or UTF-8 member and you get this, which is unexpected and IMHO wrong: EDIT TSOUSER.RECFMV.TEXTFILE (TEST) - 01.02 Columns 1 00072 Command === Scroll === CSR 000318 Qwertyuiop Asdfghjkl Zxcvbnm 1234567890-=@@@ 5766672476662576766623323444 17524959F00134678ABC0A8362ED01234567890DD000 -- 000319 -- 000320 Qwertyuiop Asdfghjkl Zxcvbnm 1234567890-= 5766672476662576766623323222 17524959F00134678ABC0A8362ED01234567890DD000 -- Am I wrong to expect that editing or viewing an existing file or member in ASCII or UTF-8 mode should consistently use the ASCII/UTF-8 space character X'20'? Peter P.S. - This is on a z/OS V2.1 system. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OT - Bash Vunerability
I just saw this. Might be old news to some, but new to me. http://tinyurl.com/k5xevos In Heartbleed's wake, Bash flaw puts Linux, Mac OS users at risk by Brandan Blevins, News Writer Researchers say a 20-year-old vulnerability uncovered in the Bash shell, found in Unix-based operating systems including Linux and Mac OS, could lead to a dangerous worm outbreak unlike anything seen in more than a decade. Discovered by UK-based Unix expert Stéphane Chazelas, the Bash vulnerability, also known as Shellshock or CVE-2014-6271, actually dates back more than 20 years and is present in every shell version up to 4.3. US-CERT's National Vulnerability Database has rated the flaw's severity as a 10.0, which is the highest possibly severity, based on the common vulnerability scoring system (CVSS), in large part because it is so easily exploited: the bug can be triggered remotely without any form of authentication. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT - Bash Vunerability
Fairly new, as in just today. There are patches for SUSE and Redhat Linux on z. I have applied the equivalent on my RedHat Fedora 20 on Intel. I need to patch the BASH port on the CBTtape, but that is a future (hopefully near future) event. On Thu, Sep 25, 2014 at 10:44 AM, Lizette Koehler stars...@mindspring.com wrote: I just saw this. Might be old news to some, but new to me. http://tinyurl.com/k5xevos In Heartbleed's wake, Bash flaw puts Linux, Mac OS users at risk by Brandan Blevins, News Writer Researchers say a 20-year-old vulnerability uncovered in the Bash shell, found in Unix-based operating systems including Linux and Mac OS, could lead to a dangerous worm outbreak unlike anything seen in more than a decade. Discovered by UK-based Unix expert Stéphane Chazelas, the Bash vulnerability, also known as Shellshock or CVE-2014-6271, actually dates back more than 20 years and is present in every shell version up to 4.3. US-CERT's National Vulnerability Database has rated the flaw's severity as a 10.0, which is the highest possibly severity, based on the common vulnerability scoring system (CVSS), in large part because it is so easily exploited: the bug can be triggered remotely without any form of authentication. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP Question
On Tue, 23 Sep 2014 09:23:54 -0500, Bill Godfrey wrote:
I have seen the very misleading 451 message when attempting this with a USS
file in which the last line does not end with hex 15.
I tried the following script (on Solaris):
550$ cat bin/longline
#! /bin/sh -x
# Doc: create a large file consisting of only a single line.
target=$HOME/work/bigline
# On ASCII system, \n is '\012'
: amp; { tr -d '\012' /dev/random |
ssh $MVS_USER@$MVS_HOST set -x
{ dd bs=1000 count=1000; echo; } |
tee $target | wc; }
cd $TMPDIR
ftp $MVS_HOST eod
verbose
ascii
cd $HOME/work
get bigline long1
site encoding=mbcs
site mbdataconn=(IBM-1047,UTF-8)
get $target long2
quit
eod
... with the results:
...
+ dd bs=1000 count=1000
+ wc
FSUM6384 844+156 records in
844+156 records out
+ echo
1 17014 863161
... Why not 101? That's for MVS-OE.
...
Verbose mode on.
200 Representation type is Ascii NonPrint
250 HFS directory .../work is the current working directory
200 Port request OK.
125 Sending data set .../work/bigline
250 Transfer completed successfully.
local: long1 remote: bigline
862162 bytes received in 0.037 seconds (22973.67 Kbytes/s)
200 SITE command was accepted
200 SITE command was accepted
200 Port request OK.
125 Sending data set .../work/bigline
451 File transfer failed. Multi-byte data conversion error occurred
221 Quit command received. Goodbye.
There's *no* character that can't be converted from IBM-1047 to UTF-8.
I suspect that when doing a MBCS conversion, FTP attempts to break the
input data into lines and convert them one at a time. Perhaps it is done
this way from concern that a buffer might otherwise contain an incomplete
character. In:
http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.bpxbd00/iconvp.htm
iconv() — Code conversion
z/OS XL C/C++ Runtime Library Reference
SC14-7314-00
...
If the input buffer ends with an incomplete character or shift sequence,
conversion stops
after the previous successfully converted bytes, and iconv() sets errno to
EINVAL.
There's a straightforward technique to recover from this that does not require
breaking
the input data into lines nor a priori knowedge of where the data may be
separated
into characters.
They could have done better.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT - Bash Vunerability
It appeared several days ago in this week's US-CERT new-vulnerabilities summary. Subscriptions to this summary are free, and those who have security responsibilities should certainly be email subscribers. If you wait to read about such problems you risk being without answers to management questions about them. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT - Bash Vunerability
On Thu, 25 Sep 2014 12:18:53 -0400, John Gilmore wrote: It appeared several days ago in this week's US-CERT new-vulnerabilities summary. Subscriptions to this summary are free, and those who have security responsibilities should certainly be email subscribers. If you wait to read about such problems you risk being without answers to management questions about them. ... not to mention the (less likely) risk of an actual exploit. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT - Bash Vunerability
Substantive concern about exploits is minimal in many z/OS shops; concern about looking bad to management is not. I chose what I judged would be the more persuasive argument for keeping oneself informed. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?!
On Thu, 25 Sep 2014 11:43:23 -0400, Farley, Peter x23353 wrote: Discovered this unpleasant fact today: Editing or Viewing an existing RECFM=VB UTF-8 file or PDS(E) member uses X'40' for the trailing spaces on screen (i.e., the part of each record past the end of the actual record contents). Editing a new file or PDS(E) member using ASCII or UTF-8 mode uses X'20' for spaces as expected. ... Am I wrong to expect that editing or viewing an existing file or member in ASCII or UTF-8 mode should consistently use the ASCII/UTF-8 space character X'20'? P.S. - This is on a z/OS V2.1 system. ISPF Edit is stupid and obsessive concerning trailing spaces. AFAIK, there's no way to add trailing spaces to a record, nor to remove some but not all of them. I'm dismayed but not surprised with what you observe. The hex display should distinguish between blanks present in the line and the area beyond the end of the line. Browse does this well: blanks appear as '40'; nonexistent characters as blank space in the hex display. BTW, how do non-ASCII UTF-8 characters, code points above 0xFF, appear in the hex display? Does ISPF add a third or fourth line of hex as needed? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?!
Why do I feel the need to defend things like ISPF too often here? The ISPF editor makes a nulls mode available; it provides for optional warning messages when blanks are truncated; etc., etc. In general, it is much more parametric, both globally and for individual users, than this discussion has so far suggested. Moreover, there are elaborate facilities made available for supplying and using exits than can modify its behavior. It is an old, cosmetically ugly beast; and in many but not all situations there are better alternatives to it available. It is not nearly so bad as it is being represented as being. Are we perhaps dealing here yet again with atrophied skill sets? With people who no longer know how to use the facilities that IBM makes available to them? With systems programmers who are non-programmers? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL 5 compile options
AFP: I'm thinking we're safe chosing NOVOLATILE. We don't even use floati= ng-point, so perhaps it doesn't even matter what option we choose. COBOLV 5 will use floating-point registers for fixed point math at higher ARCH levels. in some cases we convert DISPLAY numeric data item to DFP (Decimal Floating Poiint) rather than packed decimal to do the math. On the other hand, we think NOVOLATILE is mostly safe. DISPSIGN: I can't think of any harm in specifying SEP. Certainly makes di= splays of negative signed fields easier to read. I agree, DISPLAY output is for humans HGPR: NOPRESERVE, since we're almost entirely COBOL calls COBOL, except = for a few COBOL calls assembler routines. Is there anything I should loo= k at in the latter case to make sure NOPRESERVE doesn't cause any issues? This one needs more research. For example, EXEC SQL calls DB2, which could thhen switch to AMODE 64 and change the regs. On the other hand, I did a service search and found a case where DB2 was fixed when it inadvertantly changed the upper halves of some regs. We know for sure that NOPRESERVE is safe, and PRESERVE should be safe, but we need more data! Other than NUMPROC, discussed in my previous post, I think these are the on= ly ones I'm concerned about. In your NUMPROC discussion you compared signed to unsigned, but NUMPROC is more about signed data to signed data. If you get nonpreferred signs as input data then you need to run with NUMPROC(NOPFD) to make sure you get correct results. I gave a presentation at SHARE about one way to check if you can use NUMPROC(PFD), please see my recent SHARE presentation, Coding for Performance. The relevant parts are here: NUMPROC(NOPFD) - NUMPROC(PFD) is faster Performance considerations using NUMPROC: - On the average, NUMPROC(PFD) was 1% faster than NUMPROC(NOPFD), with a range of 21% faster to equivalent. Investigate your signed data in External Decimal and Packed-decimal - How can you do that? It is not easy, but if you really want to: If NUMERIC with NUMPROC(PFD) will tell you if you need NOPFD 1 Create a sniffer program from existing programs to access all of the data 2 Use IF NUMERIC (CLASS TEST) for every data item in files and DBs 3 If 100% NUMERIC, change to NUMPROC(PFD)! * Compile sniffer with NUMPROC(PFD) EXEC SQL SELECT Ext-Dec Packed-Dec INTO :X, :Y END-EXEC If X NUMERIC and Y NUMERIC Then Display Use NUMPROC(PFD)! Move 2 To Return-Code Else Display Sorry, use NUMPROC(NOPFD)! Move 16 To Return-Code* Or call CEE3ABD Stop Run End-If Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?!
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, September 25, 2014 12:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?! Snipped BTW, how do non-ASCII UTF-8 characters, code points above 0xFF, appear in the hex display? Does ISPF add a third or fourth line of hex as needed? No, all on the same line as additional characters, like this for the British pound symbol followed by the digit 1 and a space: £1 CA32 2310 Or this for a capital letter B followed by the dagger character and a space: B 4E8A2 22000 Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?!
John, AFAIK, only system programmers can set up ISPF exits, and I am not a sysprog. The use of EBCDIC X'40' characters for trailing (non-existent) spaces in a putatively ASCII/UTF-8 edit or view display is both jarring and wrong. I did have NULLS ON in the displays I showed, but those were existing lines of text transmitted to z/OS from elsewhere. It is not the entering of data which is the issue here, but the display of existing data. I am not particularly against the ISPF editor function; in fact it has facilities I sorely miss when using other platform editors. But this behavior is not acceptable. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Thursday, September 25, 2014 1:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?! Why do I feel the need to defend things like ISPF too often here? The ISPF editor makes a nulls mode available; it provides for optional warning messages when blanks are truncated; etc., etc. In general, it is much more parametric, both globally and for individual users, than this discussion has so far suggested. Moreover, there are elaborate facilities made available for supplying and using exits than can modify its behavior. It is an old, cosmetically ugly beast; and in many but not all situations there are better alternatives to it available. It is not nearly so bad as it is being represented as being. Are we perhaps dealing here yet again with atrophied skill sets? With people who no longer know how to use the facilities that IBM makes available to them? With systems programmers who are non-programmers? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?!
A further discovery - Using the EA (Edit ASCII) command from the UDLIST display of a Unix File System directory of a copy of exactly the same data does NOT use X'40' for trailing (non-existent) spaces, but the expected X'20' instead. So the behavior seems to relate to the file system source of the data; from classic MVS-type files the unexpected X'40' is used, from HFS/ZFS directories the expected X'20' is used. Possibly fixable, possibly (B/W)AD. If someone who has authority to report bugs wishes to make a report, it would be interesting to hear IBM's response. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Thursday, September 25, 2014 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?! Discovered this unpleasant fact today: Editing or Viewing an existing RECFM=VB UTF-8 file or PDS(E) member uses X'40' for the trailing spaces on screen (i.e., the part of each record past the end of the actual record contents). Editing a new file or PDS(E) member using ASCII or UTF-8 mode uses X'20' for spaces as expected. Snipped -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5 compile options
Thanks Tom! For HGPR, don't you mean the reverse of what you said? PRESERVE would always be save because COBOL preserves and restores the high-halves of the registers, right? Safer, but not as efficient? As for NUMPROC, thanks for the info. Seems to me the documentation could be made clearer, though I don't know exactly all. In the end I can't imagine doing what you suggest, even though it's the only way to be sure. So we'll probably, unfortunately, just go with NOPFD. But thanks a lot for the info!! Question about one additional option. We use TRUNC(STD) right now. What would be have to be aware of if we wanted to switch to TRUNC(OPT) (where I assume OPT = optimize)? Is OPT fully compliant with COBOL standard truncation rules? Thanks! Frank FirstBank From: Tom Ross tmr...@stlvm20.vnet.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, September 25, 2014 11:32 AM Subject: COBOL 5 compile options AFP: I'm thinking we're safe chosing NOVOLATILE. We don't even use floati= ng-point, so perhaps it doesn't even matter what option we choose. COBOLV 5 will use floating-point registers for fixed point math at higher ARCH levels. in some cases we convert DISPLAY numeric data item to DFP (Decimal Floating Poiint) rather than packed decimal to do the math. On the other hand, we think NOVOLATILE is mostly safe. DISPSIGN: I can't think of any harm in specifying SEP. Certainly makes di= splays of negative signed fields easier to read. I agree, DISPLAY output is for humans HGPR: NOPRESERVE, since we're almost entirely COBOL calls COBOL, except = for a few COBOL calls assembler routines. Is there anything I should loo= k at in the latter case to make sure NOPRESERVE doesn't cause any issues? This one needs more research. For example, EXEC SQL calls DB2, which could thhen switch to AMODE 64 and change the regs. On the other hand, I did a service search and found a case where DB2 was fixed when it inadvertantly changed the upper halves of some regs. We know for sure that NOPRESERVE is safe, and PRESERVE should be safe, but we need more data! Other than NUMPROC, discussed in my previous post, I think these are the on= ly ones I'm concerned about. In your NUMPROC discussion you compared signed to unsigned, but NUMPROC is more about signed data to signed data. If you get nonpreferred signs as input data then you need to run with NUMPROC(NOPFD) to make sure you get correct results. I gave a presentation at SHARE about one way to check if you can use NUMPROC(PFD), please see my recent SHARE presentation, Coding for Performance. The relevant parts are here: NUMPROC(NOPFD) - NUMPROC(PFD) is faster Performance considerations using NUMPROC: - On the average, NUMPROC(PFD) was 1% faster than NUMPROC(NOPFD), with a range of 21% faster to equivalent. Investigate your signed data in External Decimal and Packed-decimal - How can you do that? It is not easy, but if you really want to: If NUMERIC with NUMPROC(PFD) will tell you if you need NOPFD 1 Create a sniffer program from existing programs to access all of the data 2 Use IF NUMERIC (CLASS TEST) for every data item in files and DBs 3 If 100% NUMERIC, change to NUMPROC(PFD)! * Compile sniffer with NUMPROC(PFD) EXEC SQL SELECT Ext-Dec Packed-Dec INTO :X, :Y END-EXEC If X NUMERIC and Y NUMERIC Then Display Use NUMPROC(PFD)! Move 2 To Return-Code Else Display Sorry, use NUMPROC(NOPFD)! Move 16 To Return-Code* Or call CEE3ABD Stop Run End-If Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 5 compile options
DISPSIGN only affects fields in a DISPLAY statement. With your S999 DISPLAY example, let's say field (let.s name it ZONED-FIELD-1) was set to -987. DISPLAY QUOTE ZONED-FIELD-1 QUOTE Output with DISPSIGN(COMPAT): 98P Output with DISPSIGN(SEP): -987 The size of the field is unchanged (it's still signed zoned, 3 bytes). It's just that it's displayed as a 4 character text string. Now we just need DISPDEC(YES) to show the decimal position indicator (the period for a init integer field), e.g.: -987.65 instead of -98765 for a PIC S999V99 (any USAGE) field. Maybe next release! Frank From: Clark Morris cfmpub...@ns.sympatico.ca To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, September 24, 2014 8:51 PM Subject: Re: COBOL 5 compile options On 24 Sep 2014 18:27:34 -0700, in bit.listserv.ibm-main you wrote: AFP: I'm thinking we're safe chosing NOVOLATILE. We don't even use floating-point, so perhaps it doesn't even matter what option we choose. DISPSIGN: I can't think of any harm in specifying SEP. Certainly makes displays of negative signed fields easier to read. Since I think this would affect existing record descriptions, I would test before making a decision. If your current display numeric fields (PIC S999 USAGE DISPLAY) do not have the SIGN IS SEPARATE clause this option may force it on recompile which would increase the size of the field by 1 byte. I'm not certain what the valid sign characters would be. Clark Morris HGPR: NOPRESERVE, since we're almost entirely COBOL calls COBOL, except for a few COBOL calls assembler routines. Is there anything I should look at in the latter case to make sure NOPRESERVE doesn't cause any issues? Other than NUMPROC, discussed in my previous post, I think these are the only ones I'm concerned about. Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
BASH - CVE 10
This just in: TA14-268A: GNU Bourne Again Shell (Bash) ‘Shellshock’ Vulnerability (CVE-2014-6271,CVE-2014-7169) Systems affected: o GNU Bash through 4.3. o Linux, BSD, and UNIX distributions including but not limited to: CentOS 5 through 7 Debian Mac OS X Red Hat Enterprise Linux 4 through 7 Ubuntu 10.04 LTS, 12.04 LTS, and 14.04 LTS John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Defaults (Was: SLIP IF Trap?)
Hello all, As a DB2 v10 recommendation we have set out MAXSPACE to 1M (10GB). We had to increase Central and Auxiliary (PAGE) storage in order to do this. If a DB2 dump is taken things can get nasty storage-wise when running with this recommended value. Regards, *Lucas Rosalen* 2014-09-25 7:31 GMT-03:00 Elardus Engelbrecht elardus.engelbre...@sita.co.za: Ed Jaffe wrote: I noticed our most important systems issue the following command in COMMNDxx: CD SET,SDUMP=(RGN,CSA,LPA),ADD,MAXSPACE=5000M Just only that? What about LSQA, NUC, PSA, SUMDUMP and other friends? Beside MAXSPACE, what is the size of BUFFERS? (We got it at 8M) ... probably inherited from something someone did before the last millennium. Someone TRACE-able must have SLIPped up and DUMPed something... :-D Does anyone have any other (21st-century) recommendations for improving this? I'm also curious about those recommendations. What about settings for SYSMDUMP? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?!
On Sep 25, 2014, at 11:46 AM, Paul Gilmartin wrote: ISPF Edit is stupid and obsessive concerning trailing spaces. AFAIK, there's no way to add trailing spaces to a record, nor to remove some but not all of them. I'm dismayed but not surprised with what you observe. The hex display should distinguish between blanks present in the line and the area beyond the end of the line. Browse does this well: blanks appear as '40'; nonexistent characters as blank space in the hex display. Paul, Maybe because I have leaned to love it (ISPF edit) I have gotten used to its restrictions. btw you can lengthen VB (ie clist) files quite easily example: ch dsn dsname Or I suppose ch dsname to dsn Adding blanks (t the end is a little hard) but IIRC it can be done I don't have a system on to try it but in the past I have done it more than a few time all you have to is sit and think like ISPF and the HW and TSO. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT - Bash Vunerability
While we're being OT here, can anyone explain this to me in practical terms? Sally has a basic everyday Mac running unpatched OS X. It is connected to the Internet for Web browsing and e-mail, but she does not operate a Web server. Let's for argument's sake assume no firewall. Is Sally vulnerable to this? I am guessing that if she is vulnerable it is because someone can telnet to her machine, run the Bash shell, and trick OS X into executing arbitrary commands in some sort of su-type mode? Yes? No? If she's not vulnerable, what sort of *IX machine is? If this is too OT for your taste you could reply privately. Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, September 25, 2014 8:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OT - Bash Vunerability Fairly new, as in just today. There are patches for SUSE and Redhat Linux on z. I have applied the equivalent on my RedHat Fedora 20 on Intel. I need to patch the BASH port on the CBTtape, but that is a future (hopefully near future) event. On Thu, Sep 25, 2014 at 10:44 AM, Lizette Koehler stars...@mindspring.com wrote: I just saw this. Might be old news to some, but new to me. http://tinyurl.com/k5xevos In Heartbleed's wake, Bash flaw puts Linux, Mac OS users at risk by Brandan Blevins, News Writer Researchers say a 20-year-old vulnerability uncovered in the Bash shell, found in Unix-based operating systems including Linux and Mac OS, could lead to a dangerous worm outbreak unlike anything seen in more than a decade. Discovered by UK-based Unix expert Stéphane Chazelas, the Bash vulnerability, also known as Shellshock or CVE-2014-6271, actually dates back more than 20 years and is present in every shell version up to 4.3. US-CERT's National Vulnerability Database has rated the flaw's severity as a 10.0, which is the highest possibly severity, based on -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT - Bash Vunerability
On Thu, 25 Sep 2014 16:47:29 -0700, Charles Mills wrote: While we're being OT here, can anyone explain this to me in practical terms? Sally has a basic everyday Mac running unpatched OS X. It is connected to the Internet for Web browsing and e-mail, but she does not operate a Web server. Let's for argument's sake assume no firewall. Is Sally vulnerable to this? I am guessing that if she is vulnerable it is because someone can telnet to her machine, Not unless she enables telnet in System Preferences. I don't even know if that's an option. ssh is. I rarely turn it on. run the Bash shell, and trick OS X into executing arbitrary commands in some sort of su-type mode? Yes? No? If she's not vulnerable, what sort of *IX machine is? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT - Bash Vunerability
Thanks. I'm reading http://en.wikipedia.org/wiki/Shellshock_(software_bug) and I sort of get it. I guess the worry is that the effects are so unknown. IF there is a situation where a user can set an environment variable to some arbitrary value and IF that variable gets passed to a child process, the child process will end up executing the user's malicious command appended to the environment variable. What are all the situations where that might happen? I guess no one knows, and that is the problem. Note that there is also a variant out there now, as yet apparently unpatched, CVE-2014-7169. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, September 25, 2014 5:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OT - Bash Vunerability On Thu, 25 Sep 2014 16:47:29 -0700, Charles Mills wrote: While we're being OT here, can anyone explain this to me in practical terms? Sally has a basic everyday Mac running unpatched OS X. It is connected to the Internet for Web browsing and e-mail, but she does not operate a Web server. Let's for argument's sake assume no firewall. Is Sally vulnerable to this? I am guessing that if she is vulnerable it is because someone can telnet to her machine, Not unless she enables telnet in System Preferences. I don't even know if that's an option. ssh is. I rarely turn it on. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Defaults (Was: SLIP IF Trap?)
On Thu, 25 Sep 2014 18:08:02 -0300, Lucas Rosalen wrote: As a DB2 v10 recommendation we have set out MAXSPACE to 1M (10GB). We had to increase Central and Auxiliary (PAGE) storage in order to do this. If a DB2 dump is taken things can get nasty storage-wise when running with this recommended value. DB2 support with an over-the-top recommendation. How unusual is that ?. I was interested in how many people had found 5000M was enough though. I've had CICS dumps eat more than that in a reasonably small system. Partial dumps are a no-no, even though they may have all you need in them. Maybe. MAXSPACE is easy to determine at least. Pick your biggest, baddest environment that you care about (SAP, DB2, OMVS, whatever ...) and issue a dump. Multi address-space with dataspaces will generally do the job. If you get a partial dump, increase it - rinse, spin, repeat. Do it on a representative non-prod system - especially if you do synchronous dumps. Sandpits tend to be too small. As for the options, Barbara covered that. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
