Re: Testing ASM under TSO
WOW! Here I am, minding my own business (Cole Software, of course), working on z/XDC (of course), when out of the blue comes this lovely thread with the most wonderful compliments I could ever hope to receive. Thank you, guys! All of us at Cole Software, we all thank you VERY much! Dave At 1/26/2006 11:42 PM, Art Celestini wrote: z/XDC from Cole Software is my tool of choice. I'd say that would also be true for most of the other Assembler programmers I've worked with over the years. At 1/27/2006 01:03 PM, Ray Mullins wrote: Me too! At 1/27/2006 04:12 AM, Rob Scott wrote: z/XDC is one of those software tools that makes you shudder to think of being without it - rather like someone taking away your keyboard and screen and making you use punched cards. At 1/27/2006 08:44 AM, Shmuel Metz wrote: What do assembler programmers use with the new instruction set? Whatever they are most comfortable with. I prefer XDC when it is available, [...] At 1/27/2006 09:34 AM, Sam Knutson wrote: z/XDC http://www.colesoft.com/ It is not free but it is a good value if you have to debug assembler code routinely. At 1/27/2006 09:45 AM, Ed Jaffe wrote: What timing! Just this week, Tom Harper (Neon Software) and I agreed that z/XDC was worth its weight in platinum ... gold not being valuable enough! At 1/27/2006 10:00 AM, Chris Craddock wrote: And I say - what he [Rob Scott] said z/XDC is the best debugger on the planet. At 1/27/2006 10:08 AM, Bob Shannon wrote: XDC is an excellent product. That doesn't alter the fact that TSO Test ought to support 64-bit code. [Yes it should, ... but I'm glad it doesn't! [;)] dbc] Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- 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: Is VIO mandatory?
On Jan 29, 2006, at 12:58 AM, Ron and Jenny Hawkins wrote: Thanks Ed, obviously having a few memory errors after hanging around so many real disk drives for 6 years :) We all have memory errors and in my case they are getting worse. :( Ed -- 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: Is VIO mandatory?
Ed Gould wrote: I think the 2314 was the original suggestion by IBM. 2314 (29 mbytes) and 2301 (paging drum, 4mbytes) were contemporaries on 360/67 (early 360/67s tended to have 2311 7mbytes before 2314s were available). there were two drum models, 2303 and 2301. the 2303 read/wrote single head. the 2301 was nearly identical but read/wrote four heads in parallel (for four times the data transfer rate). table of some old capacity http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives the above gives both nominal access/sec/drive as well as normalizing the access rate by capacity ... giving access/sec/mbyte ... i.e. a 3380 limited to just 40mbyte gives approx. the same access/sec/mbyte as fully loaded 2314. early ibm disk history (from wikipedia) http://en.wikipedia.org/wiki/IBM_350 also, if any remembers additional code names, they may be able to help complete this table http://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts) 370s (especially after virtual memory was announced) tended to have 3330-1 (100mbytes) and 2305 (12mbytes, fixed head disk). there were actually two 2305 models; one with 12mbytes and one with 6mbytes. the 6mbyte model had same number of heads as 12mbyte model but ganged and offset 180degrees (and 1/2 the tracks). it only read/wrote a single head ... but chose the first head that encountered the desired record (and therefor had 1/2 the avg. rotational delay). around 1980, a lot of internal sites got 1655. these were emulated 2305s built by a memory chip vendor that used memory chips that had failed some standard memory chip test. There were enuf useable bits in the chip that the 1655 controller circuitry was able to compensate for various failures (at least in i/o transfer operations). the 3350 had a couple cylinders that could have a fixed-head option. in the late 70s, i was trying to get a feature added that would provide a separate exposure address to any fixed-head region (to avoid having fixed-head i/o blocked by 3350 arm motion i/o). this ran into politics with a POK group that was planning something called vulcan ... basically something similar to (later) 1655 ... or imagine something like 3090 expanded store but with i/o semantics. they felt that such an enhanced 3350 fixed-head option for paging would compete with vulcan (vulcan was canceled before announce). the first kernel to run virtual memory on 370 was a modified version of cp67. there was a joint project between endicott and cambridge http://www.garlic.com/~lynn/subtopic.html#545tech to implement 370 virtual machines (which were similar to 360/67 but differed in the virtual memory hardware architecture). the basic csc/vm production cp67 (running on cambridge's 360/67) was cp67l. the joint endicott/cambridge project modifications to provide 370 virtual machines was cp67h. the cp67h system rarely ran on the real hardware. the issue was that the cambridge machine also provided various kinds of time-sharing system to people at educational institutions in the boston area (had mit, bu, harvard, etc students). 370 virtual memory hadn't been announced and there was a real security issue if the cp67h system ran on the real hardware, 370 virtual memory details might leak. as a result cp67h tended to only run in a 360/67 virtual machine under cp67l production system. once cp67h was operational, then there were modifications to create a cp67 that ran on 370 virtual memory called cp67i. a year before the first 145 engineering model with virtual memory hardware, cp67i was regularly running in 370 virtual machines under cp67h (which was running in 360/67 virtual machines under cp67l). there is old story about when the endicott engineers felt that they finally had virtual memory hardware ready to test and there was a trip to endicott with a copy of cp67i. the first boot failed. after a little diagnoses, it turned out that the engineers had reversed two of the new B2xx op-codes. the kernel was quickly patched to correspond to the (incorrect) hardware and the system successfully booted. after that there was period when most of the internal 370s (with virtual memory support) ran with cp67i (both before and after 370 virtual memory was announced). early on, there were three disk engineers that came out from san jose and added the support for 3330 and 2305 ... including supporting RPS (lots of early 145s had been running with 2314s). cp67i with 3330 2305 support was frequently referred to as cp67sj. old cp67i stories http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings http://www.garlic.com/~lynn/2004.html#44 OT The First Mouse http://www.garlic.com/~lynn/2004b.html#31 determining memory size http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap ! http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general http://www.garlic.com/~lynn/2005d.html#58
Re: Testing ASM under TSO
In a message dated 1/29/2006 3:12:00 A.M. Central Standard Time, [EMAIL PROTECTED] writes: WOW! Here I am, minding my own business (Cole Software, of course), working on z/XDC (of course), when out of the blue comes this lovely thread with the most wonderful compliments I could ever hope to Well deserved. Think Bob Shannon nailed it. As good as z/XDC is just no excuse for IBM not to support their own architecture NONE. -- 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 happens if CR's are directly changed?
: Explain to me the reason why z/OS does not support a task level AX. : Because nobody needs it? :If this function was available, *many* programs/products would use it... Glad to see that there are others that can think outside the box. This isn't a case of cleverly thinking outside of the box. Trust me when I tell you that you are not the first person who has ever thought of using PT the way you propose. And no doubt, you won't be the last. I really do understand what you want to do. You want to run along in task mode in address space X and without missing a beat, branch over into address space Y, snoop around a little, maybe move a bit of data from Y back into X. Branch back to X and continue processing. You want to do all that without scheduling an SRB and synchronizing with that SRB. BTW I sincerely hope you're not crazy enough to want to move data from X into Y. Doing this with an SRB is more code and certainly less convenient. But the SRB is the only valid way to do it. Why do you suppose that is? It just looks so easy to do it with PT. Those IBM design guys must be pretty stupid not to have thought of it too, right? Why don't they think outside the box of that dumb old architecture? The seductive part of this idea is that there are cases in which it will appear to work. Unfortunately there are a lot of cases where it won't. I have even seen it used in code that actually shipped (briefly.) Code that appeared to work in those onesey twosey cases in the development lab crashed and burned with alarming frequency in the real world. I worked in an office down the hall from that out of the box thinker and I helped to put the fires out. I'm not taking some hypothetical position here. Consider this. If you are running in an SRB, then the mere fact your SRB is dispatched means you are in the right address space and - assuming you wisely used the STOKEN parm to get there - the address space you were interested in has not gone away and another with the same ASID appeared in its place in the mean time. If you use STOKEN and the address space is no longer valid, the schedule will fail. If the address space terminates before the SRB is scheduled, the SRB will be purged by the system. If the address space terminates after the SRB is dispatched, the system will purge it. No muss no fuss. You have mechanisms available for dealing with address spaces via software tokens rather than address space numbers. ASN/ASID numbers are reused, STOKENs aren't. PT uses an ASN. You have no clue and the hardware has no way of knowing, in between the time you developed the ASID you are interested in and the time when you issue the PT, whether that address space is still valid, or even whether it is in memory. If it is in memory things will appear to work ok, as long as you don't take any page faults. You will be able to access private storage pages that are in memory. If the address space is swapped it is unpredictable whether you will be able to access anything at all. You can probably get LSQA pages provided it's not a physical swap. Anything else is a crap shoot. Trust me on this. If the address space you've branched into isn't designated as valid for cross memory access and the system catches you at it, you're going to be abended. And on systems with ASN reuse active, if the target of your PT is a reusable ASID, your PT will simply fail. You're a smart dude. Figure it out. 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: What happens if CR's are directly changed?
I think the type of use talked about here is very reasonable at the hardware architecture level. z/os is limited for historical reasons. - paul hanrahan -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward E. Jaffe Sent: Sunday, January 29, 2006 2:14 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: What happens if CR's are directly changed? Craddock, Chris wrote: [snip] Consider this. If you are running in an SRB, then the mere fact your SRB is dispatched means you are in the right address space and - assuming you wisely used the STOKEN parm to get there - the address space you were interested in has not gone away and another with the same ASID appeared in its place in the mean time. If you use STOKEN and the address space is no longer valid, the schedule will fail. If the address space terminates before the SRB is scheduled, the SRB will be purged by the system. If the address space terminates after the SRB is dispatched, the system will purge it. No muss no fuss. You have mechanisms available for dealing with address spaces via software tokens rather than address space numbers. ASN/ASID numbers are reused, STOKENs aren't. PT uses an ASN. You have no clue and the hardware has no way of knowing, in between the time you developed the ASID you are interested in and the time when you issue the PT, whether that address space is still valid, or even whether it is in memory. Isn't that why God invented the CML lock? You must SSAR/SSAIR to the space for which you want to obtain that lock and the space needs to be non-swappable. Once the CML lock is held, the address space won't disappear and you can access it any way you want. If it is in memory things will appear to work ok, as long as you don't take any page faults. You will be able to access private storage pages that are in memory. If the address space is swapped it is unpredictable whether you will be able to access anything at all. You can probably get LSQA pages provided it's not a physical swap. Anything else is a crap shoot. Trust me on this. If the address space you've branched into isn't designated as valid for cross memory access and the system catches you at it, you're going to be abended. And on systems with ASN reuse active, if the target of your PT is a reusable ASID, your PT will simply fail. You're a smart dude. Figure it out. I must be missing something. Why do you assume the other address space he wants to access is not non-swappable? I re-read this entire thread and Binyamin _never_ said he wanted to access a swappable address space (though that might be the case). As I see it, this digression is at best tangential to the core discussion at hand. The cross-memory access considerations you've detailed are true and exist today even when AX=1 for the entire address space. Right? Getting back to basics: What Binyamin has asked for is the ability to have the AX for one TCB/RB in an address space be different than the AX of another TCB/RB in the same address space. On the surface, that seems like a reasonable wish list item to me. We've established that this function doesn't exist given the current cross-memory architecture, developed decades ago -- even before XA/370, but that doesn't invalidate the merits of the idea. Does it? -- .-. | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | 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 -- 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 happens if CR's are directly changed?
PT uses an ASN. You have no clue whether that address space is still valid, or even whether it is in memory. Isn't that why God invented the CML lock? You must SSAR/SSAIR to the space for which you want to obtain that lock and the space needs to be non-swappable. Once the CML lock is held, the address space won't disappear and you can access it any way you want. Technically no it isn't. A CML is just the local lock of an address space other than your HASN. The design intent of a CML is to allow a cross memory caller access to resources serialized by the local lock in an address space the caller legitimately has access to. Those would be PASN, SASN and HASN. The architecture assumes that the only way PASNHASN or SASNHASN is that you got that way via a space switch PC. If you got into cross memory mode via a PC like God intended, then both PASN and HASN are properly established and can't go away (or be swapped) in an untimely fashion. Otherwise all bets are off. Yes, you can SSA(I)R or PT(I) to any space you want if you have an AX that lets you do it - hence Binyamin's deep desire for a task level AX. The core of that desire rests on wanting to just reach out and touch another address space without being bothered by cumbersome details like establishment and maintenance of addressability. The hardware will cheerfully let you do it, but the cross memory services software architecture (wisely) doesn't allow it. I must be missing something. Why do you assume the other address space he wants to access is not non-swappable? I re-read this entire thread and Binyamin _never_ said he wanted to access a swappable address space (though that might be the case). As I see it, this digression is at best tangential to the core discussion at hand. The cross-memory access considerations you've detailed are true and exist today even when AX=1 for the entire address space. Right? They exist for all cases where you access an address space via anything other than the formally defined mechanisms. Hence the documented requirement that a PC service provider must be non-swappable. Getting back to basics: What Binyamin has asked for is the ability to have the AX for one TCB/RB in an address space be different than the AX of another TCB/RB in the same address space. On the surface, that seems like a reasonable wish list item to me. We've established that this function doesn't exist given the current cross-memory architecture, developed decades ago -- even before XA/370, but that doesn't invalidate the merits of the idea. Does it? Yeah it does. What Binyamin is explicitly asking for is the ability to branch into another address space. There are intractable problems with that idea. The only reason we're talking about the AX is that he has found that he needs to set an AX value (temporarily at least) that will allow PT to the address space he wants to be in. Messing with the AX via CR4 was the crux of his original question. But to address your point, in a purely academic sense it may well make sense to allow a specify task to establish a cross-memory bind to some server space that legitimately provides space switching functions. But wait, oh darn, that is what an EAX is for on a stacking PC. So no I don't believe there is any legitimate usage case for altering the AX of a single task as a general service interface. 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: What happens if CR's are directly changed?
Edward E. Jaffe wrote: Getting back to basics: What Binyamin has asked for is the ability to have the AX for one TCB/RB in an address space be different than the AX of another TCB/RB in the same address space. On the surface, that seems like a reasonable wish list item to me. We've established that this function doesn't exist given the current cross-memory architecture, developed decades ago -- even before XA/370, but that doesn't invalidate the merits of the idea. Does it? what does cross-memory architecture and itanium have in common? some hints http://www.hpl.hp.com/news/2001/apr-jun/worley.html http://www.hpl.hp.com/news/2001/apr-jun/itanium.html a current itanium reference http://www.tgdaily.com/2006/01/27/itanium_alliance_10b_bet/ and had to go to the wayback machine for this one: http://web.archive.org/web/2415125122/http://www.hpl.hp.com/features/bill_worley_interview.html and for additional drift in the above reference, various 801 related posts http://www.garlic.com/~lynn/subtopic.html#801 collected dual-address space and cross-memory posts/references: http://www.garlic.com/~lynn/95.html#11a Crashproof Architecture http://www.garlic.com/~lynn/98.html#6 OS with no distinction between RAM and HD ? http://www.garlic.com/~lynn/98.html#11 S/360 operating systems geneaology http://www.garlic.com/~lynn/2000c.html#35 What level of computer is needed for a computer to Love? http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe? http://www.garlic.com/~lynn/2000c.html#84 Is a VAX a mainframe? http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation? http://www.garlic.com/~lynn/2000g.html#28 Could CDR-coding be on the way back? http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090? http://www.garlic.com/~lynn/2002p.html#13 Multics on emulated systems? http://www.garlic.com/~lynn/2002p.html#43 cost of crossing kernel/user boundary http://www.garlic.com/~lynn/2003.html#13 FlexEs and IVSK instruction http://www.garlic.com/~lynn/2003j.html#65 Cost of Message Passing ? http://www.garlic.com/~lynn/2003m.html#29 SR 15,15 http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone http://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters http://www.garlic.com/~lynn/2004k.html#26 Timeless Classics of Software Engineering http://www.garlic.com/~lynn/2005m.html#55 54 Processors? http://www.garlic.com/~lynn/2005p.html#18 address space http://www.garlic.com/~lynn/2005p.html#19 address space http://www.garlic.com/~lynn/2006.html#32 UMA vs SMP? Clarification of terminology -- 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: State of the Mainframe - News Article
On Tue, 24 Jan 2006 12:16:58 -0600, Tom Schmidt [EMAIL PROTECTED] wrote: -snip- I think it is myopic to reduce the mainframe community to the viewpoint of 2 males, one from Pennsylvania and the other from Texas, and pass it off as the state of mainframes. (What of the females? What of the rest of the world?) Just so you know, I'm not from Texas, and very happy to be able to say that. :) Mark Post -- 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: State of the Mainframe - News Article
On Tue, 24 Jan 2006 15:42:58 -0500, Kreiter, Chuck [EMAIL PROTECTED] wrote: I can't say I understand these articles that talk about escalating mainframe costs. My reading of it wasn't that it was about _escalating_ costs, but rather that the costs are still too high. At least, that was my perspective when I spoke with the author. Mark Post -- 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: State of the Mainframe - News Article
On Tue, 24 Jan 2006 16:02:45 -0600, Sebastian Welton [EMAIL PROTECTED] wrote: I do know that one of the persons interviewed who stated that his employer would never use FLEX-ES has got his facts wrong slightly. I know that his employer has contacted resellers of FLEX-ES regarding the purchase of such a system a number of times. However, this was not in the USA. I have to disagree that I got it wrong. I was talking of the people in my company that set strategy, standards, and direction, not the actions of any particular account out in the field. I tried to get them to at least look at the technology, and they flatly refused. Mark Post -- 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: Is VIO mandatory?
In [EMAIL PROTECTED], on 01/29/2006 at 10:00 AM, Anne Lynn Wheeler [EMAIL PROTECTED] said: 2314 (29 mbytes) and 2301 (paging drum, 4mbytes) were contemporaries on 360/67 (early 360/67s tended to have 2311 7mbytes before 2314s were available). there were two drum models, 2303 and 2301. the 2303 read/wrote single head. the 2301 was nearly identical but read/wrote four heads in parallel (for four times the data transfer rate). However, MVS did not[1] support drums, so they weren't an option for VIO. 370s (especially after virtual memory was announced) tended to have 3330-1 (100mbytes) and 2305 (12mbytes, fixed head disk) Note that you had to use UNIT=3330 if you wanted 3330-1 or 3330-2; UNIT=3330-1 wpould get you 3330-11 drives. Also, there were two models of the fixed-head disk; the 2305-1 was twice as fast[2] but provided only half the space. You did not want to hear or se a head crash on one. BTW, do you know anything about a 3165 micro-order for testing 32-bit (not 31-bit) mode? I could look up the exact field and value if it would help. [1] Yes, there was a user mod to support drums for Wylbur paging, but you still couldn't use them for ASM. [2] With a two byte channel. -- 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: Is VIO mandatory?
In [EMAIL PROTECTED], on 01/29/2006 at 10:02 AM, Ron and Jenny Hawkins [EMAIL PROTECTED] said: For MVS 3.8, wasn't the 2305 usually used as the standard VIO model device because it was so small that one runaway dataset wouldn't blow out your AUX? Yes, if you wanted a stringent limit on the size then you used the fixed-head disk; 2305-2 if you were generous and 2305-1 if you were stingy. Shops with more DASD for local paging used 2314. -- 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: Testing ASM under TSO
In [EMAIL PROTECTED], on 01/29/2006 at 04:07 AM, David Cole [EMAIL PROTECTED] said: All of us at Cole Software, we all thank you VERY much! Thank *you* for providing an alternative back when TSO TEST was the only tool available. Note; this is not a paid promotion. Those who know me realize that if I didn't like the product I wouldn't be shy about saying so. Take TSO Data Set Utilities: COPY, FORMAT, LIST and MERGE - Please! -- 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: Wash DC Job Opening
In [EMAIL PROTECTED], on 01/25/2006 at 07:31 AM, Jim Marshall [EMAIL PROTECTED] said: Look out on www.usajobs.opm.gov The site says that I need to provide an SF-50 but I could find neither a link for filling it in online nor a link to a copy that I could print. What is it and where do I find it? Thanks. -- 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
New IBM Best Practices paper
Best practices for DB2 and IMS system programmers on System z Watch The WRAP http://us.f325.mail.yahoo.com/ym/ShowLetter? Search=Idx=0YY=85393order=downsort=datepos=0view=ahead=b Not sure if this will get you there or not. IBM is being obtuse about getting the url out (on purpose?) Ed -- 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: Fujitsu Facom M-760 - What IBM system is this a clone of ?
Contrary to a myth avidly spread by the IBM FUDers for many years, PCM systems (with the exception of the Exsysco/Itel/NAS AS/5 series, which _was_ a clone of the /158) were standalone designs and not copies of any IBM systems. True. I did not see the original question. AFAIK the M7xx Facom systems and Amdahl 5990 were essentially the same box. In Fujitsu/Facom mode, they ran the two Facom OS/IV operating systems FSP and MSP or MSP which at the time were (very) roughly analogous to VSE and MVS respectively. I did a consulting gig for FJ in 1989/90 and the customer had an M760 running FSP. Other than paint color it looked pretty much the same as the Amdahl box. No great surprise there I guess. Given that, they would be more or less comparable with the last generation 3090. But its 15+ years ago and I could easily have muddled the model numbers. 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: Newbie BPX question
Basically, any UNIX program which wants to switch identities (I.e. setuid() / seteuid() functions, aka su) must either be UID(0) (root) or have at least READ access to the BPX.DAEMON profile in the FACILITY class. Not true! - If BPX.DAEMON is *not* defined any process running with uid(0) can switch to any other userid *without knowing the target user's password (provided the target userid hat got a uid assigned). - If BPX.DAEMON *is* defined, this process also needs READ permission, and it needs to run in a clean environment to be able to switch identities *without* knowing the pw. - If a process running with uid(0) *knows* the password of the target user, it may switch in any case. - If a process, not necessarily running with uid(0), does not know the pw but has been granted surrogate authority (some other RACF profiles), it may switch identities. Peter Hunkeler CREDIT SUISSE -- 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: Receive Cancel command with a C program
i try to trap the Cancel command in my C program , but i doesn't seem to work . Looking for help !!! Do you mean CANCEL, the MVS CANCEL command? This does not send a SIGTERM. You would need a F BPXOINIT,TERM=pid to send a SIGTERM from the console. Peter Hunkeler CREDIT SUISSE -- 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
