(too old to reply)
TSSO help please
Neal Eckhardt
2011-04-13 14:40:30 UTC
I am trying to get TSSO running, and I have run into a problem the worst of
which is being a newbie to TSSO. The OSCMD command works fine in a CLIST,
but I prefer to use REXX. I originally tried setting CMDRESP= 'CLIST' but found
out with a Instruction trace that while the code finds the variable, the value
is inaccessable from the code. I spend most of the day learning a valuable
lesson that in a SLIP instruction fetch trace, just because you can see a
memory location in the trace does not mean that the code can see it.

Anyway, after discovering this, the section of the documentation about using
SYSAUTH_MAXCMDOUT finally made sense. So I set SYSAUTH_AUTHCMDOUT
= 200, and made it past the code that was failing. Unfortunately, the code is
now failing in the JCEVCTDB routine with the exact same problem I had before.
The address of the value is being passed to the routine, and the trace shows
it is correct, but I get a S0C4 in the

DECCHK CLI 0(1),C'0'

instruction, and R1 is pointing to the correct value of 200. I thought the
SYSAUTH_MAXCMDOUT value was supposed to be readable, but it appears
that the storage containing the value is not.

Does anybody have any insights in using OSCMD in a REXX program and what
might be causing my issue? Oh yes, all the TSSO commands are in the
AUTHCMD section of IKJTSO00, and the TSSO library is in the LINKLIST.

Thanks,
Neal

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Brian Westerman
2011-04-14 05:40:35 UTC
Hi,

What version of TSSO are you using and what version of z/OS are you using it
under?

Did you assemble TSSO on the level of the system that you are using now?

You can contact me offline if you want to discuss how to set things up
correctly.

Brian Westerman

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Neal Eckhardt
2011-04-14 17:37:23 UTC
Thanks Brian, I replied to your Email address.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Brian Westerman
2011-04-15 08:29:49 UTC
I looked through my old notes and found that JCECVTDB is/was not authorized,
it isn't meant to be, but it also isn't 31bit. Since you are getting an
0C4, is it possible that you have inadvertently assembled/linked things and
made them 31bit?

There are a lot of issues that will pop up over the next few releases of
z/OS with TSSO, mostly because of the changes to the system to support
System REXX, and it's possible also that you have run into some of them. I
think that V1.13 will probably see the end of TSSO as t is now, but the
original code is WELL over 30 years old and 4.3 is something on the order of
25+ years old. Once I saw the "writing on the wall" I decided that the best
course was to re-write it completely and that's what I have been doing for
the past year or so as time permits.

I can't get mine to fail, but I have also modified things a great deal and
no longer really have the old TSSO that you are probably using. I will
download a copy of the old one and give your code a shot, but I wanted to
make sure it wasn't something simple (like the wrong assembly/link parms).

Brian

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Neal Eckhardt
2011-04-15 15:50:51 UTC
I have found that there are several places in the TSSO OSCMD command
where routines are called in 24 bit mode. The documentation for IKJCT441
says you must be in 31 bit mode to process REXX variables. Since the value
for these REXX variables are contained in 31 bit storage, JCECVTDB and
IKJCT441 must be called in 31 bit mode.

Setting the mode before the call, and resetting it after the call has seemed to
fix the problem but now I am getting the message:

$HASP622 RESPONSE LOCATION UNKNOWN UNAVAILABLE

after the command is processed. I will provide updates for this module if I can
get it working.

Neal

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Jim Thomas
2011-04-16 10:13:31 UTC
Neal,

If you think it's pertinent, please check some of the old
APAR's ... I seemed to remember some for the TSO OPER command.

Jim Thomas

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@bama.ua.edu] On Behalf
Of Neal Eckhardt
Sent: Friday, April 15, 2011 10:45 AM
To: IBM-***@bama.ua.edu
Subject: Re: TSSO help please

I have found that there are several places in the TSSO OSCMD command
where routines are called in 24 bit mode. The documentation for IKJCT441
says you must be in 31 bit mode to process REXX variables. Since the value
for these REXX variables are contained in 31 bit storage, JCECVTDB and
IKJCT441 must be called in 31 bit mode.

Setting the mode before the call, and resetting it after the call has seemed
to
fix the problem but now I am getting the message:

$HASP622 RESPONSE LOCATION UNKNOWN UNAVAILABLE

after the command is processed. I will provide updates for this module if I
can
get it working.

Neal

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
W. Kevin Kelley
2011-04-16 19:56:14 UTC
On Fri, 15 Apr 2011 03:28:27 -0500, Brian Westerman
Post by Brian Westerman
There are a lot of issues that will pop up over the next few releases of
z/OS with TSSO, mostly because of the changes to the system to support
System REXX, and it's possible also that you have run into some of them.
Brian,

I would be very curious what those problems are. Changes to z/OS for console
support and for System REXX have been out for several releases now, and
both are stable. I am not aware of any forthcoming changes that affect
either, so I am puzzled by your statement.

W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Brian Westerman
2011-04-18 12:41:58 UTC
I looked into the problem, and I think if you specify "PROFILE
VARSTORAGE(LOW)" at the beginning of your REXX exec, you will be able to run
without changing the convert program to flip in and out of 31 bit and not
have to worry about it during the life of that particular exec. (make sure
you change the program back).

This appears to be the result of the change in z/OS 1.8 that added support
for moving the storage obtained for parms above the line. The
VARSTORAGE(LOW) will make it run like the pre-1.8 method for the life of the
exec that issues the PROFILE VARSTORAGE(LOW) command only. It does not
effect the rest of the system and won't effect the TSSO address space
(except for your exec). It works on my test system that I have installed
the current CBT version of TSSO on with your sample exec.

To answer the other person's question, there are pieces of TSSO that have
not worked correctly for quite some time, there are control block changes
that we have "patched" the module for, but all we really have done is skip
some functions to make the "more important" functions work.

Brian

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html