Re: Web post quoting
On Sun, 20 May 2012 03:58:18 -0500, Shane Ginnane wrote: >On Sun, 20 May 2012 00:44:13 -0500, John Chase wrote: > >>I don't know why the web interface to IBM-MAIN does not allow quoting the >>original post, ... > >Bottom right, two green inverted quote marks. Mouse-hover should give a >tool-tip. > >Shane ... Dang me! Another "small fortune" wasted on new glasses :-( -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Retiring after 43+ years with IBM
Hi, Frank, I don't know why the web interface to IBM-MAIN does not allow quoting the original post, but your subject line says what needs to be said. I'll offer to you the same "advice" I offered to Walt Farrell of RACF Development when he announced his retirement: "Whatever you choose to do in retirement, DON'T GET BORED!!" Boredom in retirement is one of the fastest paths to the grave. I've seen it more times than I care to recount. "Live long and prosper." -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: FW: Another Mysterious Email from IBM
Don't know yet if it's related, but I was in the midst of a ShopzSeries session and "suddenly" any navigation attempts in Shopz give "500 Internal Server Error". Can't even sign out. -jc- On Thu, 14 Jul 2011 08:57:06 -0500, Chase, John wrote: >This time it's from POK. Again addressed to "undisclosed recipients". > >-jc- > >> -Original Message- >> From: rscs.system.at.s39...@d01av02.pok.ibm.com >[mailto:rscs.system.at.s39...@d01av02.pok.ibm.com] >> Sent: Thursday, July 14, 2011 8:53 AM >> To: undisclosed-recipients >> Subject: >> >> Regarding: File sent to JDC1 at S390VM on 07/14/11 at 9:52:13 >> File sent from JCHASE at INTERNET >> File name: JCHASE NOTE, size: 36 records >> >>We have received the file shown above because it was sent to an >> unknown user ID. This file cannot be delivered because the JDC1 >> ID is not known at node S390VM. The file has not been purged, but >> is being held for you for correction. If you take no action, the >> file will be purged in 4 days. >>If the file was sent from a VM system, you can transfer or purge >the >> file by using one of the following commands. If the file was sent >from >> on MVS or AIX system, PLEASE RESEND IT, or contact the CUSTOMER >ASSISTANce >> CENTER for further assistance asking them to TRANSFER or PURGE the >file >> for you. They will need to know the RSCS machine the file is >currently >> on is S390VM, the spoolid is 4796, and the correct destination >> NODEID and USERID so they can also do the following HELPDESK commands. >> >> FROM ORIGINATING VM USERID - >> >> Transfer:SM RSCS CMD S390VM TRANSFER 4796 TO newnode newuser >> Purge: SM RSCS CMD S390VM PURGE 4796 >> >> HELPDESK commands to be done from NODEID that the &localnode. RSCS is >on >> >> Transfer:SM RSCS TRANSFER *NOTHERE 4796 TO newnode newuser >> Purge: SM RSCS PURGE *NOTHERE 4796 >> >>Note to PROFS/OFFICE VISION users: >>The above commands must be issued from the PROFS/OV main menu, or >> from the CMS command line. >> >>Note to non-ER customers: >>If your system netid is not RSCS, replace RSCS with your system >>netid in the above Transfer/Purge commands. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF and z/OS 1.11
On Fri, 20 Aug 2010 09:36:22 -0500, Mark Zelden wrote: >On Fri, 20 Aug 2010 08:39:17 -0500, Chase, John wrote: > >>Here's a weird one for you: >> >>We recently upgraded two LPARs from z/OS 1.9 to z/OS 1.11. One of those >>LPARs is our "sandbox", which is pretty well "crippled" (one CPU, 3GiB >>central storage, on a z9-BC). My "standard" tn3270 emulation is the >>3290 screen size (62x160), and I specify LOGMODE(D4C32XX3) at logon >>time. This has worked wonderfully through z/OS 1.9. >> >>At z/OS 1.11, and (so far) only on the "sandbox", my 3290 emulation >>simply will not display SDSF at all; the session simply "hangs". If I >>omit the LOGMODE(D4C32XX3) and accept our default 24x80 screen size, >>there is no problem with SDSF (other than readability, of course). Note >>that the "other" LPAR that was upgraded lives on the same z9-BC, which >>also hosts a Coupling Facility. >> >>Anybody have any idea what I should look for, and where, to address my >>SDSF on the 'Sandbox" problem? >> > > >Known problem, and discussed several times before. If you hadn't skipped >z/OS 1.10 you would have found out a long time ago. :-) > >Change HIBFREXT=96000 in TSOKEY00 (I assume it is something lower >or you wouldn't have this problem). Unfortunately you can't change this >dynamically. Well, now that I've had a chance to browse the archives, I find that not only had this been discussed, but I (!!) had "bragged" about using 62x160 on z/OS 1.11 with TSOKEY00 values HIBFREXT=6600 and LOBFREXT=3300! I can't imagine what changed where when we upgraded the second LPAR on that box. I have no idea where the 6600 and 3300 values came from originally, but the "last changed" date on our TSOKEY00 members is sometime in 1992. I see in current (and not-so-current) documentation that the DEFAULTS are now HIBFREXT=48000 and LOBFREXT=24000, so maybe I've just been "lucky" for quite some time now. I think I'll lobby for using the current defaults for now (we've developed quite a taste for "vanilla" :-) ), and note that I did see Ed Jaffe's post about using LOBFREXT=48000 and HIBFREXT=96000. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: System Rexx questions
On Fri, 11 Apr 2008 17:13:13 +0200, Lindy Mayfield wrote: >1.8 with a APAR and shipped by default in 1.9. > >It is where you put system rexx programs that can run system commands. > >I found this nice presentation on it: > >http://www.gsezos.be/PDF-Files/071121%20-%20System%20Rexx.pdf [ snip ] We're finally getting around to SYSREXX, and find that the documentation for setup is rather sparse. Both the Init & Tuning Reference and the z/OS 1.9 Implementation Redbook say: "The AXRUSER parameter in the AXRxx parmlib member specifies a 1 to 8 character user ID that is used to define the security environment that an exec initiated using the AXREXX macro when SECURITY=BYAXRUSER is specified. The exec will run with the level of authorization associated with the specified user ID. The installation needs to provide the user ID with SAF access to the resource SYSREXX.. If this parameter is omitted, then the default is AXRUSER." What's missing from this is the RACF class in which SYSREXX. should be defined. Its format and usage context suggests the SURROGAT class, but it could as easily need to be defined in the FACILITY class. It seems odd that the user ID would need to be permitted to its own SURRUGAT profile, though Can someone say definitively in which class to define SYSREXX.? TIA, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: curious about Java usage.
On Fri, 30 Oct 2009 09:39:49 -0400, Jousma, David wrote: >We are in the middle of implementing our first home-grown application >written JAVA app. It is stored in ZFS datasets. Our current mainframe >change control doesn't support unix file systems. We have a separate >change control process for the open systems(unix and windows) from IBM >and is a combination of ClearCase, Clear Quest, and Build Forge. I >installed the Buildforge agent on the mainframe. It is the conduit to >these processes. In our case, the java app is compiled off platform, >and all the parts and pieces are then pushed to the mainframe. Does Buildforge support "classic" mainframe entities, like COBOL, MVS datasets, etc.? Our current mainframe change control product doesn't support the "UNIX-y stuff" yet; that's being investigated for "a future release" of it. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TN3270 Abend S0F8 RC04
On Mon, 25 Aug 2008 07:31:32 -0500, John Chase wrote: >On Sun, 17 Aug 2008 09:04:35 -0500, Chase, John wrote: > >>Hi, All, >> >>Running a "smoke test" of z/OS 1.9 on the Prod LPAR, and getting >>intermittent S0F8-04 abends in TN3270. No hits on IBMLink for this. >> >>"System Codes" manual says: >> >>"The issuer [of an SVC instruction] was in a mode other than task >>control block (TCB) mode." >> >>Any ideas, while we open a PMR? > >Well, nobody replied, so it must be a new problem. For our z/OS 1.9 rollout >attempt yesterday, it was a show-stopper. The effect on end-users is that >they are unable to connect to the system at all. > >Empirical evidence suggests that this situation affects only tn3270 clients >assigned to an LU pool for which we don't specify a default LOGAPPL. This is >consistent with IBM's analysis so far of our dump from last week, in which >they have determined that the abending task was trying to send the >USSMSG10 buffer to the connecting client. Adding to the puzzle is the fact >that clients assigned to an LU pool that -does- have a default LOGAPPL can, >upon exit from that application, display the (same) USSMSG10 without problem. > >I'll try to keep the list updated with progress from our PMR. "Be sure to look under -ALL- of the rocks." Amazing where you can "lose" stuff in z/OS. While "grasping at straws", we started comparing the contents of individual libraries, parmlib members, etc., between the Production copies and the source copies of our 1.9 "master" image, and discovered that we were loading a back-level (HBB5520) copy of ASASYMBM into the MLPA on the Production system only. The "why" is lost in the dustbin of history, but when we copied the back-level ASASYMBM to the sandbox and IPLed it into the MLPA there, we were able to reproduce the S0F8 abends in TN3270 at will. The level of ASASYMBM that shipped with z/OS 1.9 is HBB7707. In the PMR, IBM indicated that the relevant change introduced into ASASYMBM (at z/OS 1.2) was support for SRB and cross-memory mode processing. Oh, the reason this problem never surfaced on z/OS 1.7 is that TELNET (TN3270) didn't start invoking ASASYMBM until z/OS 1.8. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TN3270 Abend S0F8 RC04
On Sun, 17 Aug 2008 09:04:35 -0500, Chase, John wrote: >Hi, All, > >Running a "smoke test" of z/OS 1.9 on the Prod LPAR, and getting >intermittent S0F8-04 abends in TN3270. No hits on IBMLink for this. > >"System Codes" manual says: > >"The issuer [of an SVC instruction] was in a mode other than task >control block (TCB) mode." > >Any ideas, while we open a PMR? Well, nobody replied, so it must be a new problem. For our z/OS 1.9 rollout attempt yesterday, it was a show-stopper. The effect on end-users is that they are unable to connect to the system at all. Empirical evidence suggests that this situation affects only tn3270 clients assigned to an LU pool for which we don't specify a default LOGAPPL. This is consistent with IBM's analysis so far of our dump from last week, in which they have determined that the abending task was trying to send the USSMSG10 buffer to the connecting client. Adding to the puzzle is the fact that clients assigned to an LU pool that -does- have a default LOGAPPL can, upon exit from that application, display the (same) USSMSG10 without problem. I'll try to keep the list updated with progress from our PMR. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Scotts new role
On Mon, 5 Nov 2007 08:44:38 -0600, Mark Zelden wrote: >Can't we just vote Eg off the island? That would (properly) be Darren's call, even if a vote to do so were unanimous. And he could always re-subscribe with a pseudonym, from a different email address. About the best we can do is to simply ignore anything he posts, and/or "killfile" him, and maybe some day he'll get bored enough to just "go away" on his own accord. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
