> 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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Jon
Perryman <jperr...@pacbell.net>
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 <sme...@gmu.edu>
> 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
<sme...@gmu.edu> 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
> <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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Jay
Maynard <jaymayn...@gmail.com>
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 <jperr...@pacbell.net> 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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf
> of Jon Perryman <jperr...@pacbell.net>
> 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
----------------------------------------------------------------------
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
