John Perryman's post seems to have been written in ignorance of the
TRTE, TRanslate and Test Extended, instruction. Its availability
eliminates the need for his macro and otherwise much simplifies what
he proposes.
John Gilmore, Ashland, MA 01721 - USA
I would like to thank you all for your suggestions and for this discussion.
The reason why I will stay with my current logic (the large startup macro
at the beginning, followed by the code, followed by the static definitions)
is that there are several thousand existant programs which are not yet
On Fri, 12 Apr 2013 09:12:45 -0700, Scott Ford wrote:
> I have a field in a RACF parameter list ...CMDBUFL ..this is the length
> of the command buffer.
> It looks like it is x'F8' which is 248 ..bytes. I need to calculate the
> total length of CMDBUFD which is the incoming buffer. I have a issue
On Fri, 12 Apr 2013 16:23:47 -0700, Jon Perryman wrote:
>The total length of CMDBUFD is CMDBUFL.
>
>Since this is a command buffer, you don't know if it was cleaned up or if
>the command syntax was verified. I personally would not assume anything.
He said it's a RACF parameter list, and the only
The total length of CMDBUFD is CMDBUFL.
Since this is a command buffer, you don't know if it was cleaned up or if the
command syntax was verified. I personally would not assume anything. The length
may not always be X'F8'. You don't know if CONNECT begins at offset 0. Is CONN a
short form of the C
On 4/12/2013 9:27 AM, Scott Ford wrote:
This is a matter of style to me and experience level. I learned the
data areas and liberals at the tail end of your code ...always worked
for me. Doesn't mean that's the only way to to do II
Yes, those d**n liberals sneak in everywhere
My pet peeve are
Hey John:
To have some one get you, i.e.; overlay your storage if you are in Key 0, they
have to be in Key 0 and right PSW correct ?
Scott J Ford
Software Engineer
http://www.identityforge.com/
From: John McKown
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: F
New to list, but no way new to assembler. :)
Ken Meyer
CA
Technically, not "write protected" storage per se, but key 0 storage.
Which does make them write protected from most users.
On Fri, Apr 12, 2013 at 1:42 PM, Gerhard Postpischil wrote:
> On 4/12/2013 11:55 AM, John Gilmore wrote:
>>
>> Richard Peurifoy has been lucky, and perhaps others have been
> Some years ago, prior to IBM's adoption of the vendor table, I went
> to a
> conference. During my absence the local CA salesman, who happened to
> be
> golfing with the company president, talked him into doing performance
> measurement on our MVS system. One of my systems people installed
> thei
On 4/12/2013 11:55 AM, John Gilmore wrote:
Richard Peurifoy has been lucky, and perhaps others have been too, but
the basic difficulty remains. The use of these fields is
undocumented, in fact unpoliced, and thus also unwise.
As a long-time user of both CVTUSER and TCBUSER,
I have to disagree.
Guys:
I have a field in a RACF parameter list ...CMDBUFL ..this is the length of the
command buffer.
It looks like it is x'F8' which is 248 ..bytes. I need to calculate the total
length of CMDBUFD which is
the incoming buffer. I have a issue with a large amount of userids being passed
to our
There would be, I suppose, no objection to 'customer use' of these
fields if somehow it were possible to police their non-use by everyone
else.
Richard Peurifoy has been lucky, and perhaps others have been too, but
the basic difficulty remains. The use of these fields is
undocumented, in fact unp
> The CVTUSER and TCBUSER fields have always been worthless precisely
> because you can't count on them. There's no documented interface, so
> nobody actually uses them - or at least not without taking their
> hero pills and pulling on the kevlar undies first.
> CC
I have lost my hero pills, and m
Jon,
>> Sorry if I offended anyone. That was not my intent. "NEED TO" was not meant
>> to
dictate what vendors must do.
I was the one who . - It was my understanding (and English is not
my native language) of what you posted and my curiosity (but certainly
no offence felt here).
I also thou
On Fri, 12 Apr 2013 07:23:48 -0700, Jon Perryman wrote:
>Tom is not saying you should change your coding style.
Right.
>You leave the data areas and literals at the end of
>your source code. You add LOCTR statements into your
>program to change generated machine code sequence.
I would say "You
The quality of this discussion would be improved if a distinction between
1) the sequence of things in a source program and
2) the sequence of the corresponding entities in an assembled object program
were made and observed with some care.
John Gilmore, Ashland, MA 01721 - USA
Jon,
I understand what Tom said no problemo
Scott J Ford
Software Engineer
http://www.identityforge.com/
From: Jon Perryman
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Friday, April 12, 2013 10:23 AM
Subject: Re: Baseless problem
Tom is not saying you s
Steve,
A big absolutely I am a big learner...taught myself just a ton of
programming languages.
Its a nack
Scott J Ford
Software Engineer
http://www.identityforge.com/
From: Steve Comstock
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Friday, April
Tom is not saying you should change your coding style. You leave the data areas
and literals at the end of your source code. You add LOCTR statements into your
program to change generated machine code sequence.
Jon Perryman
- Original Message
> From: Scott Ford
> This is a matter of s
On 4/12/2013 7:43 AM, Scott Ford wrote:
I totally agree..Tom I think one has to be open to different techniques and
try them
It's a constant balance thing. When you have a
technique that works for you, then there's one
less set of decisions you need to make, allowing
you to focus on the cu
I totally agree..Tom I think one has to be open to different techniques and
try them
Scott ford
www.identityforge.com
Tell me and I'll forget; show me and I may remember; involve me and I'll
understand. - Chinese Proverb
On Apr 12, 2013, at 9:37 AM, Tom Marchant wrote:
> On Fri, 12 Apr
On Fri, 12 Apr 2013 09:27:37 -0400, Scott Ford wrote:
>This is a matter of style to me and experience level. I learned the data
areas and liberals at the tail end of your code
Right. If you *want* to put your constants and literals at the end, that's
your business. But when someone says that t
This is a matter of style to me and experience level. I learned the data areas
and liberals at the tail end of your code ...always worked for me. Doesn't mean
that's the only way to to do II
Scott ford
www.identityforge.com
Tell me and I'll forget; show me and I may remember; involve me and I'
Thomas,
There are a lot of well versed , heavily experienced , aka heavy hitters, here
on this listserv.
Scott ford
www.identityforge.com
Tell me and I'll forget; show me and I may remember; involve me and I'll
understand. - Chinese Proverb
On Apr 12, 2013, at 4:48 AM, Thomas Berg wrote:
>
Chris,
I like that , 2 pts very funny ...
Scott ford
www.identityforge.com
Tell me and I'll forget; show me and I may remember; involve me and I'll
understand. - Chinese Proverb
On Apr 12, 2013, at 4:38 AM, Chris Craddock wrote:
>> :>The next most efficient technique after using a sanct
>> ... helpful to place an ad-con to the beginning of the module
Sure - that takes the human factor out of calculating the correct start
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
On Thu, 11 Apr 2013 23:43:04 +0200, Bernd Oppolzer wrote:
>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,
The language conventions are defined in the Assembler Services Guide. An
eyecatcher is not
We have found it very helpful to place an ad-con to the beginning of the
module as the first thing in the "static area" (where the base reg points
in a relative-addressing module).
Peter Relson
z/OS Core Technology Design
On Thu, 11 Apr 2013 23:22:15 +0200, Bernd Oppolzer wrote:
>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 en
On Thu, 11 Apr 2013 08:11:19 -0700, Ed Jaffe wrote:
>On 4/11/2013 7:45 AM, Paul Gilmartin wrote:
>> I believe LOCTR is fairly new.
>
>I am curious to know how Mike Shaw observed the
>literals-physically-first technique implemented using 1976-era
>assemblers.
See pages 4 and 6 of the Assembler H L
And there was also HSK - the assembler generator. You can read a little
about it here: http://www.romanredz.se/cv.htm#ibm (Roman's history with
IBM - it's rather interesting).
We used HSK at IBM Hursley for a few projects, notably to create an
assembler for the Motorola 68xx family. I still have
Sometimes when I'm reading this list or IBM-MAIN I got a feeling like as I was
listening to a historic science discussion where now and then Titus Livius and
Thucydides pop in with anecdotes... :)
(No offence please! I'm very impressed by all.)
Regards
Thomas Berg
_
> :>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.
Nope. It's for vendors - mainly to keep them
34 matches
Mail list logo
