[H390-MVS] IFOX assembler source troubles

[Tony Harminc [e-mail] [H390-MVS]]

So for various reasons I decided to have a look at the VS Assembler, aka
Assembler XF aka IFOX[00]. It's been close to 40 years since I did so, so I
remember very little.

Where to start...? Of course it's already installed on systems like TK4-,
and I remembered talk of someone having put in the serious grunt work to
disassemble the available PTFs and build matching source, but that's about
it. So over to Jay Mosely's page at http://www.jaymoseley.com/herc
ules/compilers/ifox00.htm and ta-da it's all there. And it was Paul
Gorlinsky who did that grunt work.

A quick download, assemble (minor problems with one missing macro
IECTDECB), and link, and hey - let's try it by assembling one of its own
modules. This was on z/OS, BTW (on Real Iron, let me hasten to say).

For I believe the first time in my roughly 45 years of assembler
programming, I got an S504 abend. I had never heard of such a thing, looked
it up, and it says that the input and output lists on a VU-type GETMAIN
(LA= and A=) overlap. Bizarre, but a quick glance at the source (IFOX0A)
shows that it's true; someone was perhaps trying to save 8 bytes by using
the same storage for both arguments. OK, thought I, another new check
that's been added to z/OS, maybe as part of their grand VSM rework from a
few releases ago. I just thought I'd check to see how far back the doc goes
on this abend code, and to cut a long search story short, it is documented
at least as far back as when VS1 and SVS shared a System Codes manual.

Just weird. How can this code have ever worked? And what does the working
module on, say, TK4- contain? Well, not much disassembling is needed to see
that the addresses for the two arguments are different in the IFOX0A on
TK4-, both in the DLIB and the running SYS1.LINKLIB, IDR'd with Z32460,
whatever that is.

So... This is disquieting. None of the Mosely/Gorlinsky IBM PTFs appears to
fix this problem, yet the fix is on TK4- and presumably similar MVS 3.8
systems. So of course this throws the whole "matching source" into doubt.
Or rather, it throws my understanding of what the Gorlinsky tape claims to
have accomplished - maybe "just" getting the PTFs turned into source form -
work enough, but not what I thought.

There's another oddity that I think is unrelated, but I'm not quite sure:
The description of the tape at
http://www.jaymoseley.com/hercules/downloads/pdf/ifox00.memo.pdf
(Paul G's memo) doesn't quite match the actual tape at
http://www.jaymoseley.com/hercules/downloads/archives/ifox.tgz
Specifically a tapemap shows just 14 files vs 16 in the memo, and it's 13
and 14 that seem to be missing.

More questions... The memo lists some files as "DISASM IBM BAS" and "DISASM
HRC BAS". Disassembled (with which disassembler?) but what is IBM vs HRC,
and what is BAS?

Anyway - I haven't seen a post from Paul Gorlinsky since 2013, or Jay
Mosely for I think longer than that, so I'm not sure where to turn. Has
anyone else played with IFOX source lately?

Tony H.

[Greg Price [e-mail] [H390-MVS]]

On 2017-03-31 4:41 PM, Tony Harminc ***@gmail.com [H390-MVS] wrote:
> More questions... The memo lists some files as "DISASM IBM BAS" and
> "DISASM HRC BAS". Disassembled (with which disassembler?) but what is
> IBM vs HRC, and what is BAS?
Perhaps
IBM => version obtained from IBM
HRC => version updated in days of Hercules - perhaps incorporating the
ESD count limit increase
BAS => version updated to support the BAS and BASR mnemonics

See
http://www.prycroft6.com.au/vs2mods/index.html#zp60024
http://www.prycroft6.com.au/vs2mods/index.html#zp60025

I was satisfied that I had the source matching what was running on TK3
at the time.

Cheers,
Greg

[[e-mail] [H390-MVS]]

Hi Tony


Concerning the IFOX version on TK4-: It's just taken over from TK3, with the two usermods applied that Greg mentioned in his reply. I never digged into finding out which of the various source variants floating around is really matching.


Just a heads up in case you don't already know: Tom Armstrong is conducting a major IFOX refurbishment project, aiming to bring it much closer to HLASM than it currently is. In particular, I think, he is implementing support for most (if not all) of the s37x instructions currently available... it probably would be a good idea to contact him, perhaps some work can be coordinated.


Cheers
JÃŒrgen



---In H390-***@yahoogroups.com, <***@...> wrote :

So for various reasons I decided to have a look at the VS Assembler, aka Assembler XF aka IFOX[00]. It's been close to 40 years since I did so, so I remember very little.


Where to start...? Of course it's already installed on systems like TK4-, and I remembered talk of someone having put in the serious grunt work to disassemble the available PTFs and build matching source, but that's about it. So over to Jay Mosely's page at http://www.jaymoseley.com/herc ules/compilers/ifox00.htm http://www.jaymoseley.com/hercules/compilers/ifox00.htm and ta-da it's all there. And it was Paul Gorlinsky who did that grunt work.


A quick download, assemble (minor problems with one missing macro IECTDECB), and link, and hey - let's try it by assembling one of its own modules. This was on z/OS, BTW (on Real Iron, let me hasten to say).


For I believe the first time in my roughly 45 years of assembler programming, I got an S504 abend. I had never heard of such a thing, looked it up, and it says that the input and output lists on a VU-type GETMAIN (LA= and A=) overlap. Bizarre, but a quick glance at the source (IFOX0A) shows that it's true; someone was perhaps trying to save 8 bytes by using the same storage for both arguments. OK, thought I, another new check that's been added to z/OS, maybe as part of their grand VSM rework from a few releases ago. I just thought I'd check to see how far back the doc goes on this abend code, and to cut a long search story short, it is documented at least as far back as when VS1 and SVS shared a System Codes manual.


Just weird. How can this code have ever worked? And what does the working module on, say, TK4- contain? Well, not much disassembling is needed to see that the addresses for the two arguments are different in the IFOX0A on TK4-, both in the DLIB and the running SYS1.LINKLIB, IDR'd with Z32460, whatever that is.


So... This is disquieting. None of the Mosely/Gorlinsky IBM PTFs appears to fix this problem, yet the fix is on TK4- and presumably similar MVS 3.8 systems. So of course this throws the whole "matching source" into doubt. Or rather, it throws my understanding of what the Gorlinsky tape claims to have accomplished - maybe "just" getting the PTFs turned into source form - work enough, but not what I thought.


There's another oddity that I think is unrelated, but I'm not quite sure: The description of the tape at
http://www.jaymoseley.com/ hercules/downloads/pdf/ifox00. memo.pdf http://www.jaymoseley.com/hercules/downloads/pdf/ifox00.memo.pdf
(Paul G's memo) doesn't quite match the actual tape at
http://www.jaymoseley.com/ hercules/downloads/archives/ ifox.tgz http://www.jaymoseley.com/hercules/downloads/archives/ifox.tgz

Specifically a tapemap shows just 14 files vs 16 in the memo, and it's 13 and 14 that seem to be missing.


More questions... The memo lists some files as "DISASM IBM BAS" and "DISASM HRC BAS". Disassembled (with which disassembler?) but what is IBM vs HRC, and what is BAS?


Anyway - I haven't seen a post from Paul Gorlinsky since 2013, or Jay Mosely for I think longer than that, so I'm not sure where to turn. Has anyone else played with IFOX source lately?


Tony H.

[Tony Harminc [e-mail] [H390-MVS]]

On 31 March 2017 at 12:43, ***@id.ethz.ch wrote:
>
> Concerning the IFOX version on TK4-: It's just taken over from TK3, with the two usermods applied that Greg mentioned in his
> reply. I never digged into finding out which of the various source variants floating around is really matching.

As far as I can see, none of the source versions of IFOX0A has the
necessary correction. This is a strange one, because it's not clear
how the code can ever have worked. And this is *the* GETMAIN for all
working storage, done right at assembler startup, so it's not some
kind of subtle problem that will be encountered only when assembling
some complex code.

Well, I'm guessing there may be an exception, and that is that CMS's
OS emulation may not check for overlap, which could explain how Paul
G. was able to say of the combined IBM base and PTFs in his memo that
"As it turned out they matched the TEXT DECKS from a VM/SP and a z/VM
system." Modern z/OS no longer ships IFOX at all (no SYS1.AOS03 DLIB),
and modern z/VM has the MODULE files, but I can't find any source,
matching or not. So the puzzle is where did the object code on TKx
systems come from, and how is it that we have no IBM PTF that corrects
what must surely be a very old and basic problem.

> Just a heads up in case you don't already know: Tom Armstrong is conducting a major IFOX refurbishment project, aiming to
> bring it much closer to HLASM than it currently is. In particular, I think, he is implementing support for most (if not all) of the
> s37x instructions currently available... it probably would be a good idea to contact him, perhaps some work can be coordinated.

I did not know - thank you! Was there a mention of this somewhere? Tom
does not post much on these lists (unless I am missing one somewhere),
but I will certainly contact him. I don't have any grand project in
mind, but certainly coordination will not hurt.

Is ***@yahoo.com still a good address?

Tony H.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> Just a heads up in case you don't already know:
> Tom Armstrong is conducting a major IFOX
> refurbishment project, aiming to bring it much
> closer to HLASM than it currently is.

Hi Tom. Could you please provide an update
on this project, and perhaps share a beta?
It would be good to start compiling IFOX from
source, even without any new features.

Thanks. Paul.

[[e-mail] [H390-MVS]]

Hi Paul,
Sorry to say I am some way from even providing a beta release.
New opcodes, enhanced macro functions, new message generation code etc etc have all taken so much more time than I thought to implement.
I will let you know when I have something that is stable enough for a beta.
Regards
Tom

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> Sorry to say I am some way from even providing a beta release.

Hi Tom.

Would you perhaps have an archive that you would
say is the definitive source for what we are running
now, so that we can start building the assembler
from source?

Or is even that uncertain?

Thanks. Paul.

[[e-mail] [H390-MVS]]

Hi Paul,
Yahoo search is your friend here. The topic of building IFOX00 from available source has been covered previously.
Regards

[[e-mail] [H390-MVS]]

Hi Tony,
You certainly have opened up an interesting problem.
Two problems in fact.
Firstly you have found that that source code for module IFOX0A does not match the load module that is distributed in TK3 and in TK4-.

The assembly of the problem area in IFOX0A shows:

00018C D203 D174 D2D0 00174 002D0 679 MVC JEOS,CORESIZE GET REQ CORESIZE
000192 D203 D170 8458 00170 00460 680 MVC JBOS(D4),MINCORE GET MIN CORE VALUE @AZ13738
681 GETMAIN VU,LA=JBOS,A=JBOS,SP=0,HIARCHY=0,MF=(E,JDWORD) GET ALL THE CORE WE CAN
682+* OS/VS2 RELEASE 4 VERSION -- 10/21/75
000198 4110 D2F8 002F8 683+ LA 1,JDWORD LOAD PARAMETER REG 1
00019C 41E0 D170 00170 684+ LA 14,JBOS PICK UP LIST ADDRESS
0001A0 50E0 1000 00000 685+ ST 14,0(0,1) STORE INTO PARAM LIST
0001A4 92C0 1008 00008 686+ MVI 8(1),B'11000000' SET MODE / BNDRY FLGS
0001A8 41E0 D170 00170 687+ LA 14,JBOS LOAD AREA LIST ADDRESS
0001AC 50E0 1004 00004 688+ ST 14,4(0,1) STORE INTO PARAM LIST
0001B0 9200 1009 00009 689+ MVI 9(1),0 MOVE IN SUBPOOL VALUE
0001B4 0A04 690+ SVC 4 ISSUE GETMAIN SVC
However a AMASPZAP DUMP of the load module in TKx shows:
018C D203 D2D8 D2D0
0192 D203 D2D4 8458
0198 4110 D2F8
019C 41E0 D2D4
01A0 50E0 1000
01A4 92C0 1008
01A8 41E0 D170
01AC 50E0 1004
01B0 9200 1009
01B4 0A04
Note the use of another area in the setup and parameter list construction.
Looking at what area was used looks like whoever did this just borrowed another area. If I was to point the finger I would say AZ13738 has something to do with this as its footprint are all over the source code in the changed areas.
0002D0 366 CORESIZE DS F REQUESTED WORKAREA @AZ13738
0002D4 367 OLDBUF DS F PTR TO MBUF LAST USED @AZ13738 00546000
0002D8 368 CURRBUF DS F PTR TO MBUF IN USE @AZ13738 00548000
Now to the next problem. I attempted to duplicate your abend with the following program:
TEST TITLE 'TEST GETMAIN PROCESSING'
TESTMAIN CSECT
USING *,R12
TLAB SAVE (14,12),,'TEST GETMAIN PROCESSING &SYSDATE &SYSTIME'
LR R12,R15 LOAD BASE REGISTER
LR R2,R13
LA R13,SAVEA1
ST R2,4(,R13) CHAIN SAVE AREAS
ST R13,8(,R2)
*
* TEST
*
MVC JEOS,CORESIZE GET REQ CORESIZE
MVC JBOS(4),MINCORE GET MIN CORE VALUE
WTO 'ISSUE GETMAIN'
*
* GET ALL THE STORAGE AVAILABLE
*
GETMAIN VU,LA=JBOS,A=JBOS,SP=0,MF=(E,JDWORD)
WTO 'RETURN FROM GETMAIN'
* RETURN TO CALLER
EOJ L R13,4(,R13) RETURN TO CALLER
RETURN (14,12),RC=0
* SAVEAREAS
SAVEA1 DC 18F'0'
JDWORD DC D'0'
*
JBOS DC F'0'
JEOS DC F'0'
*
CORESIZE DC A(512*1024)
MINCORE DC F'8'

10.33.19 JOB 8209 +ISSUE GETMAIN
10.33.19 JOB 8209 +RETURN FROM GETMAIN
10.33.19 JOB 8209 T1MAIN TEST TESTMAIN RC= 0000

The program runs successfully on my system. The next question to ask is what MVS system are you using that gives you the Abend?

Regards
Tom

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
- - - All snipped - - -

This is also being discussed on:
https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages

Including asking if all PTFs were applied before disassembly?

An old list from IBM but most were superseded by the FMID or
other PTFs.

0AS2 UY77102 9203
0AS2 UZ23668 7903
0AS2 UZ24114 7903
0AS2 UZ25389 8001
0AS2 UZ25390 7905
0AS2 UZ28890 8001
0AS2 UZ31687
0AS2 UZ31800 8011
0AS2 UZ31801 8011
0AS2 UZ32444 8010
0AS2 UZ32460 8010
0AS2 UZ32461 8010
0AS2 UZ33414 8011
0AS2 UZ33807 8101
0AS2 UZ33809 8101
0AS2 UZ34102 8101
0AS2 UZ34597 8102
0AS2 UZ34598 8107
0AS2 UZ34601 8102
0AS2 UZ34603 8102
0AS2 UZ35490 8106
0AS2 UZ35791 8106
0AS2 UZ36111 8207
0AS2 UZ36471 8107
0AS2 UZ36815
0AS2 UZ36971 8108
0AS2 UZ42140 8507
0AS2 UZ49959 8602
0AS2 UZ52227 8209
0AS2 UZ56206 8301
0AS2 UZ57269 8209
0AS2 UZ57526 8209
0AS2 UZ57881 8209
0AS2 UZ58330 8209
0AS2 UZ61763 8306
0AS2 UZ65533 8310
0AS2 UZ68355 8402
0AS2 UZ69166 8402
0AS2 UZ69418 8402
0AS2 UZ70679 8404
0AS2 UZ70940 8405
0AS2 UZ71064 8405
0AS2 UZ71545 8405
0AS2 UZ73741 8407
0AS2 UZ73839 8407
0AS2 UZ80273 8504
0AS2 UZ80274 8504
0AS2 UZ81148 8605

++ PTF (UZ34603) 004 ? ? ? FMID superceded but adds instructions ? ? ?
++ VER (Z038) FMID (EAS1102) SUP (AZ49687)
PROBLEM OZ49687 INSTRUCTIONS CONCS, DISCS, IPTE, TPROT AND CLRCH
ARE NOT SUPPORTED.

++ PTF (UZ52227) CUM8503 ? ? ? Adds MVCIN ? ? ?
++ VER (Z038) FMID (EAS1102) SUP (AZ49687,AZ52956,UZ34603)
PROBLEM DESCRIPTION(S):
OZ49687 - INSTRUCTIONS INTRODUCED BY EXTENDED FACILITY, RECOVERY
EXTENSION FEATURE & CHANNEL-SET-SWITCHING WERE NOT
SUPPORTED.
OZ52956 - MVCIN WAS NOT SUPPORTED.

++ PTF (UY77102)
++ VER (Z038) FMID(EAS1102) PRE (UZ23668)
SUP (UZ36111,UZ33807,AZ51171,AZ48965,AY51810)
OY51810 -
* PROBLEM DESCRIPTION: ABEND0C4 OCCURRED AT X'4E8' IN IFOX21
* WHEN ASSEMBLING ON AN MVS/XA SYSTEM.
* THE SAME SOURCE ASSEMBLED ERROR FREE
* ON AN MVS/SP SYSTEM.
*
* RECOMMENDATION:
DUE TO AN INCORRECT BRANCH THE ASSEMBLER WAS ENTERING
AN AREA OF CODE WITHOUT CORRECTLY SETTING UP THE REGISTERS.
THE ABENDOC4 WAS ENCOUNTERED ON SUBSEQUENT OPERATIONS WHICH
DEPENDED ON THE REGISTER VALUES THAT HAD BEEN PASSED IN.
MODULE IFNX2A HAS BEEN CHANGED TO BRANCH TO THE CORRECT
LOCATION.

++ PTF (UZ34601) ? ? ? This is the GETMAIN issue ? ? ?
++ VER (Z037) PRE (UZ13353) SUP (AZ50039).
++ VER (Z038) FMID (EAS1102) SUP (AZ50039)
PROBLEM OZ50039 TWO WORDS RETURNED FROM V FORM GETMAIN OVERLAP
THE LA PARAMETER
ENVIRONMENT SYSTEM MVS RELEASE 037, 038
++ MOD (IFOX0A) DISTLIB (AOS03)

++ PTF (UZ57269) ? ? ? 3380 fix ? ? ?
++ VER (Z038) FMID(EAS1102) PRE (UZ23668) SUP (UZ54879,AZ51220,AZ61067)
PROBLEM DESCRIPTION(S):
OZ51220 - ASSEMBLER NOT USING MAX BUFFSIZE FOR WORKFILES ON D/T3380
OZ61067 - MSGIFO089 WITH BUFFSIZE=(MAX) & OZ51220, D/T3380

++ PTF (UZ58330) ? ? ? RECFM=UB issue ? ? ?
++ VER (Z038) FMID(EAS1102) SUP (AZ58316)
PROBLEM DESCRIPTION(S):
OZ58316 - ASSEMBLER ALLOWS USER TO OUTPUT SYSPUNCH AS RECFM=U BUT
CHANGES IT TO RECFM=UB WHICH IS INVALID FOR LINKEDIT

++ PTF (UZ81148) ? ? ? Our ESD issue ? ? ?
++ VER (Z038) FMID(EAS1102)
SUP (UZ80274,UZ71545,UZ70679,UZ69166,UZ68355,UZ61763,
UZ56206,UZ37628,UZ36815,UZ31801,UZ31800,AZ93894,
AZ84820,AZ76306,AZ75686,AZ75662,AZ71509,AZ65233,
AZ59051,AZ54553,AZ52752,AZ46156,AZ42243)
PROBLEM DESCRIPTION(S):
OZ93894 -
* USERS AFFECTED: ANY ASSEMBLER XF USER THAT HAS AN ASSEMBLY
* WITH A VERY LARGE NUMBER OF ESD ENTRIES
* PROBLEM DESCRIPTION: AN ASSEMBLY WITH A VERY LARGE NUMBER OF
* ESD ENTRIES CAN OVERLAY THE SYMBOL
* TABLE. THIS TEST CASE HAD X'FD' ESD
* ENTRIES.
* RECOMMENDATION:
A LARGER AREA IS BEING PROVIDED FOR ESD TABLE BUILD.
LOAD MODULES IFOX41 AND IFOX42 WILL BE REPLACED.

[Tony Harminc [e-mail] [H390-MVS]]

On 31 March 2017 at 20:06, ***@yahoo.com wrote:

>
> Hi Tony,
>
> You certainly have opened up an interesting problem.
>
> Two problems in fact.
>
> Firstly you have found that that source code for module IFOX0A does not
> match the load module that is distributed in TK3 and in TK4-.
>
>
>
> The assembly of the problem area in IFOX0A shows:
>

Hi Tom,

I think you have perhaps come in in the middle of the conversation. This is
my fault, because I cross posted to multiple Hercules groups, and then
things took on multiple threads. I should know better by now, but I tend to
think of Hercules as a single group, and though e.g. I tag the group mail
with different Gmail labels, I generally read them all sequentially.

So in my original post I pointed out this problem of a difference in the
GETMAIN expansion in the TK4- libraries (both distlib (SYS1.AOS03) and
SYS1.LINKLIB as compared to Paul Gorlinsky's source and object. Clearly
there was a missing fix, and though I didn't realize it at the time, I had
its number right in the IDR data for the load module. (I don't know why
it's just Z34601, but it clearly corresponds to UZ34601 as posted later by
somitcw.)


> However a AMASPZAP DUMP of the load module in TKx shows:
>
> 018C D203 D2D8 D2D0
> 0192 D203 D2D4 8458
> 0198 4110 D2F8
> 019C 41E0 D2D4
> 01A0 50E0 1000
> 01A4 92C0 1008
> 01A8 41E0 D170
> 01AC 50E0 1004
> 01B0 9200 1009
> 01B4 0A04
>
> Note the use of another area in the setup and parameter list construction.
>
> Looking at what area was used looks like whoever did this just borrowed
> another area. If I was to point the finger I would say AZ13738 has
> something to do with this as its footprint are all over the source code in
> the changed areas.
>

Are you suggesting that AZ13738 broke the original, and it was then
corrected by UZ34601? AZ13738 is, as you say, all over it, but
conspicuously not tagged on the GETMAIN.


> Now to the next problem. I attempted to duplicate your abend with the
> following program:
>
[...]



The program runs successfully on my system. The next question to ask is
what MVS system are you using that gives you the Abend?



For several reasons of curiosity, I had both built from source and tried to
run the Paul G. version on a current (2.2) z/OS system (on IBM Real Iron).
That's why I had mentioned earlier my suspicion that z/OS had added the
overlap check and abend S504 quite recently, probably as part of their
grand VSM rework of a few years ago (1.9, iirc). Then somitcw pointed out
that enforcement of this long-documented check was actually mentioned as an
MVS/XA difference. So that's why it failed for me, and not for you or
anyone else on MVS/370.


I was actually expecting to get some kind of failure on z/OS - maybe some
obsolete assumption about I/O or something, but not this one! But there's
time yet; I haven't fixed the GETMAIN and tried to run again.


FYI, there was another curious difference between my z/OS GETMAIN expansion
(which expands identically to the MVS 3.8J one, BTW), and the object deck
(CMS TEXT file) as distributed in Paul G's tape file 2. In Pauls object for
IFOX0A, there is an additional MVI 4(R1),0 just before the MVI 9(R1),0
before the SVC 4. Eventually I realized that his assembly was done using
the CMS OSMACRO MACLIB dated 3/02/89, and presumbly the GETMAIN there is
more like MVT's than MVS's. So this is unrelated to the missing PTF, and
just something that consumed an extra hour or so.


Regards,


Tony H.

------------------------------
___

>

[[e-mail] [H390-MVS]]

Tony wrote:

"So in my original post I pointed out this problem of a difference in the GETMAIN expansion in the TK4- libraries (both distlib (SYS1.AOS03) and SYS1.LINKLIB as compared to Paul Gorlinsky's source and object. Clearly there was a missing fix, and though I didn't realize it at the time, I had its number right in the IDR data for the load module. (I don't know why it's just Z34601, but it clearly corresponds to UZ34601 as posted later by somitcw.)"

1st - IFOX isn't assembled in TK3 or TK4-

It comes straight from the DLIB tape and is linked into SYS1.LINKLIB as part of the system build.

2nd - UZ34601 is already in the distribution libraries

No separate PTF to apply

3rd - Paul G must have gotten his modules to disassemble and compare from VM/370 and VM/SP ?

If they had come from any of the Turnkey systems ( 1-3, 4-) they would have had the fix in place already. Since his work has numerous VM isms associated with it believe the libraries in VM must be backlevel to those in MVS 3.8j.

The 'naming' of the files xxxx IBM BAS xxxx HRC BAS makes me think IBM was from a later VM system versus HRC with VM/370 as origin. BAS - Basic Assembler Source ( some more VM speak I think where no . between qualifiers ).

Phil

[[e-mail] [H390-MVS]]

Phil,



That sounds plausible. Paul spent much of his time working on VM, I haven’t spoken to him for a while but I can ask him if needs be. The assembler in VM is one of the few bits of code with no source supplied, and there don’t seem to be any fixes on the 6-Pack.



Dave



From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: 01 April 2017 18:11
To: H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Re: IFOX assembler source troubles





Tony wrote:

"So in my original post I pointed out this problem of a difference in the GETMAIN expansion in the TK4- libraries (both distlib (SYS1.AOS03) and SYS1.LINKLIB as compared to Paul Gorlinsky's source and object. Clearly there was a missing fix, and though I didn't realize it at the time, I had its number right in the IDR data for the load module. (I don't know why it's just Z34601, but it clearly corresponds to UZ34601 as posted later by somitcw.)"

1st - IFOX isn't assembled in TK3 or TK4-

It comes straight from the DLIB tape and is linked into SYS1.LINKLIB as part of the system build.

2nd - UZ34601 is already in the distribution libraries

No separate PTF to apply

3rd - Paul G must have gotten his modules to disassemble and compare from VM/370 and VM/SP ?

If they had come from any of the Turnkey systems ( 1-3, 4-) they would have had the fix in place already. Since his work has numerous VM isms associated with it believe the libraries in VM must be backlevel to those in MVS 3.8j.

The 'naming' of the files xxxx IBM BAS xxxx HRC BAS makes me think IBM was from a later VM system versus HRC with VM/370 as origin. BAS - Basic Assembler Source ( some more VM speak I think where no . between qualifiers ).

Phil

[[e-mail] [H390-MVS]]

Not sure when the base of IFOX appeared or what VM/370 may have as distributed libraries for IFOX. It may be missing some more of the below. From the Program Directory for 3.8j in the files section:

6.1
EAS1102
* * *
I N C L U D E D
PTF#


UZ23668
UZ24114
UZ25389
UZ25390
UZ28890
UZ31800
UZ31801
UZ32444
UZ32460
UZ32461
UZ33414
UZ33807
UZ33809
UZ34102
UZ34597
UZ34598
UZ34601
UZ34603
UZ35490
UZ35791
UZ36111
UZ36471
UZ36971

from 7903 to 8207.

Phil

[Tony Harminc [e-mail] [H390-MVS]]

On 1 April 2017 at 13:11, ***@hotmail.com wrote:

> 1st - IFOX isn't assembled in TK3 or TK4-
>
> It comes straight from the DLIB tape and is linked into SYS1.LINKLIB as
> part of the system build.
>
> 2nd - UZ34601 is already in the distribution libraries
>
> No separate PTF to apply
>
> 3rd - Paul G must have gotten his modules to disassemble and compare from
> VM/370 and VM/SP ?
>
> If they had come from any of the Turnkey systems ( 1-3, 4-) they would
> have had the fix in place already. Since his work has numerous VM isms
> associated with it believe the libraries in VM must be backlevel to those
> in MVS 3.8j.
>

Sounds plausible, but I don't think that idea is compatible with what he
had to say in the memo accompanying his tape (actually from Jay Moseley's
site, but I see no indication that the memo isn't Paul G''s original):

"I started with the DLIBS from the MVS 38J TURNKEY distribution as of
26-DEC-06. I then imported
from the PTF TAPE "ALLPTFS" included with the TURNKEY system. Sorted out
the SUSPed PTFS, they are on
this tape with an 'S' on then end of the PTF.
PTFs are:
UY77102, UZ49959, UZ52227, UZ56206S,
UZ57269, UZ57526, UZ57881S, UZ58330,
UZ61763S, UZ65533S, UZ68355S, UZ69166S,
UZ69418S, UZ70679S, UZ70940S, UZ71064,
UZ71545S, UZ73741, UZ73839, UZ80273,
UZ80274S, UZ81148
These are the filenames with EAS1102 as the filetype. The PTFs are in SMP
format, the TEXT DECKS were
manually pulled out of the file, from there I sorted out the PRE-REQ,
CO-REQ, and SUSPs and used those
TEXT DECKS to form the base. As it turned out they matched the TEXT DECKS
from a VM/SP and a z/VM system."

So while he was indeed working and building on a VM system, the origin was
evidently MVS in 2006, presumably an earlier iteration than TK3 or TK4-.
Maybe it was the latest available maintenance as of 2007 when he did this
work, and as has come out in this thread, the GETMAIN in question evidently
does not fail on MVS/370 or CMS systems, so it went unnoticed until my z/OS
adventure.

Tony H.

[[e-mail] [H390-MVS]]

Hi Tony,

We can speculate as to what he started with even though 3.8j distribution tape has the PTF included already. The program directory in the files section is dated as maintenance to 8208. Mine is the same except there is SERVICE LEVEL 8505 for 2 additional FMIDs ( ESY1400 and EBB1102 ).

Back in pre-Turnkey days, I compared my dlib tape with the one available online and the one used to create the Turnkey systems later. They were the same. Don't know where Paul's starting point was.

1. The starter system was used MVS 3.7 no dlibs but can disassemble from SYS1.LINKLIB

2. VS1 from a university for a short period of time - no idea what was on it IFOX wise

3. VM/370 but confused memo source comment as to where it actually came from .

4. Something in Paul's archive of stuff, again confused memo source .

Phil

[[e-mail] [H390-MVS]]

AArrggh,

I meant to add:

If you want to try it out on z/OS on real iron from the Turnkey, migrate SYS1.AOS03 over to the z/OS system and run sg0130 from the Turnkey system generation to link from the dlib.

Phil

[[e-mail] [H390-MVS]]

I asked Paul. He says:-



Dave,



It has been a long time since I looked at all of this, however, what I remember is that I started with the source from the Dlibs, moved it to VM, then disassembled each object PTF create source patches of each. Finally rolling it backup to match what was on MVS and VM as object code. There might of been additional PTFs discovered after I did that work.



I thought I put a memo detailing the ptfs that were included. It was suppose to be a base to start adding current instructions into the assembler.



Paul



The memo included with the six=pack mentions non of this. It just says the files are a re-packaging of the Pycroft mods. I know this don’t help much, but it should stop further speculation




Dave



From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: 02 April 2017 00:17
To: H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Re: IFOX assembler source troubles








On 1 April 2017 at 13:11, ***@hotmail.com <mailto:***@hotmail.com> wrote:

1st - IFOX isn't assembled in TK3 or TK4-

It comes straight from the DLIB tape and is linked into SYS1.LINKLIB as part of the system build.

2nd - UZ34601 is already in the distribution libraries

No separate PTF to apply

3rd - Paul G must have gotten his modules to disassemble and compare from VM/370 and VM/SP ?

If they had come from any of the Turnkey systems ( 1-3, 4-) they would have had the fix in place already. Since his work has numerous VM isms associated with it believe the libraries in VM must be backlevel to those in MVS 3.8j.



Sounds plausible, but I don't think that idea is compatible with what he had to say in the memo accompanying his tape (actually from Jay Moseley's site, but I see no indication that the memo isn't Paul G''s original):

"I started with the DLIBS from the MVS 38J TURNKEY distribution as of 26-DEC-06. I then imported
from the PTF TAPE "ALLPTFS" included with the TURNKEY system. Sorted out the SUSPed PTFS, they are on
this tape with an 'S' on then end of the PTF.
PTFs are:
UY77102, UZ49959, UZ52227, UZ56206S,
UZ57269, UZ57526, UZ57881S, UZ58330,
UZ61763S, UZ65533S, UZ68355S, UZ69166S,
UZ69418S, UZ70679S, UZ70940S, UZ71064,
UZ71545S, UZ73741, UZ73839, UZ80273,
UZ80274S, UZ81148
These are the filenames with EAS1102 as the filetype. The PTFs are in SMP format, the TEXT DECKS were
manually pulled out of the file, from there I sorted out the PRE-REQ, CO-REQ, and SUSPs and used those
TEXT DECKS to form the base. As it turned out they matched the TEXT DECKS from a VM/SP and a z/VM system."

So while he was indeed working and building on a VM system, the origin was evidently MVS in 2006, presumably an earlier iteration than TK3 or TK4-. Maybe it was the latest available maintenance as of 2007 when he did this work, and as has come out in this thread, the GETMAIN in question evidently does not fail on MVS/370 or CMS systems, so it went unnoticed until my z/OS adventure.

Tony H.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> source code for module IFOX0A

Hi Tom.

What would be required to make the
IFOX load modules AM31-bit clean
so that they can all run on z/OS in
31-bit mode, while still working as
AM24 o MVS 3.8j (ie AMODE ANY)?

Also, for the memory that they use
for work areas to be obtained using
GETMAIN LOC=ANY/31.

Or even better - for the module to
be able to reside ATL (ie RMODE
ANY) so that the default LOC=RES
GETMAIN will get ATL memory.

And then to work on MVS/380, meaning
that buffers/addresses given to the
operating system must reside BTL,
ie memory must have been allocated
with either LOC=BELOW or
"GETMAIN R".

Gerhard - I have a vague recollection
that you had a problem with some
assembler (maybe not IFOX?)
running out of memory forcing you
to use some alternate assembler?
Tachyon? But there was some other
issue with that?

Thanks. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

On 4/2/2017 11:47 PM, ***@yahoo.com.au [H390-MVS] wrote:
> ---In H390-***@yahoogroups.com, <***@...> wrote :
>
>> source code for module IFOX0A
> Hi Tom.
>
> What would be required to make the
> IFOX load modules AM31-bit clean
> so that they can all run on z/OS in
> 31-bit mode, while still working as
> AM24 o MVS 3.8j (ie AMODE ANY)?
>
>
Err...

First, you are going to need to change all the BALR to BASR...(and BAL
to BAS).

--Ivan

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

>>> source code for module IFOX0A
>>
>> What would be required to make the
>> IFOX load modules AM31-bit clean
>> so that they can all run on z/OS in
>> 31-bit mode, while still working as
>> AM24 o MVS 3.8j (ie AMODE ANY)?

> Err...

> First, you are going to need to change all
> the BALR to BASR...(and BAL to BAS).

No, that is not required. BAL/BALR
work fine in 31-bit mode and do not
populate the crap byte with, well, crap.
That only happens in 24-bit mode.

The 3 MB GCC load module uses
BALR exclusively:

C:\devel\gcc\gcc>grep BAL toplev.s | head
BALR 12,0
BALR 12,0
BALR 12,0
BALR 12,0
BALR 14,15
BALR 14,15
BALR 12,0
BALR 12,0
BALR 14,15
BALR 12,0

and runs perfectly fine on z/OS and
MVS/380 in 31-bit mode. And
perfectly fine in 24-bit mode
anywhere too.

BFN. Paul.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> No, that is not required. BAL/BALR
> work fine in 31-bit mode

And the code can reside ATL on
z/OS too, no problem. In fact I
rely on it so that I can use LOC=RES
for my ANY/ANY modules.

BFN. Paul.

[Tony Harminc [e-mail] [H390-MVS]]

On 2 April 2017 at 17:53, Ivan Warren ***@vmfacility.fr wrote:
>> What would be required to make the
>> IFOX load modules AM31-bit clean
>> so that they can all run on z/OS in
>> 31-bit mode, while still working as
>> AM24 o MVS 3.8j (ie AMODE ANY)?
>>
>>
> Err...
>
> First, you are going to need to change all the BALR to BASR...(and BAL to
> BAS).
>
> --Ivan

Ivan, it's April 2nd - no longer the 1st anywhere in the world...

Tony H.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> Gerhard - I have a vague recollection
> that you had a problem with some
> assembler (maybe not IFOX?)
> running out of memory forcing you
> to use some alternate assembler?
> Tachyon? But there was some other
> issue with that?

Searching through the os380 archives,
it looks like I have that the wrong way
around.

It is Tachyon that runs out of memory,
and IFOX is fine (at least as far as
memory is concerned).

The thing stopping you from using IFOX
for various projects is that it is missing
features in HLASM (aka ASMA90),
which is why you were going down the
Tachyon route in the first place.

BFN. Paul.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> It is Tachyon that runs out of memory,

So what we need is for Tachyon to
be recompiled with the latest
GCC/PDPCLIB so that when
MVS/380 starts supporting multiple
ATL requests, Tachyon can do
large assemblies on that platform.

BFN. Paul.

[Joe Monk [e-mail] [H390-MVS]]

Tachyon is commercial software.

Joe

On Sun, Apr 2, 2017 at 6:56 PM, ***@yahoo.com.au [H390-MVS] <
H390-***@yahoogroups.com> wrote:

>
>
> ---In H390-***@yahoogroups.com, <***@...> wrote :
>
> > It is Tachyon that runs out of memory,
>
> So what we need is for Tachyon to
> be recompiled with the latest
> GCC/PDPCLIB so that when
> MVS/380 starts supporting multiple
> ATL requests, Tachyon can do
> large assemblies on that platform.
>
> BFN. Paul.
>
>

[[e-mail] [H390-MVS]]

Yes, but they have a free license:

http://www.tachyonsoft.com/legacy.html

Hercules is free.
Linux is free.
MVS 3.8 is free.
The Tachyon Legacy Assembler is free.



Does anyone know what C compiler
they used to build the legacy assembler?

If it is Dignus, I might try contacting
Dignus and ask them to produce
ANY/ANY modules the same as
GCCMVS (beta) does.

With a view to having it work on
the next generation MVS/380
that will hopefully support multiple
ATL requests.

BFN. Paul.





---In H390-***@yahoogroups.com, <***@...> wrote :

Tachyon is commercial software.

Joe


On Sun, Apr 2, 2017 at 6:56 PM, ***@... mailto:***@... [H390-MVS] <H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com> wrote:
---In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com, <***@...> wrote :

> It is Tachyon that runs out of memory,

So what we need is for Tachyon to
be recompiled with the latest
GCC/PDPCLIB so that when
MVS/380 starts supporting multiple
ATL requests, Tachyon can do
large assemblies on that platform.

BFN. Paul.

[[e-mail] [H390-MVS]]

Hi Paul,
To answer your question first an extract of my post 9088 of June 11, 2015 on Yahoo Turnkey-MVS:


“

The code for the assembler referred to as IFOX00 is carefully divided into two components. The IFO prefixed modules deal with all the interaction with MVS for program management, storage management and I/O. The actual modules that perform the assembly processing are prefixed IFN. It is these IFN modules that, with an appropriate DOS/VS equivalent of the IFO modules, would have been the DOS/VS assembler
.”.


The modules that interface to MVS are IFOX0A through to IFOX0J. There are also a number of macros (JCOMMON etc) that generate or contain the parameter lists that get passed from the IFN to the IFO modules and back. As you would expect the hi-order byte on some parameter words were used for flags.



It is the IFO modules that have all the program interfaces, memory management and I/O interfaces to MVS including DCBs, DECBs etc. Getting this to run in 31 bit mode while remaining compatible with 24 bit MVS would take some work and code that recognized what mode it was running and changed paths accordingly.
Getting the actual assembler IFN modules to run in 31 bit mode would be more difficult with lots more work because of the extensive use of flag bytes in the hi-order byte of address words in its various record formats.
From my testing of the current IFOX00 assembler there is very little to be gained, if anything at all, in allocating increased memory above 1M. This is because the code was designed to run in small partition sizes (a VS/1 legacy) and makes extensive use of I/O for storing the dictionary and the assembler code being processed through the phases. There is no doubt that the whole dictionary storage and work file processing design for IFOX00 would benefit from a redesign to improve performance and use more storage effectively to reduce I/O processing.



So in summary, without reworking the dictionary and work file logic to take advantage of a larger storage model there would little or no benefit in undertaking the work to convert the IFO/IFN modules to use 31 bit addressing.


Of immediate greater use for everyone would be an assembler that provided many of the very useful enhancements now available in HLASM such as dependent and named USINGs, more builtin functions and support for 20 bit signed displacement addressing now that Juergen has enabled so many of the new opcodes in TK4-.



I have been working on these enhancements for some time but then left it while I completed another project. I will return to the assembler refurbishment project soon.



Without preempting Gerhard’s reply to your question I think you will find that Gerhard experienced storage problems using the Tachyon Legacy assembler. Its storage management model is quite poor when significant macro processing is involved in an assembly. I have experienced the same problem where a region of 6 MB was insufficient to complete an assembly with extensive macro usage. The same assembly completed successfully with IFOX00 in 512 KB albeit with lots of work file I/O.


Regards
Tom

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> From my testing of the current IFOX00
> assembler there is very little to be gained,
> if anything at all, in allocating increased
> memory above 1M.

Understood. So request dropped, but I
still have a question on the theory.

> MVS including DCBs, DECBs etc. Getting
> this to run in 31 bit mode while remaining
> compatible with 24 bit MVS would take
> some work and code that recognized what
> mode it was running and changed paths accordingly.

Why do you think different code paths
are required for 24-bit vs 31-bit
execution?

All the ANY/ANY modules I produce have
identical code paths. The only exception
is where if the module is seen to be
residing ATL then a stub for the DCB
OPEN exit is inserted.

> support for 20 bit signed displacement
> addressing now that Juergen has
> enabled so many of the new opcodes in TK4-.

I'm not familiar with what he has opened
up, but I would like instructions like STG
to work properly. From memory the STG
macro fails to use the index register, and
generates a warning about that, so I had
to use STMG instead.

BFN. Paul.

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
- - - beginning and old note snipped - - -
> I'm not familiar with what he has opened
>up, but I would like instructions like STG
>to work properly. From memory the STG
>macro fails to use the index register, and
>generates a warning about that, so I had
>to use STMG instead.
> BFN. Paul.

The index register is not an issue.
The MACRO could have handled that.

The issue is the displacement is split,
is 20 bits long and and it expects a
half meg back and half meg forward
USING domain.

If all code hard-coded the displacement
number of -524288 to +524287 there would
be no issue but most people let the
assembler determine the displacement of
0 to 4095.

Of course 0 to 4095 is all you need and
that could be supplied by just adding the
instruction and instruction type to IFOX00

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> Of course 0 to 4095 is all you need and
> that could be supplied by just adding the
> instruction and instruction type to IFOX00

Ok, I don't really understand the
issue, but I just want to reaffirm
that I don't need a perfect z/Arch
compliant STG. I am happy for
STG to have the same restriction
on displacement (ie 0 to 4095)
that ST has.

I just want to have a simple upgrade
from 31-bit to 64-bit programming
(note that Hercules/380 + MVS 3.8j
allows both 31-bit and 64-bit
programming).

BFN. Paul.

[[e-mail] [H390-MVS]]

Hi Paul,
When you mentioned running in 31 bit mode I assumed that you were referring to fully embracing running in either 24 bit MVS 3.8 or 31 bit with a more recent OS. In your posting you identified one reason why there are different code paths. I am sure that there are others as well if z/OS features are fully utilized.



On the issue of using macros to generate newer opcodes not known to IFOX00 the expert in this area is Shelby Beach. Shelby has done a very thorough and excellent job of providing a series of macros that support all the advanced opcodes so that IFOX00 can generate code for their use. Her macro library is distributed as part of Juergen’s TK4- distribution.


As you would expect with these macros from Shelby, a 20 bit signed displacement instruction can be generated but only with a 12 bit positive displacement. It is not possible to calculate and then generate 20 bit signed displacements with the level of macro language provided with IFOX00. I would consider being able to fully use 20 bit signed displacement instructions as very useful in refurbishing old code. So often I find myself up against the 12 bit displacement limit and without a spare register to use to extend the addressability. The combined issues of trying to comprehend old spaghetti logic code and working out how to gain addressability for additional instructions adds a great deal of complexity to a refurbishment job.


I suggest use of Shelby Beach’s macro library as some of the other macro libraries, including the macro library I created, contain errors and lack some instructions.
Regards
Tom

['Shelby Beach' [e-mail] [H390-MVS]]

Hi Tom, et. al.,

I just want to clarify one additional thing... neither the macros nor any of
the additional instructions provided by the Hercules emulator included in
TK4- support the use of the grande (64-bit) registers. The additional
instructions consist of those originally provided by the Hercules S37X
module, which has been extended and significantly cleaned up in TK4-. S37X
provides additional, non-64 bit instructions when running in S/370 mode,
hence no grande registers.

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Sunday, April 02, 2017 8:22 PM
To: H390-***@yahoogroups.com
Subject: [H390-MVS] Re: IFOX assembler source troubles





Hi Paul,

When you mentioned running in 31 bit mode I assumed that you were referring
to fully embracing running in either 24 bit MVS 3.8 or 31 bit with a more
recent OS. In your posting you identified one reason why there are different
code paths. I am sure that there are others as well if z/OS features are
fully utilized.





On the issue of using macros to generate newer opcodes not known to IFOX00
the expert in this area is Shelby Beach. Shelby has done a very thorough and
excellent job of providing a series of macros that support all the advanced
opcodes so that IFOX00 can generate code for their use. Her macro library is
distributed as part of Juergen's TK4- distribution.




As you would expect with these macros from Shelby, a 20 bit signed
displacement instruction can be generated but only with a 12 bit positive
displacement. It is not possible to calculate and then generate 20 bit
signed displacements with the level of macro language provided with IFOX00.
I would consider being able to fully use 20 bit signed displacement
instructions as very useful in refurbishing old code. So often I find myself
up against the 12 bit displacement limit and without a spare register to use
to extend the addressability. The combined issues of trying to comprehend
old spaghetti logic code and working out how to gain addressability for
additional instructions adds a great deal of complexity to a refurbishment
job.




I suggest use of Shelby Beach's macro library as some of the other macro
libraries, including the macro library I created, contain errors and lack
some instructions.

Regards

Tom

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
> Hi Tom, et. al.,
> I just want to clarify one additional thing... neither the macros nor any of the
>additional instructions provided by the Hercules emulator included in TK4-
>support the use of the grande (64-bit) registers. The additional instructions
>consist of those originally provided by the Hercules S37X module, which
>has been extended and significantly cleaned up in TK4-. S37X provides
>additional, non-64 bit instructions when running in S/370 mode, hence no
>grande registers.
> Shelby
- - - old notes snipped - - -

The issue is not with Hercules or S/370-24bit.

Hercules has the 64bit registers already.

The issue are:

SYS1.ZMACLIB did not bother to support index registers for
STG type instructors ( Rxy )..
It also uses the index register spot in the generated code for
the base so won't generate identical code as HLASM.

IFOX00 MACRO language has no facility to generate 20bit
displacements or I don't know how to code it.

IFOX00 source, aka spaghetti code, could handle 20bit
displacement but without proper source, it could be
difficult. MACROs to build IFOX00 are not even shipped
when updated.
The long-displacement instructions could be done with the old
IBM supplied source and then copied to the disassembled
source and the updated MACROs.

[[e-mail] [H390-MVS]]

- - - all snipped - - -

It may not be 100% accurate, but here is an old list of Rxy instructions needed.

https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/11390

IBM may have added more?

There are plenty of other instructions with other formats needed.

['Shelby Beach' [e-mail] [H390-MVS]]

somitcw,

Yes Hercules has 64-but regs, but they are not useable in 370 mode. The only
reason I brought this up was in response to Tom's note; I didn't want the
issue to become further confused. Paul (and you) keep mentioning the STG
instruction. I wanted to make it clear that the macros I was supplying did
not support 64-bit regs. Additionally, I am talking about SYS2.SXMACLIB
(shipped with TK4-). There were numerous issues with ZMACLIB. I fixed the
ones that I could (but not 20 bit displacements). If there is some problem
with the generated code (i.e. index/base reg confusion) in SXMACLIB, report
it and I will try to fix it.

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Monday, April 03, 2017 1:17 AM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles




- - - In H390-***@yahoogroups.com, <***@...> wrote:
> Hi Tom, et. al.,
> I just want to clarify one additional thing... neither the macros nor any
of the
>additional instructions provided by the Hercules emulator included in TK4-
>support the use of the grande (64-bit) registers. The additional
instructions
>consist of those originally provided by the Hercules S37X module, which
>has been extended and significantly cleaned up in TK4-. S37X provides
>additional, non-64 bit instructions when running in S/370 mode, hence no
>grande registers.
> Shelby
- - - old notes snipped - - -

The issue is not with Hercules or S/370-24bit.

Hercules has the 64bit registers already.

The issue are:

SYS1.ZMACLIB did not bother to support index registers for
STG type instructors ( Rxy )..
It also uses the index register spot in the generated code for
the base so won't generate identical code as HLASM.

IFOX00 MACRO language has no facility to generate 20bit
displacements or I don't know how to code it.

IFOX00 source, aka spaghetti code, could handle 20bit
displacement but without proper source, it could be
difficult. MACROs to build IFOX00 are not even shipped
when updated.
The long-displacement instructions could be done with the old
IBM supplied source and then copied to the disassembled
source and the updated MACROs.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> Yes Hercules has 64-but regs, but they are
> not useable in 370 mode.

That is true of base Hercules, and
also Juergen's version, but not
Hercules/380.

It is because Hercules/380 supports
64-bit registers and memory in 370
mode that I am interested in the
STG and STMG etc etc macros.

I think I will just take what is in
ZMACLIB (which includes STG)
and then overwrite it with your
macro library, so that any mods
you have are made available,
without losing instructions that
are not supplied in your maclib.

BFN. Paul.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> I think I will just take what is in
> ZMACLIB (which includes STG)
> and then overwrite it with your
> macro library, so that any mods
> you have are made available,
> without losing instructions that
> are not supplied in your maclib.

Although that doesn't leave me any
better off than I am already.

My hope is that STG will be implemented
in either some macro or in Tom's direct
changes to IFOX. Even if STG isn't
implemented perfectly, I will be happy
enough if, like ST, it supports both
base and index, and also a displacement
of 0-4095.

Rome can be built another day.

BFN. Paul.

['Shelby Beach' [e-mail] [H390-MVS]]

Paul,

There is nothing magical about the STG instruction format. In fact, it is
identical to the STY instruction format which is supported by my macros.
Change the extended opcode byte and you get STG ! I suspect this is true for
many of the other instructions you are interest in. Of course you'll have to
live with the 12 bit displacement.

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Monday, April 03, 2017 1:43 PM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles




---In H390-***@yahoogroups.com, <***@...> wrote :

> I think I will just take what is in
> ZMACLIB (which includes STG)
> and then overwrite it with your
> macro library, so that any mods
> you have are made available,
> without losing instructions that
> are not supplied in your maclib.

Although that doesn't leave me any
better off than I am already.

My hope is that STG will be implemented
in either some macro or in Tom's direct
changes to IFOX. Even if STG isn't
implemented perfectly, I will be happy
enough if, like ST, it supports both
base and index, and also a displacement
of 0-4095.

Rome can be built another day.

BFN. Paul.

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
> Paul,
> There is nothing magical about the STG instruction format. In fact,
>it is identical to the STY instruction format which is supported by
>my macros. Change the extended opcode byte and you get STG !
>I suspect this is true for many of the other instructions you are
>interest in. Of course you'll have to live with the 12 bit displacement.
> Shelby
- - - old note snipped - - -

If you have a working RXY like STY, it can be cloned to cover the
other Rxy instructions.

If going with 12bit displacements, then RXE and RXY are identical.
So are RSE and RSY.

For a RXY list, see:

https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/11390

Other instruction lists are needed for RXE, RSE, and RSY.

['Shelby Beach' [e-mail] [H390-MVS]]

OK everyone,

This is getting ridiculous with all the conjecturing. Here is a link to a
spreadsheet listing all 330+ additional instructions supported by my macros
and TK4- Hercules (if S37X has been loaded):
https://www.dropbox.com/s/xt2ao2t4p3cpsms/S37X%20Instructions.xls?dl=0

Note that in addition to these instructions, there are macros for all the
required extended mnemonics for the likes of LOC, STOC, J (BRC), etc.

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Monday, April 03, 2017 5:16 PM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles




- - - In H390-***@yahoogroups.com, <***@...> wrote:
> Paul,
> There is nothing magical about the STG instruction format. In fact,
>it is identical to the STY instruction format which is supported by
>my macros. Change the extended opcode byte and you get STG !
>I suspect this is true for many of the other instructions you are
>interest in. Of course you'll have to live with the 12 bit displacement.
> Shelby
- - - old note snipped - - -

If you have a working RXY like STY, it can be cloned to cover the
other Rxy instructions.

If going with 12bit displacements, then RXE and RXY are identical.
So are RSE and RSY.

For a RXY list, see:

https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/11
390

Other instruction lists are needed for RXE, RSE, and RSY.

[Tony Harminc [e-mail] [H390-MVS]]

On 3 April 2017 at 16:33, ***@yahoo.com.au wrote:
> I think I will just take what is in
> ZMACLIB (which includes STG)
> and then overwrite it with your
> macro library, so that any mods
> you have are made available,
> without losing instructions that
> are not supplied in your maclib.

If Shelby's maclib fully supports RX instructions (yes, not including
long-displacement, but at least 12-bit with index regs), then it
should be simple to clone that support for things like STG.

Tony H.

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
- - - old note snipped - - -
> If Shelby's maclib fully supports RX instructions (yes, not including
>long-displacement, but at least 12-bit with index regs), then it
>should be simple to clone that support for things like STG.
> Tony H.

Yes, if the first Rxy format MACRO is written either with the
12bit displacement or the full 20bit displacement, cloning the
other 95 Rxy MACROs would be easy. Just change their
name and op-code.

But then, there are other formats:

many are old and don't need MACROs
( RR, RS, RX, SI, SS ).

Perhaps priority for:
RSE, RXE, RSY, and SIY with the two with a "Y"
for 20bit displacements.

Prin. of Op. says:

Basic Instruction Formats:

E denotes an operation using implied operands
and an extended op-code field.
I denotes an immediate operation.
IE denotes an immediate-and-immediate operation.
MII denotes a masked immediate-and-immediate
operation.
RI denotes a register-and-immediate operation
and an extended op-code field.
RIE denotes a register-and-immediate operation
and a longer extended op-code field.
RIL denotes a register-and-immediate operation,
an extended op-code field, and a longer
immediate field.
RIS denotes a register-and-immediate operation
and a storage operation.
RR denotes a register-and-register operation.
• RRD denotes a register-and-register operation,
an extended op-code field, and an additional R
field.
• RRE denotes a register-and-register operation
and an extended op-code field.
• RRF denotes a register-and-register operation,
an extended op-code field, and an additional R
field, M field, or both.
• RRS denotes a register-and-register operation
and a storage operation.
• RS denotes a register-and-storage operation.
• RSI denotes a register-and-immediate operation.
• RSL denotes a storage operation (with an
instruction format derived from the ESA/390 RSE
format).
• RSY denotes a register-and-storage operation,
an extended op-code field, and a long
displacement field.
• RX denotes a register-and-indexed-storage
operation.
• RXE denotes a register-and-indexed-storage
operation and an extended op-code field.
• RXF denotes a register-and-indexed-storage
operation, an extended op-code field, and an
additional R field.
• RXY denotes a register-and-indexed-storage
operation, an extended op-code field, and a long
displacement field.
• S denotes an operation using an implied operand
and storage.
• SI denotes a storage-and-immediate operation.
• SIL denotes a storage-and-immediate operation,
with a 16-bit immediate field.
• SIY denotes a storage-and-immediate operation
and a long displacement field.
• SMI denotes a masked storage-and-immediate
operation.
• SS denotes a storage-and-storage operation.
• SSE denotes a storage-and-storage operation
and an extended op-code field.
• SSF denotes a storage-and-storage operation
and an extended op-code field.
• VRI denotes a vector register-and-immediate
operation and an extended op-code field.
• VRR denotes a vector register-and-register
operation and an extended op-code field.
• VRS denotes a vector register-and-storage
operation and an extended op-code field.
• VRV denotes a vector register-and-vector-index-
storage operation and an extended op-code field.
• VRX denotes a vector register-and-index-storage
operation and an extended op-code field.

Clean IFOX00 source and MACROs might allow
adding instructions without resorting to user MACROs
Difficult but much better in the long run.

['Shelby Beach' [e-mail] [H390-MVS]]

Hi Tony,

As I just pointed out, it is ridiculously simple ! In the case of STY to
STG, it's one byte !

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Monday, April 03, 2017 3:24 PM
To: H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Re: IFOX assembler source troubles




On 3 April 2017 at 16:33, ***@yahoo.com.au wrote:
> I think I will just take what is in
> ZMACLIB (which includes STG)
> and then overwrite it with your
> macro library, so that any mods
> you have are made available,
> without losing instructions that
> are not supplied in your maclib.

If Shelby's maclib fully supports RX instructions (yes, not including
long-displacement, but at least 12-bit with index regs), then it
should be simple to clone that support for things like STG.

Tony H.

[[e-mail] [H390-MVS]]

Hi Shelby.

Could you send me STY so that I
can try to get STG working?

Thanks. Paul.




---In H390-***@yahoogroups.com, <***@...> wrote :

Hi Tony,

As I just pointed out, it is ridiculously simple ! In the case of STY to STG, it's one byte !

Shelby



From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Monday, April 03, 2017 3:24 PM
To: H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Re: IFOX assembler source troubles



On 3 April 2017 at 16:33, ***@... wrote:
> I think I will just take what is in
> ZMACLIB (which includes STG)
> and then overwrite it with your
> macro library, so that any mods
> you have are made available,
> without losing instructions that
> are not supplied in your maclib.

If Shelby's maclib fully supports RX instructions (yes, not including
long-displacement, but at least 12-bit with index regs), then it
should be simple to clone that support for things like STG.

Tony H.

[[e-mail] [H390-MVS]]

Hi Shelby.

I revisited the code that I am trying
to run. Here it is:

SAM64
LG R4,BIGADDR
LG R5,BIGVAL
STG R5,0(R4)
LOOP B LOOP
DS 0D
BIGADDR DC X'0000000140000000'
BIGVAL DC X'F3F3F3F4F4F4F5F5'


And I was surprised to find that the code
does in fact work:

22:23:38 r 140000000
22:23:38 R:140000000:K:00=F3F3F3F4 F4F4F5F5 00000000 00000000 33344455........
22:23:38 R:140000010:K:00=00000000 00000000 00000000 00000000 ................
22:23:38 R:140000020:K:00=00000000 00000000 00000000 00000000 ................
22:23:38 R:140000030:K:00=00000000 00000000 00000000 00000000 ................


The only problem is that I get
warnings from the macros LG
and STG:

ASSEMBLER (XF) DONE
171 LG R4,BIGADDR
172+ 4,RXE FORMAT INCOMPLETE, NO INDEX REGISTER ASSIGNED
IFO197 *** MNOTE ***
175 LG R5,BIGVAL
176+ 4,RXE FORMAT INCOMPLETE, NO INDEX REGISTER ASSIGNED
IFO197 *** MNOTE ***
179 STG R5,0(R4)
180+ 4,RXE FORMAT INCOMPLETE, NO INDEX REGISTER ASSIGNED
IFO197 *** MNOTE ***


And I confirmed that making this code change
(plus irrelevant whitespace change):

STG R5,0(,R4)

gives this error:

178 STG R5,0(,R4)
181+ DC 0XL6'00',X'E3',AL.4(R5,0),S(0(,R4)),X'0024'
IFO234 PREMATURE END OF EXPRESSION NEAR OPERAND COLUMN 31


This also fails:

178 STG R5,0(R0,R4)
181+ DC 0XL6'00',X'E3',AL.4(R5,0),S(0(R0,R4)),X'0024'
IFO178 SYNTAX ERROR NEAR OPERAND COLUMN 35


I'm tempted to just change the MNOTE
value to 0 in both LG and STG, since the
macros actually works for my purposes.

But it would be good if the index
register actually worked so that
people weren't caught off-guard.

BFN. Paul.




---In H390-***@yahoogroups.com, <***@...> wrote :

Hi Shelby.

Could you send me STY so that I
can try to get STG working?

Thanks. Paul.




---In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com, <***@...> wrote :

Hi Tony,

As I just pointed out, it is ridiculously simple ! In the case of STY to STG, it's one byte !

Shelby



From: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com]
Sent: Monday, April 03, 2017 3:24 PM
To: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Re: IFOX assembler source troubles



On 3 April 2017 at 16:33, ***@... wrote:
> I think I will just take what is in
> ZMACLIB (which includes STG)
> and then overwrite it with your
> macro library, so that any mods
> you have are made available,
> without losing instructions that
> are not supplied in your maclib.

If Shelby's maclib fully supports RX instructions (yes, not including
long-displacement, but at least 12-bit with index regs), then it
should be simple to clone that support for things like STG.

Tony H.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> I'm tempted to just change the MNOTE
> value to 0 in both LG and STG, since the
> macros actually works for my purposes.

Actually, they don't quite work for
my purposes because they swap
base and index compared to a
proper z/OS assembler, I believe.

So they are functionally equivalent,
but I don't like the idea of generating
non-standard hex.

BFN. Paul.

[Gerhard Postpischil [e-mail] [H390-MVS]]

On 4/4/2017 9:35 AM, ***@yahoo.com.au [H390-MVS] wrote:
> Actually, they don't quite work for
> my purposes because they swap
> base and index compared to a
> proper z/OS assembler, I believe.
>
> So they are functionally equivalent,
> but I don't like the idea of generating
> non-standard hex.
They're functionally equivalent unless you're in access register mode;
do you plan to add that to S/370/380 ? <g>


Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

['Shelby Beach' [e-mail] [H390-MVS]]

Paul,

You are using some really, really old macros. That error has long ago been
fixed. I'll send you what I have for STY offline in a couple of hours (I'm
in the middle of something else right now).

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Tuesday, April 04, 2017 5:48 AM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles




Hi Shelby.

I revisited the code that I am trying
to run. Here it is:

SAM64
LG R4,BIGADDR
LG R5,BIGVAL
STG R5,0(R4)
LOOP B LOOP
DS 0D
BIGADDR DC X'0000000140000000'
BIGVAL DC X'F3F3F3F4F4F4F5F5'

And I was surprised to find that the code
does in fact work:

22:23:38 r 140000000
22:23:38 R:140000000:K:00=F3F3F3F4 F4F4F5F5 00000000 00000000
33344455........
22:23:38 R:140000010:K:00=00000000 00000000 00000000 00000000
................
22:23:38 R:140000020:K:00=00000000 00000000 00000000 00000000
................
22:23:38 R:140000030:K:00=00000000 00000000 00000000 00000000
................

The only problem is that I get
warnings from the macros LG
and STG:

ASSEMBLER (XF) DONE
171 LG R4,BIGADDR
172+ 4,RXE FORMAT INCOMPLETE, NO INDEX REGISTER ASSIGNED
IFO197 *** MNOTE ***
175 LG R5,BIGVAL
176+ 4,RXE FORMAT INCOMPLETE, NO INDEX REGISTER ASSIGNED
IFO197 *** MNOTE ***
179 STG R5,0(R4)
180+ 4,RXE FORMAT INCOMPLETE, NO INDEX REGISTER ASSIGNED
IFO197 *** MNOTE ***

And I confirmed that making this code change
(plus irrelevant whitespace change):

STG R5,0(,R4)

gives this error:

178 STG R5,0(,R4)
181+ DC 0XL6'00',X'E3',AL.4(R5,0),S(0(,R4)),X'0024'
IFO234 PREMATURE END OF EXPRESSION NEAR OPERAND COLUMN 31

This also fails:

178 STG R5,0(R0,R4)
181+ DC 0XL6'00',X'E3',AL.4(R5,0),S(0(R0,R4)),X'0024'
IFO178 SYNTAX ERROR NEAR OPERAND COLUMN 35

I'm tempted to just change the MNOTE
value to 0 in both LG and STG, since the
macros actually works for my purposes.

But it would be good if the index
register actually worked so that
people weren't caught off-guard.

BFN. Paul.

---In H390-***@yahoogroups.com, <***@...> wrote :

Hi Shelby.

Could you send me STY so that I
can try to get STG working?

Thanks. Paul.




---In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com,
<***@...> wrote :

Hi Tony,

As I just pointed out, it is ridiculously simple ! In the case of STY to
STG, it's one byte !

Shelby



From: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com
[mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com]
Sent: Monday, April 03, 2017 3:24 PM
To: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Re: IFOX assembler source troubles



On 3 April 2017 at 16:33, ***@... wrote:
> I think I will just take what is in
> ZMACLIB (which includes STG)
> and then overwrite it with your
> macro library, so that any mods
> you have are made available,
> without losing instructions that
> are not supplied in your maclib.

If Shelby's maclib fully supports RX instructions (yes, not including
long-displacement, but at least 12-bit with index regs), then it
should be simple to clone that support for things like STG.

Tony H.

['Shelby Beach' [e-mail] [H390-MVS]]

No Paul,

What was fixed was the MNOTE re. no index reg. That error (restriction)
crossed dozens of macros. I've said before there is no grande reg support in
the macros, so there is no LG, STG, or *G whatever macro !

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Tuesday, April 04, 2017 10:25 AM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles




Hi Shelby.

If LG and STG have already been fixed,
then there's no need to send me STY.

I will get the working LG and STG when
I upgrade to TK4-.

I don't wish to write 64-bit programs
right now. I will try again after I've
upgraded.

Thanks. Paul.

---In H390-***@yahoogroups.com, <***@...> wrote :

Paul,

You are using some really, really old macros. That error has long ago been
fixed. I'll send you what I have for STY offline in a couple of hours (I'm
in the middle of something else right now).

Shelby


From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Tuesday, April 04, 2017 5:48 AM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles

Hi Shelby.

I revisited the code that I am trying
to run. Here it is:

SAM64
LG R4,BIGADDR
LG R5,BIGVAL
STG R5,0(R4)
LOOP B LOOP
DS 0D
BIGADDR DC X'0000000140000000'
BIGVAL DC X'F3F3F3F4F4F4F5F5'

And I was surprised to find that the code
does in fact work:

22:23:38 r 140000000
22:23:38 R:140000000:K:00=F3F3F3F4 F4F4F5F5 00000000 00000000
33344455........
22:23:38 R:140000010:K:00=00000000 00000000 00000000 00000000
................
22:23:38 R:140000020:K:00=00000000 00000000 00000000 00000000
................
22:23:38 R:140000030:K:00=00000000 00000000 00000000 00000000
................

The only problem is that I get
warnings from the macros LG
and STG:

ASSEMBLER (XF) DONE
171 LG R4,BIGADDR
172+ 4,RXE FORMAT INCOMPLETE, NO INDEX REGISTER ASSIGNED
IFO197 *** MNOTE ***
175 LG R5,BIGVAL
176+ 4,RXE FORMAT INCOMPLETE, NO INDEX REGISTER ASSIGNED
IFO197 *** MNOTE ***
179 STG R5,0(R4)
180+ 4,RXE FORMAT INCOMPLETE, NO INDEX REGISTER ASSIGNED
IFO197 *** MNOTE ***

And I confirmed that making this code change
(plus irrelevant whitespace change):

STG R5,0(,R4)

gives this error:

178 STG R5,0(,R4)
181+ DC 0XL6'00',X'E3',AL.4(R5,0),S(0(,R4)),X'0024'
IFO234 PREMATURE END OF EXPRESSION NEAR OPERAND COLUMN 31

This also fails:

178 STG R5,0(R0,R4)
181+ DC 0XL6'00',X'E3',AL.4(R5,0),S(0(R0,R4)),X'0024'
IFO178 SYNTAX ERROR NEAR OPERAND COLUMN 35

I'm tempted to just change the MNOTE
value to 0 in both LG and STG, since the
macros actually works for my purposes.

But it would be good if the index
register actually worked so that
people weren't caught off-guard.

BFN. Paul.

---In H390-***@yahoogroups.com, <***@...> wrote :

Hi Shelby.

Could you send me STY so that I
can try to get STG working?

Thanks. Paul.

---In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com,
<***@...> wrote :

Hi Tony,

As I just pointed out, it is ridiculously simple ! In the case of STY to
STG, it's one byte !

Shelby

From: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com
[mailto:H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com]
Sent: Monday, April 03, 2017 3:24 PM
To: H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Re: IFOX assembler source troubles

On 3 April 2017 at 16:33, ***@... wrote:
> I think I will just take what is in
> ZMACLIB (which includes STG)
> and then overwrite it with your
> macro library, so that any mods
> you have are made available,
> without losing instructions that
> are not supplied in your maclib.

If Shelby's maclib fully supports RX instructions (yes, not including
long-displacement, but at least 12-bit with index regs), then it
should be simple to clone that support for things like STG.

Tony H.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> What was fixed was the MNOTE re. no index reg.

Ok, what about the fact that the
hex that is generated is different
from what z/OS produces? ie
base and index are swapped.

> I've said before there is no grande
> reg support in the macros,

I'm confused by what you're calling
"the macros".

The macros that I use, from sys1.zmaclib
from memory, DO have grande support.

> so there is no LG, STG, or *G whatever macro !

If LG and STG have been fixed to
assemble the code that I showed
you previously, generating correct
hex, that is all I am interested in.

If the latest zmaclib with the latest
LG & STG still produce bad hex,
then I'm interested in your STY
so that it can be modified to
produce an LG and STG that
generate correct hex.

BFN. Paul.

['Shelby Beach' [e-mail] [H390-MVS]]

Paul,

There is no *fixed* ZMACLIB. That thing is ancient. The new macro library is
SXMACLIB. I suspect that if you try it, STY in ZMACLIB will give you the
same error as STG. The macros in SXMACLIB generate correct code. The index
and base registers are not screwed up !

BTW, you mentioned waiting for the next TK4- update. If you have the most
recently released TK4-, you have the current SYS2.SXMACLIB. You can take STY
from there and easily make an STG.

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Tuesday, April 04, 2017 10:43 AM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles




---In H390-***@yahoogroups.com, <***@...> wrote :

> What was fixed was the MNOTE re. no index reg.

Ok, what about the fact that the
hex that is generated is different
from what z/OS produces? ie
base and index are swapped.

> I've said before there is no grande
> reg support in the macros,

I'm confused by what you're calling
"the macros".

The macros that I use, from sys1.zmaclib
from memory, DO have grande support.

> so there is no LG, STG, or *G whatever macro !

If LG and STG have been fixed to
assemble the code that I showed
you previously, generating correct
hex, that is all I am interested in.

If the latest zmaclib with the latest
LG & STG still produce bad hex,
then I'm interested in your STY
so that it can be modified to
produce an LG and STG that
generate correct hex.

BFN. Paul.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> There is no *fixed* ZMACLIB.

Ok, thanks for the clarification.

> The macros in SXMACLIB generate
> correct code. The index and base
> registers are not screwed up !

Ok, then once again I am interested
in your STY so that I can convert
it into STG. So please email that to
me when you get a chance.

> BTW, you mentioned waiting for
> the next TK4- update.

No, I am waiting *to* update to
*any* version of TK4-.

> If you have the most recently released TK4-

I am using an old version of MVS/380,
which was not based on TK4-.

I will upgrade MVS/380 to be based
on the latest TK4- when I have all
the technology I need.

There's one bit of technology I am
waiting on - multiple ATL GETMAINs.

BFN. Paul.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

Shelby, thanks a lot for the STY and E3OP
macros. Using them I was able to construct
and test LG and STG macros and they all
work great with no warnings. I checked that
base + index went into what seemed to be
the right locations too.

All have been uploaded here:
https://groups.yahoo.com/neo/groups/hercules-os380/files/mac64.zip

And reproduced below too.

Note that I was able to identify the
opcode changes required by looking
at the old macro expansions.

BFN. Paul.



C:\scratch>type stg.txt
MACRO
&LABEL STG &R1,&BXD
.*
.* Generate Opcode in IFOX00
.*
&LABEL E3OP &R1,&BXD,24
MEND

C:\scratch>type lg.txt
MACRO
&LABEL LG &R1,&BXD
.*
.* Generate Opcode in IFOX00
.*
&LABEL E3OP &R1,&BXD,04
MEND

C:\scratch>type sty.txt
MACRO
&LABEL STY &R1,&BXD
.*
.* Generate Opcode in IFOX00
.*
&LABEL E3OP &R1,&BXD,50
MEND

C:\scratch>type e3op.txt
MACRO
&LABEL E3OP &R,&BXD,&SUBOP
.*
.* Generate E3 Opcodes in IFOX00
.*
DS 0H
&LABEL DC 0XL6'00' Set Instruction Length of 6
AIF ('&SUBOP' EQ '3E').GENST STRV Opcode ?
AIF ('&SUBOP' EQ '3F').GENST STRVH Opcode ?
.*
.* Use IC opcode to generate Base and Index Registers and
.* DL Displacement for E3 Load instructions
.*
IC &R,&BXD OpCode overwritten to E3
AGO .GENE3
.*
.* Use STC opcode to generate Base and Index Registers and
.* DL Displacement for E3 Store instructions
.*
.GENST ANOP
STC &R,&BXD Opcode overwritten to E3
.GENE3 ANOP
.*
.* Org back to reset the Opcode to E3
.*
ORG *-4
DC X'E3' Opcode set to E3
.*
.* Zero DH and set Sub Opcode
.*
ORG *+3
DC X'00',X'&SUBOP'
MEND

C:\scratch>

[[e-mail] [H390-MVS]]

And for good measure, here is
my code:

SAM64
LG R4,BIGADDR
LG R5,BIGVAL
STG R5,0(,R4)
LOOP B LOOP
DS 0D
BIGADDR DC X'0000000140000000'
BIGVAL DC X'F3F3F3F4F4F4F5F5'


and here is the expansion:

167 SAM64
0000B4 168+ DS 0H
0000B4 010E 169+ DC 0XL2'00',X'010E'
170 LG R4,BIGADDR
0000B6 171+ DS 0H
0000B6 172+ DC 0XL6'00' Set Instruction Length of 6
0000B6 4340 A0C8 000D0 173+ IC R4,BIGADDR OpCode overwritten to E3
0000BA 000B6 174+ ORG *-4
0000B6 E3 175+ DC X'E3' Opcode set to E3
0000B7 000BA 176+ ORG *+3
0000BA 0004 177+ DC X'00',X'04'
178 LG R5,BIGVAL
0000BC 179+ DS 0H
0000BC 180+ DC 0XL6'00' Set Instruction Length of 6
0000BC 4350 A0D0 000D8 181+ IC R5,BIGVAL OpCode overwritten to E3
0000C0 000BC 182+ ORG *-4
0000BC E3 183+ DC X'E3' Opcode set to E3
0000BD 000C0 184+ ORG *+3
0000C0 0004 185+ DC X'00',X'04'
186 STG R5,0(,R4)
0000C2 187+ DS 0H
0000C2 188+ DC 0XL6'00' Set Instruction Length of 6
0000C2 4350 4000 00000 189+ IC R5,0(,R4) OpCode overwritten to E3
0000C6 000C2 190+ ORG *-4

0000C2 E3 191+ DC X'E3' Opcode set to E3
0000C3 000C6 192+ ORG *+3
0000C6 0024 193+ DC X'00',X'24'
0000C8 47F0 A0C0 000C8 194 LOOP B LOOP
0000D0 195 DS 0D
0000D0 0000000140000000 196 BIGADDR DC X'0000000140000000'
0000D8 F3F3F3F4F4F4F5F5 197 BIGVAL DC X'F3F3F3F4F4F4F5F5'


and here is the log excerpt:

06:58:22 20.58.22 JOB 1 PDPMVS PDPPRLG IEBGENER RC= 0000
06:58:22 20.58.22 JOB 1 PDPMVS PDPEPIL IEBGENER RC= 0000
06:58:23 20.58.23 JOB 1 PDPMVS MVSSTART ASM ASMA90 RC= 0000
06:58:24 20.58.24 JOB 1 PDPMVS MVSSTART LKED IEWL RC= 0004
06:58:30 20.58.30 JOB 1 PDPMVS MVSSUPA ASM ASMA90 RC= 0000
06:58:30 20.58.30 JOB 1 PDPMVS MVSSUPA LKED IEWL RC= 0000
06:58:30 20.58.30 JOB 1 PDPMVS START ASM ASMA90 RC= 0000
06:58:31 20.58.31 JOB 1 PDPMVS START LKED IEWL RC= 0004
06:58:33 20.58.33 JOB 1 PDPMVS STDIO ASM ASMA90 RC= 0000
06:58:33 r 140000000
06:58:33 R:140000000:K:00=00000000 00000000 00000000 00000000 ................
06:58:33 R:140000010:K:00=00000000 00000000 00000000 00000000 ................
06:58:33 R:140000020:K:00=00000000 00000000 00000000 00000000 ................
06:58:33 R:140000030:K:00=00000000 00000000 00000000 00000000 ................
06:58:33 20.58.33 JOB 1 PDPMVS STDIO LKED IEWL RC= 0004
06:58:34 20.58.34 JOB 1 PDPMVS STDLIB ASM ASMA90 RC= 0000
06:58:34 20.58.34 JOB 1 PDPMVS STDLIB LKED IEWL RC= 0004
06:58:35 20.58.35 JOB 1 PDPMVS CTYPE ASM ASMA90 RC= 0000
06:58:35 20.58.35 JOB 1 PDPMVS CTYPE LKED IEWL RC= 0000
06:58:36 20.58.36 JOB 1 PDPMVS STRING ASM ASMA90 RC= 0000
06:58:36 20.58.36 JOB 1 PDPMVS STRING LKED IEWL RC= 0000
06:58:37 20.58.37 JOB 1 PDPMVS TIME ASM ASMA90 RC= 0000
06:58:37 20.58.37 JOB 1 PDPMVS TIME LKED IEWL RC= 0004
06:58:38 20.58.38 JOB 1 PDPMVS ERRNO ASM ASMA90 RC= 0000
06:58:38 20.58.38 JOB 1 PDPMVS ERRNO LKED IEWL RC= 0000
06:58:38 20.58.38 JOB 1 PDPMVS ASSERT ASM ASMA90 RC= 0000
06:58:38 20.58.38 JOB 1 PDPMVS ASSERT LKED IEWL RC= 0004
06:58:39 20.58.39 JOB 1 PDPMVS LOCALE ASM ASMA90 RC= 0000
06:58:39 20.58.39 JOB 1 PDPMVS LOCALE LKED IEWL RC= 0004
06:58:40 20.58.40 JOB 1 PDPMVS MATH ASM ASMA90 RC= 0000
06:58:40 20.58.40 JOB 1 PDPMVS MATH LKED IEWL RC= 0004
06:58:40 20.58.40 JOB 1 PDPMVS SETJMP ASM ASMA90 RC= 0000
06:58:41 20.58.41 JOB 1 PDPMVS SETJMP LKED IEWL RC= 0004
06:58:41 20.58.41 JOB 1 PDPMVS SIGNAL ASM ASMA90 RC= 0000
06:58:41 20.58.41 JOB 1 PDPMVS SIGNAL LKED IEWL RC= 0004
06:58:42 20.58.42 JOB 1 PDPMVS @@MEMMGR ASM ASMA90 RC= 0000
06:58:42 20.58.42 JOB 1 PDPMVS @@MEMMGR LKED IEWL RC= 0004
06:58:43 20.58.43 JOB 1 PDPMVS PDPTEST ASM ASMA90 RC= 0000
06:58:43 20.58.43 JOB 1 PDPMVS PDPTEST LKED IEWL RC= 0004
06:58:43 20.58.43 JOB 1 PDPMVS LKED IEWL RC= 0000
06:58:47 r 140000000
06:58:47 R:140000000:K:00=F3F3F3F4 F4F4F5F5 00000000 00000000 33344455........
06:58:47 R:140000010:K:00=00000000 00000000 00000000 00000000 ................
06:58:47 R:140000020:K:00=00000000 00000000 00000000 00000000 ................
06:58:47 R:140000030:K:00=00000000 00000000 00000000 00000000 ................
06:58:51 /(001F) c pdpmvs
06:58:51 20.58.51 IEE301I PDPMVS CANCEL COMMAND ACCEPTED
06:58:51 20.58.51 JOB 1 IEF450I PDPMVS PDPTEST - ABEND S222 U0000 - TIME=20.58.51
06:58:51 20.58.51 JOB 1 PDPMVS PDPTEST PDPTEST AB S222


And I'm a very happy camper. :-)

BFN. Paul.

['Shelby Beach' [e-mail] [H390-MVS]]

>And I'm a very happy camper. :-)

Good !

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Tuesday, April 04, 2017 2:03 PM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles




And for good measure, here is
my code:

SAM64
LG R4,BIGADDR
LG R5,BIGVAL
STG R5,0(,R4)
LOOP B LOOP
DS 0D
BIGADDR DC X'0000000140000000'
BIGVAL DC X'F3F3F3F4F4F4F5F5'

and here is the expansion:

167 SAM64
0000B4 168+ DS 0H
0000B4 010E 169+ DC 0XL2'00',X'010E'
170 LG R4,BIGADDR
0000B6 171+ DS 0H
0000B6 172+ DC 0XL6'00' Set Instruction Length of 6
0000B6 4340 A0C8 000D0 173+ IC R4,BIGADDR OpCode overwritten to E3
0000BA 000B6 174+ ORG *-4
0000B6 E3 175+ DC X'E3' Opcode set to E3
0000B7 000BA 176+ ORG *+3
0000BA 0004 177+ DC X'00',X'04'
178 LG R5,BIGVAL
0000BC 179+ DS 0H
0000BC 180+ DC 0XL6'00' Set Instruction Length of 6
0000BC 4350 A0D0 000D8 181+ IC R5,BIGVAL OpCode overwritten to E3
0000C0 000BC 182+ ORG *-4
0000BC E3 183+ DC X'E3' Opcode set to E3
0000BD 000C0 184+ ORG *+3
0000C0 0004 185+ DC X'00',X'04'
186 STG R5,0(,R4)
0000C2 187+ DS 0H
0000C2 188+ DC 0XL6'00' Set Instruction Length of 6
0000C2 4350 4000 00000 189+ IC R5,0(,R4) OpCode overwritten to E3
0000C6 000C2 190+ ORG *-4

0000C2 E3 191+ DC X'E3' Opcode set to E3
0000C3 000C6 192+ ORG *+3
0000C6 0024 193+ DC X'00',X'24'
0000C8 47F0 A0C0 000C8 194 LOOP B LOOP
0000D0 195 DS 0D
0000D0 0000000140000000 196 BIGADDR DC X'0000000140000000'
0000D8 F3F3F3F4F4F4F5F5 197 BIGVAL DC X'F3F3F3F4F4F4F5F5'

and here is the log excerpt:

06:58:22 20.58.22 JOB 1 PDPMVS PDPPRLG IEBGENER RC= 0000
06:58:22 20.58.22 JOB 1 PDPMVS PDPEPIL IEBGENER RC= 0000
06:58:23 20.58.23 JOB 1 PDPMVS MVSSTART ASM ASMA90 RC= 0000
06:58:24 20.58.24 JOB 1 PDPMVS MVSSTART LKED IEWL RC= 0004
06:58:30 20.58.30 JOB 1 PDPMVS MVSSUPA ASM ASMA90 RC= 0000
06:58:30 20.58.30 JOB 1 PDPMVS MVSSUPA LKED IEWL RC= 0000
06:58:30 20.58.30 JOB 1 PDPMVS START ASM ASMA90 RC= 0000
06:58:31 20.58.31 JOB 1 PDPMVS START LKED IEWL RC= 0004
06:58:33 20.58.33 JOB 1 PDPMVS STDIO ASM ASMA90 RC= 0000
06:58:33 r 140000000
06:58:33 R:140000000:K:00=00000000 00000000 00000000 00000000
................
06:58:33 R:140000010:K:00=00000000 00000000 00000000 00000000
................
06:58:33 R:140000020:K:00=00000000 00000000 00000000 00000000
................
06:58:33 R:140000030:K:00=00000000 00000000 00000000 00000000
................
06:58:33 20.58.33 JOB 1 PDPMVS STDIO LKED IEWL RC= 0004
06:58:34 20.58.34 JOB 1 PDPMVS STDLIB ASM ASMA90 RC= 0000
06:58:34 20.58.34 JOB 1 PDPMVS STDLIB LKED IEWL RC= 0004
06:58:35 20.58.35 JOB 1 PDPMVS CTYPE ASM ASMA90 RC= 0000
06:58:35 20.58.35 JOB 1 PDPMVS CTYPE LKED IEWL RC= 0000
06:58:36 20.58.36 JOB 1 PDPMVS STRING ASM ASMA90 RC= 0000
06:58:36 20.58.36 JOB 1 PDPMVS STRING LKED IEWL RC= 0000
06:58:37 20.58.37 JOB 1 PDPMVS TIME ASM ASMA90 RC= 0000
06:58:37 20.58.37 JOB 1 PDPMVS TIME LKED IEWL RC= 0004
06:58:38 20.58.38 JOB 1 PDPMVS ERRNO ASM ASMA90 RC= 0000
06:58:38 20.58.38 JOB 1 PDPMVS ERRNO LKED IEWL RC= 0000
06:58:38 20.58.38 JOB 1 PDPMVS ASSERT ASM ASMA90 RC= 0000
06:58:38 20.58.38 JOB 1 PDPMVS ASSERT LKED IEWL RC= 0004
06:58:39 20.58.39 JOB 1 PDPMVS LOCALE ASM ASMA90 RC= 0000
06:58:39 20.58.39 JOB 1 PDPMVS LOCALE LKED IEWL RC= 0004
06:58:40 20.58.40 JOB 1 PDPMVS MATH ASM ASMA90 RC= 0000
06:58:40 20.58.40 JOB 1 PDPMVS MATH LKED IEWL RC= 0004
06:58:40 20.58.40 JOB 1 PDPMVS SETJMP ASM ASMA90 RC= 0000
06:58:41 20.58.41 JOB 1 PDPMVS SETJMP LKED IEWL RC= 0004
06:58:41 20.58.41 JOB 1 PDPMVS SIGNAL ASM ASMA90 RC= 0000
06:58:41 20.58.41 JOB 1 PDPMVS SIGNAL LKED IEWL RC= 0004
06:58:42 20.58.42 JOB 1 PDPMVS @@MEMMGR ASM ASMA90 RC= 0000
06:58:42 20.58.42 JOB 1 PDPMVS @@MEMMGR LKED IEWL RC= 0004
06:58:43 20.58.43 JOB 1 PDPMVS PDPTEST ASM ASMA90 RC= 0000
06:58:43 20.58.43 JOB 1 PDPMVS PDPTEST LKED IEWL RC= 0004
06:58:43 20.58.43 JOB 1 PDPMVS LKED IEWL RC= 0000
06:58:47 r 140000000
06:58:47 R:140000000:K:00=F3F3F3F4 F4F4F5F5 00000000 00000000
33344455........
06:58:47 R:140000010:K:00=00000000 00000000 00000000 00000000
................
06:58:47 R:140000020:K:00=00000000 00000000 00000000 00000000
................
06:58:47 R:140000030:K:00=00000000 00000000 00000000 00000000
................
06:58:51 /(001F) c pdpmvs
06:58:51 20.58.51 IEE301I PDPMVS CANCEL COMMAND ACCEPTED
06:58:51 20.58.51 JOB 1 IEF450I PDPMVS PDPTEST - ABEND S222 U0000 -
TIME=20.58.51
06:58:51 20.58.51 JOB 1 PDPMVS PDPTEST PDPTEST AB S222

And I'm a very happy camper. :-)

BFN. Paul.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :
>>And I'm a very happy camper. :-)
> Good !
> Shelby
- - - old notes snipped - - -

The STY and E3OP MACROs are excellent work but performance could
be improved.

1. Nesting MACROs is perfectly legal in assembler but coms at a
unbelievable cost.
Example, I had a CICS I/O table to generate and each MACRO had
several operands but only one changed from one MACRO to the next.
I created an outer MACRO to ease my coding.
Assembly time more than doubled.
I suggest that STY not call an inner MACRO.

2. LA X'41', not IC X'43' is the first RX instruction without a complication.
STH X'40' is earlier but has issues like half-word alignment.
Why not save the assembler lookup time.
Okay, it's just two instructions earlier and not used much.

3. A DC for six bytes that will all be overlaid is not required.
If really just to set a length, an EQU would be better.
If the STY instruction is unlabelled, no DC or EQU should be used.

I have seen a recommendation that ORG can set the location counter
too many levels back so LOCTR should be used instead but I don't
understand how ORG can mess up except for actually coding errors,
have used ORG since the end of the 1960s, and have never used LOCTR.
For now, I'll stick, with ORG.
We could add two "ORG ," statements? Opinions?

[Gerhard Postpischil [e-mail] [H390-MVS]]

On 4/5/2017 10:20 AM, ***@yahoo.com [H390-MVS] wrote:
> 1. Nesting MACROs is perfectly legal in assembler but coms at a
> unbelievable cost.
> Example, I had a CICS I/O table to generate and each MACRO had
> several operands but only one changed from one MACRO to the next.
> I created an outer MACRO to ease my coding.
> Assembly time more than doubled.
> I suggest that STY not call an inner MACRO.

I suspect you had a really awful inner macro. I use inner macros all the
time, with no noticable, but possibly measurable, performance hit.

> 2. LA X'41', not IC X'43' is the first RX instruction without a complication.
> STH X'40' is earlier but has issues like half-word alignment.
> Why not save the assembler lookup time.
> Okay, it's just two instructions earlier and not used much.

I haven't looked at it for years, but IFOX uses a hash table or
something similar, so alphabetic sequence has little relevance for
look-up time.

> I have seen a recommendation that ORG can set the location counter
> too many levels back so LOCTR should be used instead but I don't
> understand how ORG can mess up except for actually coding errors,
> have used ORG since the end of the 1960s, and have never used LOCTR.
> For now, I'll stick, with ORG.
IIRC, LOCTR was introduced with ASM h, and isn't in IFOX. It would make
a nice addition though.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
> On 4/5/2017 10:20 AM, ***@... mailto:***@... [H390-MVS] wrote:
>> 1. Nesting MACROs is perfectly legal in assembler but coms at a
>>unbelievable cost.
>> Example, I had a CICS I/O table to generate and each MACRO had
>>several operands but only one changed from one MACRO to the next.
>>I created an outer MACRO to ease my coding.
>>Assembly time more than doubled.
>>I suggest that STY not call an inner MACRO.
> I suspect you had a really awful inner macro. I use inner macros
>all the time, with no noticable, but possibly measurable,
>performance hit.

The inner MACROs were IBM written terminal defining MACROs
so may have been "awful" as you say.
The outer MACRO I added just supplied the terminal name and
address for the inner MACRO.
Think thousands of terminals on a S370/158 with 3330 and
3350 disks or a 4341 with 3375 disks.
SYSUT1 was beat to near death and duration went from
slow to more double in time.

Even with Hercules MIPS and superfast CCKD disks,
there is still a small effect.
Using small unnamed MACROs in place of complex
IBM terminal definition, the difference can be measured.
Less than 50% longer duration,
less than 50% more CPU time, and
less than 50% more I/O,
but it is still there:

1000 occurrences of single unnested MACRO
elapsed time 24:00:02,29
CPU time 00:00:01,62
SYSLIB 148.......1 ... 248.......1 ... 141.......2
SYSUT1 140....3974
SYSUT2 180......59
SYSUT3 170......38
VIRT 768K
SYS 280K
TOTAL RECORDS READ FROM SYSTEM INPUT 1032
TOTAL RECORDS READ FROM SYSTEM LIBRARY 26
TOTAL RECORDS PUNCHED 0
TOTAL RECORDS PRINTED 7538

1000 occurrences of outer MACRO with nested inner MACRO
elapsed time 24:00:03,13
CPU time 00:00:02,20
SYSLIB 148.......2 248.......2 141.......4
SYSUT1 140....5937
SYSUT2 180......53
SYSUT3 170......44
VIRT 768K
SYS 276K
TOTAL RECORDS READ FROM SYSTEM INPUT 1032
TOTAL RECORDS READ FROM SYSTEM LIBRARY 40
TOTAL RECORDS PUNCHED 0
TOTAL RECORDS PRINTED 8576

The 24 hour bug is probably from IEFACTRT ?

>> 2. LA X'41', not IC X'43' is the first RX instruction without a complication.
>> STH X'40' is earlier but has issues like half-word alignment.

Both LA and IC are wrong for an instruction that store in memory.
STC is best for memory storers and LA for others.

>> Why not save the assembler lookup time.
>> Okay, it's just two instructions earlier and not used much.
> I haven't looked at it for years, but IFOX uses a hash table or
>something similar, so alphabetic sequence has little relevance for
>look-up time.

The table is not in alphabetic sequence.
It's defined in op-code sequence.

It could somehow have a hidden sort and hash table, but I doubt it.

>> I have seen a recommendation that ORG can set the location counter
>>too many levels back so LOCTR should be used instead but I don't
>>understand how ORG can mess up except for actually coding errors,
>>have used ORG since the end of the 1960s, and have never used LOCTR.
>>For now, I'll stick, with ORG.
> IIRC, LOCTR was introduced with ASM h, and isn't in IFOX.
>It would make a nice addition though.
> Gerhard Postpischil
> Bradford, VT
> ---
>This email has been checked for viruses by AVG.
> http://www.avg.com http://www.avg.com

I don't remember ever using LOCTR.
I just found that I have been using ORG in an unsafe manner.
I learned assembler almost fifty years ago so the issue may
no longer be actionable. I don't even remember the instructor's
name, only that my assembler instructor was on the CoDaSyL
Committee but my CoBOL instructor was not.

['Shelby Beach' [e-mail] [H390-MVS]]

I'd like to make one additional comment with regards to the use of inner
macros. As you've demonstrated, there is some overhead involved. I'm not
sure that was ever in question. SXMACLIB contains roughly 500 macros in
support of the instructions provided by S37X. Most of those macros utilize a
single (and rarely two) inner macro calls. Even given cut and paste in an
editor, eliminating the inner macro references by copying the inner macro
code into each referencing macro is a bit of additional work. But... more
importantly, consider the maintenance issue. If an error needs to be
corrected (or an enhancement made), it's much easier to change one inner
macro, rather than the dozens of macros (or more) that the code was copied
into.

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Thursday, April 06, 2017 8:00 AM
To: H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Re: IFOX assembler source troubles




- - - In H390-***@yahoogroups.com, <***@...> wrote:
> On 4/5/2017 10:20 AM, ***@... mailto:***@... [H390-MVS] wrote:
>> 1. Nesting MACROs is perfectly legal in assembler but coms at a
>>unbelievable cost.
>> Example, I had a CICS I/O table to generate and each MACRO had
>>several operands but only one changed from one MACRO to the next.
>>I created an outer MACRO to ease my coding.
>>Assembly time more than doubled.
>>I suggest that STY not call an inner MACRO.
> I suspect you had a really awful inner macro. I use inner macros
>all the time, with no noticable, but possibly measurable,
>performance hit.

The inner MACROs were IBM written terminal defining MACROs
so may have been "awful" as you say.
The outer MACRO I added just supplied the terminal name and
address for the inner MACRO.
Think thousands of terminals on a S370/158 with 3330 and
3350 disks or a 4341 with 3375 disks.
SYSUT1 was beat to near death and duration went from
slow to more double in time.

Even with Hercules MIPS and superfast CCKD disks,
there is still a small effect.
Using small unnamed MACROs in place of complex
IBM terminal definition, the difference can be measured.
Less than 50% longer duration,
less than 50% more CPU time, and
less than 50% more I/O,
but it is still there:

1000 occurrences of single unnested MACRO
elapsed time 24:00:02,29
CPU time 00:00:01,62
SYSLIB 148.......1 ... 248.......1 ... 141.......2
SYSUT1 140....3974
SYSUT2 180......59
SYSUT3 170......38
VIRT 768K
SYS 280K
TOTAL RECORDS READ FROM SYSTEM INPUT 1032
TOTAL RECORDS READ FROM SYSTEM LIBRARY 26
TOTAL RECORDS PUNCHED 0
TOTAL RECORDS PRINTED 7538

1000 occurrences of outer MACRO with nested inner MACRO
elapsed time 24:00:03,13
CPU time 00:00:02,20
SYSLIB 148.......2 248.......2 141.......4
SYSUT1 140....5937
SYSUT2 180......53
SYSUT3 170......44
VIRT 768K
SYS 276K
TOTAL RECORDS READ FROM SYSTEM INPUT 1032
TOTAL RECORDS READ FROM SYSTEM LIBRARY 40
TOTAL RECORDS PUNCHED 0
TOTAL RECORDS PRINTED 8576

The 24 hour bug is probably from IEFACTRT ?

>> 2. LA X'41', not IC X'43' is the first RX instruction without a
complication.
>> STH X'40' is earlier but has issues like half-word alignment.

Both LA and IC are wrong for an instruction that store in memory.
STC is best for memory storers and LA for others.

>> Why not save the assembler lookup time.
>> Okay, it's just two instructions earlier and not used much.
> I haven't looked at it for years, but IFOX uses a hash table or
>something similar, so alphabetic sequence has little relevance for
>look-up time.

The table is not in alphabetic sequence.
It's defined in op-code sequence.

It could somehow have a hidden sort and hash table, but I doubt it.

>> I have seen a recommendation that ORG can set the location counter
>>too many levels back so LOCTR should be used instead but I don't
>>understand how ORG can mess up except for actually coding errors,
>>have used ORG since the end of the 1960s, and have never used LOCTR.
>>For now, I'll stick, with ORG.
> IIRC, LOCTR was introduced with ASM h, and isn't in IFOX.
>It would make a nice addition though.
> Gerhard Postpischil
> Bradford, VT
> ---
>This email has been checked for viruses by AVG.
> http://www.avg.com http://www.avg.com

I don't remember ever using LOCTR.
I just found that I have been using ORG in an unsafe manner.
I learned assembler almost fifty years ago so the issue may
no longer be actionable. I don't even remember the instructor's
name, only that my assembler instructor was on the CoDaSyL
Committee but my CoBOL instructor was not.

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
> I'd like to make one additional comment with regards to the use of inner macros.
>As you've demonstrated, there is some overhead involved. I'm not sure that was
>ever in question. SXMACLIB contains roughly 500 macros in support of the
>instructions provided by S37X. Most of those macros utilize a single (and rarely
>two) inner macro calls. Even given cut and paste in an editor, eliminating the
>inner macro references by copying the inner macro code into each referencing
>macro is a bit of additional work. But... more importantly, consider the
>maintenance issue. If an error needs to be corrected (or an enhancement
>made), it's much easier to change one inner macro, rather than the dozens
>of macros (or more) that the code was copied into.
> Shelby
- - - old notes snipped - - -

As I already tried to explain to Paul, scattering pieces around
makes maintenance more difficult.

With your excellent solution to the index register issue and
after I said that to Paul, I coded a quick CLIST to generate
the RXY MACROs as RXE instructions.

Okay I always code sloppy but it was still trivial.
I just up loaded a sample to:
https://groups.yahoo.com/neo/groups/H390-MVS/files/Temporary.trash/
get them quick before I delete.

['Shelby Beach' [e-mail] [H390-MVS]]

Well I guess that is one way for Paul to get what he wants. Of course RXY
instructions are only a subset of those supported by S37X. I have no idea
what Paul plans to do with these, but if he's using S37X (as opposed to some
non-370 Hercules mode), then he should know that not all of the RXY
instructions are implemented by S37X. Nice to see you could keep yourself
busy though.

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Thursday, April 06, 2017 7:34 PM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles




- - - In H390-***@yahoogroups.com, <***@...> wrote:
> I'd like to make one additional comment with regards to the use of inner
macros.
>As you've demonstrated, there is some overhead involved. I'm not sure that
was
>ever in question. SXMACLIB contains roughly 500 macros in support of the
>instructions provided by S37X. Most of those macros utilize a single (and
rarely
>two) inner macro calls. Even given cut and paste in an editor, eliminating
the
>inner macro references by copying the inner macro code into each
referencing
>macro is a bit of additional work. But... more importantly, consider the
>maintenance issue. If an error needs to be corrected (or an enhancement
>made), it's much easier to change one inner macro, rather than the dozens
>of macros (or more) that the code was copied into.
> Shelby
- - - old notes snipped - - -

As I already tried to explain to Paul, scattering pieces around
makes maintenance more difficult.

With your excellent solution to the index register issue and
after I said that to Paul, I coded a quick CLIST to generate
the RXY MACROs as RXE instructions.

Okay I always code sloppy but it was still trivial.
I just up loaded a sample to:
https://groups.yahoo.com/neo/groups/H390-MVS/files/Temporary.trash/
get them quick before I delete.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> I have no idea what Paul plans to do with these,

I use LG and STG to test out 64-bit
addressing in S/370 mode using
Hercules/380.

That is all I wish to do at the moment,
ie just a demo.

At a later date I (or someone else like
Dave Pitts) may add 64-bit capability
to GCCMVS.

Note that the s390 (not i370) target
in GCCMVS is already capable of
using the 64-bit instructions. So
another path is to modify s390 to
start producing normal 370 assembler.

> but if he's using S37X (as opposed to some
> non-370 Hercules mode),

I am using neither. I am using Hercules/380
in S/370 mode.

> then he should know that not all of the RXY
> instructions are implemented by S37X.

I believe nearly ALL of the instructions
in ESA/390 and z/Arch are available
in S/370 mode under the latest
Hercules/380 beta released.

And it is WAY cool to see the "64" bit
light up on the Hercules console when
running MVS 3.8j. And dumping some
populated ATB memory too.

BFN. Paul.

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
> Well I guess that is one way for Paul to get what he wants.
>Of course RXY instructions are only a subset of those
>supported by S37X. I have no idea what Paul plans to do
>with these, but if he's using S37X (as opposed to some
>non-370 Hercules mode), then he should know that not all
>of the RXY instructions are implemented by S37X.
>Nice to see you could keep yourself busy though. > Shelby
- - - old notes snipped - - -

It was just copy and paste a page at a time from from
IBM's zArch Reference Summary ( weeks ago ) and transfer
a column at a time to the sloppily written CLIST.
I did have to mark the ST* and CVD* instruction by changing
LA to STC.

Then I had decide to set the CLIST to create
IEBUPDTE/PDSLOAD format,
separate members, and
ISPF/PDF statistics or not for which was chosen.

Your idea to use RX to base RXY on as RXE was all that
was needed.

Since you have looked at my sample, all except the
template have been deleted.

['Shelby Beach' [e-mail] [H390-MVS]]

somitcw,

I'm curious, why the big emphasis on store vs. load instructions ? In the
end, that opcode only exists briefly and then it's replaced. The output
object code bears no relation to what the macro generated initially.

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Friday, April 07, 2017 5:46 AM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles




- - - In H390-***@yahoogroups.com, <***@...> wrote:
> Well I guess that is one way for Paul to get what he wants.
>Of course RXY instructions are only a subset of those
>supported by S37X. I have no idea what Paul plans to do
>with these, but if he's using S37X (as opposed to some
>non-370 Hercules mode), then he should know that not all
>of the RXY instructions are implemented by S37X.
>Nice to see you could keep yourself busy though. > Shelby
- - - old notes snipped - - -

It was just copy and paste a page at a time from from
IBM's zArch Reference Summary ( weeks ago ) and transfer
a column at a time to the sloppily written CLIST.
I did have to mark the ST* and CVD* instruction by changing
LA to STC.

Then I had decide to set the CLIST to create
IEBUPDTE/PDSLOAD format,
separate members, and
ISPF/PDF statistics or not for which was chosen.

Your idea to use RX to base RXY on as RXE was all that
was needed.

Since you have looked at my sample, all except the
template have been deleted.

[Tony Harminc [e-mail] [H390-MVS]]

On 7 April 2017 at 13:10, 'Shelby Beach' ***@comcast.net wrote:

> somitcw,
>
> I'm curious, why the big emphasis on store vs. load instructions ? In the
> end, that opcode only exists briefly and then it's replaced. The output
> object code bears no relation to what the macro generated initially.
>

I think his point is valid enough -- that the assembler RENT option will
not catch those violations that it otherwise could, if the base instruction
is a load type that the macro turns into a store. Not, of course, that any
assembler can possibly catch all RENT violations. Maybe it could catch
*some* more with some improbably advanced data flow analysis, but catching
them all is probably equivalent to the halting problem...

Tony H.

['Shelby Beach' [e-mail] [H390-MVS]]

Hi Tony,

Good point. I'd not noticed that he mentioned RENT detection (but the noise
level has been pretty high). I write a lot of reentrant code, but don't
really depend upon the assembler to find those types of errors for me (the
hardware is pretty good at that :-) !).

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Friday, April 07, 2017 11:54 AM
To: H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Re: IFOX assembler source troubles






On 7 April 2017 at 13:10, 'Shelby Beach' ***@comcast.net wrote:


somitcw,

I'm curious, why the big emphasis on store vs. load instructions ? In the
end, that opcode only exists briefly and then it's replaced. The output
object code bears no relation to what the macro generated initially.


I think his point is valid enough -- that the assembler RENT option will not
catch those violations that it otherwise could, if the base instruction is a
load type that the macro turns into a store. Not, of course, that any
assembler can possibly catch all RENT violations. Maybe it could catch
*some* more with some improbably advanced data flow analysis, but catching
them all is probably equivalent to the halting problem...


Tony H.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> catching them all is probably equivalent
> to the halting problem...

What "halting problem"?

BFN. Paul.

[Gerhard Postpischil [e-mail] [H390-MVS]]

On 4/7/2017 3:06 PM, ***@yahoo.com.au [H390-MVS] wrote:

> What "halting problem"?
Is it possible to write a program, to which another program is supplied
as data, that will correctly determine whether the subject program comes
to a halt, or will loop indefinitely.

While there may be some programs whose status may be determined, in the
general case the answer is no. The (dis)proof consists of feeding that
program into itself.

BTW, in the mid-eighties there was a company advertising just such a
program in Byte, PC, and PC World magazines - I have no idea what
happened to them, or if they ever got sued.



Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
> somitcw,
> I'm curious, why the big emphasis on store vs. load instructions ?
>In the end, that opcode only exists briefly and then it's replaced.
>The output object code bears no relation to what the macro
>generated initially.
> Shelby
- - - old notes snipped - - -

IFOX00 treats instructions that alter memory differently than
instructions that don't. We should allow that to continue.

The two examples that I gave were:

1. Literal pools are constantly read from but should never be
altered. The assembler will tell you unless you break its
ability to do so.

2. The assembler needs to know which instructions alter
memory to handle PARM=RENT properly.

Examples:

1. I never label any machine instruction unless it is an
EXecuted instruction. Even if I did, I would never use the
length value for the instruction or care what it is set to.
That is, I don't know what the length value is and don't care.
But both you and I did try to match what we believe the
length value should be set to.
If we are trying to emulate an assembly instruction, we do
try to properly emulate that instruction the best we can.

2. We all know that we can code DISP=SHARE on the
SYSUT2 DD statements for IEBUPDTE, IEBCOPY, and
others but we normally code the safer MOD or OLD.
Doing it right occasionally is sometimes better than
being the most expedient.

[Gerhard Postpischil [e-mail] [H390-MVS]]

On 4/6/2017 10:59 AM, ***@yahoo.com [H390-MVS] wrote:
> The table is not in alphabetic sequence.
> It's defined in op-code sequence.

I just checked the source we have, and you are correct. But I distinctly
remember looking at a version (circa seventies or eighties) that used
something other than a plain text listing. I may have the assembler
listing, so I'll see if I can find it.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

['Shelby Beach' [e-mail] [H390-MVS]]

somitcw,

If my implementation offends your sensibilities, I suggest that you make a
copy of the library and modify it to meet your high expectations. One could
bit fiddle with these things until the cows come home, and yield very little
significant improvement. I have better things to do. Personally, I think
your comments smell of NIH !

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Wednesday, April 05, 2017 7:21 AM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles




---In H390-***@yahoogroups.com, <***@...> wrote :
>>And I'm a very happy camper. :-)
> Good !
> Shelby
- - - old notes snipped - - -

The STY and E3OP MACROs are excellent work but performance could
be improved.

1. Nesting MACROs is perfectly legal in assembler but coms at a
unbelievable cost.
Example, I had a CICS I/O table to generate and each MACRO had
several operands but only one changed from one MACRO to the next.
I created an outer MACRO to ease my coding.
Assembly time more than doubled.
I suggest that STY not call an inner MACRO.

2. LA X'41', not IC X'43' is the first RX instruction without a
complication.
STH X'40' is earlier but has issues like half-word alignment.
Why not save the assembler lookup time.
Okay, it's just two instructions earlier and not used much.

3. A DC for six bytes that will all be overlaid is not required.
If really just to set a length, an EQU would be better.
If the STY instruction is unlabelled, no DC or EQU should be used.

I have seen a recommendation that ORG can set the location counter
too many levels back so LOCTR should be used instead but I don't
understand how ORG can mess up except for actually coding errors,
have used ORG since the end of the 1960s, and have never used LOCTR.
For now, I'll stick, with ORG.
We could add two "ORG ," statements? Opinions?

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
>somitcw,
> If my implementation offends your sensibilities, I suggest
>that you make a copy of the library and modify it to meet
>your high expectations. One could bit fiddle with these
>things until the cows come home, and yield very little
>significant improvement. I have better things to do.

If you don't like my suggestions, just forget them.

Since your MACROs would be replicated for one or two hundred
MACROs, I assumed that you would prefer working with others
to get the best code possible.

I was wrong to assUme and humbly apologize.

>Personally, I think your comments smell of NIH !
> Shelby
- - - old notes snipped - - -

My suggestions were not in anyway related to the
Nation Institutes of Health or other allopathic institution.
They weren't related to traditional medicine either.

[Joe Monk [e-mail] [H390-MVS]]

NIH = Not Invented Here

Joe

On Wed, Apr 5, 2017 at 1:07 PM, ***@yahoo.com [H390-MVS] <
H390-***@yahoogroups.com> wrote:

>
>
> - - - In H390-***@yahoogroups.com, <***@...> wrote:
> >somitcw,
> > If my implementation offends your sensibilities, I suggest
> >that you make a copy of the library and modify it to meet
> >your high expectations. One could bit fiddle with these
> >things until the cows come home, and yield very little
> >significant improvement. I have better things to do.
>
> If you don't like my suggestions, just forget them.
>
> Since your MACROs would be replicated for one or two hundred
> MACROs, I assumed that you would prefer working with others
> to get the best code possible.
>
> I was wrong to assUme and humbly apologize.
>
> >Personally, I think your comments smell of NIH !
> > Shelby
> - - - old notes snipped - - -
>
> My suggestions were not in anyway related to the
> Nation Institutes of Health or other allopathic institution.
> They weren't related to traditional medicine either.
>
>

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
> NIH = Not Invented Here
> Joe
- - - old notes snipped - - -

I never claimed to be Jan Jaeger or anyone that later tried to
replaced any SYS1.ZMACLIB MACROs.

P.S. My "LA" has one of the same fatal flaw as the "IC".

Store instructions like "STY" are not allowed to store in
the literal pool and are checked against PARM=RENT

I should have used "STC" for store instructions like
"STY" and used "LA" for non-store instructions.

Not matching store and non-store to the same type
of opcode can cause strange messages or worse,
no error indication at all.

But, I have been told off and am out of it now.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

Now that I understand the E3OP macro,
I have updated it:

https://groups.yahoo.com/neo/groups/hercules-os380/files/mac64.zip

I just made it look like this:

AIF ('&SUBOP' EQ '24').GENST STG Opcode ?
AIF ('&SUBOP' EQ '3E').GENST STRV Opcode ?
AIF ('&SUBOP' EQ '3F').GENST STRVH Opcode ?
AIF ('&SUBOP' EQ '50').GENST STY Opcode ?

And now I can comment on somitcw's
changes:

> 1. Nesting MACROs is perfectly legal in
> assembler but coms at a unbelievable cost.

I am more interested in maintainability
than slightly faster assemblies. The
E3OP is more maintainable.

> 2. LA X'41', not IC X'43' is the first RX instruction without a complication.

LA is far less intuitive than IC, and
again I'm more interested in
maintainability than slightly faster
assemblies.

> 3. A DC for six bytes that will all be overlaid is not required.

The code is this:

&LABEL DC 0XL6'00' Set Instruction Length of 6

The "0" means that it allocates 0 bytes,
not 6, and thus there is no ORG in
order to do an overlay.

This is neater than your multiple lines
to replace this one line.

Note that I don't know how a multiplier
of "0" manages to make a length of 6
in the first place though. But if it works
as-is, go for it!

BFN. Paul.

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
> - - - In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com,
><***@...> wrote :
> Now that I understand the E3OP macro,
>I have updated it:
> https://groups.yahoo.com/neo/groups/hercules-os380/files/mac64.zip
> I just made it look like this:
> AIF ('&SUBOP' EQ '24').GENST STG Opcode ?
> AIF ('&SUBOP' EQ '3E').GENST STRV Opcode ?
> AIF ('&SUBOP' EQ '3F').GENST STRVH Opcode ?
> AIF ('&SUBOP' EQ '50').GENST STY Opcode ?

Checking for instructions that start with "ST" would
have gotten all of those and more.
Checking fo instructions that start with "CVD" would
get more. Perhaps all?

Why weren't they set to use "STC" in the outer MACRO ?
Why weren't the others done?

Obvious RXY instructions that store in memory are:

E324 STORE (64) STG
E326 CONVERT TO DECIMAL (32) CVDY
E32E CONVERT TO DECIMAL (64) CVDG
E32F STORE REVERSED (64) STRVG
E33E STORE REVERSED (32) STRV
E33F STORE REVERSED (16) STRVH
E350 STORE (32) STY
E370 STORE HALFWORD STHY
E372 STORE CHARACTER STCY
E38E STORE PAIR TO QUADWORD STPQ
E3C3 STORE CHARACTER HIGH (8) STCH
E3C7 STORE HALFWORD HIGH (16) STHH
E3CB STORE HIGH (32) STFH
. first byte of op-code below is different than above:
ED66 STORE (short) STEY
ED67 STORE (long) STDY

That doesn't include RSE, RSY, or RXE which
is more than the number of RXY.
And there are more new instruction types.

> And now I can comment on somitcw's changes:
>> 1. Nesting MACROs is perfectly legal in
>>assembler but coms at a unbelievable cost.
> I am more interested in maintainability
>than slightly faster assemblies. The
>E3OP is more maintainable.

Delaying setting the instruction to overlay until
the end to intercept the issue with what started
the issue is a strange thing to call
"more maintainable".

Doing it right to start with is more my idea of
"more maintainable".

Note: Assembler allows many levels of nesting.
You can add a few more if you like.
Going through ten MACROs to update what could
have been one MACRO could be great fun.
Isn't that even "more maintainable"?
The more you spread it out, the more fun to
make changes.

> 2. LA X'41', not IC X'43' is the first RX instruction
>without a complication.
> LA is far less intuitive than IC, and again I'm more
>interested in maintainability than slightly faster
>assemblies.

Any S/370 assembler programmer would instantly
know that "LA" is an RX format instruction.
Much quicker than the less common "IC".

So "IC" is slower to look up and a less common of
an instruction. Anything else going for it?

>> 3. A DC for six bytes that will all be overlaid is not required.
> The code is this:
> &LABEL DC 0XL6'00' Set Instruction Length of 6
> The "0" means that it allocates 0 bytes,
>not 6, and thus there is no ORG in
>order to do an overlay.
> This is neater than your multiple lines
>to replace this one line.
> Note that I don't know how a multiplier
>of "0" manages to make a length of 6
>in the first place though. But if it works
>as-is, go for it!
> BFN. Paul.

The purpose is to set a label to a length value of
6 bytes whether there is a label or not.
Did you read the comment on the line?
The fact that it has a replication factor of zero
does not affect the length value.

If there is no label, which would be most of the
time, then it sets nothing to a length value of 6.
When no label, it is more sensible to skip
setting the length value on a label that isn't there.
The fact that coding the best costs two lines of
code is unimportant. Your goal to achieve less
than desireable code is strange.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> Why weren't they set to use "STC" in the outer MACRO ?

Yes, I think E3OP should take an extra
parameter to say "this is a store", assuming
that is technically possible.

Or perhaps have an E3OPL and E3OPS,
which may be implemented to call a
modified E3OP.

BFN. Paul.

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
> - - - In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com,
><***@...> wrote :
>> Why weren't they set to use "STC" in the outer MACRO ?
> Yes, I think E3OP should take an extra
>parameter to say "this is a store", assuming
>that is technically possible.
> Or perhaps have an E3OPL and E3OPS,
>which may be implemented to call a
>modified E3OP.
> BFN. Paul.

It would make more sense for you to:

1. Trash E3OP, ESOPL, and ESOPS

2. Write a template that handles RXE and RXY.
RSY without the extra 8 bit displacement is RXE.
Example, "STG" was RXE format.
IBM declared that STG became RXY so could
then use the high order 8 bit displacement.
Yes, the same mnemonic, same format, and
the same op-code.

3. Write a CLIST written to copy the template
many times with different instruction names,
both halves of the op-codes, instruction name
to set something to overlay like "LA" or "STC".
If a change is ever needed, change the template
and re-ruin the CLIST.
You are welcome to use my CHANGE71 program,
Rexx, CLIST, batch, "C" if it can copy with
updates, etc

(sarcasm)But that would be your version of
not being maintainable.(/sarcasm).

P.S. If you don't like the number of lines in my
programs, MACROs, or other, just delete the
comments.
I overdo comments anyway and you may save
a track or two of dirt cheap disk space by
blinding yourself.

['Shelby Beach' [e-mail] [H390-MVS]]

Short answer, because as more instructions were added that called a given
inner macro, I simply forgot to go back and update the inner macro. Thing
is, it has no affect at all on the resultant object code. So why does it
matter ? The opcode is going to overlaid anyway. Aren't you bothered that
all those additional AIFs slow down the assembly process :-) !

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Thursday, April 06, 2017 2:39 PM
To: H390-***@yahoogroups.com
Subject: RE: [H390-MVS] Re: IFOX assembler source troubles




- - - In H390-***@yahoogroups.com, <***@...> wrote:
> - - - In H390-***@yahoogroups.com mailto:H390-***@yahoogroups.com,
><***@...> wrote :
> Now that I understand the E3OP macro,
>I have updated it:
> https://groups.yahoo.com/neo/groups/hercules-os380/files/mac64.zip
> I just made it look like this:
> AIF ('&SUBOP' EQ '24').GENST STG Opcode ?
> AIF ('&SUBOP' EQ '3E').GENST STRV Opcode ?
> AIF ('&SUBOP' EQ '3F').GENST STRVH Opcode ?
> AIF ('&SUBOP' EQ '50').GENST STY Opcode ?

Checking for instructions that start with "ST" would
have gotten all of those and more.
Checking fo instructions that start with "CVD" would
get more. Perhaps all?

Why weren't they set to use "STC" in the outer MACRO ?
Why weren't the others done?

Obvious RXY instructions that store in memory are:

E324 STORE (64) STG
E326 CONVERT TO DECIMAL (32) CVDY
E32E CONVERT TO DECIMAL (64) CVDG
E32F STORE REVERSED (64) STRVG
E33E STORE REVERSED (32) STRV
E33F STORE REVERSED (16) STRVH
E350 STORE (32) STY
E370 STORE HALFWORD STHY
E372 STORE CHARACTER STCY
E38E STORE PAIR TO QUADWORD STPQ
E3C3 STORE CHARACTER HIGH (8) STCH
E3C7 STORE HALFWORD HIGH (16) STHH
E3CB STORE HIGH (32) STFH
. first byte of op-code below is different than above:
ED66 STORE (short) STEY
ED67 STORE (long) STDY

That doesn't include RSE, RSY, or RXE which
is more than the number of RXY.
And there are more new instruction types.

> And now I can comment on somitcw's changes:
>> 1. Nesting MACROs is perfectly legal in
>>assembler but coms at a unbelievable cost.
> I am more interested in maintainability
>than slightly faster assemblies. The
>E3OP is more maintainable.

Delaying setting the instruction to overlay until
the end to intercept the issue with what started
the issue is a strange thing to call
"more maintainable".

Doing it right to start with is more my idea of
"more maintainable".

Note: Assembler allows many levels of nesting.
You can add a few more if you like.
Going through ten MACROs to update what could
have been one MACRO could be great fun.
Isn't that even "more maintainable"?
The more you spread it out, the more fun to
make changes.

> 2. LA X'41', not IC X'43' is the first RX instruction
>without a complication.
> LA is far less intuitive than IC, and again I'm more
>interested in maintainability than slightly faster
>assemblies.

Any S/370 assembler programmer would instantly
know that "LA" is an RX format instruction.
Much quicker than the less common "IC".

So "IC" is slower to look up and a less common of
an instruction. Anything else going for it?

>> 3. A DC for six bytes that will all be overlaid is not required.
> The code is this:
> &LABEL DC 0XL6'00' Set Instruction Length of 6
> The "0" means that it allocates 0 bytes,
>not 6, and thus there is no ORG in
>order to do an overlay.
> This is neater than your multiple lines
>to replace this one line.
> Note that I don't know how a multiplier
>of "0" manages to make a length of 6
>in the first place though. But if it works
>as-is, go for it!
> BFN. Paul.

The purpose is to set a label to a length value of
6 bytes whether there is a label or not.
Did you read the comment on the line?
The fact that it has a replication factor of zero
does not affect the length value.

If there is no label, which would be most of the
time, then it sets nothing to a length value of 6.
When no label, it is more sensible to skip
setting the length value on a label that isn't there.
The fact that coding the best costs two lines of
code is unimportant. Your goal to achieve less
than desireable code is strange.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> When you mentioned running in 31 bit mode
> I assumed that you were referring to fully
> embracing running in either 24 bit MVS
> 3.8 or 31 bit with a more recent OS. In
> your posting you identified one reason
> why there are different code paths. I am
> sure that there are others as well if z/OS
> features are fully utilized.

Sorry for not being clear. No, the assumption
is the exact opposite - that the only features
that will be used are those present in
MVS 3.8j.

And the single load module would not
normally do a BSM, it would just accept
whatever AMODE it was invoked under.

With that clarified, do you agree that
different code paths are not required?

> I suggest use of Shelby Beach’s macro
> library as some of the other macro libraries,
> including the macro library I created,
> contain errors and lack some instructions.

Well Shelby is claiming that his/her
macro library doesn't have 64-bit
instructions.

The macro library I am using does
have both STG and STGM, even
if they are substandard. I don't
know who produced it, but those
are the instructions I wish to use.

BFN. Paul.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> The macro library I am using does
> have both STG and STGM

Ok, this is the VERY LAST TIME that
I am going to make this mistake.

My dad used to own 2 MG cars.
Morris's Garage.

The correct instruction is STMG,
not STGM.

I logged on and checked my
SYS1.MACLIB to be sure, as it
wasn't on somitcw's list.

BFN. Paul.

['Shelby Beach' [e-mail] [H390-MVS]]

Paul,

There is no license associated with my macros in SXMACLIB. I corrected many
of the errors that were in other incarnations of the macros. Feel free to
take what's in SXMACLIB and add your own macros to it. Perhaps some of my
macros might serve as a guide for fixing any other issues you might be
seeing.

Shelby



_____

From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Monday, April 03, 2017 2:22 AM
To: H390-***@yahoogroups.com
Subject: [H390-MVS] Re: IFOX assembler source troubles




---In H390-***@yahoogroups.com, <***@...> wrote :

> When you mentioned running in 31 bit mode
> I assumed that you were referring to fully
> embracing running in either 24 bit MVS
> 3.8 or 31 bit with a more recent OS. In
> your posting you identified one reason
> why there are different code paths. I am
> sure that there are others as well if z/OS
> features are fully utilized.

Sorry for not being clear. No, the assumption
is the exact opposite - that the only features
that will be used are those present in
MVS 3.8j.

And the single load module would not
normally do a BSM, it would just accept
whatever AMODE it was invoked under.

With that clarified, do you agree that
different code paths are not required?

> I suggest use of Shelby Beach's macro
> library as some of the other macro libraries,
> including the macro library I created,
> contain errors and lack some instructions.

Well Shelby is claiming that his/her
macro library doesn't have 64-bit
instructions.

The macro library I am using does
have both STG and STGM, even
if they are substandard. I don't
know who produced it, but those
are the instructions I wish to use.

BFN. Paul.

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

Hi Tom.

I'm not sure what status you are at with
your IFOX mods, but you can see the
changes I made to the source (from
Paul G) to sync up with the TK module here:

https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/12742

BFN. Paul.

[Gerhard Postpischil [e-mail] [H390-MVS]]

On 4/2/2017 5:47 PM, ***@yahoo.com.au [H390-MVS] wrote:
> Gerhard - I have a vague recollection
> that you had a problem with some
> assembler (maybe not IFOX?)
> running out of memory forcing you
> to use some alternate assembler?
> Tachyon? But there was some other
> issue with that?
The problem is with the Tachyon (X390) assembler. Even a moderate size
module under development runs out of memory. I have a special IPL with
an absolute minimum LPA and CSA, and get just over 9MB for the private
region, but even that's not enough.

Regarding assembling it under GCC, it might be nice, but I've tried to
get my license renewed for the last two years, and never got a response.


Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

> The problem is with the Tachyon (X390) assembler.

> Regarding assembling it under GCC, it might be nice, but I've tried to
> get my license renewed for the last two years, and never got a response.

I emailed then on "Sunday" with this
suggestion of using GCC to use ATL
memory, and on "Monday" I got this
reply:

Just a note to let you know that Tachyon Software is no longer issuing licenses for
the Tachyon Legacy Assembler.


I think that's the end of the road
there. A shame. I had hoped that
they would stop requiring licenses
and instead include it on TK4-. And
have it run in 31-bit mode on
MVS/380.

I suggested to them that if this was
the permanent situation, that they
update this on their website:

http://www.tachyonsoft.com/legacy.html

The Tachyon Legacy Assembler is free.


I haven't had a response to that yet.

BFN. Paul.

[Tony Harminc [e-mail] [H390-MVS]]

On 3 April 2017 at 16:51, ***@yahoo.com.au wrote:
> I emailed then on "Sunday" with this
> suggestion of using GCC to use ATL
> memory, and on "Monday" I got this
> reply:
>
> Just a note to let you know that Tachyon Software is no longer issuing licenses for
> the Tachyon Legacy Assembler.


Back in December 2016 there was a thread on IBM-MAIN that this is a
good-enough summary of:

On 8 December 2016 at 14:15, Ed Jaffe wrote:
> On 12/8/2016 1:36 AM, David Cole wrote:
>>
>> I guess for most people, this is old news, but I've learned only recently
>> that Dave Bond is no longer involved at TachyonSoft. Does anyone know how to
>> reach him these days?
>
>
> He lives in Switzerland and works for LzLabs -- John Moores' latest
> kill-the-mainframe endeavor.
>
> Their web site URL is https://www.lzlabs.com/
>
> --