Need help setting up SLIP trap
Hi, All, We seem to have a loop in the DUMPSRV address space, causing continuous dump requests all containing the following dump title: COMPON=SSI,COMPID=5752SC1B6,ISSUER=IEFJSARR,MODULE=IEFJRASP,ABEND=S0C4,REASON=0011,SNAME=EYUX The system is not down so my PMR is only at Sev 2, but we'd like to suppress dump requests containing all, or as many as possible, of the symptoms in the dump title cited above. Can someone suggest an appropriate SLIP to set? TIA, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need help setting up SLIP trap
On Thu, 16 Jan 2014 11:18:37 -0700, Lizette Koehler wrote: In ipcs there is a panel entry which let's you change the setting in dae. You can suppress dumps from there The only panel I see anywhere in IPCS that even mentions DAE is this one: - DAE Display Row 1 to 48 of 672 Command === Scroll === CSR Enter an Action Code next to an entry. Enter / next to an entry to choose from a list of Action Codes. Dataset: 'SYS1.DAE' Dumps since last DAE Display: 0 Total Dumps suppressed: 8071 Events since last DAE Display: 4377Suppression rate: 9% A Last Last Total Date of Symptom String information: C Date SystemEvents Dump Abend ReasonModuleCSECT 01/16/14 SC10 64254 01/14/14* S00C4IEFJRASP IEFJRASP 01/16/14 SC10 12533 01/14/14* S00C4IEFJRASP IEFJRASP 01/16/14 SC10 260 01/14/14* S00C1IEFJRASP IEFJRASP - 01/15/14 SC10 114 01/14/14* S00C4IEFJRASP IEFJRASP for which these action codes are available: DAE Action Codes Place cursor on Action Code and press Enter. S- S Show Entry Details T Take Next Dump V View Dump Index Entry W Leave this panel We already have the following DAE options in effect: DAE=START,RECORDS(400), SVCDUMP(MATCH,SUPPRESS,UPDATE), SYSMDUMP(MATCH,UPDATE) They don't seem to be working as expected. Thus my request to code as specific a SLIP trap as I can to suppress those dumps (suppressing LOGREC recording appears not to be possible), to give DUMPSRV a rest (and stop wasting CPU cycles. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need help setting up SLIP trap
On Thu, 16 Jan 2014 11:09:45 -0800, Skip Robinson wrote: Make that SL SET,ID=NDMP,A=NOSVCD,LPAMOD=IEFJRASP,C=0C4 . . JO.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 From: Skip Robinson To: IBM-MAIN@LISTSERV.UA.EDU, Date: 01/16/2014 11:06 AM Subject:Re: Need help setting up SLIP trap Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU If you can get advice from IBM, I'd go for that. Meanwhile you might try this NON-PER trap: SL SET,ID=NDMP,A=NOSVCD,LPAMOD=IEFJRASP,ABEND=S0C4 . . JO.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 Thanks. Now 10 minutes after setting it, it appears to have had no effect: JOBNAME STEPNAME PROCSTEP TYPE JNUM C POS DP REAL PAGINGSIO CPU% DUMPSRV DUMPSRV DUMPSRV STC NS FF 3491 0.00 4126.5 4.50 On the other LPARs, the DUMPSRV SIO and CPU% are both zero most of the time. We're scheduled to IPL this LPAR Saturday night, so we're considering a SADUMP at scheduled shutdown time. This spin in DUMPSRV seems to be rather benign, all things considered; we lived with it overnight last night. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out Top 10 Strategic Technologies | Gartner
On Wed, 1 Jan 2014 13:42:00 -0500, Ed Finnell efinnel...@aol.com wrote: _Top 10 Strategic Technologies | Gartner_ (http://www.gartner.com/technology/research/top-10-technology-trends/) We'll see how this goesHave a Happy Those were for 2013 (last year). Try this one: http://www.gartner.com/technology/research/predicts/ Gartner Predicts 2014 -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Without Crypto Card?
On Thu, 19 Sep 2013 12:19:37 -0400, Farley, Peter x23353 wrote: QTE6CVllcywgdGhlIGNsZWFyLWtleSBJQ1NGIGVuY3J5cHQvZGVjcnlwdCBmdW5jdGlvbnMgKHdo aWNoIHVzZSBvbmx5IHRoZSBDUEFDRiBDUFUgaW5zdHJ1Y3Rpb25zLCBubyBjcnlwdG8tY2FyZCBu [. . .] But it was readable before I quoted it using the listserv web interface. Anyway, thanks for all the replies so far. I'll see if I can get HCR77A0 downloaded, installed and fired up. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ICSF Without Crypto Card?
Hi, List, On z/OS 1.13: Q1: Is there anything to be gained, running ICSF without any cryptographic coprocessors installed? Q2: Is anything lost by NOT running ICSF without cryptographic coprocessors installed? TIA, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Makes you go hmmmm, EVA MSU of 21 Cyls
On Thu, 12 Sep 2013 09:13:39 -0500, Chip Grantham wrote: I've finally taken the time to try to understand the numbers behind the way EAVs were implemented. I found a great discussion in the redbook z/OS v1.12 Implimentation SG24-7853-00 manual, chapter 20. Any time spend you happen to spend here is worth it. (not unlike all redbooks). Thanks to those that wrote it. I did happen into a segment that makes me go hmmm. 20.4.3 Multicylinder unit section says the 21-cylinder value for the MCU is derived from being the smallest unit that can map out the largest possible EAV and stay within the index architecture (with a block size of 8192), as follows: * It is also a value that divides evenly into the 1 GB storage segments of an IBM DS8000, * These 1 GB segments are the allocation unit in the IBM DS8000 and are equivalent to 1,113 cylinders. I'm sure the index architecture references the index vtoc architecture, which has always been a curious archeture to me. Has this design ever been made open? Just curious as to why it made 21 the magic number? I also ran into a math issue when I divided 21 into 1GB (or 1,073,741,824/21 = 51,130,563.0476...). I suspect that's because the 1GB storage segment is a number used in the DS8000 degisn, and its really close to the 1GB value. Wondering if that's true or some other reason. IIRC, when discussing disk storage, the industry uses the decimal meanings of KB, MB, GB, etc. Thus, a 1GB disk allocation would be 1,000,000,000 bytes, which divided by 21 yields 47,619,047. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL ? - emulating recursive PERFORM statement
On Sun, 4 Aug 2013 09:00:02 +1000, Wayne Bickerdike wayn...@gmail.com wrote: LOL, Didn't say it was my hands! Have you heard me play the violin? Been playing 50 years and still awful. Even worse than Jack Benny? :-D -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Stand-alone Dump Revisited
On Mon, 28 Jan 2013 16:19:49 -0500, Jim Mulder d10j...@us.ibm.com wrote:
A couple instances of n MESSAGE BUFFERS MISSING (total of 6), but
otherwise lists just about all the active ASIDs being processed.
This, along with the other symptoms, suggests that IPCS
is not seeing the data from all of the volumes.
IPCS said:
28,578 blocks, 118,884,480 bytes, in DSNAME('SYS1.SADMP.DDS1 ')
That's around 188 megabytes.
SADMP said:
AMD095I REAL DUMP 63% COMPLETED. TOTAL MEGABYTES DUMPED: 2,912
You are running IPCS directly against the original multivolume
SADMP output data set. The documentation (and I) strongly recommend
that you should copy that data set with IPCS COPYDUMP, and then
do further IPCS processing against the copy.
As we determined in my PMR, we did use IPCS COPYDUMP to copy the dump into a
single dataset, but we did not have the fix for OA36232 installed; so COPYDUMP
only copied the first volume, even though it read all 5 volumes. Thus,
IPCS-ing the copy gave the appearance of IPCS-ing the first volume of the
actual dump.
After changing our COPYDUMP JCL to specify all five VOLSERs, we did get a full
copy of the SADUMP.
Sometimes, running some utility other than SADMP or IPCS
against the multi-volume data set may cause the last volume
indicator to get turned on in the F1/F8 DSCB for some volume other
than the last volume. This will cause subsequent attempts to read
the data set sequentially to not see all of the data. COPYDUMP
will avoid this issue, and improve IPCS performance by merging
the data back into logical dumping order.
With the PTF for APAR OA37350 installed, SADMP should fix
an incorrect last volume indicator each time it takes
a dump.
We have duly added UA63883 to our apply list for maintenance.
-jc-
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Stand-alone Dump Revisited
OK, we finally noticed we had back-level IPLTEXT on the SADMP IPL volume.
Re-generated SADMP, captured the dump, and now IPCS gives us this hate mail:
Dump written by z/OS 01.13.00 stand alone dump - level same as IPCS level
z/Architecture mode system
CPU(0) STATUS available
Stand alone dump required 00:22 to record to SYS1.SADMP.DDS1
28,578 blocks, 118,884,480 bytes, in DSNAME('my.stand.alone.dump')
TIME-04:28:01 PM. CPU-00:00:02 SERVICE-25837 SESSION-01:34:22 JANUARY 25,2013
BLS18104I Symbol CVT not found
BLS18104I Symbol PVT not found
BLS18104I Symbol PFT not found
BLS18104I Symbol CVT not found
BLS18104I Symbol PVT not found
BLS18104I Symbol PFT not found
BLS18104I Symbol PSAVALID not found
BLS18104I Symbol CVT not found
BLS18104I Symbol IARHVSHR not found
BLS18104I Symbol CVT not found
BLS18104I Symbol PVT not found
BLS18104I Symbol PFT not found
BLS18104I Symbol CVT not found
BLS18104I Symbol PVT not found
***
Looks almost like OA32829, but no BLS18154I messages. The only other hits I
get on IBMLink involve multiple SADMP IPLs, or 28 or more CPUs; neither applies
here. Besides, both of those APARs have PTFs only up to z/OS 1.12.
Any ideas?
TIA,
-jc-
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Checkpoint and GRSRNL
On Mon, 28 Jan 2013 03:12:32 -0600, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Barbara Nitz kindly wrote: Also, I seem to remember that the checkpoint is always serialized via RESERVE. True. See JES2 Init and Tuning Guide (z/OS v1.12): For the checkpoint data set(s) that reside on a DASD volume, JES2 processing uses RESERVE and RELEASE logic with a software checkpoint lock to prevent JES2 members from simultaneously referencing and updating information kept in the checkpoint data set. I don't see any reason not to change the RNLS, as then JES shouldn't have any reason to even be aware that there is another JES on another system. Perhaps, but also from same book, this quote: For checkpoint data sets residing on DASD, IBM suggests that you add the checkpoint data set(s) to the RESERVE conversion resource exclusion name list (RNL) to prevent global resource serialization (GRS) from limiting access to that data set and degrading performance. A little more digging revealed the following: 1. We have back-level DSNs for the JES checkpoint datasets in our RNL EXCL list; 2. The updated DSNS are unique to each image; 3. Each image has two JES checkpoint datasets, each of which is the only dataset on its respective volume. Thus, there are a total of six JES checkpoint datasets, with six unique DSNs, on six different volumes. It would appear that the only way checkpoint lock contention could arise between z/OS images would be if GRS uses only the QNAME (SYSZJES2) but not the RNAME, or a wildcard RNAME (*). The RESERVE by one system should not have any effect on the other systems, right? Any further insights would be appreciated. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Stand-alone Dump Revisited
On Mon, 28 Jan 2013 11:05:39 -0600, Mark Zelden m...@mzelden.com wrote: On Mon, 28 Jan 2013 10:23:51 -0600, John Chase jonboy...@gmail.com wrote: [ snip ] Looks almost like OA32829, but no BLS18154I messages. The only other hits I get on IBMLink involve multiple SADMP IPLs, or 28 or more CPUs; neither applies here. Besides, both of those APARs have PTFs only up to z/OS 1.12. Any ideas? Did you watch the dump run and see the expected messages? In other words, are you sure the dump was taken properly? Although these days if you take a stand alone dump of a stand alone dump, I think IPCS tells you so. Not I personally, but a colleague, who cut'n'pasted the console output into an internal email: AMD083I STAND-ALONE DUMP INITIALIZED. SCHSET: 0 IPLDEV: ccuu LOADP: ccuu40M1 AMD115I SADMP for z/OS 01.13.00 AMD116I Dump of z/OS 01.13.00 AMD001A SPECIFY OUTPUT DEVICE ADDRESS (1) AMD101I OUTPUT DEVICE: ccuu volser SYS1.SADMP.DDS1 SENSE ID DATA: FF 3990 E9 3390 0C BLOCKSIZE: 24,960 AMD101I OUTPUT DEVICE: ccuu volser SYS1.SADMP.DDS1 SENSE ID DATA: FF 3990 E9 3390 0C BLOCKSIZE: 24,960 AMD101I OUTPUT DEVICE: ccuu volser SYS1.SADMP.DDS1 SENSE ID DATA: FF 3990 E9 3390 0C BLOCKSIZE: 24,960 AMD101I OUTPUT DEVICE: ccuu volser SYS1.SADMP.DDS1 SENSE ID DATA: FF 3990 E9 3390 0C BLOCKSIZE: 24,960 AMD101I OUTPUT DEVICE: ccuu volser SYS1.SADMP.DDS1 SENSE ID DATA: FF 3990 E9 3390 0C BLOCKSIZE: 24,960 AMD011A TITLE= TECH Test AMD005I DUMPING OF REAL STORAGE NOW IN PROGRESS. AMD005I DUMPING OF PAGE FRAME TABLE COMPLETED. AMD005I DUMPING OF REAL STORAGE FOR MINIMALASIDS COMPLETED. AMD029D REPLY W TO WAIT AFTER NEXT FULL SCREEN, ELSE REPLY N; REPLY= w AMD005I DUMPING OF REAL STORAGE FOR SUMMARYASIDS COMPLETED. AMD005I DUMPING OF REAL STORAGE FOR SWAPPED-IN ASIDS COMPLETED. AMD005I DUMPING OF IN-USE REAL STORAGE COMPLETED. AMD005I DUMPING OF REAL STORAGE SUSPENDED. AMD108I DUMPING OF AUXILIARY STORAGE FOR MINIMAL ASIDS COMPLETED. AMD108I DUMPING OF AUXILIARY STORAGE FOR SUMMARY ASIDS COMPLETED. AMD108I DUMPING OF AUXILIARY STORAGE FOR SWAPPED-IN ASIDS COMPLETED. AMD108I DUMPING OF AUXILIARY STORAGE FOR SWAPPED-OUT ASIDS COMPLETED. AMD056I DUMPING OF AUXILIARY STORAGE COMPLETED. AMD005I DUMPING OF REAL STORAGE RESUMED. AMD095I REAL DUMP 63% COMPLETED. TOTAL MEGABYTES DUMPED: 2,912 AMD005I DUMPING OF AVAILABLE REAL STORAGE COMPLETED. AMD005I DUMPING OF REAL STORAGE COMPLETED. AMD029D REPLY W TO WAIT AFTER NEXT FULL SCREEN, ELSE REPLY N; REPLY= w AMD104I STAND-ALONE DUMP PROCESSING COMPLETED. DEVICE VOLUME USED DATA SET NAME 1 ccuu volser 9% SYS1.SADMP.DDS1 2 ccuu volser 9% SYS1.SADMP.DDS1 3 ccuu volser 9% SYS1.SADMP.DDS1 4 ccuu volser 9% SYS1.SADMP.DDS1 5 ccuu volser 12% SYS1.SADMP.DDS1 Looks book to me. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Stand-alone Dump Revisited
On Mon, 28 Jan 2013 13:11:58 -0500, Jim Mulder d10j...@us.ibm.com wrote: OK, we finally noticed we had back-level IPLTEXT on the SADMP IPL volume. Re-generated SADMP, captured the dump, and now IPCS gives us this hate mail: [ snip ] I would start with \ STATUS CPU(0) REGS CPU(X'000') STATUS: BLS18100I NOCPU ASID(X'0001') FDBF48 not available for CVT BLS18104I Symbol LCCAVT not found BLS18104I Symbol LCCA0 not found BLS18058I Warnings regarding STRUCTURE(Ascb) at NOCPU ASID(X'0001') FDA500: BLS18300IStorage not in dump BLS18100I NOCPU ASID(X'0001') FDA500 not available for LCCA0 PSW=0706 No work wait BLS18100I NOCPU ASID(X'0001') FDBF44 not available for CVT BLS18104I Symbol PCCAVT not found BLS18104I Symbol PCCA0 not found Storage access could not read block at 026920E8 for CLTE No storage areas were passed or obtained, formatting is terminated. CURRENT FRR STACK IS: SVC PREVIOUS FRR STACK(S): NORMAL General purpose register values 0-1 _ C000_ 2-3 0002D048_ C000_ 4-5 4000_ 8000_ 6-7 _ _ 8-9 8000_ _ 10-11 _ 8000_ 12-13 8000_ _ 14-15 4000_ 8000_ Access register values 0-3 4-7 8-11 12-15 Control register values 0-1 _DF88EE70 _7CC69007 2-3 _7ED26FC0 0001_0001 4-5 0001_00010001 _07E29040 6-7 _FE00 _7CC69007 8-9 _ _ 10-11 _ _ 12-13 _85B7ADBC _7CC69007 14-15 _DF882EB2 _027AF010 The No work wait is kind of surprising. and VERBX SADMPMSG A couple instances of n MESSAGE BUFFERS MISSING (total of 6), but otherwise lists just about all the active ASIDs being processed. Also, make sure that IPCS is accessing the IPCS-related parmlib members for the correct release. These parmlib members would be coming from the IPCSPARM ddname if you are using one, or your parmlib concatenation (viewable via D PARMLIB ) otherwise. Verified that only the IBM-supplied, unmodified IPCSPR00 and BLSCECT(X) are in the parmlib concatenation. We don't have a BLSCUSER member at all. If the problem is not apparent, the easiest thing is usually to open a PMR and send in the dump so I can look at it. That seems the best option at this point. So, it will be coming at you shortly, Sev 3. Thanks, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JES2 Checkpoint and GRSRNL
All, We run three z/OS 1.13 images in a bronzeplex configuration, but do not share the spool; each image is a single-member MAS. We're also having fun with an ISV product on the sandbox, that started out as simply a S0C4 at shutdown time of the product's STC, but only frequently. At other times shutdown was clean and normal, and now, fairly consistently, shutdown of this STC somehow causes the sandbox to go into a disabled spin while (apparently) somebody on the sandbox holds the JES checkpoint lock. Naturally, the other two images quickly bog down and start complaining on the consoles about the JES checkpoint lock being held. GRS also says ISG378I GRS QSCAN ERROR COMMUNICATING WITH SYSTEM , DIAG=0001, where is the SMFID of the sandbox and DIAG= is for diagnostic data for IBM. Since we don't (yet) share spool access and each z/OS image has its own JES checkpoint dataset, would it be safe to convert the GRS enqueue from SYSTEMS (plural) to SYSTEM (singular)? Would it be wise to do so? TIA, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Stand-alone Dump Revisited
Hi, All, We're looking to clean up our Stand-alone Dump process, and get up to snuff for z/OS 1.13 and beyond. Toward that end we are studying the latest Tech Doc from IBM: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103286 But one question (so far) remains: What are the minimum ASIDs we should specify nowadays for a SAD? What should also be in the nice to have list? TIA, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E: Move products from one GLOBAL CSI to another
On Mon, 31 Dec 2012 11:12:35 -0600, Andy Higgins ahigg...@transunion.com wrote: John, For the situation you describe I believe adding ZONEINDEX entries for the products' CSIs to the 1.13 GLOBAL zone plus doing a GZONEMERGE from the 1.11 GLOBAL zone to the 1.13 GLOBAL ZONE of content for the products' FMIDs would accomplish what you want. The GZONEMERGE command will take care of the 2 concerns you mentioned. If I'm wrong about that I hope someone more knowledgeable chime in. Thanks for the vote of confidence. I haven't studied GZONEMERGE yet, but will do that later today. The BUILDMCS command Sandro mentioned is useful for carrying forward withdrawn-from-marketing, but still supported, products to a new z/OS release's CSI. Yes; I've used that before but determined it's not applicable to the current situation. The products I want to move already live in their own Target and DLIB CSIs, and I want them to stay there but become accessible from the z/OS 1.13 Global CSI. Happy New Year! Andy And the same to you and yours. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E: Move products from one GLOBAL CSI to another
On Mon, 31 Dec 2012 10:14:36 -0800, Skip Robinson jo.skip.robin...@sce.com wrote: I'd like to suggest that you reconsider the business case for merging disparate and unrelated SMP/E objects into one amorphous mass. We determined years ago to install z/OS and only z/OS into a single independent GLOBAL zone. This zone gets replaced in toto with each new ServerPac with no impact on other products. The only virtue I can imagine of a single comprehensive GLOBAL would be the ability to install a single sysmod into multiple TARGET/DLIB zones. The products we're contemplating moving (RDz and WAS) are rather intimately intertwined with Language Environment (LE), which is a part of base z/OS. The motivation behind our contemplated move/merger is to facilitate our recognition and resolution of cross-zone IFREQs and COREQs between the products and LE. I can't recall any case in the last decade where that ability would have justified increased SMP/E management effort: whatever means you employ to accomplish your goal for R13, you will have to do the same thing again for future releases ad infinitum. Since that process should remain substantially unchanged in the future, having done it once should allow us to declare it nearly an exact science. :-) I recommend keeping the z/OS GLOBAL--possibly with multiple TARGET zones to track sysmod installation--separate from non-ServerPac products. Thanks for your valuable insights. Keeping our z/OS 1.13 Global zone pristine would still require us to create product-specific Global zones (and CSI datasets) in order to de-link them from the z/OS 1.11 Global zone, wouldn't it? If so, the original questions and considerations regarding moving products from one Global zone to another remain. Thanks, -jc- [ snip ] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMP/E: Move products from one GLOBAL CSI to another
We have a few products that were installed into the z/OS 1.11 GLOBAL zone, and since we completed our z/OS 1.13 upgrade about 6 months ago would like to move them into the z/OS 1.13 GLOBAL zone. The Target and DLIB zones for each product resides in their own VSAM clusters, and they each have their own SMPxxS datasets, so ZONEEXPORT - ZONEIMPORT appear to be significant overkill. But SMP/E Reference seems to suggest that merely defining the ZONEINDEX entries for the Target and DLIB zones in the z/OS 1.13 GLOBAL zone might be insufficient. It's not immediately clear what effect, if any, un-ACCEPTed PTFs might have on the move, and there may be one or more USERMODs (that we never ACCEPT). So what appears to be the main concerns are: 1) Will the absence of any knowledge of the USERMOD in the z/OS 1.13 Global zone (RMID is kept only in the Target and DLIB zones, right?) adversely affect a future need to RESTORE the USERMOD (e.g., for subsequent maintenance APPLY)? It would seem that (re-)RECEIVE of the USERMOD would not be a problem in any event, since we would normally update the REWORK (and PRE, if necessary) value anyway. 2) Would the absence of the APPLYed but not ACCEPTed product PTFs from the z/OS 1.13 SMPPTS adversely affect a future ACCEPT of them using the z/OS 1.13 GLOBAL zone? We normally PURGE the PTFS at successful ACCEPT time. Pointouts of any other potential gotchas would also be appreciated. Thanks in advance, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBMLink Out to Lunch again?
Unable to connect to IBMLink sign-on page from Chicago area. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ShopzSeries SSL Connectivity Test
On Fri, 14 Sep 2012 17:08:04 -0700, Charles Mills charl...@mcn.org wrote: My bad -- DEBUG, not TRACE. Try DEBUG FLO DEBUG INT DEBUG ACC DEBUG SEC Charles -Original Message- From: IBM Mainframe Discussion List On Behalf Of John Chase Sent: Thursday, September 13, 2012 11:05 AM On Thu, 13 Sep 2012 06:44:53 -0700, Charles Mills charl...@mcn.org wrote: Turn on some FTP tracing. You can do it in FTP.DATA. Take a look at the TRACE (?) statement in the CS configuration manuals and pick some plausible options. Charles Not much new with TRACE in the FTP.DATA: [ snip ] OK, the DEBUG options write a book now. :-) Our firewall guys tried a couple different things, and I guess we made some progress: Now the failure is FC0994 authServer: secure_socket_init failed with rc = 8 (Certificate validation error). Time to call Shopz Support, since we're trying to use the certificate they issued. The certificate works fine for RECEIVE ORDER over a non-SSL connection. Thanks for all your help and suggestions. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ShopzSeries SSL Connectivity Test
On Thu, 20 Sep 2012 09:56:51 -0400, Rob Schramm rob.schr...@gmail.com wrote: If it is a certificate related issue.. you can run a GSKSRVR trace. It's a bit verbose... but gives you pretty specific information as to the real issue. These instructions were for CICS.. but it'll work for ftp just the same. - S GSKSRVR - Restart CICS. - Update GSKWTR PROC to add a dataset to hold the trace. - TRACE CT,WTRSTART=GSKWTR - TRACE CT,ON,COMP=GSKSRVR - R n,JOBNAME=(yyy),OPTIONS=(LEVEL=255),WTR=GSKWTR,END where yyy is the name of CICS. - Recreate the problem. - TRACE CT,OFF,COMP=GSKSRVR - TRACE CT,WTRSTOP=GSKWTR OK, everything APPEARED to work, but the output trace dataset did not get created. Here's what our GSKWTR proc looks like: //GSKWTR PROC //*-*// //* Component trace external writer for the System SSL started *// //* task. Up to 16 trace datasets (TRCOUT01 - TRCOUT16) may *// //* be specified. *// //*-*// //IEFPROC EXEC PGM=ITTTRCWR,REGION=32M //TRCOUT01 DD DSN=TECH.SYSSSL.CTRACE,DISP=(NEW,CATLG), //SPACE=(CYL,(100)),UNIT=SYSDA That's as delivered by IBM except for the output dataset name. Now, for the JOBNAME in the WTOR I specified the batch job name that I submitted. Should I specify FTPDn there instead? I.e., should I specify the job name of the FTP Daemon? Seems counter-intuitive if true, since my batch job is the client, not the server, in context. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ShopzSeries SSL Connectivity Test
On Thu, 20 Sep 2012 14:02:29 -0400, Kurt Quackenbush ku...@us.ibm.com wrote: Our firewall guys tried a couple different things, and I guess we made some progress: Now the failure is FC0994 authServer: secure_socket_init failed with rc = 8 (Certificate validation error). You need the GeoTrust Global CA certificate (https://www.geotrust.com/resources/root-certificates/index.html) in the keyring used by the ftp client. That's the CA that signed the FTP server's cert and is required for the SSL handshake. THANK YOU, SIR!! NOW we're cooking with gas. Successfully completed the SSL handshake. Now all that remains is to get the last tidbit of error data to our firewall guys so they can allow the private (encrypted) data connection, and we should be in business. Time to call Shopz Support, since we're trying to use the certificate they issued. The certificate works fine for RECEIVE ORDER over a non-SSL connection. I'm not sure what you mean when you say the cert works fine for RECEIVE ORDER over a non-SSL connection. Which cert are you talking about? The client certificate generated by Shopz? That's not used for the SSL handshake at all. The generated client cert is used simply to carry unique identifying information to the server, such as IBM customer number. That was a grasping at straws gesture, based (partly) on the ass.u.mption that the CA that signed our client cert (Equifax Secure CA) would be the same CA that signed IBM's server cert. WNORG! It did seem odd specifying a personal key ring given that the connectivity test JCL included user and password commands, which seem superfluous if authenticating with a certificate. By chance, does the ECuRep server (where we upload PMR documentation) require the GeoTrust Global CA as well? I've had similar fun trying th test an SSL connection there, too. Thanks, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ShopzSeries SSL Connectivity Test
Hi, All, Anybody successfully using SSL/TLS to download stuff from ShopzSeries direct to z/OS? How does one need to set up the z/OS client to do so? Trying the ShopzSeries Connectivity Test for the first time. I've set up the FTP.DATA specifications according to the sample provided by ShopzSeries, and am using their sample JCL almost unchanged (using local JOB card is about the only change). All I get so far is this: EZA1450I IBM FTP CS V1R13 EZA1772I FTP: EXIT has been set. EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages. EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21. 220-IBM's internal systems must only be used for conducting IBM's 220-business or for purposes authorized by IBM management. 220- 220-Use is subject to audit at any time by IBM management. 220- 220 dhebpcb01 secure FTP server ready. EZA1701I AUTH TLS 234 SSLv23/TLSv1 EZA2897I Authentication negotiation failed EZA1534I *** Control connection with dispby-117.boulder.ibm.com dies. EZA1457I You must first issue the 'OPEN' command EZA1735I Std Return Code = 10234, Error Code = 00010 I'm using our SMP/E Client Certificate that we use for RECEIVE ORDER jobs. The return code and client error code say nothing more than connection failed; no clues as to why. Might we need to poke a hole in our firewall? Haven't tried that yet; RECEIVE ORDER jobs work without it anyway. Any other ideas would be appreciated as well. TIA, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Quantas hit by leap second issue?
On Tue, 3 Jul 2012 05:53:21 -0500, Barry Merrill ba...@mxg.com wrote: QATAR Airways is also without the U and seemingly well pronounced in their advertisements. Hmmm ISTR Qatar being pronounced Cutter in recent news reports. I've not heard their airline's name pronounced, properly or improperly. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: installing serverpac for 1.13 using 1.11 system
On Wed, 13 Jun 2012 16:08:02 -0500, Mark Steely mark.ste...@wnco.com wrote: The format looks correct - this is what I had: /Service/etc OS130508.OMVS.ETC /Service/usr/lpp/java/J6.0.1 OS130508.OMVS.JAVA31M1 /Service/usr/lpp/java/J6.0.1_64 OS130508.OMVS.JAVA64M1 /Service OS130508.OMVS.ROOT /Service/zWebSphereOEM/V7R0/config1 OS130508.OMVS.SBBNCON1 /Service/usr/lpp/zWebSphereOEM/V7R0 OS130508.OMVS.SBBN7HFS /Service/var/wbemOS130508.OMVS.SCFZHFS2 /Service/usr/lpp/IHSA/V7R0 OS130508.OMVS.SHAPHFS /Service/usr/lpp/perlOS130508.OMVS.SHPEROOT /Service/usr/lpp/php OS130508.OMVS.SHPHROOT /Service/usr/lpp/ported OS130508.OMVS.SHPUROOT /Service/usr/lpp/ixm/IBM OS130508.OMVS.SIXMHFS /Service/var/zosmf/data OS130508.OMVS.SIZUDATA /Service/usr/lpp/zosmf/V1R13 OS130508.OMVS.SIZUROOT /Service/var OS130508.OMVS.VAR Of course you have to mount the /Service first. We just rolled out z/OS 1.13 (from 1.11) on our TEST/DEV lpar, and I noticed something strange: In the 1.13 root filesystem, the /etc and /var directories show as directories, whereas on 1.11 (and earlier) they showed as symlinks to /SYSTEM/etc and /SYSTEM/var respectively. I looked at our installation/sandbox lpar and it's the same there. Yet the /SYSTEM directory contains /etc and /var subdirectories, along with /dev and /tmp, as in the past. Did we do something wrong at installation? Or are /etc and /var now (1.13) supposed to be directories in / rather than symlinks to the /SYSTEM subdirectories? TIA, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
