Re: SMP/E in TSO (was: Why AUTHPGM?)

On 2/4/2007 4:53 PM, Paul Gilmartin wrote: On Sat, 4 Nov 2006 09:16:44 -0500, Gilbert Saint-Flour wrote: The system closes DCBs at end-of-task. You and IBM are in agreement, at least insofar as this should happen; they've taken APAR OA19801 for a case where it doesn't. Interesting -- the APAR

Re: SMP/E in TSO (was: Why AUTHPGM?)

On Sat, 4 Nov 2006 09:16:44 -0500, Gilbert Saint-Flour wrote: > > The system closes DCBs at end-of-task. > You and IBM are in agreement, at least insofar as this should happen; they've taken APAR OA19801 for a case where it doesn't. Interesting -- the APAR seems to say that an attempt is made to

Re: SMP/E in TSO (was: Why AUTHPGM?)

On Mon, 6 Nov 2006 12:33:13 -0500, Gilbert Saint-Flour wrote: > > A task doesn't own a DCB per se, but DEBs created by OPEN are placed on a > chain anchored in the TCBDEB field of the TCB under which OPEN is invoked. > > When a task terminates, the Task Close routine (IFGxTCx IIRC) runs the DEB >

[SPAM] Re: SMP/E in TSO (was: Why AUTHPGM?)

In <[EMAIL PROTECTED]>, on 11/22/2006 at 12:33 PM, Paul Gilmartin said: >To get Rexx out of the picture, >I simply put >CALL *(GIMSMP) 'PROCESS=WAIT' >in my SYSTSIN. Did you consider using CLIST? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see

Re: SMP/E in TSO (was: Why AUTHPGM?)

In a recent note, Gilbert Saint-Flour said: > Date: Sat, 4 Nov 2006 09:16:44 -0500 > > The system closes DCBs at end-of-task. > I believe I have a fairly concise test case that shows DCBs failing to be closed properly when Binder ABENDs with Sx37. No SMP/E; no AUTHPGM manipulations requi

Re: SMP/E in TSO (was: Why AUTHPGM?)

On Wed, 22 Nov 2006 11:09:09 -0600, Brian Peterson <[EMAIL PROTECTED]> wrote: > > I would suggest reporting this problem against the TSO/E CALL command under > component 566528502. The CALL command is acting differently than PGM= in > JCL. > Thanks. I guess the best argument I can make in suppo

Re: SMP/E in TSO (was: Why AUTHPGM?)

I would suggest reporting this problem against the TSO/E CALL command under component 566528502. The CALL command is acting differently than PGM= in JCL. Brian On Wed, 22 Nov 2006 08:25:35 -0700, Paul Gilmartin wrote: >But in SYSTSPRT: > > >>> "call *(GIMSMP) 'PROCESS=WAIT'"

SMP/E in TSO (was: Why AUTHPGM?)

In a recent note, Walt Farrell said: > Date: Tue, 19 Sep 2006 14:00:51 -0400 > > It is, in fact, likely that if a program were to cause an integrity > problem when run in TSO that it would also cause an exposure when run in > batch. However, I can envision some odd kinds of effects that

Re: SMP/E in TSO (was: Why AUTHPGM?)

In a recent note, Ted MacNEIL said: > Date: Thu, 9 Nov 2006 06:15:18 + > > >If a DCB/ACB is inaccessible or appears corrupted, then TC issues IDC999I > >and S0 > C3. > > ITYM SC03. > > (Considering I'm chasing one right now). > What triggers the CLOSE when the DDNAME is allocated

Re: SMP/E in TSO (was: Why AUTHPGM?)

>If a DCB/ACB is inaccessible or appears corrupted, then TC issues IDC999I and >S0C3. ITYM SC03. (Considering I'm chasing one right now). When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access inst

Re: SMP/E in TSO (was: Why AUTHPGM?)

In a recent note, Gilbert Saint-Flour said: > Date: Mon, 6 Nov 2006 12:33:13 -0500 > > When a task terminates, the Task Close routine (IFGxTCx IIRC) runs the DEB > chain and tries to close corresponding DCBs and ACBs. If a DCB/ACB is > inaccessible or appears corrupted, then TC issues ID

Re: SMP/E in TSO (was: Why AUTHPGM?)

In a recent note, Gilbert Saint-Flour said: > Date: Mon, 6 Nov 2006 12:33:13 -0500 > > When a task terminates, the Task Close routine (IFGxTCx IIRC) runs the DEB > chain and tries to close corresponding DCBs and ACBs. If a DCB/ACB is > inaccessible or appears corrupted, then TC issues ID

Re: SMP/E in TSO (was: Why AUTHPGM?)

Paul Gilmartin wrote: >> The system closes DCBs at end-of-task. >> > I had been unaware of such task ownership of DCBs.   > But I suspect that somehow SMP/E (or perhaps IEBCOPY) > is completing without closing some DCB.   A task doesn't own a DCB per se, but DEBs created by OPEN are placed on

Re: SMP/E in TSO (was: Why AUTHPGM?)

Rats! New terminal emulator -- I keep fumbling things into the list. In a recent note, Gilbert Saint-Flour said: > Date: Sat, 4 Nov 2006 09:16:44 -0500 > > The system closes DCBs at end-of-task. > I had been unaware of such task ownership of DCBs. I bow to your expertise. But I susp

Re: SMP/E in TSO (was: Why AUTHPGM?)

t;[EMAIL PROTECTED]> > Organization: GSF Software > Subject: Re: SMP/E in TSO (was: Why AUTHPGM?) > Content-Type: text/plain; charset="us-ascii" > Content-Disposition: inline > > Paul Gilmartin wrote: > > I prevailed on our sysprog to add GIMSMP to AUTHPGM. > &

Re: SMP/E in TSO (was: Why AUTHPGM?)

Paul Gilmartin wrote: > I prevailed on our sysprog to add GIMSMP to AUTHPGM. > This helped lots of things when I run SMP/E from an EXEC: (...) > I suppose I could try to "SYSCALL spawn" SMP/E into a separate address > space -- the DCB's should be closed at end-of-memory, shouldn't they? > But

SMP/E in TSO (was: Why AUTHPGM?)

On Tue, 19 Sep 2006 13:40:58 -0300, Shmuel Metz (Seymour J.) <[EMAIL PROTECTED]> wrote: > > In <[EMAIL PROTECTED]>, on 09/19/2006 >at 10:34 AM, Binyamin Dissen <[EMAIL PROTECTED]> said: > > >The issue is that AC=1 programs expect to be called as job-step > >programs and may not completely cl