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
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,
>
> 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
>
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.
On Thu, Jun 6, 2019 at 6:38 AM Peter Relson wrote:
> >AIF ('_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 A new possible
>AIF ('_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 A new possible value is added every release.
The intended way to indicate to
