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 CI
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
In , on 01/27/2010
at 11:36 AM, Paul Gilmartin 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 th
In <05c701ca9e76$66eb0bd0$34c123...@us>, on 01/26/2010
at 04:57 AM, Jim Thomas 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 considerat
In , on 01/28/2010
at 08:58 AM, Paul Gilmartin 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 mi
In , on 01/29/2010
at 07:58 AM, Paul Gilmartin 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
wi
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 C
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
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
-
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
00
> 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.
>
>> 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-ho
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 v
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen
>
> On Thu, 28 Jan 2010 08:58:24 -0600 Paul Gilmartin
> wrote:
>
> :>My naive understanding of the OS/360 multiprocessing
> :>paradigm is that when one unit of work WAITs, another
> :>is dispatched.
Relating this back to the OP's question, it seems to me that this
approach might work:
- A Unix process could be writing output to a named pipe.
- A CICS task could use BPX1SEL (select) and BPX1RED to read from the pipe.
- A CICS wait can be used with BPX1SEL's ECB to prevent blocking.
Kirk Wolf
On Thu, 28 Jan 2010 08:58:24 -0600 Paul Gilmartin
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 d
> -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 Auto
>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 c
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.
-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
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
On Wed, 27 Jan 2010 13:10:27 +0100, Hunkeler Peter (KIUP 4)
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'r
In article
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 remembe
>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 Op
> -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,
, 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
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
>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
keler 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
On Tue, 26 Jan 2010 09:33:24 -0600, Paul Gilmartin
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
>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 subscrib
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
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
> 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 sen
> I'm looking for some direction
> From
> 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 ?
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
36 matches
Mail list logo
