Re: SDSDF Command Line
Lindy Mayfield wrote: I any case, does anyone know how to tell SDSF to put the command line on top? I've been through all the options and the docs with no luck so far. Command line placement is an ISPF setting. You won't normally find it discussed in the documentation for individual ISPF applications you might run. To change your ISPF settings for any ISPF application, you issue the SETTINGS command while using the application. The resulting panel allows you to change various options -- including the placement of the command line. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSDF Command Line
I any case, does anyone know how to tell SDSF to put the command line on top? I've been through all the options and the docs with no luck so far. When you are on SDSF panel, just invoke SETTINGS from there and unselect Command line at bottom Regards, Marija -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBMLink, again
On Fri, 28 Mar 2008 12:12:03 -0400, Tony Harminc wrote: On 27/03/2008, Bruce Hewson wrote: I would assume, like on some web screens we use here, that the text input fields are not transparent. By that I mean the characters entered are treated as HTTP control characters, or something like that. This sort of behaviour on a web page is a great place to look for security holes like code injection. Maybe that would help IBM see the light. IBM says: We are aware of this issue and the development team is working on a fix. The problem is with less than and greater than symbols being interpreted as HTML tags. In most cases, using the Printable version link at the bottom of the page is the workaround. However, there have been some ... A truly naive blunder, particularly given that they were able to get it right on one page but not on another from the same source. (and the Printable version is naive in its own way: I looked at the raw HTML and it uses nbsp; pervasively, pointlessly between PRE and /PRE tags. And I can imagine some printers considering NBSP (ASCII 0xA0) not to be very Printable.) I wonder what would happen if someone were to take an open-source 3270 emulator (or browser) and hack it to transmit 3270 command codes in the POST data? One might thus create a page that would display correctly in a browser but fail with TERMINAL ERROR on a 3270. There's a thread ongoing in MVS-OE on CGI security. The first principle is: don't trust data received over the network. The second is: don't trust Javascript validation on the client side. Always remember that your potential adversary controls the client. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSDF Command Line
On Sat, 29 Mar 2008 17:52:39 +0100, Marija Perkovic wrote: I any case, does anyone know how to tell SDSF to put the command line on top? I've been through all the options and the docs with no luck so far. When you are on SDSF panel, just invoke SETTINGS from there and unselect Command line at bottom It ain't that easy. I've selected / Command line at bottom (my choice; don't argue with me -- I'm not a very good typist and I believe it helps to have my fingers in my peripheral vision as I view the command line). Yet the command line jumps distractingly between bottom and top depending on what SDSF option I select. I think some just don't honor the setting. And (IIRC; I can't reproduce this right now) it sometimes switches on certain operations within a panel, perhaps when a message is issued. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSDF Command Line
Paul Gilmartin wrote: It ain't that easy. I've selected / Command line at bottom (my choice; don't argue with me -- I'm not a very good typist and I believe it helps to have my fingers in my peripheral vision as I view the command line). Yet the command line jumps distractingly between bottom and top depending on what SDSF option I select. I think some just don't honor the setting. And (IIRC; I can't reproduce this right now) it sometimes switches on certain operations within a panel, perhaps when a message is issued. Panels must be defined correctly in order to allow ISPF to properly manage command line placement. Or, put another way, subtle errors in panel definitions can cause ISPF to *not* manage command line placement. Given that 90% of ISPF users prefer top-placed command lines, it's not surprising that this clumsy SDSF behavior hasn't been reported or fixed -- one of many irritating usability issues with that product. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBMLink, again
On 29/03/2008, Paul Gilmartin [EMAIL PROTECTED] wrote: There's a thread ongoing in MVS-OE on CGI security. The first principle is: don't trust data received over the network. The second is: don't trust Javascript validation on the client side. Always remember that your potential adversary controls the client. There's a recent thread on Bruce Schneier's blog on The Security Mindset. http://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html Somehow it seems that people either think this way or they don't. That anyone in 2008 could consider for a moment doing validation of anything important on the client side is astonishing. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF System Logger - limitations of MANx
I have been following this thread with some interest. The one aspect I have not seen mentioned has been what constitutes too high of volume of SMF data? I'll admit my shop is small but our production LPAR was switching SMF in the range of 95 to 105 times a day. The other LPARs were behaving switching 5 to 15 times a day. The source of the problem was that all of the MANx data sets had the same allocation - 100 cylinders -, which had been sufficient for many years. Anyway, I reallocated the MANx data sets for the production LPAR to 750 cylinders; and, I modified the offload PROC as well. Now, the production LPAR only switches 14 or 15 times a day. With this in mind, what is too high of a volume for the MANx data sets to handle given the size of the MANx data sets and rate of switching? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
