Re: What is largest record that can be sent using LU2?
On Wed, 7 Oct 2009 16:39:48 -0500, Ward, Mike S mw...@ssfcu.org wrote: I tried getting LU0 to work, but couldn't. So I used LU2 and it worked. But used it to do what? What's behind the LU on the remote end? A 3270 emulator that displays the data? Or a program that does something else with the data? If the former, and if that emulator accurately emulates a 3270, you are functionally limited to sending at most the size of the screen specified in the BIND. You can send as much data as you like but there is only one buffer for the data to go into. You won't get an error; you will just overlay data. Actually, you may have a much greater limitation. It all depends on the 3270 screen addressing being used by the CICS transaction. If it were foolishly sending 100k bytes of data in 8-byte chunks all specifying the same 8-byte field in the 3270 buffer you would be functionally limited to sending 8 bytes. And if tried to use a buffer address outside the screen size the 3270 emulator will choke and give you an error. BTW, LU0 has 2 very different implications, depending on context. #1. In general, LU0 implies a roll-your-own protocol where you write the LU application at each end to do whatever you want (within the limits of SNA); you (the programmer) design your own rules and write the applications to follow those rules. #2. LU0 3270 support, which is VTAM's support for non-SNA 3270. In either case, I'm not surprised LU0 didn't work ... unless you knew that LU0 was specifically required. I was more wondering why you were using any 3270 datastream. Why not LU1? (Or even LU6.2, but that would be a lot more work.) Pat O'Keefe -- 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: What is largest record that can be sent using LU2?
On Wed, 7 Oct 2009 14:33:18 -0500, Chris Mason chrisma...@belgacom.net wrote: A minor gloss on Chris's response ... If you want to indicate that the request units you are sending constitute a larger unit of data at the level of the application, There are two bits in the request header which are used to indicate only in chain, beginning of chain, middle in chain and end of chain with an obvious pattern of use. The Large Message Performance Enhancement (which has nothing to do with performance, as far as I can see) allows a program to send an indefinitely long (I think) list of blocks of data, each up to 32k bytes long (I think). VTAM will do all the required collecting and chaining. I'd be very surprised if CICS did not use LMPE. It has been available since the early to mid 80s, and is very handy for combining independent chunks of data into one RU (chain), whether or not large applies. ... I can't tell you what limits you may encounter in CICS or Windows/CS. If you are in charge of the programming behind each of the communicating LUs, just how large the units of data at the level of the application are will be a matter with which your programming will deal. ... On the other hand, if there is something inherently 3270-ish in the Windows/CS side - something like a display buffer - be aware that data will wrap when it comes to the end of the buffer and overlay what may be at the beginning of the buffer. If there is NOT anything 3270-ish involved, why is an LU2 session being used? Please forgive me for breaking my vow of silence. I'll now return to lurkdom. Pat O'Keefe -- 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: Slow FTPS thruput
On Fri, 25 Sep 2009 09:36:21 -0500, Neal Eckhardt neckha...@penntraffic.com wrote: ... How can I tell. I don't see anything in the FTP parms. We are running z/OS 1.4 BTW. I don't know when GSKSRVR came into existance, but if it is in 1.4, issue the command F GSKSRVR,DISPLAY CRYPTO It will display the available hardware and software encryption is available to you. For example: GSK01009I Cryptographic status Algorithm HardwareSoftware DES 56 56 3DES 168 168 AES256 256 RC2 -- 128 RC4 -- 128 RSA Encrypt 20484096 RSA Sign 20484096 DSS --1024 SHA-1 160 160 SHA-2 512 512 (Sorry about any formatting problems in that display.) Then you have the pleasant task of translating that into TLS cipher suites. (Google TLS cipher for help.) Pat O'Keefe -- 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: Slow FTPS thruput
On Fri, 25 Sep 2009 13:16:35 -0500, Neal Eckhardt neckha...@penntraffic.com wrote: ... on the z9 that we just installed. Do I need to be running ICSF for this assist to work? ICSF is needed to access a crypto coprocessor. It is not needed to access crypto assist (if crypto assist means CPACF instructions). CPACF will reduce cycles used for the symmetric-key encryption used during the data transfer. It does not help with the asymmetric -key encryption used during the TLS handshake. That is probably fine for your FTPs. Pat O'Keefe -- 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: Long parms ... again (was: Reading DD card information)
On Thu, 24 Sep 2009 13:06:01 -0400, Scott Rowe scott.r...@joann.com wrote: I understand the concerns, but this sounds like a good reason for all ISVs to review their code. ... Not just ISV; shops should review their own code, too. My point is that there is no 100 byte limit on the interface, there is only a limit on the implementation. ... And the good news: there is time to perform those reviews. Regardless of how much we yammer here about long parm support in JCL, IBM is not likely to implement it for a while. And unless we decide what we want and put it in a formal requirement, it's not likely to happen at all. (And I'm using that we a bit broadly, of course, since I won't be part of it.) Pat O'Keefe -- 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: Slow FTPS thruput
On Thu, 24 Sep 2009 14:19:14 -0500, Neal Eckhardt neckha...@penntraffic.com wrote: ... A 20 megabyte file takes about 9 seconds to transfer without TLS and about 160 seconds with TLS. The transfer rates are about 130 kbytes/sec with TLS and almost 2000 Kbytes/sec without. Are there any tweaking knobs that we can turn to improve this? ... Wow! When we went to using encrypted data transfers we noticed very little increase. (This was not FTP, it was mostly CONNECT:Direct but the effect of encryption should be the same regardless of the actual product transferring the data. Do you have hardware encryption support? If so, make sure you specify cipher suites that use the hardware encryption. Are these large transfers, or many short transfers? The encryption process used in the TLS/SSL handshake and the encryption process used for data encryption/decryption are very different and use different encryption hardware. The encryption process used in the handshake is VERY cycle intensive if you do not have an encryption engine. The data encryption process is simpler, and uses CPACF instructions that are automatically avalable on Z9s (I think) and Z10s (definitely). I think the instruction support has to be manuall enabled though. Anyway, if you don't have a crypto card on your processors but are doing long transfers, the expensive TLS handshake is going to be lost in the backround noise. If you are doing many short transfers, those handshakes are going to kill your throughput. System SSL support in z/OS has a pretty good trace available that can help pinpoint encryption performmance problems. You have to run the GSKSRVR started task in order to take the trace.I think you should run a CTRACE writer, too, although I think the trace data can be extracted from a dump of the GSKSRVR address space (or maybe an associated data space) if you don't run the writer. You may need some help from IBM in interpretting it, but this help is available through IBMLink's Ask a question ETR support. I'm not always impressed with the help available through that part of IBMLink, but was very pleasantly surprised by the System SSL folks.) If the problem really is related specifically to FTP, you might consider posting your question on the IBMTCP list. Pat O'Keefe -- 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: IBM Program To Help Students Gain Critical Mainframe Skills Grows To More Than 600 Universities
On Thu, 24 Sep 2009 13:56:31 -0700, Howard Rifkind ibm_m...@yahoo.com wrote: ... Want cheap..hire a newbie low salary and what not. Want to get the job done pick an experience sysprog. ... Ok. 2 not particularly compatable problems: 1. a large number of experienced programmers out of work 2. a large numberof programmers soon to retire IBM's initiative is directed at #2 but may make #1 worse. You can bet the freshly minted graduates are going to need training that wasn't provided in college. So maybe the unemployed programmers should sell their skills as tutors and trainers. (Oops. Sorry Steve. I forgot about #3 - languishing trainers.) Pat O'Keefe -- 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: Long parms...again
On Thu, 24 Sep 2009 17:27:13 -0500, Chase, John jch...@ussco.com wrote: ... I thought he was pointing out your misspelling of Chris Craddock's first name as Christ. ... You didn't hear about Chris's promotion? Pat O'Keefe -- 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: Long parms ... again (was: Reading DD card information)
On Wed, 23 Sep 2009 12:57:46 -0400, Barkow, Eileen ebar...@doitt.nyc.gov wrote: The argument that an existing program cannot handle a longer parm area if it was available is nonsense - just don't pass it the longer area and there will not be a problem. I don't buy that. Whether you are talking about a you-bet-your- company production program or a critical system utility, Murphy says that somebody will pass the program an invalidly long parm as soon as the operating system allows it.Documenting Don't do that may protect your rear end but it won't your company from the results. Pat O'Keefe A perfect example on why a longer parm area over 100 bytes is needed is the CICS Web Service Assistant job streams (DFHLS2WS/DFHWS2LS) that IBM stupidly wrote to require long-winded hfs file names passed in the parm field. I had to use convoluted links and 1 character file names in order to fit every thing in. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Craddock Sent: Wednesday, September 23, 2009 12:30 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Long parms ... again (was: Reading DD card information) On Wed, Sep 23, 2009 at 10:59 AM, Thompson, Steve steve_thomp...@stercomm.com wrote: Might I suggest that you are being a bit myopic? Or perhaps suffering from tunnel vision? APF programs are to be written to a higher standard. From what you have written, you believe that if someone passes an APF program you have written, an invalid parm, that program should accept that as gospel and go clobber some part of the address space (say the JSCB, or change the ASCBSENV, etc.) and give the caller authorities they should not have, right? I think you're missing the point entirely Steve. This has nothing to do with APF or non-APF and nothing at all to do with abstract program A calling theoretical program B. The consequences for an APF program are potentially more serious, but the problem is the same. Back before the flood the PARM interface was explicitly limited to 100 bytes. So a valid program written to that specification could legally pick up the length and mindlessly move that many bytes from the parameter data into another pre-allocated (or dynamically allocated) 100 byte area knowing full well there was no chance of overflow because the OS guaranteed (then) that the actual length would never be greater than 100. Fast forward 4 decades and change the interface so the length could go over 100 and now you have valid programs that can suddenly overlay their 100 byte area. Nothing good can come of it and if you're lucky you just abend right then and there. If you're an APF program then things can go awfully pear shaped. An interface definition is a contract. You can't break it, even if the original contract (as in this case) was stupid. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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 -- 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: Long parms ... again (was: Reading DD card information)
On Wed, 23 Sep 2009 16:53:03 -0500, Kirk Wolf k...@dovetail.com wrote: ... I respectfully disagree: 1) how are two options cleaner? The usage would be ugly... the JCL coder would have to think - let me see, should I use PARM with 100 or PARMX with more? and what if both are coded? I see that required thinking as a positive rather than a negative. And the inclusion of both parm formats (if allowed by JCL) would be supported since they use 2 different interfaces. I don't see a downside to that. 2) a separate program api would require modifications to any program that can already support 100 character parm fields, which is probably a good percentage. Programs already supporting 100 parms could easily be handled by a simple driver program that takes data from the new long parm api, stuffs it in an old format parm, and LINKs to the program. Since the JCL would already have to be changed to include the new long parm, invoking the driver program would be simple. Having an LE option ... When drag LE into this if it's not needed? Pat O'Keefe -- 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: SYS1.VTAMLST Full - Production
On Tue, 22 Sep 2009 13:35:08 +0200, R.S. r.skoru...@bremultibank.com.pl wrote: ... For directory full there is simple trick available: just delete ISPF statistics action char G). If the ISPF statistics are important to your shop (They are for ours.), you can use the PDS utility from the CBT collection to increase the directory. I've never been brave enough to do this to VTAMLST in production but we did it in a test environment once. (I've never PDS hose over a directory but I'm always a bit nervous about doing it.) There are probably commercial products that can do the same thing. See if you already have one. Pat O'Keefe -- 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
Long parms ... again (was: Reading DD card information)
On Tue, 22 Sep 2009 08:15:59 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: ... :I'd be quite satisfied with this _provided_ it was compatible :with the existing CALL, LINK, ATTACH, etc. argument lists. :I.e. on program entry R1 points to a fullword which points :to a halfword containing the length of the PARMX followed :by the PARMX string. ... Actually the current interface does set the high order bit of the word pointing to the parm to x'80'. All (almost all?) IBM utilities support a three word plist, where the second word points to a list of overriding DDNAMEs and the third word points to a starting page number. I don't think any new arguments, counter-arguments, or proposed solutions are being raised here (and I'm certainly not about to), but the above comment adds a new twist. It confirms that the end-of-parms flag must be set for parms provided by JCL but also confirms that having both PARM and PARMX would be misconstrued by those programs expecting an optional list of overriding DDnames. This almost supports those saying that only one parm - PARM or PARMX - must be allowed. Almost. A program (foolishly) written with the assumption that it will always be invoked by via JCL with a 100-byte limit on parm length might (foolishly) keep the length in a single byte. It *might* get by with a max 255-byte parm but not a longer one. And when it abends the owner (possible a vendor), not the JCL coder, is probably going to be called. Whatever technique used to pass a long parm is not going to be safely handled byt the old, standard parm passing scheme because a long parm passed that way will break old, standard programs. Some new technique that can be verified by new programs is needed or a lot of stable production jobs are going to die. I know some people see that as hobbling z/OS with severe limitations of the S/360 past, but I see maintaining compatability as a source of the great stability of z/OS and its ancestors. Thee is an obvious need for lifting the 100-byte limit on parms, but it needs to be done in a way that allows old programs to continue to work. Pat O'Keefe -- 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: SYS1.VTAMLST Full - Production
On Tue, 22 Sep 2009 13:21:40 -0400, Pinnacle pinnc...@rochester.rr.com wrote: ... If there is not enough space in the dataset, you can do an ADDCYL or ADDTRK, and PDS will dynamically create another extent. Not sure if VTAM can tolerate that, but you'll find out soon enough ;-) ... It's been a long time since I've seen a VTAMLST allocated with secondary extents so I don't remember the last time I ran into that. I'd be surprised if VTAM did not close and reopen VTAMLST when it runs into the beyond the end of extent problem, but I've been surprised before. Our VTAMLSTs have so little in them now that there's no hope of running into the end of extents ever again ... especially when my ever again is only about 3 more days. :-) Pat O'Keefe -- 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: nslookup only searching default nsinteraddr
On Tue, 22 Sep 2009 10:38:31 -0500, Chris Mason chrisma...@belgacom.net wrote: ... - After the resolver has successfully contacted a name server, it stops without contacting the remaining name servers for that query. Name servers beyond the first in the list are used only if the name server currently being contacted is down, or unreachable through the network. ... True, and applicable to NSLOOKUP, but NSLOOKUP doesn't use the RESOLVER; it has it's own internal resolver and accepts an optional name server address as a parm. That at least allows you to see if other name servers have the correct address. This behavior is exactly as intended and is appropriate. A not found is a perfectly valid repsonse. In fact, I'm pretty sure it is even cached by a caching name server. If in fact the address is invalid you don't want to go through your whole list of name servers trying to find it. All name servers in the list should contain the same information; that is a list of a primary and backup servers. Pat O'Keefe -- 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: Reading DD card information
On Mon, 21 Sep 2009 14:54:45 -0500, Paul Gilmartin paulgboul...@aim.com wrote: ... PARM='PARMX',PARMX='WAY LONGER THAN 100 CHARACTERS'. ... I'd be quite satisfied with this _provided_ it was compatible with the existing CALL, LINK, ATTACH, etc. argument lists. ... (And that symbol substitution would work within PARMX.) ... My vote doesn't count any more (as if it ever did!) but I can guarantee that whether you want this parm substitution to take place at Reader/Interpreter time, conversion time, or execution, I want one of the others. The world just works that way. But how would this facilitate implementation? I'm sure this is not why Rob suggested PARMX, but his suggestion would facilitate the creation of PARMR (for R/I substitution), PARMC (for Converter substitution), and PARMX (for execution substitution). I'm certainly not implying there is a way to allow that implementation to happen; just saying that there must be a way to pick or some people will be unhappy (as compared to the current situation where everybody is unhappy). Pat O'Keefe -- 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: Reading DD card information
On Mon, 21 Sep 2009 16:10:12 -0500, Paul Gilmartin paulgboul...@aim.com wrote: ... Awww, c'mon. That exposure has existed for classic PARM since the Dawn of Time, and we aren't hearing complaints, are we? Clarifying, by symbol, I meant JCL symbol, for which substitution is supported. I wasn't advocating substituting system symbols in batch JCL -- that belongs in a different thread. Actually, with Gilbert's example of inline SYSIN I thought the topic HAD switched to, or included, that other thread. (Yes, I know he could have been refering to a Console Started Job, but I hadn't thought of that.) I stand corrected, but I still think Rob's suggestion would make a perfectly good basis for for a solution to the system symbols in a submitted job problem. Pat O'Keefe -- 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
OT - End of a personal era
On Sept 25 my current employment ends, and since I'm not planning to look for another job, about 37 years of a system programming career ends with it. Although the last 20 of those years have been more support / administration / configuration of MVS communication-related software than any real system programming I still claim the title, and IBM-Main has helped my maintain that fiction. I discovered IBM-Main pretty late in my career (10-12 years ago maybe?) but since then it has been a constant source of both information and entertainment. IBM-Main is unusual among the online technical discussion venues in that it has a real sense of community. While this has resulted in many non-technical threads that have given Darren heartburn it also has added context to postings, making otherwise obscure comments understandable. I'd hate to think of that ever changing. I've decided I'll drop off the list in a week or 2 rather than hear more about all the neat new features of software and hardware that I will never see. (I'm already feeling obsolete by being stuck on z/OS 1.8 while others talk about 1.10, etc.) Should I forget this decision and start posting again feel free to remind me I have nothing useful to add. :-) Exception: I will probably hop back on the list late Feb to find out who's going to be at SHARE in Seattle. During SHARE I'll probably be wandering the halls - sans badge - snubbing people. Thanks and good-bye. Pat O'Keefe P.S. A slightly early Another one bites the dust. By the end of this year all mainframe processing of the former Washington Mutual Bank will have been transferred to JPMorgan Chase or eliminated. What a year ago was one of the largest MVS shops in the Pacific Northwest will power off its processors and cease to exist. I'm glad I won't be there to see that final Z EOD. -- 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: Interesting article on the future of mainframe programming and support personnel
On Wed, 16 Sep 2009 17:26:12 -0400, Gerhard Postpischil gerh...@valley.net wrote: Ian wrote: Take a moment and participate in the poll: http://www.cicsworld.com/ Like many a poll, it's missing some alternatives, making the results questionable. ... I think the results would be pretty questionable anyway. Except for one pretty large poll: If you are a Mainframe Programmer, Systems Programmer or Designer... What is your age groups? - 1325 votes - closed the most responses they've had was 206. They don't get much participation. And if the current poll is any example, they don't collect any demographic information. There is no way to tell if they get reasonable cross-section of the community. (And I wouldn't know how to tell anyway.) Has anybody tried voting twice? I decided not to since there was only 1 vote in my bucket. (If I'd been more on the ball I'd have noted which the largest bucket and would have tried to add another vote to it - less of a misleading impact that way (unless that's why it was the largest - everybody threw an extra vote into it). Pat O'Keefe -- 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: Interesting article on the future of mainframe programming and support personnel
On Wed, 16 Sep 2009 16:38:44 -0500, Ian pcs...@gmail.com wrote: ... Thanks Gerhard, leaving out an option for retirees was an omission. I've added 2 option. Unfortunately, the really important missing options are Already retired and no longer taking mainframe-related surveys and Dead (And no, I'm not trying to make a very tasteless joke. Not this time.) This survey will not show how much of the mainframe workforce has already shrunk due to people completely moving out of the field or (unfortunately) dying. I think that is a significant number of those in the profession when people started publicly worrying about the greying problem 10 years ago or so. Pat O'Keefe -- 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: TCB Address
On Mon, 14 Sep 2009 19:09:29 -0300, Digestani, Raul rdigest...@santanderrio.com.ar wrote: I'm asking about how to obtain current TCB address in an assembly pgm. Others have given helpful answers. I'll give the curmudgeonly answer. RTFM (where m can stand for either manual or macro). The Data Areas manual's description of the TCB and the IKJTCB macro both give a list of pointers to TCB. You will probably have one of these close at hand while you program anyway. I could have added If you have to ask ..., but I won't. I'm mellowing out in my old age. :-) Pat O'Keefe -- 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: TCB Address
On Tue, 15 Sep 2009 15:05:15 -0500, Diehl, Gary gary.di...@allstate.com wrote: Factual ?? Even though I'm one (of many, I'm sure) that started the Fine usage, in this case I'm sure it stands for Fascinating. Or perhaps Fun-filled. Pat O'Keefe -- 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: TSSO use of NETVIEW
On Thu, 10 Sep 2009 11:07:36 -0500, Chris Mason chrisma...@belgacom.net wrote: ... In the days of NCCF - and I think NOSP before it - and the first release of NetView, a semi-automation capability existed after the clist language was introduced. I describe it as semi-automation in that the operator had to keep an eye out for unsolicited messages betokening a problem. He/she then had to enter the name of the clist and commands could be issued - with name substitution from clist operands. If any delay was necessary, the operator could be instructed for which solicited messages to look out and what new clist commands to enter. Crude or what? Caveat: My introduction to NetView was to upgrade R1 to R2 in 1989 and we did not have any automation in place to be converted. My memory is a bit shaky and I didn't need to apply anything I was reading, but I vaguely remember the description of a rudimentary form of automation described that went a little bit beyond what Chris described. I think a clist named the same as a message id would be invoked automatically when the message was issued. (There may have been a table specifying the automated message. I don't remember. If so, it was a far cry from the automation table introduced in R2.) The description of that first NetView release describes Improvement of the capability to drive NetView CLISTs based on application messages (such as VTAM, CICS, and IMS) but NetView did not use the SSI until release 2 so I'm not sure how it saw the non-VTAM messages. (VTAM message would have been presented to NetView across the Program Operator Interface.) It would appear that during these dark days, TSSO offered a cleverer way which included actually trapping messages and entering commands fashioned by the information trapped - if I have understood the TSSO of the early '80s correctly. Anything sitting in the list of SSIs or invoked via MPF would have been able to be cleverer than that original NetView. I have no idea what technique TSSO used to get the messages it automated, but it would be hard not to be cleverer than that NetView technique. ... [1]. TSSO is described as allowing itself to be invoked from NCCF/NetView as a command processor, that is, TSSO has been extended to use one of the APIs which characterised NCCF - and the command facility component of NetView - as an enabling environment. The API in this case would have been to define TSSO as a command in NetView's command table definitions and to have TSSO access NetView's command parameter control blocks when invoked. I'm not sure what this would have achieved, though. It would be interesting to see the data flow though NetView and TSSO when used this way. I'm probably envisioning the wrong flow. Pat O'Keefe -- 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: ist663i suppression
Sorry for the late response. I was out of town last week (and will be again by the time this is read, probably). On Sun, 30 Aug 2009 09:36:51 -0500, Chris Mason chrisma...@belgacom.net wrote: ... However, the right way to go about suppressing the IST663I message and all the following messages in the message group is first to work out why the messages are there in the first place and then deal with the problem which causes them to be created. But as Chris says in a later post, this may not be possible. ... I'm assuming that at some time in the past somebody noticed that there were a lot of IST663I messages and, rather than bother about why they were being created, ... ... or knew there was no easy or desirable way to eliminate their creation ... ...cleverly recalled that the quick way to deal with unwanted messages was to use the NetView Message Automation Table (MAT), forgetting that the purpose of the NetView MAT was to get rid of messages which didn't really matter ... ... or perhaps remembering rather than forgetting. The NetView solution, in fact, works well if NetView is running with its Primary Programmer Operator function enabled. VTAM will pass most its messages to NetView across the PPO interface rather than issuing a WTO (thus keeping the messages from SYSLOG/OPERLOG). NetView then has a number of message-handling options: it (rather than VTAM) can issue a WTO for the message, and/or it can write the message to the NetView log, and/or it can automate the message, etc. as specified in NetView's automation table. In the past NetView's ability to reference information from multiple lines of a multi-line message was very limited. This was improved a few releases ago with the automation function ACQUIRE. One of the real advantages of using NetView to manage IST633I messages is the ability reduce the number of the IST663Is displayed based on the resource name or type: every 10th message for some resources; every 100the for another; no IST633Is for yet another. Unfortunately, NetView provides no straightforward ability to request (for example) one IST633I messages every 10 minutes for some resource. Don't bother looking for it; it doesn't exist. THRESHOLD sounds like the solution. It isn't. :-( Pat O'Keefe -- 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: RIP snubbing
On Fri, 28 Aug 2009 11:00:12 -0400, David Andrews d...@lists.duda.com wrote: I was not snubbed by anyone! I found everyone to be friendly and inclusive. This old joke once had a point, but now it simply is old and not very funny. ... I'm guilty first mention this time and I'm unrepentant. I said I was not going to be at SHARE and asked someone to snub people for me. Translation: I wish I were attending but I'm not. Greet people for me. Being a very strong SHARE advocate / bigot, I (and many others) happily took the term snub as a name for typical interactions at SHARE (which are very far removed from a snub). An in-joke that is not very in and not much of a joke but pretty innocuous as far as I'm concerned, and significant enough to be added to the Devil's IT Dictionary as mentioned in this thread. Pat O'Keefe -- 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: Need new 3270 emulator: SSH, inexpensive, reliable
On Tue, 25 Aug 2009 16:13:28 -0500, Hal Merritt hmerr...@jackhenry.com wrote: ... VPN is a good solution, but not PCI compliant. You shouldn't have sensitive data flowing over a network in the open. Period. You would use VPN to gain access to the network, but layer another solution such as TLS on top. ... I don't understand your comments about VPN. I can't speak to the PCI compliance since I haven't read the PCI specs, but there are many VPN configurations that don't have data in the clear except over the socket between the IP stack and the application. Ok, also within the stack between the IPSEC code and the socket code. Is it that clear data at the socket that makes VPN insecure? Pat O'Keefe -- 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: Forcing connection limits on CICS Sockets
On Wed, 26 Aug 2009 16:14:03 -0500, Henrique Seganfredo henri...@seganfredo.com wrote: ... I am thinking on a way of limiting the % of acceptance of sockets calls to the mainframe coming from the J2EE 'stress-test' servers. Is there anything that provides a way of forcing connection limits on CICS/Sockets? ... I assume there is a CICS parm to do this (and someone will tell you how), but if not, you can do this using the z/CS Policy Agent. Doing it in CICS is probably easier, though. Pat O'Keefe -- 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: Need new 3270 emulator: SSH, inexpensive, reliable
On Tue, 25 Aug 2009 10:35:18 -0700, John Mattson john_matt...@ea.epson.com wrote: ... Management ... now wants a SSH based 3270 emulation for accessing mainframe TSO, CICS, and such apps. ... Uh, something I've missed in the thread so far: What are you going to talk to? Does some vendor produce an SSH-based Tn3270 server? Or are you going to talk with some server that includes a Tn3270 client that then connects to the local z/CS Tn3270 server? (Maybe something sort of like HATS except with some special SSH client rather than a browser.) Or something else I can't envision? It looks to me like somebody has tried to define a solution rather defining the problem and then looking for solutions that address it. Pat O'Keefe -- 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: Fw: Fw: Binder API...broke or working as designed
On Mon, 24 Aug 2009 14:56:05 -0500, William H. Blair wmhbl...@comcast.net wrote: ... The problem for us was that we could not invoke the binder API as we assumed we would be able to, and the reason had to do with restrictions that originate in LE. For our application, that was a pretty clear-cut issue ... You can't do that. ... Warning: The following comment is based on total ignorance. It seems like better (but MUCH longer term) goal would be to have the restrictions in LE relaxed ot removed. If IBM is going to use LE functions as general purpose subroutines these functions work where needed and expected. Since I don't know what functions and restrictions are involved, I may be suggesting that fundimental laws of the universe be changed. But since the whole excercise may be tilting at windmills, this is just a probably just a bigger windmill. Pat O'Keefe -- 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: ISPF Counter
On Fri, 21 Aug 2009 07:36:42 -0500, Paul Gilmartin paulgboul...@aim.com wrote: ... Why is horizontal scrolling so much more difficult than vertical scrolling in ISPF? ... Well, for one thing, it's harder to know what the user (or developer) wants.If it's a table display doing vertical scrolling, the static lines stay as is and a new set of data lines are put into the display. For horizontal scrolling, what do you do if the static part of the panel definition contains a mix of truly static fields and column headers? Scroll some lines but not others? What do you do if when a horizontal scroll puts the left edge of the panel in the middle of field of data? Do you want to display the partial data field or do you want to restrict scrolling to whole field amounts? And are you sure you have the same answer for each display? BTW, if you want to display partial fields you are really redefining the field size in the 3270 data stream. If you are able to include the 3270 attribute in the data (It's been too long. I don't remember if you can do that in ISPF displays.) then behind the scenes the software has to find the attribute in the data an move it to its new location. Bottom line: Horizontal scrolling IS harder than vertical scrolling. There is nothing ISPF can do about it until it is enhanced to incorporate mind reading. Pat O'Keefe -- 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: IBM z/OS Management Facility V1.11 -- A new face for z/OS
On Thu, 20 Aug 2009 09:38:03 -0400, John Eells ee...@us.ibm.com wrote: Correction! The Service and Support is also priced at zero dollars. ... But SEPARATELY priced at zero dollars. Pat O'Keefe -- 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: SHARE in Denver
On Mon, 17 Aug 2009 09:42:52 -0400, Scott Rowe scott.r...@joann.com wrote: So, Denver is going to be my first real SHARE trip since 2000, who else is going to be there? ... Since my SHAREing days are over I humbly request you and/or others to snub someone for me. I'd hate to think that SHARE traditions were not being followed.:-) Pat O'Keefe -- 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: Any Utilities to Archive Members of a PDS/PDSE - Load Librari es, Not Source
On Tue, 18 Aug 2009 03:19:16 -0500, Paul Gilmartin paulgboul...@aim.com wrote: ... ...who can be held accountable if some thing goes wrong. Accountable? Better read the disclaimer carefully. A software provider like IBM or an ISV will fix a bug if you report it. But, they won't pay you for down time or lost data... I believe that. And even if you were to find a provider generous enough to indemnify consequential damages, they'd be likely to exclude ... customer's programming error and hardware failure. ... Any vendor naive enough to be that generous would be swamped with bogus reports of lost productivity due to the product's behavior. Pat O'Keefe -- 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
IBM Satisfaction surveys (Was: The Shame Approach)
On Thu, 13 Aug 2009 16:16:10 +0900, Timothy Sipples timothy.sipp...@us.ibm.com wrote: IBM takes a lot of customer satisfaction measurements, and there is a pretty good system for looking at trends and taking action if/when there are weaknesses. I don't know if the satisfaction measurement tools are employed uniformly across IBM. My PMRs have been almost exclusively for z/CS and zNetView (and their predecessors) and in the past I would almost always get a survey phone call shortly after a PMR was closed. (That has not been true for the last few PMRs.) I usually have good things to say because I usually get good service from those teams. The one time I really had a terrible experience (and had the PMR open for about 6 months withmost of the the time waiting for something from IBM) I did not get a call. I suppose that was just coinidence but it really irritated me. The one thing that was apparently missing in the survey process was a way to provide feedback on the survey itself. The last question was something like Would you recommend IBM Service to others?. Why yes; I tell all my friends and relatives to use IBM service. What kind of a question is that?!? (Stupid, THAT's what's what kind!)That question has been part of the survey for years, and I'm sure I'm ot the only one to complain. Pat O'Keefe -- 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: Concatenations and blocksizes
On Thu, 13 Aug 2009 14:02:48 -0700, Schwarz, Barry A barry.a.schw...@boeing.com wrote: Even though the PDS calls it a TTR, each member starts a new block so the situation you describe cannot occur. ... Thank you for corfirming what my questionable memory told me. Doesn't that also argue against what Paul Gilmartin said about NOTE on Mon, 10 Aug 2009 16:31:31 -0500: regarding my QPAM question: ... it's because the definition of the NOTE word has no provision for specifying the offset of the current record within a block. Or maybe I just misunderstood Gil's comment. Maybe I don't know what use of NOTE he was refering to. Pat O'Keefe -- 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: Concatenations and blocksizes
On Thu, 13 Aug 2009 16:58:21 -0500, Paul Gilmartin paulgboul...@aim.com wrote: ... My understanding/conjecture is that when the Assembler (for example), using BPAM, encounters a COPY nested within another COPY member, it: o Does a NOTE to mark the current block. o Saves the NOTE word _and_ the offset of the current source record relative to that block o Does a FIND to open the referenced member. At the end of that member, it reverses the process with a POINT and displacing to the saved offset. If the motivation of Q*AM is to make blocking and unblocking transparent to the program, the putative QNOTE would need to save both the TTR and the record offset in an opaque data object. QPOINT would need to employ both. ... Ok. I agree. A Q*AM version of NOTE and POINT would have to include record number or block offset or some such (just as that info has to be added to the NOTE data by a B*AM program). All those about to submit a formal request for QPAM should take note (so to speak). Pat O'Keefe -- 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: Missing QPAM (was: Concatenations and blocksizes)
On Tue, 11 Aug 2009 16:59:52 -0500, Rick Fochtman rfocht...@ync.net wrote: Ok. I didn't word things very clearly. ... QSAM handles individual members just fine so FIND, READ, WRITE and STOW are working under the covers. Seems like that covers most of the functions. Here I was just trying to say that the basic functions worked under QSAM. I should have addede to be built on and/or improved in a QPAM. I haven't written anything using BPAM since the mid '80s ... Keep that in mind! Did BPAM have an easy way to do an update in place? If so, I could have lived without that in QPAM. I assume there must have been more significant reasons than that. I thought BPAM had an update in place, but I wasn't sure. I was just trying to say that I would have accepted a QPAM even if that function couldn't be provided. Pat O'Keefe -- 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: The Shame Approach
On Wed, 12 Aug 2009 08:50:29 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: ... There does seem to be much more emphasis on getting PMRs closed than before. Someone's performance appraisal is probably based on the number of open (or closed) PMRs. ... I've also noticed a tendency for PMRs to be put on the customer queue even when waiting for something from IBM. This seems to vary from person to person, though. Maybe it's just irritating behavior on the part of the IBMer working the PMR rather than a policy to make the statistics look better. Pat O'Keefe -- 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: Missing QPAM (was: Concatenations and blocksizes)
On Tue, 11 Aug 2009 10:37:31 -0500, Rick Fochtman rfocht...@ync.net wrote: ... I was told that if you couldn't master the concepts of blocking/deblocking in BSAM, you had no business messing around with BPAM, which was designed as a add on product for BSAM. ... He was right, but that logic didn't prevent IBM from creating QSAM for those that couldn't master (read: had better things to do than) blocking/deblocking in BSAM. QSAM handles individual members just fine so FIND, READ, WRITE and STOW are working under the covers. Seems like that covers most of the functions. I haven't written anything using BPAM since the mid '80s so I am undoubtedly forgetting some BPAM quirks that might be tricky in a QPAM. Did BPAM have an easy way to do an update in place? If so, I could have lived without that in QPAM. I assume there must have been more significant reasons than that. Pat O'Keefe been -- 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: USSTAB
On Tue, 11 Aug 2009 10:47:37 -0500, Chris Mason chrisma...@belgacom.net wrote: ... I have seen system programmers deliberately colour their USS message fields without regard to whether or not the colour caused the field to become unprotected. Guilty as charged ... almost. Not exactly without regard to whether . More accurately even though. I had reason to want red (I think). I'm pretty sure I placed it after the normal input field so both the Insert Cursor order and the the HOME key positioned to the correct input field. (I have no idea if USS cares. It might process any input it finds, regardless of the field. But I didn't want to chance that not being the case.) Pat O'Keefe -- 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: USS misuse
On Tue, 11 Aug 2009 14:24:59 -0500, Ed Rabara edrab...@yahoo.com wrote: ... By design, the standalone TN3270 Telnet Servers were to remain active when the TCPIP address space was terminated, with the expectation that TCPIP will restart shortly. ... Ed, you made the same misinterpretation I did.Barbara's problem was with bringing OMVS down, not the TCP/IP address space. And at least one of the Tn3270 address spaces was unusable after OMVS was restarted. This was NOT a design point for the Tn3270 server. This was a bug. Pat O'Keefe -- 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: Concatenations and blocksizes
On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden mark.zel...@zurichna.com wrote: ... CONCATENATION ENHANCEMENT: Like-attribute concatenation will be allowed for eligible data sets with different block sizes in any order; the largest no longer need be first. Eligible data sets are partitioned or sequential data sets that are DASD-resident, accessed by QSAM, and for which the system obtained buffer space. ... Interesting wording. partitioned ... data sets ... accessed by QSAM ... If they really meant that, wouldn't that restrict this enhancement to a concatenation sequential datasets and/or PDS members? Doesn't a PDS or concatenation of PDSs have to be accessed by BPAM? I assume they meant QSAM or BPAM. (I could ask for the umpteenth time why there is no QPAM, but I won't.) Pat O'Keefe -- 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: Concatenations and blocksizes
On Mon, 10 Aug 2009 17:36:44 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick O'Keefe Sent: Monday, August 10, 2009 4:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Concatenations and blocksizes On Mon, 10 Aug 2009 15:20:53 -0500, Mark Zelden mark.zel...@zurichna.com wrote: ... Interesting wording. partitioned ... data sets ... accessed by QSAM ... f they really meant that, wouldn't that restrict this enhancement to a concatenation sequential datasets and/or PDS members? Ok. I shouldn't have included that statement. It just muddied the water. Doesn't a PDS or concatenation of PDSs have to be accessed by BPAM? That's what I was really trying to ask. ... No. If you take a program that uses a QSAM DCB and point the DD statement to a PDS with member name, it will read that member and treat it as if it were reading a DSORG=PS data set. The QSAM code will detect end of member and treat that as if it were EOD (and I think it even drives your EOV exit if you have one). I know a single member can be read with QSAM. I assume a concatenation of members can be read by QSAM. I was actually trying to exclude that uninteresting case from consideration. ... So if you concatenate a series of DSORG=PS data sets together, you can't concatenate a PDS as a PDS in the middle. ... And I didn't want to. ... OTOH, if you concatenate PDSs together as PDS and then stick in a DSORG=PS I would imagine you will get a very interesting ABEND And luckily I didn't want to do that, either. I'm just puzzled that the enhancement limited itself to QSAM. No mention of BPAM. Pat O'Keefe -- 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
Missing QPAM (was: Concatenations and blocksizes)
On Mon, 10 Aug 2009 16:31:31 -0500, Paul Gilmartin paulgboul...@aim.com wrote: ... (I could ask for the umpteenth time why there is no QPAM, but I won't.) If you had asked (which you didn't) someone might have answered that it's because the definition of the NOTE word has no provision for specifying the offset of the current record within a block. But that merely regresses the question (which you didn't ask) one level. ... Ok. I'll buy that. But NOTE didn't return anything at all until they wrote it. So I'll regress: These smart people could also have written NOTEX or QNOTE that returned all that was required to do queued processing of the member. There must have been some reason they did not. I hope. What was that reason? Anybody know? (Idle curiosity.) Pat O'Keefe -- 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: Concatenations and blocksizes
On Mon, 10 Aug 2009 17:20:48 -0500, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 10 Aug 2009 16:52:59 -0500, Patrick O'Keefe wrote: I'm just puzzled that the enhancement limited itself to QSAM. No mention of BPAM. I had hoped this was an oversight in the doc, but apparently not. An assembly with: //SYSLIBDD UNIT=SYSALLDA,SPACE=(80,(1,1)), // RECFM=FB,LRECL=80,BLKSIZE=80 // DD DISP=SHR,DSN=SYS1.MACLIB Fails with: * TOP OF DATA ** ** ASMA999U Assembly terminated - SYNAD Exit taken - Permanent I/O error on SYSL ,HELLO ,C ,4140,D,SYSLIB ,UNKOWN,WRNG.LEN.RECORD,00 001F7100030 ... Um, I've got a hunch that wasn't a concatenation problem. Did you have another dataset in the concatenation with a large blocksize? If not, you probably got a blocksize of 80 ... much smaller than the length of the records (blocks) that have to be read. Pat O'Keefe -- 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: VTAM security issue
On Sun, 9 Aug 2009 16:03:33 -0500, Paul Gilmartin paulgboul...@aim.com wrote: On Sun, 9 Aug 2009 11:57:15 -0400, Anne Lynn Wheeler wrote: possibly SNA organization viewed it as competition (even tho SNA had nothing to do with networking). Now I'm confused. What does the initialism SNA stand for? Or, while this list is focused on initialism pedantry, is it possible that there's another SNA than the one I found at the top of a Google search? ... Well, the N is Network, not Networking, but I don't think that clarifies anything. Lynn apparently has some very specific defibition of Networking in mind. His comment may be accurate (His comments usually are.) but I'm not sure what that comment really was. SNA does not have a universal addressing scheme and IP does. Perhaps that was the point. But SNI provided that in sort of the same way that NATing allows interconnection of 2 IP networks that use private IP addresses. SNA does not provide a universal name space for resources, but neither does IP. The Domain Name space used by IP hosts is not provided by, or dependent on IP. Pat O'Keefe -- 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: Telnet, was: Re: USS misuse
On Fri, 7 Aug 2009 00:05:02 -0500, Barbara Nitz nitz-...@gmx.net wrote: What did NOT come down were the three corresponding telnet address spaces. This was by design. (Not just working as designed.) But that's not true! When OMVS starts to go away, without *any* stop or other command the telnet address spaces *do* start terminating! Ah! I misunderstood and so my comment was not relevant. The working as designed part was the Tn3270 server staying up if the stack goes down. I don't know what the appropriate behavior if OMVS goes down (or starts to go down). There must be some sort of provision, apparently it just wasn't tested, much less fixed. ... That's just my point: We are not talking 'broken as designed' here, we are talking BUG here, which IBM normally even fixes via ptf! Yes. This sounds like APARable behavior. Unless they designed the server to purposefully hang. ... 2. In a multi-stack environment access to Tn3270 may still be available through another stack. (I did not hear this justification from IBM and have never worked in a multi-stack environment so I don't know if that explanation holds water.) Aha, where did you hear that? ... I think it was a discussion at SHARE, but since I have never been in a multi-stack environment (multi-stack on one LPAR, that is), I didn't pay much attention. Interestingly enough, IBM support hasn't told me that the third telnet asid NOT coming down was by design, too! :-) The third one also started to terminate, but never 'blocked' OMVS shutdown, so it remained up in half-terminated state throughout OMVS restart, and obviously didn't really work afterwards. I'm sort of surprised that anything in TCP/IP worked after a restart of OMVS, and I'm not surprised that different parts failed (or not) in different ways. There must have been timing dependant failures all over the place. Does IBM claim that TCP/IP and its associated bits and pieces can survive the loss and restart of OMVS? If so, they should make it work. Pat O'Keefe -- 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: USSTAB
On Fri, 7 Aug 2009 00:28:07 -0500, Barbara Nitz nitz-...@gmx.net wrote: Fixing USS design flaws isn't going to be very high on anybody's list. But having enough complaints from different people (not just me - after all, we're just someone out in Europe!) may get a few of the 'suits' thinking, and a few technicians in a position to do something about it might start pushing for better solutions and for introducing better designs! I suggest people that want this start opening lots of PMRs and submitting lots of formal requirements. This is going to take work from both Tn3270 development and VTAM development (because they own the macros). VTAM development is spread VERY thin now so this is going to have to be seen as really important to customers by management. Pat O'Keefe -- 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: ibm Tivoli ETR support
On Fri, 7 Aug 2009 00:34:50 -0500, Barbara Nitz nitz-...@gmx.net wrote: ... Yes, I meant Kathy. While I certainly say congratualtions for the promotion, I still have to ask why a very good technician has to become a 'suit' :-) ... I may be wrong, but I thought she was supervisor of the group for many years. She may have just been first among equals. In other words, she may not officially be a suit. Pat O'Keefe -- 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: USS misuse (was Re: Mainframe hacking)
On Fri, 7 Aug 2009 17:26:54 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: ... It is also a problem that some time after 1991, the IBM internal standards were apparently discarded (apparently with management blessing). There were specific naming standards, specific requirements for program directories (and their very specific formatting), etc. ... I'm afraid you are right. There was a time when unexpected behavior could be flagged INCORROUT and a design could be just as defective as code. (I don't know if that was ever an official policy, but it seemed to be the way Service worked.) But that was back when IBM had people around to fix problems. A lot of those people have retired, moved to other positions, become suits, etc. In the past I've argued myself blue in the face of Broken as Designed issues. (Not problems. Just ask IBM. Can't be a problem if it's working as designed.) But now that all the development, change, and level 2 support teams have evaporated, and now that my technical relationships with some of those left have been replaced by friendships, I tend to take less strident tone. Submit a Requirement. No, you shouldn't have to, but the lone developer where there used to be 10 is going to be working on high priority changes (when he's not stolen by Service to work on a Sev 1 bug). Even if you get them to accept a PMR it's going to a Sev 3; your grand children may see the PTF. So submit a Requirement for it. (I'm a lot more comfortable saying that now that I'm no longer the Requirements Coordinator for SHARE's Networking program.) Pat O'Keefe -- 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: USS misuse
On Thu, 6 Aug 2009 00:44:20 -0500, Barbara Nitz nitz- i...@gmx.net wrote: Recent experience has shown (and resulted in *a lot* of ETRs) that TCPIP cannot exist without the OMVS address space ... This is absolutely the case. The TCP/IP address space will hang in initialization if Unix System Services is (are?) not available. I think the symptoms may vary with release. What did NOT come down were the three corresponding telnet address spaces. This was by design. (Not just working as designed.) I've heard 2 justifications for this: 1. Faster recovery if a TCP/IP stack crashes. Depending on the Tn3270 configuration, Tn3270 initialization can be lengthy. 2. In a multi-stack environment access to Tn3270 may still be available through another stack. (I did not hear this justification from IBM and have never worked in a multi-stack environment so I don't know if that explanation holds water.) In my opinion (which counts for nothing) this was not the right decission, but it was a purposeful one, not ust an accidental implementation. I think they could have made this behavior optional, but they forgot to ask me. :-) Pat O'Keefe -- 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
Concatenations and blocksizes
On another list someone found some product doc that still mentioned having the largest blocksize first in a concatenation. While trying to reassure the person I realized how little I actually knew about the topic. So I've got some questions. (Idle curiosity.) 1. How long ago did this requirement disappear? 2. Did SMS relax the restriction or did it cover all concatenations? 3. What changed? Does OPEN find the largest blocksize in the concatenation before allocating buffers, or does it simply allocate buffers large enough for any blocksize? Or something else altogether? 4. Are there still instances of concatenations with this restriction? Thanks. Pat O'Keefe -- 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: USSTAB
On Thu, 6 Aug 2009 14:20:53 -0500, Martin Kline martin.kl...@yrcw.com wrote: ... BTW, for everyone (anyone?) who bothered to read this far, how many use a custom USS table? Is it just Chris, Patrick, myself and a couple other people in the world? ... You already know I'm in the customized camp, but I thought I'd add: I've worked in only 5 shops since the early 80's (when I first got into VTAM) but all used customized USS tables - both VTAM and Tn3270 when it came along. Pat O'Keefe -- 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: ibm Tivoli ETR support
On Thu, 6 Aug 2009 00:17:07 -0500, Barbara Nitz nitz- i...@gmx.net wrote: I would not call it delayed support, but extremely incompetent or more bluntly incapable support. In our case it is Netview, and the person has no clue whatsoever what a sliptrap does and 'works with MVS' ... ... Whatever happened to the competent NetView lady who has done this support for years? ... Barbara, I tried sending you a response off line but that bounced so here's a very cut down response - no last names named. If the lady you refered to is Kathryn, she is still in NetView Service. I think she is a manager or supervisor now and rarely handles PMRs. You could try asking for her but I don't know if that would work. If you meant Denise, she is now longer with NetView (but was still with IBM last I heard). If you meant Betsy, ... well, I doubt you meant her; that was too long ago and I don't know what happened to her anyway. All 3 could be described as the competent NetView lady but I bet you mean Kathryn. She's been there since at least 1990. Comments I was making about some of the other people in NetView level 2 Service I will make only off line. I will say online that the level 3 (change team) people are very good. Pat O'Keefe -- 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: Concatenations and blocksizes
On Thu, 6 Aug 2009 18:28:16 -0500, Paul Gilmartin paulgboul...@aim.com wrote: A problem that I have had in the past was someone updating a PDS with a blocksize on the DD which causes the blocksize in the vtoc to be changed. It is a misdesign that the OS allows this ever to happen. The principal use of this facility is to correct errors that were introduced by its earlier inadvertent use. Simply, any OPEN for WRITE with overriding attributes where the label contains different nonzero attributes should ABEND for inconsistent attributes. I strongly agree with that, but ... If the programmer feels compelled to change attributes the recourse should be: o ZAP the VTOC, or ... I don't agree with that.Using a utility that requires knowing the format of the label is asking for trouble. Sure, zapping the VTOC is don't gazillions of times a year, but it's (usually) done by techies. The fixing of a hosed over blocksize should be able to be done by the same people that hosed it over in the first place, and it should be safe enough that it won't hose over something else. But it should NOT be a function available in data copying utilities like GENER. The should fail as you mentioned. o COPY, reblock, and rename. Well, yes, definitely ... if the dataset is readable enough do do that. Pat O'Keefe ... -- 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: USSTAB
On Tue, 4 Aug 2009 19:03:22 -0500, Chris Mason chrisma...@belgacom.net wrote: ... Yes, the whole design is a total mess. I suggest you hit your IBM support with this shoddy design with as much force as you can muster. It's incompetence piled on incompetence, in the implementation *and* the description. It shows what can happen when the suits force a quick-and-dirty enhancement and use developers who clearly don't understand the environment in which they are working to implement it. I don't have any of the inside IBM connections that Chris has so I can't say he is wrong, but I see this much differently on a number of points. 1. The product is working as designed. If you want this changed you're going to have to submit a Requirement with a very strong business case. Fixing USS design flaws isn't going to be very high on anybody's list. 2. If siuts were involved I think they were those that decided staffing levels. 3. I may be thinking designers rather than developers, but I don't think incompetence is an operative word here. On the TCP/IP side this is a very small group (possibly one person) working on less than stellar code. On the VTAM side I suspect it is down to about nobody - not for the USS part. Rather than incompetence, I suspect this is a matter of wanting to touch a house of cards as little as possible. ... Instead the people of inadequate intelligence have amazingly done the exact opposite. Once again, I may be thinking designer rather than developer, but I think this is a very unfortunate characterization. He is in no way of inadequate intelligence. ... I'm guessing that the reason they shied away from altering the USSMSG macro ... is that they didn't want to involve the SNA (VTAM) side of the Communication Server house in their clandestine enhancement. I think it much more likely that there was nobody on VTAM side to work on it. They are (he is?) stretched pretty thin. It's cheaper if you just impose the change in the TN3270 server logic. Or possibly that was the only way to get it done at all. Pat O'Keefe -- 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: USSTAB
On Wed, 5 Aug 2009 20:07:50 -0500, Chris Mason chrisma...@belgacom.net wrote: ... To someone who understands the matter - see the analysis above - incompetence is the only word that seems to fit. The appearance of incompetence may have been forced on both the designers and developers - in which case my abject apologies to them ... All I can say for sure is that the one person I assume was involved is not incompetent. ... On the TCP/IP side this is a very small group ... The change to the stand-alone TN3270 server took place around the same time as this enhancement which implies somebody or some bodies reasonably competent with TN3270 function was/were available. And very busy creating the stand-alone Tn3270 server, I assume. I suspect this is a matter of wanting to touch a house of cards as little as possible. The bulk of the work is in performing the substitution. What's missing is the (sub)operand setting a bit which asks permission to use system symbols with maybe a few words not dissimilar to my analysis above concerning the care that needs to be taken. I can a see a political process arising there because that involves the macros - which aren't that complicated - but that's VTAM territory. My house of cards comment was based on hearing that as the reason for not touching other things in the Tn3270 server. I very well may not apply in this case. But (as you mentioned) changing the macros requires coordination with VTAM development and he is spread pretty thin.(Ok. That may be an exaggeration, but from what I hear it's not much of one.) ... Once again, ..., but I think this is a very unfortunate characterization. He is in no way of inadequate intelligence. This was an euphemism for what I really wanted to say. ... If you know someone - you suggest only one - who is likely to be involved, it would be fascinating to know the inside story. If this discussion were happening on the TCP/IP list rather than IBM-Main he might respond. (And he might say there are more people than one himself working on Tn3270. I don't know.) But I doubt he would be willing go into much behind-the-scenes detail. Similarly, the last time I thought about it, I could come up with two names on the VTAM side. And I suspect one is in design, one is in development, and both are more heavily involved in Enterprise Extender (and maybe some other APPN stuff) than anything else in VTAM. That's about all I come up with, too. Since I've dropped out of SHARE and am about to drop out of my career I no longer have professional contact with them and am not going to risk the friendships by asking them about this. ... The IBM I used to know had quality standards to set against accounting considerations. Yes, that used to be the case. Unfortunately, things change. :-( ... I don't have any of the inside IBM connections that Chris has ... Actually my closest contact near IBM development has left in the last few months. FSVO left. Frome what I heard, his being laid off caused a lot of anger (and worry) in those remaining. In any case I'm an ex-SE. It was expected of SEs that they should be gentle to customers and less gentle to developers[2] - it was their job! And through SHARE I've been interacting with some of those developers as people (rather than as anonymous parts of IBM) for many years and see them in a really difficult situation now ... made a worse by the recent lay offs. Pat O'Keefe -- 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: USS misuse
On Sun, 2 Aug 2009 01:26:11 EDT, Ed Finnell efinnel...@aol.com wrote: ... Not much litany, but IBM has put out Dictionary of Computing for years. ... Online found this but it's poorly indexed. _http://www-01.ibm.com/software/globalization/terminology/index.jsp_ (http://www-01.ibm.com/software/globalization/terminology/index.jsp) ... Interesting. USS is clearly Unformated System Services in that listing. No abbreviation is mentioned for Unix System Services (but that implies nothing given the way the list is laid out). OMVS is mentioned only as the name of RACF segment. OE is not mentioned at all. No z/... abbreviation or phrase for anything Unixy except for zFS . Even z/Linux is omited. With about 30 years involvement with Unformated System Services (first VTAM, the both VTAM and Tn3270) and the rest of my career measured in weeks, I think I'll ignore the suggestion that flexability is needed. :-) Pat O'Keefe Pat O'Keefe -- 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 PREFIX Enhancement (UK44477)
On Thu, 30 Jul 2009 17:39:12 -0500, Chris Craddock crashlu...@gmail.com wrote: ... Call me a wuss, but I just type FILTER ? and get a fairly i ntuitive series of panels. . Ok Skip, You're a wuss. :-) ... Note that Chris comes emerges from lurkdom only when the most technical of responses is needed. :-) Pat O'Keefe -- 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: ICF - Information Center Facility
On Fri, 31 Jul 2009 10:52:14 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: Just out of curiosity, does anyone actually use ICF - Information Center Facility? ... Is ICF the same Information Center as in the Eclipse-based doc viewing cr..., uhr, system? If so, I had to use it as part of a beta program (the things IBM used to call ESPs). That was the only way the product's doc was provided. But that system called itself IBM Help System so it may not be what you are asking about. The only thing I liked was a fairly good multi-doc search facility, and that was negated by my never figuring out how to limit the search to the one manual I was reading. (I'm sure the capability was there. I just never found it.) As near as I can tell this was just another way of presenting all of BookManager's inconveniences to the user (but with IBM using someone else's implementation). Luckily I was able to get to a PDF copy of each manual from within the system. Pat O'Keefe -- 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: USS misuse
On Fri, 31 Jul 2009 09:47:55 -0500, McKown, John jmck...@healthmarkets.com wrote: ... How are VTAM Unformatted System Services and z/OS UNIX System Services the same context? ... Because it is not VTAM Unformatted System Services any more. It is z/CS Unformatted System Services, and once the context is TCP/IP both Unix System Services and Unformatted System Services are appropriate. This whole thread exists because people reading a posting picked the wrong context! Pat O'Keefe -- 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: SMTP misuse (was: Sending email via rexx)
On Thu, 30 Jul 2009 08:08:59 -0500, Paul Gilmartin paulgboul...@aim.com wrote: On Thu, 30 Jul 2009 11:05:45 +0200, CUNY Yann wrote: You can use SMTP directly with REXX. (Socket REXX). Here we go again. There are two email facilities generally available on z/OS: one with a JES interface, customarily called SMTP; the other with a socket interface, customarily called sendmail. Actually, I've never heard the thing that interfaces with JES called SMTP (unless that is the name of the proc used). SMTP server or SMTP daemon, yes; SMTP, no. Perhaps SMTP is used that way in some shops, but I wouldn't call it wide spread. RFC 821 et. al. describe Simple Mail Transfer Protocol, abbreviated SMTP. Its description more closely matches the facilities of z/OS sendmail than of z/OS SMTP. Both the z/OS sendmail and SMTP daemon use SMTP. Sendmail has a lot more functionality, but both make use of the protoocol. No need for controversy; merely clarification. I know. I'm probably introducing controversy, but I'd hate to see SMTP used for somthing beyond the protocol itself just because they read it here. Pat O'Keefe -- 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: Of link lists and application programs
On Mon, 27 Jul 2009 08:27:38 -0500, Paul Gilmartin paulgboul...@aim.com wrote: ... o Does the OS hold LNKLST data sets open, thwarting reclaim of PDSE unused space? ... LLA and XCFAS on every LPAR in the Sysplex that has the dataset in the LLA. Depending on how many LPARs have the dataset LLAed you can have a LOT of work to get that space reclaimed. (Note: rambling anecdote follows. ) In my previous shop I had a loadlib of a non-IBM product in the linklist. Maintenance of this product was separate from our standard mantenance procedures. Once maintenance had been applied and tested in its target libraries I would bring the product down on all LPARs, copy from target libraries into run time libraries, compress them, do an LLA UPDATE on all LPARs, and restart the product. I got tired of having the loadlib overallocated to handle the copy so I switched to a PDSE with just a little extra space. All was fine until I had maintenance to apply. I was able to copy 4 out of a couple hundred modules before the library filled. Out of panic I decided to delete all modules from the library and tried again. :-( Very bad decission! I knew of no way of seeing who had the library open but after seeing 12 ENQUEUEs on it, I gave up. A few minutes later I was back on a PDS. Pat O'Keefe -- 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: Sending email via rexx
On Wed, 29 Jul 2009 09:13:55 -0400, Baraniecki, Ray ray.baranie...@morganstanley.com wrote: ... Address TSO XMIT BLDVMB.VNETIBM DDNAME(EMAILFIL) ... XMIT-formatted emails are rejected by our SMTP daemon with a message claiming we need the gateway function enabled - the part of the SMTP daemon that allows it to write to (not just read) the spool. The messgae is correct; we don't have that function enabled. But the relationship between tge XMIT spool members and the need to write to the spool is not at all clear to me. It may be because of some poorly chosen parms. That is, it might fail with more meaningful messages if we did have the gateway function enabled, but we don't (and it's going to stay that way). Pat O'Keefe -- 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: Operator Validation before Executing Command
On Tue, 28 Jul 2009 17:55:11 +, Ted MacNEIL eamacn...@yahoo.ca wrote: ... Before automation, we had to enter a $PQ,Q=... I was going to bring that up. There were probably VERY few times when $PQ was entered on purpose but if entered it was processed without question. The only time I saw it happen the command was immediately followed by a finger pressing LOAD. Only a few dozen listings were lost. Nobody questioned that solution, but those were simpler days back then.(And that is no longer an available solution anyway. Doing the load via the HMC? You'd have a pristine queue before you got logged on.) There are some commands that are just so unlikely that they should be questioned. But that should probably be done by something with significant inteligence, not applied to everry command that could possible do harm. Pat O'Keefe -- 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: USS misuse
On Tue, 28 Jul 2009 16:39:15 EDT, Ed Finnell efinnel...@aol.com wrote: ... We did not chose USS as an acronym for z/OS UNIX System Services. ... In reality, herding cats is easier than making absolutely sure that everyone uses the correct full and short names all the time in all contexts, formal and informal, but we keep trying. ... Just doing a quick USS search of Austin SHARE shows Vanguard considers it a current acronyn as does IBM's Marianne Hamner in her differences updates. ... It's also in some RedBooks. That doesn't change a thing John said. It's just naming some of the cats. In fact, USS is obviously an acronym (or abreviation[1]) for Unix System Services, just not an official one. Pat O'Keefe [1] I don't have much time left for pedantry. Complaining about the (supposed) misue of both USS and acronym in one posting saves time. -- 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
Compiled REXX behavior - SEALPA vs. SEAGALT
Just in case somebody else is not aware of this, ... The behavior of a compiled REXX exec can depend on which run time library is used - the SEAGLPA library provided with the compiler or the so called ALT library SEAGALT (for shops without the compiler). One big difference: when using SEAGLPA, the REXX Halt condition is not raised unless the exec was compiled with the TESTHALT option or the source contained the %TESTHALT directive. When using SEAGALT the exec acts like uncompiled REXX - the Halt condition is automatically checked regularly during execution. This means the developer of an exec that is going to be provided compiled has to take steps to enable Halt detection. I doubt all REXX developers know that. (Some IBM developers didn't know it. ) I know the above is true for compiled execs provided as execs. Compiled REXX execs can also be bound into load modules. I don't know if these use a run-time library or have all the needed runtime routines linked into the load module. I suspect they use the library so would have that same library-dependent behavior. Pat O'Keefe -- 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: Mainframe hacking (getting back on topic)
On Sun, 26 Jul 2009 22:54:52 -0700, Ed Gould ps2...@yahoo.com wrote: Not true... We had a programmer who wrote an SVC screener ... SVC screener = APF. APF means that you can update the dataset without opening it. So??? countless installations still do not have a clue about APF libraries. ... The so is that once you're talking about APF authorized programs MVS security concerns are no longer on the table - the door is open. The technique used at that point - manual response to a security prompt, automated response to a security prompt, access to the dataset without going through a security check, etc. doesn't really matter - technical details. If a shop has lax controls over authorized libraries then they indeed have a security problem, but it's not a mainframe problem; it's a management problem. Pat O'Keefe -- 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: USS misuse (was Re: Mainframe hacking)
On Mon, 27 Jul 2009 09:26:33 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: ... The picture and last laugh came from one who had been rebuffed for pointing out the confusion caused by using USS instead of OE or OMVS, or some such. ... I admit I could not tell who got the last laugh and who or what was being laughed at, but suspected I might be in the laughed at catagory. I guess Chris felt that a bit more strongly than I did. I think we were both wrong. And to show how deeply entrenched I am in the old (real :-) ) def of USS, when I saw the subject I thought, Oh oh. I misused USS once. I replaced the default IBMTEST with something that displayed a whole buch of diagnostic stuff. And if nobody but Chris understands what I just said, well, that's fine. Pat O'Keefe -- 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: USSTAB
On Fri, 24 Jul 2009 09:02:42 -0500, Chris Mason chrisma...@belgacom.net wrote: Martin Note that there is only one set of USS macros and they some from a VTAM distribution library, SISTMAC1. The IP reference, however, also indicates that you can use system symbols, whereas the SNA reference does not. ... It's important to remember that even though the same USStab load module can the used by both VTAM and the Tn3270 server, different code processes the table. VTAM development could have have put support in the macros for functions supported only by the Tn3270 server. It's sort of unlikely that they did that. It's much more likely that the doc and the code are out of synch. Pat O'Keefe -- 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: Downloading large datasets to PC is that Mainframe any Performance issue ?????
On Wed, 22 Jul 2009 16:23:38 +0530, Sachin T sachin.sach...@gmail.com wrote: I am downloading it through FTP... One of the biggest factors effecting large file transfers is the TCP window size, especially if you have a high speed connection with significant latency (i.e., a long distance). You will spend most of the time waiting for acknowledgements. The problem: the number of unacknowledged bytes is help in a 16 bit field in the TCP header. After sending that many bytes you have to wait for an Ack. The solution: during the initial TCP handshake, agree to multiply the value in outstanding window field by a scaling factor. Whenever we have had significantly slow TFP transfers over an otherwise fast connection, this has been the problem. We ran into this a LOT when we moved a datacenter and transfers that had been across the computer room floor now had to go 2000 miles. Those transfers that used large scaled windows had no problem; those that were restricted to 64K The Z/OS FTP server has supported window scaling for eons. Most FTP clients supports support it too, but it may not be automatically enabled, and guessing the name of the knob to turn it on is anybody's guess. Key phrases to look for when researching this issue: TCP window scale receive window size Long-Fat Networks, or LFN RFC 1323 Good luck. Pat O'Keefe -- 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: Mainframe hacking (getting back on topic)
On Wed, 22 Jul 2009 21:12:40 +, Ted MacNEIL eamacn...@yahoo.ca wrote: Also many operators acquired the bad habit of replying U to everything, and only checking what it was for if it didn't work. Unfortunately, auto-ops has that same opportunity. ... There is no incorrect manual action that cannot be done a lot faster through automation. :-) Pat O'Keefe -- 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: Mainframe hacking (getting back on topic)
On Mon, 20 Jul 2009 14:43:32 -0400, David Cole dbc...@colesoft.com wrote: ... A couple of years ago, there was a thread called Back doors. I posted something there about the vulnerability of z/OS to hacking. Here's the link: http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608L=IBM- MAINP=R63457X=2F4EDA1D0DDA5823A7-Y=dbcole% 40colesoft.com (The resulting silence was deafening.) ... Maybe the result was silence that time but the general topic has been discussed a number of time in a number of venues. I think you were saying that you have the keys to the realm if you are an authorized program and IBM requires authorization for far too many services, so it is far too easy to stick back-door code in a program that needs to be authorized. That certainly is a hole in mainframe security, but I don't think of that as a hacking issue. (I'm going to assume the hacking in the original posting was meant to imply a breaching of MVS security by outsiders where outsiders could be either outside the company or outside the group of legitimate users - a meaning real hackers would find very offensive.) Writing a back door is an inside job. It could be an interesting hack, but I don't think that's what the OP meant. MVS security (when used) does a good job of keeping outsiders out, but no system on any operating system is safe from those that are given the authority to bypass the security. Pat O'Keefe I think hacking around or through MVS security is very rare. -- 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: IBM error messages getting worse?
On Fri, 17 Jul 2009 18:32:29 -0600, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: I have a very basic one to complain about: DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ This really means that the specified PSB DDMPPSZ is not in the specified IMS library. Why can't it just say that? As an application programmer do I really need to know that BLDL means, well, whatever it means? ... I think this is a pretty common example of an error message saying what rather than why. Maybe it was written by a coder that had no idea why the BLDL was issued or a developer who was just too close too close to the code. It's accurate but not helpful. But I doubt this is much more common now than in the past. Pat O'Keefe -- 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: IBM error messages getting worse?
On Wed, 15 Jul 2009 22:33:38 -0700, Ed Gould ps2...@yahoo.com wrote: ... Pat:I am not sure I agree , but I think that most USS messages are at best inscrutable. Since I'm one of those that gets anal over this use of USS, I'll object up front and you can not care starting now. More importantly, I'm not sure what messages you are referring to. The TCP/IP messages you mention below are standard MVS msgs, not Unix messages. (I agree that the Unix messages are indeed inscrutable.) Take TCP as an example most of the messages I had to look up at the time did not follow the IBM convention as to importance (W,I,E,C) and then they didn't set the condition code to match the message. The IBM convention as to importance (W,I,E,C) does not apply to console messages. As far as I know this has always been the case. For console messages I believe W is for a Wait State message, E is for an eventual response needed, and I'm not sure the other 2 are used at all. To the extent that the convention you refer to exists at all, I think it is for SYSOUT messages like from compilers, etc. I'm hard pressed to think of TCP/IP messages associated with condition codes so I assume you mean other USS messages. But last I knew there were 4 volumes of TCP/IP messages; there are a lot of both good and bad messages. I can't comment on the other messages you are referring to because I don't know which they are. Pat O'Keefe -- 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: IBM error messages getting worse?
On Thu, 16 Jul 2009 07:01:03 -0500, Chris Mason chrisma...@belgacom.net wrote: ... ideally USS messages are composed within the installation and so, if they are inscrutable, the person to whom to complain should be available with an in-organisation telephone call - assuming the original author hasn't been let go. ... I have to admit that USS messages cannot be looked up in a Messages and Codes manual, cannot (except for the default messages supplied by IBM) be the subject of PMRs, RCFs, etc. And they often ARE inscrutable. If Ed hadn't added his final disclaimer I would have had to agree with him. :-) Pat O'Keefe -- 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: Article Mainframe Stolen
On Thu, 16 Jul 2009 11:46:40 -0500, Rick Fochtman rfocht...@ync.net wrote: ... The proliferation of the PC has resulted in another proliferation: that of self-proclaimed experts that know next to nothing, but have loud voices. ... Oh, come on! We've existed and proliferated long before PCs! :-) Pat O'Keefe -- 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: What is the current philosophy on running SMP/E ACCEPT on z/OS?
On Fri, 17 Jul 2009 16:06:29 -0700, Guy Gardoit ggard...@gmail.com wrote: ... why would I want to try to RESTORE one or more troublesome PTFs?? At worst, just IPL the production system(s) from the previous resvol (set) until the problem can be determined and fixed. IPLing off the old resvols is the obvious quick solution, but you are backing out all maintenance when you do that. That may not be an acceptable (so to speak) long term solution (and clearing up some PE messes has definitely fallen into the long term category). ... I see no inherent 'danger' in ACCEPTing major maintenance as long as you have a back out plan of some sort. I'd prefer not to rely on the RESTORE function from prior ugly experiences. ... I see fighting with even the ugliest RESTORE situations preferable to waiting many months for a PE'ed PTF to get a fix. Well, maybe not ugliest. The ugliest RESTORE situation I've seen involved an incorrectly packaged PTF that made doing a RESTORE was impossible (if you wanted a usable load module). But that just meant I reverted to your technique - wait for a fix. Pat O'Keefe -- 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: Find the computer error
On Thu, 16 Jul 2009 06:42:59 -0600, Steve Comstock st...@trainersfriend.com wrote: ... Twenty Three Quadrillion? Looks like Twenty Three Thousand Billion to me. Well, my understanding is that American English uses terms a little differently than the-rest-of-the-world English. ... It's those tricky English prefixes bi, tri, quad, etc. :-) Pat O'Keefe -- 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: NVAS error explanation
On Wed, 15 Jul 2009 10:28:42 -0500, Chase, John jch...@ussco.com wrote: ... The application is not found (not started, wrong spelling or not reachable - ie. over cross domain or like) Why would that be true only for me? I'm on the same network, in the same building, same list of applications, same terminal emulator, etc. etc. etc. . ... I know nothing about NVAS, but based on TPX and Supersession, ... How about something related to your LUname or logmode? Does your LUname come out of a different pool from everybody else and mess up some kind of real LUname / virtual terminal LUname mapping? (Virtual terminal may not be a NVAS term. I hope it is understandable.) Do you log on with a particular logmode name that isn't being handled correctly? There is also the very unlikely possibility that you are always user n+1 trying to use a pool of n LUs, but you would have to be incredably unlucky for that to always be the case. :-) Pat O'Keefe -- 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: Complexity (was Re: Convert DB2 on z/OS to Oracle on z/Linux?)
On Sun, 12 Jul 2009 13:20:59 -0500, Chris Craddock crashlu...@gmail.com wrote: ... Realistically no company in its right mind is going to invest development and maintenance effort in something they can buy and have somebody else on the hook for maintaining it. That's what all the buzz about *-as-a-service is about. ... ... Folks hate to hear me say it, but just about everything we know about IT today is wrong. We're never going back to the home grown development cottage industry and sooner or later the in-house IT function is going to go the way of the dodo too. ... That is probably the inevitable future, but the time frame is not at all clear, and the ecomonic break-even line between do it in-house and buy it changes over time. When you pass development and maintenance over to an outside vendor you also pass off control. The vendor's service had better be a very good match to the business needs or the economic advantage disappears. Pat O'Keefe -- 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: Any product to undelete file?
On Fri, 10 Jul 2009 09:05:39 -0400, Bill Fairchild bi...@mainstar.com wrote: Of course you can with EXCP or XDAP, neither of which requires authorizatoin. ... Anyone who owns a data set that he doesn't want someone else to be able to read after he deletes it needs to cause it to be erased when deleted ... Ok. So my Migrate on Delete needs to optionally be Migrate and Shred on Delete. I still think this recovery idea would be a good thing to have built into HSM (or some such) and a very bad thing to have as a stand- alone utility. And if the is a Migrate on Delete there absolutely needs to be a Delete (and Shred) without Migrate for those cases where for legal or contractual reasons the data must be deleted without any chance of recovery. Pat O'Keefe -- 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: IBM error messages getting worse?
On Thu, 9 Jul 2009 08:21:22 -0400, David Andrews d...@lists.duda.com wrote: On Wed, 2009-07-08 at 17:33 -0400, John Mattson wrote: Am I just getting more cranky as I age, or are IBM messages getting ever more obtuse? I wouldn't say more obtuse. Remember this chestnut? IEB817I MEMBER NAME NOT FOUND IN NM DIRECTORY. STOWED WITH TTR. which meant: I added a new member to your PDS. I think you make a very good point. There have always been absolutely inscrutable MVS messages and there will probably be new ones. But there are many prefectly clear ones, too, and there is that message id you can look up, run searches on, submit RCFs on (if those still exist ... and are read), or even open PMRs on if they are so bad as to be considered a defect. I don't think it is getting worse. Pat O'Keefe -- 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: Any product to undelete file?
On Thu, 9 Jul 2009 15:22:24 +0200, Vernooij, CP - SPLXM kees.vern...@klm.com wrote: ... A feature like a Recycle Bin could be useful without introducing too much overhead. If a dataset is deleted, just keep it, but hide it by administrating it in a Recycle Bin per volume. HSM could periodically delete data from the Recycle based on age or size of the Recycle Bin. The user could then be given an Undelete function, because the data is still there. This would also solve the problem that you can restore last night's backup, but still have to redo today's updates. ... This would also not have the security issues raised earlier in this thread. Maybe this could be implemented as an Migrate on delete sort of function (with some tricky renaming so that the dataset it is both deleted from the catalog and recoverable) so that it could be a HRECOVERed. That would have additional pain that the delete would happen right away but the recover would have to wait for normal migration and recovery processing to complete. Unintended deletion would still be painful, but not terminal. Pat O'Keefe -- 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: Preview: z/VM V6.1; IBM Declares New Architecture Level Set (ALS)
On Thu, 9 Jul 2009 09:15:02 -0500, Mark Zelden mark.zel...@zurichna.com wrote: ... ... we can expect some future level of zOS to require the new ALS. ... Sometimes, the new ALS means a renaming of the OS. But again, that has always been a marketing decision, not a technical one. ... IBM doesn't need to make a new version, but that might be the best time to release a new version. A version upgrades often mean price increases. Those are a little more palatable / salable to upper management if the new version is the first in a line of releases that can make use off new hardware features. Pat O'Keefe -- 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: Any product to undelete file?
On Thu, 9 Jul 2009 13:10:15 -0700, shai hess shai.h...@gmail.com wrote: ... All your questions easily can be handle. ... The one part you cannot handle is that, in my opinion, this kind of function should be implemented by IBM as part of HSM. One thing that absolutely should NOT be part of this kind of tool would be the ability to allocate a dataset on top of the old deleted dataset and access the data. This would be a huge security hole (as others have said in this thread). Pat O'Keefe -- 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: Anynet
On Tue, 7 Jul 2009 16:03:10 -0500, Ward, Mike S mw...@ssfcu.org wrote: Hello all, is anynet incorporated into z/os vtam like enterprise extender is? Or is there any way to communicate with an SNA Gateway(Communications Server) from z/os 1.7 using the enterprise extender functions? ANYNET is no longer supposed (as of 1.8 I think). I'm not sure what you mean by SNA Gateway(Communications Server). There are a number of products called SNA Gateway. They only one(s) I know of that are Communication Servers are the IBM one for AIX and maybe for AS/400. I think both AIX and AS/400 support EE, but I'm not sure what the software is called. Do you maybe mean the microsoft SNA gateway? I think it supports EE. So do Cisco routers through the Cisco SNASwitch. SNASw and DLSw can run in the same router with a virtual LAN between them. That is sort of the standard was of supporting DLSW-connected SNA devices. If your remote routers are powerful enough you can run SNASw out at the remote sites and benefit from HPR APPN all the way out to those devices, but I think it is more common to replace the FEP with a DLSw/SNASw router. Pat O'Keefe -- 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: anynet SNA over TCPIP
On Sat, 27 Jun 2009 06:44:30 -0500, Chris Mason chrisma...@belgacom.net wrote: ... [3] In principle this applies to APPN nodes also and could be used to argue that, just because a LEN or APPN node does not have a visible PU, it still has a PU and that the PU could be used to characterise the type 2.1 node! Nobody has ever used that argument to refute my insistence that there is no such animal as a PU 2.1 and it may be that you are the only person who can see the irony here - or indeed follow what I am talking about! ... Well, I no longer have access to access to the SNA FAPs and can't find the equivalent APPN architecture definition so I don't know if there is any difference between the PUCP in a node type 2 and the PUCP in a node type 2.1. But in looking at a display of a PU_T2.1 I see characteristics of the linkstation and maybe the node, but nothing I would associate with the PU. I think you might still be safe saying there is no such thing as a PU_T2.1. :-) Pat O'Keefe -- 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: Weird Formatting of posts
On Thu, 25 Jun 2009 16:07:33 -0500, Bill Godfrey yak36...@yahoo.com wrote: This problem was discussed, but not resolved, in a thread named width of postings July 18-19 2007. In that thread, in one of my posts, I suggested it might be a problem with the HTML built by the Listserv program... I still think the problem is in Listserv. ... Well, we have one of those weird ones in today's archive: Ed Gould's posting. (As usual, watch the wrap.) http://bama.ua.edu/cgi-bin/wa?A2=ind0906L=ibm- mainT=0O=DF=S=P=183214 With IBM-Main options medium text and monospaced font, and using IE6.0 with who-knows-what options I see the repeated words and, well, this is a lot weider than I thought. If I vary the width of my browser window so that the lines are reformated the problem goes away and will not reappear regardless of my display width. But if I exit and rebrowse the posting, the duplication is back. This evening I'll check using Firefox. Pat O'Keefe -- 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: anynet SNA over TCPIP
Just one small comment on one very small excerpt: On Fri, 26 Jun 2009 07:07:15 -0500, Chris Mason chrisma...@belgacom.net wrote: ... Pat, there's a hole in your education! ... Chris, This definitely not the first time you've discovered that! :-) Nor the first time I've displayed that on this list (and others). ... AnyNet SNA over IP constituted a Low Entry Networking (LEN) link just like any other LEN link, ... Actually, I didn't have any education (or training) on AnyNet. I just picked up some manuals and started cobbling together something that would allow a CICS to talk with a TCP62 application on some remote device. Perhaps if the that remote device had implemented an SSCP I would have seen beyond the APPL-APPL connection. Pat O'Keefe -- 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: Weird Formatting of posts
On Thu, 25 Jun 2009 09:34:32 -0500, Mark Zelden mark.zel...@zurichna.com wrote: ... The same thing happens to me when I use IE6. I proved to myself that my issue was a browser problem by slowly resizing the browser window and watching the words reflow. As the words reflow, the duplicate words disappear. Hmmm... I don't see a problem in IE6. ... I see this with IE6, but in only a very few posts, and usually in multiple posts from the same person. I think it must be a combination of what created it and what is used to view it. I say this recently (last week?) in a couple postings. If I can find them I'll see what they look like with Firefox 3.something. (But the chances of my finding those postings is pretty remote.) Pat O'Keefe -- 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: question about searching datasets for ip addresses
On Thu, 25 Jun 2009 15:19:58 -0400, Bob Rutledge deerh...@ix.netcom.com wrote: ... You could be in for a surprise later in life... c:\brping 100.020.002.020 Pinging 100.16.2.16 with 32 bytes of data: 0nn means octal nn. ... On z/OS (and I assume other IBM mainframe operating systems) a leading zero signifies a leading zero, not a switch to octal. We include leading zeroes in some IP addresses because it simplifies sorting. It will be simpler with IPv6. The numbers are in hex without need for any format indicator. Pat O'Keefe -- 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: anynet SNA over TCPIP
On Thu, 25 Jun 2009 14:53:46 -0500, Chris Mason chrisma...@belgacom.net wrote: ... Regrettably there is no replacement for the brilliant AnyNet Sockets over SNA function. While true, there isn't much need for it, either. It's rare to find 2 devices with SNA connectivity that don't have IP connectivity. ... There are a number of platforms where you can install Enterprise Extender precisely to replace AnyNet SNA over IP. ... It's worth noting a significant difference between the 2 configs. AnyNet SNA over IP (TCP62, etc.) made an appl-to-appl connection. EE makes an APPN node-to-node connection. The application does not care, of course, but there is more to setting up the connection if the nodes are not already APPN nodes. On the other hand, setting up a connection with another node is trivial once everything in the SNA world is using APPN. And, of course, the EE connection can automatically handle any other SNA sessions you care to add once you have it in place ... Mention of TCP62 raises an alarm. ... Wasn't TCP62 just the name of the non-VTAM AnyNet SNA over IP LU6.2 component? The manual may have been terrible, but the client implementation had to be written to some spec, and TCP62 was that spec (I assumed). Was anything other than than LU6.2 support implemented using AnyNet SNA over IP? I know PComm supported AnyNet as a protocol, but I thought it used APPC3270. (I don't have a clue what the PComm 5250 AnyNet support used.) Pat O'Keefe -- 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: question about searching datasets for ip addresses
On Thu, 25 Jun 2009 16:36:28 -0400, Bob Rutledge deerh...@ix.netcom.com wrote: Patrick O'Keefe wrote: ... On z/OS (and I assume other IBM mainframe operating systems) a leading zero signifies a leading zero, not a switch to octal. We include leading zeroes in some IP addresses because it simplifies sorting. READY nslookup 10.20.100.4 EZB3170I Server: ... EZB3172I Address: ... EZB3170I Name:host... EZB3172I Address: 10.20.100.4 READY nslookup 10.020.100.4 EZB3170I Server: ... EZB3172I Address: ... EZB3010I *** ... can't find 10.020.100.4: Non-existent domain ... I forgot that NSLOOKUP uses its own resolver. It implements different rules than gethostbyaddr(). Try a ping or tracerte or any application that uses gethostbyaddr() on z/OS (at least 1.8) and you get the same results with or without leading zeroes. NSLOOKUP and DIG use their own name resolution schemes. Interestingly, the Unix command host (no TSO equivalent in 1.8) that I thought used gethostbyaddr() seems to have the octal junk support. (Why octal is still supported in anything is beyond me.) Pat O'Keefe Pat O'Keefe -- 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: question about searching datasets for ip addresses
On Thu, 25 Jun 2009 14:25:19 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: ... It will be simpler with IPv6. The numbers are in hex without need for any format indicator. I think IPv6 addresses will actually be more difficult to scan for. You can optionally specify :: (two colons) anywhere in the address to denote any number of zeros, leading zeros after a colon are optional, and you are often allowed to specify an IPv4 formatted address at the extreme right side of the address to describe an IP address that happens to be in the IPv4 space. It's highly unlikely that everyone will code any two IPv6 addresses exactly alike! ... Well, note that I did put simpler in quotes. I probably should also have added a smiley. It's not going to get easier; just different - very, very different. Pat O'Keefe -- 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
Access to IBM-Main archives (was: SHARE Requirements and IBM)
On Wed, 24 Jun 2009 11:15:22 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: ... And, sometimes they're rejected even *after* they're implemented! :-D http://bama.ua.edu/cgi-bin/wa?A2=ind0407L=ibm-main- archivesP=R2529I=1X=- Odd. In following Ed's link (that was not wrapped in the original) I get a login popup saying Sorry, you are not authorized to browse the archives of the IBM-MAIN-ARCHIVES list from the email address (patrick.oke...@wamu.net) you entered in the login screen. Entering the only IBM-Main id and password I have results in a repeat of the same popup. I am still able to search the archives and read the resulting found postings, but I don't know what Ed searched on so don't know if I found the entry he was pointing to. A hint (if a hint were needed) that I'm not part of the in crowd? Pat O'Keefe -- 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: TCP SMTP
On Thu, 18 Jun 2009 09:43:11 -0700, Ulrich Krueger u...@pacbell.net wrote: ... What is your setting of RESOLVERUSAGE? I believe the value of this parameter needs to be changed if you want to use IPMAILERNAME xxx.com ALL|UNKNOWN vs IPMAILERADDRESS ... Yes. If you are going to use IPMAILERNAME you must specify RESOLVERUSAGE YES. Otherwise the SNMP daemon will not try to resolve the name. But you may not want to do this. In my previous shop (as set up by me) and my current shop (as set up by others) we used IPMAILERADDRESS and (once the parm became available) RESOLVERUSAGE NO because of problems introduced by RESOLVERUSAGE YES. We are reeducating ourselves on the topic because we could not remember what those problems were. As I read it you may have trouble even if the name is resolved. If you enable the SMTP daemon's name resolution it will not only resolve names, it will also attempt to get mail exchange (MX) records from the name server and try to send emails to mail transfer agent (MTA) closest to the recipient rather than sending the emails to the mailer you defined. If either end has firewalls or access lists in place they very likely will prevent your use of those remote MTAs. There does not seem to be any way to tell the z/OS SMTP daemon to resolve the mail of your defined mailer and use it for all outbound mail. IBM is providing a new SMTP daemon (with z/OS 1.11?). Hopefully they will have addressed this problem by then. Pat O'Keefe -- 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: REXX HI vs HE
On Tue, 16 Jun 2009 18:23:47 -0400, Tony Harminc tz...@attglobal.net wrote: ... HI and friends are conditions in the REXX interpreter, that are checked at each instruction (REXX clause, I assume that means). It's just a matter of turning the flag on using the IRXIC service, and the interpreter will notice it some time real soon. ... Thanks. Good information. My original question can be ignored. IBM finally reproduced the condition I ran into. There is definitely not any global condition influencing REXX behavior; it was a bug in the exec. (I do not understand IBM's initial difficulty reproducing the problem but I've decided not to inquire.) Pat O'Keefe -- 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: IBM Software Secure Support via USA Citizens
On Wed, 17 Jun 2009 08:59:41 -0400, Mary Anne Matyaz maryanne4...@gmail.com wrote: ...It's simply a way for US Govt accounts to open problems and speak to a US citizen. It's surprising how much is not in the US, and right now if a Govt customer opens a PMR, and happens to get a non-US citizen, they have to close the pmr. ... ... because we just can't trust those Canadians, etc. not to take advantage of a US Government's 0C4. If those are the US Government's rules then IBM would be foolish not to set up such accounts, but the concept behind the rule makes no sense. It would make more sense (but would be impossible to implement) a rule that requires competency rather than US citizenship. Pat O'Keefe -- 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: REXX HI vs HE
On Tue, 16 Jun 2009 17:19:01 +1000, Wayne Bickerdike wayn...@gmail.com wrote: I don't know if compiled REXX works differently from interpretive. I don't think the behavior is any different. I just mentioned that to indicate that I couldn't see what the exec was doing and that my diagnostic options were limited. There is a possibility that you are executing an ISPF service or something that isn't interruptible. That could be the case in the past when I ran into this under TSO, but the most recent case is an exec running in NetView - no ISPF. I know that I might have to hit ATTN a few times and enter the HI command to break a looping or long running REXX. I'm not sure how the equivalent process works in NetView. EXECs run as interruptable long running commands in sort of a pseudo- subtask. NetView has a read up while the exec is running and (I guess) issues an HI if the user enters a CANCEL or RESET. But I don't know what causes the REXX interpreter to give up control so that the CANCEL can be read and the HI presented. I don't know if I mentioned it but the CANCEL works fine for NetView lvl 2 but fails for me. Can you execute with TRACE? ... Nope. ... Is there a call to a REXX external routine that you can substitute your own code and use it to stop your REXX? Not that I know of. Pat O'Keefe -- 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
REXX HI vs HE
What is the supposed difference between HI and HE to REXX? I have never been able to terminate an errant exec under TSO with an HI (even though the response to ATTN tells me I can). Is there anything that would make HI work in some installations but not others? I specifically said in some installations rather than for some exes because I've got a problem with an IBM-supplied NetView exec that is misbehaving in our shop. An internally issued HI is not stopping execution of the exec for me but, of course, works fine for IBM. (It's compiled REXX so I can't see what is going on.) This is a hare-brained idea, but I wonder if there could be something in my shop (my last 2 shops) that would prevent HI from working. BTW, I tried searching the archives, but a search for REXX plus HI or HE finds a few too many irrelevant hits. :-) Thanks. Pat O'Keefe -- 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
