Discussion:
Standard REXX Stream I/O on MVS/TSO
(too old to reply)
Cruz, Robert
2007-06-20 22:38:52 UTC
Permalink
I am interested to know how many of you have installed the IBM MVS REXX
Stream I/O package**,
and how many of you are using it.

For those who are using it, I would appreciate learning of your
experiences:
- has there been much adoption of it (to replace EXECIO)?
- has it improved the portability of your REXX programs?
- what have your experiences (good or bad) with it been?

Thank you for your support.


** you know, LINEIN(), LINEOUT(), CHARIN(), CHAROUT() and STREAM()

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Paul Gilmartin
2007-06-25 20:00:22 UTC
Permalink
In a recent note, Cruz, Robert said:

> Date: Wed, 20 Jun 2007 15:38:42 -0700
>
> I am interested to know how many of you have installed the IBM MVS REXX
> Stream I/O package**,
> and how many of you are using it.
>
> For those who are using it, I would appreciate learning of your
> experiences:
> - has there been much adoption of it (to replace EXECIO)?
> - has it improved the portability of your REXX programs?
> - what have your experiences (good or bad) with it been?
>
Among the dismaying facts:

o This competes and is incompatible with the identically
named functions available when Rexx is invoked under
Unix System Services. I believe one accesses UNIX files;
the other Classic data sets; you can't get to both from
a single EXEC. A suitably enhanced STREAM() could have
made this possible.

o I don't believe either version provides SIGNAL ON NOTREADY,
part of Cowlishaw's original specification.

Conway's law strikes again.

> ** you know, LINEIN(), LINEOUT(), CHARIN(), CHAROUT() and STREAM()
>
And LINES() and CHARS()?

-- gil
--
StorageTek
INFORMATION made POWERFUL

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Cruz, Robert
2007-06-27 16:12:09 UTC
Permalink
Thank you for your reply, it was quite informative. Hopefully, IBM will
soon address this in a uniform, consistent, and standards-conforming
manner, rather than this piecemeal approach.

P.S. CHARS() and LINES() are included, but not, as you point out, NOT
READY.

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf
Of Paul Gilmartin
Sent: Mon 25 Jun 2007 12:53
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Standard REXX Stream I/O on MVS/TSO


In a recent note, Cruz, Robert said:

> Date: Wed, 20 Jun 2007 15:38:42 -0700
>
> I am interested to know how many of you have installed the IBM MVS
> REXX Stream I/O package**, and how many of you are using it.
>
> For those who are using it, I would appreciate learning of your
> experiences:
> - has there been much adoption of it (to replace EXECIO)?
> - has it improved the portability of your REXX programs?
> - what have your experiences (good or bad) with it been?
>
Among the dismaying facts:

o This competes and is incompatible with the identically
named functions available when Rexx is invoked under
Unix System Services. I believe one accesses UNIX files;
the other Classic data sets; you can't get to both from
a single EXEC. A suitably enhanced STREAM() could have
made this possible.

o I don't believe either version provides SIGNAL ON NOTREADY,
part of Cowlishaw's original specification.

Conway's law strikes again.

> ** you know, LINEIN(), LINEOUT(), CHARIN(), CHAROUT() and STREAM()
>
And LINES() and CHARS()?

-- gil
--
StorageTek
INFORMATION made POWERFUL

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions, send
email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Paul Gilmartin
2007-06-27 18:47:34 UTC
Permalink
<<< No Message Collected >>>

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Paul Gilmartin
2007-06-27 18:54:23 UTC
Permalink
In a recent note, Cruz, Robert said:

> Date: Wed, 27 Jun 2007 09:11:50 -0700
>
> Thank you for your reply, it was quite informative. Hopefully, IBM will
> soon address this in a uniform, consistent, and standards-conforming
> manner, rather than this piecemeal approach.
>
Don't hold your breath.

> P.S. CHARS() and LINES() are included, but not, as you point out, NOT
> READY.
>
But VM/CMS has SIGNAL ON NOTREADY. The same vendor; originally
the same source code. How can they do so poorly?

> -----Original Message-----
> In a recent note, Cruz, Robert said:
>
> > Date: Wed, 20 Jun 2007 15:38:42 -0700
> >
> > I am interested to know how many of you have installed the IBM MVS
> > REXX Stream I/O package**, and how many of you are using it.
>
> o This competes and is incompatible with the identically
> named functions available when Rexx is invoked under
> Unix System Services. I believe one accesses UNIX files;
> the other Classic data sets; you can't get to both from
> a single EXEC. A suitably enhanced STREAM() could have
> made this possible.
>
> o I don't believe either version provides SIGNAL ON NOTREADY,
> part of Cowlishaw's original specification.
>
> Conway's law strikes again.

-- gil
--
StorageTek
INFORMATION made POWERFUL

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Cruz, Robert
2007-06-27 18:59:57 UTC
Permalink
"originally the same source code"

Yes, but that was back when VM/CMS used EXECIO. The standard-compliant
I/O was added long after the fork in the source between VM and MVS
occurred. As a result, I don't expect improvements in one
implementation of REXX to quickly become part of the other, especially
platform-specific stuff like I/O.

Oh well...

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf
Of Paul Gilmartin
Sent: Wed 27 Jun 2007 11:22
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Standard REXX Stream I/O on MVS/TSO


In a recent note, Cruz, Robert said:

> Date: Wed, 27 Jun 2007 09:11:50 -0700
>
> Thank you for your reply, it was quite informative. Hopefully, IBM
> will soon address this in a uniform, consistent, and
> standards-conforming manner, rather than this piecemeal approach.
>
Don't hold your breath.

> P.S. CHARS() and LINES() are included, but not, as you point out, NOT

> READY.
>
But VM/CMS has SIGNAL ON NOTREADY. The same vendor; originally the same
source code. How can they do so poorly?

> -----Original Message-----
> In a recent note, Cruz, Robert said:
>
> > Date: Wed, 20 Jun 2007 15:38:42 -0700
> >
> > I am interested to know how many of you have installed the IBM MVS
> > REXX Stream I/O package**, and how many of you are using it.
>
> o This competes and is incompatible with the identically
> named functions available when Rexx is invoked under
> Unix System Services. I believe one accesses UNIX files;
> the other Classic data sets; you can't get to both from
> a single EXEC. A suitably enhanced STREAM() could have
> made this possible.
>
> o I don't believe either version provides SIGNAL ON NOTREADY,
> part of Cowlishaw's original specification.
>
> Conway's law strikes again.

-- gil
--
StorageTek
INFORMATION made POWERFUL

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions, send
email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Horacio Villa
2007-06-27 19:39:11 UTC
Permalink
Hi,

we are experiencing a weird error on z/OS 1.4 with some REXX procedures.
Prod people called us saying "the job is running but doing nothing".
Looking at SYSPRINT, we can see a SAY instruction, which is immediately
before the EXIT.
The job consumes CPU but doesn't end.
This happened first with compiled REXX and we replaced all this scripts
with the source version.
Now it's happening again with the source version.
This time, a previous script in the job finished with this error, when it
reached the EXIT:

IKJ79009I PHASE 1 PROCESSING OF CLIST OR REXX EXEC ENDED ABNORMALLY +
IKJ79010I ABEND CODE: S614 REASON CODE: 0014
READY
END

Storage people are looking at this error.

I wonder if this problem ever happened to somebody in the list.
The REXX scripts in error have been working fine for more than 1 year.
We are not aware of any change made to the OS or SMS routines.

Cheers,

Horacio Villa

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Ryerse, Robin
2007-06-27 19:42:20 UTC
Permalink
Is the exec "stand alone" or launched by another process?


Robin Ryerse




-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf
Of Horacio Villa
Sent: June 27, 2007 3:32 PM
To: TSO-***@VM.MARIST.EDU
Subject: Loop in Exit

Hi,

we are experiencing a weird error on z/OS 1.4 with some REXX procedures.
Prod people called us saying "the job is running but doing nothing".
Looking at SYSPRINT, we can see a SAY instruction, which is immediately
before the EXIT.
The job consumes CPU but doesn't end.
This happened first with compiled REXX and we replaced all this scripts
with the source version.
Now it's happening again with the source version.
This time, a previous script in the job finished with this error, when
it
reached the EXIT:

IKJ79009I PHASE 1 PROCESSING OF CLIST OR REXX EXEC ENDED ABNORMALLY +
IKJ79010I ABEND CODE: S614 REASON CODE: 0014
READY
END

Storage people are looking at this error.

I wonder if this problem ever happened to somebody in the list.
The REXX scripts in error have been working fine for more than 1 year.
We are not aware of any change made to the OS or SMS routines.

Cheers,

Horacio Villa

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Paul Gilmartin
2007-06-27 19:57:24 UTC
Permalink
In a recent note, Horacio Villa said:

> Date: Wed, 27 Jun 2007 16:32:06 -0300
>
> IKJ79009I PHASE 1 PROCESSING OF CLIST OR REXX EXEC ENDED ABNORMALLY +
> IKJ79010I ABEND CODE: S614 REASON CODE: 0014
> READY
> END
>
I had something similar (but I believe it involved a S0C4) when
I had a UNIX directory in my SYSEXEC concatenation (or in HLASM
SYSLIB). OA17707.
hours.

-- gil
--
StorageTek
INFORMATION made POWERFUL

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Horacio Villa
2007-06-27 20:26:29 UTC
Permalink
Hi Paul,

in this case there's no UNIX directory in SYSEXEC, and no HLASM SYSLIB.
Systems programmers are complaining about the library being PDSE, but it
has been so for more than a year.

Cheers,

Horacio Villa




Paul Gilmartin <***@UNIX.STORTEK.COM>
Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
27/06/2007 16:49
Please respond to
TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>


To
TSO-***@VM.MARIST.EDU
cc

Subject
Re: [TSO-REXX] Loop in Exit






In a recent note, Horacio Villa said:

> Date: Wed, 27 Jun 2007 16:32:06 -0300
>
> IKJ79009I PHASE 1 PROCESSING OF CLIST OR REXX EXEC ENDED ABNORMALLY +
> IKJ79010I ABEND CODE: S614 REASON CODE: 0014
> READY
> END
>
I had something similar (but I believe it involved a S0C4) when
I had a UNIX directory in my SYSEXEC concatenation (or in HLASM
SYSLIB). OA17707.
hours.

-- gil
--
StorageTek
INFORMATION made POWERFUL

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Thomas Berg
2007-06-27 21:36:14 UTC
Permalink
What is Your REGION= parm ?
(EXEC or in JOB card ?)

Thomas Berg

====== Horacio Villa ====== wrote 2007-06-27 21:32:
> Hi,
>
> we are experiencing a weird error on z/OS 1.4 with some REXX procedures.
> Prod people called us saying "the job is running but doing nothing".
> Looking at SYSPRINT, we can see a SAY instruction, which is immediately
> before the EXIT.
> The job consumes CPU but doesn't end.
> This happened first with compiled REXX and we replaced all this scripts
> with the source version.
> Now it's happening again with the source version.
> This time, a previous script in the job finished with this error, when it
> reached the EXIT:
>
> IKJ79009I PHASE 1 PROCESSING OF CLIST OR REXX EXEC ENDED ABNORMALLY +
> IKJ79010I ABEND CODE: S614 REASON CODE: 0014
> READY
> END
>
> Storage people are looking at this error.
>
> I wonder if this problem ever happened to somebody in the list.
> The REXX scripts in error have been working fine for more than 1 year.
> We are not aware of any change made to the OS or SMS routines.
>
> Cheers,
>
> Horacio Villa
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
>

--

__________________________

Mundus Vult Decipi
__________________________

They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
- Benjamin Franklin

Military justice is to justice what military music is to music.
- Groucho Marx

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Horacio Villa
2007-06-27 21:45:56 UTC
Permalink
We are using REGION=0M

Horacio Villa



Thomas Berg <***@TBERG.NET>
Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
27/06/2007 18:37
Please respond to
TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>


To
TSO-***@VM.MARIST.EDU
cc

Subject
Re: [TSO-REXX] Loop in Exit






What is Your REGION= parm ?
(EXEC or in JOB card ?)

Thomas Berg

====== Horacio Villa ====== wrote 2007-06-27 21:32:
> Hi,
>
> we are experiencing a weird error on z/OS 1.4 with some REXX procedures.
> Prod people called us saying "the job is running but doing nothing".
> Looking at SYSPRINT, we can see a SAY instruction, which is immediately
> before the EXIT.
> The job consumes CPU but doesn't end.
> This happened first with compiled REXX and we replaced all this scripts
> with the source version.
> Now it's happening again with the source version.
> This time, a previous script in the job finished with this error, when
it
> reached the EXIT:
>
> IKJ79009I PHASE 1 PROCESSING OF CLIST OR REXX EXEC ENDED ABNORMALLY +
> IKJ79010I ABEND CODE: S614 REASON CODE: 0014
> READY
> END
>
> Storage people are looking at this error.
>
> I wonder if this problem ever happened to somebody in the list.
> The REXX scripts in error have been working fine for more than 1 year.
> We are not aware of any change made to the OS or SMS routines.
>
> Cheers,
>
> Horacio Villa
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
>

--

__________________________

Mundus Vult Decipi
__________________________

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
- Benjamin Franklin

Military justice is to justice what military music is to music.
- Groucho Marx

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Thomas Berg
2007-06-27 22:05:46 UTC
Permalink
Have You tried e g REGION=32M and REGION=4M ?
Have You checked the IEFUSI (?) exit for changes ?

(IIRC I have had some similar behaviour caused by memory problems.)

Thomas Berg

====== Horacio Villa ====== wrote 2007-06-27 23:47:
> We are using REGION=0M
>
> Horacio Villa
>
>
>
> Thomas Berg <***@TBERG.NET>
> Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
> 27/06/2007 18:37
> Please respond to
> TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
>
>
> To
> TSO-***@VM.MARIST.EDU
> cc
>
> Subject
> Re: [TSO-REXX] Loop in Exit
>
>
>
>
>
>
> What is Your REGION= parm ?
> (EXEC or in JOB card ?)
>
> Thomas Berg
>
> ====== Horacio Villa ====== wrote 2007-06-27 21:32:
>> Hi,
>>
>> we are experiencing a weird error on z/OS 1.4 with some REXX procedures.
>> Prod people called us saying "the job is running but doing nothing".
>> Looking at SYSPRINT, we can see a SAY instruction, which is immediately
>> before the EXIT.
>> The job consumes CPU but doesn't end.
>> This happened first with compiled REXX and we replaced all this scripts
>> with the source version.
>> Now it's happening again with the source version.
>> This time, a previous script in the job finished with this error, when
> it
>> reached the EXIT:
>>
>> IKJ79009I PHASE 1 PROCESSING OF CLIST OR REXX EXEC ENDED ABNORMALLY +
>> IKJ79010I ABEND CODE: S614 REASON CODE: 0014
>> READY
>> END
>>
>> Storage people are looking at this error.
>>
>> I wonder if this problem ever happened to somebody in the list.
>> The REXX scripts in error have been working fine for more than 1 year.
>> We are not aware of any change made to the OS or SMS routines.
>>
>> Cheers,
>>
>> Horacio Villa
>>
>> ----------------------------------------------------------------------
>> For TSO-REXX subscribe / signoff / archive access instructions,
>> send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
>>
>
> --
>
> __________________________
>
> Mundus Vult Decipi
> __________________________
>
> They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety.
> - Benjamin Franklin
>
> Military justice is to justice what military music is to music.
> - Groucho Marx
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
>
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
>

--

__________________________

Mundus Vult Decipi
__________________________

They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
- Benjamin Franklin

Military justice is to justice what military music is to music.
- Groucho Marx

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Bill Turner, WB4ALM
2007-06-28 14:52:33 UTC
Permalink
Caution, REGION=0M does not do what you think it does.

Region=0m asks the system to give you whatever memory is "CURRENTLY"
available.
And what is "currently" available will change from moment to moment.

Strongly recommend specifying a region value that is less than the
maximum amount available "below the line" or specifying a number larger
than 16M. Some MVS systems provide a 9M to 10M below the line, but many
are pushed to provide more than 7M to 8M. It all depends on the
qualifications of your MVS System Support Staff, and how much time they
have to optimize memory usage..

Personally, I _NEVER_ code REGION=0M

/s/ Bill Turner, wb4alm


Horacio Villa wrote:
> We are using REGION=0M
>
> Horacio Villa
>
>
>
> Thomas Berg <***@TBERG.NET>
> Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
> 27/06/2007 18:37
> Please respond to
> TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
>
>
> To
> TSO-***@VM.MARIST.EDU
> cc
>
> Subject
> Re: [TSO-REXX] Loop in Exit
>
>
>
>
>
>
> What is Your REGION= parm ?
> (EXEC or in JOB card ?)
>
> Thomas Berg
>
> ====== Horacio Villa ====== wrote 2007-06-27 21:32:
>
>> Hi,
>>
>> we are experiencing a weird error on z/OS 1.4 with some REXX procedures.
>> Prod people called us saying "the job is running but doing nothing".
>> Looking at SYSPRINT, we can see a SAY instruction, which is immediately
>> before the EXIT.
>> The job consumes CPU but doesn't end.
>> This happened first with compiled REXX and we replaced all this scripts
>> with the source version.
>> Now it's happening again with the source version.
>> This time, a previous script in the job finished with this error, when
>>
> it
>
>> reached the EXIT:
>>
>> IKJ79009I PHASE 1 PROCESSING OF CLIST OR REXX EXEC ENDED ABNORMALLY +
>> IKJ79010I ABEND CODE: S614 REASON CODE: 0014
>> READY
>> END
>>
>> Storage people are looking at this error.
>>
>> I wonder if this problem ever happened to somebody in the list.
>> The REXX scripts in error have been working fine for more than 1 year.
>> We are not aware of any change made to the OS or SMS routines.
>>
>> Cheers,
>>
>> Horacio Villa
>>
>> ----------------------------------------------------------------------
>> For TSO-REXX subscribe / signoff / archive access instructions,
>> send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
>>
>>
>
> --
>
> __________________________
>
> Mundus Vult Decipi
> __________________________
>
> They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety.
> - Benjamin Franklin
>
> Military justice is to justice what military music is to music.
> - Groucho Marx
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
>
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
>
>

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Imbriale, Donald
2007-06-27 20:02:20 UTC
Permalink
The 614-14 suggests

A CLOSE macro instruction detected an error return code from an
SMS service while processing a PDSE data set.

Did you recently convert a REXX library to a PDSE? Have you recently
implemented the SMSPDSE1 address space?

Don Imbriale


-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, June 27, 2007 3:50 PM
To: TSO-***@VM.MARIST.EDU
Subject: Re: Loop in Exit

In a recent note, Horacio Villa said:

> Date: Wed, 27 Jun 2007 16:32:06 -0300
>
> IKJ79009I PHASE 1 PROCESSING OF CLIST OR REXX EXEC ENDED ABNORMALLY +
> IKJ79010I ABEND CODE: S614 REASON CODE: 0014
> READY
> END
>



***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Horacio Villa
2007-06-27 21:22:55 UTC
Permalink
Hi Donald,

no, for both of your questions.

Cheers,

Horacio Villa



"Imbriale, Donald" <***@BEAR.COM>
Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
27/06/2007 17:01
Please respond to
TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>


To
TSO-***@VM.MARIST.EDU
cc

Subject
Re: [TSO-REXX] Loop in Exit






The 614-14 suggests

A CLOSE macro instruction detected an error return code from an
SMS service while processing a PDSE data set.

Did you recently convert a REXX library to a PDSE? Have you recently
implemented the SMSPDSE1 address space?

Don Imbriale


-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, June 27, 2007 3:50 PM
To: TSO-***@VM.MARIST.EDU
Subject: Re: Loop in Exit

In a recent note, Horacio Villa said:

> Date: Wed, 27 Jun 2007 16:32:06 -0300
>
> IKJ79009I PHASE 1 PROCESSING OF CLIST OR REXX EXEC ENDED ABNORMALLY +
> IKJ79010I ABEND CODE: S614 REASON CODE: 0014
> READY
> END
>



***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Robert Zenuk
2007-06-28 17:20:54 UTC
Permalink
I do not see the behavior you are describing for REGION=0M. I have always
used this for basic jobs and have been very successful with it. Every place I
have ever worked has implemented an IEFACTRT exit to place a "flower box" in
the JES Allocation/Deallocation messages for each step. A common reported
component of all these exits is Virtual Memory availability and usage. Since
MVS/XA (circa 1983?), when you look at the step statistics when using
REGION=0M you always see the Virtual Available match the max below the line value
(used obviously depends upon the program). This value (as you already stated)
ranges between 7M and 10M. If you need above the line storage, you must code
a value above 16M and may need to modify your IEFUSI to increase the default
32M limit (last I knew, 32M was still the default limit).

Rob



In a message dated 6/28/2007 9:25:26 A.M. US Mountain Standard Time,
***@ARRL.NET writes:

Caution, REGION=0M does not do what you think it does.

Region=0m asks the system to give you whatever memory is "CURRENTLY"
available.
And what is "currently" available will change from moment to moment.

Strongly recommend specifying a region value that is less than the
maximum amount available "below the line" or specifying a number larger
than 16M. Some MVS systems provide a 9M to 10M below the line, but many
are pushed to provide more than 7M to 8M. It all depends on the
qualifications of your MVS System Support Staff, and how much time they
have to optimize memory usage..

Personally, I _NEVER_ code REGION=0M

/s/ Bill Turner, wb4alm


Horacio Villa wrote:
> We are using REGION=0M
>
> Horacio Villa
>
>
>
> Thomas Berg <***@TBERG.NET>
> Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
> 27/06/2007 18:37
> Please respond to
> TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
>
>
> To
> TSO-***@VM.MARIST.EDU
> cc
>
> Subject
> Re: [TSO-REXX] Loop in Exit
>
>
>
>
>
>
> What is Your REGION= parm ?
> (EXEC or in JOB card ?)
>
> Thomas Berg
>
> ====== Horacio Villa ====== wrote 2007-06-27 21:32:
>
>> Hi,
>>
>> we are experiencing a weird error on z/OS 1.4 with some REXX procedures.
>> Prod people called us saying "the job is running but doing nothing".
>> Looking at SYSPRINT, we can see a SAY instruction, which is immediately
>> before the EXIT.
>> The job consumes CPU but doesn't end.
>> This happened first with compiled REXX and we replaced all this scripts
>> with the source version.
>> Now it's happening again with the source version.
>> This time, a previous script in the job finished with this error, when
>>
> it
>
>> reached the EXIT:
>>
>> IKJ79009I PHASE 1 PROCESSING OF CLIST OR REXX EXEC ENDED ABNORMALLY +
>> IKJ79010I ABEND CODE: S614 REASON CODE: 0014
>> READY
>> END
>>
>> Storage people are looking at this error.
>>
>> I wonder if this problem ever happened to somebody in the list.
>> The REXX scripts in error have been working fine for more than 1 year.
>> We are not aware of any change made to the OS or SMS routines.
>>
>> Cheers,
>>
>> Horacio Villa
>>
>> ----------------------------------------------------------------------
>> For TSO-REXX subscribe / signoff / archive access instructions,
>> send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
>>
>>
>
> --
>
> __________________________
>
> Mundus Vult Decipi
> __________________________
>
> They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety.
> - Benjamin Franklin
>
> Military justice is to justice what military music is to music.
> - Groucho Marx
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
>
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
>
>

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX







************************************** See what's free at http://www.aol.com.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
João Luís Matos Carvalho (DSI)
2007-06-28 17:47:45 UTC
Permalink
Hello list !

Sorry this dummy question (and I don't know if this is the correct list to do so) but, I've have done a few weeks ago a program that obtain certain system info (JOBNAME;STEP NAME;IPL JDATE; etc....).

But to be honest, I didn't understand how that values were obtained, so I copied the code....

But I want to understand how that info is obtained.

Can someone recommend me what books or sites to read/look ?



Atenciosamente,

João Carvalho

* - mailto:***@caixaseguros.pt

"Em momentos de crise, só a imaginação é mais importante que o conhecimento"

(Albert Einstein)

P Antes de imprimir este e-mail pense bem se tem mesmo que o fazer. Há cada vez menos árvores


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Bob Stark
2007-06-30 07:50:33 UTC
Permalink
João,

At the following site there are the MVS Data Areas books, volumes 1-5:
http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/r7pdf/mvs.html

It's pretty complex. When I started there were 3 tiny books that contained
almost everything an assembler programmer needed. Now there are more data
areas and less Assembler source code to browse. And fewer gurus to ask, but
now of course we have the Internet.

Assembler programmers can call system services to get back data (such as
GQSCAN to get ENQ data), or to do things Like raise an ENQ or Attach a
subtask.

As a REXX programmer, all that you can do is look through the data areas.
But there is a lot of data laying around.

There are two key control blocks in memory that help you find all the other
control blocks:

1. The PSA - Stands for Prefixed Save Area - it is the first couple thousand
or so bytes of memory, contains useful fields like PSATOLD which is the
pointer to the current TCB (task Control Block), and PSAAOLD, which is the
pointer to the current ASCB (address space control block). As MVS switches
tasks, it stores things into PSA, so that when your task is running, your
data is in the PSA.

2. The CVT - Stands for Communication Vector Table - it's pointer is located
at x'10' (decimal 16) into the PSA. It is a collection of pointers to other
control blocks. From it you can find lots of other things.

You'll see that fancy data gathering REXX code by awesome coders such as
Doug Nadel, Mark Zelden, Lionel Dyck, and others will often start by
fetching the CVT.

To learn more, I would recommend you pick apart some REXX code that
interests you by trying to find the first control block in the data areas
book, then the next, etc.

You can use IPCS under ISPF to do look at active memory; Then you can poke
around and browse these control blocks interactively.

Where possible, I would use a high level interface like the MVSVAR() and/or
SYSVAR() functions, if they can get the data, before I would fool around
with the STORAGE() function. That said, I have used the Storage() function a
good bit.

Regards,

Bob Stark

ProTech - When you're serious about Systems Management
Consulting, Software, and Training for z/OS, UNIX and Internet
www.protechtraining.com 800-373-9188 x150 412-445-8072

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of
João Luís Matos Carvalho (DSI)
Sent: Thursday, June 28, 2007 1:32 PM
To: TSO-***@VM.MARIST.EDU
Subject: MVS Data Areas

Hello list !

Sorry this dummy question (and I don't know if this is the correct list to
do so) but, I've have done a few weeks ago a program that obtain certain
system info (JOBNAME;STEP NAME;IPL JDATE; etc....).

But to be honest, I didn't understand how that values were obtained, so I
copied the code....

But I want to understand how that info is obtained.

Can someone recommend me what books or sites to read/look ?

Atenciosamente,

João Carvalho

* - mailto:***@caixaseguros.pt

"Em momentos de crise, só a imaginação é mais importante que o conhecimento"

(Albert Einstein)

P Antes de imprimir este e-mail pense bem se tem mesmo que o fazer. Há cada
vez menos árvores


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions, send email
to ***@VM.MARIST.EDU with the message: INFO TSO-REXX



--
If this email is spam, report it here:
http://www.OnlyMyEmail.com/reportSpam?Id=Mzg3MzE6MzQyMjU2MzEzOmJzdGFya0Bwcm9
0ZWNocHRzLmNvbQ%3D%3D

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Lindy Mayfield
2007-06-30 11:12:19 UTC
Permalink
You can also use TSO ISRDDN to browse control blocks, or double check your Rexx code.

For example, at the command line, enter: B 0.

The control block you see is your PSA. Scroll down to where it reads +220 and place your cursor on the second group of addresses so that you are at offset 224 hex.

This one
+220 (00000220) 00FDAB00 00F7B780 00000000 00000000

Hit enter with the cursor there and it will take you to that address which is your own ASCB (of your TSO session). You should see written ASCB as the first 4 bytes in the dump.

Go down to the address at 150, put the cursor there and hit enter and you are at the ASSB. Go to A8 and do the same and you'll be in the JSAB. You'll see the names of the control blocks (ASSB, JSAB) in the dump text.

At offset 14 of the JSAB you'll see the jobid, for example.

You can see what information is there in these control blocks by checking the data areas docs that Bob pointed out.

I still have a lot of trouble when, for example, I want to find a certain piece of information to know which control block it is in.

Lindy


-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of Bob Stark
Sent: Saturday, June 30, 2007 7:14 AM
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] MVS Data Areas
.

To learn more, I would recommend you pick apart some REXX code that
interests you by trying to find the first control block in the data areas
book, then the next, etc.

You can use IPCS under ISPF to do look at active memory; Then you can poke
around and browse these control blocks interactively.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Horacio Villa
2007-06-30 14:07:50 UTC
Permalink
Hi Lindy,

I tried your example, but with B 0 at the command line I get:

The load module was not browsed because it is not loaded into storage. You

may be able to explicitly load it using the LOAD command.

Do you know which module is it? Or what should be done to have it online?

Cheers,

Horacio Villa




Lindy Mayfield <***@SSF.SAS.COM>
Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
30/06/2007 08:11
Please respond to
TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>


To
TSO-***@VM.MARIST.EDU
cc

Subject
Re: [TSO-REXX] MVS Data Areas






You can also use TSO ISRDDN to browse control blocks, or double check your
Rexx code.

For example, at the command line, enter: B 0.

The control block you see is your PSA. Scroll down to where it reads +220
and place your cursor on the second group of addresses so that you are at
offset 224 hex.

This one
+220 (00000220) 00FDAB00 00F7B780 00000000 00000000

Hit enter with the cursor there and it will take you to that address which
is your own ASCB (of your TSO session). You should see written ASCB as
the first 4 bytes in the dump.

Go down to the address at 150, put the cursor there and hit enter and you
are at the ASSB. Go to A8 and do the same and you'll be in the JSAB.
You'll see the names of the control blocks (ASSB, JSAB) in the dump text.

At offset 14 of the JSAB you'll see the jobid, for example.

You can see what information is there in these control blocks by checking
the data areas docs that Bob pointed out.

I still have a lot of trouble when, for example, I want to find a certain
piece of information to know which control block it is in.

Lindy


-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf
Of Bob Stark
Sent: Saturday, June 30, 2007 7:14 AM
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] MVS Data Areas
.

To learn more, I would recommend you pick apart some REXX code that
interests you by trying to find the first control block in the data areas
book, then the next, etc.

You can use IPCS under ISPF to do look at active memory; Then you can poke
around and browse these control blocks interactively.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Lindy Mayfield
2007-06-30 14:12:02 UTC
Permalink
Hi,

Make sure you end the address (in this case 0) with a period "."

So: TSO ISRDDN from anywhere in ISPF. Then B 0. (or BROWSE 0. ) but remember the last "." because it is important. Not sure why exactly, but it is. Maybe it is just syntax so that the code knows the difference between an address and a module (which you can also load).

Lindy

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of Horacio Villa
Sent: Saturday, June 30, 2007 5:09 PM
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] MVS Data Areas

Hi Lindy,

I tried your example, but with B 0 at the command line I get:

The load module was not browsed because it is not loaded into storage. You

may be able to explicitly load it using the LOAD command.

Do you know which module is it? Or what should be done to have it online?

Cheers,

Horacio Villa




Lindy Mayfield <***@SSF.SAS.COM>
Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
30/06/2007 08:11
Please respond to
TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>


To
TSO-***@VM.MARIST.EDU
cc

Subject
Re: [TSO-REXX] MVS Data Areas






You can also use TSO ISRDDN to browse control blocks, or double check your
Rexx code.

For example, at the command line, enter: B 0.

The control block you see is your PSA. Scroll down to where it reads +220
and place your cursor on the second group of addresses so that you are at
offset 224 hex.

This one
+220 (00000220) 00FDAB00 00F7B780 00000000 00000000

Hit enter with the cursor there and it will take you to that address which
is your own ASCB (of your TSO session). You should see written ASCB as
the first 4 bytes in the dump.

Go down to the address at 150, put the cursor there and hit enter and you
are at the ASSB. Go to A8 and do the same and you'll be in the JSAB.
You'll see the names of the control blocks (ASSB, JSAB) in the dump text.

At offset 14 of the JSAB you'll see the jobid, for example.

You can see what information is there in these control blocks by checking
the data areas docs that Bob pointed out.

I still have a lot of trouble when, for example, I want to find a certain
piece of information to know which control block it is in.

Lindy


-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf
Of Bob Stark
Sent: Saturday, June 30, 2007 7:14 AM
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] MVS Data Areas
.

To learn more, I would recommend you pick apart some REXX code that
interests you by trying to find the first control block in the data areas
book, then the next, etc.

You can use IPCS under ISPF to do look at active memory; Then you can poke
around and browse these control blocks interactively.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Horacio Villa
2007-06-30 14:17:11 UTC
Permalink
Thanks Lindy,

I didn't realize the period was indeed part of the command, I thought it
was the normal end of a sentence.
That made the trick.

Cheers,

Horacio



Lindy Mayfield <***@SSF.SAS.COM>
Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
30/06/2007 11:11
Please respond to
TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>


To
TSO-***@VM.MARIST.EDU
cc

Subject
Re: [TSO-REXX] MVS Data Areas






Hi,

Make sure you end the address (in this case 0) with a period "."

So: TSO ISRDDN from anywhere in ISPF. Then B 0. (or BROWSE 0. ) but
remember the last "." because it is important. Not sure why exactly, but
it is. Maybe it is just syntax so that the code knows the difference
between an address and a module (which you can also load).

Lindy

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf
Of Horacio Villa
Sent: Saturday, June 30, 2007 5:09 PM
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] MVS Data Areas

Hi Lindy,

I tried your example, but with B 0 at the command line I get:

The load module was not browsed because it is not loaded into storage. You

may be able to explicitly load it using the LOAD command.

Do you know which module is it? Or what should be done to have it online?

Cheers,

Horacio Villa




Lindy Mayfield <***@SSF.SAS.COM>
Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
30/06/2007 08:11
Please respond to
TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>


To
TSO-***@VM.MARIST.EDU
cc

Subject
Re: [TSO-REXX] MVS Data Areas






You can also use TSO ISRDDN to browse control blocks, or double check your
Rexx code.

For example, at the command line, enter: B 0.

The control block you see is your PSA. Scroll down to where it reads +220
and place your cursor on the second group of addresses so that you are at
offset 224 hex.

This one
+220 (00000220) 00FDAB00 00F7B780 00000000 00000000

Hit enter with the cursor there and it will take you to that address which
is your own ASCB (of your TSO session). You should see written ASCB as
the first 4 bytes in the dump.

Go down to the address at 150, put the cursor there and hit enter and you
are at the ASSB. Go to A8 and do the same and you'll be in the JSAB.
You'll see the names of the control blocks (ASSB, JSAB) in the dump text.

At offset 14 of the JSAB you'll see the jobid, for example.

You can see what information is there in these control blocks by checking
the data areas docs that Bob pointed out.

I still have a lot of trouble when, for example, I want to find a certain
piece of information to know which control block it is in.

Lindy


-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf
Of Bob Stark
Sent: Saturday, June 30, 2007 7:14 AM
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] MVS Data Areas
.

To learn more, I would recommend you pick apart some REXX code that
interests you by trying to find the first control block in the data areas
book, then the next, etc.

You can use IPCS under ISPF to do look at active memory; Then you can poke
around and browse these control blocks interactively.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
João Luís Matos Carvalho (DSI)
2007-07-02 12:47:46 UTC
Permalink
Thank's !
I'll try to "dig" into this.

Atenciosamente,
João Carvalho
* - mailto:***@caixaseguros.pt
"Em momentos de crise, só a imaginação é mais importante que o conhecimento"
(Albert Einstein)
P Antes de imprimir este e-mail pense bem se tem mesmo que o fazer. Há cada vez menos árvores

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of Horacio Villa
Sent: sábado, 30 de Junho de 2007 15:18
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] MVS Data Areas

Thanks Lindy,

I didn't realize the period was indeed part of the command, I thought it
was the normal end of a sentence.
That made the trick.

Cheers,

Horacio



Lindy Mayfield <***@SSF.SAS.COM>
Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
30/06/2007 11:11
Please respond to
TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>


To
TSO-***@VM.MARIST.EDU
cc

Subject
Re: [TSO-REXX] MVS Data Areas






Hi,

Make sure you end the address (in this case 0) with a period "."

So: TSO ISRDDN from anywhere in ISPF. Then B 0. (or BROWSE 0. ) but
remember the last "." because it is important. Not sure why exactly, but
it is. Maybe it is just syntax so that the code knows the difference
between an address and a module (which you can also load).

Lindy

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf
Of Horacio Villa
Sent: Saturday, June 30, 2007 5:09 PM
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] MVS Data Areas

Hi Lindy,

I tried your example, but with B 0 at the command line I get:

The load module was not browsed because it is not loaded into storage. You

may be able to explicitly load it using the LOAD command.

Do you know which module is it? Or what should be done to have it online?

Cheers,

Horacio Villa




Lindy Mayfield <***@SSF.SAS.COM>
Sent by: TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>
30/06/2007 08:11
Please respond to
TSO REXX Discussion List <TSO-***@VM.MARIST.EDU>


To
TSO-***@VM.MARIST.EDU
cc

Subject
Re: [TSO-REXX] MVS Data Areas






You can also use TSO ISRDDN to browse control blocks, or double check your
Rexx code.

For example, at the command line, enter: B 0.

The control block you see is your PSA. Scroll down to where it reads +220
and place your cursor on the second group of addresses so that you are at
offset 224 hex.

This one
+220 (00000220) 00FDAB00 00F7B780 00000000 00000000

Hit enter with the cursor there and it will take you to that address which
is your own ASCB (of your TSO session). You should see written ASCB as
the first 4 bytes in the dump.

Go down to the address at 150, put the cursor there and hit enter and you
are at the ASSB. Go to A8 and do the same and you'll be in the JSAB.
You'll see the names of the control blocks (ASSB, JSAB) in the dump text.

At offset 14 of the JSAB you'll see the jobid, for example.

You can see what information is there in these control blocks by checking
the data areas docs that Bob pointed out.

I still have a lot of trouble when, for example, I want to find a certain
piece of information to know which control block it is in.

Lindy


-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf
Of Bob Stark
Sent: Saturday, June 30, 2007 7:14 AM
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] MVS Data Areas
.

To learn more, I would recommend you pick apart some REXX code that
interests you by trying to find the first control block in the data areas
book, then the next, etc.

You can use IPCS under ISPF to do look at active memory; Then you can poke
around and browse these control blocks interactively.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
João Luís Matos Carvalho (DSI)
2007-07-03 09:45:34 UTC
Permalink
Hello again,

I've been reading how to get for example the Jobname.

For I've read, I've to go to PSA, then, obtain the TCB address, get the TIOT address and then the Jobname.

In the "MVS Data Areas books", I've got the following :



PSA (get the TCB address) --> Offset Dec (540) Hex (21C)





TCB (get the TIOT address) --> Offset Dec (12) Hex (C)

In TCB I find that the OFFSET is 12, but I found a program that don't have that, but the information returned is correct. The code is like this (the addresses don't match). Get someone tell me why ?





PSA SET ADDRESS OF L-AREA1 TO NULL

*-----------------------------------------------------------

TCB SET ADDRESS OF L-AREA1 TO L-AREA1-PTR(136)

*-----------------------------------------------------------

TIOT SET ADDRESS OF L-AREA2 TO L-AREA1-PTR(4)

MOVE L-AREA2(1:8) TO MX298-JOB-NAME



Atenciosamente,

João Carvalho

* - mailto:***@caixaseguros.pt

"Em momentos de crise, só a imaginação é mais importante que o conhecimento"

(Albert Einstein)

P Antes de imprimir este e-mail pense bem se tem mesmo que o fazer. Há cada vez menos árvores



-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of Bob Stark
Sent: sábado, 30 de Junho de 2007 5:14
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] MVS Data Areas



João,



At the following site there are the MVS Data Areas books, volumes 1-5:

http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/r7pdf/mvs.html



It's pretty complex. When I started there were 3 tiny books that contained

almost everything an assembler programmer needed. Now there are more data

areas and less Assembler source code to browse. And fewer gurus to ask, but

now of course we have the Internet.



Assembler programmers can call system services to get back data (such as

GQSCAN to get ENQ data), or to do things Like raise an ENQ or Attach a

subtask.



As a REXX programmer, all that you can do is look through the data areas.

But there is a lot of data laying around.



There are two key control blocks in memory that help you find all the other

control blocks:



1. The PSA - Stands for Prefixed Save Area - it is the first couple thousand

or so bytes of memory, contains useful fields like PSATOLD which is the

pointer to the current TCB (task Control Block), and PSAAOLD, which is the

pointer to the current ASCB (address space control block). As MVS switches

tasks, it stores things into PSA, so that when your task is running, your

data is in the PSA.



2. The CVT - Stands for Communication Vector Table - it's pointer is located

at x'10' (decimal 16) into the PSA. It is a collection of pointers to other

control blocks. From it you can find lots of other things.



You'll see that fancy data gathering REXX code by awesome coders such as

Doug Nadel, Mark Zelden, Lionel Dyck, and others will often start by

fetching the CVT.



To learn more, I would recommend you pick apart some REXX code that

interests you by trying to find the first control block in the data areas

book, then the next, etc.



You can use IPCS under ISPF to do look at active memory; Then you can poke

around and browse these control blocks interactively.



Where possible, I would use a high level interface like the MVSVAR() and/or

SYSVAR() functions, if they can get the data, before I would fool around

with the STORAGE() function. That said, I have used the Storage() function a

good bit.



Regards,



Bob Stark



ProTech - When you're serious about Systems Management

Consulting, Software, and Training for z/OS, UNIX and Internet

www.protechtraining.com 800-373-9188 x150 412-445-8072



-----Original Message-----

From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of

João Luís Matos Carvalho (DSI)

Sent: Thursday, June 28, 2007 1:32 PM

To: TSO-***@VM.MARIST.EDU

Subject: MVS Data Areas



Hello list !



Sorry this dummy question (and I don't know if this is the correct list to

do so) but, I've have done a few weeks ago a program that obtain certain

system info (JOBNAME;STEP NAME;IPL JDATE; etc....).



But to be honest, I didn't understand how that values were obtained, so I

copied the code....



But I want to understand how that info is obtained.



Can someone recommend me what books or sites to read/look ?



Atenciosamente,



João Carvalho



* - mailto:***@caixaseguros.pt



"Em momentos de crise, só a imaginação é mais importante que o conhecimento"



(Albert Einstein)



P Antes de imprimir este e-mail pense bem se tem mesmo que o fazer. Há cada

vez menos árvores





----------------------------------------------------------------------

For TSO-REXX subscribe / signoff / archive access instructions, send email

to ***@VM.MARIST.EDU with the message: INFO TSO-REXX







--

If this email is spam, report it here:

http://www.OnlyMyEmail.com/reportSpam?Id=Mzg3MzE6MzQyMjU2MzEzOmJzdGFya0Bwcm9

0ZWNocHRzLmNvbQ%3D%3D



----------------------------------------------------------------------

For TSO-REXX subscribe / signoff / archive access instructions,

send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
McKown, John
2007-07-03 12:36:39 UTC
Permalink
> -----Original Message-----
> From: TSO REXX Discussion List
> [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of João Luís Matos
> Carvalho (DSI)
> Sent: Tuesday, July 03, 2007 4:45 AM
> To: TSO-***@VM.MARIST.EDU
> Subject: Re: [TSO-REXX] MVS Data Areas
>
> Hello again,

Greetings. I will mention that this question is not really about REXX in a TSO environment. It might have been better to ask this on IBM-MAIN.

>
> I've been reading how to get for example the Jobname.
>
> For I've read, I've to go to PSA, then, obtain the TCB
> address, get the TIOT address and then the Jobname.

This is only one way. There are others.

>
> In the "MVS Data Areas books", I've got the following :
>
> PSA (get the TCB address) --> Offset Dec (540) Hex (21C)
>
> TCB (get the TIOT address) --> Offset Dec (12) Hex (C)
>
> In TCB I find that the OFFSET is 12, but I found a program
> that don't have that, but the information returned is
> correct. The code is like this (the addresses don't match).
> Get someone tell me why ?
>
> PSA SET ADDRESS OF L-AREA1 TO NULL

This does indeed set L-AREA1 to point to the PSA. So far, so good.

>
>
> TCB SET ADDRESS OF L-AREA1 TO L-AREA1-PTR(136)

OK, assuming L-AREA1-PTR is a normal COBOL "occurs" of POINTERs. This gets the address at offset (136-1)*4 or 540. This is the field PSATOLD which does indeed point to the current TCB.

>
> TIOT SET ADDRESS OF L-AREA2 TO L-AREA1-PTR(4)

Again, with the same logic as above, the offset is (4-1)*3 or 12, which is indeed the TIOT address. So L-AREA2 points to the TIOT.

>
> MOVE L-AREA2(1:8) TO MX298-JOB-NAME

Do a "reference modification" to pick up the first 8 bytes of the TIOT, which contains the job name.

>
> Atenciosamente,
>
> João Carvalho

Remember that COBOL starts all subscripts at 1, not 0. So to find the offset, you must subtract 1 from the array index before multiplying by the array element size.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
João Luís Matos Carvalho (DSI)
2007-07-03 13:06:03 UTC
Permalink
Thank you very much !

I've got it. I know that with REXX, I can go directly for the offset (Storage...), but when I looked to the Cobol Source, I didn't understand that values. Know with your help it turned very clear.

Thanks again !



Atenciosamente,

João Carvalho

* - mailto:***@caixaseguros.pt

"Em momentos de crise, só a imaginação é mais importante que o conhecimento"

(Albert Einstein)

P Antes de imprimir este e-mail pense bem se tem mesmo que o fazer. Há cada vez menos árvores



-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of McKown, John
Sent: terça-feira, 3 de Julho de 2007 13:36
To: TSO-***@VM.MARIST.EDU
Subject: Re: [TSO-REXX] MVS Data Areas



> -----Original Message-----

> From: TSO REXX Discussion List

> [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of João Luís Matos

> Carvalho (DSI)

> Sent: Tuesday, July 03, 2007 4:45 AM

> To: TSO-***@VM.MARIST.EDU

> Subject: Re: [TSO-REXX] MVS Data Areas

>

> Hello again,



Greetings. I will mention that this question is not really about REXX in a TSO environment. It might have been better to ask this on IBM-MAIN.



>

> I've been reading how to get for example the Jobname.

>

> For I've read, I've to go to PSA, then, obtain the TCB

> address, get the TIOT address and then the Jobname.



This is only one way. There are others.



>

> In the "MVS Data Areas books", I've got the following :

>

> PSA (get the TCB address) --> Offset Dec (540) Hex (21C)

>

> TCB (get the TIOT address) --> Offset Dec (12) Hex (C)

>

> In TCB I find that the OFFSET is 12, but I found a program

> that don't have that, but the information returned is

> correct. The code is like this (the addresses don't match).

> Get someone tell me why ?

>

> PSA SET ADDRESS OF L-AREA1 TO NULL



This does indeed set L-AREA1 to point to the PSA. So far, so good.



>

>

> TCB SET ADDRESS OF L-AREA1 TO L-AREA1-PTR(136)



OK, assuming L-AREA1-PTR is a normal COBOL "occurs" of POINTERs. This gets the address at offset (136-1)*4 or 540. This is the field PSATOLD which does indeed point to the current TCB.



>

> TIOT SET ADDRESS OF L-AREA2 TO L-AREA1-PTR(4)



Again, with the same logic as above, the offset is (4-1)*3 or 12, which is indeed the TIOT address. So L-AREA2 points to the TIOT.



>

> MOVE L-AREA2(1:8) TO MX298-JOB-NAME



Do a "reference modification" to pick up the first 8 bytes of the TIOT, which contains the job name.



>

> Atenciosamente,

>

> João Carvalho



Remember that COBOL starts all subscripts at 1, not 0. So to find the offset, you must subtract 1 from the array index before multiplying by the array element size.



--

John McKown

Senior Systems Programmer

HealthMarkets

Keeping the Promise of Affordable Coverage

Administrative Services Group

Information Technology



The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.



----------------------------------------------------------------------

For TSO-REXX subscribe / signoff / archive access instructions,

send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Loading...