NRSTR

[Greg Price-3]

In case anyone has been hampered by the lack of the
&NRSTR built-in function in TSO CLIST under MVS 3.8,
I'd just like to report that it is now included in the
latest rework of usermod ZP60014 downloadable from

http://www.prycroft6.com.au/vs2mods/

Cheers,
Greg

[kerravon86]

--- In H390-MVS@..., "Greg Price" <greg.price@...> wrote:
>
> In case anyone has been hampered by the lack of the
> &NRSTR built-in function in TSO CLIST under MVS 3.8,
> I'd just like to report that it is now included in the
> latest rework of usermod ZP60014 downloadable from
>
> http://www.prycroft6.com.au/vs2mods/

Thanks Greg. Someone was having trouble with that
just the other day.

Now the "only" thing that is missing is mixed case. :-)

BFN.  Paul.

[Greg Price-3]

On Sun, 23 Aug 2009 11:44:10 -0000, kerravon86 wrote:

>Thanks Greg. Someone was having trouble with that
>just the other day.

>Now the "only" thing that is missing is mixed case. :-)

>BFN. Paul.

Yes, I did receive a request for the enhancement after
the reference to NRSTR was made over on os380.

AFAICT there are general uppercase/lowercase
translate tables which are also used to lowercase
control characters (ampersand to x'10', for example)
so that they only get interpreted when appropriate.

I think this means that control code translations would
need to be decoupled from the alphabetic string data
translations.  Then there is the &SYSCAPS and &SYSLC
built-in functions to tack in.

While that might all be doable in due course (though
taking much longer than adding &NRSTR I'd guess),
probably the most significant thing to implement is
the CONTROL ASIS and CONTROL CAPS settings.

And then there is the whole question of adding the
variables that CLISTs can test and optionally set
to control CONTROL settings.  As well as the ones
for existing settings (such as &SYSPROMPT, &SYSLIST,
&SYSCONLIST, etc.) we'd be looking at adding
&SYSASIS which is OFF in the classic situation and
ON to allow the preservation of lower case letters.

A non-trivial exercise, I'd reckon...

Cheers,
Greg

[kerravon86]

--- In H390-MVS@..., "Greg Price" <greg.price@...> wrote:
>
> While that might all be doable in due course (though
> taking much longer than adding &NRSTR I'd guess),
> probably the most significant thing to implement is
> the CONTROL ASIS and CONTROL CAPS settings.
>
> A non-trivial exercise, I'd reckon...

Well maybe people should be using rexx anyway. I
believe that is the modern thing to do.

What would it take to get /* rexx */ recognized
and get brexx invoked?

BFN.  Paul.

[halfmeg]

> kerravon86 wrote:

<snip>

> What would it take to get /* rexx */ recognized
> and get brexx invoked?

Wouldn't a quick and simple method be to rename the initial CLIST module with a usermod which passes control to brexx if REXX is in header and defaults to the newly named CLIST module for all others.

If there is some dependency on keeping the current modules as they are, create a usermod to intercept all TSO calls, pass everything though except REXX in header.

Phil - maybe totally off base as well

[somitcw-2]

--- In H390-MVS@..., "kerravon86"
 <kerravon86@...> wrote:

> --- In H390-MVS@...,
>"Greg Price" <greg.price@> wrote:
>> While that might all be doable in due course (though
>>taking much longer than adding &NRSTR I'd guess),
>>probably the most significant thing to implement is
>>the CONTROL ASIS and CONTROL CAPS settings.
>> A non-trivial exercise, I'd reckon...
> Well maybe people should be using rexx anyway. I
> believe that is the modern thing to do.
> What would it take to get /* rexx */ recognized
> and get brexx invoked?
> BFN.  Paul.

   CLIST processing calling BRexx if the first
comment in the CLIST contains Rexx would make
MVS 3.8j act like TSO/E on zOS.  That would be
great.  It would have to be smart enough to not
call BRexx if BLDL fails.  Some people don't have
BRexx or the support needed.

   The ASIS support on CONTROL and &SYSASIS support
in WRITE and WRITENR would also be a great improvement.

[kerravon86]

--- In H390-MVS@..., "somitcw" <somitcw@...> wrote:

>
> > Well maybe people should be using rexx anyway. I
> > believe that is the modern thing to do.
> > What would it take to get /* rexx */ recognized
> > and get brexx invoked?
>
>    CLIST processing calling BRexx if the first
> comment in the CLIST contains Rexx would make
> MVS 3.8j act like TSO/E on zOS.  That would be
> great.  It would have to be smart enough to not
> call BRexx if BLDL fails.  Some people don't have
> BRexx or the support needed.

Simply stating that brexx is a prereq should be all
that is required.

Not sure what "support" is required. Just copy the
brexx load module into sys2.linklib on any version
of MVS and it's a done deal. Not sure that it works
on MVT or earlier, but then I'm not sure they have
TSO either.

BFN.  Paul.

[somitcw-2]

--- In H390-MVS@...,
 "kerravon86" <kerravon86@...> wrote:

> --- In H390-MVS@...,
>"somitcw" <somitcw@> wrote:
>>> Well maybe people should be using rexx anyway. I
>>>believe that is the modern thing to do.
>>>What would it take to get /* rexx */ recognized
>>>and get brexx invoked?
>> CLIST processing calling BRexx if the first
>>comment in the CLIST contains Rexx would make
>>MVS 3.8j act like TSO/E on zOS.  That would be
>>great.  It would have to be smart enough to not
>>call BRexx if BLDL fails.  Some people don't have
>>BRexx or the support needed.
> Simply stating that brexx is a prereq should be all
>that is required.

   It's too late to "Simply state".

   People are already running CLIST in MVS 3.8j
without BRexx installed.  If someone puts a
Rexx exec in SYSPROC or SYSEXEC, why not tell
them why it isn't working?

   Also, someone might want to play with some Rexx
other than BRexx?

> Not sure what "support" is required. Just copy the
>brexx load module into sys2.linklib on any version
>of MVS and it's a done deal. Not sure that it works
>on MVT or earlier, but then I'm not sure they have
>TSO either.
> BFN.  Paul.

   MVT does have TSO.

   Does BRexx require GCC, above the line memory,
MVS dependencies not in MVT, or anything else that
should be considered.

   I will locate and copy the BRexx load module
into my SYS2.LINKLIB and will have backup in case
the system will no longer IPL.

[kerravon86]

--- In H390-MVS@..., "somitcw" <somitcw@...> wrote:

>
> --- In H390-MVS@...,
>  "kerravon86" <kerravon86@> wrote:
> > --- In H390-MVS@...,
> >"somitcw" <somitcw@> wrote:
> >>> Well maybe people should be using rexx anyway. I
> >>>believe that is the modern thing to do.
> >>>What would it take to get /* rexx */ recognized
> >>>and get brexx invoked?
> >> CLIST processing calling BRexx if the first
> >>comment in the CLIST contains Rexx would make
> >>MVS 3.8j act like TSO/E on zOS.  That would be
> >>great.  It would have to be smart enough to not
> >>call BRexx if BLDL fails.  Some people don't have
> >>BRexx or the support needed.
> > Simply stating that brexx is a prereq should be all
> >that is required.
>
>    It's too late to "Simply state".

Why? They haven't installed the usermod yet.

>    People are already running CLIST in MVS 3.8j
> without BRexx installed.  If someone puts a
> Rexx exec in SYSPROC or SYSEXEC, why not tell
> them why it isn't working?

In the documentation for the usermod? Sure, why not.

>    Also, someone might want to play with some Rexx
> other than BRexx?

Documentation for the usermod can say where to
change the name of the rexx processor too.

> > Not sure what "support" is required. Just copy the
> >brexx load module into sys2.linklib on any version
> >of MVS and it's a done deal. Not sure that it works
> >on MVT or earlier, but then I'm not sure they have
> >TSO either.
>
>    MVT does have TSO.

Ok, we're in with a shot then.

>    Does BRexx require GCC, above the line memory,

No. BREXX is a stock standard MVS 3.8j 24-bit
executable.

> MVS dependencies not in MVT, or anything else that
> should be considered.

BREXX uses PDPCLIB. Specifically it uses mvssupa.asm.
If you've ever spent any time looking at the mvssupa
code, you would know that it uses macros like OPEN,
GET, PUT. I'm not familiar with MVT, but my guess is
that if it has TSO, it probably also has those
macros.

>    I will locate and copy the BRexx load module
> into my SYS2.LINKLIB and will have backup in case
> the system will no longer IPL.

It doesn't run APF authorized. If your operating
system can't cope with a non-APF-authorized module
doing whatever it wants (short of calling the
magic SVC **), then I suggest you buy a better
operating system.

BFN.  Paul.


(**) And you can simply disable the magic SVC if you
think the program is "one of them".

[halfmeg]

> halfmeg wrote:

> > kerravon86 wrote:

> <snip>

> Phil - maybe totally off base as well

Or maybe modify this guy:

IKJCT432 - EXEC RECORD SCAN ROUTINE

down around the  COMMAND SCAN ROUTINE

Phil - again maybe off base

[Gerhard Postpischil]

halfmeg wrote:
> IKJCT432 - EXEC RECORD SCAN ROUTINE
> down around the  COMMAND SCAN ROUTINE
> Phil - again maybe off base

Thanks. It's in MVSSRC.SYM103.F09, but when I assembled it, it
was larger than the load module in the current system. So I'll
need to assemble and see what got changed.


Gerhard Postpischil
Bradford, VT