Re: IKJTSOEV & ISPF services question

2012-05-25 Thread Shmuel Metz (Seymour J.) 
In <1356750482717750.wa.paulgboulderaim@bama.ua.edu>, on
05/25/2012
   at 08:54 AM, Paul Gilmartin  said:

>(This might be more on-charter for ISPF-L.)

Anything on-topic for ISPF-L is on topic here. However, if there are
any ISPF gurus who don't subscribe to IBM-MAIN then it might be
worthwhile trying both.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: INFO IBM-MAIN

Re: IKJTSOEV & ISPF services question

2012-05-25 Thread Shmuel Metz (Seymour J.) 
In ,
on 05/25/2012
   at 10:23 AM, "McKown, John"  said:

>From my view point, it is because the user of my program simply does
>EXEC PGM=MYPGM rather than PGM=IKJEFT01,PARM='%MYPGM' which runs a,
>in my case, REXX program called MYPGM, which then does the TSO
>allocates for the ISPF datasets, followed by ISPSTART CMD(%MYPGM2).
>Which is either a TSO command, or another REXX program which does a
>TSO CALL to actually invoke the processing program. All that
>"overhead" just so that my program can, for instance, use a DSINFO to
>__easily__ get a list of cataloged datasets and their attributes.

I don't see anything there that you wouldn't also have to do if you
used IKJTSOEV.

>Again, what I really would like is something like the ISPF services
>(non DISPLAY). 

CSI is available from COBOL.

>But make them available via a simple COBOL CALL verb without the
>need for the "complicated" JCL and REXX layers.

Are you putting "complicated" in quotes because you agree that it is
*not* complicated? ;-)

>This would allow a COBOL program to easily allocate and "open" a
>PDS, get a list of the members, and then read one or more of the
>members.

A COBOL program can already do those.

>Or use DSINFO for some DASD management reports.

If you want to use the services of an application then you have to set
up the environment of that application.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: INFO IBM-MAIN

Re: IKJTSOEV & ISPF services question

2012-05-25 Thread Walt Farrell 
On Fri, 25 May 2012 13:59:37 -0500, McKown, John 
 wrote:

>Very good. Thanks much, Walt.
>
>Now to "encapsulate" that functionality in a subroutine. And, horrible person 
>that I am, my subroutine will be in HLASM and packaged as an LE enabled DLL so 
>I can use it in my UNIX programs.
>

I don't think it's amenable to coding as a subroutine, John. At least not using 
ATTACH. And even without using ATTACH I'm not sure I see a good way to run 
multiple service calls to ISPF.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: IKJTSOEV & ISPF services question

2012-05-25 Thread McKown, John 
Very good. Thanks much, Walt.

Now to "encapsulate" that functionality in a subroutine. And, horrible person 
that I am, my subroutine will be in HLASM and packaged as an LE enabled DLL so 
I can use it in my UNIX programs.

-- 
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
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


> As others have noted, you have to be "under" ISPF to use ISPF 
> services. But you should be able to start ISPF from your 
> program once it's setup a TSO environment using IKJTSOEV.
> 
> So you might consider:
> 
> (a) Invoking IKJTSOEV
> (b) Using IDENTIFY to create an "alias" (say, for example, 
> XYZ) for an address within your program
> (c) Invoking ISPSTART (with an appropriate CPPL, etc.) and 
> telling it to invoke XYZ. I'd probably ATTACH it, for safety.
> 
> At that point, the rest of your code, starting at the XYZ 
> address, is "under" ISPF.
> 
> -- 
> Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: IKJTSOEV & ISPF services question

2012-05-25 Thread Walt Farrell 
On Fri, 25 May 2012 07:44:31 -0500, McKown, John 
 wrote:

>I know that I can run the TSO TMP in batch. Using this, I can run a REXX 
>program which sets up all the ISPF required datasets. I can then invoke 
>ISPSTART with the CMD(...) option to run another program/CLIST/REXX. In that 
>program, I can use most of the non-DISPLAY oriented services, such as DIRLIST 
>or DSINFO. The TSO book on IKJTSOEV only talks about ISPF in the negative, but 
>mentions display services. So, can I write a batch program which uses IKJTSOEV 
>to set up a TSO environment. Once I have a TSO environment set, can I directly 
>invoke ISPF services?
>
>What I would like to do is to have some simple way in a batch program to 
>invoke ISPF services such as DSINFO without the "hokeyness" of running the TSO 
>TMP. And also without invoking ISPSTART and telling it to run a separate 
>program/CLIST/REXX routine. But I don't think it's possible. Frustrates me no 
>end.
>

As others have noted, you have to be "under" ISPF to use ISPF services. But you 
should be able to start ISPF from your program once it's setup a TSO 
environment using IKJTSOEV.

So you might consider:

(a) Invoking IKJTSOEV
(b) Using IDENTIFY to create an "alias" (say, for example, XYZ) for an address 
within your program
(c) Invoking ISPSTART (with an appropriate CPPL, etc.) and telling it to invoke 
XYZ. I'd probably ATTACH it, for safety.

At that point, the rest of your code, starting at the XYZ address, is "under" 
ISPF.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: IKJTSOEV & ISPF services question

2012-05-25 Thread Farley, Peter x23353 
Thank you.  That link was very helpful.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Gord Tomlin
Sent: Friday, May 25, 2012 12:51 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IKJTSOEV & ISPF services question

Sorry, it stands for model/view/controller, and it is a widely used 
design pattern for decoupling the logic of a program from the 
presentation of its inputs and outputs. The basic idea is that you can 
reuse the program that does the actual work in different scenarios, 
because that program is not wedded to a particular presentation layer.

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-05-25 12:16, Farley, Peter x23353 wrote:
> I've never seen this term before now -- "MVC design pattern"???  What is that 
> please?  I'm guessing it is not "MoVe Character" design pattern.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Gord Tomlin
> Sent: Friday, May 25, 2012 12:12 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IKJTSOEV&  ISPF services question
>
> Unfortunately, ISPF significantly predates the MVC design pattern.
>
> --
>
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
>
> On 2012-05-25 11:23, McKown, John wrote:
>>>  From my view point, it is because the user of my program simply does EXEC 
>>> PGM=MYPGM rather than PGM=IKJEFT01,PARM='%MYPGM' which runs a, in my case, 
>>> REXX program called MYPGM, which then does the TSO allocates for the ISPF 
>>> datasets, followed by ISPSTART CMD(%MYPGM2). Which is either a TSO command, 
>>> or another REXX program which does a TSO CALL to actually invoke the 
>>> processing program. All that "overhead" just so that my program can, for 
>>> instance, use a DSINFO to __easily__ get a list of cataloged datasets and 
>>> their attributes.
>>
>> Again, what I really would like is something like the ISPF services (non 
>> DISPLAY). But make them available via a simple COBOL CALL verb without the 
>> need for the "complicated" JCL and REXX layers. This would allow a COBOL 
>> program to easily allocate and "open" a PDS, get a list of the members, and 
>> then read one or more of the members. All in a relatively simple, easy to 
>> use, way. The same with z/OS UNIX files too. Or use DSINFO for some DASD 
>> management reports.
>>
>> I guess it's just a recent "itch" of mine. Not possible as I would like to 
>> do it, so I'm just stuck with the "clumsy" (IMO) way.
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: IKJTSOEV & ISPF services question

2012-05-25 Thread Gord Tomlin 
Sorry, it stands for model/view/controller, and it is a widely used 
design pattern for decoupling the logic of a program from the 
presentation of its inputs and outputs. The basic idea is that you can 
reuse the program that does the actual work in different scenarios, 
because that program is not wedded to a particular presentation layer.


https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-05-25 12:16, Farley, Peter x23353 wrote:

I've never seen this term before now -- "MVC design pattern"???  What is that please?  
I'm guessing it is not "MoVe Character" design pattern.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Gord Tomlin
Sent: Friday, May 25, 2012 12:12 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IKJTSOEV&  ISPF services question

Unfortunately, ISPF significantly predates the MVC design pattern.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-05-25 11:23, McKown, John wrote:

 From my view point, it is because the user of my program simply does EXEC PGM=MYPGM 
rather than PGM=IKJEFT01,PARM='%MYPGM' which runs a, in my case, REXX program called 
MYPGM, which then does the TSO allocates for the ISPF datasets, followed by ISPSTART 
CMD(%MYPGM2). Which is either a TSO command, or another REXX program which does a TSO 
CALL to actually invoke the processing program. All that "overhead" just so 
that my program can, for instance, use a DSINFO to __easily__ get a list of cataloged 
datasets and their attributes.


Again, what I really would like is something like the ISPF services (non DISPLAY). But make them 
available via a simple COBOL CALL verb without the need for the "complicated" JCL and 
REXX layers. This would allow a COBOL program to easily allocate and "open" a PDS, get a 
list of the members, and then read one or more of the members. All in a relatively simple, easy to 
use, way. The same with z/OS UNIX files too. Or use DSINFO for some DASD management reports.

I guess it's just a recent "itch" of mine. Not possible as I would like to do it, so I'm 
just stuck with the "clumsy" (IMO) way.

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: IKJTSOEV & ISPF services question

2012-05-25 Thread Farley, Peter x23353 
I've never seen this term before now -- "MVC design pattern"???  What is that 
please?  I'm guessing it is not "MoVe Character" design pattern.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Gord Tomlin
Sent: Friday, May 25, 2012 12:12 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IKJTSOEV & ISPF services question

Unfortunately, ISPF significantly predates the MVC design pattern.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-05-25 11:23, McKown, John wrote:
>> From my view point, it is because the user of my program simply does EXEC 
>> PGM=MYPGM rather than PGM=IKJEFT01,PARM='%MYPGM' which runs a, in my case, 
>> REXX program called MYPGM, which then does the TSO allocates for the ISPF 
>> datasets, followed by ISPSTART CMD(%MYPGM2). Which is either a TSO command, 
>> or another REXX program which does a TSO CALL to actually invoke the 
>> processing program. All that "overhead" just so that my program can, for 
>> instance, use a DSINFO to __easily__ get a list of cataloged datasets and 
>> their attributes.
>
> Again, what I really would like is something like the ISPF services (non 
> DISPLAY). But make them available via a simple COBOL CALL verb without the 
> need for the "complicated" JCL and REXX layers. This would allow a COBOL 
> program to easily allocate and "open" a PDS, get a list of the members, and 
> then read one or more of the members. All in a relatively simple, easy to 
> use, way. The same with z/OS UNIX files too. Or use DSINFO for some DASD 
> management reports.
>
> I guess it's just a recent "itch" of mine. Not possible as I would like to do 
> it, so I'm just stuck with the "clumsy" (IMO) way.
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: IKJTSOEV & ISPF services question

2012-05-25 Thread Gord Tomlin 

Unfortunately, ISPF significantly predates the MVC design pattern.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-05-25 11:23, McKown, John wrote:

From my view point, it is because the user of my program simply does EXEC PGM=MYPGM 
rather than PGM=IKJEFT01,PARM='%MYPGM' which runs a, in my case, REXX program called 
MYPGM, which then does the TSO allocates for the ISPF datasets, followed by ISPSTART 
CMD(%MYPGM2). Which is either a TSO command, or another REXX program which does a TSO 
CALL to actually invoke the processing program. All that "overhead" just so 
that my program can, for instance, use a DSINFO to __easily__ get a list of cataloged 
datasets and their attributes.


Again, what I really would like is something like the ISPF services (non DISPLAY). But make them 
available via a simple COBOL CALL verb without the need for the "complicated" JCL and 
REXX layers. This would allow a COBOL program to easily allocate and "open" a PDS, get a 
list of the members, and then read one or more of the members. All in a relatively simple, easy to 
use, way. The same with z/OS UNIX files too. Or use DSINFO for some DASD management reports.

I guess it's just a recent "itch" of mine. Not possible as I would like to do it, so I'm 
just stuck with the "clumsy" (IMO) way.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: IKJTSOEV & ISPF services question

2012-05-25 Thread McKown, John 
>From my view point, it is because the user of my program simply does EXEC 
>PGM=MYPGM rather than PGM=IKJEFT01,PARM='%MYPGM' which runs a, in my case, 
>REXX program called MYPGM, which then does the TSO allocates for the ISPF 
>datasets, followed by ISPSTART CMD(%MYPGM2). Which is either a TSO command, or 
>another REXX program which does a TSO CALL to actually invoke the processing 
>program. All that "overhead" just so that my program can, for instance, use a 
>DSINFO to __easily__ get a list of cataloged datasets and their attributes.

Again, what I really would like is something like the ISPF services (non 
DISPLAY). But make them available via a simple COBOL CALL verb without the need 
for the "complicated" JCL and REXX layers. This would allow a COBOL program to 
easily allocate and "open" a PDS, get a list of the members, and then read one 
or more of the members. All in a relatively simple, easy to use, way. The same 
with z/OS UNIX files too. Or use DSINFO for some DASD management reports.

I guess it's just a recent "itch" of mine. Not possible as I would like to do 
it, so I'm just stuck with the "clumsy" (IMO) way.

-- 
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
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

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Friday, May 25, 2012 8:16 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: IKJTSOEV & ISPF services question
> 
> In ,
> on 05/25/2012
>at 07:44 AM, "McKown, John"  said:
> 
> >I know that I can run the TSO TMP in batch. Using this, I can run a
> >REXX program which sets up all the ISPF required datasets. I can then
> >invoke ISPSTART with the CMD(...) option to run another
> >program/CLIST/REXX. In that program, I can use most of the
> >non-DISPLAY oriented services, such as DIRLIST or DSINFO. The TSO
> >book on IKJTSOEV only talks about ISPF in the negative, but 
> >mentions display services. So, can I write a batch program which 
> >uses IKJTSOEV to set up a TSO environment. Once I have a TSO 
> >environment set, can I directly invoke ISPF services?
> 
> No. ISPF services are only available for applications running under
> ISPF. 
> 
> The good news is that ISPF display services are available in batch if
> you connect to the WSA on a PC.
> 
> >What I would like to do is to have some simple way in a batch
> >program to invoke ISPF services such as DSINFO without the
> >"hokeyness" of running the TSO TMP. 
> 
> Why isn't IKJTSOEV just as hokey?
>  
> -- 
>  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: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: IKJTSOEV & ISPF services question

2012-05-25 Thread Shmuel Metz (Seymour J.) 
In ,
on 05/25/2012
   at 07:44 AM, "McKown, John"  said:

>I know that I can run the TSO TMP in batch. Using this, I can run a
>REXX program which sets up all the ISPF required datasets. I can then
>invoke ISPSTART with the CMD(...) option to run another
>program/CLIST/REXX. In that program, I can use most of the
>non-DISPLAY oriented services, such as DIRLIST or DSINFO. The TSO
>book on IKJTSOEV only talks about ISPF in the negative, but 
>mentions display services. So, can I write a batch program which 
>uses IKJTSOEV to set up a TSO environment. Once I have a TSO 
>environment set, can I directly invoke ISPF services?

No. ISPF services are only available for applications running under
ISPF. 

The good news is that ISPF display services are available in batch if
you connect to the WSA on a PC.

>What I would like to do is to have some simple way in a batch
>program to invoke ISPF services such as DSINFO without the
>"hokeyness" of running the TSO TMP. 

Why isn't IKJTSOEV just as hokey?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: INFO IBM-MAIN

Re: IKJTSOEV & ISPF services question

2012-05-25 Thread Paul Gilmartin 
On Fri, 25 May 2012 07:44:31 -0500, McKown, John wrote:

>I know that I can run the TSO TMP in batch. Using this, I can run a REXX 
>program which sets up all the ISPF required datasets. I can then invoke 
>ISPSTART with the CMD(...) option to run another program/CLIST/REXX. In that 
>program, I can use most of the non-DISPLAY oriented services, such as DIRLIST 
>or DSINFO. The TSO book on IKJTSOEV only talks about ISPF in the negative, but 
>mentions display services. So, can I write a batch program which uses IKJTSOEV 
>to set up a TSO environment. Once I have a TSO environment set, can I directly 
>invoke ISPF services?
>
>What I would like to do is to have some simple way in a batch program to 
>invoke ISPF services such as DSINFO without the "hokeyness" of running the TSO 
>TMP. And also without invoking ISPSTART and telling it to run a separate 
>program/CLIST/REXX routine. But I don't think it's possible. Frustrates me no 
>end.
> 
I would say, "If it ain't broke, don't fix it."  Except it is broke.  Syntactic
restrictions of the CMD(...) option prohibit my passing certain PARM
strings to my program/CLIST/REXX routine that I could readily specify
if I invoked it directly from the command line.  Bummer.

(This might be more on-charter for ISPF-L.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

IKJTSOEV & ISPF services question

2012-05-25 Thread McKown, John 
I know that I can run the TSO TMP in batch. Using this, I can run a REXX 
program which sets up all the ISPF required datasets. I can then invoke 
ISPSTART with the CMD(...) option to run another program/CLIST/REXX. In that 
program, I can use most of the non-DISPLAY oriented services, such as DIRLIST 
or DSINFO. The TSO book on IKJTSOEV only talks about ISPF in the negative, but 
mentions display services. So, can I write a batch program which uses IKJTSOEV 
to set up a TSO environment. Once I have a TSO environment set, can I directly 
invoke ISPF services?

What I would like to do is to have some simple way in a batch program to invoke 
ISPF services such as DSINFO without the "hokeyness" of running the TSO TMP. 
And also without invoking ISPSTART and telling it to run a separate 
program/CLIST/REXX routine. But I don't think it's possible. Frustrates me no 
end.


John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
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: INFO IBM-MAIN