Re: Hex error code interpreter?

[Eric Rossman]

BPXMTEXT is for errno. The return value from gskit calls are not errno s.


From: IBM Mainframe Discussion List  on behalf of Sri 
Hari Kolusu 
Sent: Friday, April 26, 2024 8:38:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [EXTERNAL] Re: Hex error code interpreter?

Phil,

You can use the command TSO EXEC 'SYS1.SBPXEXEC(BPXMTEXT)' 'your 8 digit hex 
code' or $ bpxmtext hexcode from shell to get the description of the errnox .

TSO EXEC 'SYS1.SBPXEXEC(BPXMTEXT)' '0594003D' results in

BPXFVLKP 09/23/23
JRDirNotFound: A directory in the pathname was not found

Action: One of the directories specified was not found.  Verify that the name
specified is spelled correctly.


However, TSO EXEC 'SYS1.SBPXEXEC(BPXMTEXT)' '03353084' just results in BPXFSIT 
10/29/19   which is not that helpful

Thanks,
Kolusu

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

Re: Hex error code interpreter?

[Sri Hari Kolusu]

Phil,

You can use the command TSO EXEC 'SYS1.SBPXEXEC(BPXMTEXT)' 'your 8 digit hex 
code' or $ bpxmtext hexcode from shell to get the description of the errnox .

TSO EXEC 'SYS1.SBPXEXEC(BPXMTEXT)' '0594003D' results in

BPXFVLKP 09/23/23
JRDirNotFound: A directory in the pathname was not found

Action: One of the directories specified was not found.  Verify that the name
specified is spelled correctly.


However, TSO EXEC 'SYS1.SBPXEXEC(BPXMTEXT)' '03353084' just results in BPXFSIT 
10/29/19   which is not that helpful

Thanks,
Kolusu



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

Re: Anyone exploiting ZEDC?

[Russell Witt]

The new release (over a year old, so not so new) of CA 1 Flexible Storage
has an option to exploit z/EDC when writing to tape or to exploit z/EDC and
ACS256 encryption when writing to tape. In both cases, we have an option to
do those both in a zIIP engine if available. On the z16 systems, it screams.
A simple ADRDSSU job can run 30% faster (clock time) with barely an uptick
in CPU usage. Running ADRDSSU with the ZCOMPRESS option goes a little fast
clock-time; but you see a HUGE increase in CPU time. 

But the z/EDC compression chip is wonderful. And running it in the zIIP is
even better.

Russell Witt
Broadcom 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Tuesday, April 16, 2024 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Anyone exploiting ZEDC?

Is anyone exploiting ZEDC data compression accelerator in your environments?
We recently licensed the enablement and are working through the issues in
our DEV environment.

We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets,
but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have
issues.   We've turned back off for now.

There is no central location in any IBM doc(including recent REDBOOKS) that
discusses where we can and cannot leverage ZEDC.   As it stands now, we had
to back out, and looking at taking a new approach in our ACS routines
checking for DSORG=PS, and then if not temp-dataset, or tape assign a DC
with the right options.

What I am wondering is if anyone is further along that can share how they
rolled out?   I really don't want to have to make the applications teams
have to "opt-in" by coding a DC in their JCL or other dataset allocations.

Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.

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

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

Re: Hex error code interpreter?

[Charles Mills]

Well, any UNIX error code interpreter is perforce going to be somewhat 
UNIX-centric.

strerror() I believe interprets errno values. This command interprets errnojr 
values, kind of analogous to reason codes for errno error codes. 

My V2R4 system does not have LOOKAT on it so I can't try it.

I doubt that ChicagoSoft goes to this depth (but I could be wrong). These are 
really obscure and detailed error explanations.

BTW, what is the etymology of errnojr? I always think of it as Errno Junior.

CM

On Fri, 26 Apr 2024 18:20:04 -0500, Paul Gilmartin  wrote:

>On Fri, 26 Apr 2024 18:09:50 -0500, Charles Mills wrote:
>
>>https://www.ibm.com/docs/en/zos-basic-skills?topic=messages-bpxmtext-zos-unix-reason-codes
>> 
>UNIX-centric?  As is SYSCALL STRERROR
>
>Is the network service LOOKAT  current?
>
>Otherwise, there's ChicagoSoft.
>
>-- 
>gil
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Moving from nonFIPS gskkyman dB to a FIPS one

[Charles Mills]

And just to add to the fun, some of the certificates may refuse to import 
because of non-FIPS algorithms.

Charles

On Fri, 26 Apr 2024 11:26:20 -0500, Charles Mills  wrote:

>That is my *impression*, that there is no easier way.
>
>CM
>
>On Thu, 25 Apr 2024 07:36:54 -0400, Mark Regan  wrote:
>
>>At a site I support we need to start using FIPS mode. At the present our
>>certificates are in gskkyman database that was not set up to support FIPS.
>>From what I understand we have to export the certificates from the non-FIPS
>>database and then import them into a new FIPS one. Since we have many
>>certificates is there a simpler way of doing this?
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Hex error code interpreter?

[Paul Gilmartin]

On Fri, 26 Apr 2024 18:09:50 -0500, Charles Mills wrote:

>https://www.ibm.com/docs/en/zos-basic-skills?topic=messages-bpxmtext-zos-unix-reason-codes
> 
UNIX-centric?  As is SYSCALL STRERROR

Is the network service LOOKAT  current?

Otherwise, there's ChicagoSoft.

-- 
gil

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

Re: Hex error code interpreter?

[Charles Mills]

https://www.ibm.com/docs/en/zos-basic-skills?topic=messages-bpxmtext-zos-unix-reason-codes

Although it is coming up with nonsense for your error code on my V2R4 system. I 
can try it on a V3R1 system if you really need.

I also have code somewhere for calling the underlying service (not the shell 
command) from code if you want.

Charles

On Fri, 26 Apr 2024 18:16:00 -0400, Phil Smith III  wrote:

>Did I dream it, or is there some utility that can take an error such as
>gsk_encrypt_tls13_record(): AES GCM Encryption failed: Error 0x03353084
>and interpret the 0x03353084? I swear I remember seeing this but can't find it 
>now. Getting old sucks*.

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

Re: finding callers key in svc

[Seymour J Metz]

MODEST. An SVC that calls another SVC. ...

Multithreading would normally involve multiple TCBs.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Erik Janssen <062c999269e8-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 26, 2024 6:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: finding callers key in svc

On Fri, 26 Apr 2024 21:36:36 +, Seymour J Metz  wrote:

>NO! Use RBOPSW; the caller might not be in the PSW key.
>
>--

Could you explain in what situation that happens? Is that when the task is 
multihreaded and another thread has changed the key in the psw in between the 
call to the svc and the time of looking at the psw?
Thank you all for the quick reponses by the way :-)

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


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

Hex error code interpreter?

[Phil Smith III]

Did I dream it, or is there some utility that can take an error such as
gsk_encrypt_tls13_record(): AES GCM Encryption failed: Error 0x03353084
and interpret the 0x03353084? I swear I remember seeing this but can't find it 
now. Getting old sucks*.

*But consider the alternatives.

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

Re: finding callers key in svc

[Erik Janssen]

On Fri, 26 Apr 2024 21:36:36 +, Seymour J Metz  wrote:

>NO! Use RBOPSW; the caller might not be in the PSW key.
>
>--

Could you explain in what situation that happens? Is that when the task is 
multihreaded and another thread has changed the key in the psw in between the 
call to the svc and the time of looking at the psw?
Thank you all for the quick reponses by the way :-)

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

Re: finding callers key in svc

[Seymour J Metz]

NO! Use RBOPSW; the caller might not be in the PSW key.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Erik Janssen <062c999269e8-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 26, 2024 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: finding callers key in svc

It is a type 3 svc.
I also saw an example that uses the TCBPKF field to determine the key. So I 
guess that is also an option?

On Fri, 26 Apr 2024 20:20:26 +, Seymour J Metz  wrote:

>What type of SVC? The SVRB only exists for 3, 3 and 4.
>
>--

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


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

Re: BPX COND_SETUP/COND_WAIT, the SIR and "pushing back" signals

[Tony Harminc]

On Fri, 26 Apr 2024 at 14:48, Thomas David Rivers  wrote:
[...]

>  I did find APAR PK80435 that references OTCBCTWACTIVE but couldn't find
> any documentation
>  on the bit itself, and I don't know if it's a programmable interface
>
>  IBM very carefully claims:
>
> Only the following fields are externally documented. All other fields
> are reserved for IBM use only.
> OtcbThli
> OtcbWLMEToken
> OtcbSigPending
> OtcbOapb
>
>  Any thoughts?
>

On the narrow issue of what's a Programming Interface in the OTCB,
historically all the documented z/OS UNIX control blocks were BPXY, and
the OCO ones were BPXZ. Over time a few of the BPXZs have been shipped,
but generally with only a very few fields marked as PI, and in one case
(OAPB) with only the newly exposed fields shipped as a stripped down
assembler version of the larger PL/X structure.

On the larger frustrating issue you're working on, I think the best bet is
to open a ticket with IBM; if the doc does not provide enough information
to write a program using an interface, then IBM needs to fix it. Ideally
some IBMer would say to you (or here...) that "this field is improperly not
documented, we'll document how to use it in the next edition, and in the
meantime here's how to use it". This has certainly happened before, though
I don't remember z/OS UNIX being a hotbed of such revelations.

Tony H.

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

Re: finding callers key in svc

[Erik Janssen]

It is a type 3 svc. 
I also saw an example that uses the TCBPKF field to determine the key. So I 
guess that is also an option?

On Fri, 26 Apr 2024 20:20:26 +, Seymour J Metz  wrote:

>What type of SVC? The SVRB only exists for 3, 3 and 4.
>
>--

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

Re: finding callers key in svc

[Seymour J Metz]

What type of SVC? The SVRB only exists for 3, 3 and 4.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Erik Janssen <062c999269e8-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 26, 2024 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: finding callers key in svc

Hello List,

Is there way to determine the key that the caller of a SVC is executing in? For 
a PC routine doing an ESTA and some shifting seems to be the way to find the 
key, but I'm unsure how the same could be done from a user SVC.
Is it somewhere in the SVRB?
Also, I see this example in the authorized code scanner:
https://www.ibm.com/docs/en/zos/2.4.0?topic=fixes-fetch-vulnerability-example

vulnerable:
   LA R3,copyparms
   MVC 0(4,R3),0(R2)

fixed:
LHI R3,1
ESTA R0,R3
SRDL R0,48
LHI R0,3
LA R3,copyparms
MVCSK 0(R3),0(R2)

I noticed that the length loading in R0 for the MVCSK is 3, while in the 
vulnerable mvc example the length is 4.
The POP for MVCSK says:
L specifies the number of bytes to the right of the first
byte of each operand. Therefore, the length in bytes
of each operand is 1-256, corresponding to a length
code in L of 0-255.

Is there any logic behind why MVC uses the actual byte count and MVCSK uses the 
'number of bytes to the right'?

Kind regards,
Erik Janssen.



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

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

Re: finding callers key in svc

[Wayne Driscoll]

The key is in the RBOPSW of the callers RB. As for the byte count, MVCSK
uses the same format of the length in the register as you would use in EX
instruction, 1 less than the actual length. Also, if you look at the
assembly listing for an MVC, for example MVC  0(8,R3),0(R8) the assembler
will generate D207 3000 8000, so it uses the a length of 1 less than the
length.

Wayne Driscoll
Note: All opinions strictly my own.

On Fri, Apr 26, 2024 at 2:21 PM Erik Janssen <
062c999269e8-dmarc-requ...@listserv.ua.edu> wrote:

> Hello List,
>
> Is there way to determine the key that the caller of a SVC is executing
> in? For a PC routine doing an ESTA and some shifting seems to be the way to
> find the key, but I'm unsure how the same could be done from a user SVC.
> Is it somewhere in the SVRB?
> Also, I see this example in the authorized code scanner:
>
> https://www.ibm.com/docs/en/zos/2.4.0?topic=fixes-fetch-vulnerability-example
>
> vulnerable:
>LA R3,copyparms
>MVC 0(4,R3),0(R2)
>
> fixed:
> LHI R3,1
> ESTA R0,R3
> SRDL R0,48
> LHI R0,3
> LA R3,copyparms
> MVCSK 0(R3),0(R2)
>
> I noticed that the length loading in R0 for the MVCSK is 3, while in the
> vulnerable mvc example the length is 4.
> The POP for MVCSK says:
> L specifies the number of bytes to the right of the first
> byte of each operand. Therefore, the length in bytes
> of each operand is 1-256, corresponding to a length
> code in L of 0-255.
>
> Is there any logic behind why MVC uses the actual byte count and MVCSK
> uses the 'number of bytes to the right'?
>
> Kind regards,
> Erik Janssen.
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne Driscoll
Software Engineer | Mainframe Software Division
Broadcom Software

*Office: *630-300-1931* Mobile:* 630-247-1632
wayne.drisc...@broadcom.com

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

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

finding callers key in svc

[Erik Janssen]

Hello List,

Is there way to determine the key that the caller of a SVC is executing in? For 
a PC routine doing an ESTA and some shifting seems to be the way to find the 
key, but I'm unsure how the same could be done from a user SVC.
Is it somewhere in the SVRB? 
Also, I see this example in the authorized code scanner:
https://www.ibm.com/docs/en/zos/2.4.0?topic=fixes-fetch-vulnerability-example

vulnerable:
   LA R3,copyparms
   MVC 0(4,R3),0(R2)

fixed:
LHI R3,1
ESTA R0,R3 
SRDL R0,48 
LHI R0,3 
LA R3,copyparms 
MVCSK 0(R3),0(R2)

I noticed that the length loading in R0 for the MVCSK is 3, while in the 
vulnerable mvc example the length is 4. 
The POP for MVCSK says:
L specifies the number of bytes to the right of the first
byte of each operand. Therefore, the length in bytes
of each operand is 1-256, corresponding to a length
code in L of 0-255.

Is there any logic behind why MVC uses the actual byte count and MVCSK uses the 
'number of bytes to the right'?

Kind regards,
Erik Janssen.



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

Re: BPX COND_SETUP/COND_WAIT, the SIR and "pushing back" signals

[Thomas David Rivers]

> 
> And - to follow-up one more time, the SIR documentation from the MVSSIGSETUP
> service has this to say:
> 
> 
>If the interrupt cannot be processed at this time, possibly due to general
>register 13 not currently containing the address of a program stack, or 
> the last
>service called on the current thread was cond_setup, then the 
> queue_interrupt
>service request is issued
> 
> So - my question really is "how can the SIR determine that the last service
> called on the current thread was cond_setup?"
> 
>   - Thanks -
>   - Dave R. -
> 

 So -  to follow-up some more, I did find this field in the BPXZOTCB (OMVS TCB 
extension):

OTCBCTWACTIVE EQU X'02'  cond_timed_wait (BPX1CTW) is active

 (it seems to go all the way back to OS/390 2.10.)


 If that flag is also set whe just cond_wait is active (which would make 
sense), then
 perhaps a possible mechanism is:

   1) Set a flag somewhere indicating cond_setup is about to be called

 a) If a signal arrives at the SIR, check that flag and return any
signals to the kernal via queue_interrupt, unless the 
OTCBCTWACTIVE flag
in the OTCB is set, in which case you clear the flag and let 
the signal proceed.

   2) Invoke cond_setup

   3) Do housekeeping

   4) Invoke cond_wait/cond_timed_wait (which presumably turns on OTCBCTWACTIVE 
in the OTCB).

 That is assuming that the OTCBCTWACTIVE flag is set for both cond_wait and 
cond_timed_wait.

 I did find APAR PK80435 that references OTCBCTWACTIVE but couldn't find any 
documentation
 on the bit itself, and I don't know if it's a programmable interface

 IBM very carefully claims:

Only the following fields are externally documented. All other fields are 
reserved for IBM use only.
OtcbThli
OtcbWLMEToken
OtcbSigPending
OtcbOapb

 Any thoughts?

- Thanks -
- Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: Moving from nonFIPS gskkyman dB to a FIPS one

[Charles Mills]

That is my *impression*, that there is no easier way.

CM

On Thu, 25 Apr 2024 07:36:54 -0400, Mark Regan  wrote:

>At a site I support we need to start using FIPS mode. At the present our
>certificates are in gskkyman database that was not set up to support FIPS.
>From what I understand we have to export the certificates from the non-FIPS
>database and then import them into a new FIPS one. Since we have many
>certificates is there a simpler way of doing this?

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

Re: Netview

[Phil Smith III]

For those who are curious like me, "vel" is Polish for "AKA". That was my 
guess, confirmed via Tha Goog.

Not throwing shade at Radoslaw, whose English is better than that of a lot of 
folks on the list who are native speakers!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, April 26, 2024 7:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Netview

It is not so easy.
Do you know IWS vel TWS vel Workload Scheduler?
It is still being sold by IBM, but development is out of IBM.
The same for SDSF (Rocket), PCOMM (HCL), Omegamon, etc. The list is longer.
And it is nothing new IMHO, as far as I remember ESCON Director was also third 
party product under IBM logo.

Note, JES3 and z/VSE are different - in both cases products are supported and 
marketed by their current producers - that means PSI and 21CS.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 26.04.2024 o 07:38, Bruce Hewson pisze:
> Hello Steve,
>
> FUD
>
> "IBM Netview for Z/OS" is still being sold and supported by IBM, and is a 
> pre-req for IBM System Automation and GDPS.  No evidence that this product 
> has been sold.
>
> On Wed, 24 Apr 2024 16:19:17 -0500, Steve Beaver  
> wrote:
>
>> My understanding is that IBM sold off Netview.
>>
>> Who did they sell it to?
>>
>>
>> Sent from my iPhone
>>
>> No one said I could type with one thumb
>>
>
> Regards
> Bruce Hewson
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Netview

[Steve Beaver]

Thank you.  IBM has sold or pushed support of we need a program to know what is 
what 

Sent from my iPhone

No one said I could type with one thumb 

> On Apr 26, 2024, at 06:22, Radoslaw Skorupka 
> <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
> 
> It is not so easy.
> Do you know IWS vel TWS vel Workload Scheduler?
> It is still being sold by IBM, but development is out of IBM.
> The same for SDSF (Rocket), PCOMM (HCL), Omegamon, etc. The list is longer.
> And it is nothing new IMHO, as far as I remember ESCON Director was also 
> third party product under IBM logo.
> 
> Note, JES3 and z/VSE are different - in both cases products are supported and 
> marketed by their current producers - that means PSI and 21CS.
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> W dniu 26.04.2024 o 07:38, Bruce Hewson pisze:
>> Hello Steve,
>> 
>> FUD
>> 
>> "IBM Netview for Z/OS" is still being sold and supported by IBM, and is a 
>> pre-req for IBM System Automation and GDPS.  No evidence that this product 
>> has been sold.
>> 
>>> On Wed, 24 Apr 2024 16:19:17 -0500, Steve Beaver  
>>> wrote:
>>> 
>>> My understanding is that IBM sold off Netview.
>>> 
>>> Who did they sell it to?
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>> No one said I could type with one thumb
>>> 
>> 
>> Regards
>> Bruce Hewson
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Netview

[Radoslaw Skorupka]

It is not so easy.
Do you know IWS vel TWS vel Workload Scheduler?
It is still being sold by IBM, but development is out of IBM.
The same for SDSF (Rocket), PCOMM (HCL), Omegamon, etc. The list is longer.
And it is nothing new IMHO, as far as I remember ESCON Director was also 
third party product under IBM logo.


Note, JES3 and z/VSE are different - in both cases products are 
supported and marketed by their current producers - that means PSI and 21CS.


--
Radoslaw Skorupka
Lodz, Poland



W dniu 26.04.2024 o 07:38, Bruce Hewson pisze:

Hello Steve,

FUD

"IBM Netview for Z/OS" is still being sold and supported by IBM, and is a 
pre-req for IBM System Automation and GDPS.  No evidence that this product has been sold.

On Wed, 24 Apr 2024 16:19:17 -0500, Steve Beaver  wrote:


My understanding is that IBM sold off Netview.

Who did they sell it to?


Sent from my iPhone

No one said I could type with one thumb



Regards
Bruce Hewson

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


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

Re: Control Block field that provides the last USS System-Call?

[Thomas David Rivers]

Thanks Rob!

Unfortunately - this is intended to be used in a SIR that needs to answer
the question of "was the last service a cond_setup?" to be able to "push back"
a signal, without calling a BPX service.  (Calling a BPX service breaks
the cond_setup.)

IBM documents that the SIR needs to "push back" the signal after a cond_setup,
but doesn't seem to document how the SIR can determine that happened.

I've been scouring control blocks looking for the flag that cond_setup must
be setting, but can't seem to find it... so I was hoping that there was a field
somewhere that held an indicator of the last service invoked.

Thanks for the pointer!

   - Dave

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

Re: Control Block field that provides the last USS System-Call?

[Rob Scott]

Dave

The only method I can think of is using PGTHJSYSCALL (and PGTHJPREVSC) from the 
BPX1GTH service.

I would not be surprised if the information is actually held inside control 
blocks in OMVS address space rather than the user/caller.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Thomas David Rivers
Sent: Thursday, April 25, 2024 9:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Control Block field that provides the last USS System-Call?

EXTERNAL EMAIL



I've been scouring control-blocks wondering if there is a field somewhere
that happens to provide the most recent USS system-call (to be able
to, in a SIR, determine of cond_setup was the most recent call.)

Does anyone happen to know if that exists somewhere?

- Many thanks -
- Dave Rivers -

--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at 
http://www.dignus.com

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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