Hello,
Is there a document or program directory on upgrading IBM SCRT tool. I am
looking for some migration or upgrade consideration notes.
Any Advise or pointers would be appreciated.
z/OS : 2.1
Peter.
--
For IBM-MAIN
What internet searches have you done?
Have you looked on the IBM Web site?
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Tuesday, November 04, 2014 1:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SCRT tool
Hi,
I did but i get the SCRT user guide instead of program directory or any
upgrade notes.
On Tue, Nov 4, 2014 at 2:11 PM, Lizette Koehler stars...@mindspring.com
wrote:
What internet searches have you done?
Have you looked on the IBM Web site?
Lizette
-Original Message-
mf db wrote:
I did but i get the SCRT user guide instead of program directory or any
upgrade notes.
From where? Please post the URL. The manual, details about what-is-new and
other info for upgrades are freely available.
You need to register on IBM and then download the file after accepting
There is TIMEOUT subparameter in CICS segment of user profile in RACF.
AFAIK when there is no CICS segment for the user default values are
taken from the segment of CICS default user.
What in case there is no CICS segment for default user?
What is the timeut value in effect?
Is is 0 (means no
I believe this may be what you are looking for:
Greetings!
IBM is pleased to announce that SCRT Version 23.1.0 is now available from the
SCRT website. Starting with the submission of your SCRT report at the beginning
of November, and until further notice, you must use SCRT V23 to generate
On Mon, 3 Nov 2014 17:18:55 -0600, Barry Merrill wrote:
I'm totally confused. Why would it NOT be better to have a User Return Code
that
explains the single 0C1 or 0C4 (of which I've had so many, they are Oh-Chuck4's
instead of the more formal Oh-Charlie4) or OC7 value. How is that less
...and I was IBM and I had no clue how to find out what
module even had *issued* the message, much less what the
reason code meant.
I'm sorry that you had such a bad time while at IBM.
Long long ago the powers that be edicted that the books are for customers
not for IBM. Therefore (to the
On Tue, 4 Nov 2014 10:43:44 +0100, R.S. wrote:
There is TIMEOUT subparameter in CICS segment of user profile in RACF.
AFAIK when there is no CICS segment for the user default values are
taken from the segment of CICS default user.
What in case there is no CICS segment for default user?
Experience (and
http://www-01.ibm.com/support/knowledgecenter/SSGMCP_4.1.0/com.ibm.cics.ts.resourcedefinition.doc/macros/srt/system.html?cp=SSGMCP_4.1.0%2F12-9-1-3-8-1)
make it clear that system ABEND codes are hex and user codes are decimal. Why?
Or is this lost in the mists of time? It's not
I suspect that one of the original OS/360 developers decided that U0C7 could
easily be confused with S0C7. So they adopted the convention of documenting
and displaying User Abend Codes in decimal vs Hex for System Abends. They are
both unsigned 12 bit numbers, 0 to 4095 in decimal of 000 to
I always thought it was the hex just sort of seemed system-like and
decimal numbers were, you know, for those COBOL types. g
I always wondered why did they put two more or less mutually-exclusive data
in two different 12-bit fields? If they had devoted 11 bits to the ABEND
code and one bit to
Good thought, although the confusion is still possible for, say S122 versus
U122. Of the 4095 possible system ABEND codes, just under a quarter are
valid decimal numbers also.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of
On 4 Nov 2014 02:23:26 -0800, in bit.listserv.ibm-main you wrote:
On Mon, 3 Nov 2014 17:18:55 -0600, Barry Merrill wrote:
I'm totally confused. Why would it NOT be better to have a User Return Code
that
explains the single 0C1 or 0C4 (of which I've had so many, they are
Oh-Chuck4's
instead of
On Tue, 4 Nov 2014 14:30:54 -0800, Charles Mills wrote:
I always thought it was the hex just sort of seemed system-like and
decimal numbers were, you know, for those COBOL types. g
I always wondered why did they put two more or less mutually-exclusive data
in two different 12-bit fields? If they
Yeah, 23. I was thinking in base 22. g
After I wrote it I thought that 23-bit ABEND codes were probably a bit much but
16 bits might have been an improvement on 12, especially since the hardware
provides halfword support and lots of things are in halfwords.
I have never worked on an octal
In response to your REGION question, nope.
REGION[.procstepname]=valueK|valueM
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Tuesday, November 04, 2014 4:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re:
In 007401cff7bc$8a6ceb60$9f46c220$@mxg.com, on 11/03/2014
at 05:18 PM, Barry Merrill ba...@mxg.com said:
I'm totally confused. Why would it NOT be better to have a User
Return Code that explains the single 0C1 or 0C4 (of which I've had
so many, they are Oh-Chuck4's instead of the more formal
On Nov 4, 2014, at 4:21 PM, Roberts, John J wrote:
I suspect that one of the original OS/360 developers decided that
U0C7 could easily be confused with S0C7. So they adopted the
convention of documenting and displaying User Abend Codes in
decimal vs Hex for System Abends. They are both
Ed Gould wrote:
That is nice but how do you handle a vendor that issues say a S001 ?
I say throw their software out with the dirty dishwater.
Agreed. The same [1] goes with SMF record types, SVC ##, messsage prefixes,
SSI prefixes, program module name prefixes, dataset HLQ, etc.
If I find a
20 matches
Mail list logo
