Re: Storage and Tokens

[Binyamin Dissen]

On Thu, 11 Apr 2013 21:57:52 + "Hall, Keven" 
wrote:

:>The next most efficient technique after using a sanctioned slot in the area 
referenced by ECVTCTBL is Name/Token services.  A System-level Name/Token in 
would be needed in this case.

I wonder if IBM has reserved some for the installation.

Of course, there is the ancient technique of anchoring the SITECVT address in
CVTUSER. Faster than ECVTCTBL.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Re: Baseless problem

[Jon Perryman]

Sorry if I offended anyone. That was not my intent. "NEED TO" was not meant to 
dictate what vendors must do. Only that additional considerations exist that 
have an impact in a product environment. I just wanted Scott to consider the 
following now instead of after RTM. These possible problems could be easily 
eliminated by placing the data first in modules. It would certainly take less 
time than trying to verify are not issues for your product. 

1. Common abend recovery may be affected. Maybe the module eyecacther (not to 
be 
confused with load module name) and offset into that module are displayed. 
Maybe 
it expects a standard base register that starts at the beginning of the 
program. 
2. How do customers and customer support deal with abends. Do they somehow use 
module base register? Do they have procedures that will be affected? Does it 
affect how they search the problem database?
3. How are IPCS diagnostic exec's affected? 
4. Diagnostic documentation, FAQ's, problem database and other online material 
might have something that is affected. 

Are there any drawbacks to placing data first in a module? I only see possible 
drawbacks when it is not first. 

Regards, Jon Perryman.
  

>
>From: Martin Trübner 
>Enough been said about the reason and the cause (and solutions)
>
>But who dictates techniques for vendors?
>
>While your points are okay- the "trick" to have the definitions right at the 
>beginning of the module  (with just a J in front) is something that makes 
>sense 
>for everyone. If you ever tried to calculate offset in a DOB-program (data 
>only 
>base) from the start of the LTORG (or wherever the base points to) knows what 
>I  
>mean.
>
>Credit for the technique goes to Ed J.  
>

Re: Baseless problem

[Scott Ford]

Chris:
 
thanks for the suggestion much appreciated...I am writing more code 
tonight...so i will let you all now how it comes out

Scott J Ford
Software Engineer
http://www.identityforge.com/
 
 


 From: "Webster, Chris" 
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 
Sent: Thursday, April 11, 2013 2:11 PM
Subject: Re: Baseless problem
  

Scott,

A couple more suggestions.
1. add 'ieabrcx enable' (or maybe it was snipped)
2. use larl 12,const instead of lr/ahi - it will make amode 64 conversion easier
3. limit the using range to avoid base register bleed beyond the intended range 
'using (const,constend),12'
4. both dataloc1/2 loctr's have no purpose when they are just followed by dsects
5. use the noprint option on the print statements to keep the listing cleaner

...chris.
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Scott Ford
Sent: Thursday, April 11, 2013 12:13 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Baseless problem

Guys:

I wanted to say a BIG THX...I got my code to assemble still working thru design 
and coding issues..but hey what's life without a challenge or two or three...

Heres my new code..I had to changes things for obivious reasons.

SAMPLE01 AMODE 31
SAMPLE01 RMODE ANY
         YREGS
         PRINT OFF
         SYSSTATE ARCHLVL=2
         IEABRCX DEFINE
         PRINT ON
         J     BEGIN
PROLOG   LOCTR
         DC    C'SAMPLE01 - xxx V4.7.0.2'
         DC    C'Assembled Date && Time: &SYSDATE &SYSTIME'
         DC    C'Copyright (C), Identityforge,LLC'
         DC    C'All rights reserved'
CODEBG1  LOCTR
BEGIN    DS    0H
         SAVE  (14,12)                      save regs coming in
         LR    R12,R15
         AHI   R12,CONST-BEGIN
         USING CONST,R12
         LR    R10,R1
         USING WRKDSECT,R11                 base parameter map
         USING EVXPL,R10                    base parameter map
         L     R4,EVXFLAGS                  exit flag address .
..
.
CONST    DC    0D
.(literal constants)
        LTORG
DATALOC1 LOCTR
DYNAMIC  DSECT
SAVEAREA DS    18F                 register save area ...
...
DYNSIZE  EQU   *-DYNAMIC           length of DSECT
DATALOC2 LOCTR
WRKDSECT DSECT
WRKSIZE  EQU   *-WRKDSECT          length of DSECT
         IHAPSA
         IHAASCB
         IHAASXB
         IRREVXP
         IEANTASM
         IHAACEE
         IKJTSB LIST=YES,EXT=YES

Something I would also like to comment on and share. I saw Jon Perryman's 
comments. I thank him for the suggestion but still as a vendor we are the ones 
responsible for our code. Can it be done better, of course, but there is a way 
to suggest that.

Over the last couple of days a customer , tried to tell us that every vendor 
had to have their modules identify the vendor by its first three characters of 
a name. There were a few other ill-educated suggestions. I understand everyone 
has to learn but again there is a respectful way of suggesting this to a 
company, i.e.;  vendor. I would never try to tell a vendor, i.e.; IBM, how to 
code or what to do, they have suggestion forms and forums for that. Maybe I am 
too old school..

Regards,

Scott J Ford
Software Engineer
http://www.identityforge.com/

aka ...somewhere lost in NJ




From: John McKown 
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Thursday, April 11, 2013 12:54 PM
Subject: Re: Baseless problem


He said that he did, IIRC.

On Thu, Apr 11, 2013 at 10:56 AM, Steve Comstock
 wrote:
> On 4/11/2013 9:33 AM, Ed Jaffe wrote:
>>

> I wonder if the OP got his problem solved.
>
> --
>
> Kind regards,
>
> -Steve Comstock
> The Trainer's Friend, Inc.
>
> 303-355-2752
> http://www.trainersfriend.com/

Re: Baseless problem

[Scott Ford]

Andreas:
 
Amen to that. I am working with LE now ..a lot of serious differences, 
especially
when ppl dont run the right run options.. like STACK() ...

Scott J Ford
Software Engineer
http://www.identityforge.com/
 
 


 From: Andreas F. Geissbuehler 
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 
Sent: Thursday, April 11, 2013 8:40 PM
Subject: Re: Baseless problem
  

Bernd Oppolzer schrieb:
> ... the OS linkage conventions, no other IBM language processor like
> the PL/1 compiler or LE ever used it - I never understood this.

LE  was a game changer. Prior to LE almost all programs and modules
adhered to __one and the same set__ of rules, including IBM access
methods and supervisor services.

Andreas F. Geissbuehler

Re: Baseless problem

[Andreas F. Geissbuehler]

Bernd Oppolzer schrieb:

... the OS linkage conventions, no other IBM language processor like
the PL/1 compiler or LE ever used it - I never understood this.


LE  was a game changer. Prior to LE almost all programs and modules
adhered to __one and the same set__ of rules, including IBM access
methods and supervisor services.

Andreas F. Geissbuehler

Re: Baseless problem

[Webster, Chris]

Scott,

A couple more suggestions.
1. add 'ieabrcx enable' (or maybe it was snipped)
2. use larl 12,const instead of lr/ahi - it will make amode 64 conversion easier
3. limit the using range to avoid base register bleed beyond the intended range 
'using (const,constend),12'
4. both dataloc1/2 loctr's have no purpose when they are just followed by dsects
5. use the noprint option on the print statements to keep the listing cleaner

...chris.
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Scott Ford
Sent: Thursday, April 11, 2013 12:13 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Baseless problem

Guys:

I wanted to say a BIG THX...I got my code to assemble still working thru design 
and coding issues..but hey what's life without a challenge or two or three...

Heres my new code..I had to changes things for obivious reasons.

SAMPLE01 AMODE 31
SAMPLE01 RMODE ANY
 YREGS
 PRINT OFF
 SYSSTATE ARCHLVL=2
 IEABRCX DEFINE
 PRINT ON
 J BEGIN
PROLOG   LOCTR
 DCC'SAMPLE01 - xxx V4.7.0.2'
 DCC'Assembled Date && Time: &SYSDATE &SYSTIME'
 DCC'Copyright (C), Identityforge,LLC'
 DCC'All rights reserved'
CODEBG1  LOCTR
BEGINDS0H
 SAVE  (14,12)  save regs coming in
 LRR12,R15
 AHI   R12,CONST-BEGIN
 USING CONST,R12
 LRR10,R1
 USING WRKDSECT,R11 base parameter map
 USING EVXPL,R10base parameter map
 L R4,EVXFLAGS  exit flag address .
..
.
CONSTDC0D
.(literal constants)
LTORG
DATALOC1 LOCTR
DYNAMIC  DSECT
SAVEAREA DS18F register save area ...
...
DYNSIZE  EQU   *-DYNAMIC   length of DSECT
DATALOC2 LOCTR
WRKDSECT DSECT
WRKSIZE  EQU   *-WRKDSECT  length of DSECT
 IHAPSA
 IHAASCB
 IHAASXB
 IRREVXP
 IEANTASM
 IHAACEE
 IKJTSB LIST=YES,EXT=YES

Something I would also like to comment on and share. I saw Jon Perryman's 
comments. I thank him for the suggestion but still as a vendor we are the ones 
responsible for our code. Can it be done better, of course, but there is a way 
to suggest that.

Over the last couple of days a customer , tried to tell us that every vendor 
had to have their modules identify the vendor by its first three characters of 
a name. There were a few other ill-educated suggestions. I understand everyone 
has to learn but again there is a respectful way of suggesting this to a 
company, i.e.;  vendor. I would never try to tell a vendor, i.e.; IBM, how to 
code or what to do, they have suggestion forms and forums for that. Maybe I am 
too old school..

 Regards,

Scott J Ford
Software Engineer
http://www.identityforge.com/

aka ...somewhere lost in NJ




 From: John McKown 
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Thursday, April 11, 2013 12:54 PM
Subject: Re: Baseless problem


He said that he did, IIRC.

On Thu, Apr 11, 2013 at 10:56 AM, Steve Comstock
 wrote:
> On 4/11/2013 9:33 AM, Ed Jaffe wrote:
>>

> I wonder if the OP got his problem solved.
>
> --
>
> Kind regards,
>
> -Steve Comstock
> The Trainer's Friend, Inc.
>
> 303-355-2752
> http://www.trainersfriend.com

Re: Baseless problem

[Dave]

On 11/04/2013 20:23, Tony Harminc wrote:

On 11 April 2013 10:32, Ed Jaffe  wrote:


The oldest assembler I ever used was IFOX00. ISTR, it did not have
support for LOCTR but my memory could be faulty.

It matches mine.

It's worth remembering that ASMH predates IFOX00. (Well, as far as
customer availability goes; I have no idea what went on inside IBM.) I
have never understood the point of IFOX00; it appears to be a
reimplemention from scratch to the IEUASM specs, with a couple of
trivial functional enhancements, and using reentrant code. Compared to
IEUASM it has no significant performance advantage, appears not to
exploit any particular aspects of virtual storage, the supported macro
and assembler language is essentially identical, diagnostics are no
better, and so on.

It will assemble the code the old GCC370 compiler spits out  and I don't
think IUEASM will. Certainly ASMG failed when I tried it


I can only guess at the internal politics in play at the time that
must have led to this project, when ASMH already existed and offered
so much more. IBM's usual internal competition, I suppose, but in such
a small subject area...

On the more on-topic matter of jumpifying and putting data at the
start of a module, it bears keeping in mind that it does locality of
reference no good to have a single branch/jump instruction at the
start of a module, followed by a large amount of data, and then code
continuing way down. While no-one may be paging the way they used to
these days, it still shouldn't be encouraged, and hopping down the
pages with one instruction reference each is not the thing to do. Even
on the smaller scale and much faster resolution time of cache lines,
it's probably not such a good thing.

Tony H.

Re: Baseless problem

[Lloyd Fuller]

LOCTR has been around since at least the mid-1980s.

I had to debug a full-screen editor that used it heavily.  This would have been
the H-Assembler with SLAC mods.

Lloyd



- Original Message 
From: Paul Gilmartin 
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Thu, April 11, 2013 10:48:09 AM
Subject: Re: Baseless problem

On Apr 11, 2013, at 08:32, Ed Jaffe wrote:
>
> The oldest assembler I ever used was IFOX00. ISTR, it did not have
> support for LOCTR but my memory could be faulty.
>
I believe LOCTR is fairly new.  Some of my co-workers are old
enough not to know about it.  Bitsavers would probably know,
but why bother.

I once played with LOCTR until I created an unresolvable
expression in an address constant (no base-displacement
involved) with no symbols having been referenced prior
to their definitions.

-- gil

Re: Storage and Tokens

[Hall, Keven]

Scott,

The next most efficient technique after using a sanctioned slot in the area 
referenced by ECVTCTBL is Name/Token services.  A System-level Name/Token in 
would be needed in this case.

Keven

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Rob Scott
Sent: Wednesday, April 10, 2013 12:12
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Storage and Tokens

Off the top of my head - here are a few alternatives to the system level 
name/token approach :

(1) Anchor your product in a slot in the "customer table" pointed to by 
ECVTCTBL - this is a technique used by many ISVs who have reserved one or more 
slots with IBM (Peter Relson is the "guardian" of the slots IIRC).
- If this is just an in-house utility, then this is probably overkill
- Very efficient process to find the slot  - maybe six instructions or 
so?
(2) Hang the anchor address off SSCTSUSE or SSCTSUS2 for a subsystem entry
This is easily done - however if you are a shop with many subsystems it 
might be prohibitive to keep performing a sequential search of the SSCT chain 
each time you need to find the anchor
(3) Your STC holds an system enqueue for an agreed QNAME - you stick the anchor 
in the RNAME and use ISGQUERY to find it
Not as efficient as system level name/token - however the big advantage 
over other methods of being possible to achieve in problem state code.

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Scott Ford
Sent: 10 April 2013 16:09
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Storage and Tokens

Sam,
This is more or less what we do
 Sorry let me explain...
The code i am referring to was written in 2002 not that is bad. But it wasnt 
well thought out because of time.
Here is in a nutshell what happens:
1. STC ( written in Cobol with assembler subroutines ) starts up , btw its AC=1 
(TCPIP server) a. Allocates storage b. Inserts a Token after a good RC from (a) 
c. Waits for incoming messages d. Once a message arrives ( the STC polls - a - 
) e. The message is read and processed.
The messages are generated via a RACF exit ..

Scott J Ford
Software Engineer
http://www.identityforge.com/




 From: Sam Siegel 
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Wednesday, April 10, 2013 10:54 AM
Subject: Re: Storage and Tokens

Scott - I guess it depends on who needs to access the data and how they access 
it?  Same address space?  Different address space?  Serialization requirements? 
Etc.

Sam

On Wed, Apr 10, 2013 at 7:23 AM, Scott Ford  wrote:

> All:
>
> I have a storage related Assembler question, currently we :
>
> 1.  Do a Storage Obtain in Key=0
> 2.  Using IEANTCR insert a 16 byte storage token 3.  Add data to this
> area upon finding the token - IEANTRT 4.  Read data from this area
> upon finding the token - IEANTRT
>
> Is there another way , better ?
>
> Scott J Ford
> Software Engineer
> http://www.identityforge.com/
>

Re: Baseless problem

[Bernd Oppolzer]

Reading again:

there is no problem finding the (static) data, even if the USING point
is not
at the beginning of the module; if you have the load point of the
module, which
you get easily from CDE/XTLST, then you add the offsets of the variables
from
the CSECT.

Oh, I see, you are VSE normally - don't know how easy or difficult it is
to get
the load points of the modules in a VSE environment - but at least the
load point
of the abending module should be present at the top of a dump, even in VSE.

Kind regards

Bernd



Am 11.04.2013 23:22, schrieb Bernd Oppolzer:


For finding the variables in the dump, you should use the offsets in
the instructions, not the offsets in the assembly list - or: you have to
add the distance of the data area base.

Re: IFOX00/ASMH (Was: Baseless problem)

[Bernd Oppolzer]

I recall that one time when we reported an error to IBM where
an ASSEMBLER module was involved, we got the simple and short answer

"Customer should not use ASSEMBLER"

I don't recall what the problem was, maybe something involving DB2 and the
DB2 precompiler for ASSEMBLER ...


Am 11.04.2013 21:46, schrieb John Ehrman:

So "internal politics" is correct -- some IBM execs apparently believed that
PL/I would satisfy all future programming needs, and that Assembler
applications would disappear shortly.

Re: Baseless problem

[Bernd Oppolzer]

Although the eyecatcher on SAVE (one byte length field
at EPA+4 followed by the message) seems to be kind of part of
the OS linkage conventions, no other IBM language processor like the
PL/1 compiler or LE ever used it - I never understood this. This discourages
the use of SYSUDUMP for error diagnose heavily. Same goes for the lack
of forward save area chaining by LE - SYSUDUMP is only capable of printing
a forward save area chain, if the LSA pointers in the save areas are filled
correctly.

For decades, we tried to restore the forward chain on every call, by calling
special ASSEMBLER routines after every PL/1 procedure entry; just to
have the SYSUDUMP forward chain in the case of an error. What a mess!
In the end, we removed this, and wrote our own error recovery and dump
printing routine, which we use in every environment, and which does not
rely on the forward chain, like CEEDUMP - it restores the forward chain
only in the error situation, when needed - for us it works better than
CEEDUMP,
and it also works in environments where we don't have LE - in an LE
environment,
the dump printing routine is called by an LE exit and replaces CEEDUMP.

I sometimes had the impression that the designers of LE never talked
with the
opsys people and both didn't talk with the compiler people and vice
versa ...
how sad ...

Ok, I see one possible reason for this: LE has to work on EVERY opsys,
and so may not rely on features that are specific to a special opsys. This
may be the reasons for some of the trouble we have here.

Kind regards

Bernd




Am 11.04.2013 20:23, schrieb Andreas F. Geissbuehler:

Mike Shaw wrote:

Amen. I saw it first in code in 1976, with the eyecatcher preceded by a
one-byte length field for the eyecatcher. That one byte length is
used by
the dump formatter to print the eyecatchers when formatting the save
area
chain.


... and the eyecatcher, the 3rd operand of SAVE reg[,T,*]

181  SAVE  (14,12),T,'ACMDXL00 &VERS &ASMDTE'
182+ B 24(0,15)  BRANCH AROUND ID
01-SAVE
183+ DCAL1(19)   LENGTH OF IDENTIFIER
01-SAVE
184+ DCCL8'ACMDXL00' IDENTIFIER
01-SAVE
185+ DCCL8'  1.1 030' IDENTIFIER
01-SAVE
186+ DCCL3'102'  IDENTIFIER
01-SAVE
187+ STM   14,12,12(13)  SAVE REGISTERS
01-SAVE
188  LRR12,R15  LOAD PGM BASE REG = EP
ADDRESS

The above was assembled 10 years ago by HLASM R4.0. The SAVE macro is at
least 45 years old. Frequently the bytes following the eyecatcher /
dump-id
were used for version/PTF id's and for "global" address vector tables.

Andreas F. Geissbuehler




--
Bernd Oppolzer
---
*Oppolzer-Informatik
* Dipl. Inf. Bernd Oppolzer
Bärenhofstraße 23
70771 Leinfelden-Echterdingen
---
Tel.: +49 711 2272522
priv.: +49 711 7949590
eMail: bernd.oppol...@t-online.de 
---
Für Umsatzsteuerzwecke:
SteuerNr.: 97 076 / 29921
USt-ID-Nr.: DE 147 700 393
---
Jubiläumsjahr 2013:
30 Jahre Oppolzer-Informatik

Re: Baseless problem

[Bernd Oppolzer]

Slightly different opinion on my side:

I just expanded our local startup macro to support
baseless code areas. The standard startup macro especially for
main programs generates lots of instructions, that count for some
600 bytes (for example: error handling, buildung a LE environment etc.).
So I cannot have a base register for data at the beginning
of the program, because there resides this large startup macro.

And: the LTORG at the end of the program needs addressibility;
there also go the definitions created by the structured programming
macros, which are used in the code section.

So I did the following:

a) establish temporary base regs using R15 to support the startup
macro - it was not possible to get all the startup code baseless

b) drop temporary base

c) force the developers to have code first, then data

d) establish base regs only for the data section

So the code area is baseless and may grow. The data area starts with
a special macro which defines the base address, which is used in the
USING in the startup code.

For finding the variables in the dump, you should use the offsets in
the instructions, not the offsets in the assembly list - or: you have to
add the distance of the data area base.

Other features:

you specify an arbitrary number of base regs in the startup macro.

and you have 3 options:

BASREG=CODE: the base regs cover the code area, from the start
of the CSECT

BASREG=CODDAT: first base reg covers the code area, the second
and the following cover the data area

BASREG=DATA: the base regs cover the data area (true baseless
code area)

The definition and initialization of the registers is done by the startup
macro code.

Our ASSEMBLER coders are accustomed to use ASSEMBLER
almost like a high level language - they normally don't want to deal
with such things like addressibility issues. That's why we normally
use the structured programming macros exclusively, too.

Kind regards

Bernd




Am 11.04.2013 13:37, schrieb Martin Trübner:

Jon,

Enough been said about the reason and the cause (and solutions)

But who dictates techniques for vendors?

While your points are okay- the "trick" to have the definitions right
at the beginning of the module  (with just a J in front) is something
that makes sense for everyone. If you ever tried to calculate offset
in a DOB-program (data only base) from the start of the LTORG (or
wherever the base points to) knows what I  mean.

Credit for the technique goes to Ed J.

Martin

Re: Baseless problem

[Andreas F. Geissbuehler]

Tony Harminc wonders...

I can only guess at the internal politics in play at the time that
must have led to this project, when ASMH already existed and offered
so much more. IBM's usual internal competition, I suppose, but in such
a small subject area...


AFAIR... core..! hmm "virtual memory", sysgens and $$$

With the arrival of the 512K 370/155 our boss allowed a partition size
increase from 80K to 128K. Then the DAT-box and SVS. IFOX00 worked but was
awefully slow. ASMH costed money and needed 200K+ to assemble anything
substantial. The free ASMG from University of Waterloo became our saviour.

FWIW, more details in this post by Peter, dated 29 Mar 2008 18:40 here:
http://comments.gmane.org/gmane.comp.emulators.hercules390.mvs/6553
A lot of  "oddball"-stuff of today was shaped by the physical (and IBMs
legal!) constraints at the time it was conceived.

Andreas F. Geissbuehler

IFOX00/ASMH (Was: Baseless problem)

[John Ehrman]

Tony Harminc commented:

It's worth remembering that ASMH predates IFOX00. (Well, as far as
customer availability goes; I have no idea what went on inside IBM.)
I have never understood the point of IFOX00; it appears to be a
reimplemention from scratch to the IEUASM specs, with a couple of
trivial functional enhancements, and using reentrant code. Compared to
IEUASM it has no significant performance advantage, appears not to
exploit any particular aspects of virtual storage, the supported macro
and assembler language is essentially identical, diagnostics are no
better, and so on.

I can only guess at the internal politics in play at the time that
must have led to this project, when ASMH already existed and offered
so much more. IBM's usual internal competition, I suppose, but in such
a small subject area...


As I remember, ASMH came out in 1971, IFOX in 1972. IFOX was the "official"
assembler, while ASMH was an internal tool that was almost not announced
(it took a lot of  pressure from field SE's who insisted it made SYSGENs
possible in an afternoon rather than a weekend with ASMF/IEUASM). So
"internal politics" is correct -- some IBM execs apparently believed that
PL/I would satisfy all future programming needs, and that Assembler
applications would disappear shortly.

IFOX actually had some internal improvements that helped performance: the
second conditional-assembly and first final-assembly passes were merged, as
had also been done in the Waterloo G assembler; both were based on ASMF. I
doubt IFOX was a "from scratch" implementation.

I gave a short talk on Assembler History at the San Francisco SHARE
conference; look for the proceedings of session 12235.

John Ehrman

Re: Baseless problem

[Tony Harminc]

On 11 April 2013 10:32, Ed Jaffe  wrote:

> The oldest assembler I ever used was IFOX00. ISTR, it did not have
> support for LOCTR but my memory could be faulty.

It matches mine.

It's worth remembering that ASMH predates IFOX00. (Well, as far as
customer availability goes; I have no idea what went on inside IBM.) I
have never understood the point of IFOX00; it appears to be a
reimplemention from scratch to the IEUASM specs, with a couple of
trivial functional enhancements, and using reentrant code. Compared to
IEUASM it has no significant performance advantage, appears not to
exploit any particular aspects of virtual storage, the supported macro
and assembler language is essentially identical, diagnostics are no
better, and so on.

I can only guess at the internal politics in play at the time that
must have led to this project, when ASMH already existed and offered
so much more. IBM's usual internal competition, I suppose, but in such
a small subject area...

On the more on-topic matter of jumpifying and putting data at the
start of a module, it bears keeping in mind that it does locality of
reference no good to have a single branch/jump instruction at the
start of a module, followed by a large amount of data, and then code
continuing way down. While no-one may be paging the way they used to
these days, it still shouldn't be encouraged, and hopping down the
pages with one instruction reference each is not the thing to do. Even
on the smaller scale and much faster resolution time of cache lines,
it's probably not such a good thing.

Tony H.

Re: Baseless problem

[Andreas F. Geissbuehler]

Mike Shaw wrote:

Amen. I saw it first in code in 1976, with the eyecatcher preceded by a
one-byte length field for the eyecatcher. That one byte length is used by
the dump formatter to print the eyecatchers when formatting the save area
chain.


... and the eyecatcher, the 3rd operand of SAVE reg[,T,*]

181  SAVE  (14,12),T,'ACMDXL00 &VERS &ASMDTE'
182+ B 24(0,15)  BRANCH AROUND ID
01-SAVE
183+ DCAL1(19)   LENGTH OF IDENTIFIER
01-SAVE
184+ DCCL8'ACMDXL00' IDENTIFIER
01-SAVE
185+ DCCL8'  1.1 030' IDENTIFIER
01-SAVE
186+ DCCL3'102'  IDENTIFIER
01-SAVE
187+ STM   14,12,12(13)  SAVE REGISTERS
01-SAVE
188  LRR12,R15  LOAD PGM BASE REG = EP ADDRESS

The above was assembled 10 years ago by HLASM R4.0. The SAVE macro is at
least 45 years old. Frequently the bytes following the eyecatcher / dump-id
were used for version/PTF id's and for "global" address vector tables.

Andreas F. Geissbuehler

Re: Baseless problem

[Gerhard Postpischil]

On 4/11/2013 7:37 AM, Martin Trübner wrote:

While your points are okay- the "trick" to have the definitions right at
the beginning of the module  (with just a J in front) is something that
makes sense for everyone. If you ever tried to calculate offset in a
DOB-program (data only base) from the start of the LTORG (or wherever
the base points to) knows what I  mean.


The easiest way I've found to simplify debugging is to use page
alignment (at the start, add a PUNCH  ' ORDER csect(P) '). While IBM
actively discourages this (IEBCOPY throws a hissy fit for page aligned
modules), having the last three bytes of a dump address agree with the
assembled address is an enormous time-saver.

Gerhard Postpischil
Bradford, Vermont

Re: Baseless problem

[John Ehrman]

Ed Jaffe noted...

>The oldest assembler I ever used was IFOX00. ISTR, it did not
>have support for LOCTR but my memory could be faulty.

I think your memory is correct.

As I remember the IFOX assembler used basically the four-pass structure of
Assembler F.  It was developed and supported by a group in Lidingo Sweden
(a suburb of Stockholm?), and its popular publications were done by Jan
Sandzelius. (The Swedish group attended several SHARE conferences while
they were learning "skills transfers" from the assembler team in San Jose.)

I believe LOCTR was introduced with Assembler H. Due to its having merged
conditional assembly and ordinary-assembly pass 1, any time a location
counter discontinuity was found it had to establish LOCTR-like temporary
location counter that ASMH then resolved at the end of pass 1 in an
"interlude".  The LOCTR instruction was apparently a "public exposure" of
this internal facility.

More than you wanted to know, maybe...

Re: Baseless problem

[Steve Comstock]

On 4/11/2013 9:33 AM, Ed Jaffe wrote:

On 4/11/2013 7:55 AM, Mike Shaw wrote:

You are of course correct; my reference was to eyecatcher placement
after the initial instruction in the CSECT, which was a branch around
the eyecatcher and its length byte.


Ahhh. That's where the confusion comes from! :)

See pages 48-50 of my 2011 SHARE in Anaheim "Jumpify" presentation:
ftp://ftp.phoenixsoftware.com/pub/demo/Jumpify_Your_Code_2011.pdf

Getting the base register pointing to the physical start of a
no-code-base program is the focus of those three slides. The format of
the eyecatcher is unimportant.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/



Interesting tangents and diversions.

I wonder if the OP got his problem solved.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

Re: Baseless problem

[Scott Ford]

Guys:
 
I wanted to say a BIG THX...I got my code to assemble still working thru design 
and coding issues..but hey what's
life without a challenge or two or three...
 
Heres my new code..I had to changes things for obivious reasons.
 
SAMPLE01 AMODE 31
SAMPLE01 RMODE ANY
 YREGS
 PRINT OFF
 SYSSTATE ARCHLVL=2
 IEABRCX DEFINE
 PRINT ON
 J BEGIN
PROLOG   LOCTR
 DC    C'SAMPLE01 - xxx V4.7.0.2'
 DC    C'Assembled Date && Time: &SYSDATE &SYSTIME'
 DC    C'Copyright (C), Identityforge,LLC'
 DC    C'All rights reserved'
CODEBG1  LOCTR
BEGIN    DS    0H
 SAVE  (14,12)  save regs coming in
 LR    R12,R15
 AHI   R12,CONST-BEGIN
 USING CONST,R12
 LR    R10,R1
 USING WRKDSECT,R11 base parameter map
 USING EVXPL,R10    base parameter map
 L R4,EVXFLAGS  exit flag address
.
..
.
CONST    DC    0D
.(literal constants)
    LTORG
DATALOC1 LOCTR
DYNAMIC  DSECT
SAVEAREA DS    18F register save area
...
...
DYNSIZE  EQU   *-DYNAMIC   length of DSECT
DATALOC2 LOCTR
WRKDSECT DSECT
WRKSIZE  EQU   *-WRKDSECT  length of DSECT
 IHAPSA
 IHAASCB
 IHAASXB
 IRREVXP
 IEANTASM
 IHAACEE
 IKJTSB LIST=YES,EXT=YES
 
Something I would also like to comment on and share. I saw Jon Perryman's 
comments. I thank him for the suggestion but
still as a vendor we are the ones responsible for our code. Can it be done 
better, of course, but there is a way to suggest that.
 
Over the last couple of days a customer , tried to tell us that every vendor 
had to have their modules identify the vendor by its first 
three characters of a name. There were a few other ill-educated suggestions. I 
understand everyone has to learn but again there is a respectful way of 
suggesting this to a company, i.e.;  vendor. I would never try to tell a 
vendor, i.e.; IBM, how to code or
what to do, they have suggestion forms and forums for that. Maybe I am too old 
school..
 
 Regards,

Scott J Ford
Software Engineer
http://www.identityforge.com/

aka ...somewhere lost in NJ
 
 


 From: John McKown 
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 
Sent: Thursday, April 11, 2013 12:54 PM
Subject: Re: Baseless problem
  

He said that he did, IIRC.

On Thu, Apr 11, 2013 at 10:56 AM, Steve Comstock
 wrote:
> On 4/11/2013 9:33 AM, Ed Jaffe wrote:
>>

> I wonder if the OP got his problem solved.
>
> --
>
> Kind regards,
>
> -Steve Comstock
> The Trainer's Friend, Inc.
>
> 303-355-2752
> http://www.trainersfriend.com

Re: Baseless problem

[John McKown]

He said that he did, IIRC.

On Thu, Apr 11, 2013 at 10:56 AM, Steve Comstock
 wrote:
> On 4/11/2013 9:33 AM, Ed Jaffe wrote:
>>

> I wonder if the OP got his problem solved.
>
> --
>
> Kind regards,
>
> -Steve Comstock
> The Trainer's Friend, Inc.
>
> 303-355-2752
> http://www.trainersfriend.com

Re: Baseless problem

[DASDBILL2]

How about something like this: 

BEGIN   CSECT  

 USING BEGIN ,15 

 LR    12,15 

 DROP  1 5 

 USING BEGIN,12 

 B ORIGIN2 

ORIGIN1 EQU * 

  ORG   *+1000 

ORIGIN2 put all your executable code here, which includes references using base 
registers (this was 1976, remember) 

   . 

end of executable code 

    ORG   ORIGIN1 

LTORG , 

    ORG   , resume executable code 



Not that this would be useful, but I thihk this would get all the literals 
defined at the beginning.  Anyway, IBM has been putting a Branch instruction at 
the beginning of their modules, followed by much eyecatcher info, for a lot 
longer than "baseless" coding has been promulgated.  And doing that did not 
eliminate their need for base registers, either. 

Bill Fairchild 
Franklin, TN 


- Original Message -
From: "Ed Jaffe"  
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 
Sent: Thursday, April 11, 2013 10:11:19 AM 
Subject: Re: Baseless problem 

On 4/11/2013 7:45 AM, Paul Gilmartin wrote: 
> I believe LOCTR is fairly new.  Some of my co-workers are old 
> enough not to know about it.  Bitsavers would probably know, 
> but why bother. 

Why bother? I am curious to know how Mike Shaw observed the 
literals-physically-first technique implemented using 1976-era 
assemblers. Using HLASM, I don't know how to make literals physically 
precede the code that declares them without the use of LOCTR, but I'm 
willing to learn. 

-- 
Edward E Jaffe 
Phoenix Software International, Inc 
831 Parkview Drive North 
El Segundo, CA 90245 
http://www.phoenixsoftware.com/ 

Re: Baseless problem

[Ed Jaffe]

On 4/11/2013 7:55 AM, Mike Shaw wrote:

You are of course correct; my reference was to eyecatcher placement
after the initial instruction in the CSECT, which was a branch around
the eyecatcher and its length byte.


Ahhh. That's where the confusion comes from! :)

See pages 48-50 of my 2011 SHARE in Anaheim "Jumpify" presentation:
ftp://ftp.phoenixsoftware.com/pub/demo/Jumpify_Your_Code_2011.pdf

Getting the base register pointing to the physical start of a
no-code-base program is the focus of those three slides. The format of
the eyecatcher is unimportant.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Baseless problem

[Ed Jaffe]

On 4/11/2013 7:45 AM, Paul Gilmartin wrote:

I believe LOCTR is fairly new.  Some of my co-workers are old
enough not to know about it.  Bitsavers would probably know,
but why bother.


Why bother? I am curious to know how Mike Shaw observed the
literals-physically-first technique implemented using 1976-era
assemblers. Using HLASM, I don't know how to make literals physically
precede the code that declares them without the use of LOCTR, but I'm
willing to learn.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Baseless problem

[Mike Shaw]

On Thu, Apr 11, 2013 at 10:32 AM, Ed Jaffe wrote:

>
> The oldest assembler I ever used was IFOX00. ISTR, it did not have
> support for LOCTR but my memory could be faulty.
>
> 


You are of course correct; my reference was to eyecatcher placement after
the initial instruction in the CSECT, which was a branch around the
eyecatcher and its length byte.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

Re: Baseless problem

[Steve Hobson]

> The oldest assembler I ever used was IFOX00. ISTR, it did not have
> support for LOCTR but my memory could be faulty.

I cut my teeth on ACP. ACP assembler code included set symbols like &BG15 
(possibly still there in zTPF).
This naming is a relic of an Assembler that, AFAIK, pre-dated OS/360.
et symbol names were restricted (BASIC-like) to A/B/C (arithmetic, etc) 
G/L (global/local) then a number.

Best regards, Steve Hobson
Je me presse de rire de tout, de peur d'être obligé d'en pleurer
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: Baseless problem

[Paul Gilmartin]

On Apr 11, 2013, at 08:32, Ed Jaffe wrote:
>
> The oldest assembler I ever used was IFOX00. ISTR, it did not have
> support for LOCTR but my memory could be faulty.
>
I believe LOCTR is fairly new.  Some of my co-workers are old
enough not to know about it.  Bitsavers would probably know,
but why bother.

I once played with LOCTR until I created an unresolvable
expression in an address constant (no base-displacement
involved) with no symbols having been referenced prior
to their definitions.

-- gil

Re: Baseless problem

[Ed Jaffe]

On 4/11/2013 6:52 AM, Mike Shaw wrote:

On Thu, Apr 11, 2013 at 8:47 AM, Steve Comstock wrote:


..Well, Ed's super sharp but I think that technique has been
around a while.



Amen. I saw it first in code in 1976, with the eyecatcher preceded by a
one-byte length field for the eyecatcher. That one byte length is used by
the dump formatter to print the eyecatchers when formatting the save area
chain.


The oldest assembler I ever used was IFOX00. ISTR, it did not have
support for LOCTR but my memory could be faulty.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Baseless problem

[Mike Shaw]

On Thu, Apr 11, 2013 at 8:47 AM, Steve Comstock wrote:

> ..Well, Ed's super sharp but I think that technique has been
> around a while.
>
>
Amen. I saw it first in code in 1976, with the eyecatcher preceded by a
one-byte length field for the eyecatcher. That one byte length is used by
the dump formatter to print the eyecatchers when formatting the save area
chain.

--
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

Re: Baseless problem

[DASDBILL2]

From: "Steve Comstock"  
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 
Sent: Thursday, April 11, 2013 7:47:33 AM 
Subject: Re: Baseless problem 

>Interesting how COBOL-ish that part is: data division 
>before procedure division. 

“Plus ça change, plus c’est la même chose.”  (perhaps) 

Bill Fairchild 
Franklin, TN

Re: Baseless problem

[Steve Comstock]

On 4/11/2013 5:37 AM, Martin Trübner wrote:

Jon,

Enough been said about the reason and the cause (and solutions)

But who dictates techniques for vendors?

While your points are okay- the "trick" to have the definitions right at the
beginning of the module  (with just a J in front) is something that makes sense
for everyone. If you ever tried to calculate offset in a DOB-program (data only
base) from the start of the LTORG (or wherever the base points to) knows what I
mean.


Interesting how COBOL-ish that part is: data division
before procedure division.



Credit for the technique goes to Ed J.


Well, Ed's super sharp but I think that technique has
been around a while.



Martin





--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

Re: Baseless problem

[Paul Gilmartin]

On Apr 11, 2013, at 06:40, John McKown wrote:

> I agree. It is very nice.  Now to change my habits ... again. 
>
LOCTR can alleviate that impact.

> On Thu, Apr 11, 2013 at 6:37 AM, Martin Trübner  wrote:
>> Jon,
>>
>> Enough been said about the reason and the cause (and solutions)
>>
>> But who dictates techniques for vendors?
>>
>> While your points are okay- the "trick" to have the definitions right at the
>> beginning of the module  (with just a J in front) is something that makes
>> sense for everyone. If you ever tried to calculate offset in a DOB-program
>> (data only base) from the start of the LTORG (or wherever the base points
>> to) knows what I  mean.
>>
>> Credit for the technique goes to Ed J.

-- gil

Re: Baseless problem

[John McKown]

I agree. It is very nice.  Now to change my habits ... again. 

On Thu, Apr 11, 2013 at 6:37 AM, Martin Trübner  wrote:
> Jon,
>
> Enough been said about the reason and the cause (and solutions)
>
> But who dictates techniques for vendors?
>
> While your points are okay- the "trick" to have the definitions right at the
> beginning of the module  (with just a J in front) is something that makes
> sense for everyone. If you ever tried to calculate offset in a DOB-program
> (data only base) from the start of the LTORG (or wherever the base points
> to) knows what I  mean.
>
> Credit for the technique goes to Ed J.
>
> Martin
>
>



--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

Re: Baseless problem

[Martin Trübner]

Jon,

Enough been said about the reason and the cause (and solutions)

But who dictates techniques for vendors?

While your points are okay- the "trick" to have the definitions right at the beginning of the module  (with just a J in front) is something that makes sense for everyone. If you ever tried to calculate offset in a DOB-program (data only base) from the start of the LTORG (or wherever the base points to) knows what I  mean.

Credit for the technique goes to Ed J.  

Martin