IFOX assembler source troubles

classic Classic list List threaded Threaded
84 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

IFOX assembler source troubles

Hercules390 - Mvs mailing list
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.
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
On 2017-03-31 4:41 PM, Tony Harminc [hidden email] [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

Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
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 [hidden email], <tharminc@...> 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.






Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
On 31 March 2017 at 12:43, [hidden email] 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 [hidden email] still a good address?

Tony H.
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
- - - In [hidden email], <thomas_j_armstrong@...> 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.
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 31 March 2017 at 20:06, [hidden email] 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.

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

>
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
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: [hidden email] [mailto:[hidden email]]
Sent: 01 April 2017 18:11
To: [hidden email]
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







Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 1 April 2017 at 13:11, [hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
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: [hidden email] [mailto:[hidden email]]
Sent: 02 April 2017 00:17
To: [hidden email]
Subject: Re: [H390-MVS] Re: IFOX assembler source troubles

 






On 1 April 2017 at 13:11, [hidden email] <mailto:[hidden email]>  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.








Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
---In [hidden email], <thomas_j_armstrong@...> 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.
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list


On 4/2/2017 11:47 PM, [hidden email] [H390-MVS] wrote:

> ---In [hidden email], <thomas_j_armstrong@...> 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


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
---In [hidden email], <ivan@...> 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.
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
---In [hidden email], <kerravon86@...> 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.
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 2 April 2017 at 17:53, Ivan Warren [hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: IFOX assembler source troubles

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
---In [hidden email], <kerravon86@...> 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.
12345