Re: Java Demos (02/02)
For more Java demos along with their evivalent forms written in HLASM mainframe assembler, HLA Intel assembler, C++, and COBOL visit: www.mfatc.org Also you could choose to classify the z390 portable assembler and emulator written entirely in J2SE open source Java as a demo. All the classes are packaged into a single z390.jar which supports a Swing GUI interface, macro assembler, linker, and emulator that runs on Windows Vista, XP, or Linux. To download and install on Windows using InstallShield visit here: www.z390.org There are hundreds of Demo regression test programs as defined here: http://z390.sourceforge.net/z390_Regression_Tests.htm More recently there is an ongoing z390 Mainframe Assembler Coding Contest (ZMFACC) which now includes a number of intereseting Demo solutions submitted in a portable source program form which can now be run run on z390 using J2SE Java plus Hercules 3.8 MVS, z/OS, z/VM with CMS, and VSE. Some of the Demos include some intersting things like swapping 2 fields in memory with 2 instructions (no not 3 XC), hash table lookup in 5 instructions, calculating standard deviation to 34 decimal places, calculating Pi to 34 decimal places, calculating recursive Ackerman function values. Check the contest Demos out here: http://z390.sourceforge.net/z390_Mainframe_Assemble_Coding_Contest.htm Don Higgins [EMAIL PROTECTED] -- 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: IBM Cuts Employee Salaries
HERE! HERE! Let's do away with those golden parachutes as well Ron Wells wrote: cutting salaries ... u. since I know IBM has lots of fatand on the top end as well like many other firms ... I would also suggest bonus's and the mill. dollar salaries be cut as well money back in the company to expandmake more job's ... OK I get that ... but top guys not taking a hit as well I have a problem with it -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- 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 -- 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: Trouble opening specific volumes with OPEN TYPE=J
In [EMAIL PROTECTED], on 01/14/2008 at 11:34 AM, Gerhard Postpischil [EMAIL PROTECTED] said: I don't have access to my docs right now, otherwise I would have specified the bit, but JFCVSL sounds correct. It needs to be set on any OPEN when there is a changed data set name or serial. I seem to recall setting it for a changed member name also. I'm pretty sure that it's not required for a changed member. My recollection is that it's strictly for a changed volser. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Trouble opening specific volumes with OPEN TYPE=J
In [EMAIL PROTECTED], on 01/14/2008 at 01:09 PM, Tom Quarendon [EMAIL PROTECTED] said: I'm trying to write some code that performs random access I/O on a multi volume dataset using a technique similar to that described in chapter 7 of DFSMSdfp Advanced Services, and am having mixed results. Probably because you're using the wrong tool. The code all works just fine, so long as the dataset I'm dealing with exists already, or is allocated in a previous step of my job using, for example, an EXEC PGM=IEFBR14 step. If I try and allocate the dataset in the step that actually performs the I/O as a DISP=(NEW,CATLG) or DISP=(NEW,DELTE) dataset, then when I try and open specific volumes by changing the JFCBVLSQ field in the JFCB prior to performing an OPEN TYPE=J, then I don't get the right volume. What do you mean by that? The OPENJ does not[1] change the TIOT, so you're still pointing to the same UCB's as before. Since MVS no longer supports mountable DASD, that means that you can only succeed in changing a volser that you already have allocated. That means that you don't need an RDJFCB at all, just a correct calculation of the extent number. It seems to me like I always get the first volume. That's expected if you always set M to 0. [1] Well, it may do a DYNALLOC under the covers, but that's just for ENQ housekeeping. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
What happened to resumable instructions?
Long ago in a galaxy far away, IBM introduced the concept of resumeable instructions; an interrupt could occur in the middle of the instruction execution and the instruction would continue properly after a normal dispatch. It appears that CLCL and MVCL were not only the first such long instructions but also the last. Subsequent long instructions have required testing the condition code to see whether the instruction had been interrupted in media res. Superficially that seems like extraneous overhead. Can anybody cast any light on why IBM went that way? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: What happened to resumable instructions?
On Sun, 3 Feb 2008 08:21:34 -0500, Shmuel Metz (Seymour J.) wrote: Long ago in a galaxy far away, IBM introduced the concept of resumeable instructions; an interrupt could occur in the middle of the instruction execution and the instruction would continue properly after a normal dispatch. It appears that CLCL and MVCL were not only the first such long instructions but also the last. Subsequent long instructions have required testing the condition code to see whether the instruction had been interrupted in media res. Superficially that seems like extraneous overhead. Can anybody cast any light on why IBM went that way? What can I think of? o Special treatment in microcode for saving the PSW on interrupt? Only the resumable instructions need to store the PSW before execution. o Special branch prediction for instruction pipelining. This might be simplified by the manifest BC after repeatable instructions. But I'd expect any interrupt to void the pipeline regardless. And I believe it was stated on this list that BCT(R) is always predicted taken; all other conditional branches not taken. This might seem an adverse convention for a BC after a repeatable instruction. But aren't both cans of worms already opened by CLCL and MVCS, irreversibly unless those two instructions are relegated to millicode and deprecated in favor of nonresumable instructions (CLCG? MVCG?). Are millicode sequences interruptable? o Page faults? How are page faults handled for resumable instructions? Is a fault generated for any page in the range of either operand, with the OS attempting to stage both, or does a fault possibly for each resumption. -- 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: What happened to resumable instructions?
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Paul Gilmartin) writes: o Page faults? How are page faults handled for resumable instructions? Is a fault generated for any page in the range of either operand, with the OS attempting to stage both, or does a fault possibly for each resumption. the resumable instructions were storage-to-storage operations with address and length specified in registers for both source and destination. requirement was that the registers be appropriately updated as the instruction proceeded ... so that on any interrupt, all registers will have been appropriately updated (and therefor on restart, the instruction would resume from the appropriate position). the problem wouldn't so much the psw address being correct on the interrupt ... the issue was that all registers actually reflecting the correct values (i.e. working copies of the values weren't squirreled away in other hardware location). prior to mvcl/clcl ... instructions would pretest start and end location for both (2k) storage protection and 4k page fault. with mvcl/clcl, the testing had to be done incrementally for every byte processed (although there were later optimizations that would do it in larger blocks, and then fall back to per byte mode ... for any residual). highly pipelined machines gets into lots of issues with what are the current (visable) register contents at any point in time (lots of different parallel executing circuits with possibly their own register values). newer machines also have extensive hardware ras with status checkpoint and instruction retry (to mask various kinds of transient hardware glitches) ... instructions that execute incrementally aggrevate status checkpointing overhead (and instruction retry logic). i actually ran into early problem with 370/125 implementation on vm370. at vm370 boot (on real machine), it would load maximum values into mvcl (initialized to clear storage) and kick it off, it would zero all of real storage ... interrupting when it hit the end of real storage. early 370/125 microcode had a bug where it was still pretesting origin end for mvcl/clcl and aborting the instruction before starting ... which to vm370 made it appear like there was no real storage. vm370 was originally targeted at supporting 256kbyte machines ... prior to announce of 370/125 ... and was never announced for 370/125. at this point, a customer had requested assistance in getting vm370 running on 370/125. while vm370 had non-swappable kernel support ... the amount of fixed kernel had somewhat bloated between the original announce ... and this point ... which also significantly aggrevated vm370 operation in 256k real storage. recent post referring to having done lots of work in 60s as undergraduate on cp67 ... much of which got picked up and shipped in the product: http://www.garlic.com/~lynn/2008c.html#65 No Glory for the PDP-15 one of the other things that i had done for cp67 in the 60s was making portions of the kernel pageable ... which wasn't shipped in cp67 product ... but was picked up for vm370 product. however, since the initial release ... things had gotten lax between what was in the fixed kernel and what was in the pageable kernel. by the time of the customer vm370 370/125 request to the science center http://www.garlic.com/~lynn/subtopic.html#545tech I had moved much of the cp67 work (that had been dropped in the cp67 to vm370 morph) as well as adding lots of new stuff ... and was supplying highly modified vm370 systems to large number of internal datacenters. some old email references: http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 and part of getting vm370 up and running on 370/125 also involved going thru lots of kernel infrastructure and significantly reducing the fixed storage footprint for running in 256kbyte real storage machine. -- 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: What happened to resumable instructions?
On Sun, 3 Feb 2008 08:21:34 -0500 Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: :Long ago in a galaxy far away, IBM introduced the concept of resumeable :instructions; an interrupt could occur in the middle of the instruction :execution and the instruction would continue properly after a normal :dispatch. It appears that CLCL and MVCL were not only the first such long :instructions but also the last. Subsequent long instructions have required :testing the condition code to see whether the instruction had been :interrupted in media res. Superficially that seems like extraneous :overhead. Can anybody cast any light on why IBM went that way? I think it is because these storage to storage operations can take so long to execute, so long that the CPU would assume a problem and go into a check-stop. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: IND$FILE
In [EMAIL PROTECTED], on 02/01/2008 at 10:24 AM, Bob Shannon [EMAIL PROTECTED] said: I have searched high and low for documentation on this relic. Can anyone help? You may be able to get information from vendors who have reversed engineered it, but the only IBM documentation on IND$FILE was a skimpy manual that contained absolutely no useful information. If you have an old 3270PC lying around, maybe it's documented there. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: IND$FILE
In [EMAIL PROTECTED], on 02/02/2008 at 03:59 PM, Pinnacle [EMAIL PROTECTED] said: IND$FILE is slower at most installations because VTAM is not optimized for throughput, but instead for robustness of delivery. Why do you say that? Don't confuse the options appropriate for a basic LU2 session with the limitations of VTAM. If you want to examine VTAM throughput issues, NJE is a better application to look at, and even there you're seeing, e.g., BDT, JES2, JES3, RSCS, performance as much as VTAM performance. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: IPCS NAMETOKN Command
In [EMAIL PROTECTED], on 02/01/2008 at 05:53 PM, Wayne Driscoll [EMAIL PROTECTED] said: However, the contents of the rexx variable is unformatted data, so how do I utilize the data? You can use, e.g., left(), right(), substr() to chop up the value, or use parse. REXX has transfer functions, e.g., c2d(), c2x(), d2c(), d2x(), x2b(), x2c(), x2d(), for converting numbers between various bases. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: IPCS NAMETOKN Command
In [EMAIL PROTECTED], on 02/02/2008 at 08:58 AM, Robert Wright [EMAIL PROTECTED] said: I'll defer to many who contribute to IBM-MAIN and use REXX more than I do to help with the conversion. We'll add something like a FORMATTED (always as hexadecimal digits) versus UNFORMATTED (current default) option to the wish list for improving the NAMETOKN subcommand. From the perspective of a long time REXX user, the current default would be preferable even without considering compatibility considerations. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Query concerning USS uids and home directories.
In [EMAIL PROTECTED], on 04/27/2005 at 06:54 AM, Andy Robertson [EMAIL PROTECTED] said: 1) Suppose you have two users; USERA defined with uid 200 and home directory /home/usera USERB defined with uid 200 (same as USAEA) and home directory /home/userb Ouch! Well, it's not my dog. 2) If USERA starts to do USS ITYM Unix wor4k; USS is something quite different. will his home directory always be /u/usera? Yes. Or can it switch to /u/userb under some circumstances?? If he submits a job as a proxy for USERB then it will run with USSERB's home directory. However we would like to understand whether the home directory is always derived directly from a RACF userid Yes. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Query concerning USS uids and home directories.
2) If USERA starts to do USS ITYM Unix wor4k; USS is something quite different. Can't you just drop it? - Too busy driving to stop for gas! -- 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: Migration from Mainframe to othre platforms - the othe bell?
Go license ORACLE on the hundreds of servers you might need to replace a z9 with two IFLs running z/VM and as many Linux guests as you care to put on it. The expense management is comparing is one z9 versus one little server. Once they start multiplying the number of little servers they need to run the same workload they spend more. But any one little server costs less. They also fail to account for the floor space, the cooling, the electricity, and personnel it takes to manage all of those servers. With eyes focused on just some of the costs it sure looks like they are going to save money. And since the little costs are spread all over the place, the bean counters do not accumulate the sum of all costs and prove they are spending more. So everyone is happy. Ignorance is bliss. If you are not running Linux on z./VM, or don't have licensed-by-number of processor software, and fit the bill to be a teeny weeny shop, then sure, a z9 is expensive. It comes bloated with reliability, serviceability, and availability. The mainframe people know how to write fault tolerant applications. Teeny companies do not need that. They are content with outages and rebooting servers throughout the day that froze for unkown reasons that will never be debugged. It is okay to reboot your desktop, your teeny servers, but for some reason not the mainframe. You get what you pay for. Those CEOs and CIOs jumping to just get off the mainframe to save a fictitious dollar usually bail out with stock options before it all crumbles. On Thu, 31 Jan 2008 11:58:25 -0200, Mautalen Juan Guillermo [EMAIL PROTECTED] wrote: Hi, I am full of reports, sent to Management, about completely succesfull conversions from the old and expensive IBM Mainframe to other platforms. And, as you may know, the most important argument is that the Mainframe is very expensive and the same level of processing, with the same degree of thrust, can be achieved in other platforms with much less money. Of course, i dont beleive this, or at least i dont think things to be so simple. So, i want to collect some information to support the Mainframe side. Are there somewhere on the web, as a counterpart of all the marketing flood about getting rid of the Mainframe, stories, reports or analysis of : - Conversions (or Consolidations) from other platforms into Mainframes. - Stories of unsuccessful migrations from Mainframe to other platforms. - Serious and independant cost analysis between different solutions. - Serious and independant studies comparing the security level of the different platforms. Thanks in advance for your help, Juan G. Mautalen El contenido del presente mensaje y sus anexos es privado, confidencial y de exclusivo uso para el titular de la direccion de correo electronico a quien esta dirigido. Puede contener informacion privilegiada o amparada por el secreto profesional o por disposiciones legales y/o reglamentarias vigentes. Cualquier modificacion, retransmision, diseminacion o divulgacion de su informacion se encuentra expresamente prohibida y su uso inadecuado puede derivar en responsabilidad civil para el usuario o configurar los delitos previstos en los articulos 153 a 157 del Codigo Penal. Si no fuere uno de los destinatarios consignados o lo hubiere recibido por error, Ud. NO ESTA AUTORIZADO a utilizar total o parcialmente, copiar, enviar, revelar, imprimir, divulgar de manera alguna el contenido del presente mensaje o el de sus adjuntos. En consecuencia, tenga a bien comunicarselo inmediatamente al emisor y ELIMINARLO. ANSES no aceptara responsabilidad alguna por errores u omisiones emergentes del presente mensaje o sus adjuntos, ni garantiza la seguridad, exactitud u oportunidad de lo transmitido por este medio debido a que el mismo puede ser objeto de intercepcion, modificacion, retraso, perdida, o bien de contener virus informaticos u otras anomalias. Asimismo, las opiniones expresadas en este mensaje son propias del remitente y no representan la opinion o politicas de ANSES y/o de ningun empleado y/o funcionario de la organizacion. Por ende, ANSES no asumira -en ningun caso- responsabilidad alguna frente al destinatario y/o terceros en virtud de dichas comunicaciones y ademas, no sera responsable frente a los usuarios por la correspondencia o los mensajes de correo electronico enviados por terceros u otras personas distintas a ANSES, ya sea que estos hubieren o no solicitado el envio de tales mensajes. ANSES se reserva el derecho de bloquear el acceso o remover en forma parcial o total todo mensaje y sus adjuntos que a su criterio pudiere resultar abusivo, difamatorio, obsceno, fraudulento, artificioso, enganoso, ofensivo o violatorio a los terminos de la presente. PD:Tildes omitidas intencionalmente. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the
Re: original JCL via SAPI
I'm just now looking at the SDSF REXX Function available with z/OS 1.9 and it can let your REXX program get the input JCL. For all those who have been wanting to programmatically get the original JCL, UPGRADE! On Wed, 11 Apr 2007 11:10:46 +0200, Miklos Szigetvari [EMAIL PROTECTED] wrote: Hi I would like to get back the original JCL (as SDSF SJ does) via SAPI interface. -- Miklos Szigetvari Development Team ISIS Information Systems Gmbh tel: (+43) 2236 27551 570 Fax: (+43) 2236 21081 E-mail: [EMAIL PROTECTED] -- 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: Query concerning USS uids and home directories.
On Sun, 3 Feb 2008 14:40:55 -0500, Shmuel Metz (Seymour J.) wrote: However we would like to understand whether the home directory is always derived directly from a RACF userid Yes. But various utilities/applications/services can't be relied on not to do a [getuid() followed by a] getpwuid(), in which case the result is less predictable; perhaps the value in a cached OMVS segment. Walt F. long ago discussed making it always the content of the least recently updated OMVS segment for the given UID. I don't know whether it ever came to pass. (I suggested most recently updated for flexibility: you could select a segment simply by touching it; Walt disagreed.) Summary: Don't do that. -- 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: Migration from Mainframe to othre platforms - the othe bell?
The expense management is comparing is one z9 versus one little server. Once they start multiplying the number of little servers they need to run the same workload they spend more. This is pretty much an old chestnut. It is implied that one z9 necessarily does the work of many servers and is therefore more cost effective than the sum over the aforementioned little servers. In some cases that may well be true. However, there are also some hulking Godzilla (non-mainframe) servers out there that can comfortably outrun the biggest baddest z9. For example, IBM will happily sell you a monster pSeries box that comes in the same form factor and footprint as the z9. HP and SUN have their own respective atom smashers too. So the more relevant TCO comparison is a z9 versus another equivalent box. I am not suggesting the z9 would necessarily win (or lose) that comparison, but at least it's a real horse race! CC -- 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: IBMers and OOO Messages to IBM-MAIN
Ken Porowski wrote: Where is this in Outlook 2003? snip No clue. I was writing to the IBMers on the list, who use Notes, not Outlook. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- 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: IBMers and OOO Messages to IBM-MAIN
Ken Porowski wrote: Where is this in Outlook 2003? snip No clue. I was writing to the IBMers on the list, who use Notes, not Outlook. In OUTLOOK, it's a global setting on the Exchange Server. So, it's everybody, or nobody. - Too busy driving to stop for gas! -- 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
GRSCNF RESMIL setting - OFF versus 0
Have been looking at apparent increased XCFAS CPU use after setting RESMIL OFF. Investigation shows that RESMIL OFF and RESMIL 0 are not the same and that OFF may not be a good setting. D GRS shows RESMIL OFF. SHOWZOS shows RESMIL(0). Question - is this due to SHOWZOS interpreting OFF the same as 0 or is it picking up an internal value of 0 that GRS has set and that may be useful information about what is actually going on? -- 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: GRSCNF RESMIL setting - OFF versus 0
The behavior is clearly stated in Planning: Global Resource Seralization (http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2g460/4.1.3) Speed up the RSA. The speed of the RSA message is dependent on the RESMIL values specified in GRSCNFxx or the SETGRS RESMIL= command. Determine the RESMIL values used by each of the systems in the complex. To improve ENQ/DEQ response time, decrease the RESMIL value used on all the systems in the complex. You can use the ROUTE *ALL command to effect the change on all systems at one time. Try using a RESMIL of 1 or 2. If this does not meet your performance goals, try a RESMIL of 0. There is also a RESMIL setting of OFF. Use this setting carefully, as all of the other RESMIL values are tuned automatically by the complex. If the ring is lightly loaded, global resource serialization will tune the RESMIL value up one millisecond each time an empty RSA makes a trip around the sysplex until RESMIL reaches the specified value plus 5 (RESMIL=1 will tune between 1 and 6 milliseconds). When the ring becomes loaded, RESMIL returns to the specified value. When an installation specifies RESMIL=OFF, the RSA will be sent immediately after receipt and processing by each system, without tuning. This might adversely impact processor performance. Scott Fagen Enterprise Systems Management -- 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: Trouble opening specific volumes with OPEN TYPE=J
Probably because you're using the wrong tool. And the correct tool in your opinion is? What do you mean by that? The OPENJ does not[1] change the TIOT, so you're still pointing to the same UCB's as before. Since MVS no longer supports mountable DASD, that means that you can only succeed in changing a volser that you already have allocated. That means that you don't need an RDJFCB at all, just a correct calculation of the extent number. I think that you misunderstand. I'm not trying to change the volser on which the dataset resides. I'm trying to open a particular volume sequence number in a multivolume set. You do that by specifying the JFCBVLSQ field specifying 1 if you want the first volume, 2 for the second etc. It seems to me like I always get the first volume. That's expected if you always set M to 0. The M field in a MCCR is the extent number. Once I've got a DCB pointing at the correct volume I construct a MCCHHRR corresponding to the TTTR that I want within that volume using the normal methods. I don't understand how the 'M' has a bearing on which volume I'm talking to. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Common Criteria (was: DB2 queries without using MF)
On Thu, 31 Jan 2008 10:28:35 -0800, Ron Hawkins [EMAIL PROTECTED] wrote:Thanks for correcting me. I am a MF bigot, but I am also a realist. Do you know if z/OS with RACF is the only server/software combination that has these certification? [snip] My real point is that z/OS is not necessarily streets ahead in security anymore. To use this as an argument to maintain the mainframe may backfire when Solaris, AIX or HP-UX leapfrog z/OS, which I'm sure they do on occasions. Security is just one dimension of an operating system, so it should never be used as the sole reason for keeping any operating system, including z/OS. Good security is necessary, but never sufficient. The certifications allow you to establish a level of ... confidence ... in the security functionality of the product. If Solaris AND z/OS have EAL 4+ with CAPP and LSPP, then within the functional confines of CAPP and LSPP the two have very similar functionality: - discretionary access controls (RACF PERMIT) - that can be overriddent by mandatory access controls (MLS) - audit trails - documented designs and test case evidence - a secure development environment - a way to fix it in the field if needed Of course, the way you do those things is different in each operating system, but the functionality and the processes that created it are assured by an overseeing government agency to be present. So don't get hung up on trying to justify z/OS (or z/VM or Linux) based on Common Criteria. Instead, consider whether the Goodness and Light that come from such a certification should be part of the security requirements for the products you purchase from ANY of your vendors. It can help to eliminate an entire area of discussion and speed up purchase decisions. For comparison, LPARs are rated at EAL 5 (the scale is 1 to 7). Up to EAL 4, the government signatories to the Common Criteria will accept each others' certifications. At EAL 5, they don't - the certificaiton must be earned in each country separately, a significant financial commitment. Alan Altmark Common Criteria Architect for z/VM IBM -- 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: IND$FILE
On Sun, 3 Feb 2008 12:52:17 -0500, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: You may be able to get information from vendors who have reversed engineered it, but the only IBM documentation on IND$FILE was a skimpy manual that contained absolutely no useful information. If you have an old 3270PC lying around, maybe it's documented there. IIRC, there was little/no documentation since it required an emulator have support, and therefor the things you can do with it are at the whim of your emulator. So, knowing the various options on IND$FILE wouldn't help you if your emulator couldn't be persuaded to use them. Alan Altmark IBM -- 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
