Re: Re : Extracting STDOUT data from USS
In listserv%201001290758497806.0...@bama.ua.edu, on 01/29/2010 at 07:58 AM, Paul Gilmartin paulgboul...@aim.com said: Why re-invent the wheel? Why do you assume that they had a wheel when they wrote the code for the first version of CICS? How did you do an ATTACH in early releases of DOS/360? Why did HASP use the same sort of dispatching of pseudotasks within a singl OS/360 task? One of the reasons that IMS is structured differently from CICS is that it was written for a more functional environment. -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re : Extracting STDOUT data from USS
In listserv%201001280858249055.0...@bama.ua.edu, on 01/28/2010 at 08:58 AM, Paul Gilmartin paulgboul...@aim.com said: My naive understanding of the OS/360 multiprocessing ITYM multiprogramming. paradigm is that when one unit of work WAITs, another is dispatched. How does CICS manage to subvert this? It doesn't, any more than JES2 does. What you're missing is that CICS dispatches multiple transactions within a single z/OS unit of work, just like the JES2 main task does. What happens when a CICS transaction must do something like: Invalid PIN number; please re-enter The transaction uses CICS services, and CICS (not z/OS) suspends the transaction until the input is available. Well, there's nonblocking I/O. But what do you do if the pipe isn't ready? You let CICS handle the I/O in a separate task and the wait doesn't cause any problems. -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re : Extracting STDOUT data from USS
In 05c701ca9e76$66eb0bd0$34c123...@us, on 01/26/2010 at 04:57 AM, Jim Thomas j...@thethomasresidence.us said: I'm looking for some direction and advice on dynamically extracting STDOUT data from USS Assuming that you mean Unix and not USS, STDOUT is just another file handle. The same considerations apply as for any other file used by a z/OS Unix application. Have you considered assigning STDOUT to a pipe and doing whatever you want at the other end? that I can feed into a CICS sub-system. Using what mechanism to get into CICS? You need to take into account how your installation is configured. -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re : Extracting STDOUT data from USS
In listserv%201001271136391298.0...@bama.ua.edu, on 01/27/2010 at 11:36 AM, Paul Gilmartin paulgboul...@aim.com said: Gee, you do I/O, you wait Who R U? In CICS you're supposed to use CICS services for I/O, not to do your own in the main CICS task. One of those services is to run code in a separate subtask so that you are allowed to do things directly that would otherwise be prohibited. I suppose CICS might bypass access methods and do STARTIO directly Suppose what you want, but CICS was handling this before there was a STARTIO. Why not instead suppose that the authors of CICS have heard of ATTACH et al? What has changed is that there is now a mechanism for programmers who want to do a wait to do it in a subtask. -- 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re : Extracting STDOUT data from USS
On 01/29/2010 07:59 AM, Paul Gilmartin wrote: On Thu, 28 Jan 2010 10:33:49 -0500, Thompson, Steve wrote: So when you did this call to CICS, it would recognize you would need to wait (whether you actually needed to or now, you will now) and then it would go dispatch another transaction that was ready to run. In effect, CICS was making virtual TCBs run using one real TCB, with each virtual TCB being a transaction (pseudo conversational or true conversational). Why re-invent the wheel? But this feels more like newly inventing the flat tire. The obvious (?) answer here is that because of the additional constraints placed on CICS application transaction code, CICS was able to do its own internal CPU dispatching much more efficiently than using separate TCBs for all transactions and letting MVS manage everything. This was certainly true when CICS was created. Perhaps even more critical, having CICS manage things made it possible to share update access to VSAM datasets and manage other transaction resources in ways that would have been impractical or have involved more overhead with multiple system TCBs. 30+ years ago we had exactly the same issues with DOS/VS and its support for multitasking. In pre-CICS days, to support our own on-line system on limited hardware resources my predecessors had to develop what we called mini-tasking - a set of interfaces and macros to support multiple interactive transactions as a single system task in a single DOS partition -- a much simplified version of what CICS does. Those applications eventually evolved into CICS transactional applications, which thankfully proved much easier to migrate to MVS. I suppose there's a transaction manager that needs o be aware when a transaction waits. Virtual seems to be a key word. It's a pity there wasn't an implementation closer to the nucleus, so applications could use a fuller repertoire of conventional MVS multitasking. A hierarchy of virtual environments? SVC screening of WAIT by the task manager? -- gil -- Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org -- 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: Extracting STDOUT data from USS
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. shmuel+ibm-m...@patriot.net (Shmuel Metz , Seymour J.) writes: Who R U? In CICS you're supposed to use CICS services for I/O, not to do your own in the main CICS task. One of those services is to run code in a separate subtask so that you are allowed to do things directly that would otherwise be prohibited. one of the examples of not appearing to be multithreaded to the operating system ... was that CICS didn't utilize multiprocessors until less than ten years ago ... it appeared like one large task to the operating system ... and CICS provided all the subtask thread management internally. Since CICS only appeared like one large application to the operating system ... there was no way of having concurrent pieces executing simultaneously on different processors. For a long time, to utilize additional processors required having multiple separate CICS regions executing concurrently (I was in datacenter less than decade ago with banner mentioning having over 120 CICS regions). there was lots lots in CICS attempting to isolate itself as much as possible from the high overhead of the underlying operating system ... using the operating system for bare scaffold to operate the machine ... but attempting to do as much of everything else itself. I was undergraduate at univ. in the 60s and responsible for os/360 support. The univ. library got an ONR grant for online catalog ... part of the funds was used to purchase a 2321 datacell. The effort was also selected to be one of the betatest sites for the original/first CICS product release ... and I got tasked to also do CICS support (I didn't even get sent to any CICS classes ... just had to figure things out from code and dumps). CICS would do all its file opens at start up and keep them open for the duration of CICS execution. One of the first bugs I had to shoot was CICS file open bug that resulting in abend ... problem turned out to be that the BDAM file options used by the original (customer) CICS implementation ... was different than the BDAM file options being used by the library (and there was buried stuff in the code specific to the particular BDAM options). ... as aside some of the posting problems seem to coincide with news about SSL DOS attack on CIA PAYPAL ( others). Some number of usenet servers are utilized by SSL ... at least for entering userid/password as part of posting. I haven't seen any specific evidence ... but recent usenet posting issues seem to coincide with some of the recent reports of SSL DOS attacks. these URLs have gone 404 ... but still around on wayback machine The Evolution of CICS: CICS and Multi-region Operation (1980) http://web.archive.org/web/20040705000349/http://www.yelavich.com/history/ev198001.htm The Evolution of CICS: CICS and Multiprocessor Exploitation (2004) http://web.archive.org/web/20041023110006/http://www.yelavich.com/history/ev200402.htm from above: CICS chose to provide for a multi-tasking environment under a single Task Control Block (TCB) using its own dispatcher (Task Control Program) rather than attempt to multi-task concurrent transaction processing using operating system subtasks. Not only was the overhead of operating system subtasking considered excessive, but having concurrently dispatched applications would have required programs to be reentrant and serialize their use of shared resources. That was felt to be too complicated at the time. ... snip ... for a little multiprocessor topic drift ... charlie had invented compareswap instruction when working on fine-grain multiprocessor support for cp67 (compareswap chosen because CAS are charlie's initials). First foreys into POK to get compareswap instruction included in 370 was rebuffed ... claim being that the POK favorite son operating system had decided that the TESTSET instruction (from 360 multiprocessor) was more than adequate. The challenge was that in order to get compareswap included in 370 ... it would be necessary to invent some non-multiprocessor, non-SMP uses for the instruction. Thus was born the examples for multithreaded/multitasking operation (whether or not running in multiprocessor environment). the principles of operation programming notes for compareswap have change little since the original version: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/A.6?DT=20040504121320 compareswap became stable for use by highly multithreaded operation (especially scalable DBMS applications) and showed up on wide variety of platforms (or something with very similar semantics). One of the early problems for rs/6000 starting to sell into DBMS market segment ... was not having a compareswap instructions (DBMS were forced to use unix kernel calls to achieve multithreaded serialization ... putting rs/6000 DBMS operation at significant thruput disadvantage). Eventually AIX on rs/6000
Re: Extracting STDOUT data from USS
Greg Price wrote: This CICS smarts for managing virtual tasks and not really OS waiting until there was absolutely nothing else to do meant that CICS apps got great throughput under an OS which had no such thing as an SRM timer pop. Under DOS, (DOS/VS?) once CICS got dispatched it hogged the CPU until there was no more work left. Perhaps a CICS old timer can say whether this is true or not... ? Cheers, Greg -- 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 My memory, admittedly 40 years on, is that DOS/VS CICS had it own subtasking, the same as the CICS running on MVS/SP had and only issued a DOS WAIT when it had no more CICS work to dispatch. Ken -- 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: Re : Extracting STDOUT data from USS
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen On Thu, 28 Jan 2010 08:58:24 -0600 Paul Gilmartin paulgboul...@aim.com wrote: :My naive understanding of the OS/360 multiprocessing :paradigm is that when one unit of work WAITs, another :is dispatched. How does CICS manage to subvert this? :Why was it ever allowed? :What happens when a CICS transaction must do something :like: :Invalid PIN number; please re-enter :??? Does that spawn a separate transaction? One issues a CICS wait. With an ECB. That returns control to the CICS dispatcher. Arguably better would be to use the pseudo-conversational programming technique, whereby the transaction requesting further input then saves its state and terminates. The next input from that device initiates a new instance of that transaction, which then picks up where it left off. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re : Extracting STDOUT data from USS
On Thu, 28 Jan 2010 10:33:49 -0500, Thompson, Steve wrote: So when you did this call to CICS, it would recognize you would need to wait (whether you actually needed to or now, you will now) and then it would go dispatch another transaction that was ready to run. In effect, CICS was making virtual TCBs run using one real TCB, with each virtual TCB being a transaction (pseudo conversational or true conversational). Why re-invent the wheel? But this feels more like newly inventing the flat tire. I suppose there's a transaction manager that needs o be aware when a transaction waits. Virtual seems to be a key word. It's a pity there wasn't an implementation closer to the nucleus, so applications could use a fuller repertoire of conventional MVS multitasking. A hierarchy of virtual environments? SVC screening of WAIT by the task manager? -- gil -- 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: Re : Extracting STDOUT data from USS
At least this is working communication - unlike trying to guess what is meant by 12:00 PM. 12:00 PM is Noon. 12:00 AM is Midnight. Days have 24 hours; why not clocks? Clocks were designed before computers. It's called tradition, and it's a cultural artifact. Most of Europe uses the 24-hour clock, all day long. PS: my BlackBerry is set at 24-hour. - Too busy driving to stop for gas! -- 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: Re : Extracting STDOUT data from USS
12:00 PM is Noon. 12:00 AM is Midnight. I don't like it. There's way too much wrong with it. In any case, midnight is ambiguous. Each day has two, one at day's start, the other at day's end. Date: Fri, 29 Jan 2010 17:28:20 + From: eamacn...@yahoo.ca Subject: Re: Re : Extracting STDOUT data from USS To: IBM-MAIN@bama.ua.edu At least this is working communication - unlike trying to guess what is meant by 12:00 PM. 12:00 PM is Noon. 12:00 AM is Midnight. Days have 24 hours; why not clocks? Clocks were designed before computers. It's called tradition, and it's a cultural artifact. Most of Europe uses the 24-hour clock, all day long. PS: my BlackBerry is set at 24-hour. - Too busy driving to stop for gas! -- 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 _ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/196390710/direct/01/ -- 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
FW: Re : Extracting STDOUT data from USS
I meant to add that the 24-hour clock can eliminate the abiguity. 00:00 is the midnight that starts the day, 24:00 the one that ends it. Date: Fri, 29 Jan 2010 12:43:49 -0500 From: jayare...@hotmail.com Subject: Re: Re : Extracting STDOUT data from USS To: IBM-MAIN@bama.ua.edu 12:00 PM is Noon. 12:00 AM is Midnight. I don't like it. There's way too much wrong with it. In any case, midnight is ambiguous. Each day has two, one at day's start, the other at day's end. Date: Fri, 29 Jan 2010 17:28:20 + From: eamacn...@yahoo.ca Subject: Re: Re : Extracting STDOUT data from USS To: IBM-MAIN@bama.ua.edu At least this is working communication - unlike trying to guess what is meant by 12:00 PM. 12:00 PM is Noon. 12:00 AM is Midnight. Days have 24 hours; why not clocks? Clocks were designed before computers. It's called tradition, and it's a cultural artifact. Most of Europe uses the 24-hour clock, all day long. PS: my BlackBerry is set at 24-hour. - Too busy driving to stop for gas! _ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/196390710/direct/01/ -- 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: Re : Extracting STDOUT data from USS
On Fri, 29 Jan 2010 17:28:20 +, Ted MacNEIL wrote: At least this is working communication - unlike trying to guess what is meant by 12:00 PM. 12:00 PM is Noon. 12:00 AM is Midnight. Tecnically (will Jonh G. confirm?) Noon is 12:00 M. -- gil -- 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: Extracting STDOUT data from USS
Paul Gilmartin wrote: Why re-invent the wheel? I always thought that this came about because CICS was a DOS app later ported to MVS. This CICS smarts for managing virtual tasks and not really OS waiting until there was absolutely nothing else to do meant that CICS apps got great throughput under an OS which had no such thing as an SRM timer pop. Under DOS, (DOS/VS?) once CICS got dispatched it hogged the CPU until there was no more work left. Perhaps a CICS old timer can say whether this is true or not... ? Cheers, Greg -- 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: Re : Extracting STDOUT data from USS
Gee, you do I/O, you wait ... [snip] Sure. I don't know if there is a CICS service to do I/O to some non-CICS dataset, or if it was simply tolerated. Actually, a wait only affects other transactions in the same CICS region as the will have to wait, too. I remember that in the early releases of OpenEdition / OS/390 UNIX CICS and IMS both stated that they do not allow UNIX services from within transactions because teh waits that could result. No matter whether waits are allowed or tolerated there is big differece between a transaction doing an I/O to some dataset or UNIX file and a transaction doing an I/O to some named pipe. In the later case there is a second *independent* process involved. And this process might run or not when the CICS transacion does its I/O (to the pipe). Long waits may result and this must be acceptable to the transaction's purpose. -- Peter Hunkeler Credit Suisse -- 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: Re : Extracting STDOUT data from USS
In article dc74548a025aff4a85f46926802a9b230412b...@chsa1035.share.beluni.net you wrote: Gee, you do I/O, you wait ... [snip] Sure. I don't know if there is a CICS service to do I/O to some non-CICS dataset, or if it was simply tolerated. Actually, a wait only affects other transactions in the same CICS region as the will have to wait, too. I remember that in the early releases of OpenEdition / OS/390 UNIX CICS and IMS both stated that they do not allow UNIX services from within transactions because teh waits that could result. No matter whether waits are allowed or tolerated there is big differece between a transaction doing an I/O to some dataset or UNIX file and a transaction doing an I/O to some named pipe. In the later case there is a second *independent* process involved. And this process might run or not when the CICS transacion does its I/O (to the pipe). Long waits may result and this must be acceptable to the transaction's purpose. For a while now (5 years or so), you could code your transaction using OTE (Open Transaction Environment.) If a wait is needed, the transaction waits under a special TCB. http://www.zjournal.com/index.cfm?section=articleaid=767 -- Peter Hunkeler Credit Suisse -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- 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: Re : Extracting STDOUT data from USS
On Wed, 27 Jan 2010 13:10:27 +0100, Hunkeler Peter (KIUP 4) peter.hunke...@credit-suisse.com wrote: that CICS transaction must not go into a wait, be it deliberately or as the result of calling a non-CICS service. I think nowadays there is a special queue to put transactions that do incur waits. Quite right. As I said: you're likely not to be alone in your CICS and you should be polite to the others that are in there with you. If you would consider the solution I propose, you will want to go OTE, because your task can indeed get into a long wait when trying to read from a named pipe. A named pipe is different from a standard file in that both ends my become blocked upon a read or write, resp. The reader if there is insufficient data in the pipe, i.e. the reader is faster reading from the pipe than the writer can write into it. The writer if the pipe becomes full, i.e. the writer is faster in writing to the pipe than the reader can read from it. Very true and definitely something to take into account. Cheers, Jantje. -- 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: Re : Extracting STDOUT data from USS
On Thu, 28 Jan 2010 09:02:07 +0100, Hunkeler Peter (KIUP 4) wrote: Gee, you do I/O, you wait ... [snip] Sure. I don't know if there is a CICS service to do I/O to some non-CICS dataset, or if it was simply tolerated. Actually, a wait only affects other transactions in the same CICS region as the will have to wait, too. I remember that in the early releases of OpenEdition / OS/390 UNIX CICS and IMS both stated that they do not allow UNIX services from within transactions because teh waits that could result. My naive understanding of the OS/360 multiprocessing paradigm is that when one unit of work WAITs, another is dispatched. How does CICS manage to subvert this? Why was it ever allowed? What happens when a CICS transaction must do something like: Invalid PIN number; please re-enter ??? Does that spawn a separate transaction? No matter whether waits are allowed or tolerated there is big differece between a transaction doing an I/O to some dataset or UNIX file and a transaction doing an I/O to some named pipe. In the later case there is a second *independent* process involved. And this process might run or not when the CICS transacion does its I/O (to the pipe). Long waits may result and this must be acceptable to the transaction's purpose. Well, there's nonblocking I/O. But what do you do if the pipe isn't ready? -- gil -- 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: Re : Extracting STDOUT data from USS
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Thursday, January 28, 2010 8:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Re : Extracting STDOUT data from USS On Thu, 28 Jan 2010 09:02:07 +0100, Hunkeler Peter (KIUP 4) wrote: Gee, you do I/O, you wait ... [snip] Sure. I don't know if there is a CICS service to do I/O to some non-CICS dataset, or if it was simply tolerated. Actually, a wait only affects other transactions in the same CICS region as the will have to wait, too. I remember that in the early releases of OpenEdition / OS/390 UNIX CICS and IMS both stated that they do not allow UNIX services from within transactions because teh waits that could result. My naive understanding of the OS/360 multiprocessing paradigm is that when one unit of work WAITs, another is dispatched. How does CICS manage to subvert this? Why was it ever allowed? What happens when a CICS transaction must do something like: Invalid PIN number; please re-enter ??? Does that spawn a separate transaction? SNIP CICS required that a transaction NOT cause an OS wait. You used a CICS service (via MACRO or Command level interface) and allowed CICS to schedule those things that could incur a WAIT. So when you did this call to CICS, it would recognize you would need to wait (whether you actually needed to or now, you will now) and then it would go dispatch another transaction that was ready to run. In effect, CICS was making virtual TCBs run using one real TCB, with each virtual TCB being a transaction (pseudo conversational or true conversational). Today, CICS has multiple TCBs to handle different things, but still the MAIN TASK TCB is generally not allowed to incur an OS wait because the whole CICS system may stall as a result. Since Unix System Services (USS for this posting) may incur a WAIT those things are not allowed in a transaction that runs in the main task because of being able to cause the CICS system to stall. IHTH Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer -- -- 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: Re : Extracting STDOUT data from USS
On 28 Jan 2010 07:34:29 -0800, steve_thomp...@stercomm.com (Thompson, Steve) wrote: Invalid PIN number; please re-enter Personal Identification Number Number? At least this is working communication - unlike trying to guess what is meant by 12:00 PM. -- 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: Re : Extracting STDOUT data from USS
What happens when a CICS transaction must do something like: Invalid PIN number; please re-enter ??? Does that spawn a separate transaction? The basic design of transaction managers is that there is a message queue manager which stacks messages until a transaction becomes idle so it can handle the message. The transaction would read one message, process it, and then send a message back to the user (i.e terminal). So the wait for user action is not tied to any running transaction. There is a way to program transactions that is called Wait-For-Input transactions: Once they are finished with one transaction, they don't end but read the next input message from the message queue (which probably comes from another user). IMS was designed to run multiple transaction regions called message processing regions (MPP). Each MPP was running only one transaction at a time. The IMS controller dispatched the correct transaction for the next message to the next free MPP. CICS was originally designed to be a single address space multi user transaction manager. Therefore CICS had multiple tasks running in one region: terminal input / output, queue manager, db access, transaction dispatcher, etc, but there was only one transaction related MVS-task. The CICS transaction dispatcher schedules the transactions for the messages to be worked onto that task one after the other. If an IMS transaction incurs a WAIT, only that MPP was waiting, the other MPPs continued to run. If a CICS transaction incurs a WAIT the whole transaction processing is blocked. CICS has evolved much and is running wiith multiple address spaces and even multiple transaction tasks nowadays. -- Peter Hunkeler Credit Suisse -- 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: Re : Extracting STDOUT data from USS
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Howard Brazee On 28 Jan 2010 07:34:29 -0800, steve_thomp...@stercomm.com (Thompson, Steve) wrote: Invalid PIN number; please re-enter Personal Identification Number Number? Usually seen on an Automated Teller Machine machine; probably at the Department of Redundancy Department. At least this is working communication - unlike trying to guess what is meant by 12:00 PM. Days have 24 hours; why not clocks? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re : Extracting STDOUT data from USS
On Thu, 28 Jan 2010 08:58:24 -0600 Paul Gilmartin paulgboul...@aim.com wrote: :My naive understanding of the OS/360 multiprocessing :paradigm is that when one unit of work WAITs, another :is dispatched. How does CICS manage to subvert this? :Why was it ever allowed? :What happens when a CICS transaction must do something :like: :Invalid PIN number; please re-enter :??? Does that spawn a separate transaction? One issues a CICS wait. With an ECB. That returns control to the CICS dispatcher. -- Binyamin Dissen bdis...@dissensoftware.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re : Extracting STDOUT data from USS
On Tue, 26 Jan 2010 09:33:24 -0600, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 26 Jan 2010 13:15:45 +0100, Hunkeler Peter (KIUP 4) wrote: Create a named pipe and have the writer send its stdout to that pipe. In CICS run a process to read form that named pipe. Prerequisite to this design is that both ends must be active simultaneuosly. Good answer; seems to meet the OP's requirement. (But I don't know CICS; I seem to remember discussions about problems using Unix System Services in CICS.) We have done some tests and found that there is no issue to read and write HFS files from a CICS transactions, using the C library functions for reading and writing files. As a named pipe is just another file, it should work. Obviously, when in CICS, you're not alone... Make sure proper serialization (E C ENQ, E C DEQ) is done. Cheers, Jantje. -- 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: Re : Extracting STDOUT data from USS
Hello Peter, You're correct, I do not want to write to spool .. :-) Kind Regards, Jim Thomas 617-233-4130 (mobile) 636-294-1014 (res) j...@thethomasresidence.us -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hunkeler Peter (KIUP 4) Sent: Wednesday, January 27, 2010 12:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Re : Extracting STDOUT data from USS If the OP actually wants to write to spool, and is not necessarily running under BPXBATCH, he can do: I can't see where the OP ever said he wanted to write to the spool. -- Peter Hunkeler Credit Suisse -- 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.432 / Virus Database: 271.1.1/2638 - Release Date: 01/26/10 19:36:00 -- 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: Re : Extracting STDOUT data from USS
We have done some tests and found that there is no issue to read and write HFS files from a CICS transactions, using the C library functions for reading and writing files. I'm by far anything else than a CICS expert, but I seem to remember that CICS transaction must not go into a wait, be it deliberately or as the result of calling a non-CICS service. I think nowadays there is a special queue to put transactions that do incur waits. As a named pipe is just another file, it should work. A named pipe is different from a standard file in that both ends my become blocked upon a read or write, resp. The reader if there is insufficient data in the pipe, i.e. the reader is faster reading from the pipe than the writer can write into it. The writer if the pipe becomes full, i.e. the writer is faster in writing to the pipe than the reader can read from it. I'm not saying that to be an inhibitor but this fact has to be taken into account. -- Peter Hunkeler Credit Suisse -- 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: Re : Extracting STDOUT data from USS
On Wed, 27 Jan 2010 13:10:27 +0100, Hunkeler Peter (KIUP 4) wrote: I'm by far anything else than a CICS expert, but I seem to remember that CICS transaction must not go into a wait, be it deliberately or as the result of calling a non-CICS service. I think nowadays there is a special queue to put transactions that do incur waits. Gee, you do I/O, you wait (or the access method waits) until the DECB gets posted. I suppose CICS might bypass access methods and do STARTIO directly ... I drifted into spool after Jim Thomas's earliest ply yesterday (but the Subject: started Re:) mentioned writer, which I took to be JES terminology. -- gil -- 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: Re : Extracting STDOUT data from USS
My apologies Gil, I meant an external writer. Kind Regards, Jim Thomas 617-233-4130 (mobile) 636-294-1014 (res) j...@thethomasresidence.us -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Wednesday, January 27, 2010 11:37 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Re : Extracting STDOUT data from USS On Wed, 27 Jan 2010 13:10:27 +0100, Hunkeler Peter (KIUP 4) wrote: I'm by far anything else than a CICS expert, but I seem to remember that CICS transaction must not go into a wait, be it deliberately or as the result of calling a non-CICS service. I think nowadays there is a special queue to put transactions that do incur waits. Gee, you do I/O, you wait (or the access method waits) until the DECB gets posted. I suppose CICS might bypass access methods and do STARTIO directly ... I drifted into spool after Jim Thomas's earliest ply yesterday (but the Subject: started Re:) mentioned writer, which I took to be JES terminology. -- gil -- 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.432 / Virus Database: 271.1.1/2647 - Release Date: 01/27/10 13:08:00 -- 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: Re : Extracting STDOUT data from USS
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jim Thomas Sent: Wednesday, January 27, 2010 12:30 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Re : Extracting STDOUT data from USS My apologies Gil, I meant an external writer. Kind Regards, Jim Thomas The term external writer will likely imply SPOOL access too as there is such a thing in JES2. It is external to JES2 and is a writer of SPOOL to other media, such as sequential disk or tape. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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 : Extracting STDOUT data from USS
Top of the morning to everybody, I'm looking for some direction and advice on dynamically extracting STDOUT data from USS that I can feed into a CICS sub-system. Would a writer / listener be the right direction ?. How would I extract the STDOUT data ?. Could BPXWDYN be used ?. I'd prefer to have each record (as it were) be sent to my subsystem as it's written (or immediately thereafter). Any thoughts and or advice would be greatly appreciated. Kind Regards, Jim Thomas 617-233-4130 (mobile) 636-294-1014 (res) j...@thethomasresidence.us -- 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: Re : Extracting STDOUT data from USS
I'm looking for some direction From j...@thethomasresidence.us I'm looking for some direction and advice on dynamically extracting STDOUT data from USS that I can feed into a CICS sub-system. Would a writer / listener be the right direction ?. How would I extract the STDOUT data ?. Could BPXWDYN be used ?. Maybe I am misundertanding you, but IIRC STDOUT can be written to datasets ever since z/OS 1.5. Why would you want to write it to the spool first ? Which z/OS level are you at ? Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- 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: Re : Extracting STDOUT data from USS
I'm looking for some direction and advice on dynamically extracting STDOUT data from USS that I can feed into a CICS sub-system. Would a writer / listener be the right direction ?. How would I extract the STDOUT data ?. Create a named pipe and have the writer send its stdout to that pipe. In CICS run a process to read form that named pipe. Prerequisite to this design is that both ends must be active simultaneuosly. -- Peter Hunkeler Credit Suisse -- 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: Re : Extracting STDOUT data from USS
On Tue, 26 Jan 2010 13:15:45 +0100, Hunkeler Peter (KIUP 4) wrote: I'm looking for some direction and advice on dynamically extracting STDOUT data from USS that I can feed into a CICS sub-system. Would a writer / listener be the right direction ?. How would I extract the STDOUT data ?. Create a named pipe and have the writer send its stdout to that pipe. In CICS run a process to read form that named pipe. Prerequisite to this design is that both ends must be active simultaneuosly. Good answer; seems to meet the OP's requirement. (But I don't know CICS; I seem to remember discussions about problems using Unix System Services in CICS.) If the OP actually wants to write to spool, and is not necessarily running under BPXBATCH, he can do: Some-command | Rexx-EXEC where Rexx-EXEC (actually any language) allocates SYSUT1 to /dev/fd/0 and SYSUT2 to SYSOUT, then LINKMVS IEBGENER. For writing to a catalogued data set, it's easier: Some-command | cp /dev/fd/0 //'DATA.SET.NAME' -- gil -- 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: Re : Extracting STDOUT data from USS
Peter / Gil .. thank you for your advice. Kind Regards, Jim Thomas 617-233-4130 (mobile) 636-294-1014 (res) j...@thethomasresidence.us -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Tuesday, January 26, 2010 9:33 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Re : Extracting STDOUT data from USS On Tue, 26 Jan 2010 13:15:45 +0100, Hunkeler Peter (KIUP 4) wrote: I'm looking for some direction and advice on dynamically extracting STDOUT data from USS that I can feed into a CICS sub-system. Would a writer / listener be the right direction ?. How would I extract the STDOUT data ?. Create a named pipe and have the writer send its stdout to that pipe. In CICS run a process to read form that named pipe. Prerequisite to this design is that both ends must be active simultaneuosly. Good answer; seems to meet the OP's requirement. (But I don't know CICS; I seem to remember discussions about problems using Unix System Services in CICS.) If the OP actually wants to write to spool, and is not necessarily running under BPXBATCH, he can do: Some-command | Rexx-EXEC where Rexx-EXEC (actually any language) allocates SYSUT1 to /dev/fd/0 and SYSUT2 to SYSOUT, then LINKMVS IEBGENER. For writing to a catalogued data set, it's easier: Some-command | cp /dev/fd/0 //'DATA.SET.NAME' -- gil -- 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.432 / Virus Database: 271.1.1/2638 - Release Date: 01/26/10 07:46:00 -- 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: Re : Extracting STDOUT data from USS
If the OP actually wants to write to spool, and is not necessarily running under BPXBATCH, he can do: I can't see where the OP ever said he wanted to write to the spool. -- Peter Hunkeler Credit Suisse -- 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
