Getting PIC 07 after SET MACHINE Z is what I would expect for an ESA version of 
CMS.

You don't run z/OS under CMS, so that doesn't tell me whether CMS supports 
vector instructions. Does CMS running z/XC support vector instructions?

A meaningful comparison of zPDT and z14 behavior requires identifying the CP 
and zPDT settings.

The assembler messages look like you're using the opcode table for a 3090 
rather than z.


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

________________________________________
From: IBM Mainframe Discussion List [[email protected]] on behalf of 
Phil Smith III [[email protected]]
Sent: Tuesday, October 19, 2021 3:33 PM
To: [email protected]
Subject: Re: Vector examples?

Shmuel wrote:

>Are you running releases of CP and CMS that support vector instructions?

Yes. Same as the CP and CMS I'm running z/OS on at IBM Dallas (CP 7.2, CMS
30).



>How is the CMS virtual machine defined?

ESA, same as our z/OS guest in Dallas.



>Where is the HLASM documentation for the VL instruction? Does M_3 default
to 0?

Good question; I don't have HLASM doc handy, but note that:

-> 0000E072  ????    E710C0A00006    CC 1

*** 0000E072      PROG    0007 -> 0139BCF0        DATA

doesn't even translate the instruction, so that makes it pretty clear that
it's not even recognizing the instruction.



CP is pretty smart about such things-to the point of being irritating, since
it COULD say "Hey, this is a VL instruction, but I'm not simulating it"
(which I'm sensitive to from SSCH in 370 mode, back in the day, or SIO now,
I guess), rather than pretending it doesn't know what it is. At least, ISTR
that being the behavior; someone could convince me I'm wrong pretty easily.
Anyway, it's sure not translating THIS one. In fact:

vgfmg x x

 -> 0000E072  ????    E710C0A00006    CC 1

*** 0000E072      PROG    0007 -> 0139BCF0        DATA

d ie072.20

R0000E072  ******* E710         LARL    C0A00006E720 LARL    C0900006E730 E6

R0000E080  IIHF    C0980006E712 LPER    3000         LPER    30B4

R0000E08A  ******* 0000         ******* 0000         ******* 0000

R0000E090  ******* E740



Now THIS is interesting, on Dallas machine (not zPDT):

vmfhlasm vgfmg dmsvm

VMFASM2760I VMFHLASM processing started

DMSUPD181E No update files were found

DMSOPN002E File HCPOM1 MACLIB * not found

DMSOPN002E File HCPOM2 MACLIB * not found

VMFASM1907I Assembling VGFMG

 00E06E 0000 0000 41 VL 1,WORK1,4 Set 64-bit output area VGF00310

ASMA029E Incorrect register specification - WORK1

 ASMA173S Delimiter error, expected blank - ,4

 ASMA435I Record 31 in $VGFMG   ASSEMBLE A1 on volume: ETP191

 00E072 0000 0000 42 VL 2,PARM1,4 Load 64-bit value #1 VGF00320

 ASMA029E Incorrect register specification - PARM1

 ASMA173S Delimiter error, expected blank - ,4

 ASMA435I Record 32 in $VGFMG   ASSEMBLE A1 on volume: ETP191

 00E076 0000 0000 43 VL 3,PARM2 Load 64-bit value #2 VGF00330

 ASMA029E Incorrect register specification - PARM2

 ASMA435I Record 33 in $VGFMG   ASSEMBLE A1 on volume: ETP191

  44 VGFMG 1,2,3 VECTOR GALOIS FIELD MULTIPLY SUM VGF00340

 ASMA057E Undefined operation code - VGFMG



Same source code.



Another wild hare-I copied the load module I'd created on the zPDT to z/OS
and ran it (under z/VM, with PER PROG again):

vgfmg x x

 -> 0000E072  ????    E710C0A00006

*** 0000E072      PROG    0001 -> 0139B410        OPERATION



That's different-PROG 1 instead of PROG 7.



Then I did a SET MACHINE Z and IPL ZCMS and I'm back to a PROG 7 again, DXC
FE.



Same on the zPDT, but I suspect that the fact that I get a PROG 7 instead of
a PROG 1 is a buglet.



Meanwhile, in Z mode I can do D XG0:

CRG  0 =  00000000000010E0 (z14)

CRG  0 =  00000000000010E2 (zPDT)



So it appears that, indeed, the hardware supports not the vector stuff (bits
45/46 are both zero).. I didn't think that was optional on a z14! Maybe an
option in HMC, though why is beyond me.



My conclusions:

1.      zPDT and real hardware behave differently here
2.      I do NOT have a machine that does the vector instructions
3.      The documentation on this is atrocious



Unless someone has another suggestion, I'm going to give this up at this
point, other than pointing out the inconsistency to IBM. I've learned a few
things-thanks for all the help!



...phsiii


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to