In an instance where the IPL fails due to an ALS related issue, what would
the wait state code be and would there be any system messages generated?
Did this get answered?
The wait state code and wait state reason depend on which ALS was not met.
-- 07B reason 1E is "not even a z9" (you won't
Hey Peter,
In an instance where the IPL fails due to an ALS related issue, what would the
wait state code be and would there be any system messages generated?
Thanks...
Michael Cleary
On Fri, Jun 7, 2019 at 7:59 AM Peter Relson wrote:
> Sorry for using the ALS nomenclature. I assumed "everyone" would know what
> was meant by Architecture Levelset (AKA ALS).
>
Thanks.
>
> It means, for z/OS, that a release requires a specific set of hardware
> features. Generally, that is e
Sorry for using the ALS nomenclature. I assumed "everyone" would know what
was meant by Architecture Levelset (AKA ALS).
It means, for z/OS, that a release requires a specific set of hardware
features. Generally, that is enforced, so IPL will fail if not met. Those
features are usually provided
On Thu, Jun 6, 2019 at 2:58 PM Ed Jaffe wrote:
> On 6/5/2019 9:27 AM, John McKown wrote:
> >
> > ...I am now looking at the EXECUTABLE=NO
> > operand of the STORAGE OBTAIN. I already check the z/OS level "02.02.00"
> or
> > greater to dual path my assembly code. But I have also read that although
On 6/5/2019 9:27 AM, John McKown wrote:
...I am now looking at the EXECUTABLE=NO
operand of the STORAGE OBTAIN. I already check the z/OS level "02.02.00" or
greater to dual path my assembly code. But I have also read that although
z/OS 2.3 will accept this operand, on anything less than a z14, i
>
> When there is another architecture levelset so that it makes sense for us
> to do that.
> As far as I know, no z/OS macros generate different code based on machines
> newer than the most recent architecture levelset.
>
> That is partly why I wrote that SYSSTATE ARCHLVL=xx is intended for
> noti
So when do you guys intend to add support beyond that?
When there is another architecture levelset so that it makes sense for us
to do that.
As far as I know, no z/OS macros generate different code based on machines
newer than the most recent architecture levelset.
That is partly why I wrote
Sent from Yahoo Mail on Android
On Thu, Jun 6, 2019 at 7:38 AM, Peter Relson wrote:
The intended way to indicate to z/OS macros what architecture level may be
assumed is via SYSSTATE ARCHLVL=xxx, but that provides support only up to
architecture level-sets and thus nothing past zEC12.
T
On Thu, Jun 6, 2019 at 6:38 AM Peter Relson wrote:
> >AIF ('&ZOS_LVL' LT '02.02.00').NOEXEC
>
> FWIW, The intended way for a program to indicate to z/OS (or other) macros
> what z/OS release the coder is asserting may be assumed is via
> SYSSTATE OSREL=xxx.
>
> This sets GBLC &SYSOSREL. A n
>AIF ('&ZOS_LVL' LT '02.02.00').NOEXEC
FWIW, The intended way for a program to indicate to z/OS (or other) macros
what z/OS release the coder is asserting may be assumed is via
SYSSTATE OSREL=xxx.
This sets GBLC &SYSOSREL. A new possible value is added every release.
The intended way to
> AIF ('&SYSOPT_CURR_OPTABLE' LT 'Z14').NOEXEC
Comparing OPTABLE names by alphabetical sequence (which is what
this does) is never going to produce reliable results.
For a start, OPTABLE(Z14) is supported (since PH03536) as an
alternative name for OPTABLE(ZS8), but the above test w
I doubt that you will find an airtight solution..
If someone issues an OPSYN to define or undefine
the operation mnemonic of your choice, your assembly
will take the wrong turn.
I fail to see how you would prevent that ...
Kind regards,
Abe Kornelis
==
Op 05/06/2019 om 19:13 schreef J
RCF submitted.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of John McKown
Sent: Wednesday, June 5, 2019 1:08 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z14 specific instructions?
On
On Wed, Jun 5, 2019 at 11:57 AM Seymour J Metz wrote:
> No, O'opcode will tell you whether opcode is defined, and if defined, what
> type of opcode it is. &SYSOPT_CURR_OPTABLE and &SYSOPT_OPTABLE tell you
> what table the assembler is using.
>
Correct. Suppose you are on a z14 running z/OS 2.3.
On Wed, Jun 5, 2019 at 12:05 PM Seymour J Metz wrote:
> > AIF ('&SYSOPT_CURR_OPTABLE' LT 'Z14').NOEXEC
>
> That doesn't match the documentation. Shouldn't it be
>
> AIF ('&SYSOPT_CURR_OPTABLE' LT 'ZS8').NOEXEC
>
Actually, I didn't read the doc on this. I looked at t
Assembler List on
> behalf of John McKown
> Sent: Wednesday, June 5, 2019 11:11 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: z14 specific instructions?
>
> Is there a list of instructions which only work on a z14? Why am I asking?
> Because I want to do some conditio
From: IBM Mainframe Assembler List on behalf
of John McKown
Sent: Wednesday, June 5, 2019 12:54 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z14 specific instructions?
On Wed, Jun 5, 2019 at 11:39 AM Charles Mills wrote:
> O'opcode will
___
From: IBM Mainframe Assembler List on behalf
of Charles Mills
Sent: Wednesday, June 5, 2019 12:39 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z14 specific instructions?
O'opcode will tell you what machine the programmer claimed he was targeting.
What better test is there? Yes, he
On Wed, Jun 5, 2019 at 11:39 AM Charles Mills wrote:
> O'opcode will tell you what machine the programmer claimed he was
> targeting. What better test is there? Yes, he might be lying or confused,
> but no matter what you test at assembly time, the "user" (of your source
> code -- programmer IOW)
confused ).
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of John McKown
Sent: Wednesday, June 5, 2019 9:28 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z14 specific instructions?
On Wed, Jun 5, 2019 at 11:04 AM Steve Smith
On Wed, Jun 5, 2019 at 11:04 AM Steve Smith wrote:
> Just test the O'opcode result. No guessing or research needed.
>
I have done that for some things. I am now looking at the EXECUTABLE=NO
operand of the STORAGE OBTAIN. I already check the z/OS level "02.02.00" or
greater to dual path my assem
er List on
> behalf of John McKown
> Sent: Wednesday, June 5, 2019 11:11 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: z14 specific instructions?
>
> Is there a list of instructions which only work on a z14? Why am I asking?
> Because I want to do some conditional asse
ssembler List on behalf
of John McKown
Sent: Wednesday, June 5, 2019 11:11 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: z14 specific instructions?
Is there a list of instructions which only work on a z14? Why am I asking?
Because I want to do some conditional assembly based on whether code is
: z14 specific instructions?
Is there a list of instructions which only work on a z14? Why am I asking?
Because I want to do some conditional assembly based on whether code is
assembled to run on a z14. I don't want to dual path. This will be a source
distribution, so dual pathing shou
Is there a list of instructions which only work on a z14? Why am I asking?
Because I want to do some conditional assembly based on whether code is
assembled to run on a z14. I don't want to dual path. This will be a source
distribution, so dual pathing should be unnecessary. I.e. I am "dual
pathing
26 matches
Mail list logo
