subject:"Ignorant z\/OS question"

I'm saying that you are lying about what we disagree about.

When you launch gratuitous ad hominem attacks on me then you have forfeited any 
claim to respect.

From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Sunday, July 30, 2023 6:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Sunday, July 30, 2023 at 01:11:05 PM PDT, Seymour J Metz  
 > wrote:
> You are repeating the same old lie.

What lie are you saying I'm repeating? z/VM console 3215 for screen scraping? 
Are you saying you asked a question in trying to understand my point? Are you 
saying as your message didn't imply, it's inconceivable my I point may have 
merit? Are you saying your last message was in any way an attempt to show any 
type of respect for my opinion? Are you saying that your response was not 
intended to deny all possibility that you could be wrong and I may have a valid 
point.

What is the lie? See-more Putz proving you can't fix stupid. Is this really the 
direction you want to take this?

On Sunday, July 30, 2023 at 01:11:05 PM PDT, Seymour J Metz 
 wrote:

 You are repeating the same old lie. In fact, I am aware that I sumetimes err 
and I have thanked people one this list for correcting errors that I have made. 
Can you honestly make the same claim?

I will consistently respect opinions for others when they have a basis in fact. 
I, however, do not suffer fools gladly and do not respect the opinions of those 
who deliberately misrepresent what is in contention.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Sunday, July 30, 2023 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Sunday, July 30, 2023 at 09:04:58 AM PDT, Seymour J Metz  
 > wrote:
> WTF? It has nothing to do with screen scraping. It has to do with addresses 
> and device types matching.

Once again Seymour fails to ask even one basic question to determine if there 
is any merit. Seymour's incompetence once again demands I must be wrong because 
it's inconceivable that anyone can be more knowledgeable than he.

z/OS 3270 to z/VM 3215 CONSOLE to a SECUSER running z/VM PROP to capture the 
3270 data stream. Only a couple more pieces of the puzzle to figure out and you 
can quickly prototype a screen scraper. If someone wants to see 3270 data 
stream, they have easy access through z/VM 3215 console. Device mismatching has 
it's uses.

Seymour, in the future, do you plan on respecting opinions from others or will 
you continue to insist that your opinion is the only one with true merit and 
that you can't possibly be wrong?

--
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

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

Re: Ignorant z/OS question

 > On Sunday, July 30, 2023 at 01:11:05 PM PDT, Seymour J Metz  
 > wrote:
> You are repeating the same old lie.

What lie are you saying I'm repeating? z/VM console 3215 for screen scraping? 
Are you saying you asked a question in trying to understand my point? Are you 
saying as your message didn't imply, it's inconceivable my I point may have 
merit? Are you saying your last message was in any way an attempt to show any 
type of respect for my opinion? Are you saying that your response was not 
intended to deny all possibility that you could be wrong and I may have a valid 
point.

What is the lie? See-more Putz proving you can't fix stupid. Is this really the 
direction you want to take this?

On Sunday, July 30, 2023 at 01:11:05 PM PDT, Seymour J Metz 
 wrote:  

 You are repeating the same old lie. In fact, I am aware that I sumetimes err 
and I have thanked people one this list for correcting errors that I have made. 
Can you honestly make the same claim?

I will consistently respect opinions for others when they have a basis in fact. 
I, however, do not suffer fools gladly and do not respect the opinions of those 
who deliberately misrepresent what is in contention.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Sunday, July 30, 2023 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Sunday, July 30, 2023 at 09:04:58 AM PDT, Seymour J Metz  
 > wrote:
> WTF? It has nothing to do with screen scraping. It has to do with addresses 
> and device types matching.

Once again Seymour fails to ask even one basic question to determine if there 
is any merit. Seymour's incompetence once again demands I must be wrong because 
it's inconceivable that anyone can be more knowledgeable than he.

z/OS 3270 to z/VM 3215 CONSOLE to a SECUSER running z/VM PROP to capture the 
3270 data stream. Only a couple more pieces of the puzzle to figure out and you 
can quickly prototype a screen scraper. If someone wants to see 3270 data 
stream, they have easy access through z/VM 3215 console. Device mismatching has 
it's uses.

Seymour, in the future, do you plan on respecting opinions from others or will 
you continue to insist that your opinion is the only one with true merit and 
that you can't possibly be wrong?

--
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: Ignorant z/OS question

You are repeating the same old lie. In fact, I am aware that I sumetimes err 
and I have thanked people one this list for correcting errors that I have made. 
Can you honestly make the same claim?

I will consistently respect opinions for others when they have a basis in fact. 
I, however, do not suffer fools gladly and do not respect the opinions of those 
who deliberately misrepresent what is in contention.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Sunday, July 30, 2023 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Sunday, July 30, 2023 at 09:04:58 AM PDT, Seymour J Metz  
 > wrote:
> WTF? It has nothing to do with screen scraping. It has to do with addresses 
> and device types matching.

Once again Seymour fails to ask even one basic question to determine if there 
is any merit. Seymour's incompetence once again demands I must be wrong because 
it's inconceivable that anyone can be more knowledgeable than he.

z/OS 3270 to z/VM 3215 CONSOLE to a SECUSER running z/VM PROP to capture the 
3270 data stream. Only a couple more pieces of the puzzle to figure out and you 
can quickly prototype a screen scraper. If someone wants to see 3270 data 
stream, they have easy access through z/VM 3215 console. Device mismatching has 
it's uses.

Seymour, in the future, do you plan on respecting opinions from others or will 
you continue to insist that your opinion is the only one with true merit and 
that you can't possibly be wrong?

--
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: Ignorant z/OS question

 > On Sunday, July 30, 2023 at 09:04:58 AM PDT, Seymour J Metz  
 > wrote:
> WTF? It has nothing to do with screen scraping. It has to do with addresses 
> and device types matching.

Once again Seymour fails to ask even one basic question to determine if there 
is any merit. Seymour's incompetence once again demands I must be wrong because 
it's inconceivable that anyone can be more knowledgeable than he.

z/OS 3270 to z/VM 3215 CONSOLE to a SECUSER running z/VM PROP to capture the 
3270 data stream. Only a couple more pieces of the puzzle to figure out and you 
can quickly prototype a screen scraper. If someone wants to see 3270 data 
stream, they have easy access through z/VM 3215 console. Device mismatching has 
it's uses.

Seymour, in the future, do you plan on respecting opinions from others or will 
you continue to insist that your opinion is the only one with true merit and 
that you can't possibly be wrong? 

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

Re: Ignorant z/OS question

> In what world were you spot on?

The real one.

> screen scraping 

WTF? It has  nothing to do with screen scraping. It has to do with addresses 
and device types matching.

From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Sunday, July 30, 2023 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Sunday, July 30, 2023 at 02:05:59 AM PDT, Seymour J Metz  
 > wrote:
> I was spot on when I wrote that the CP and z/OS definitions had to be in 
> synch.

In what world were you spot on? There is a huge difference between must and 
should. In this case, out of synch is a solution for 3270 screen scraping which 
was not useful for Phil's problem but it does solve a useful problem. More 
important at that point, we suspected but did not know the behavior of mixing 
3270 with 3215. It could have potentially led to a better solution than Phil's 
current solution to his problem. Why are you saying that out of synch can't 
possibly have a useful purpose?
You haven't learned a thing. You don't have the humility to even consider you 
might not understand and be wrong. Instead, you demand we hold your opinion in 
reverence even when it throws a monkey wrench into the works. Is this something 
we both learn from?
On Sunday, July 30, 2023 at 02:05:59 AM PDT, Seymour J Metz 
 wrote:

 > If I'm continually "wrong again", how is it that we arrived at the solution?

When you perpetually launch ad hominem attacks, it's difficult to justify the 
claime that you are being civil.

> Does anyone think that Seymour was leading Phil towards a solution to his 
> problem?

Only those who actually read what I wrote, instead of reflexively attacking me. 
I was spot on when I wrote that the CP and z/OS definitions had to be in synch.

> Disagreements are expected but complete dismissal is not acceptable.

And yet, complete dismissal seems to be your forté.

> I will show respect as long as respect is returned.

That is an outright lie.

> What I've learned is that you are a hypocrite.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Sunday, July 30, 2023 12:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz 
 >  wrote:
> I'm perfectly willing to be civil with people who are civil,

If I'm continually "wrong again", how is it that we arrived at the solution? 
Does anyone think that Seymour was leading Phil towards a solution to his 
problem? I'm civil to those who earn and demonstrate respect instead of 
demanding it. Lack of humility and the inability to understand the value of 
what others say is not a sign of respect. To prattle on about complete nonsense 
is not a sign of respect. What in any way was Seymour's comments being useful 
or informative? With the help of others, I was able to lead Phil to a solution 
for his problem and a solution he understands. I have no doubt that Seymour 
thinks he played a vital role in solving this problem but as he says, the 
devils in the details. I don't expect people to have all the correct answers 
but I do expect humility and respect for everyone in this group (not just me). 
Disagreements are expected but complete dismissal is not acceptable. I will 
show respect as long as respect is returned. As long as everyone is being 
respected, I will return that respect. Time will tell if Seymour has actually 
learned from what I've said.

Please accept my apologies for those who are upset with me but there is a line 
that I will not allow to be crossed without some form of retribution.

On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz 
 wrote:

 I'm perfectly willing to be civil with people who are civil, but when someone 
insists on repeated personal attacks. Take a look at the history of this thread 
and you will see that I have been restrained by comparison.

From: IBM Mainframe Discussion List  on behalf of Jay 
Maynard 
Sent: Saturday, July 29, 2023 6:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Now folks...let's not descend into personal name-calling, how about?

On Sat, Jul 29, 2023 at 4:56 PM Jon Perryman  wrote:

>  > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
> > Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
>
> See-more Putz. What are you saying is wrong with my second sentence that
> says "z/OS has many consoles." which applies to native and z/VM. Can you
> stop with the non-stop nonsense.
>
>   On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J

Re: Ignorant z/OS question

 > On Sunday, July 30, 2023 at 02:05:59 AM PDT, Seymour J Metz  
 > wrote:
> I was spot on when I wrote that the CP and z/OS definitions had to be in 
> synch.

In what world were you spot on? There is a huge difference between must and 
should. In this case, out of synch is a solution for 3270 screen scraping which 
was not useful for Phil's problem but it does solve a useful problem. More 
important at that point, we suspected but did not know the behavior of mixing 
3270 with 3215. It could have potentially led to a better solution than Phil's 
current solution to his problem. Why are you saying that out of synch can't 
possibly have a useful purpose?
You haven't learned a thing. You don't have the humility to even consider you 
might not understand and be wrong. Instead, you demand we hold your opinion in 
reverence even when it throws a monkey wrench into the works. Is this something 
we both learn from?  
On Sunday, July 30, 2023 at 02:05:59 AM PDT, Seymour J Metz 
 wrote:  

 > If I'm continually "wrong again", how is it that we arrived at the solution?

When you perpetually launch ad hominem attacks, it's difficult to justify the 
claime that you are being civil.

> Does anyone think that Seymour was leading Phil towards a solution to his 
> problem?

Only those who actually read what I wrote, instead of reflexively attacking me. 
I was spot on when I wrote that the CP and z/OS definitions had to be in synch.

> Disagreements are expected but complete dismissal is not acceptable.

And yet, complete dismissal seems to be your forté.

> I will show respect as long as respect is returned.

That is an outright lie.

> What I've learned is that you are a hypocrite.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Sunday, July 30, 2023 12:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz 
 >  wrote:
> I'm perfectly willing to be civil with people who are civil,

If I'm continually "wrong again", how is it that we arrived at the solution? 
Does anyone think that Seymour was leading Phil towards a solution to his 
problem? I'm civil to those who earn and demonstrate respect instead of 
demanding it. Lack of humility and the inability to understand the value of 
what others say is not a sign of respect. To prattle on about complete nonsense 
is not a sign of respect. What in any way was Seymour's comments being useful 
or informative? With the help of others, I was able to lead Phil to a solution 
for his problem and a solution he understands. I have no doubt that Seymour 
thinks he played a vital role in solving this problem but as he says, the 
devils in the details. I don't expect people to have all the correct answers 
but I do expect humility and respect for everyone in this group (not just me). 
Disagreements are expected but complete dismissal is not acceptable. I will 
show respect as long as respect is returned. As long as everyone is being 
respected, I will return that respect. Time will tell if Seymour has actually 
learned from what I've said.

Please accept my apologies for those who are upset with me but there is a line 
that I will not allow to be crossed without some form of retribution.

    On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz 
 wrote:

 I'm perfectly willing to be civil with people who are civil, but when someone 
insists on repeated personal attacks. Take a look at the history of this thread 
and you will see that I have been restrained by comparison.

From: IBM Mainframe Discussion List  on behalf of Jay 
Maynard 
Sent: Saturday, July 29, 2023 6:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Now folks...let's not descend into personal name-calling, how about?

On Sat, Jul 29, 2023 at 4:56 PM Jon Perryman  wrote:

>  > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
> > Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
>
> See-more Putz. What are you saying is wrong with my second sentence that
> says "z/OS has many consoles." which applies to native and z/VM. Can you
> stop with the non-stop nonsense.
>
>   On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
>
>  Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jon Perryman 
> Sent: Saturday, July 29, 2023 5:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ignorant z/OS qu

Re: Ignorant z/OS question

2023-07-30 Thread Bill Johnson

Any manager who bases his hiring on what transpires here, is a fool.


Sent from Yahoo Mail for iPhone


On Sunday, July 30, 2023, 8:08 AM, Jay Maynard  wrote:

Do you really think you're accomplishing anything by getting personally
insulting?  ...that is, beyond destroying your own credibility and
potential future job prospects? If I was looking at your resume, I'd think
twice about keeping it instead of sticking it in the nearest shredder.

On Sat, Jul 29, 2023 at 11:17 PM Jon Perryman  wrote:

>  > On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
> > I'm perfectly willing to be civil with people who are civil,
>
> If I'm continually "wrong again", how is it that we arrived at the
> solution? Does anyone think that Seymour was leading Phil towards a
> solution to his problem? I'm civil to those who earn and demonstrate
> respect instead of demanding it. Lack of humility and the inability to
> understand the value of what others say is not a sign of respect. To
> prattle on about complete nonsense is not a sign of respect. What in any
> way was Seymour's comments being useful or informative? With the help of
> others, I was able to lead Phil to a solution for his problem and a
> solution he understands. I have no doubt that Seymour thinks he played a
> vital role in solving this problem but as he says, the devils in the
> details. I don't expect people to have all the correct answers but I do
> expect humility and respect for everyone in this group (not just me).
> Disagreements are expected but complete dismissal is not acceptable. I will
> show respect as long as respect is returned. As long as everyone is being
> respected, I will return that respect. Time will tell if Seymour has
> actually learned from what I've said.
>
> Please accept my apologies for those who are upset with me but there is a
> line that I will not allow to be crossed without some form of retribution.
>
>    On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
>
>  I'm perfectly willing to be civil with people who are civil, but when
> someone insists on repeated personal attacks. Take a look at the history of
> this thread and you will see that I have been restrained by comparison.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jay Maynard 
> Sent: Saturday, July 29, 2023 6:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ignorant z/OS question
>
> Now folks...let's not descend into personal name-calling, how about?
>
> On Sat, Jul 29, 2023 at 4:56 PM Jon Perryman  wrote:
>
> >  > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> > sme...@gmu.edu> wrote:
> > > Wrong again. When running z/OS under VM for production, multiple 3270
> > consoles is the norm.
> >
> > See-more Putz. What are you saying is wrong with my second sentence that
> > says "z/OS has many consoles." which applies to native and z/VM. Can you
> > stop with the non-stop nonsense.
> >
> >    On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> > sme...@gmu.edu> wrote:
> >
> >  Wrong again. When running z/OS under VM for production, multiple 3270
> > consoles is the norm.
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Jon Perryman 
> > Sent: Saturday, July 29, 2023 5:04 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Ignorant z/OS question
> >
> >  > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> > li...@akphs.com> wrote:
> > > After changing the virtual console address from 03E1 to 0009
> > > linemode output went to SECUSER without artifacts
> >
> >
> > Congrats Phil. Here is what you need to know:
> >
> > 1. z/OS has many consoles. You don't have any consoles activated. The
> > hardware console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing
> to
> > do with DEV(3E1) in CONSOL##.
> >
> > 2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the
> > terminal is defined (DEF CONS, DEF GRAF or ATTACH). If someone decides
> they
> > need a console located next to the tape drives and another console next
> to
> > printers, then DEV(SYSCONS) will no longer be automatically activated.
> >
> > 3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default
> for
> > screen full with non-autoscroll messages requires a real person clear the
> > screen. This VM user typically would not be logged on. It could be days
> or
> > week

Re: Ignorant z/OS question

2023-07-30 Thread Jay Maynard

Do you really think you're accomplishing anything by getting personally
insulting?  ...that is, beyond destroying your own credibility and
potential future job prospects? If I was looking at your resume, I'd think
twice about keeping it instead of sticking it in the nearest shredder.

On Sat, Jul 29, 2023 at 11:17 PM Jon Perryman  wrote:

>  > On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
> > I'm perfectly willing to be civil with people who are civil,
>
> If I'm continually "wrong again", how is it that we arrived at the
> solution? Does anyone think that Seymour was leading Phil towards a
> solution to his problem? I'm civil to those who earn and demonstrate
> respect instead of demanding it. Lack of humility and the inability to
> understand the value of what others say is not a sign of respect. To
> prattle on about complete nonsense is not a sign of respect. What in any
> way was Seymour's comments being useful or informative? With the help of
> others, I was able to lead Phil to a solution for his problem and a
> solution he understands. I have no doubt that Seymour thinks he played a
> vital role in solving this problem but as he says, the devils in the
> details. I don't expect people to have all the correct answers but I do
> expect humility and respect for everyone in this group (not just me).
> Disagreements are expected but complete dismissal is not acceptable. I will
> show respect as long as respect is returned. As long as everyone is being
> respected, I will return that respect. Time will tell if Seymour has
> actually learned from what I've said.
>
> Please accept my apologies for those who are upset with me but there is a
> line that I will not allow to be crossed without some form of retribution.
>
> On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
>
>  I'm perfectly willing to be civil with people who are civil, but when
> someone insists on repeated personal attacks. Take a look at the history of
> this thread and you will see that I have been restrained by comparison.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jay Maynard 
> Sent: Saturday, July 29, 2023 6:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ignorant z/OS question
>
> Now folks...let's not descend into personal name-calling, how about?
>
> On Sat, Jul 29, 2023 at 4:56 PM Jon Perryman  wrote:
>
> >  > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> > sme...@gmu.edu> wrote:
> > > Wrong again. When running z/OS under VM for production, multiple 3270
> > consoles is the norm.
> >
> > See-more Putz. What are you saying is wrong with my second sentence that
> > says "z/OS has many consoles." which applies to native and z/VM. Can you
> > stop with the non-stop nonsense.
> >
> >On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> > sme...@gmu.edu> wrote:
> >
> >  Wrong again. When running z/OS under VM for production, multiple 3270
> > consoles is the norm.
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Jon Perryman 
> > Sent: Saturday, July 29, 2023 5:04 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Ignorant z/OS question
> >
> >  > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> > li...@akphs.com> wrote:
> > > After changing the virtual console address from 03E1 to 0009
> > > linemode output went to SECUSER without artifacts
> >
> >
> > Congrats Phil. Here is what you need to know:
> >
> > 1. z/OS has many consoles. You don't have any consoles activated. The
> > hardware console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing
> to
> > do with DEV(3E1) in CONSOL##.
> >
> > 2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the
> > terminal is defined (DEF CONS, DEF GRAF or ATTACH). If someone decides
> they
> > need a console located next to the tape drives and another console next
> to
> > printers, then DEV(SYSCONS) will no longer be automatically activated.
> >
> > 3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default
> for
> > screen full with non-autoscroll messages requires a real person clear the
> > screen. This VM user typically would not be logged on. It could be days
> or
> > weeks before someone notices the message backlog.
> >On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> > li...@akphs.com> wrote:
> >
> >

Re: Ignorant z/OS question

> If I'm continually "wrong again", how is it that we arrived at the solution?

When you perpetually launch ad hominem attacks, it's difficult to justify the 
claime that you are being civil.

> Does anyone think that Seymour was leading Phil towards a solution to his 
> problem?

Only those who actually read what I wrote, instead of reflexively attacking me. 
I was spot on when I wrote that the CP and z/OS definitions had to be in synch.

> Disagreements are expected but complete dismissal is not acceptable.

And yet, complete dismissal seems to be your forté.

> I will show respect as long as respect is returned.

That is an outright lie.

> What I've learned is that you are a hypocrite.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Sunday, July 30, 2023 12:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz 
 >  wrote:
> I'm perfectly willing to be civil with people who are civil,

If I'm continually "wrong again", how is it that we arrived at the solution? 
Does anyone think that Seymour was leading Phil towards a solution to his 
problem? I'm civil to those who earn and demonstrate respect instead of 
demanding it. Lack of humility and the inability to understand the value of 
what others say is not a sign of respect. To prattle on about complete nonsense 
is not a sign of respect. What in any way was Seymour's comments being useful 
or informative? With the help of others, I was able to lead Phil to a solution 
for his problem and a solution he understands. I have no doubt that Seymour 
thinks he played a vital role in solving this problem but as he says, the 
devils in the details. I don't expect people to have all the correct answers 
but I do expect humility and respect for everyone in this group (not just me). 
Disagreements are expected but complete dismissal is not acceptable. I will 
show respect as long as respect is returned. As long as everyone is being 
respected, I will return that respect. Time will tell if Seymour has actually 
learned from what I've said.

Please accept my apologies for those who are upset with me but there is a line 
that I will not allow to be crossed without some form of retribution.

On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz 
 wrote:

 I'm perfectly willing to be civil with people who are civil, but when someone 
insists on repeated personal attacks. Take a look at the history of this thread 
and you will see that I have been restrained by comparison.

From: IBM Mainframe Discussion List  on behalf of Jay 
Maynard 
Sent: Saturday, July 29, 2023 6:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Now folks...let's not descend into personal name-calling, how about?

On Sat, Jul 29, 2023 at 4:56 PM Jon Perryman  wrote:

>  > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
> > Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
>
> See-more Putz. What are you saying is wrong with my second sentence that
> says "z/OS has many consoles." which applies to native and z/VM. Can you
> stop with the non-stop nonsense.
>
>    On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
>
>  Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jon Perryman 
> Sent: Saturday, July 29, 2023 5:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ignorant z/OS question
>
>  > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> li...@akphs.com> wrote:
> > After changing the virtual console address from 03E1 to 0009
> > linemode output went to SECUSER without artifacts
>
>
> Congrats Phil. Here is what you need to know:
>
> 1. z/OS has many consoles. You don't have any consoles activated. The
> hardware console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing to
> do with DEV(3E1) in CONSOL##.
>
> 2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the
> terminal is defined (DEF CONS, DEF GRAF or ATTACH). If someone decides they
> need a console located next to the tape drives and another console next to
> printers, then DEV(SYSCONS) will no longer be automatically activated.
>
> 3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default for
> screen full with non-autoscroll messages requires a real person clear the
> screen. This VM user typi

Re: Ignorant z/OS question

> simply a point where I think it's obvious that someone is intentionally being 
> disrespectful.

And it is obvious that you are intentionally being disrespectful.

> As a rule, I don't act snarky unless something is happening.

Actually, you attack people based on who they are rather than what they wrote.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Sunday, July 30, 2023 2:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Saturday, July 29, 2023 at 09:58:00 PM PDT, Tom Brennan 
 >  wrote:

> Ok, I guess that could mean that if/until someone earns your respect,
> you make fun of them like you did with me, ignore their answers like you
> did with me, and ignore their questions like you did with me.

I give everyone the benefit of the doubt from the start and treat them respect. 
There is simply a point where I think it's obvious that someone is 
intentionally being disrespectful. The vast majority in this group are 
extremely respectful.

As for ignoring questions and responses, that is more often a problem of yahoo 
mail web interface. Tab, backspace and space somehow permanently delete entire 
threads and I can no longer find them (not even in trash). I apologize if I did 
not respond when I should have.

As for making fun of you and I was in the wrong, then I apologize. As a rule, I 
don't act snarky unless something is happening. I don't recall the situation 
but maybe I misinterpreted something you said or maybe incorrectly felt you 
were being disrespectful of someone else. If that was not your intent, then I 
apologize for my mistake.

 On Saturday, July 29, 2023 at 09:58:00 PM PDT, Tom Brennan 
 wrote:

 Ok, I guess that could mean that if/until someone earns your respect,
you make fun of them like you did with me, ignore their answers like you
did with me, and ignore their questions like you did with me.

On 7/29/2023 9:14 PM, Jon Perryman wrote:
> I'm civil to those who earn and demonstrate respect instead of demanding it.

--
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: Ignorant z/OS question

2023-07-30 Thread Tom Brennan


Sounds good, thanks!

On 7/29/2023 11:29 PM, Jon Perryman wrote:

  > On Saturday, July 29, 2023 at 09:58:00 PM PDT, Tom Brennan 
 wrote:


Ok, I guess that could mean that if/until someone earns your respect,
you make fun of them like you did with me, ignore their answers like you
did with me, and ignore their questions like you did with me.


I give everyone the benefit of the doubt from the start and treat them respect. 
There is simply a point where I think it's obvious that someone is 
intentionally being disrespectful. The vast majority in this group are 
extremely respectful.

As for ignoring questions and responses, that is more often a problem of yahoo 
mail web interface. Tab, backspace and space somehow permanently delete entire 
threads and I can no longer find them (not even in trash). I apologize if I did 
not respond when I should have.

As for making fun of you and I was in the wrong, then I apologize. As a rule, I 
don't act snarky unless something is happening. I don't recall the situation 
but maybe I misinterpreted something you said or maybe incorrectly felt you 
were being disrespectful of someone else. If that was not your intent, then I 
apologize for my mistake.
  
  On Saturday, July 29, 2023 at 09:58:00 PM PDT, Tom Brennan  wrote:
  
  Ok, I guess that could mean that if/until someone earns your respect,

you make fun of them like you did with me, ignore their answers like you
did with me, and ignore their questions like you did with me.

On 7/29/2023 9:14 PM, Jon Perryman wrote:

I'm civil to those who earn and demonstrate respect instead of demanding it.


--
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: Ignorant z/OS question

 > On Saturday, July 29, 2023 at 09:58:00 PM PDT, Tom Brennan 
 >  wrote:

> Ok, I guess that could mean that if/until someone earns your respect,
> you make fun of them like you did with me, ignore their answers like you
> did with me, and ignore their questions like you did with me.

I give everyone the benefit of the doubt from the start and treat them respect. 
There is simply a point where I think it's obvious that someone is 
intentionally being disrespectful. The vast majority in this group are 
extremely respectful.

As for ignoring questions and responses, that is more often a problem of yahoo 
mail web interface. Tab, backspace and space somehow permanently delete entire 
threads and I can no longer find them (not even in trash). I apologize if I did 
not respond when I should have. 

As for making fun of you and I was in the wrong, then I apologize. As a rule, I 
don't act snarky unless something is happening. I don't recall the situation 
but maybe I misinterpreted something you said or maybe incorrectly felt you 
were being disrespectful of someone else. If that was not your intent, then I 
apologize for my mistake.

 On Saturday, July 29, 2023 at 09:58:00 PM PDT, Tom Brennan 
 wrote:  

 Ok, I guess that could mean that if/until someone earns your respect, 
you make fun of them like you did with me, ignore their answers like you 
did with me, and ignore their questions like you did with me.

On 7/29/2023 9:14 PM, Jon Perryman wrote:
> I'm civil to those who earn and demonstrate respect instead of demanding it.

--
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: Ignorant z/OS question

2023-07-29 Thread Tom Brennan

Ok, I guess that could mean that if/until someone earns your respect, 
you make fun of them like you did with me, ignore their answers like you 
did with me, and ignore their questions like you did with me.


On 7/29/2023 9:14 PM, Jon Perryman wrote:

I'm civil to those who earn and demonstrate respect instead of demanding it.


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

Re: Ignorant z/OS question

2023-07-29 Thread Jon Perryman

 > On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz 
 >  wrote:
> I'm perfectly willing to be civil with people who are civil, 

If I'm continually "wrong again", how is it that we arrived at the solution? 
Does anyone think that Seymour was leading Phil towards a solution to his 
problem? I'm civil to those who earn and demonstrate respect instead of 
demanding it. Lack of humility and the inability to understand the value of 
what others say is not a sign of respect. To prattle on about complete nonsense 
is not a sign of respect. What in any way was Seymour's comments being useful 
or informative? With the help of others, I was able to lead Phil to a solution 
for his problem and a solution he understands. I have no doubt that Seymour 
thinks he played a vital role in solving this problem but as he says, the 
devils in the details. I don't expect people to have all the correct answers 
but I do expect humility and respect for everyone in this group (not just me). 
Disagreements are expected but complete dismissal is not acceptable. I will 
show respect as long as respect is returned. As long as everyone is being 
respected, I will return that respect. Time will tell if Seymour has actually 
learned from what I've said.

Please accept my apologies for those who are upset with me but there is a line 
that I will not allow to be crossed without some form of retribution.

On Saturday, July 29, 2023 at 04:33:30 PM PDT, Seymour J Metz 
 wrote:  

 I'm perfectly willing to be civil with people who are civil, but when someone 
insists on repeated personal attacks. Take a look at the history of this thread 
and you will see that I have been restrained by comparison.

From: IBM Mainframe Discussion List  on behalf of Jay 
Maynard 
Sent: Saturday, July 29, 2023 6:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Now folks...let's not descend into personal name-calling, how about?

On Sat, Jul 29, 2023 at 4:56 PM Jon Perryman  wrote:

>  > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
> > Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
>
> See-more Putz. What are you saying is wrong with my second sentence that
> says "z/OS has many consoles." which applies to native and z/VM. Can you
> stop with the non-stop nonsense.
>
>    On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
>
>  Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jon Perryman 
> Sent: Saturday, July 29, 2023 5:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ignorant z/OS question
>
>  > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> li...@akphs.com> wrote:
> > After changing the virtual console address from 03E1 to 0009
> > linemode output went to SECUSER without artifacts
>
>
> Congrats Phil. Here is what you need to know:
>
> 1. z/OS has many consoles. You don't have any consoles activated. The
> hardware console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing to
> do with DEV(3E1) in CONSOL##.
>
> 2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the
> terminal is defined (DEF CONS, DEF GRAF or ATTACH). If someone decides they
> need a console located next to the tape drives and another console next to
> printers, then DEV(SYSCONS) will no longer be automatically activated.
>
> 3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default for
> screen full with non-autoscroll messages requires a real person clear the
> screen. This VM user typically would not be logged on. It could be days or
> weeks before someone notices the message backlog.
>    On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> li...@akphs.com> wrote:
>
>  After changing the virtual console address from 03E1 (matching the
> CONSOLE entry in CONSOLxx) to 0009 (matching no z/OS console definition)
> and reIPLing the guest, the linemode output went to SECUSER without
> artifacts, as it did on our old hosting environment.
>
> I'm convinced based on the evidence that:
>
> *    The old environment had the virtual console at 0009
> *    The old environment had the z/OS CONSOLE definition at 03E1
> *    The folks who ported our system over for us had logon access to the
> old environment, but did NOT have access to the VM directory entry for the
> guest
> *    They thus made the logically correct decision to define the virtual
> console at 03E1
>
>
> That was the "right thing to do", except it turned

Re: Ignorant z/OS question

2023-07-29 Thread Mike Schwab

Me just thinking about the 'Levels Of Argument' keeps me calm when the name
calling begins.

On Sat, Jul 29, 2023, 17:48 Jay Maynard  wrote:

> Now folks...let's not descend into personal name-calling, how about?
>
> On Sat, Jul 29, 2023 at 4:56 PM Jon Perryman  wrote:
>
> >  > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> > sme...@gmu.edu> wrote:
> > > Wrong again. When running z/OS under VM for production, multiple 3270
> > consoles is the norm.
> >
> > See-more Putz. What are you saying is wrong with my second sentence that
> > says "z/OS has many consoles." which applies to native and z/VM. Can you
> > stop with the non-stop nonsense.
> >
> > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> > sme...@gmu.edu> wrote:
> >
> >  Wrong again. When running z/OS under VM for production, multiple 3270
> > consoles is the norm.
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Jon Perryman 
> > Sent: Saturday, July 29, 2023 5:04 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Ignorant z/OS question
> >
> >  > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> > li...@akphs.com> wrote:
> > > After changing the virtual console address from 03E1 to 0009
> > > linemode output went to SECUSER without artifacts
> >
> >
> > Congrats Phil. Here is what you need to know:
> >
> > 1. z/OS has many consoles. You don't have any consoles activated. The
> > hardware console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing
> to
> > do with DEV(3E1) in CONSOL##.
> >
> > 2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the
> > terminal is defined (DEF CONS, DEF GRAF or ATTACH). If someone decides
> they
> > need a console located next to the tape drives and another console next
> to
> > printers, then DEV(SYSCONS) will no longer be automatically activated.
> >
> > 3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default
> for
> > screen full with non-autoscroll messages requires a real person clear the
> > screen. This VM user typically would not be logged on. It could be days
> or
> > weeks before someone notices the message backlog.
> > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> > li...@akphs.com> wrote:
> >
> >  After changing the virtual console address from 03E1 (matching the
> > CONSOLE entry in CONSOLxx) to 0009 (matching no z/OS console definition)
> > and reIPLing the guest, the linemode output went to SECUSER without
> > artifacts, as it did on our old hosting environment.
> >
> > I'm convinced based on the evidence that:
> >
> > *The old environment had the virtual console at 0009
> > *The old environment had the z/OS CONSOLE definition at 03E1
> > *The folks who ported our system over for us had logon access to the
> > old environment, but did NOT have access to the VM directory entry for
> the
> > guest
> > *They thus made the logically correct decision to define the virtual
> > console at 03E1
> >
> >
> > That was the "right thing to do", except it turned out to change the
> > behavior in an unintuitive way. Now we know.
> >
> > Thanks 10**6 for all the thoughts and advice here! It was a bit of an
> > odyssey but we got there.
> >
> > And this might be due an IBM-MAIN award for the longest thread without
> > significant topic drift, at least in a while. No idea why, but that's
> rare
> > here!
> >
> > ...phsiii
> >
> >
> > --
> > 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
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Jay Maynard
>
> --
> 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: Ignorant z/OS question

2023-07-29 Thread Seymour J Metz

I'm perfectly willing to be civil with people who are civil, but when someone 
insists on repeated personal attacks. Take a look at the history of this thread 
and you will see that I have been restrained by comparison.


From: IBM Mainframe Discussion List  on behalf of Jay 
Maynard 
Sent: Saturday, July 29, 2023 6:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Now folks...let's not descend into personal name-calling, how about?

On Sat, Jul 29, 2023 at 4:56 PM Jon Perryman  wrote:

>  > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
> > Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
>
> See-more Putz. What are you saying is wrong with my second sentence that
> says "z/OS has many consoles." which applies to native and z/VM. Can you
> stop with the non-stop nonsense.
>
> On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
>
>  Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jon Perryman 
> Sent: Saturday, July 29, 2023 5:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ignorant z/OS question
>
>  > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> li...@akphs.com> wrote:
> > After changing the virtual console address from 03E1 to 0009
> > linemode output went to SECUSER without artifacts
>
>
> Congrats Phil. Here is what you need to know:
>
> 1. z/OS has many consoles. You don't have any consoles activated. The
> hardware console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing to
> do with DEV(3E1) in CONSOL##.
>
> 2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the
> terminal is defined (DEF CONS, DEF GRAF or ATTACH). If someone decides they
> need a console located next to the tape drives and another console next to
> printers, then DEV(SYSCONS) will no longer be automatically activated.
>
> 3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default for
> screen full with non-autoscroll messages requires a real person clear the
> screen. This VM user typically would not be logged on. It could be days or
> weeks before someone notices the message backlog.
> On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> li...@akphs.com> wrote:
>
>  After changing the virtual console address from 03E1 (matching the
> CONSOLE entry in CONSOLxx) to 0009 (matching no z/OS console definition)
> and reIPLing the guest, the linemode output went to SECUSER without
> artifacts, as it did on our old hosting environment.
>
> I'm convinced based on the evidence that:
>
> *The old environment had the virtual console at 0009
> *The old environment had the z/OS CONSOLE definition at 03E1
> *The folks who ported our system over for us had logon access to the
> old environment, but did NOT have access to the VM directory entry for the
> guest
> *They thus made the logically correct decision to define the virtual
> console at 03E1
>
>
> That was the "right thing to do", except it turned out to change the
> behavior in an unintuitive way. Now we know.
>
> Thanks 10**6 for all the thoughts and advice here! It was a bit of an
> odyssey but we got there.
>
> And this might be due an IBM-MAIN award for the longest thread without
> significant topic drift, at least in a while. No idea why, but that's rare
> here!
>
> ...phsiii
>
>
> --
> 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
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Jay Maynard

--
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: Ignorant z/OS question

2023-07-29 Thread Jay Maynard

Now folks...let's not descend into personal name-calling, how about?

On Sat, Jul 29, 2023 at 4:56 PM Jon Perryman  wrote:

>  > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
> > Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
>
> See-more Putz. What are you saying is wrong with my second sentence that
> says "z/OS has many consoles." which applies to native and z/VM. Can you
> stop with the non-stop nonsense.
>
> On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz <
> sme...@gmu.edu> wrote:
>
>  Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jon Perryman 
> Sent: Saturday, July 29, 2023 5:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ignorant z/OS question
>
>  > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> li...@akphs.com> wrote:
> > After changing the virtual console address from 03E1 to 0009
> > linemode output went to SECUSER without artifacts
>
>
> Congrats Phil. Here is what you need to know:
>
> 1. z/OS has many consoles. You don't have any consoles activated. The
> hardware console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing to
> do with DEV(3E1) in CONSOL##.
>
> 2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the
> terminal is defined (DEF CONS, DEF GRAF or ATTACH). If someone decides they
> need a console located next to the tape drives and another console next to
> printers, then DEV(SYSCONS) will no longer be automatically activated.
>
> 3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default for
> screen full with non-autoscroll messages requires a real person clear the
> screen. This VM user typically would not be logged on. It could be days or
> weeks before someone notices the message backlog.
> On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III <
> li...@akphs.com> wrote:
>
>  After changing the virtual console address from 03E1 (matching the
> CONSOLE entry in CONSOLxx) to 0009 (matching no z/OS console definition)
> and reIPLing the guest, the linemode output went to SECUSER without
> artifacts, as it did on our old hosting environment.
>
> I'm convinced based on the evidence that:
>
> *The old environment had the virtual console at 0009
> *The old environment had the z/OS CONSOLE definition at 03E1
> *The folks who ported our system over for us had logon access to the
> old environment, but did NOT have access to the VM directory entry for the
> guest
> *They thus made the logically correct decision to define the virtual
> console at 03E1
>
>
> That was the "right thing to do", except it turned out to change the
> behavior in an unintuitive way. Now we know.
>
> Thanks 10**6 for all the thoughts and advice here! It was a bit of an
> odyssey but we got there.
>
> And this might be due an IBM-MAIN award for the longest thread without
> significant topic drift, at least in a while. No idea why, but that's rare
> here!
>
> ...phsiii
>
>
> --
> 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
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Jay Maynard

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

Re: Ignorant z/OS question

2023-07-29 Thread Jon Perryman

 > On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz 
 >  wrote:
> Wrong again. When running z/OS under VM for production, multiple 3270 
> consoles is the norm.

See-more Putz. What are you saying is wrong with my second sentence that says 
"z/OS has many consoles." which applies to native and z/VM. Can you stop with 
the non-stop nonsense.

On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz 
 wrote:  

 Wrong again. When running z/OS under VM for production, multiple 3270 consoles 
is the norm.

From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Saturday, July 29, 2023 5:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III 
 >  wrote:
> After changing the virtual console address from 03E1 to 0009
> linemode output went to SECUSER without artifacts

Congrats Phil. Here is what you need to know:

1. z/OS has many consoles. You don't have any consoles activated. The hardware 
console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing to do with 
DEV(3E1) in CONSOL##.

2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the terminal is 
defined (DEF CONS, DEF GRAF or ATTACH). If someone decides they need a console 
located next to the tape drives and another console next to printers, then 
DEV(SYSCONS) will no longer be automatically activated.

3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default for 
screen full with non-autoscroll messages requires a real person clear the 
screen. This VM user typically would not be logged on. It could be days or 
weeks before someone notices the message backlog.
    On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III 
 wrote:

 After changing the virtual console address from 03E1 (matching the CONSOLE 
entry in CONSOLxx) to 0009 (matching no z/OS console definition) and reIPLing 
the guest, the linemode output went to SECUSER without artifacts, as it did on 
our old hosting environment.

I'm convinced based on the evidence that:

*    The old environment had the virtual console at 0009
*    The old environment had the z/OS CONSOLE definition at 03E1
*    The folks who ported our system over for us had logon access to the old 
environment, but did NOT have access to the VM directory entry for the guest
*    They thus made the logically correct decision to define the virtual 
console at 03E1

That was the "right thing to do", except it turned out to change the behavior 
in an unintuitive way. Now we know.

Thanks 10**6 for all the thoughts and advice here! It was a bit of an odyssey 
but we got there.

And this might be due an IBM-MAIN award for the longest thread without 
significant topic drift, at least in a while. No idea why, but that's rare here!

...phsiii

--
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

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

Re: Ignorant z/OS question

2023-07-29 Thread Seymour J Metz

Wrong again. When running z/OS under VM for production, multiple 3270 consoles 
is the norm.

From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Saturday, July 29, 2023 5:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III 
 >  wrote:
> After changing the virtual console address from 03E1 to 0009
> linemode output went to SECUSER without artifacts

Congrats Phil. Here is what you need to know:

1. z/OS has many consoles. You don't have any consoles activated. The hardware 
console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing to do with 
DEV(3E1) in CONSOL##.

2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the terminal is 
defined (DEF CONS, DEF GRAF or ATTACH). If someone decides they need a console 
located next to the tape drives and another console next to printers, then 
DEV(SYSCONS) will no longer be automatically activated.

3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default for 
screen full with non-autoscroll messages requires a real person clear the 
screen. This VM user typically would not be logged on. It could be days or 
weeks before someone notices the message backlog.
On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III 
 wrote:

 After changing the virtual console address from 03E1 (matching the CONSOLE 
entry in CONSOLxx) to 0009 (matching no z/OS console definition) and reIPLing 
the guest, the linemode output went to SECUSER without artifacts, as it did on 
our old hosting environment.

I'm convinced based on the evidence that:

*The old environment had the virtual console at 0009
*The old environment had the z/OS CONSOLE definition at 03E1
*The folks who ported our system over for us had logon access to the old 
environment, but did NOT have access to the VM directory entry for the guest
*They thus made the logically correct decision to define the virtual 
console at 03E1

That was the "right thing to do", except it turned out to change the behavior 
in an unintuitive way. Now we know.

Thanks 10**6 for all the thoughts and advice here! It was a bit of an odyssey 
but we got there.

And this might be due an IBM-MAIN award for the longest thread without 
significant topic drift, at least in a while. No idea why, but that's rare here!

...phsiii

--
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: Ignorant z/OS question

2023-07-29 Thread Jon Perryman

 > On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III 
 >  wrote:
> After changing the virtual console address from 03E1 to 0009
> linemode output went to SECUSER without artifacts

Congrats Phil. Here is what you need to know:

1. z/OS has many consoles. You don't have any consoles activated. The hardware 
console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing to do with 
DEV(3E1) in CONSOL##.

2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the terminal is 
defined (DEF CONS, DEF GRAF or ATTACH). If someone decides they need a console 
located next to the tape drives and another console next to printers, then 
DEV(SYSCONS) will no longer be automatically activated. 

3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default for 
screen full with non-autoscroll messages requires a real person clear the 
screen. This VM user typically would not be logged on. It could be days or 
weeks before someone notices the message backlog.
On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III 
 wrote:  

 After changing the virtual console address from 03E1 (matching the CONSOLE 
entry in CONSOLxx) to 0009 (matching no z/OS console definition) and reIPLing 
the guest, the linemode output went to SECUSER without artifacts, as it did on 
our old hosting environment.

I'm convinced based on the evidence that:

*    The old environment had the virtual console at 0009
*    The old environment had the z/OS CONSOLE definition at 03E1
*    The folks who ported our system over for us had logon access to the old 
environment, but did NOT have access to the VM directory entry for the guest
*    They thus made the logically correct decision to define the virtual 
console at 03E1

That was the "right thing to do", except it turned out to change the behavior 
in an unintuitive way. Now we know.

Thanks 10**6 for all the thoughts and advice here! It was a bit of an odyssey 
but we got there.

And this might be due an IBM-MAIN award for the longest thread without 
significant topic drift, at least in a while. No idea why, but that's rare here!

...phsiii

--
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: Ignorant z/OS question

2023-07-29 Thread Phil Smith III

After changing the virtual console address from 03E1 (matching the CONSOLE 
entry in CONSOLxx) to 0009 (matching no z/OS console definition) and reIPLing 
the guest, the linemode output went to SECUSER without artifacts, as it did on 
our old hosting environment.

I'm convinced based on the evidence that:

*   The old environment had the virtual console at 0009
*   The old environment had the z/OS CONSOLE definition at 03E1
*   The folks who ported our system over for us had logon access to the old 
environment, but did NOT have access to the VM directory entry for the guest
*   They thus made the logically correct decision to define the virtual 
console at 03E1


That was the "right thing to do", except it turned out to change the behavior 
in an unintuitive way. Now we know.

Thanks 10**6 for all the thoughts and advice here! It was a bit of an odyssey 
but we got there.

And this might be due an IBM-MAIN award for the longest thread without 
significant topic drift, at least in a while. No idea why, but that's rare here!

...phsiii


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

Re: Ignorant z/OS question

2023-07-28 Thread Seymour J Metz

PKB. The fact that you don't understand something doesn't make it silly.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Thursday, July 27, 2023 8:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Thursday, July 27, 2023 at 03:22:06 AM PDT, Seymour J Metz 
 >  wrote:
> I take it that you can't read. "I would have expected" is not a claim of fact.

Your many expectations are too often silly wild ass guesses. More than once in 
this thread alone, you've spewed absolute non-sense that leads people down dead 
ends. You don't know your own limitations. I did not say your expectation is a 
claim of fact. "Devil in the details" really? It's me saying your expectations 
are not based on common sense or facts. Tony asked you what facts you were 
basing your expectations and you agreed with his guesses. I take it you can't 
figure out your own limitations.

On Thursday, July 27, 2023 at 03:22:06 AM PDT, Seymour J Metz 
 wrote:

 I take it that you can't read. "I would have expected" is not a claim of fact.

Or did you know that and choose to lie about it?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Thursday, July 27, 2023 12:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Wednesday, July 26, 2023 at 03:49:12 AM PDT, Tony Harminc 
 >  wrote:

>>On Tue, 25 Jul 2023 at 17:25, Seymour J Metz  wrote:

>> I would have expected 1052-7, 3210 and 3215 support to die at the same time.

> Is there any reason to think that there is/was separate code for these

> three devices? IIRC their programming specs are identical, or very

> close to identical. Obviously the hardware is quite different

> (Selectric printer, dot-matrix), but the software generally doesn't

> care about that kind of thing.

Seymour constantly makes silly wild ass guesses and passes them off as fact. 
Use your common sense and knowledge about IBM. When IBM rewrote console 
services, they dropped typewriter console support. Deleting the HCD / IODF 
definitions for these obsolete devices is simpler than excluding these devices 
from the NIP address. We only know that HCD & IODF do not allow these devices 
to be defined. IBM does not change code unless it's necessary and only deletes 
non-functional code when they are already working on that module. As for 
removing the device support code, this code might also support the CONSOLE 
printer devices.  Deletion of these modules is pure conjecture without any 
factual basis.

On Wednesday, July 26, 2023 at 03:49:12 AM PDT, Tony Harminc 
 wrote:

 On Tue, 25 Jul 2023 at 17:25, Seymour J Metz  wrote:
>
> I would have expected 1052-7, 3210 and 3215 support to die at the same time.

Is there any reason to think that there is/was separate code for these
three devices? IIRC their programming specs are identical, or very
close to identical. Obviously the hardware is quite different
(Selectric printer, dot-matrix), but the software generally doesn't
care about that kind of thing.

Tony H.

> 
> From: IBM Mainframe Discussion List  on behalf of 
> Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu>
[...]
> ISTR the some of the older "console" support was removed in the indicated 
> timeframe. E.g. 1052
> I cannot say for certain that the 3215 code was removed at that time.

--
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

--
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: Ignorant z/OS question

2023-07-27 Thread David Spiegel

Hi Jon,
A SPECIAL (in the directory) can also be DETACHd.

Regards,
David

On 2023-07-27 20:51, Jon Perryman wrote:

  > On Thursday, July 27, 2023 at 04:03:52 PM PDT, David Spiegel wrote:

You said: "...Detaching a "console" requires a "DEFINE CONSOLE" ..."
AFAIK, (since VM R6.0) this statement has never been true.

Hi David,

Can you explain why this is false or how I have this wrong? Steve said device but he 
really meant to say virtual device. The antonym of ATTACH is DETACH but strangely DETACH 
has many antonyms (e.g. ATTACH, DEFINE CONSOLE, DEFINE GRAF, ...). If you detach a 
console, then the antonym is define console. If you detach a real address, then the 
antonym is attach. As for "require", I think this is what you are talking about 
being false. I should have been clearer and said the opposite of detach console is define 
console (not attach console).

 On Thursday, July 27, 2023 at 04:03:52 PM PDT, David Spiegel 
<0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

  Hi Jon,

You said: "...Detaching a "console" requires a "DEFINE CONSOLE" ..."
AFAIK, (since VM R6.0) this statement has never been true.

Regards,
David

On 2023-07-26 23:37, Jon Perryman wrote:

   > On Tuesday, July 25, 2023 at 07:14:21 PM PDT, Steve Horein 
 wrote:

Just out of curiosity, is there such a thing as VM "attach" to reconnect a
device at a later time?

Phil would need to verify what I'm saying. "detach" is a generic command that eliminates a virtual address regardless of how the 
virtual address was defined. "attach" is for attaching real VM addresses to a user at a virtual address. Detaching a 
"console" requires a "DEFINE CONSOLE". Detaching a "GRAF" requires a "DEFINE GRAF". I think there 
are several variations of DEFINE specific to the virtual device type.

       On Tuesday, July 25, 2023 at 07:14:21 PM PDT, Steve Horein 
 wrote:

   To my understanding, that sounds correct.

Explicitly removing the NIP *console* definition, though leaving the
address defined/intact in the IODF for later use by MVS console services
(CONSOLxx), would have the same effect as making the device inaccessible,
either through (presumably) bad cabling in my case, or through VM detach
that you describe, which sounds more dynamic.

Just out of curiosity, is there such a thing as VM "attach" to reconnect a
device at a later time?

--
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: Ignorant z/OS question

2023-07-27 Thread Phil Smith III

Jon Perryman wrote:
>Can you explain why this is false or how I have this wrong? Steve said
>device but he really meant to say virtual device. The antonym of
>ATTACH is DETACH but strangely DETACH has many antonyms (e.g. ATTACH,
>DEFINE CONSOLE, DEFINE GRAF, ...). If you detach a console, then the
>antonym is define console. If you detach a real address, then the
>antonym is attach. As for "require", I think this is what you are
>talking about being false. I should have been clearer and said the
>opposite of detach console is define console (not attach console).

See my note. Y'all are both right, it's just semantics! ("Do those matter?"


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

Re: Ignorant z/OS question

2023-07-27 Thread Jon Perryman

 > On Thursday, July 27, 2023 at 04:03:52 PM PDT, David Spiegel wrote:
> You said: "...Detaching a "console" requires a "DEFINE CONSOLE" ..."

> AFAIK, (since VM R6.0) this statement has never been true.
Hi David,

Can you explain why this is false or how I have this wrong? Steve said device 
but he really meant to say virtual device. The antonym of ATTACH is DETACH but 
strangely DETACH has many antonyms (e.g. ATTACH, DEFINE CONSOLE, DEFINE GRAF, 
...). If you detach a console, then the antonym is define console. If you 
detach a real address, then the antonym is attach. As for "require", I think 
this is what you are talking about being false. I should have been clearer and 
said the opposite of detach console is define console (not attach console).



On Thursday, July 27, 2023 at 04:03:52 PM PDT, David Spiegel 
<0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:  
 
 Hi Jon,
You said: "...Detaching a "console" requires a "DEFINE CONSOLE" ..."
AFAIK, (since VM R6.0) this statement has never been true.

Regards,
David

On 2023-07-26 23:37, Jon Perryman wrote:
>  > On Tuesday, July 25, 2023 at 07:14:21 PM PDT, Steve Horein 
> wrote:
>> Just out of curiosity, is there such a thing as VM "attach" to reconnect a
>> device at a later time?
>
> Phil would need to verify what I'm saying. "detach" is a generic command that 
> eliminates a virtual address regardless of how the virtual address was 
> defined. "attach" is for attaching real VM addresses to a user at a virtual 
> address. Detaching a "console" requires a "DEFINE CONSOLE". Detaching a 
> "GRAF" requires a "DEFINE GRAF". I think there are several variations of 
> DEFINE specific to the virtual device type.
>
>
>      On Tuesday, July 25, 2023 at 07:14:21 PM PDT, Steve Horein 
> wrote:
>  
>  To my understanding, that sounds correct.
>
> Explicitly removing the NIP *console* definition, though leaving the
> address defined/intact in the IODF for later use by MVS console services
> (CONSOLxx), would have the same effect as making the device inaccessible,
> either through (presumably) bad cabling in my case, or through VM detach
> that you describe, which sounds more dynamic.
>
> Just out of curiosity, is there such a thing as VM "attach" to reconnect a
> device at a later time?

  

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

Re: Ignorant z/OS question

2023-07-27 Thread Jon Perryman

 > On Thursday, July 27, 2023 at 03:22:06 AM PDT, Seymour J Metz 
 >  wrote:
> I take it that you can't read. "I would have expected" is not a claim of fact.

Your many expectations are too often silly wild ass guesses. More than once in 
this thread alone, you've spewed absolute non-sense that leads people down dead 
ends. You don't know your own limitations. I did not say your expectation is a 
claim of fact. "Devil in the details" really? It's me saying your expectations 
are not based on common sense or facts. Tony asked you what facts you were 
basing your expectations and you agreed with his guesses. I take it you can't 
figure out your own limitations. 

On Thursday, July 27, 2023 at 03:22:06 AM PDT, Seymour J Metz 
 wrote:  

 I take it that you can't read. "I would have expected" is not a claim of fact.

Or did you know that and choose to lie about it?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Thursday, July 27, 2023 12:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Wednesday, July 26, 2023 at 03:49:12 AM PDT, Tony Harminc 
 >  wrote:

>>On Tue, 25 Jul 2023 at 17:25, Seymour J Metz  wrote:

>> I would have expected 1052-7, 3210 and 3215 support to die at the same time.

> Is there any reason to think that there is/was separate code for these

> three devices? IIRC their programming specs are identical, or very

> close to identical. Obviously the hardware is quite different

> (Selectric printer, dot-matrix), but the software generally doesn't

> care about that kind of thing.

Seymour constantly makes silly wild ass guesses and passes them off as fact. 
Use your common sense and knowledge about IBM. When IBM rewrote console 
services, they dropped typewriter console support. Deleting the HCD / IODF 
definitions for these obsolete devices is simpler than excluding these devices 
from the NIP address. We only know that HCD & IODF do not allow these devices 
to be defined. IBM does not change code unless it's necessary and only deletes 
non-functional code when they are already working on that module. As for 
removing the device support code, this code might also support the CONSOLE 
printer devices.  Deletion of these modules is pure conjecture without any 
factual basis.

    On Wednesday, July 26, 2023 at 03:49:12 AM PDT, Tony Harminc 
 wrote:

 On Tue, 25 Jul 2023 at 17:25, Seymour J Metz  wrote:
>
> I would have expected 1052-7, 3210 and 3215 support to die at the same time.

Is there any reason to think that there is/was separate code for these
three devices? IIRC their programming specs are identical, or very
close to identical. Obviously the hardware is quite different
(Selectric printer, dot-matrix), but the software generally doesn't
care about that kind of thing.

Tony H.

> 
> From: IBM Mainframe Discussion List  on behalf of 
> Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu>
[...]
> ISTR the some of the older "console" support was removed in the indicated 
> timeframe. E.g. 1052
> I cannot say for certain that the 3215 code was removed at that time.

--
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

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

Re: Ignorant z/OS question

2023-07-27 Thread Phil Smith III

David is, of course, correct that DETACH doesn't require a DEFINE. I think Jon 
meant they were the opposites for the virtual console, rather than 
DETACH/ATTACH.

If you want, say, a real tape drive attached to your virtual machine (remember 
tape drives?), you (or more likely an operator or service virtual machine) 
would ATTACH it; when done, you'd DETACH it, same as a virtual device. That's 
the point of VM: virtual, real-the guest mostly doesn't need to care. As, 
indeed, z/OS doesn't.


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

Re: Ignorant z/OS question

2023-07-27 Thread Phil Smith III

Jon Perryman wrote:
>"detach" is a generic command that eliminates a virtual address
>regardless of how the virtual address was defined. "attach" is for
>attaching real VM addresses to a user at a virtual address. Detaching
>a "console" requires a "DEFINE CONSOLE". Detaching a "GRAF" requires a
>"DEFINE GRAF". I think there are several variations of DEFINE specific
>to the virtual device type.

Exactly. You DEFINE a virtual device: you ATTACH a real device.

DEFINE CONSOLE 0009  <

Re: Ignorant z/OS question

2023-07-27 Thread David Spiegel

Hi Jon,
You said: "...Detaching a "console" requires a "DEFINE CONSOLE" ..."
AFAIK, (since VM R6.0) this statement has never been true.

Regards,
David

On 2023-07-26 23:37, Jon Perryman wrote:

> On Tuesday, July 25, 2023 at 07:14:21 PM PDT, Steve Horein
wrote:

Just out of curiosity, is there such a thing as VM "attach" to reconnect a
device at a later time?

Phil would need to verify what I'm saying. "detach" is a generic command that eliminates a virtual address regardless of how the
virtual address was defined. "attach" is for attaching real VM addresses to a user at a virtual address. Detaching a
"console" requires a "DEFINE CONSOLE". Detaching a "GRAF" requires a "DEFINE GRAF". I think there
are several variations of DEFINE specific to the virtual device type.

On Tuesday, July 25, 2023 at 07:14:21 PM PDT, Steve Horein
wrote:

To my understanding, that sounds correct.

Explicitly removing the NIP *console* definition, though leaving the
address defined/intact in the IODF for later use by MVS console services
(CONSOLxx), would have the same effect as making the device inaccessible,
either through (presumably) bad cabling in my case, or through VM detach
that you describe, which sounds more dynamic.

Just out of curiosity, is there such a thing as VM "attach" to reconnect a
device at a later time?

On Tue, Jul 25, 2023 at 7:20 PM Jon Perryman wrote:

> On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein <
steve.hor...@gmail.com> wrote:

This is what I was referring to, relating to NIP and IODF:

Phil, you can ignore this topic.

Steve, does it make a difference if the NIP address doesn't exist versus
clearing the NIP address in the IODF? I thought both caused the hardware
console to be used. updating the NIP address might not be something Phil
is comfortable with. Phil understands VM detach and it should achieve the
same results. Detaching all consoles ensures things like problem
determination mode and more doesn't affect hardware console activation.
Phil gets 1 chance on the weekend and I'm just ensuring we cover the most
possibilities in 1 try.

Am I wrong? If this works, then recommending the deletion of the NIP
address becomes a trivial change.

On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein <
steve.hor...@gmail.com> wrote:

This is what I was referring to, relating to NIP and IODF:

https://www.ibm.com/docs/en/zos/2.4.0?topic=configuration-working-operating-system-consoles

The topic mentions both MVS and VM, so there may be some useful
information.

While I mentioned my request to have "...the NIP *device *be removed from
IODF", I should have stated to have "... the NIP *CONSOLE* be removed from
IODF".
Yes, the device should be defined to allow CONSOLxx to make use of it once
MVS has been initialized, but an IODF defined NIP CONSOLE is not
required, making use of the hardware console in its absence.

Maybe you're saying the same thing, just in VM speak?!

On Tue, Jul 25, 2023 at 10:43 AM Jon Perryman
wrote:

> On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
steve.hor...@gmail.com> wrote:

The only time I have seen NIP messages (those messages prior to VARY
CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP

device

Hi Phil, Sorry for the long delay.but I had other things to do. Steve may
have a possible solution. Let me put it into terms you can understand.

Steve says there is 1 exception to the hardware console requiring V
CN(*),ACT to become the first active console during IPL. He says if you
disable all z/OS DEV(###) consoles, then the hardware console will
automatically activate because there is no other console available. I
believe this to be true but I have never tried this. There may be a

couple

caveats that can be discussed later if it solves your problem.
This is simple to test. From the z/OS VM user, detach all devices
specified in PARMLIB(CONSOL##). At the moment, forget he mentions "NIP"
device because this is almost always included in PARMLIB(CONSOL##) which
means you would have detached it. This is so simple it's worth a try.

On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
steve.hor...@gmail.com> wrote:

The only time I have seen NIP messages (those messages prior to VARY
CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP

device

defined in the IODF was not available, I believe due to some cabling
issues. In that situation, all NIP messages were routed to the SE/HMC
System Console. I had requested the NIP device be removed from IODF years
before, for that exact purpose, to assist with automation that uses
SYSCONS, and/or for diagnostics, but due to Fear/Uncertainty/Doubt, the
request was flatly denied.

https://www.ibm.com/docs/en/zos/2.4.0?topic=system-nip-console
"If no NIP console is defined and ready, MVS™ will use the system console
as the NIP-time console."

I have zero experience with zVM, so I do not know if that NIP message
behavior

Re: Ignorant z/OS question

2023-07-27 Thread Seymour J Metz

z/OS uses a DIAG to communicate with the HMC; this is true even when running on 
a bare LPAR. I'm not aware of any publicly available documentation. 

Do you have a CONSOLE with DEVNUM(HMCS) or DEVNUM(SYSCONS)?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Wednesday, July 26, 2023 5:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Berry van Sleeuwen wrote, in part:
>I guess it doesn't really matter what address you use, especially for
>Guest Operating Systems, as long as they are defined in their
>respective configuration members (CONSOLxx for z/OS, SYSTEM CONFIG for
>z/VM, IPL proc for z/VSE).

Right. I'm betting that z/OS (which does know when it's running under VM) does 
a DIAG x'24' to find where the actual console is even if it doesn't match 
CONSOLxx.

--
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: Ignorant z/OS question

2023-07-27 Thread Seymour J Metz

I take it that you can't read. "I would have expected" is not a claim of fact.

Or did you know that and choose to lie about it?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Thursday, July 27, 2023 12:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Wednesday, July 26, 2023 at 03:49:12 AM PDT, Tony Harminc 
 >  wrote:

>>On Tue, 25 Jul 2023 at 17:25, Seymour J Metz  wrote:

>> I would have expected 1052-7, 3210 and 3215 support to die at the same time.

> Is there any reason to think that there is/was separate code for these

> three devices? IIRC their programming specs are identical, or very

> close to identical. Obviously the hardware is quite different

> (Selectric printer, dot-matrix), but the software generally doesn't

> care about that kind of thing.

Seymour constantly makes silly wild ass guesses and passes them off as fact. 
Use your common sense and knowledge about IBM. When IBM rewrote console 
services, they dropped typewriter console support. Deleting the HCD / IODF 
definitions for these obsolete devices is simpler than excluding these devices 
from the NIP address. We only know that HCD & IODF do not allow these devices 
to be defined. IBM does not change code unless it's necessary and only deletes 
non-functional code when they are already working on that module. As for 
removing the device support code, this code might also support the CONSOLE 
printer devices.  Deletion of these modules is pure conjecture without any 
factual basis.

On Wednesday, July 26, 2023 at 03:49:12 AM PDT, Tony Harminc 
 wrote:

 On Tue, 25 Jul 2023 at 17:25, Seymour J Metz  wrote:
>
> I would have expected 1052-7, 3210 and 3215 support to die at the same time.

Is there any reason to think that there is/was separate code for these
three devices? IIRC their programming specs are identical, or very
close to identical. Obviously the hardware is quite different
(Selectric printer, dot-matrix), but the software generally doesn't
care about that kind of thing.

Tony H.

> 
> From: IBM Mainframe Discussion List  on behalf of 
> Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu>
[...]
> ISTR the some of the older "console" support was removed in the indicated 
> timeframe. E.g. 1052
> I cannot say for certain that the 3215 code was removed at that time.

--
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: Ignorant z/OS question

2023-07-26 Thread Jon Perryman

 > On Wednesday, July 26, 2023 at 03:49:12 AM PDT, Tony Harminc 
 >  wrote:

>>On Tue, 25 Jul 2023 at 17:25, Seymour J Metz  wrote:

>> I would have expected 1052-7, 3210 and 3215 support to die at the same time.

> Is there any reason to think that there is/was separate code for these

> three devices? IIRC their programming specs are identical, or very

> close to identical. Obviously the hardware is quite different

> (Selectric printer, dot-matrix), but the software generally doesn't

> care about that kind of thing.

Seymour constantly makes silly wild ass guesses and passes them off as fact. 
Use your common sense and knowledge about IBM. When IBM rewrote console 
services, they dropped typewriter console support. Deleting the HCD / IODF 
definitions for these obsolete devices is simpler than excluding these devices 
from the NIP address. We only know that HCD & IODF do not allow these devices 
to be defined. IBM does not change code unless it's necessary and only deletes 
non-functional code when they are already working on that module. As for 
removing the device support code, this code might also support the CONSOLE 
printer devices.  Deletion of these modules is pure conjecture without any 
factual basis. 

On Wednesday, July 26, 2023 at 03:49:12 AM PDT, Tony Harminc 
 wrote:  

 On Tue, 25 Jul 2023 at 17:25, Seymour J Metz  wrote:
>
> I would have expected 1052-7, 3210 and 3215 support to die at the same time.

Is there any reason to think that there is/was separate code for these
three devices? IIRC their programming specs are identical, or very
close to identical. Obviously the hardware is quite different
(Selectric printer, dot-matrix), but the software generally doesn't
care about that kind of thing.

Tony H.

> 
> From: IBM Mainframe Discussion List  on behalf of 
> Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu>
[...]
> ISTR the some of the older "console" support was removed in the indicated 
> timeframe. E.g. 1052
> I cannot say for certain that the 3215 code was removed at that time.

--
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: Ignorant z/OS question

2023-07-26 Thread Jon Perryman

 > On Tuesday, July 25, 2023 at 07:14:21 PM PDT, Steve Horein 
 >  wrote:
> Just out of curiosity, is there such a thing as VM "attach" to reconnect a

> device at a later time?


Phil would need to verify what I'm saying. "detach" is a generic command that 
eliminates a virtual address regardless of how the virtual address was defined. 
"attach" is for attaching real VM addresses to a user at a virtual address. 
Detaching a "console" requires a "DEFINE CONSOLE". Detaching a "GRAF" requires 
a "DEFINE GRAF". I think there are several variations of DEFINE specific to the 
virtual device type.


On Tuesday, July 25, 2023 at 07:14:21 PM PDT, Steve Horein 
 wrote:  
 
 To my understanding, that sounds correct.

Explicitly removing the NIP *console* definition, though leaving the
address defined/intact in the IODF for later use by MVS console services
(CONSOLxx), would have the same effect as making the device inaccessible,
either through (presumably) bad cabling in my case, or through VM detach
that you describe, which sounds more dynamic.

Just out of curiosity, is there such a thing as VM "attach" to reconnect a
device at a later time?

On Tue, Jul 25, 2023 at 7:20 PM Jon Perryman  wrote:

>  > On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein <
> steve.hor...@gmail.com> wrote:
> > This is what I was referring to, relating to NIP and IODF:
>
> Phil, you can ignore this topic.
>
> Steve, does it make a difference if the NIP address doesn't exist versus
> clearing the NIP address in the IODF? I thought both caused the hardware
> console to be used.  updating the NIP address might not be something Phil
> is comfortable with. Phil understands VM detach and it should achieve the
> same results. Detaching all consoles ensures things like problem
> determination mode and more doesn't affect hardware console activation.
> Phil gets 1 chance on the weekend and I'm just ensuring we cover the most
> possibilities in 1 try.
>
> Am I wrong? If this works, then recommending the deletion of the NIP
> address becomes a trivial change.
>
>
>    On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein <
> steve.hor...@gmail.com> wrote:
>
>  This is what I was referring to, relating to NIP and IODF:
>
> https://www.ibm.com/docs/en/zos/2.4.0?topic=configuration-working-operating-system-consoles
>
>
> The topic mentions both MVS and VM, so there may be some useful
> information.
>
> While I mentioned my request to have "...the NIP *device *be removed from
> IODF", I should have stated to have "... the NIP *CONSOLE* be removed from
> IODF".
> Yes, the device should be defined to allow CONSOLxx to make use of it once
> MVS has been initialized, but an IODF defined NIP CONSOLE is not
> required, making use of the hardware console in its absence.
>
> Maybe you're saying the same thing, just in VM speak?!
>
> On Tue, Jul 25, 2023 at 10:43 AM Jon Perryman 
> wrote:
>
> >  > On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
> > steve.hor...@gmail.com> wrote:
> > > The only time I have seen NIP messages (those messages prior to VARY
> >
> > > CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP
> > device
> >
> >
> > Hi Phil, Sorry for the long delay.but I had other things to do. Steve may
> > have a possible solution. Let me put it into terms you can understand.
> >
> > Steve says there is 1 exception to the hardware console requiring V
> > CN(*),ACT to become the first active console during IPL. He says if you
> > disable all z/OS DEV(###) consoles, then the hardware console will
> > automatically activate because there is no other console available. I
> > believe this to be true but I have never tried this. There may be a
> couple
> > caveats that can be discussed later if it solves your problem.
> >  This is simple to test. From the z/OS VM user, detach all devices
> > specified in PARMLIB(CONSOL##). At the moment, forget he mentions "NIP"
> > device because this is almost always included in PARMLIB(CONSOL##) which
> > means you would have detached it. This is so simple it's worth a try.
> >
> >
> >
> >    On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
> > steve.hor...@gmail.com> wrote:
> >
> >  The only time I have seen NIP messages (those messages prior to VARY
> > CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP
> device
> > defined in the IODF was not available, I believe due to some cabling
> > issues. In that situation, all NIP messages were routed to the SE/HMC
> > System Console. I had requested the NIP device be removed from IODF years
> > before, for that exact purpose, to assist with automation that uses
> > SYSCONS, and/or for diagnostics, but due to Fear/Uncertainty/Doubt, the
> > request was flatly denied.
> >
> > https://www.ibm.com/docs/en/zos/2.4.0?topic=system-nip-console
> > "If no NIP console is defined and ready, MVS™ will use the system console
> > as the NIP-time console."
> >
> > I have zero experience with zVM, so I do not know if

Re: Ignorant z/OS question

2023-07-26 Thread Phil Smith III

Berry van Sleeuwen wrote, in part:
>I guess it doesn't really matter what address you use, especially for
>Guest Operating Systems, as long as they are defined in their
>respective configuration members (CONSOLxx for z/OS, SYSTEM CONFIG for
>z/VM, IPL proc for z/VSE).

Right. I'm betting that z/OS (which does know when it's running under VM) does 
a DIAG x'24' to find where the actual console is even if it doesn't match 
CONSOLxx.

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

Re: Ignorant z/OS question

2023-07-26 Thread Seymour J Metz

That's why I would have expected them to die in lockstep.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Wednesday, July 26, 2023 6:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

On Tue, 25 Jul 2023 at 17:25, Seymour J Metz  wrote:
>
> I would have expected 1052-7, 3210 and 3215 support to die at the same time.

Is there any reason to think that there is/was separate code for these
three devices? IIRC their programming specs are identical, or very
close to identical. Obviously the hardware is quite different
(Selectric printer, dot-matrix), but the software generally doesn't
care about that kind of thing.

Tony H.

> 
> From: IBM Mainframe Discussion List  on behalf of 
> Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu>
[...]
> ISTR the some of the older "console" support was removed in the indicated 
> timeframe. E.g. 1052
> I cannot say for certain that the 3215 code was removed at that time.

--
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: Ignorant z/OS question

2023-07-26 Thread Seymour J Metz

<https://www.vm.ibm.com/library/720pdfs/72626811.pdf#page=70> is ATTACH, but 
DIAL is more useful for MVS guests.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Horein [steve.hor...@gmail.com]
Sent: Tuesday, July 25, 2023 10:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

To my understanding, that sounds correct.

Explicitly removing the NIP *console* definition, though leaving the
address defined/intact in the IODF for later use by MVS console services
(CONSOLxx), would have the same effect as making the device inaccessible,
either through (presumably) bad cabling in my case, or through VM detach
that you describe, which sounds more dynamic.

Just out of curiosity, is there such a thing as VM "attach" to reconnect a
device at a later time?

On Tue, Jul 25, 2023 at 7:20 PM Jon Perryman  wrote:

>  > On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein <
> steve.hor...@gmail.com> wrote:
> > This is what I was referring to, relating to NIP and IODF:
>
> Phil, you can ignore this topic.
>
> Steve, does it make a difference if the NIP address doesn't exist versus
> clearing the NIP address in the IODF? I thought both caused the hardware
> console to be used.  updating the NIP address might not be something Phil
> is comfortable with. Phil understands VM detach and it should achieve the
> same results. Detaching all consoles ensures things like problem
> determination mode and more doesn't affect hardware console activation.
> Phil gets 1 chance on the weekend and I'm just ensuring we cover the most
> possibilities in 1 try.
>
> Am I wrong? If this works, then recommending the deletion of the NIP
> address becomes a trivial change.
>
>
> On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein <
> steve.hor...@gmail.com> wrote:
>
>  This is what I was referring to, relating to NIP and IODF:
>
> https://www.ibm.com/docs/en/zos/2.4.0?topic=configuration-working-operating-system-consoles
>
>
> The topic mentions both MVS and VM, so there may be some useful
> information.
>
> While I mentioned my request to have "...the NIP *device *be removed from
> IODF", I should have stated to have "... the NIP *CONSOLE* be removed from
> IODF".
> Yes, the device should be defined to allow CONSOLxx to make use of it once
> MVS has been initialized, but an IODF defined NIP CONSOLE is not
> required, making use of the hardware console in its absence.
>
> Maybe you're saying the same thing, just in VM speak?!
>
> On Tue, Jul 25, 2023 at 10:43 AM Jon Perryman 
> wrote:
>
> >  > On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
> > steve.hor...@gmail.com> wrote:
> > > The only time I have seen NIP messages (those messages prior to VARY
> >
> > > CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP
> > device
> >
> >
> > Hi Phil, Sorry for the long delay.but I had other things to do. Steve may
> > have a possible solution. Let me put it into terms you can understand.
> >
> > Steve says there is 1 exception to the hardware console requiring V
> > CN(*),ACT to become the first active console during IPL. He says if you
> > disable all z/OS DEV(###) consoles, then the hardware console will
> > automatically activate because there is no other console available. I
> > believe this to be true but I have never tried this. There may be a
> couple
> > caveats that can be discussed later if it solves your problem.
> >  This is simple to test. From the z/OS VM user, detach all devices
> > specified in PARMLIB(CONSOL##). At the moment, forget he mentions "NIP"
> > device because this is almost always included in PARMLIB(CONSOL##) which
> > means you would have detached it. This is so simple it's worth a try.
> >
> >
> >
> >On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
> > steve.hor...@gmail.com> wrote:
> >
> >  The only time I have seen NIP messages (those messages prior to VARY
> > CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP
> device
> > defined in the IODF was not available, I believe due to some cabling
> > issues. In that situation, all NIP messages were routed to the SE/HMC
> > System Console. I had requested the NIP device be removed from IODF years
> > before, for that exact purpose, to assist with automation that uses
> > SYSCONS, and/or for diagnostics, but due to Fear/Uncertainty/Doubt, the
> > request was flatly denied.
> >
> > https://www.ibm.com/docs/en/zos/2.4.0?t

Re: Ignorant z/OS question

2023-07-26 Thread Tony Harminc

On Tue, 25 Jul 2023 at 17:25, Seymour J Metz  wrote:
>
> I would have expected 1052-7, 3210 and 3215 support to die at the same time.

Is there any reason to think that there is/was separate code for these
three devices? IIRC their programming specs are identical, or very
close to identical. Obviously the hardware is quite different
(Selectric printer, dot-matrix), but the software generally doesn't
care about that kind of thing.

Tony H.

> 
> From: IBM Mainframe Discussion List  on behalf of 
> Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu>
[...]
> ISTR the some of the older "console" support was removed in the indicated 
> timeframe. E.g. 1052
> I cannot say for certain that the 3215 code was removed at that time.

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

Re: Ignorant z/OS question

2023-07-26 Thread Allan Staller

Classification: Confidential

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

In this case, it means te code to support said devices was *removed* from z/OS. 
I can't speak for z/VM.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Tuesday, July 25, 2023 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

 > Phil wrote: What does "not supported" mean per se?

 The last 3215 connected to IBM computers using an ICA. IBM z computers do not 
have an ICA nor byte channel therefore not supported on a z16. I suspect you 
can't even define one in the HCD. What was the last IBM computer to have an ICA.
On Monday, July 24, 2023 at 10:48:42 AM PDT, Phil Smith III 
 wrote:

 Shmuel asked:
>Do you have the URL for the Tracy Dean paper?

Yes, I've read it.

>Does it spell out all the pieces?
Probably, but as I said before, it makes enough assumptions that I can't 
understand what to do.

Alan Staller wrote:
>Going back to the original post, I seemed to have missed the
>information about the operating system release.

>z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR
>MVS/ESA R.x, but that could be incorrect.)

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

--
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
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.

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

Re: Ignorant z/OS question

2023-07-26 Thread Allan Staller

Classification: Confidential

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Tuesday, July 25, 2023 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

 > Phil wrote: What does "not supported" mean per se?

 The last 3215 connected to IBM computers using an ICA. IBM z computers do not 
have an ICA nor byte channel therefore not supported on a z16. I suspect you 
can't even define one in the HCD. What was the last IBM computer to have an ICA.
On Monday, July 24, 2023 at 10:48:42 AM PDT, Phil Smith III 
 wrote:

 Shmuel asked:
>Do you have the URL for the Tracy Dean paper?

Yes, I've read it.

>Does it spell out all the pieces?
Probably, but as I said before, it makes enough assumptions that I can't 
understand what to do.

Alan Staller wrote:
>Going back to the original post, I seemed to have missed the
>information about the operating system release.

>z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR
>MVS/ESA R.x, but that could be incorrect.)

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

--
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
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.

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

Re: Ignorant z/OS question

2023-07-26 Thread Allan Staller

Classification: Confidential

As indicated previously, the code to support those devices was *removed* from 
z/OS (or whatever incarnation at that time).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Tuesday, July 25, 2023 11:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

PMFJI here, but when I heard some years ago that z/OS dropped support for 3215 
keyboard/printer consoles it occurred to me to ask what the users of z/OS under 
z/VM were supposed to do to easily automate console logging/monitoring and 
automated IPL/shutdown external to z/OS?  Maybe more recent z/VM’s have 
facilities I am not aware of that can directly capture output from and interact 
with 3270 devices better than in older versions, but I haven’t seen anything in 
this thread that would support that speculation.

Why withdraw support for a simple to use and simple to automate console 
interface that Just Worked (tm)?  It never made any sense to me.  Maybe 
z/OS-centric hubris (automation can only happen inside z/OS, do it our way or 
hit the highway, dude)?

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Tuesday, July 25, 2023 12:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Hi Phil,

z/VM has ALWAYS (since VM R6.0.) had the CONSOLE at 009 in the Directory

entry for users by convention.

You could DEF 9 3E1 to change it.

Regards,

David

On 2023-07-25 12:00, Phil Smith III wrote:

> Jon Perryman wrote:

>> Steve says there is 1 exception to the hardware console requiring V

>> CN(*),ACT to become the first active console during IPL. He says if

>> you disable all z/OS DEV(###) consoles, then the hardware console
>> will

>> automatically activate because there is no other console available. I

>> believe this to be true but I have never tried this. There may be a

>> couple caveats that can be discussed later if it solves your problem.

>> This is simple to test. From the z/OS VM user, detach all devices

>> specified in PARMLIB(CONSOL##). At the moment, forget he mentions

>> "NIP" device because this is almost always included in

>> PARMLIB(CONSOL##) which means you would have detached it. This is so

>> simple it's worth a try.

> I will, when I can--maybe this weekend! That might be the answer, because the 
> original directory entry (I'm told) had the virtual console at 0009, but the 
> CONSOLxx has it at 03E1.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.

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

Re: Ignorant z/OS question

2023-07-25 Thread Phil Smith III

David Spiegel wrote:
z/VM has ALWAYS (since VM R6.0.) had the CONSOLE at 009 in the Directory
entry for users by convention.
You could DEF 9 3E1 to change it.

Right, but this guest has one at 3E1. I didn't set it up, nor port it from the 
other system; it's possible that whoever did that looked at CONSOLxx on the old 
system, saw the 3E1, and said "I'll put the console there". Hence the 
possibility that bringing it up with the console *not* at 3E1 will change the 
behavior. Hopefully this weekend; I can IPL to my heart's content then.

Jon Perryman wrote: 
>"virtual console" is not a valid concept for VM CP. "CONSOLE 009 3215"
>has nothing to do with a console. 

Eh? Sure it is. Try running CMS without one.

>Have you ever tried adding both "CONSOLE 009 3215" and "CONSOLE 3E1
>3270" to the same user. I'm guessing that VM allows multiple CONSOLE
>statements. If you try it, can you let us know the results because I'm
>now curious about it.

Can't. VM allows up to one console per guest (really exactly one, as you won't 
do much without it, even DSC).

>"CONSOLE 03E1 3270" means create device address 03E1 and use DIAG 58 to
>display data received on this address and send to 03E1 all changes to
>the screen using a 3270 data stream. 

Not to CMS it doesn't. In fact, if I define a console as a 3270 and IPL CMS, it 
gets converted to a 3215. DIAG 58 is a CP thing that does full-screen writes to 
a 3215, sorta.

>In z/OS, 3E1 could be connected to anything for example VTAM. In your
>case, there is a definition in PARMLIB(CONSOL##) that tells the
>console address space to use 3E1 as a z/OS console.

Right, we've established that there is. Hence the desire to try with 0009.

>"CONSOLE 009 3215" means create device address 009 and all data
>received is forwarded to CP to be displayed by CP and commands
>returned to 009. Do you consider that CMS interacting with a console
>or a terminal. In z/OS, we have TSO which does the same thing but we
>call it a terminal instead of console.

That's CMS interacting with a console. The physical terminal is related to 
that, but only if there is one--for example, a VM guest running disconnected 
still has and uses its console.

This is fun, it's like we're talking different dialects of the same language!

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

Re: Ignorant z/OS question

2023-07-25 Thread Steve Horein

To my understanding, that sounds correct.

Explicitly removing the NIP *console* definition, though leaving the
address defined/intact in the IODF for later use by MVS console services
(CONSOLxx), would have the same effect as making the device inaccessible,
either through (presumably) bad cabling in my case, or through VM detach
that you describe, which sounds more dynamic.

Just out of curiosity, is there such a thing as VM "attach" to reconnect a
device at a later time?

On Tue, Jul 25, 2023 at 7:20 PM Jon Perryman  wrote:

>  > On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein <
> steve.hor...@gmail.com> wrote:
> > This is what I was referring to, relating to NIP and IODF:
>
> Phil, you can ignore this topic.
>
> Steve, does it make a difference if the NIP address doesn't exist versus
> clearing the NIP address in the IODF? I thought both caused the hardware
> console to be used.  updating the NIP address might not be something Phil
> is comfortable with. Phil understands VM detach and it should achieve the
> same results. Detaching all consoles ensures things like problem
> determination mode and more doesn't affect hardware console activation.
> Phil gets 1 chance on the weekend and I'm just ensuring we cover the most
> possibilities in 1 try.
>
> Am I wrong? If this works, then recommending the deletion of the NIP
> address becomes a trivial change.
>
>
> On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein <
> steve.hor...@gmail.com> wrote:
>
>  This is what I was referring to, relating to NIP and IODF:
>
> https://www.ibm.com/docs/en/zos/2.4.0?topic=configuration-working-operating-system-consoles
>
>
> The topic mentions both MVS and VM, so there may be some useful
> information.
>
> While I mentioned my request to have "...the NIP *device *be removed from
> IODF", I should have stated to have "... the NIP *CONSOLE* be removed from
> IODF".
> Yes, the device should be defined to allow CONSOLxx to make use of it once
> MVS has been initialized, but an IODF defined NIP CONSOLE is not
> required, making use of the hardware console in its absence.
>
> Maybe you're saying the same thing, just in VM speak?!
>
> On Tue, Jul 25, 2023 at 10:43 AM Jon Perryman 
> wrote:
>
> >  > On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
> > steve.hor...@gmail.com> wrote:
> > > The only time I have seen NIP messages (those messages prior to VARY
> >
> > > CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP
> > device
> >
> >
> > Hi Phil, Sorry for the long delay.but I had other things to do. Steve may
> > have a possible solution. Let me put it into terms you can understand.
> >
> > Steve says there is 1 exception to the hardware console requiring V
> > CN(*),ACT to become the first active console during IPL. He says if you
> > disable all z/OS DEV(###) consoles, then the hardware console will
> > automatically activate because there is no other console available. I
> > believe this to be true but I have never tried this. There may be a
> couple
> > caveats that can be discussed later if it solves your problem.
> >  This is simple to test. From the z/OS VM user, detach all devices
> > specified in PARMLIB(CONSOL##). At the moment, forget he mentions "NIP"
> > device because this is almost always included in PARMLIB(CONSOL##) which
> > means you would have detached it. This is so simple it's worth a try.
> >
> >
> >
> >On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
> > steve.hor...@gmail.com> wrote:
> >
> >  The only time I have seen NIP messages (those messages prior to VARY
> > CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP
> device
> > defined in the IODF was not available, I believe due to some cabling
> > issues. In that situation, all NIP messages were routed to the SE/HMC
> > System Console. I had requested the NIP device be removed from IODF years
> > before, for that exact purpose, to assist with automation that uses
> > SYSCONS, and/or for diagnostics, but due to Fear/Uncertainty/Doubt, the
> > request was flatly denied.
> >
> > https://www.ibm.com/docs/en/zos/2.4.0?topic=system-nip-console
> > "If no NIP console is defined and ready, MVS™ will use the system console
> > as the NIP-time console."
> >
> > I have zero experience with zVM, so I do not know if that NIP message
> > behavior is the same when MVS is running as a guest. I just figured I
> would
> > pass along my anecdotal observations.
> >
> > --
> > 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

Re: Ignorant z/OS question

 > On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein 
 >  wrote:
> This is what I was referring to, relating to NIP and IODF:

Phil, you can ignore this topic.

Steve, does it make a difference if the NIP address doesn't exist versus 
clearing the NIP address in the IODF? I thought both caused the hardware 
console to be used.  updating the NIP address might not be something Phil is 
comfortable with. Phil understands VM detach and it should achieve the same 
results. Detaching all consoles ensures things like problem determination mode 
and more doesn't affect hardware console activation. Phil gets 1 chance on the 
weekend and I'm just ensuring we cover the most possibilities in 1 try.

Am I wrong? If this works, then recommending the deletion of the NIP address 
becomes a trivial change. 


On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein 
 wrote:  
 
 This is what I was referring to, relating to NIP and IODF:
https://www.ibm.com/docs/en/zos/2.4.0?topic=configuration-working-operating-system-consoles


The topic mentions both MVS and VM, so there may be some useful
information.

While I mentioned my request to have "...the NIP *device *be removed from
IODF", I should have stated to have "... the NIP *CONSOLE* be removed from
IODF".
Yes, the device should be defined to allow CONSOLxx to make use of it once
MVS has been initialized, but an IODF defined NIP CONSOLE is not
required, making use of the hardware console in its absence.

Maybe you're saying the same thing, just in VM speak?!

On Tue, Jul 25, 2023 at 10:43 AM Jon Perryman  wrote:

>  > On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
> steve.hor...@gmail.com> wrote:
> > The only time I have seen NIP messages (those messages prior to VARY
>
> > CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP
> device
>
>
> Hi Phil, Sorry for the long delay.but I had other things to do. Steve may
> have a possible solution. Let me put it into terms you can understand.
>
> Steve says there is 1 exception to the hardware console requiring V
> CN(*),ACT to become the first active console during IPL. He says if you
> disable all z/OS DEV(###) consoles, then the hardware console will
> automatically activate because there is no other console available. I
> believe this to be true but I have never tried this. There may be a couple
> caveats that can be discussed later if it solves your problem.
>  This is simple to test. From the z/OS VM user, detach all devices
> specified in PARMLIB(CONSOL##). At the moment, forget he mentions "NIP"
> device because this is almost always included in PARMLIB(CONSOL##) which
> means you would have detached it. This is so simple it's worth a try.
>
>
>
>    On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
> steve.hor...@gmail.com> wrote:
>
>  The only time I have seen NIP messages (those messages prior to VARY
> CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP device
> defined in the IODF was not available, I believe due to some cabling
> issues. In that situation, all NIP messages were routed to the SE/HMC
> System Console. I had requested the NIP device be removed from IODF years
> before, for that exact purpose, to assist with automation that uses
> SYSCONS, and/or for diagnostics, but due to Fear/Uncertainty/Doubt, the
> request was flatly denied.
>
> https://www.ibm.com/docs/en/zos/2.4.0?topic=system-nip-console
> "If no NIP console is defined and ready, MVS™ will use the system console
> as the NIP-time console."
>
> I have zero experience with zVM, so I do not know if that NIP message
> behavior is the same when MVS is running as a guest. I just figured I would
> pass along my anecdotal observations.
>
> --
> 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
  

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

Re: Ignorant z/OS question

2023-07-25 Thread Tom Brennan


On 7/25/2023 2:39 PM, Jon Perryman wrote:

z15 and z16 have hardware consoles (PC's) instead of 3270.


Are you talking about the HMC's and SE's? (whether external or HMA's)

Otherwise the only "PC" I can think of related to a mainframe console is 
probably out on an operator's desk, where they can remotely access the 
HMC's, SE's, and OSA-ICC TN3270 connections (which still send 3270 
streams back and forth).


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

Re: Ignorant z/OS question

2023-07-25 Thread Steve Horein

This is what I was referring to, relating to NIP and IODF:
https://www.ibm.com/docs/en/zos/2.4.0?topic=configuration-working-operating-system-consoles


The topic mentions both MVS and VM, so there may be some useful
information.

While I mentioned my request to have "...the NIP *device *be removed from
IODF", I should have stated to have "... the NIP *CONSOLE* be removed from
IODF".
Yes, the device should be defined to allow CONSOLxx to make use of it once
MVS has been initialized, but an IODF defined NIP CONSOLE is not
required, making use of the hardware console in its absence.

Maybe you're saying the same thing, just in VM speak?!

On Tue, Jul 25, 2023 at 10:43 AM Jon Perryman  wrote:

>  > On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
> steve.hor...@gmail.com> wrote:
> > The only time I have seen NIP messages (those messages prior to VARY
>
> > CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP
> device
>
>
> Hi Phil, Sorry for the long delay.but I had other things to do. Steve may
> have a possible solution. Let me put it into terms you can understand.
>
> Steve says there is 1 exception to the hardware console requiring V
> CN(*),ACT to become the first active console during IPL. He says if you
> disable all z/OS DEV(###) consoles, then the hardware console will
> automatically activate because there is no other console available. I
> believe this to be true but I have never tried this. There may be a couple
> caveats that can be discussed later if it solves your problem.
>  This is simple to test. From the z/OS VM user, detach all devices
> specified in PARMLIB(CONSOL##). At the moment, forget he mentions "NIP"
> device because this is almost always included in PARMLIB(CONSOL##) which
> means you would have detached it. This is so simple it's worth a try.
>
>
>
> On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
> steve.hor...@gmail.com> wrote:
>
>  The only time I have seen NIP messages (those messages prior to VARY
> CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP device
> defined in the IODF was not available, I believe due to some cabling
> issues. In that situation, all NIP messages were routed to the SE/HMC
> System Console. I had requested the NIP device be removed from IODF years
> before, for that exact purpose, to assist with automation that uses
> SYSCONS, and/or for diagnostics, but due to Fear/Uncertainty/Doubt, the
> request was flatly denied.
>
> https://www.ibm.com/docs/en/zos/2.4.0?topic=system-nip-console
> "If no NIP console is defined and ready, MVS™ will use the system console
> as the NIP-time console."
>
> I have zero experience with zVM, so I do not know if that NIP message
> behavior is the same when MVS is running as a guest. I just figured I would
> pass along my anecdotal observations.
>
> --
> 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: Ignorant z/OS question

 > On Tuesday, July 25, 2023 at 12:47:52 PM PDT, Tom Brennan 
 >  wrote:

> I don't know what an ICA is in this context,  ICA (Integrated Channel 
> Adapter) back in the days when we still had channels and 3270 was the 
> hardware console.  z15 and z16 have hardware consoles (PC's) instead of 3270. 
> No more need for an ICA with 3270. TPF specifically needs it for some reason 
> thus the need for OSA-ICC-3215.  z15 and z16 are glorified PCs. Instead of 
> channels, they use PCIe slots just like your PC. OSA-ICC-3215 plugs into a 
> PCIe slot. You are told that your z16 has 200 CPUs but there are only 16 
> CPUs. Like your PC,  You think it's special because IBM says z16 has 200 CPUs 
> but if you open the box there is only 16 CPU each with 16 cores. 256 cores 
> minus 56 cores reserved for the system is 200 cores that IBM calls 200 CPUs.
  
On Tuesday, July 25, 2023 at 12:47:52 PM PDT, Tom Brennan 
 wrote:  
 
 I don't know what an ICA is in this context, but your note rang a bell. 
When the folks I work with configure a (modern) machine to be used for 
TPF, they include this feature code.

8P2980  OSA ICC- 3215 Enablement    (this one for a z15)

I've been told this is needed for TPF console processing, although I 
don't know the details.  8P2980 costs money so it's not configured on 
machines we work with that don't run TPF.

On 7/25/2023 12:03 PM, Jon Perryman wrote:
>  > Phil wrote: What does "not supported" mean per se?
> 
>   The last 3215 connected to IBM computers using an ICA. IBM z computers do 
>not have an ICA nor byte channel therefore not supported on a z16. I suspect 
>you can't even define one in the HCD. What was the last IBM computer to have 
>an ICA.
>      On Monday, July 24, 2023 at 10:48:42 AM PDT, Phil Smith III 
> wrote:
>  
>  Shmuel asked:
>> Do you have the URL for the Tracy Dean paper?
> 
> Yes, I've read it.
> 
>> Does it spell out all the pieces?
> Probably, but as I said before, it makes enough assumptions that I can't 
> understand what to do.
> 
> Alan Staller wrote:
>> Going back to the original post, I seemed to have missed the
>> information about the operating system release.
> 
>> z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR
>> MVS/ESA R.x, but that could be incorrect.)
> 
> This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, 
> just the output is fugly. And I'm 99.44% sure that wasn't true on our 
> previous system.
> 
> --
> 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
  

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

Re: Ignorant z/OS question

2023-07-25 Thread Tom Brennan

I don't know what an ICA is in this context, but your note rang a bell. 
When the folks I work with configure a (modern) machine to be used for 
TPF, they include this feature code.


8P2980  OSA ICC- 3215 Enablement(this one for a z15)

I've been told this is needed for TPF console processing, although I 
don't know the details.  8P2980 costs money so it's not configured on 
machines we work with that don't run TPF.


On 7/25/2023 12:03 PM, Jon Perryman wrote:

  > Phil wrote: What does "not supported" mean per se?

  The last 3215 connected to IBM computers using an ICA. IBM z computers do not 
have an ICA nor byte channel therefore not supported on a z16. I suspect you 
can't even define one in the HCD. What was the last IBM computer to have an ICA.
 On Monday, July 24, 2023 at 10:48:42 AM PDT, Phil Smith III 
 wrote:
  
  Shmuel asked:

Do you have the URL for the Tracy Dean paper?


Yes, I've read it.


Does it spell out all the pieces?

Probably, but as I said before, it makes enough assumptions that I can't 
understand what to do.

Alan Staller wrote:

Going back to the original post, I seemed to have missed the
information about the operating system release.



z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR
MVS/ESA R.x, but that could be incorrect.)


This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous system.

--
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: Ignorant z/OS question

 > Phil said: (I'm told) had the virtual console at 0009, but the CONSOLxx has 
 > it at 03E1.
  "virtual console" is not a valid concept for VM CP. "CONSOLE 009 3215" has 
nothing to do with a console. Have you ever tried adding both "CONSOLE 009 
3215" and "CONSOLE 3E1 3270" to the same user. I'm guessing that VM allows 
multiple CONSOLE statements. If you try it, can you let us know the results 
because I'm now curious about it.  "CONSOLE 03E1 3270" means create device 
address 3E1 and use DIAG 58 to display data received on this address and send 
to 3E1 all changes to the screen using a 3270 data stream. In z/OS, 3E1 could 
be connected to anything for example VTAM. In your case, there is a definition 
in PARMLIB(CONSOL##) that tells the console address space to use 3E1 as a z/OS 
console.  "CONSOLE 009 3215" means create device address 009 and all data 
received is forwarded to CP to be displayed by CP and commands returned to 009. 
Do you consider that CMS interacting with a console or a terminal. In z/OS, we 
have TSO which does the same thing but we call it a terminal instead of 
console.  
On Tuesday, July 25, 2023 at 09:00:19 AM PDT, Phil Smith III 
 wrote:  
 
 Jon Perryman wrote:
>Steve says there is 1 exception to the hardware console requiring V
>CN(*),ACT to become the first active console during IPL. He says if
>you disable all z/OS DEV(###) consoles, then the hardware console will
>automatically activate because there is no other console available. I
>believe this to be true but I have never tried this. There may be a
>couple caveats that can be discussed later if it solves your problem.

>This is simple to test. From the z/OS VM user, detach all devices
>specified in PARMLIB(CONSOL##). At the moment, forget he mentions
>"NIP" device because this is almost always included in
>PARMLIB(CONSOL##) which means you would have detached it. This is so
>simple it's worth a try.

I will, when I can--maybe this weekend! That might be the answer, because the 
original directory entry (I'm told) had the virtual console at 0009, but the 
CONSOLxx has it at 03E1.

--
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: Ignorant z/OS question

 > Phil wrote: What does "not supported" mean per se? 

 The last 3215 connected to IBM computers using an ICA. IBM z computers do not 
have an ICA nor byte channel therefore not supported on a z16. I suspect you 
can't even define one in the HCD. What was the last IBM computer to have an 
ICA.  
On Monday, July 24, 2023 at 10:48:42 AM PDT, Phil Smith III 
 wrote:  

 Shmuel asked:
>Do you have the URL for the Tracy Dean paper? 

Yes, I've read it.

>Does it spell out all the pieces?
Probably, but as I said before, it makes enough assumptions that I can't 
understand what to do.

Alan Staller wrote:
>Going back to the original post, I seemed to have missed the
>information about the operating system release.

>z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR
>MVS/ESA R.x, but that could be incorrect.)

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

--
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: Ignorant z/OS question

 > O'n Monday, July 24, 2023 at 10:07:48 AM PDT, Seymour J Metz 
 >  wrote:
> Do you have the URL for the Tracy Dean paper? Does it spell out all the 
> pieces?  While I'm not familiar with this paper, it's unlikely it solves 
> Phil's problem.  Phil can skip this because it's for the z/OS people. 
> PARMLIB(COMMND##) runs after NIP messages which means he will miss some 
> console messages. More important, simply adding the V CN(),ACT command did 
> not work because they say it took time to figure this out. The solution was 
> not a simple change of adding the command. If I had to venture a guess, the 
> command required the SSI be initialized and the console address space 
> attached to it. We know the hardware console uses the SSI otherwise V 
> CN(*),ACT would not have worked. The hardware console uses the SSI to issue 
> commands with possible exceptions during NIP.  On Monday, July 24, 2023 
> at 10:07:48 AM PDT, Seymour J Metz  wrote:  

 Do you have the URL for the Tracy Dean paper? Does it spell out all the pieces?

From: IBM Mainframe Discussion List  on behalf of 
Allan Staller 
Sent: Monday, July 24, 2023 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Classification: Confidential

Going back to the original post, I seemed to have missed the information about 
the operating system release.
z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR MVS/ESA 
R.x, but that could be incorrect.)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Friday, July 21, 2023 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Alan Altmark wrote:
>And if you haven't done so, please read the white paper Tracy Dean
>referenced in her post. It is focused on this aspect of managing z/OS
>guests. We spent a lot of time figuring out how to make it all come
>together. (And you may remember me asking related questions on IBM-MAIN
>at the time!)

>Particularly, understand that z/OS isn't using a "device" of any kind
>It thinks it's talking to the Operating System Messages task (aka
>integrated console on the HMC), which CP simulates the same way we do
>the 3215. It also means you can't just SEND a command like you can with
>CMS.

Well, I read that paper. Lots of assumptions in there about z/OS knowledge that 
I don't have, like where it talks about "V CN(MVS0MAST),OFFLINE". I have no V 
(I assume that's VARY?) in any of my CONSOLxx members.

I do have a CNGRP00, which contains:
GROUP          NAME(MSTGRP)
              MEMBERS(S0W103D0,S0W10FFF)

Now that's 3D0 and FFF: 3D0 is a DASD. Seems wrong? The INIT in CONSOL00 is 
INIT  CMDDELIM(;) AMRF(N) MONITOR(DSNAME) CNGRP(00) so it's looking at that 
console group. If I change the 3D0 to 3E1 to match the actual console address, 
is that likely to help/hurt? What I'd rather not do is kill the beast and 
require help from our hosting service--not that they won't help, but we'll have 
to wait at least a bit for that.

(BTW, a nit: "Screenshot 1 - z/VM Login Screen with Dial Command" on page 6 has 
no DIAL command on the screen)

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.

--
For IBM-MAIN subscribe / signoff

Re: Ignorant z/OS question

> The only CONSOLE DEV(###) that would be useful to Phil are printers that are 
> compatible with z/VM 3215.

Whoosh! The only relevant device is the one that z/OS doesn't support?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Tuesday, July 25, 2023 2:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Sunday, July 23, 2023 at 09:31:24 PM PDT, Seymour J Metz  
 > wrote: > That looks like the result of CP, HCD and MCS not specifying the 
 > same device type.
> What happens if all three are 3215? What happens if all three are 3270?  
> Please stop letting Seymour drag everyone down a rabbit hole. What Seymour is 
> saying is non-sense. He's being pompous by over valuing his own opinion. The 
> only CONSOLE DEV(###) that would be useful to Phil are printers that are 
> compatible with z/VM 3215.  Phil's only choices are CONSOLE DEV(###) printers 
> or the hardware console. Since Phil did not mention needing to issue z/OS 
> commands, printer should be acceptable. Unless I missed something, everything 
> else does not solve his problem.  Phil, you can ignore the rest of this 
> message because it is for the z/OS people. I need to describe why this is 
> complete non-sense.  1. The console addr space is a simple application that 
> happens to deal with z/OS commands and messages. It has multiple user 
> interfaces (e.g. device addresses - terminals/printers,  VTAM LU's, hardware 
> console, SSI, syslog, JES joblog & programmer log, remote console (think JES3 
> consolidated consoles) and probably a few I forgot to mention).  2. Each user 
> interface is designed around how it will be used. I've avoided details that 
> will confuse Phil who does not understand z/OS nor it's terminology. Those 
> missing details would be helpful for z/OS people to understand why I'm making 
> a statement.   3. Console DEV(###) user interface cannot support 3215. 
> DEV(###) supports a few printers for hardcopy log and 3270 for user 
> interface. If I remember correctly, the 3215 connected to channel 0 (byte 
> channel). We lost byte channels decades ago so I wouldn't expect it to be HCD 
> definable nor console definable.


4. Console DEV(###) for 3270 terminals can be queried. For years, I defined my 
TN3270 session 160 X 60 which is not a valid model but still worked with any 
valid 3278 model specified. 3174 supported ascii scrollable terminals but from 
Phils tests, it appears that console does not support this capability.   5. 
Console 3270 datastream is not useful to Phil. While it's possible to screen 
scrape, lines are scrolled on a 3270 console which would cause the same line to 
be displayed multiple times on the screen in different locations.  On 
Sunday, July 23, 2023 at 09:31:24 PM PDT, Seymour J Metz  wrote:

 That looks like the result of CP, HCD and MCS not specifying the same device 
type. What happens if all three are 3215? What happens if all three are 3270?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Sunday, July 23, 2023 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Well, this is interesting. Tried again just now with TERMINAL CONMODE 3215. It 
comes up, and I see SECUSER output. The only weirdness is that much of the 
output is oddly formatted (copied from SECUSER's screen, in linemode):

  B-*10.09.46  *CBR3002E Library LATL00 no longer u
sable.  C0*10.09.46  *CBR3002E Library LVTS00 no longe
r usable.  E  *10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,JES2_C
KPT_CONFIG_SVSCJES2):  F&    *IAZH123E One or more checkpoints or new check
points are not defined.  G-*10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,
JES2_CKPT_CONFIG_SVSCJES2):  H0*IAZH128E Operator verification is enabl
ed.¢- 10.11.25 STC03228  ADR111I-* AUTOMAT
IC SYSTEM*.&    - 10.11.25 STC03228  ADR111I-* STAR
T WILL BEGIN IN*<-- 10.11.25 STC03228  ADR111I-* A
PPROXIMATELY 60 SECONDS.  *(0- 10.11.25 STC03228  ADR111I-
**|    - 10.11.25 STC03228  ADR11
1I-* ISSUE COMMAND:  *&&    - 10.11.25 STC03228  AD
R111I-**J-- 10.11.25 STC03228
 ADR111I-* C ALLAUTO  *K0- 10.11.25 STC032
28  ADR111I-**M- 10.11.25 STC
03228  ADR111I-* TO STOP AUTO START.*

Re: Ignorant z/OS question

 > On Sunday, July 23, 2023 at 09:31:24 PM PDT, Seymour J Metz  
 > wrote: > That looks like the result of CP, HCD and MCS not specifying the 
 > same device type.
> What happens if all three are 3215? What happens if all three are 3270?  
> Please stop letting Seymour drag everyone down a rabbit hole. What Seymour is 
> saying is non-sense. He's being pompous by over valuing his own opinion. The 
> only CONSOLE DEV(###) that would be useful to Phil are printers that are 
> compatible with z/VM 3215.  Phil's only choices are CONSOLE DEV(###) printers 
> or the hardware console. Since Phil did not mention needing to issue z/OS 
> commands, printer should be acceptable. Unless I missed something, everything 
> else does not solve his problem.  Phil, you can ignore the rest of this 
> message because it is for the z/OS people. I need to describe why this is 
> complete non-sense.  1. The console addr space is a simple application that 
> happens to deal with z/OS commands and messages. It has multiple user 
> interfaces (e.g. device addresses - terminals/printers,  VTAM LU's, hardware 
> console, SSI, syslog, JES joblog & programmer log, remote console (think JES3 
> consolidated consoles) and probably a few I forgot to mention).  2. Each user 
> interface is designed around how it will be used. I've avoided details that 
> will confuse Phil who does not understand z/OS nor it's terminology. Those 
> missing details would be helpful for z/OS people to understand why I'm making 
> a statement.   3. Console DEV(###) user interface cannot support 3215. 
> DEV(###) supports a few printers for hardcopy log and 3270 for user 
> interface. If I remember correctly, the 3215 connected to channel 0 (byte 
> channel). We lost byte channels decades ago so I wouldn't expect it to be HCD 
> definable nor console definable.


4. Console DEV(###) for 3270 terminals can be queried. For years, I defined my 
TN3270 session 160 X 60 which is not a valid model but still worked with any 
valid 3278 model specified. 3174 supported ascii scrollable terminals but from 
Phils tests, it appears that console does not support this capability.   5. 
Console 3270 datastream is not useful to Phil. While it's possible to screen 
scrape, lines are scrolled on a 3270 console which would cause the same line to 
be displayed multiple times on the screen in different locations.  On 
Sunday, July 23, 2023 at 09:31:24 PM PDT, Seymour J Metz  
wrote:  
 
 That looks like the result of CP, HCD and MCS not specifying the same device 
type. What happens if all three are 3215? What happens if all three are 3270?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Sunday, July 23, 2023 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Well, this is interesting. Tried again just now with TERMINAL CONMODE 3215. It 
comes up, and I see SECUSER output. The only weirdness is that much of the 
output is oddly formatted (copied from SECUSER's screen, in linemode):

                  B-    *10.09.46          *CBR3002E Library LATL00 no longer u
sable.              C0    *10.09.46          *CBR3002E Library LVTS00 no longe
r usable.              E      *10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,JES2_C
KPT_CONFIG_SVSCJES2):      F&    *IAZH123E One or more checkpoints or new check
points are not defined.      G-    *10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,
JES2_CKPT_CONFIG_SVSCJES2):      H0    *IAZH128E Operator verification is enabl
ed.                                ¢    - 10.11.25 STC03228  ADR111I-* AUTOMAT
IC SYSTEM            *                .&    - 10.11.25 STC03228  ADR111I-* STAR
T WILL BEGIN IN        *                <-    - 10.11.25 STC03228  ADR111I-* A
PPROXIMATELY 60 SECONDS.  *                (0    - 10.11.25 STC03228  ADR111I-
*                            *                |    - 10.11.25 STC03228  ADR11
1I-* ISSUE COMMAND:              *                &&    - 10.11.25 STC03228  AD
R111I-*                            *                J-    - 10.11.25 STC03228
 ADR111I-* C ALLAUTO                  *                K0    - 10.11.25 STC032
28  ADR111I-*                            *                M    - 10.11.25 STC
03228  ADR111I-* TO STOP AUTO START.        *                N&  00- 10.11.25
STC03228  ADR111I-*                            *                O-    - 10.11.
25 STC03228  ADR111I-***                *0  IEE163I

If I take some of that output and manually reformat it, I get:

*CBR3002E Library LATL00 no longer usable.              C0    *10.09.46
*CBR3002E Library LVTS00 no longer usable.              E      *10.10.28 
STC03234
*HZS0003E CHECK(IBMJES2,JES2_CKPT_CONFIG_SVSCJES2):      F&
*IAZH123E O

Re: Ignorant z/OS question

2023-07-25 Thread Farley, Peter

PMFJI here, but when I heard some years ago that z/OS dropped support for 3215 
keyboard/printer consoles it occurred to me to ask what the users of z/OS under 
z/VM were supposed to do to easily automate console logging/monitoring and 
automated IPL/shutdown external to z/OS?  Maybe more recent z/VM’s have 
facilities I am not aware of that can directly capture output from and interact 
with 3270 devices better than in older versions, but I haven’t seen anything in 
this thread that would support that speculation.

Why withdraw support for a simple to use and simple to automate console 
interface that Just Worked (tm)?  It never made any sense to me.  Maybe 
z/OS-centric hubris (automation can only happen inside z/OS, do it our way or 
hit the highway, dude)?

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Tuesday, July 25, 2023 12:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Hi Phil,

z/VM has ALWAYS (since VM R6.0.) had the CONSOLE at 009 in the Directory

entry for users by convention.

You could DEF 9 3E1 to change it.

Regards,

David

On 2023-07-25 12:00, Phil Smith III wrote:

> Jon Perryman wrote:

>> Steve says there is 1 exception to the hardware console requiring V

>> CN(*),ACT to become the first active console during IPL. He says if

>> you disable all z/OS DEV(###) consoles, then the hardware console will

>> automatically activate because there is no other console available. I

>> believe this to be true but I have never tried this. There may be a

>> couple caveats that can be discussed later if it solves your problem.

>> This is simple to test. From the z/OS VM user, detach all devices

>> specified in PARMLIB(CONSOL##). At the moment, forget he mentions

>> "NIP" device because this is almost always included in

>> PARMLIB(CONSOL##) which means you would have detached it. This is so

>> simple it's worth a try.

> I will, when I can--maybe this weekend! That might be the answer, because the 
> original directory entry (I'm told) had the virtual console at 0009, but the 
> CONSOLxx has it at 03E1.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Ignorant z/OS question

2023-07-25 Thread David Spiegel


Hi Phil,
z/VM has ALWAYS (since VM R6.0.) had the CONSOLE at 009 in the Directory 
entry for users by convention.

You could DEF 9 3E1 to change it.

Regards,
David

On 2023-07-25 12:00, Phil Smith III wrote:

Jon Perryman wrote:

Steve says there is 1 exception to the hardware console requiring V
CN(*),ACT to become the first active console during IPL. He says if
you disable all z/OS DEV(###) consoles, then the hardware console will
automatically activate because there is no other console available. I
believe this to be true but I have never tried this. There may be a
couple caveats that can be discussed later if it solves your problem.
This is simple to test. From the z/OS VM user, detach all devices
specified in PARMLIB(CONSOL##). At the moment, forget he mentions
"NIP" device because this is almost always included in
PARMLIB(CONSOL##) which means you would have detached it. This is so
simple it's worth a try.

I will, when I can--maybe this weekend! That might be the answer, because the 
original directory entry (I'm told) had the virtual console at 0009, but the 
CONSOLxx has it at 03E1.

--
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: Ignorant z/OS question

2023-07-25 Thread Phil Smith III

Jon Perryman wrote:
>Steve says there is 1 exception to the hardware console requiring V
>CN(*),ACT to become the first active console during IPL. He says if
>you disable all z/OS DEV(###) consoles, then the hardware console will
>automatically activate because there is no other console available. I
>believe this to be true but I have never tried this. There may be a
>couple caveats that can be discussed later if it solves your problem.

>This is simple to test. From the z/OS VM user, detach all devices
>specified in PARMLIB(CONSOL##). At the moment, forget he mentions
>"NIP" device because this is almost always included in
>PARMLIB(CONSOL##) which means you would have detached it. This is so
>simple it's worth a try.

I will, when I can--maybe this weekend! That might be the answer, because the 
original directory entry (I'm told) had the virtual console at 0009, but the 
CONSOLxx has it at 03E1.

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

Re: Ignorant z/OS question

 > On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein 
 >  wrote:
> The only time I have seen NIP messages (those messages prior to VARY

> CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP device

Hi Phil, Sorry for the long delay.but I had other things to do. Steve may have 
a possible solution. Let me put it into terms you can understand. 

Steve says there is 1 exception to the hardware console requiring V CN(*),ACT 
to become the first active console during IPL. He says if you disable all z/OS 
DEV(###) consoles, then the hardware console will automatically activate 
because there is no other console available. I believe this to be true but I 
have never tried this. There may be a couple caveats that can be discussed 
later if it solves your problem. 
 This is simple to test. From the z/OS VM user, detach all devices specified in 
PARMLIB(CONSOL##). At the moment, forget he mentions "NIP" device because this 
is almost always included in PARMLIB(CONSOL##) which means you would have 
detached it. This is so simple it's worth a try.

On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein 
 wrote:  

 The only time I have seen NIP messages (those messages prior to VARY
CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP device
defined in the IODF was not available, I believe due to some cabling
issues. In that situation, all NIP messages were routed to the SE/HMC
System Console. I had requested the NIP device be removed from IODF years
before, for that exact purpose, to assist with automation that uses
SYSCONS, and/or for diagnostics, but due to Fear/Uncertainty/Doubt, the
request was flatly denied.

https://www.ibm.com/docs/en/zos/2.4.0?topic=system-nip-console
"If no NIP console is defined and ready, MVS™ will use the system console
as the NIP-time console."

I have zero experience with zVM, so I do not know if that NIP message
behavior is the same when MVS is running as a guest. I just figured I would
pass along my anecdotal observations.

--
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: Ignorant z/OS question

I would have expected 1052-7, 3210 and 3215 support to die at the same time.

From: IBM Mainframe Discussion List  on behalf of 
Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, July 25, 2023 10:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Classification: Confidential

ISTR the some of the older "console" support was removed in the indicated 
timeframe. E.g. 1052
I cannot say for certain that the 3215 code was removed at that time.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Monday, July 24, 2023 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Shmuel asked:
>Do you have the URL for the Tracy Dean paper?

Yes, I've read it.

>Does it spell out all the pieces?
Probably, but as I said before, it makes enough assumptions that I can't 
understand what to do.

Alan Staller wrote:
>Going back to the original post, I seemed to have missed the
>information about the operating system release.

>z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR
>MVS/ESA R.x, but that could be incorrect.)

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.

--
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: Ignorant z/OS question

2023-07-25 Thread Allan Staller

Classification: Confidential

ISTR the some of the older "console" support was removed in the indicated 
timeframe. E.g. 1052
I cannot say for certain that the 3215 code was removed at that time.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Monday, July 24, 2023 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Shmuel asked:
>Do you have the URL for the Tracy Dean paper?

Yes, I've read it.

>Does it spell out all the pieces?
Probably, but as I said before, it makes enough assumptions that I can't 
understand what to do.

Alan Staller wrote:
>Going back to the original post, I seemed to have missed the
>information about the operating system release.

>z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR
>MVS/ESA R.x, but that could be incorrect.)

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.

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

Re: Ignorant z/OS question

Yes, BTAM supported any contemporary 3270 except SDLC. However, MCS could not 
use BTAM for a 3270.


From: IBM Mainframe Discussion List  on behalf of 
Mike Shaw 
Sent: Tuesday, July 25, 2023 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

I used BTAM to read and write 3270 data streams to a locally attached 3270
back in the early 80's. It was simple to code and worked well.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

On Tue, Jul 25, 2023, 8:43 AM Mark Jacobs <
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> I can't confirm, but I think BTAM/SP never made it past MVS/XA and went
> out of support with MVS/ESA.
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
>
>
> --- Original Message ---
> On Tuesday, July 25th, 2023 at 8:02 AM, Seymour J Metz 
> wrote:
>
>
> > BTAM? I remember that MCS on OS/360 used BTAM to support a 2740, but I
> never saw one used in the flesh, and, IAC, it's long dead. IS BTAM/SP still
> a thing?
> >
> > IAC, another usful thing for the OP to read.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Mike Schwab [mike.a.sch...@gmail.com]
> > Sent: Tuesday, July 25, 2023 12:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Ignorant z/OS question
> >
> > https://www.mail-archive.com/ibmvm@listserv.uark.edu/msg34585.html
> >
> > On Mon, Jul 24, 2023, 06:32 Phil Smith III li...@akphs.com wrote:
> >
> > > Shmuel wrote:
> > >
> > > > That looks like the result of CP, HCD and MCS not specifying the same
> > > > device type. What happens if all three are 3215? What happens if all
> > > > three are 3270?
> > >
> > > I know what CP is :)
> > > HCD and MCS -- I assume one of these is the CONSOLE stuff in CONSOLxx;
> > > which is that, and where is the other one?
> > >
> > > --
> > > 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
>
> --
> 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: Ignorant z/OS question

2023-07-25 Thread Mike Shaw

I used BTAM to read and write 3270 data streams to a locally attached 3270
back in the early 80's. It was simple to code and worked well.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

On Tue, Jul 25, 2023, 8:43 AM Mark Jacobs <
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> I can't confirm, but I think BTAM/SP never made it past MVS/XA and went
> out of support with MVS/ESA.
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
>
>
> --- Original Message ---
> On Tuesday, July 25th, 2023 at 8:02 AM, Seymour J Metz 
> wrote:
>
>
> > BTAM? I remember that MCS on OS/360 used BTAM to support a 2740, but I
> never saw one used in the flesh, and, IAC, it's long dead. IS BTAM/SP still
> a thing?
> >
> > IAC, another usful thing for the OP to read.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Mike Schwab [mike.a.sch...@gmail.com]
> > Sent: Tuesday, July 25, 2023 12:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Ignorant z/OS question
> >
> > https://www.mail-archive.com/ibmvm@listserv.uark.edu/msg34585.html
> >
> > On Mon, Jul 24, 2023, 06:32 Phil Smith III li...@akphs.com wrote:
> >
> > > Shmuel wrote:
> > >
> > > > That looks like the result of CP, HCD and MCS not specifying the same
> > > > device type. What happens if all three are 3215? What happens if all
> > > > three are 3270?
> > >
> > > I know what CP is :)
> > > HCD and MCS -- I assume one of these is the CONSOLE stuff in CONSOLxx;
> > > which is that, and where is the other one?
> > >
> > > --
> > > 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
>
> --
> 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: Ignorant z/OS question

2023-07-25 Thread Tony Harminc

On Tue, 25 Jul 2023 at 14:44, Mark Jacobs
<0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
>
> I can't confirm, but I think BTAM/SP never made it past MVS/XA and went out 
> of support with MVS/ESA.
>
> Mark Jacobs

Even if the BTAM code still works, it's less than obvious to me what
endpoint devices could be supported, and how. Surely there is no IBM
supported way to plug in a 2740, even if you still have one. I believe
even  CCL is gone now, so how would any BSC or async device be
connected, other than through some sort of TCP/IP black-box or the
like, for which BTAM is surely not going to work.

Tony H.

> --- Original Message ---
> On Tuesday, July 25th, 2023 at 8:02 AM, Seymour J Metz  wrote:
>
>
> > BTAM? I remember that MCS on OS/360 used BTAM to support a 2740, but I 
> > never saw one used in the flesh, and, IAC, it's long dead. IS BTAM/SP still 
> > a thing?
> >
> > IAC, another usful thing for the OP to read.

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

Re: Ignorant z/OS question

2023-07-25 Thread Mark Jacobs

I can't confirm, but I think BTAM/SP never made it past MVS/XA and went out of 
support with MVS/ESA.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com


--- Original Message ---
On Tuesday, July 25th, 2023 at 8:02 AM, Seymour J Metz  wrote:


> BTAM? I remember that MCS on OS/360 used BTAM to support a 2740, but I never 
> saw one used in the flesh, and, IAC, it's long dead. IS BTAM/SP still a thing?
> 
> IAC, another usful thing for the OP to read.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Mike Schwab [mike.a.sch...@gmail.com]
> Sent: Tuesday, July 25, 2023 12:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ignorant z/OS question
> 
> https://www.mail-archive.com/ibmvm@listserv.uark.edu/msg34585.html
> 
> On Mon, Jul 24, 2023, 06:32 Phil Smith III li...@akphs.com wrote:
> 
> > Shmuel wrote:
> > 
> > > That looks like the result of CP, HCD and MCS not specifying the same
> > > device type. What happens if all three are 3215? What happens if all
> > > three are 3270?
> > 
> > I know what CP is :)
> > HCD and MCS -- I assume one of these is the CONSOLE stuff in CONSOLxx;
> > which is that, and where is the other one?
> > 
> > --
> > 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

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

Re: Ignorant z/OS question

BTAM? I remember that MCS on OS/360 used BTAM to support a 2740, but I never 
saw one used in the flesh, and, IAC, it's long dead. IS BTAM/SP still a thing?

IAC, another usful thing for the OP to read.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mike Schwab [mike.a.sch...@gmail.com]
Sent: Tuesday, July 25, 2023 12:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

https://www.mail-archive.com/ibmvm@listserv.uark.edu/msg34585.html

On Mon, Jul 24, 2023, 06:32 Phil Smith III  wrote:

> Shmuel wrote:
> >That looks like the result of CP, HCD and MCS not specifying the same
> >device type. What happens if all three are 3215? What happens if all
> >three are 3270?
>
> I know what CP is :)
> HCD and MCS -- I assume one of these is the CONSOLE stuff in CONSOLxx;
> which is that, and where is the other one?
>
> --
> 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: Ignorant z/OS question

2023-07-24 Thread Mike Schwab

https://www.mail-archive.com/ibmvm@listserv.uark.edu/msg34585.html

On Mon, Jul 24, 2023, 06:32 Phil Smith III  wrote:

> Shmuel wrote:
> >That looks like the result of CP, HCD and MCS not specifying the same
> >device type. What happens if all three are 3215? What happens if all
> >three are 3270?
>
> I know what CP is :)
> HCD and MCS -- I assume one of these is the CONSOLE stuff in CONSOLxx;
> which is that, and where is the other one?
>
> --
> 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: Ignorant z/OS question

2023-07-24 Thread Phil Smith III

Shmuel asked:
>Do you have the URL for the Tracy Dean paper? 

Yes, I've read it.

>Does it spell out all the pieces?
Probably, but as I said before, it makes enough assumptions that I can't 
understand what to do.

Alan Staller wrote:
>Going back to the original post, I seemed to have missed the
>information about the operating system release.

>z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR
>MVS/ESA R.x, but that could be incorrect.)

This is z/OS 2.4. What does "not supported" mean per se? It comes up fine, just 
the output is fugly. And I'm 99.44% sure that wasn't true on our previous 
system.

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

Re: Ignorant z/OS question

2023-07-24 Thread Seymour J Metz

Do you have the URL for the Tracy Dean paper? Does it spell out all the pieces?

From: IBM Mainframe Discussion List  on behalf of 
Allan Staller 
Sent: Monday, July 24, 2023 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Classification: Confidential

Going back to the original post, I seemed to have missed the information about 
the operating system release.
z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR MVS/ESA 
R.x, but that could be incorrect.)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Friday, July 21, 2023 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Alan Altmark wrote:
>And if you haven't done so, please read the white paper Tracy Dean
>referenced in her post. It is focused on this aspect of managing z/OS
>guests. We spent a lot of time figuring out how to make it all come
>together. (And you may remember me asking related questions on IBM-MAIN
>at the time!)

>Particularly, understand that z/OS isn't using a "device" of any kind
>It thinks it's talking to the Operating System Messages task (aka
>integrated console on the HMC), which CP simulates the same way we do
>the 3215. It also means you can't just SEND a command like you can with
>CMS.

Well, I read that paper. Lots of assumptions in there about z/OS knowledge that 
I don't have, like where it talks about "V CN(MVS0MAST),OFFLINE". I have no V 
(I assume that's VARY?) in any of my CONSOLxx members.

I do have a CNGRP00, which contains:
GROUP  NAME(MSTGRP)
   MEMBERS(S0W103D0,S0W10FFF)

Now that's 3D0 and FFF: 3D0 is a DASD. Seems wrong? The INIT in CONSOL00 is 
INIT  CMDDELIM(;) AMRF(N) MONITOR(DSNAME) CNGRP(00) so it's looking at that 
console group. If I change the 3D0 to 3E1 to match the actual console address, 
is that likely to help/hurt? What I'd rather not do is kill the beast and 
require help from our hosting service--not that they won't help, but we'll have 
to wait at least a bit for that.

(BTW, a nit: "Screenshot 1 - z/VM Login Screen with Dial Command" on page 6 has 
no DIAL command on the screen)

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.

--
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: Ignorant z/OS question

2023-07-24 Thread Allan Staller

Classification: Confidential

Going back to the original post, I seemed to have missed the information about 
the operating system release.
z/OS (MVS...) has not supported the 3215 for at least 20 years. (ISTR MVS/ESA 
R.x, but that could be incorrect.)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Friday, July 21, 2023 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Alan Altmark wrote:
>And if you haven't done so, please read the white paper Tracy Dean
>referenced in her post. It is focused on this aspect of managing z/OS
>guests. We spent a lot of time figuring out how to make it all come
>together. (And you may remember me asking related questions on IBM-MAIN
>at the time!)

>Particularly, understand that z/OS isn't using a "device" of any kind
>It thinks it's talking to the Operating System Messages task (aka
>integrated console on the HMC), which CP simulates the same way we do
>the 3215. It also means you can't just SEND a command like you can with
>CMS.

Well, I read that paper. Lots of assumptions in there about z/OS knowledge that 
I don't have, like where it talks about "V CN(MVS0MAST),OFFLINE". I have no V 
(I assume that's VARY?) in any of my CONSOLxx members.

I do have a CNGRP00, which contains:
GROUP  NAME(MSTGRP)
   MEMBERS(S0W103D0,S0W10FFF)

Now that's 3D0 and FFF: 3D0 is a DASD. Seems wrong? The INIT in CONSOL00 is 
INIT  CMDDELIM(;) AMRF(N) MONITOR(DSNAME) CNGRP(00) so it's looking at that 
console group. If I change the 3D0 to 3E1 to match the actual console address, 
is that likely to help/hurt? What I'd rather not do is kill the beast and 
require help from our hosting service--not that they won't help, but we'll have 
to wait at least a bit for that.

(BTW, a nit: "Screenshot 1 - z/VM Login Screen with Dial Command" on page 6 has 
no DIAL command on the screen)

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.

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

Re: Ignorant z/OS question

2023-07-24 Thread Seymour J Metz

HCD is the interactive tool that you use to maintain the IODF, which among 
other things defines the MVS I/O configuration.

MCS is Multiple Console Support, the component that is concerned with 
controlling MVS consoles.

From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Monday, July 24, 2023 7:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Shmuel wrote:
>That looks like the result of CP, HCD and MCS not specifying the same
>device type. What happens if all three are 3215? What happens if all
>three are 3270?

I know what CP is :)
HCD and MCS -- I assume one of these is the CONSOLE stuff in CONSOLxx; which is 
that, and where is the other one?

--
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: Ignorant z/OS question

2023-07-24 Thread Phil Smith III

Shmuel wrote:
>That looks like the result of CP, HCD and MCS not specifying the same
>device type. What happens if all three are 3215? What happens if all
>three are 3270?

I know what CP is :)
HCD and MCS -- I assume one of these is the CONSOLE stuff in CONSOLxx; which is 
that, and where is the other one?

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

Re: Ignorant z/OS question

That looks like the result of CP, HCD and MCS not specifying the same device 
type. What happens if all three are 3215? What happens if all three are 3270?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Sunday, July 23, 2023 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Well, this is interesting. Tried again just now with TERMINAL CONMODE 3215. It 
comes up, and I see SECUSER output. The only weirdness is that much of the 
output is oddly formatted (copied from SECUSER's screen, in linemode):

  B- *10.09.46  *CBR3002E Library LATL00 no longer u
sable.   C0 *10.09.46  *CBR3002E Library LVTS00 no longe
r usable.   E  *10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,JES2_C
KPT_CONFIG_SVSCJES2):  F& *IAZH123E One or more checkpoints or new check
points are not defined.   G- *10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,
JES2_CKPT_CONFIG_SVSCJES2):  H0 *IAZH128E Operator verification is enabl
ed. ¢ - 10.11.25 STC03228  ADR111I-* AUTOMAT
IC SYSTEM* .&- 10.11.25 STC03228  ADR111I-* STAR
T WILL BEGIN IN * <-- 10.11.25 STC03228  ADR111I-* A
PPROXIMATELY 60 SECONDS.   * (0- 10.11.25 STC03228  ADR111I-
* * | - 10.11.25 STC03228  ADR11
1I-* ISSUE COMMAND:  * &&- 10.11.25 STC03228  AD
R111I-* * J-- 10.11.25 STC03228
 ADR111I-* C ALLAUTO   * K0- 10.11.25 STC032
28  ADR111I-* * M - 10.11.25 STC
03228  ADR111I-* TO STOP AUTO START. * N&  00- 10.11.25
STC03228  ADR111I-* * O-- 10.11.
25 STC03228  ADR111I-*** *0  IEE163I

If I take some of that output and manually reformat it, I get:

*CBR3002E Library LATL00 no longer usable.   C0 *10.09.46
*CBR3002E Library LVTS00 no longer usable.   E  *10.10.28 
STC03234
*HZS0003E CHECK(IBMJES2,JES2_CKPT_CONFIG_SVSCJES2):  F&
*IAZH123E One or more checkpoints or new checkpoints are not defined.   G-
*10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,JES2_CKPT_CONFIG_SVSCJES2):  H0
*IAZH128E Operator verification is enabled. ¢   
  -

Note that these lines aren't 80, or 132, or anything like that.

TERMINAL LINESIZE is 00. Tried 132; all that seems to do is cut off lines.

What I see via SECUSER is also different from what I see in the SPOOLed 
console: there are a lot more blank lines displayed via SECUSER, and more 
linewraps. Guessing that's because there's some 3270 datastream stuff that's 
semi-getting handled, but can't prove that. It's sure not in the SPOOLed 
console, not even as undisplayables.

So...progress, I guess? I can now IPL via XAUTOLOG and watch it, if a bit 
incoherently.

--
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: Ignorant z/OS question

ROTF,LMAO! This from a man who persistently attributes to others things that 
they didn't write and who doesn't seem to know the difference between 3270 
printers and line/page printers. You wouldn't recognize a relevant detail if it 
hit you in the face.

I'm not going to reiterate for your benefit things that I already spelled out. 
RYFM.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Sunday, July 23, 2023 9:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > The Devil is in the details. There are relevant factors on both the CP and 
 > MVS side.

Phil, you need to be weary of Seymour's responses. His lack of problem solving 
skills and his hyper-focus on irrelevant details is leading you deeper into the 
swamp. Ignore his response because It will confuse you for no reason.

WTF Seymour! What are the details and what relevant factors do you think you 
are talking about? I now have to talk Phil out of this mess. Phil just told us 
V CN(*),ACT sort of works but its too late to see the IPL messages and messages 
are strangely formatted. Besides being partially wrong, your response has 
nothing to do with solving the ACTIVATE timing.

On Sunday, July 23, 2023 at 02:22:13 AM PDT, Seymour J Metz 
 wrote:

 The Devil is in the details. There are relevant factors on both the CP and MVS 
side.

On the MVS side you have console definitions; you are probably only concerned 
with MCS and HMCS. An HMCS console uses a special interface to the HMC. Since 
your VARY command specified CN(*), it activated the HMCS console.

On the CP side, it looks like VINPUT passes the text via the virtual HMC to the 
HMCS console; check with the VM folks whether I've gotten that right.

The type of virtual device at a virtual address must match the console 
definition for that address. Note that while it is best practice for the 
console name to include the address, that is in principle an unrelated third 
value. So the CONMODE must match the console definition for the console virtual 
address.

If the SECUSER sees traffic to the HMCS console then just set the routing codes 
on that consoles appropriately.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Saturday, July 22, 2023 6:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Jon Perryman wrote:
>I need you to stop overthinking z/OS console. It's become very simple
>since IBM rewrote it several years ago. When running on a 3215 console
>printer, lines are printed and when running on a 3270, it's a
>fullscreen interface (like every other fullscreen application such as
>xedit). Forget that it is a z/OS console.

OK. So it *will* IPL with TERMINAL CONMODE 3215? I'll go back and tinker with 
that again. That might be the key.

>You've only asked us how to use z/OS console with VM SECUID but never
>mentioned the problem you are trying to solve. I don't think it solves
>your problem. Console in 3270 mode is somewhat like xedit. Xedit deals
>with files whereas console deals with system messages which can be
>massive on an active z/OS. Like xedit, consoles in 3270 mode can
>scroll, exclude, split screen, issue commands to products on z/OS and
>much more. Very useful for someone controlling z/OS.

Apologies--it was clear to ME (of course!): I want to be able to watch the IPL 
remotely. It's a dev system, quite quiet: normally nobody is looking at the 
console at all. So when we do IPL, we're used to doing it from a VM console:
XAUTOLOG ...

< Wait for "IEE389I MVS COMMAND PROCESSING AVAILABLE", then issue>
CP SEND CP ETPGZ1D VINPUT VMSG V CN(*),ACT

>You want to use z/OS console as a 3215 which is a printer console and
>forward each line to a user using CP SECUID. With thousands of
>messages on a z/OS system, the user will be constantly clearing their
>screen. This is why I kept asking about PROP. If you don't filter the
>messages, you will just pissed off. Worse yet, because these messages
>will be formatted for a 3215, they won't be easily readable because of
>line wrap and other formatting problems.

There aren't thousands of messages, not on this system. I just left it 
overnight and there were fewer than 10 screens of them. Of course on a "real" 
system your comment would apply.

>>I thought (and still believe) the VARY made FFF "active" in some
>>sense, since without it, no SECUSER info; with it (after the VARY),
>>SECUSER info.

>V CN(*),ACTIVE could not possibly be related to FFF. It was sent to
>the emulated hardware console and activated (enabled) it for z/OS
>messages

Re: Ignorant z/OS question

> 2. Seymour was wrong that the SECUSER could not handle a 3270 screen. 

That's not what I wrote. What I wrote was that definitions must be in synch for 
things to work properly.

> 3. Most important, it shows z/OS dropped 3215 printer console support and 
> forces 3270 full screen.

Not unless he's run a test in which VM, MVS and MCS all define it as 3215.

> More likely to work is to find a 3211, 3203-5 or 1403 definition in the z/OS 
> HCD and specify UNIT(PRT) DEVICE(###) where ### is the printers address.

Already suggested.

> I doubt it behaves like a 3270 datastream

Never has, never will.

The only complication is the need to manually enter, e.g., CP SPOOL.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Sunday, July 23, 2023 10:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 Hi Phil, I have some good news and bad news.

> Well, this is interesting. Tried again just now with TERMINAL CONMODE 3215.
> The only weirdness is that much of the output is oddly formatted.

>  B-*10.09.46  *CBR3002E Library LATL00 no longer u

> sable.  C0*10.09.46  *CBR3002E Library LVTS00 no longe

> r usable.
.This is a 3270 datastream. If you displayed it in hex, you would see a series 
of SBA, address and data. This tells us a few things:

1. CONMODE 3270 uses DIAG 58 to handle data as a 3270 datastream versus CONMODE 
3215 treats the 3270 stream as simple data.

2. Seymour was wrong that the SECUSER could not handle a 3270 screen. Like a 
real 3270, CONMODE 3215 receives changes to the screen instead of a complete 
screen refresh each time.

3. Most important, it shows z/OS dropped 3215 printer console support and 
forces 3270 full screen.

UNIT(PRT) on the console definition would be simple to test but I don't think 
it will work. I suspect it will still use 3270 datastream. Even if it is a 3270 
datastream, you could write prop execs to convert from datastream to lines. 
Fullscreen scrolls on the screen so PRT eliminates the dumplicated lines 
problem.

More likely to work is to find a 3211, 3203-5 or 1403 definition in the z/OS 
HCD and specify UNIT(PRT) DEVICE(###) where ### is the printers address. I 
doubt it behaves like a 3270 datastream so it's possible it will work but no 
guarantees.

If you are forced to use V CN(*),ACT then you will need to lower your 
expectations. I will repeat that this has nothing to do with the VM z/OS user 
"console" statement. Comment it and issue the command. You will find it still 
works. Think about a real z16 hardware console in the computer room. Rarely 
will someone use this hardware console but on rare occasions you may need 
access to the hardware and z/OS consoles at the same time. You never want z/OS 
consoled active in the hardware unless someone is actively using it. IBM does 
not allow you to automatically activate this z/OS console in the hardware 
console. Instead, you must ACTIVATE it when you need it and then DEACTIVATE it 
when you are finished.

The word CONSOLE in z/VM is misleading and has a different interpretation for 
z/OS, z/VSE, hardware and more. For z/VM, "CONSOLE" is a statement in each user 
definition in the user directory. It has nothing to do with consoles. It 
defines a virtual device that sends to and receives from the logon terminal. 
The word "console" pushes z/OS and z/VSE sysprogs to use a z/OS or z/VSE 
console. If the z/OS sysprog chose a device address defined to VTAM instead of 
a console, the VTAM logon screen would appear instead of a z/OS console 
terminal. There is nothing that makes a terminal uniquely a console other than 
a z/OS defined a device address as a console.

Console has a real meaning to z/OS, z/VSE and hardware. E.g. every IBM z 
computer has a hardware console to define LPARs and IPL systems.

On Sunday, July 23, 2023 at 08:50:08 AM PDT, Phil Smith III 
 wrote:

 Well, this is interesting. Tried again just now with TERMINAL CONMODE 3215. It 
comes up, and I see SECUSER output. The only weirdness is that much of the 
output is oddly formatted (copied from SECUSER's screen, in linemode):

  B-*10.09.46  *CBR3002E Library LATL00 no longer u
sable.  C0*10.09.46  *CBR3002E Library LVTS00 no longe
r usable.  E  *10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,JES2_C
KPT_CONFIG_SVSCJES2):  F&    *IAZH123E One or more checkpoints or new check
points are not defined.  G-*10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,
JES2_CKPT_CONFIG_SVSCJES2):  H0*IAZH128E Operator verification is enabl
ed.¢- 10.11.25 STC03228  ADR111I-* AUTOMAT
IC SYSTEM*.&    - 10.11.25 STC03228

Re: Ignorant z/OS question

Some devices are veryn flexible, but not so flexible as that. If you define an 
MCS console as 3277, then MCS will write 3270 data streams with SF and all the 
rest; it will mot write any NL orders. If you define that address to VM as a 
3215 then it will not be able to correctly deblock the messages. Thus it ever 
were.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jon 
Perryman [jperr...@pacbell.net]
Sent: Sunday, July 23, 2023 10:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

 > On Sunday, July 23, 2023 at 04:28:48 PM PDT, Seymour J Metz  
 > wrote:
> Your not keeping your MVS and VM in synch; 3E1 should be a 3215 on both or a 
> 3270 on both.

Some devices must be in synch (e.g. disk drives). On the other hand, some 
devices are very flexible. z/VM CONSOLE has nothing to do with consoles because 
you can't distinguish between a terminal versus console. z/VM "CONSOLE" in each 
user defined associates a device address with the users screen. 3270 says to 
treat data to and from this device as 3270 datastream versus 3215 as a printer 
/ keyboard.

z/OS has syslog and various types of consoles available (including TSO 
CONSOLE). I think that printer / keyboard support was dropped when IBM rewrote 
consoles.

On Sunday, July 23, 2023 at 04:28:48 PM PDT, Seymour J Metz 
 wrote:

 Your not keeping your MVS and VM in synch; 3E1 should be a 3215 on both or a 
3270 on both.

From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Sunday, July 23, 2023 5:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Norman wrote:
>I'd have to try it.  3215s have been gone for decades.
>I used an attached or dialed 3270 for MVS.  For the guest,
>you probably have a Cons defined as 009 or 01F, as 3215.

Right, at 3E1, which is also in CONSOL00:
CONSOLE  DEVNUM(3E1) ROUTCODE(ALL)
  UNIT(3277-2)
  AUTH(MASTER)
  DEL(RD)
  RNUM(19)
  RTME(1)
  MFORM(J,T)
  SEG(19)
  AREA(NONE)
  NAME(S0W103E1)

And on VM:
CONS 03E1 DISCONNECTEDTERM START
03E1 CL T NOCONT NOHOLD COPY 001READY FORM STANDARD
03E1 TO MAINTRDR DIST ETPGZ1D  FLASHC 000 DEST OFF
03E1 FLASH  CHAR  MDFY  0 FCB  LPP OFF
03E1 3215  NOEOF OPEN 0029 NOKEEP NOMSG NONAME
03E1 SUBCHANNEL = 

Not sure if this is useful info, but it might be...

--
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

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

Re: Ignorant z/OS question

2023-07-23 Thread Steve Horein

The only time I have seen NIP messages (those messages prior to VARY
CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP device
defined in the IODF was not available, I believe due to some cabling
issues. In that situation, all NIP messages were routed to the SE/HMC
System Console. I had requested the NIP device be removed from IODF years
before, for that exact purpose, to assist with automation that uses
SYSCONS, and/or for diagnostics, but due to Fear/Uncertainty/Doubt, the
request was flatly denied.

https://www.ibm.com/docs/en/zos/2.4.0?topic=system-nip-console
"If no NIP console is defined and ready, MVS™ will use the system console
as the NIP-time console."

I have zero experience with zVM, so I do not know if that NIP message
behavior is the same when MVS is running as a guest. I just figured I would
pass along my anecdotal observations.

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

Re: Ignorant z/OS question

2023-07-23 Thread Jon Perryman

 > On Sunday, July 23, 2023 at 04:28:48 PM PDT, Seymour J Metz  
 > wrote:
> Your not keeping your MVS and VM in synch; 3E1 should be a 3215 on both or a 
> 3270 on both.

Some devices must be in synch (e.g. disk drives). On the other hand, some 
devices are very flexible. z/VM CONSOLE has nothing to do with consoles because 
you can't distinguish between a terminal versus console. z/VM "CONSOLE" in each 
user defined associates a device address with the users screen. 3270 says to 
treat data to and from this device as 3270 datastream versus 3215 as a printer 
/ keyboard.

z/OS has syslog and various types of consoles available (including TSO 
CONSOLE). I think that printer / keyboard support was dropped when IBM rewrote 
consoles.

On Sunday, July 23, 2023 at 04:28:48 PM PDT, Seymour J Metz 
 wrote:  

 Your not keeping your MVS and VM in synch; 3E1 should be a 3215 on both or a 
3270 on both.

From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Sunday, July 23, 2023 5:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Norman wrote:
>I'd have to try it.  3215s have been gone for decades.
>I used an attached or dialed 3270 for MVS.  For the guest,
>you probably have a Cons defined as 009 or 01F, as 3215.

Right, at 3E1, which is also in CONSOL00:
CONSOLE  DEVNUM(3E1) ROUTCODE(ALL)
      UNIT(3277-2)
      AUTH(MASTER)
      DEL(RD)
      RNUM(19)
      RTME(1)
      MFORM(J,T)
      SEG(19)
      AREA(NONE)
      NAME(S0W103E1)

And on VM:
CONS 03E1 DISCONNECTED    TERM START
    03E1 CL T NOCONT NOHOLD COPY 001    READY FORM STANDARD
    03E1 TO MAINT    RDR DIST ETPGZ1D  FLASHC 000 DEST OFF
    03E1 FLASH      CHAR      MDFY      0 FCB      LPP OFF
    03E1 3215  NOEOF OPEN 0029 NOKEEP NOMSG NONAME
    03E1 SUBCHANNEL = 

Not sure if this is useful info, but it might be...

--
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: Ignorant z/OS question

2023-07-23 Thread Jon Perryman

 Hi Phil, I have some good news and bad news. 

> Well, this is interesting. Tried again just now with TERMINAL CONMODE 3215.
> The only weirdness is that much of the output is oddly formatted.

>                  B-    *10.09.46          *CBR3002E Library LATL00 no longer u

> sable.              C0    *10.09.46          *CBR3002E Library LVTS00 no longe

> r usable.   
.This is a 3270 datastream. If you displayed it in hex, you would see a series 
of SBA, address and data. This tells us a few things:

1. CONMODE 3270 uses DIAG 58 to handle data as a 3270 datastream versus CONMODE 
3215 treats the 3270 stream as simple data.

2. Seymour was wrong that the SECUSER could not handle a 3270 screen. Like a 
real 3270, CONMODE 3215 receives changes to the screen instead of a complete 
screen refresh each time.

3. Most important, it shows z/OS dropped 3215 printer console support and 
forces 3270 full screen. 

UNIT(PRT) on the console definition would be simple to test but I don't think 
it will work. I suspect it will still use 3270 datastream. Even if it is a 3270 
datastream, you could write prop execs to convert from datastream to lines. 
Fullscreen scrolls on the screen so PRT eliminates the dumplicated lines 
problem.

More likely to work is to find a 3211, 3203-5 or 1403 definition in the z/OS 
HCD and specify UNIT(PRT) DEVICE(###) where ### is the printers address. I 
doubt it behaves like a 3270 datastream so it's possible it will work but no 
guarantees.

If you are forced to use V CN(*),ACT then you will need to lower your 
expectations. I will repeat that this has nothing to do with the VM z/OS user 
"console" statement. Comment it and issue the command. You will find it still 
works. Think about a real z16 hardware console in the computer room. Rarely 
will someone use this hardware console but on rare occasions you may need 
access to the hardware and z/OS consoles at the same time. You never want z/OS 
consoled active in the hardware unless someone is actively using it. IBM does 
not allow you to automatically activate this z/OS console in the hardware 
console. Instead, you must ACTIVATE it when you need it and then DEACTIVATE it 
when you are finished. 

The word CONSOLE in z/VM is misleading and has a different interpretation for 
z/OS, z/VSE, hardware and more. For z/VM, "CONSOLE" is a statement in each user 
definition in the user directory. It has nothing to do with consoles. It 
defines a virtual device that sends to and receives from the logon terminal. 
The word "console" pushes z/OS and z/VSE sysprogs to use a z/OS or z/VSE 
console. If the z/OS sysprog chose a device address defined to VTAM instead of 
a console, the VTAM logon screen would appear instead of a z/OS console 
terminal. There is nothing that makes a terminal uniquely a console other than 
a z/OS defined a device address as a console.

Console has a real meaning to z/OS, z/VSE and hardware. E.g. every IBM z 
computer has a hardware console to define LPARs and IPL systems.

On Sunday, July 23, 2023 at 08:50:08 AM PDT, Phil Smith III 
 wrote:  

 Well, this is interesting. Tried again just now with TERMINAL CONMODE 3215. It 
comes up, and I see SECUSER output. The only weirdness is that much of the 
output is oddly formatted (copied from SECUSER's screen, in linemode):

                  B-    *10.09.46          *CBR3002E Library LATL00 no longer u
sable.              C0    *10.09.46          *CBR3002E Library LVTS00 no longe
r usable.              E      *10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,JES2_C
KPT_CONFIG_SVSCJES2):      F&    *IAZH123E One or more checkpoints or new check
points are not defined.      G-    *10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,
JES2_CKPT_CONFIG_SVSCJES2):      H0    *IAZH128E Operator verification is enabl
ed.                                ¢    - 10.11.25 STC03228  ADR111I-* AUTOMAT
IC SYSTEM            *                .&    - 10.11.25 STC03228  ADR111I-* STAR
T WILL BEGIN IN        *                <-    - 10.11.25 STC03228  ADR111I-* A
PPROXIMATELY 60 SECONDS.  *                (0    - 10.11.25 STC03228  ADR111I-
*                            *                |    - 10.11.25 STC03228  ADR11
1I-* ISSUE COMMAND:              *                &&    - 10.11.25 STC03228  AD
R111I-*                            *                J-    - 10.11.25 STC03228 
 ADR111I-* C ALLAUTO                  *                K0    - 10.11.25 STC032
28  ADR111I-*                            *                M    - 10.11.25 STC
03228  ADR111I-* TO STOP AUTO START.        *                N&  00- 10.11.25 
STC03228  ADR111I-*                            *                O-    - 10.11.
25 STC03228  ADR111I-***                *0  IEE163I

If I take some of that output and manually reformat it, I get:

*CBR3002E Library LATL00 no longer usable.              C0    *10.09.46
*CBR3002E Library LVTS00 no longer usable.              E      *10.10.28 
STC03234
*HZS0003E

Re: Ignorant z/OS question

2023-07-23 Thread Jon Perryman

 > The Devil is in the details. There are relevant factors on both the CP and 
 > MVS side.

Phil, you need to be weary of Seymour's responses. His lack of problem solving 
skills and his hyper-focus on irrelevant details is leading you deeper into the 
swamp. Ignore his response because It will confuse you for no reason. 

WTF Seymour! What are the details and what relevant factors do you think you 
are talking about? I now have to talk Phil out of this mess. Phil just told us 
V CN(*),ACT sort of works but its too late to see the IPL messages and messages 
are strangely formatted. Besides being partially wrong, your response has 
nothing to do with solving the ACTIVATE timing.

On Sunday, July 23, 2023 at 02:22:13 AM PDT, Seymour J Metz 
 wrote:  

 The Devil is in the details. There are relevant factors on both the CP and MVS 
side.

On the MVS side you have console definitions; you are probably only concerned 
with MCS and HMCS. An HMCS console uses a special interface to the HMC. Since 
your VARY command specified CN(*), it activated the HMCS console.

On the CP side, it looks like VINPUT passes the text via the virtual HMC to the 
HMCS console; check with the VM folks whether I've gotten that right.

The type of virtual device at a virtual address must match the console 
definition for that address. Note that while it is best practice for the 
console name to include the address, that is in principle an unrelated third 
value. So the CONMODE must match the console definition for the console virtual 
address.

If the SECUSER sees traffic to the HMCS console then just set the routing codes 
on that consoles appropriately.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Saturday, July 22, 2023 6:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Jon Perryman wrote:
>I need you to stop overthinking z/OS console. It's become very simple
>since IBM rewrote it several years ago. When running on a 3215 console
>printer, lines are printed and when running on a 3270, it's a
>fullscreen interface (like every other fullscreen application such as
>xedit). Forget that it is a z/OS console.

OK. So it *will* IPL with TERMINAL CONMODE 3215? I'll go back and tinker with 
that again. That might be the key.

>You've only asked us how to use z/OS console with VM SECUID but never
>mentioned the problem you are trying to solve. I don't think it solves
>your problem. Console in 3270 mode is somewhat like xedit. Xedit deals
>with files whereas console deals with system messages which can be
>massive on an active z/OS. Like xedit, consoles in 3270 mode can
>scroll, exclude, split screen, issue commands to products on z/OS and
>much more. Very useful for someone controlling z/OS.

Apologies--it was clear to ME (of course!): I want to be able to watch the IPL 
remotely. It's a dev system, quite quiet: normally nobody is looking at the 
console at all. So when we do IPL, we're used to doing it from a VM console:
XAUTOLOG ...

< Wait for "IEE389I MVS COMMAND PROCESSING AVAILABLE", then issue>
CP SEND CP ETPGZ1D VINPUT VMSG V CN(*),ACT

>You want to use z/OS console as a 3215 which is a printer console and
>forward each line to a user using CP SECUID. With thousands of
>messages on a z/OS system, the user will be constantly clearing their
>screen. This is why I kept asking about PROP. If you don't filter the
>messages, you will just pissed off. Worse yet, because these messages
>will be formatted for a 3215, they won't be easily readable because of
>line wrap and other formatting problems.

There aren't thousands of messages, not on this system. I just left it 
overnight and there were fewer than 10 screens of them. Of course on a "real" 
system your comment would apply.

>>I thought (and still believe) the VARY made FFF "active" in some
>>sense, since without it, no SECUSER info; with it (after the VARY),
>>SECUSER info.

>V CN(*),ACTIVE could not possibly be related to FFF. It was sent to
>the emulated hardware console and activated (enabled) it for z/OS
>messages. If this solves your problem, I can tell you how to solve
>this in z/OS but it will miss the beginning messages.

Well...if I bring the guest up, the SECUSER (not "SECUID", that's not a VM 
thing) sees no messages until I issue the VARY. Repeatable. So it's doing 
*something*. Right, it misses the messages until the VARY, which is the current 
problem I'm trying to solve.

>At this point, you need to decide if this solves your problem. If not,
>maybe we can give you alternatives if you provide some details on the
>problem you want to solve. Let me know if you want me to answer your
>other questions as an fyi.

See above

Re: Ignorant z/OS question

Your not keeping your MVS and VM in synch; 3E1 should be a 3215 on both or a 
3270 on both.


From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Sunday, July 23, 2023 5:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Norman wrote:
>I'd have to try it.  3215s have been gone for decades.
>I used an attached or dialed 3270 for MVS.  For the guest,
>you probably have a Cons defined as 009 or 01F, as 3215.

Right, at 3E1, which is also in CONSOL00:
CONSOLE   DEVNUM(3E1) ROUTCODE(ALL)
  UNIT(3277-2)
  AUTH(MASTER)
  DEL(RD)
  RNUM(19)
  RTME(1)
  MFORM(J,T)
  SEG(19)
  AREA(NONE)
  NAME(S0W103E1)

And on VM:
CONS 03E1 DISCONNECTEDTERM START
 03E1 CL T NOCONT NOHOLD COPY 001READY FORM STANDARD
 03E1 TO MAINTRDR DIST ETPGZ1D   FLASHC 000 DEST OFF
 03E1 FLASH   CHAR   MDFY   0 FCB   LPP OFF
 03E1 3215   NOEOF OPEN 0029 NOKEEP NOMSG NONAME
 03E1 SUBCHANNEL = 

Not sure if this is useful info, but it might be...

--
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: Ignorant z/OS question

2023-07-23 Thread Phil Smith III

Norman wrote:
>I'd have to try it.  3215s have been gone for decades.
>I used an attached or dialed 3270 for MVS.  For the guest,
>you probably have a Cons defined as 009 or 01F, as 3215.

Right, at 3E1, which is also in CONSOL00:
CONSOLE   DEVNUM(3E1) ROUTCODE(ALL)
  UNIT(3277-2) 
  AUTH(MASTER) 
  DEL(RD)  
  RNUM(19) 
  RTME(1)  
  MFORM(J,T)   
  SEG(19)  
  AREA(NONE)   
  NAME(S0W103E1)   

And on VM:
CONS 03E1 DISCONNECTEDTERM START   
 03E1 CL T NOCONT NOHOLD COPY 001READY FORM STANDARD   
 03E1 TO MAINTRDR DIST ETPGZ1D   FLASHC 000 DEST OFF   
 03E1 FLASH   CHAR   MDFY   0 FCB   LPP OFF
 03E1 3215   NOEOF OPEN 0029 NOKEEP NOMSG NONAME   
 03E1 SUBCHANNEL = 

Not sure if this is useful info, but it might be...

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

Re: Ignorant z/OS question

2023-07-23 Thread Phil Smith III

Norman wrote:
>You told VM it's a 3215, but did you tell z/OS?
>You may be seeing strange output from incompatible
>output streams.  I always have a 3215 defined in HCD.

So if I change the CONSOLE statement from 3277-2 (yeah, yeah, 3270-X, haven't 
bothered yet) to 3215 that might fix that?

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

Re: Ignorant z/OS question

2023-07-23 Thread Phil Smith III

Well, this is interesting. Tried again just now with TERMINAL CONMODE 3215. It 
comes up, and I see SECUSER output. The only weirdness is that much of the 
output is oddly formatted (copied from SECUSER's screen, in linemode):

  B- *10.09.46  *CBR3002E Library LATL00 no longer u
sable.   C0 *10.09.46  *CBR3002E Library LVTS00 no longe
r usable.   E  *10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,JES2_C
KPT_CONFIG_SVSCJES2):  F& *IAZH123E One or more checkpoints or new check
points are not defined.   G- *10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,
JES2_CKPT_CONFIG_SVSCJES2):  H0 *IAZH128E Operator verification is enabl
ed. ¢ - 10.11.25 STC03228  ADR111I-* AUTOMAT
IC SYSTEM* .&- 10.11.25 STC03228  ADR111I-* STAR
T WILL BEGIN IN * <-- 10.11.25 STC03228  ADR111I-* A
PPROXIMATELY 60 SECONDS.   * (0- 10.11.25 STC03228  ADR111I-
* * | - 10.11.25 STC03228  ADR11
1I-* ISSUE COMMAND:  * &&- 10.11.25 STC03228  AD
R111I-* * J-- 10.11.25 STC03228 
 ADR111I-* C ALLAUTO   * K0- 10.11.25 STC032
28  ADR111I-* * M - 10.11.25 STC
03228  ADR111I-* TO STOP AUTO START. * N&  00- 10.11.25 
STC03228  ADR111I-* * O-- 10.11.
25 STC03228  ADR111I-*** *0  IEE163I

If I take some of that output and manually reformat it, I get:

*CBR3002E Library LATL00 no longer usable.   C0 *10.09.46
*CBR3002E Library LVTS00 no longer usable.   E  *10.10.28 
STC03234
*HZS0003E CHECK(IBMJES2,JES2_CKPT_CONFIG_SVSCJES2):  F&
*IAZH123E One or more checkpoints or new checkpoints are not defined.   G-
*10.10.28 STC03234 *HZS0003E CHECK(IBMJES2,JES2_CKPT_CONFIG_SVSCJES2):  H0
*IAZH128E Operator verification is enabled. ¢   
  -

Note that these lines aren't 80, or 132, or anything like that.

TERMINAL LINESIZE is 00. Tried 132; all that seems to do is cut off lines.

What I see via SECUSER is also different from what I see in the SPOOLed 
console: there are a lot more blank lines displayed via SECUSER, and more 
linewraps. Guessing that's because there's some 3270 datastream stuff that's 
semi-getting handled, but can't prove that. It's sure not in the SPOOLed 
console, not even as undisplayables.

So...progress, I guess? I can now IPL via XAUTOLOG and watch it, if a bit 
incoherently.

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

Re: Ignorant z/OS question

The Devil is in the details. There are relevant factors on both the CP and MVS 
side.

On the MVS side you have console definitions; you are probably only concerned 
with MCS and HMCS. An HMCS console uses a special interface to the HMC. Since 
your VARY command specified CN(*), it activated the HMCS console.

On the CP side, it looks like VINPUT passes the text via the virtual HMC to the 
HMCS console; check with the VM folks whether I've gotten that right.

The type of virtual device at a virtual address must match the console 
definition for that address. Note that while it is best practice for the 
console name to include the address, that is in principle an unrelated third 
value. So the CONMODE must match the console definition for the console virtual 
address.

If the SECUSER sees traffic to the HMCS console then just set the routing codes 
on that consoles appropriately.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Saturday, July 22, 2023 6:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Jon Perryman wrote:
>I need you to stop overthinking z/OS console. It's become very simple
>since IBM rewrote it several years ago. When running on a 3215 console
>printer, lines are printed and when running on a 3270, it's a
>fullscreen interface (like every other fullscreen application such as
>xedit). Forget that it is a z/OS console.

OK. So it *will* IPL with TERMINAL CONMODE 3215? I'll go back and tinker with 
that again. That might be the key.

>You've only asked us how to use z/OS console with VM SECUID but never
>mentioned the problem you are trying to solve. I don't think it solves
>your problem. Console in 3270 mode is somewhat like xedit. Xedit deals
>with files whereas console deals with system messages which can be
>massive on an active z/OS. Like xedit, consoles in 3270 mode can
>scroll, exclude, split screen, issue commands to products on z/OS and
>much more. Very useful for someone controlling z/OS.

Apologies--it was clear to ME (of course!): I want to be able to watch the IPL 
remotely. It's a dev system, quite quiet: normally nobody is looking at the 
console at all. So when we do IPL, we're used to doing it from a VM console:
XAUTOLOG ...

< Wait for "IEE389I MVS COMMAND PROCESSING AVAILABLE", then issue>
CP SEND CP ETPGZ1D VINPUT VMSG V CN(*),ACT

>You want to use z/OS console as a 3215 which is a printer console and
>forward each line to a user using CP SECUID. With thousands of
>messages on a z/OS system, the user will be constantly clearing their
>screen. This is why I kept asking about PROP. If you don't filter the
>messages, you will just pissed off. Worse yet, because these messages
>will be formatted for a 3215, they won't be easily readable because of
>line wrap and other formatting problems.

There aren't thousands of messages, not on this system. I just left it 
overnight and there were fewer than 10 screens of them. Of course on a "real" 
system your comment would apply.

>>I thought (and still believe) the VARY made FFF "active" in some
>>sense, since without it, no SECUSER info; with it (after the VARY),
>>SECUSER info.

>V CN(*),ACTIVE could not possibly be related to FFF. It was sent to
>the emulated hardware console and activated (enabled) it for z/OS
>messages. If this solves your problem, I can tell you how to solve
>this in z/OS but it will miss the beginning messages.

Well...if I bring the guest up, the SECUSER (not "SECUID", that's not a VM 
thing) sees no messages until I issue the VARY. Repeatable. So it's doing 
*something*. Right, it misses the messages until the VARY, which is the current 
problem I'm trying to solve.

>At this point, you need to decide if this solves your problem. If not,
>maybe we can give you alternatives if you provide some details on the
>problem you want to solve. Let me know if you want me to answer your
>other questions as an fyi.

See above?

Thanks for bearing with me here,

...phsiii

--
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: Ignorant z/OS question

2023-07-22 Thread Phil Smith III

Jon Perryman wrote:
>I need you to stop overthinking z/OS console. It's become very simple
>since IBM rewrote it several years ago. When running on a 3215 console
>printer, lines are printed and when running on a 3270, it's a
>fullscreen interface (like every other fullscreen application such as
>xedit). Forget that it is a z/OS console.

OK. So it *will* IPL with TERMINAL CONMODE 3215? I'll go back and tinker with 
that again. That might be the key.

>You've only asked us how to use z/OS console with VM SECUID but never
>mentioned the problem you are trying to solve. I don't think it solves
>your problem. Console in 3270 mode is somewhat like xedit. Xedit deals
>with files whereas console deals with system messages which can be
>massive on an active z/OS. Like xedit, consoles in 3270 mode can
>scroll, exclude, split screen, issue commands to products on z/OS and
>much more. Very useful for someone controlling z/OS.

Apologies--it was clear to ME (of course!): I want to be able to watch the IPL 
remotely. It's a dev system, quite quiet: normally nobody is looking at the 
console at all. So when we do IPL, we're used to doing it from a VM console:
XAUTOLOG ...

< Wait for "IEE389I MVS COMMAND PROCESSING AVAILABLE", then issue>
CP SEND CP ETPGZ1D VINPUT VMSG V CN(*),ACT  

>You want to use z/OS console as a 3215 which is a printer console and
>forward each line to a user using CP SECUID. With thousands of
>messages on a z/OS system, the user will be constantly clearing their
>screen. This is why I kept asking about PROP. If you don't filter the
>messages, you will just pissed off. Worse yet, because these messages
>will be formatted for a 3215, they won't be easily readable because of
>line wrap and other formatting problems.

There aren't thousands of messages, not on this system. I just left it 
overnight and there were fewer than 10 screens of them. Of course on a "real" 
system your comment would apply.

>>I thought (and still believe) the VARY made FFF "active" in some
>>sense, since without it, no SECUSER info; with it (after the VARY),
>>SECUSER info.

>V CN(*),ACTIVE could not possibly be related to FFF. It was sent to
>the emulated hardware console and activated (enabled) it for z/OS
>messages. If this solves your problem, I can tell you how to solve
>this in z/OS but it will miss the beginning messages.

Well...if I bring the guest up, the SECUSER (not "SECUID", that's not a VM 
thing) sees no messages until I issue the VARY. Repeatable. So it's doing 
*something*. Right, it misses the messages until the VARY, which is the current 
problem I'm trying to solve.

>At this point, you need to decide if this solves your problem. If not,
>maybe we can give you alternatives if you provide some details on the
>problem you want to solve. Let me know if you want me to answer your
>other questions as an fyi.

See above?

Thanks for bearing with me here,

...phsiii

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

Re: Ignorant z/OS question

2023-07-22 Thread Jon Perryman

 Hi Phil,

I need you to stop overthinking z/OS console. It's become very simple since IBM 
rewrote it several years ago. When running on a 3215 console printer, lines are 
printed and when running on a 3270, it's a fullscreen interface (like every 
other fullscreen application such as xedit). Forget that it is a z/OS console.

You've only asked us how to use z/OS console with VM SECUID but never mentioned 
the problem you are trying to solve. I don't think it solves your problem. 
Console in 3270 mode is somewhat like xedit. Xedit deals with files whereas 
console deals with system messages which can be massive on an active z/OS. Like 
xedit, consoles in 3270 mode can scroll, exclude, split screen, issue commands 
to products on z/OS and much more. Very useful for someone controlling z/OS.

You want to use z/OS console as a 3215 which is a printer console and forward 
each line to a user using CP SECUID. With thousands of messages on a z/OS 
system, the user will be constantly clearing their screen. This is why I kept 
asking about PROP. If you don't filter the messages, you will just pissed off. 
Worse yet, because these messages will be formatted for a 3215, they won't be 
easily readable because of line wrap and other formatting problems. 

> I thought (and still believe) the VARY made FFF "active" in some sense, > 
> since without it, no SECUSER info; with it (after the VARY), SECUSER info.

V CN(*),ACTIVE could not possibly be related to FFF. It was sent to the 
emulated hardware console and activated (enabled) it for z/OS messages. If this 
solves your problem, I can tell you how to solve this in z/OS but it will miss 
the beginning messages. 

At this point, you need to decide if this solves your problem. If not, maybe we 
can give you alternatives if you provide some details on the problem you want 
to solve. Let me know if you want me to answer your other questions as an fyi.

I forgot about CMS using a DIAG for full screen. 

Regards, Jon.On Friday, July 21, 2023 at 04:45:15 PM PDT, Phil Smith III 
 wrote:  

 (Wow, this thread is getting long! Sorry about that)

Jon Perryman is still endeavoring to help me, which is appreciated:

>The DEFINE GRAF did nothing useful. SECUID is associated with the VM
>user's CONSOLE definition. If you look at the z/OS syslog, you will
>find the V CN(*),ACT did not come from FFF. It will show the command
>came from another console that is either defined in the VM CONSOLE
>statement or SYSCONS / HWCI. I'm guessing from the VM CONSOLE defined.

Right, I never thought the VARY came from FFF. I thought (and still believe) 
the VARY made FFF "active" in some sense, since without it, no SECUSER info; 
with it (after the VARY), SECUSER info.

>If you IPL z/OS without the use of a CMS exec, then you will need to
>specify the SECUID on the VM user's CONSOLE statement. If you use an
>exec, then issue the SET SECUID before the CP IPL command.

Of course. I'm doing that.

>Keep in mind that VM CP is about hardware emulation (not about an OS).
>Even a CMS user requires CONSOLE 009 for the IPL CMS to be successful.
>Always think how hardware behaves regardless of the IPL'd os.

As I've said, I've been using VM for over 40 years, so I know this; what I 
don't understand is how z/OS deals with consoles, since it has its own 
full-screen support.

>Realize that you issued the V CN(*),ACTIVATE from a z/OS console that
>was not active. This is not possible in the real world. You would have
>issued the command from an active console. The VM CONSOLE is leaving
>the z/OS console in a funky state or real consoles are also in this
>funky state when powered on with commands enabled but messages
>disabled.

OK, what does "active" mean in a z/OS context? Remember, what I'm trying to do 
is to "connect" (or perhaps "activate") a z/OS console at IPL such that system 
log output is copied there in line mode so the SECUSER sees it. So this seems 
like a key bit of understanding. I keep reading z/OS doc but it's full of 
assumptions and short on examples.

>When you autolog the z/OS user, the VM CONSOLE is in a disconnected
>state. z/OS will not send messages to any console that is powered off.
>In the past, issuing commands was also disabled but that seems to have
>changed.

"powered off"? As in, not active?

>As I said before, you should be able to test this by autologing a CMS
>user that runs an exec that displays messages. It should do something
>similar as z/OS when disconnected. In the case of CMS, it should go
>from RUNNING to some sort of wait.

Yes, of course. I know how that works, have written and supported many products 
that use SECUSER. But they weren't z/OS, weren't running in CONMODE 3270.

>Adding a SECUID (secondary user) sends all messages (CP and underlying
>OS through VM user CONSOLE) to the secondary user. What is the
>hardware state if the secondary user is not logged on or disconnected?
>Does CP simply discard messages or does the hardware act as if it's

Re: Ignorant z/OS question

(Wow, this thread is getting long! Sorry about that)

Jon Perryman is still endeavoring to help me, which is appreciated:

>The DEFINE GRAF did nothing useful. SECUID is associated with the VM
>user's CONSOLE definition. If you look at the z/OS syslog, you will
>find the V CN(*),ACT did not come from FFF. It will show the command
>came from another console that is either defined in the VM CONSOLE
>statement or SYSCONS / HWCI. I'm guessing from the VM CONSOLE defined.

Right, I never thought the VARY came from FFF. I thought (and still believe) 
the VARY made FFF "active" in some sense, since without it, no SECUSER info; 
with it (after the VARY), SECUSER info.

>If you IPL z/OS without the use of a CMS exec, then you will need to
>specify the SECUID on the VM user's CONSOLE statement. If you use an
>exec, then issue the SET SECUID before the CP IPL command.

Of course. I'm doing that.

>Keep in mind that VM CP is about hardware emulation (not about an OS).
>Even a CMS user requires CONSOLE 009 for the IPL CMS to be successful.
>Always think how hardware behaves regardless of the IPL'd os.

As I've said, I've been using VM for over 40 years, so I know this; what I 
don't understand is how z/OS deals with consoles, since it has its own 
full-screen support.

>Realize that you issued the V CN(*),ACTIVATE from a z/OS console that
>was not active. This is not possible in the real world. You would have
>issued the command from an active console. The VM CONSOLE is leaving
>the z/OS console in a funky state or real consoles are also in this
>funky state when powered on with commands enabled but messages
>disabled.

OK, what does "active" mean in a z/OS context? Remember, what I'm trying to do 
is to "connect" (or perhaps "activate") a z/OS console at IPL such that system 
log output is copied there in line mode so the SECUSER sees it. So this seems 
like a key bit of understanding. I keep reading z/OS doc but it's full of 
assumptions and short on examples.

>When you autolog the z/OS user, the VM CONSOLE is in a disconnected
>state. z/OS will not send messages to any console that is powered off.
>In the past, issuing commands was also disabled but that seems to have
>changed.

"powered off"? As in, not active?

>As I said before, you should be able to test this by autologing a CMS
>user that runs an exec that displays messages. It should do something
>similar as z/OS when disconnected. In the case of CMS, it should go
>from RUNNING to some sort of wait.

Yes, of course. I know how that works, have written and supported many products 
that use SECUSER. But they weren't z/OS, weren't running in CONMODE 3270.

>Adding a SECUID (secondary user) sends all messages (CP and underlying
>OS through VM user CONSOLE) to the secondary user. What is the
>hardware state if the secondary user is not logged on or disconnected?
>Does CP simply discard messages or does the hardware act as if it's
>disconnected?

What is the hardware state of...what? If the userid is not logged on at all 
(disconnected *is* logged on as far as VM is concerned, just not connected), 
the virtual console is still there, is still used. But I don't think that's 
what you meant.

>If the disconnect is forwarded from the secondary user, then you will
>need to start the SECUID running PROP prior to starting the z/OS user.

Again, not sure what this means--does "disconnect is forwarded" mean "a CP 
DISCONNECT command is issued by the SECUSER"?

>You say z/OS messages are wrapping. "these" refers to additional
>information about the message. Unlike VM, z/OS can optionally display
>more than the message (e.g. jobname, jobnum and more). z/OS console
>ignores the hardware definition and queries the device to format
>messages according to the device. Since a 3215 is 132 bytes wide,
>expect lines to wrap on an 80 byte terminal if the line exceeds 80
>bytes. I don't know your requirements but lets say only displayed the
>message without anything else, then primary messages would not wrap
>because they are 80 bytes or less. Secondaries would still wrap (e.g.
>D NET command output). Get help from a z/OS sysprog who is familiar
>with z/OS syslog / consoles / messages and discuss what you
>requirements. Since you probably use TN3270, why not define your
>screen with lines longer than 132 bytes.

Well, I'm not worried about ME seeing the lines, I meant that it seemed like 
they weren't going to come to the SECUSER as separate lines. But as I said 
(somewhere), I might should tinker with that more.

This:
>Get help from a z/OS sysprog
...is of course the real solution here. I don't have one handy, alas. Though I 
have asked our service provider for their thoughts, no response yet (I just 
asked, had thought this would be easier than it's turned out to be).

>> I need to define some virtual device at the right address

>Your VM CONSOLE address is correct because you saw z/OS messages that
>can only come through the VM CONSOLE address. Regardless of the OS,
>you will not

Re: Ignorant z/OS question

2023-07-21 Thread Jon Perryman

 Resending with formatting corrected. Sorry but listservs don't play well with 
yahoo email.

> CP SEND CP ETPGZ1D DEFINE GRAF FFF
> CP SEND CP ETPGZ1D VINPUT VMSG VARY CN(*),ACT
> I do wonder if this will Just Work at IPL time

The DEFINE GRAF did nothing useful. SECUID is associated with the VM user's 
CONSOLE definition. If you look at the z/OS syslog, you will find the V 
CN(*),ACT did not come from FFF. It will show the command came from another 
console that is either defined in the VM CONSOLE statement or SYSCONS / HWCI. 
I'm guessing from the VM CONSOLE defined.

If you IPL z/OS without the use of a CMS exec, then you will need to specify 
the SECUID on the VM user's CONSOLE statement. If you use an exec, then issue 
the SET SECUID before the CP IPL command.

Keep in mind that VM CP is about hardware emulation (not about an OS). Even a 
CMS user requires CONSOLE 009 for the IPL CMS to be successful. Always think 
how hardware behaves regardless of the IPL'd os.

Realize that you issued the V CN(*),ACTIVATE from a z/OS console that was not 
active. This is not possible in the real world. You would have issued the 
command from an active console. The VM CONSOLE is leaving the z/OS console in a 
funky state or real consoles are also in this funky state when powered on with 
commands enabled but messages disabled.

When you autolog the z/OS user, the VM CONSOLE is in a disconnected state. z/OS 
will not send messages to any console that is powered off. In the past, issuing 
commands was also disabled but that seems to have changed.

As I said before, you should be able to test this by autologing a CMS user that 
runs an exec that displays messages. It should do something similar as z/OS 
when disconnected. In the case of CMS, it should go from RUNNING to some sort 
of wait.

Adding a SECUID (secondary user) sends all messages (CP and underlying OS 
through VM  user CONSOLE) to the secondary user. What is the hardware state if 
the secondary user is not logged on or disconnected? Does CP simply discard 
messages or does the hardware act as if it's disconnected?

If the disconnect is forwarded from the secondary user, then you will need to 
start the SECUID running PROP prior to starting the z/OS user. 

> "a console command to remove these" - what console command to remote what?

You say z/OS messages are wrapping. "these" refers to additional information 
about the message. Unlike VM, z/OS can optionally display more than the message 
(e.g. jobname, jobnum and more). z/OS console ignores the hardware definition 
and queries the device to format messages according to the device. Since a 3215 
is 132 bytes wide, expect lines to wrap on an 80 byte terminal if the line 
exceeds 80 bytes. I don't know your requirements but lets say only displayed 
the message without anything else, then primary messages would not wrap because 
they are 80 bytes or less. Secondaries would still wrap (e.g. D NET command 
output). Get help from a z/OS sysprog who is familiar with z/OS syslog / 
consoles / messages and discuss what you requirements. Since you probably use 
TN3270, why not define your screen with lines longer than 132 bytes.

 > I need to define some virtual device at the right address

Your VM CONSOLE address is correct because you saw z/OS messages that can only 
come through the VM CONSOLE address. Regardless of the OS, you will not see 
anything other than CP and this device from the VM user console. For instance, 
DEF GRAF allows you to dial into the GRAF address but has nothing to do with 
the VM user console.

> "This terminal"-which terminal?

The underlying OS uses VM user console as defined in the VM CONSOLE definition.

>  CMS users don't run with TERMINAL CONMODE 3270.

It's true the VM CONSOLE definition for CMS specifies 3215 but CMS queries the 
device. It ignores the hardware definition when required otherwise things like 
xedit wouldn't be full screen.

> Sam Cohen wrote:> It sounds like your console address in z/OS is not equal to 
> the console 

This is an absurd statement unless z/VM now supports virtual HWCI. You said 
that z/OS messages were displayed when IPL'd by logging onto the z/OS VM user. 
z/OS messages were coming through the VM CONSOLE definition address or through 
a virtual HWCI. Virtual HWCI might be a possibility because I think it was the 
one exception to issuing z/OS commands from an inactive console.

On Friday, July 21, 2023 at 03:43:43 PM PDT, Jon Perryman 
 wrote:  

  > CP SEND CP ETPGZ1D DEFINE GRAF FFF
> CP SEND CP ETPGZ1D VINPUT VMSG VARY CN(*),ACT
> I do wonder if this will Just Work at IPL time

The DEFINE GRAF did nothing useful. SECUID is associated with the VM user's 
CONSOLE definition. If you look at the z/OS syslog, you will find the V 
CN(*),ACT did not come from FFF. It will show the command came from another 
console that is either defined in the VM CONSOLE statement or SYSCONS / HWCI. 
I'm guessing from the VM CONSOLE defined.
If you IPL z/OS

Re: Ignorant z/OS question

2023-07-21 Thread Jon Perryman

 > CP SEND CP ETPGZ1D DEFINE GRAF FFF
> CP SEND CP ETPGZ1D VINPUT VMSG VARY CN(*),ACT
> I do wonder if this will Just Work at IPL time

The DEFINE GRAF did nothing useful. SECUID is associated with the VM user's 
CONSOLE definition. If you look at the z/OS syslog, you will find the V 
CN(*),ACT did not come from FFF. It will show the command came from another 
console that is either defined in the VM CONSOLE statement or SYSCONS / HWCI. 
I'm guessing from the VM CONSOLE defined.
If you IPL z/OS without the use of a CMS exec, then you will need to specify 
the SECUID on the VM user's CONSOLE statement. If you use an exec, then issue 
the SET SECUID before the CP IPL command.
Keep in mind that VM CP is about hardware emulation (not about an OS). Even a 
CMS user requires CONSOLE 009 for the IPL CMS to be successful. Always think 
how hardware behaves regardless of the IPL'd os.
Realize that you issued the V CN(*),ACTIVATE from a z/OS console that was not 
active. This is not possible in the real world. You would have issued the 
command from an active console. The VM CONSOLE is leaving the z/OS console in a 
funky state or real consoles are also in this funky state when powered on with 
commands enabled but messages disabled.
When you autolog the z/OS user, the VM CONSOLE is in a disconnected state. z/OS 
will not send messages to any console that is powered off. In the past, issuing 
commands was also disabled but that seems to have changed.
As I said before, you should be able to test this by autologing a CMS user that 
runs an exec that displays messages. It should do something similar as z/OS 
when disconnected. In the case of CMS, it should go from RUNNING to some sort 
of wait.
Adding a SECUID (secondary user) sends all messages (CP and underlying OS 
through VM  user CONSOLE) to the secondary user. What is the hardware state if 
the secondary user is not logged on or disconnected? Does CP simply discard 
messages or does the hardware act as if it's disconnected?
If the disconnect is forwarded from the secondary user, then you will need to 
start the SECUID running PROP prior to starting the z/OS user. 
> "a console command to remove these" - what console command to remote what?
You say z/OS messages are wrapping. "these" refers to additional information 
about the message. Unlike VM, z/OS can optionally display more than the message 
(e.g. jobname, jobnum and more). z/OS console ignores the hardware definition 
and queries the device to format messages according to the device. Since a 3215 
is 132 bytes wide, expect lines to wrap on an 80 byte terminal if the line 
exceeds 80 bytes. I don't know your requirements but lets say only displayed 
the message without anything else, then primary messages would not wrap because 
they are 80 bytes or less. Secondaries would still wrap (e.g. D NET command 
output).  Get help from a z/OS sysprog who is familiar with z/OS syslog / 
consoles / messages and discuss what you requirements. Since you probably use 
TN3270, why not define your screen with lines longer than 132 bytes.
 > I need to define some virtual device at the right address

Your VM CONSOLE address is correct because you saw z/OS messages that can only 
come through the VM CONSOLE address. Regardless of the OS, you will not see 
anything other than CP and this device from the VM user console. For instance, 
DEF GRAF allows you to dial into the GRAF address but has nothing to do with 
the VM user console.
> "This terminal"-which terminal?
The underlying OS uses VM user console as defined in the VM CONSOLE definition.
>  CMS users don't run with TERMINAL CONMODE 3270.
It's true the VM CONSOLE definition for CMS specifies 3215 but CMS queries the 
device. It ignores the hardware definition when required otherwise things like 
xedit wouldn't be full screen.
> Sam Cohen wrote:> It sounds like your console address in z/OS is not equal to 
> the console 
This is an absurd statement unless z/VM now supports virtual HWCI. You said 
that z/OS messages were displayed when IPL'd by logging onto the z/OS VM user. 
z/OS messages were coming through the VM CONSOLE definition address or through 
a virtual HWCI. Virtual HWCI might be a possibility because I think it was the 
one exception to issuing z/OS commands from an inactive console.
On Friday, July 21, 2023 at 08:37:50 AM PDT, Phil Smith III 
 wrote:  
 
 Well, doh: I finally decided to just try it:
CP SEND CP ETPGZ1D DEFINE GRAF FFF
CP SEND CP ETPGZ1D VINPUT VMSG VARY CN(*),ACT
...and now I'm seeing output as SECUSER!

I do wonder if this will Just Work at IPL time, or not until that VARY is 
issued. I guess I'll find out when I get a chance.

So presumably the thing that connects this is:
CONSOLE  DEVNUM(FFF) ROUTCODE(ALL)
      UNIT(3277-2)
      AUTH(ALL)
      DEL(RD)
      RNUM(19)
      RTME(1)
      MFORM(J,T)
      SEG(19)
      AREA(NONE)
      NAME(S0W10FFF)
It's certainly what led me to try that device address. 03E1 is the "real" 
console per

Re: Ignorant z/OS question

Alan Altmark wrote:
>And if you haven't done so, please read the white paper Tracy Dean
>referenced in her post. It is focused on this aspect of managing z/OS
>guests. We spent a lot of time figuring out how to make it all come
>together. (And you may remember me asking related questions on
>IBM-MAIN at the time!)

>Particularly, understand that z/OS isn't using a "device" of any kind
>It thinks it's talking to the Operating System Messages task (aka
>integrated console on the HMC), which CP simulates the same way we do
>the 3215. It also means you can't just SEND a command like you can
>with CMS.

Well, I read that paper. Lots of assumptions in there about z/OS knowledge that 
I don't have, like where it talks about "V CN(MVS0MAST),OFFLINE". I have no V 
(I assume that's VARY?) in any of my CONSOLxx members.

I do have a CNGRP00, which contains:
GROUP  NAME(MSTGRP)  
   MEMBERS(S0W103D0,S0W10FFF)

Now that's 3D0 and FFF: 3D0 is a DASD. Seems wrong? The INIT in CONSOL00 is
INIT  CMDDELIM(;) AMRF(N) MONITOR(DSNAME) CNGRP(00)
so it's looking at that console group. If I change the 3D0 to 3E1 to match the 
actual console address, is that likely to help/hurt? What I'd rather not do is 
kill the beast and require help from our hosting service--not that they won't 
help, but we'll have to wait at least a bit for that.

(BTW, a nit: "Screenshot 1 - z/VM Login Screen with Dial Command" on page 6 has 
no DIAL command on the screen)

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

Re: Ignorant z/OS question

It means that if your TN3270 client supports extended color then MCS can 
exploit it. It also means that a console can be larger than 24x80.

From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Friday, July 21, 2023 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Shmuel wrote:

>BTW, if you are running z/OS rather than the free MVS then you

>probably want UNIT(3270-X) for your CONSOLE definitions.

You mean instead of UNIT(3277-2)? What does this do for me? I assume it makes 
it an adaptable 327x instead of just a 3277-2?

--
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: Ignorant z/OS question

Shmuel wrote:

>BTW, if you are running z/OS rather than the free MVS then you

>probably want UNIT(3270-X) for your CONSOLE definitions.

You mean instead of UNIT(3277-2)? What does this do for me? I assume it makes 
it an adaptable 327x instead of just a 3277-2?

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

Re: Ignorant z/OS question

BTW, if you are running z/OS rather than the free MVS then you probably want 
UNIT(3270-X) for your CONSOLE definitions.


From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Friday, July 21, 2023 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Shmuel wrote:
>Your virtual machine definition has to be in synch with the guest OS.
>Your console definitions are part of that.

Right, I meant to add that of course I added that SPECIAL to the guest's 
directory entry, too.

--
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: Ignorant z/OS question

Shmuel wrote:
>Your virtual machine definition has to be in synch with the guest OS.
>Your console definitions are part of that.

Right, I meant to add that of course I added that SPECIAL to the guest's 
directory entry, too.

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

Re: Ignorant z/OS question

Your virtual machine definition has to be in synch with the guest OS. Your 
console definitions are part of that.

From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Friday, July 21, 2023 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Well, doh: I finally decided to just try it:
CP SEND CP ETPGZ1D DEFINE GRAF FFF
CP SEND CP ETPGZ1D VINPUT VMSG VARY CN(*),ACT
...and now I'm seeing output as SECUSER!

I do wonder if this will Just Work at IPL time, or not until that VARY is 
issued. I guess I'll find out when I get a chance.

So presumably the thing that connects this is:
CONSOLE   DEVNUM(FFF) ROUTCODE(ALL)
  UNIT(3277-2)
  AUTH(ALL)
  DEL(RD)
  RNUM(19)
  RTME(1)
  MFORM(J,T)
  SEG(19)
  AREA(NONE)
  NAME(S0W10FFF)
It's certainly what led me to try that device address. 03E1 is the "real" 
console per z/VM (that's what QUERY VIRTUAL CONSOLE shows on the guest). And 
that wants to be in TERMINAL CONMODE 3270, I think. Certainly when it is, and 
you log onto it, you get the scrolling full-screen z/OS console.

Wish I understood this better--I'm sure it's all there, just not in terms I 
grok as a VMer.

--
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: Ignorant z/OS question

Well, doh: I finally decided to just try it:
CP SEND CP ETPGZ1D DEFINE GRAF FFF
CP SEND CP ETPGZ1D VINPUT VMSG VARY CN(*),ACT
...and now I'm seeing output as SECUSER!

I do wonder if this will Just Work at IPL time, or not until that VARY is 
issued. I guess I'll find out when I get a chance.

So presumably the thing that connects this is:
CONSOLE   DEVNUM(FFF) ROUTCODE(ALL)
  UNIT(3277-2)
  AUTH(ALL)
  DEL(RD)
  RNUM(19)
  RTME(1)
  MFORM(J,T)
  SEG(19)
  AREA(NONE)
  NAME(S0W10FFF)
It's certainly what led me to try that device address. 03E1 is the "real" 
console per z/VM (that's what QUERY VIRTUAL CONSOLE shows on the guest). And 
that wants to be in TERMINAL CONMODE 3270, I think. Certainly when it is, and 
you log onto it, you get the scrolling full-screen z/OS console.

Wish I understood this better--I'm sure it's all there, just not in terms I 
grok as a VMer.

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

Re: Ignorant z/OS question

Jon Perryman wrote:

>If I remember correctly, a 3215 is 132 character print which is why

>messages are wrapping. I'm guessing that 3270 mode does not print some

>message attributes but in 3215 mode enables them because of the free

>space. Issue a console command to remove these if you don't like the

>wrapping.

 

"a console command to remove these" - what console command to remote what?

 

>> they're from the z/OS console.

 

>Actually, your z/OS has this defined as a terminal under a control

>unit. This terminal could be just as easily be for VTAM. z/OS doesn't

>care. Issue V xxx,console and z/OS allocates the device to the system

>instead of VTAM.

 

"This terminal"-which terminal?

 

>VM and z/OS may interact a little more but to deal with the missing CU

>or change from 3270 to 3215 but it's just a terminal connected to the

>console address space.

 

Right, I think we're getting there-I need to define some virtual device at the 
right address. See below, more info.

 

> SECUSER isn't getting the output.

>Are you using #CP DISCONNECT or using PA1 with DISCONNECT? I think PA1

>puts the terminal into CP mode and stops messages from passing to the

>VM terminal which means CP doesn't receive any messages to forward to

>SECUSER. My guess is that you will see messages being queued to that

>console. There's a D C command to see if message are queueing up.

 

No, either will stop the guest from running unless SET RUN ON is issued (which 
it is). But the guest is running.

 

>As a suggestion, get it working with a CMS user and a looping REXX

>exec. Once that's working, z/OS should work the same.

 

CMS users don't run with TERMINAL CONMODE 3270. That's gotta be part of the 
problem here. I think the various suggestions about 3215 mode may be the key, 
once I figure out the rest of the pieces.

 

Seymour added:

>I'm pretty sure that CP does not log guest messages to a virtual 3270,

>only to a virtual 3215. The OP could always define a virtual printer

>as an MCS console and process the SPOOL output.

 

How?

 

Meanwhile, here's more information, based on a couple of responses on IBMVM:

Sam Cohen wrote:

>It sounds like your console address in z/OS is not equal to the console 

>address in the virtual machine definition. Take a look at CONSOLxx in 

>SYS1.PARMLIB and the console definition(s) in the active IODF.

 

OK, that sounds promising. But I don't know how to look at the IODF, unless you 
mean "the virtual machine definition"; and there is no CONSOLxx in 
SYS1.PARMLIB. I searched *.PARMLIB) for "CONSOL"; in VENDOR.PARMLIB(IKJTSO00) I 
found:

--

CONSOLE INITUNUM(1000)

INITSNUM(1000)

MAXUNUM(1)

MAXSNUM(1)

--

...but I don't think that's what you meant. The only occurrences of "CONSOL" in 
SYS1.PARMLIB are in comments.

 

Ah HAH--in LVL0.PARMLIB(CONSOL00):

--

INIT  CMDDELIM(;) AMRF(N) MONITOR(DSNAME) CNGRP(00)

CONSOLE   DEVNUM(3E1) ROUTCODE(ALL)

  UNIT(3277-2)

  AUTH(MASTER)

  DEL(RD)

  RNUM(19)

  RTME(1)

  MFORM(J,T)

  SEG(19)

  AREA(NONE)

  NAME(S0W103E1)

CONSOLE   DEVNUM(FFF) ROUTCODE(ALL)

  UNIT(3277-2)

  AUTH(ALL)

  DEL(RD)

  RNUM(19)

  RTME(1)

  MFORM(J,T)

  SEG(19)

  AREA(NONE)

  NAME(S0W10FFF)

CONSOLE   DEVNUM(SYSCONS) LEVEL(ALL)

  NAME(HWCI) AUTH(MASTER) ROUTCODE(ALL)

CONSOLE   DEVNUM(SUBSYSTEM) AUTH(ALL) NAME(S0W10SSI)

HARDCOPY

  ROUTCODE(ALL)

  CMDLEVEL(CMDS)

--

 

And one more, LVL0.PARMLIB(CONSOLBK):

--

INIT  CMDDELIM(;) AMRF(N) MONITOR(DSNAME)

CONSOLE   DEVNUM(3E1) ALTERNATE(3D0) ROUTCODE(ALL)

  UNIT(3277-2)

  AUTH(MASTER)

  DEL(RD)

  RNUM(19)

  RTME(1)

  MFORM(J,T)

  SEG(19)

  AREA(NONE)

  NAME(S0W103E1)

CONSOLE   DEVNUM(3D0) ALTERNATE(3E1) ROUTCODE(ALL)

  UNIT(3277-2)

  AUTH(ALL)

  DEL(RD)

  RNUM(19)

  RTME(1)

  MFORM(J,T)

  SEG(19)

  AREA(NONE)

  NAME(S0W103D0)

CONSOLE   DEVNUM(FFF) ALTERNATE(3E1) ROUTCODE(ALL)

  UNIT(3277-2)

  AUTH(ALL)

  DEL(RD)

  RNUM(19)

  RTME(1)

  MFORM(J,T)

  SEG(19)

  AREA(NONE)

  NAME(S0W10FFF)

CONSOLE   DEVNUM(SYSCONS) LEVEL(ALL)

  NAME(HWCI) AUTH(MASTER) ROUTCODE(ALL) UD(Y)

CONSOLE   DEVNUM(SUBSYSTEM) AUTH(ALL)

CONSOLE   DEVNUM(SUBSYSTEM) AUTH(ALL)

HARDCOPY  DEVNUM(SYSLOG)

  ROUTCODE(ALL)

  CMDLEVEL(CMDS)

--

 

Output from D 
,S shows:

--

CNZ4104I 21.48.57 CONSOLE SUMMARY 394

CONSOLES MATCHING COMMAND: D 
,S

NAME TYPESTATUS DEFINED MATCHED

S0W10FFF MCS INACT

Re: Ignorant z/OS question

Most likely what you've seen before was a guest with the console defined as 
3215 and an MCS definition of that virtual device as a hardcopy console. I'm 
not aware of any mechanism for CP to capture syslog or operlog.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Thursday, July 20, 2023 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ignorant z/OS question

Shmuel wrote:
>Define a 3270 address that you can DIAL into; don't forget to use
>RESET rather than DETACH when you're done.

Yeah, that's not the answer, alas-if I wanted a 3270 session, I would just log 
onto the guest. What I've seen before is that the SECUSER sees all the z/OS 
SYSLOG traffic, and can reply via CP SEND. I'm sure I'm not describing it 
well-someone will (I hope!) say "You need a virtual device at " or "You need the XYZZY configuration in a PARMLIB 
member".

--
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: Ignorant z/OS question