Re: COBOL Compiller options in IGYCDOPT
There's a discussion on the AWO option that may be of interest here: https://www.ibm.com/developerworks/community/forums/html/topic?id=4a12d0d1-9847-4e01-9586-e0897241edc0 Of note is this phrase from the manual: The APPLY-WRITE ONLY clause can cause input files to use a record area rather than process the data in the buffer. This use might affect the processing of both input files and output files. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of David Speake Sent: Monday, March 23, 2015 3:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL Compiller options in IGYCDOPT Is there a historian in the house? Why is NOAWO the IBM default - since forever? I outlined for my SYSPROG the horrendous effect of LRECLs say of 80 and 32720 on device end channel traffic, run time and resource utilization. Question was raised about work loads that it might favor and why. There may be such workloads but I cannot imagine what they might be nor why. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: $HASP311 jobname re-queued at end of memory and held
On Tue, 24 Mar 2015 09:02:49 +0100, Peter Hunkeler wrote: So, the action taken at next warmstart will be determined by the setting of JOURNAL and RESTART on JOBCLASS. However, you could decide to release the job ($AJ) or cancel it ($PJ) immediately. ... And an additional hint: The job is requeued back for execution (per the $HASP311 message) since JOURNALing is active. You can confirm this by issuing a $DJOBCLASS(y),LONG where y is the respective jobclass of DB2A7417 and I would expect you find JOURNAL=YES. This is working as expected. Thanks for the update Peter. Sounds like a perfect opportunity for JES2 support to get organised and maybe set up a Health Checker to accommodate this scenario. Or do they really expect us to schedule warmstarts regularly just for them ... ? Too mundane a situation to bother JES2MON I guess. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unscheduled automatic reIPL on z10
Thanks to all who shared tips and experiences both off- and on-list. A PMR has been opened and I have changed AUTOIPL to take a standalone dump, which I have tested. By the way for the sake of completeness, the command to trigger a SAD is V XCF,sysname,OFF,SADMP Regards and thanks Paul Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983. This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with takesocket in another ASID
I wrote a simple test-bed that just call BPX1TAK() to pick up the socket and it worked fine whether called from C, HLASM or HLASM invoked from C (so LE is active). So that's the way we will go. Thanks to everyone who responded. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: 21 March 2015 00:25 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Problems with takesocket in another ASID On 20 March 2015 at 08:02, Robin Atwood abend...@gmail.com wrote: David - Thank you very much, your explanation has been most helpful. So my choices are: 1. Code a lot of wrappers so the C code can call the EZASMI macros 2. Change the ASM code to use BPX* calls The amount of coding is probably about the same but choice 2 is preferable because we have a lot more customers using server 1. There are a couple of other reasons to prefer (2). If you contemplate using AT-TLS on your connections at some point, there are cases where AT-TLS calls return a return code and a reason code, where the return code is not unique and requires the reason code to disambiguate it. While EZASMI does support AT-TLS, it offers no mechanism to return a reason code for any operation, and IBM appears to have no plans to rectify this. The BPX* calls all have provision to return a reason code. [In passing, the return codes from EZASMI and BPX* socket calls are different (!) That is, the symbolic RC names like EAGAIN or ETIMEDOUT are consistent, but the numeric values are different. Well maybe that doesn't matter, but if you want to retrieve error message text from a table or system service, you need to have them right.] It's not obvious to me that, even if you wrote wrappers for EZASMI in a C environment, LE would properly support the environment required for EZASMI calls. I am aware of no specific problems, but it's the kind of why would anyone want to do that? issue that might easily be dismissed if you run into a problem. For that matter it's not clear to me that IBM will continue the EZASMI interface indefinitely. It's clearly being maintained for compatibility reasons, but as demand drops they could just say as of release nnn you must convert. And if you believe the picture in the Sockets API book http://www-01.ibm.com/support/knowledgecenter/api/content/nl/en-us/SSLTBW_2.1.0/com.ibm.zos.v2r1.hala001/socketlib.htm#socketlib__apirel you can see that the EZASMI interface is just a front end to the BPX* code in any case, so presumably it performs better. Tony H. -- 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: Sharing a zIIP
Of course there is the option to not allow any IIP work to go to CPs by setting IIPHONORPRIORITY=NO. In this case IIP work is run only on IIPs in priority order. This may cause unacceptable waits. The AHONORPRIORITY=NO works the same way for zAAPs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA-Datacom
You can use the CICS application DDOL (DataDictionary Online) if available, or query the Directory dynamic system tables DIR_TABLE and DIR_COLUMN. If you have not done so, I suggest creating an account with CA Support. You can get all the needed documention, and the support staff for Datacom/DB are very helpful. Jim IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU writes: Hello. I am new to datacom in my new project the database used is datacom. Could some one please let me know how to get the table layout of a datacom table so that i can see what type each field is , and also the bytes it occupies? Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: $HASP311 jobname re-queued at end of memory and held
On Tue, 24 Mar 2015 09:02:49 +0100, Peter Hunkeler wrote: an End-of-Memory condition The way I used to understand it is that a Memory was once a common term for an an address space, and that the End of memory message simply meant that the address space (the initiator) terminated, taking the job with it. I'm not sure if my understanding is correct. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retrieve unallocated space numbers?
IDCAMS DCOLLECT by volume into a file. LSPACE Macro for in program use. http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idas300/s3041.htm?lang=en On Tue, Mar 24, 2015 at 4:44 PM, Charles Mills charl...@mcn.org wrote: Is there a DFSMS macro or callable service that returns the amount of unallocated space left on a volume or SMS storage group? My first preference would be results in a binary-type control block but I could live with a TSO command that gave me printable data. Am I the only person who thinks it is needlessly difficult finding things in the DFSMS documentation? SHOWCAT is logically enough in Macro Instructions for Data Sets but LOCATE and CAMLST are in DFSMSdfp Advanced Services. And what does this mean under SHOWCAT? The information shown here is provided for compatibility only. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retrieve unallocated space numbers?
Well look at that! Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Tuesday, March 24, 2015 2:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Retrieve unallocated space numbers? IDCAMS DCOLLECT by volume into a file. LSPACE Macro for in program use. http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idas300/s3041.htm?lang=en -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Retrieve unallocated space numbers?
Is there a DFSMS macro or callable service that returns the amount of unallocated space left on a volume or SMS storage group? My first preference would be results in a binary-type control block but I could live with a TSO command that gave me printable data. Am I the only person who thinks it is needlessly difficult finding things in the DFSMS documentation? SHOWCAT is logically enough in Macro Instructions for Data Sets but LOCATE and CAMLST are in DFSMSdfp Advanced Services. And what does this mean under SHOWCAT? The information shown here is provided for compatibility only. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retrieve unallocated space numbers?
In 0c0601d0667b$af430540$0dc90fc0$@mcn.org, on 03/24/2015 at 02:44 PM, Charles Mills charl...@mcn.org said: Am I the only person who thinks it is needlessly difficult finding things in the DFSMS documentation? No. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retrieve unallocated space numbers?
In cajtoo5-xtgwb8oeur15bzy8r25jjgdejclyw8owwkbbuvnp...@mail.gmail.com, on 03/24/2015 at 04:51 PM, Mike Schwab mike.a.sch...@gmail.com said: IDCAMS DCOLLECT by volume into a file. LSPACE Macro for in program use. Both of those require that you first determine what the volunmes in the storage group are. I doubt that's what the OP had in mind. Is there an open requirement for a sewrvice that, given a group name, will return the size of the largest free block and the total free space? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Compiller options in IGYCDOPT
Thank you one and all. Especially Lizzete in an offline. https://www.ibm.com/developerworks/community/forums/html/topic?id=4a12d0d1-9847-4e01-9586-e0897241edc0 and the topics pointed to by it rang all the bells. Both input and output are forced to move mode as opposed to locate mode. This causes a small CPU penalty in both cases. Obviously (now, ouch) you cannot operate in the output buffer if the space remaining available is less than the length of the record you are trying to build - S0C4. Hence you build it in a work area long enough for the longest possible record and WRITE moves it to the buffer if there is room (with AWO). Without AWO or APPLY WRITE-ONLY for the file the buffer must always have room for you the construct the next record as a maximum length record. Why it affect the inputs I still do not quite understand but I do know that it does -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retrieve unallocated space numbers?
If you have MXI, then you may find SGRP gives you what you want. On 24 March 2015 at 22:22, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In cajtoo5-xtgwb8oeur15bzy8r25jjgdejclyw8owwkbbuvnp...@mail.gmail.com, on 03/24/2015 at 04:51 PM, Mike Schwab mike.a.sch...@gmail.com said: IDCAMS DCOLLECT by volume into a file. LSPACE Macro for in program use. Both of those require that you first determine what the volunmes in the storage group are. I doubt that's what the OP had in mind. Is there an open requirement for a sewrvice that, given a group name, will return the size of the largest free block and the total free space? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: $HASP311 jobname re-queued at end of memory and held
Note also the DIAGxx parameter VSM CHECKREGIONLOSS(above,below) which looks at an initiator address space at the end of each job and automatically restarts the initiator if a loss of virtual storage exceeding the specified values is detected. This parameter is intended to avoid or minimize job errors due to initiator storage getting fragmented or by storage creep. I think CHECKREGIONLOSS was introduced in z/OS 1.11? Not sure. Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, 24 March 2015 5:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: $HASP311 jobname re-queued at end of memory and held Cross-posted to IBM-MAing and JES2-L A while ago I was seeking for help regarding jobs being re-queued at an EOM situation. I did not get the desired insight here, so we asked IBM for details. We got below explanation, which IBM support found in internal documents, only, but not in any FM. I thought I'd post it here so it will be available in the archives. Q:We have a DB2 batch job that suffers from several S878-10 and finally the initiator fails completely. At the end of that a JES2 message $HASP311 appears and the job sits in the hold queue from then. Why is the job re-queued and where is that documented? Answer from IBM support (19/02/15 13:25): $HASP311 with the associated message text is always issued by JES2 in response to a request by the Initiator to requeue the job that has gone though EOM processing. This is normal behavior and is not new and not a defect. From a JES2 perspective this has always worked this way. It is the Initiator that is requesting the requeue of the job AND if there was an EOM involved before job completion $HASP311 is issued with the corresponding text. ... and a bit more and better explanation: There are a few reasons why a job could be marked for re-execution, but the most common cause is that the initiator (where the job executes in), AND NOT THE JOB ITSELF, experiences an error, like an End-of-Memory condition which appears to be your case (the 40D indicates an out-of-storage condition during RTM processing, usually following ABEND80A or ABEND878). In that case, we turn on a flag in the control block structure to indicate that the job is eligible for restart (this is the same flag that would be set if $EJOB command was used to restart a job). JES2 requeues the job for warmstart and puts it in operator hold to prevent the job from failing recursively. During warmstart processing, JES2 will decide whether this job needs to be automatically restarted based on the setting of JOURNAL and RESTART option. The JES2 Init and Tuning Guide has more details about this under topic 1.13.2.6 titled 'Warm start considerations'. Here is an excerpt: ...If a job in execution was journaled, it is updated to indicate warmstart, and the job is queued for re-execution. If a job in execution has no journal, it is tested to determine whether restart was indicated for the job. If restart was indicated, the job is updated to remove any warmstart indications, and the job is queued for re-execution. If restart was not indicated, the job is queued for output processing. So, the action taken at next warmstart will be determined by the setting of JOURNAL and RESTART on JOBCLASS. However, you could decide to release the job ($AJ) or cancel it ($PJ) immediately. ... And an additional hint: The job is requeued back for execution (per the $HASP311 message) since JOURNALing is active. You can confirm this by issuing a $DJOBCLASS(y),LONG where y is the respective jobclass of DB2A7417 and I would expect you find JOURNAL=YES. This is working as expected. -- 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: $HASP311 jobname re-queued at end of memory and held
Oh... of course the proper syntax is VSM CHECKREGIONLOSS(below,above) not (above,below), if anyone cares. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Anthony Thompson Sent: Tuesday, 24 March 2015 6:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: $HASP311 jobname re-queued at end of memory and held Note also the DIAGxx parameter VSM CHECKREGIONLOSS(above,below) which looks at an initiator address space at the end of each job and automatically restarts the initiator if a loss of virtual storage exceeding the specified values is detected. This parameter is intended to avoid or minimize job errors due to initiator storage getting fragmented or by storage creep. I think CHECKREGIONLOSS was introduced in z/OS 1.11? Not sure. Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, 24 March 2015 5:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: $HASP311 jobname re-queued at end of memory and held Cross-posted to IBM-MAing and JES2-L A while ago I was seeking for help regarding jobs being re-queued at an EOM situation. I did not get the desired insight here, so we asked IBM for details. We got below explanation, which IBM support found in internal documents, only, but not in any FM. I thought I'd post it here so it will be available in the archives. Q:We have a DB2 batch job that suffers from several S878-10 and finally the initiator fails completely. At the end of that a JES2 message $HASP311 appears and the job sits in the hold queue from then. Why is the job re-queued and where is that documented? Answer from IBM support (19/02/15 13:25): $HASP311 with the associated message text is always issued by JES2 in response to a request by the Initiator to requeue the job that has gone though EOM processing. This is normal behavior and is not new and not a defect. From a JES2 perspective this has always worked this way. It is the Initiator that is requesting the requeue of the job AND if there was an EOM involved before job completion $HASP311 is issued with the corresponding text. ... and a bit more and better explanation: There are a few reasons why a job could be marked for re-execution, but the most common cause is that the initiator (where the job executes in), AND NOT THE JOB ITSELF, experiences an error, like an End-of-Memory condition which appears to be your case (the 40D indicates an out-of-storage condition during RTM processing, usually following ABEND80A or ABEND878). In that case, we turn on a flag in the control block structure to indicate that the job is eligible for restart (this is the same flag that would be set if $EJOB command was used to restart a job). JES2 requeues the job for warmstart and puts it in operator hold to prevent the job from failing recursively. During warmstart processing, JES2 will decide whether this job needs to be automatically restarted based on the setting of JOURNAL and RESTART option. The JES2 Init and Tuning Guide has more details about this under topic 1.13.2.6 titled 'Warm start considerations'. Here is an excerpt: ...If a job in execution was journaled, it is updated to indicate warmstart, and the job is queued for re-execution. If a job in execution has no journal, it is tested to determine whether restart was indicated for the job. If restart was indicated, the job is updated to remove any warmstart indications, and the job is queued for re-execution. If restart was not indicated, the job is queued for output processing. So, the action taken at next warmstart will be determined by the setting of JOURNAL and RESTART on JOBCLASS. However, you could decide to release the job ($AJ) or cancel it ($PJ) immediately. ... And an additional hint: The job is requeued back for execution (per the $HASP311 message) since JOURNALing is active. You can confirm this by issuing a $DJOBCLASS(y),LONG where y is the respective jobclass of DB2A7417 and I would expect you find JOURNAL=YES. This is working as expected. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataset space release
The ALLOCATE command has a RELEASE parameter 1 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tim Brown Sent: Tuesday, March 24, 2015 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dataset space release Can space in an allocated dataset via Rexx with the tso allocate cmd be freed and space reclaimed as is possible with a jcl allocated dataset with the RLSE option SPACE=(CYL,(10,2),RLSE) if this just needs 6 cyls then the unused 4 will be freed. Can't find a way to do same via TSO and Rexx. Sent from my Verizon Wireless 4G LTE smartphone -- 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
Dataset space release
Can space in an allocated dataset via Rexx with the tso allocate cmd be freed and space reclaimed as is possible with a jcl allocated dataset with the RLSE option SPACE=(CYL,(10,2),RLSE) if this just needs 6 cyls then the unused 4 will be freed. Can't find a way to do same via TSO and Rexx. Sent from my Verizon Wireless 4G LTE smartphone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataset space release
Yes, use the RELEASE parameter of the ALLOCATE command Roger On 3/24/2015 1:52 PM, Tim Brown wrote: Can space in an allocated dataset via Rexx with the tso allocate cmd be freed and space reclaimed as is possible with a jcl allocated dataset with the RLSE option SPACE=(CYL,(10,2),RLSE) if this just needs 6 cyls then the unused 4 will be freed. Can't find a way to do same via TSO and Rexx. Sent from my Verizon Wireless 4G LTE smartphone -- 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: Dataset space release
Thanks, I must of not seen that option. Sent from my Verizon Wireless 4G LTE smartphone Original message From: Roger W. Suhr (GMail) suhr...@gmail.com Date: 03/24/2015 3:00 PM (GMT-05:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dataset space release Yes, use the RELEASE parameter of the ALLOCATE command Roger On 3/24/2015 1:52 PM, Tim Brown wrote: Can space in an allocated dataset via Rexx with the tso allocate cmd be freed and space reclaimed as is possible with a jcl allocated dataset with the RLSE option SPACE=(CYL,(10,2),RLSE) if this just needs 6 cyls then the unused 4 will be freed. Can't find a way to do same via TSO and Rexx. Sent from my Verizon Wireless 4G LTE smartphone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unscheduled automatic reIPL on z10
Thanks for the command syntax. I did not know about the SADMP option. As I mentioned earlier, we first 'exercised' the auto IPL scenario when one LPAR ran out of real storage. System was IPLed around 05:00. No one else even noticed. Like you, I was sure someone had done it, but no, it was actually self-induced. It happened several times. Even with SAD the cause was elusive. With a PMR open, I posted on this list. One esteemed List contributor recalled having made a change to z/OS (!) that could be the culprit. We mirror DASD to our DR site. Occasionally an XRC action would delay an OS I/O operation, causing the I/O to be redriven. However, real storage acquired for the first I/O was not freed, causing a real storage leak that gradually reduced the available frame count to zero. One PTF fixed the problem. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Beesley, Paul Sent: Tuesday, March 24, 2015 6:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unscheduled automatic reIPL on z10 Thanks to all who shared tips and experiences both off- and on-list. A PMR has been opened and I have changed AUTOIPL to take a standalone dump, which I have tested. By the way for the sake of completeness, the command to trigger a SAD is V XCF,sysname,OFF,SADMP Regards and thanks Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CR on records using OCOPY converting from ASCII to EBCDIC
Thank you for the responses. I could not find an OCOPY option that would fix CRLF, unless it was meant for me to build a character conversion table to handle CR? We do not have Info-ZIP installed, and are using the Java JAR command to perform the unzip. It appears the suggestion to run: tr -d \r input.txt input_tr.txt will provide what we need. Another option may be to run a SORT to perform a character replacement after the data is moved from z/OS Unix files to z/OS data sets. Thanks again for the suggestions, Kevin Landin -Original Message- From: Paul Gilmartin [mailto:paulgboul...@aim.com] Sent: Thursday, March 19, 2015 12:26 PM Subject: Re: CR on records using OCOPY converting from ASCII to EBCDIC On Thu, 19 Mar 2015 09:44:56 -0500, Kevin Landin wrote: We FTP a zip file from a vendor as binary to a z/OS Unix file. ... ... Besides editing the file and removing the CR, is there a way to prevent the CR from being written to the z/OS data set during the translation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA-Datacom
Ron, There are other utilizes outside of the online environment that would provide you the same information requested. There is the Batch Utility DDUTILTY that reports exclusively on the Dictionary. You are able to get all sorts of reporting via this Utility. You will be able to find further documentation as to the reports in this Bookshelf: https://supportcontent.ca.com/cadocs/0/CA%20Datacom%2014%200%20Public-ENU/Bookshelf.html There?s also a large number of users that constantly monitor the CA Communities and are always willing to share information: https://communities.ca.com/places?filterID=all~tag%5Bglobal%5DsortKey=all~subjectAscsortOrder=1 Russell Witt CA Technologies On 03/23/15, Ron Thomasron5...@gmail.com wrote: Hello. I am new to datacom in my new project the database used is datacom. Could some one please let me know how to get the table layout of a datacom table so that i can see what type each field is , and also the bytes it occupies? Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: $HASP311 jobname re-queued at end of memory and held
Cross-posted to IBM-MAing and JES2-L A while ago I was seeking for help regarding jobs being re-queued at an EOM situation. I did not get the desired insight here, so we asked IBM for details. We got below explanation, which IBM support found in internal documents, only, but not in any FM. I thought I'd post it here so it will be available in the archives. Q:We have a DB2 batch job that suffers from several S878-10 and finally the initiator fails completely. At the end of that a JES2 message $HASP311 appears and the job sits in the hold queue from then. Why is the job re-queued and where is that documented? Answer from IBM support (19/02/15 13:25): $HASP311 with the associated message text is always issued by JES2 in response to a request by the Initiator to requeue the job that has gone though EOM processing. This is normal behavior and is not new and not a defect. From a JES2 perspective this has always worked this way. It is the Initiator that is requesting the requeue of the job AND if there was an EOM involved before job completion $HASP311 is issued with the corresponding text. ... and a bit more and better explanation: There are a few reasons why a job could be marked for re-execution, but the most common cause is that the initiator (where the job executes in), AND NOT THE JOB ITSELF, experiences an error, like an End-of-Memory condition which appears to be your case (the 40D indicates an out-of-storage condition during RTM processing, usually following ABEND80A or ABEND878). In that case, we turn on a flag in the control block structure to indicate that the job is eligible for restart (this is the same flag that would be set if $EJOB command was used to restart a job). JES2 requeues the job for warmstart and puts it in operator hold to prevent the job from failing recursively. During warmstart processing, JES2 will decide whether this job needs to be automatically restarted based on the setting of JOURNAL and RESTART option. The JES2 Init and Tuning Guide has more details about this under topic 1.13.2.6 titled 'Warm start considerations'. Here is an excerpt: ...If a job in execution was journaled, it is updated to indicate warmstart, and the job is queued for re-execution. If a job in execution has no journal, it is tested to determine whether restart was indicated for the job. If restart was indicated, the job is updated to remove any warmstart indications, and the job is queued for re-execution. If restart was not indicated, the job is queued for output processing. So, the action taken at next warmstart will be determined by the setting of JOURNAL and RESTART on JOBCLASS. However, you could decide to release the job ($AJ) or cancel it ($PJ) immediately. ... And an additional hint: The job is requeued back for execution (per the $HASP311 message) since JOURNALing is active. You can confirm this by issuing a $DJOBCLASS(y),LONG where y is the respective jobclass of DB2A7417 and I would expect you find JOURNAL=YES. This is working as expected. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
