Re: Remove a system from a SYSPLEX but keep it in the GRS ring
We have done this to two 3-system parallel sysplexes. One system was removed from each 3-system sysplex and the removed systems were each defined as a monoplex and rejoined to their former partners in a GRSPLEX. So we now have two GRSPLEXes: each with a 2-system parallel sysplex GRS'd with a monoplex. The complications were few but could be significant depending on your site. The clients only had one issue, and that was due to PDSE sharing. () We left the system names and the SMFID names the same but gave the monoplexes new sysplex names, which affected one system component and a few STC PROCs. () PDSE sharing had to be downgraded to NORMAL for all three systems in each GRSPLEX, which is very problematic if the systems really share PDSEs for UPDATE because NORMAL is very restrictive (read the PDSE Usage Guide closely), so many PDSEs had to be cloned so that there is now one PDSE per system (that is, for many PDSEs, we went from one PDSE for 3 systems with ENHANCED sharing to three PDSEs, each for one system with NORMAL sharing). Fault Analyzer PDSEs and lnklst PDSEs were the most affected. SMSPDSE1 is no longer active with NORMAL sharing. () The GRS CTCs had to be defined as BCTC so an HCD gen was required. () ECS must be turned off so one may see a performance impact () Automatic tape sharing cannot cross the sysplex boundary so the tape drives had to be divided, but the systems in the sysplex could still handle their drives on their own. () Obviously, the monoplex cannot still participate in the sysplex's spool, so you may need to setup a spool and NJE. Depending on how you submit jobs, this may or may not become another issue (like, for a scheduler or restart subsystem). () Some components that use XCF must be reconfigured to use TCPIP or SNA to communicate, like CCI and Mainview. There are other issues like BRODCAST and DAE but they are minor. The biggest loss after PDSE sharing was in recovery. A crash or even normal shutdown must be responded to carefully or GRS may just turn off across the remaining GRS members. GRS can be restarted but it is not always obvious that this has happened as message fly past. You may want to ensure that automation grabs all the messages, if you have automation, to alert the operator and instruct the operator how to restart GRS on the remaining members. regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Remove a system from a SYSPLEX but keep it in the GRS ring
> "(in XCFLOCAL mode)" I am pretty sure XCFLOCAL will not work in the GRSPLEX. I believe the doc states that the system must be a MONOPLEX for GRS to be active. If you want this rescue system to be XCFLOCAL, you will have to keep it outside of a GRSPLEX, and then risk lockout or corruption due to RESERVE or invalid sharing. This is not my recommendation, unless the system is down all of the time, except for real rescue attempts. > "run with CLOCKxx set to ETRMODE=NO?" I believe this will work for the MONOPLEX system but I have not actually tried this. Our MONOPLEXes are still using the ETR. regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on how to debug S0C7 (data exception) abend
As someone pointed out, a s0c7 may not really be due to a bad data field in the last record READ. But, to answer that question, if you did get an SVC dump using SLIP and you included RGN, SWA, TRT: use IP SUMMARY REGS FORMAT to get the DEB chain printed or follow it yourself to find the OPEN DCBs at the time of the SLIP matching. The DCB has the "next record pointer" at +4C . It should be in the "buffer" so you might need to back up one record. AbendAid and Fault Analyzer do this for you but it does not sound like you have those. If the pgm used READ INTO or the compile specified AWO, the record actually being processed is moved from the buffer. If the record description contains an OCCURS DEPENDING ON clause (a variable length table), sometimes the program is not handling examining table entries in a record validly. In the REGS FORMAT report, look for an RTM2WA which may be useful since that will show the PSW and regs, in case you are not adept at reading the RBs. use IP SYSTRACE TIME(LOCAL) to find the interrupt code 0007 to verify the PSW (this will cross check with the RTM2WA PSW and/or the PRB), and look for other errors in the trace (do a find on "RCVY"). If this abend is in a COBOL internal SORT, in a COBOL input or output procedure, the RBs will show the SORT VERB by a LINK to the in-house SORT routine and the input/output procedures are then run from that RB, not the jobstep PRB. regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to display JES2 fields from the PDDB
Hello: You may be better served by using an IF SLIP and writing trace records (A=TRACE) to a GTF that specifies TRACE=SLIP so that you can get a greater variety of PDDB iterations. A dump is going to just get you one PDDB at that point in time. Use $DMOD(modname) to get the address of the exit’s load point. Use that address to build the SLIP. Here is an example of a SLIP one of my co-workers wrote in the past: SLIP SET,IF,DISABLE,ID=TRCJ,ACTION=TRACE,J=JES2, RA=(1A9DE4F8+01F0,1A9DE4F8+0FC6), TD=(STD,REGS), END It looks legit to me. I never did an IF trace for a JES2 exit, but I have used IF for other traces and in those cases I actually coded a module name. The RANGE you code would be the address in your exit where you knew the PDDB’s address was loaded into reg2. You might just place the IF on one instruction (in the above example, he was tracing code path thru some module). And you would add to the TRDATA parameter that the locations pointed to by reg2 should be written to the trace record, e.g., TD=(STD,REGS,2r?+14,2r?+20) Which means “dump the standard trace record and the register values and what reg2 is pointing to plus x’14’ thru x’20’. After you set the SLIP (and warn everyone first that you are setting a PER trap), start the GTF to capture the trace records. Then submit jobs to create PDDBs. For what it's worth, my observation of a PDDB found this combination of values (JES2 v1.11): PDBDRMT is interpreted as a U value or a Rnnn value depending on PDBDNODE. I was only checking for certain values of PDBDNODE so I came up with this partial set of field contents: PDBDNODE PDBDRMT PDBDUSER zero ¬zero spacesPDBDRMT is a U value our-node ¬zero spacesPDBDRMT is Rnnn value. our-node zero U PDBDUSER contains the actual U value our-node zero spaceslocal SYSOUT I did not care if PDBDNODE contained another node's value so I am not going to state what would be in PDBDRMT or PDBDUSER in that case, but the SLIP / TRACE should find that if you need to know. regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS physical memory usage with multiple copies of same load module at different virtual addresses
While this is not quite the same thing as 2 CICS regions using a page of the same load module, take a look in Principles of Operation which talks about how "fork" is handled. From page 3-15 of August 2010 version of POP: The suppression-on-protection function is useful in performing the POSIX fork function, which causes a duplicate address space to be created. The following discussion pertains to when enhanced DAT does not apply, or when enhanced DAT applies but the format-control (FC) bit in the segment-table entry is zero. When forking occurs, the control program causes the same page of different address spaces to map to a single page frame of real storage as long as a store in the page is not attempted. Then, when a store is attempted in a particular address space, the control program assigns a unique page frame to the page in that address space and copies the contents of the page to the new page frame. This last action is sometimes called the copy-on-write function. The control program sets the DAT-protection bit to one in the page-table entry for a page in order to detect an attempt to store in the page. The control program may initially set the DAT-protection bit to one in a segment-table entry to detect an attempt to store anywhere in the specified segment. regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Implicit VVDS creation
The default value for implicitly defined VVDSes can now be specified in the IGGCATxx member of PARMLIB, which is relatively new (z/OS v1.13): VVDSSPACE(primary,secondary) Specifies the number of tracks for primary and secondary allocations that the Catalog Address Space (CAS) should use for an implicitly defined VVDS. The specified values are preserved across a CAS restart and are applied at IPL. If a zero secondary value is specified on a VVDSPSACE(pri,sec) parameter and the primary value is valid, then on an IPL, a default of 10 tracks will be substituted for the secondary. On a restart of the Catalog Address Space the value that existed prior to the CAS restart is retained. The default is VVDSSPACE(10,10). regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Q re attaching COBOL program
Hello: When a COBOL CALL or ENTRY is compiled, each item in the USING is used to create code to process a parameter list of full words equal in number to the number of items in that USING clause. So the CALL parameter list will have two full words. The ENTRY code will only process one full word. So, the CALL to COB#SYNC builds two fullwords of addresses, but the PROCEDURE DIVISION USING is only going to load one BLL cell. The BLL cell for item TPTAPI-COMMAREA will be loaded with the address of the caller's item WS-TPTAPI. The second item WS-TPTAPI-COMMAREA is not addressible by the subroutine (unless the second item is contiguous in storage to WS-TPTAPI and the TPTAPI-COMMAREA item describes both areas, a somewhat unorthodox way of passing parameters). I would have coded two items in the subroutines ENTRY USING clause. CALL-TPTAPI. DISPLAY WS-TPTAPI-COMMAREA CALL "COB#SYNC" USING WS-TPTAPI WS-TPTAPI-COMMAREA. - - - - - - - - - - - - - 2 Line(s) no DISPLAY WS-TPTAPI-COMMAREA. The subroutine's PROCEDURE USING: PROCEDURE DIVISION USING TPTAPI-COMMAREA. regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: jes2 Routine XINTKEY
I have seen this routine in a number of homegrown JES2 converter exits over the years when I worked at other companies. The comments stated that this bit of code was taken from HASPCNVT. In v1.13 the code resides in HASPCNVS. It is really just a search routine of the C/I text. regards, Joe Dalessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
