Re: IBM Component Codes. was: Re: IBM customer anchor

[Brian Westerman]

Both of those are macros, modules, source code and panels, which are also very 
important, but that original question and subject (for me) was about message 
prefixes.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Brian Westerman]

Peter sent me the email address.  I think we probably were originally assigned 
back in the 1980's (or 90's), but I figured it would not hurt to ask them if 
"SYZ" was assigned to us.  I found some information in some manuals, but that 
seems to be related to naming your modules, not the messages you generate.  Any 
way, I'll let you know what I get back from them on the subject.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[scott Ford]

Brian,

I wasn't aware either, we go through Partnerworld. Then someone, not sure
who, assigned us (IDMWORKS) the three character message/module prefix. The
I asked IBM for our customer anchor, Peter kindly responded with it.

Regards,
Scott

On Sun, Jul 2, 2017 at 11:57 AM Tony Harminc  wrote:

> On 2 July 2017 at 10:15, Charles Mills  wrote:
> > I think you would risk trademark issues as well as name collision issues
> if you used iBM. And yes, IBM claims the entire space AAA-I99 or perhaps
> J99, including IBM.
>
> In fact the specific prefix IBM was assigned 30+ years ago to the PL/I
> runtime library. Doubtless this is another example of product authors
> or their management gaming the system. See also the JES2 macros and
> control blocks like $DILBERT and $DOGBERT.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Tony Harminc]

On 2 July 2017 at 10:15, Charles Mills  wrote:
> I think you would risk trademark issues as well as name collision issues if 
> you used iBM. And yes, IBM claims the entire space AAA-I99 or perhaps J99, 
> including IBM.

In fact the specific prefix IBM was assigned 30+ years ago to the PL/I
runtime library. Doubtless this is another example of product authors
or their management gaming the system. See also the JES2 macros and
control blocks like $DILBERT and $DOGBERT.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Charles Mills]

I think you would risk trademark issues as well as name collision issues if you 
used iBM. And yes, IBM claims the entire space AAA-I99 or perhaps J99, 
including IBM. I suspect all of the assignments are case-insensitive or what is 
the right word? Cross-case or case-agnostic? Something like that. 

Someone just posted on another thread the address to write to. Element or 
Elements at IBM.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, July 1, 2017 10:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM customer anchor

On Fri, 30 Jun 2017 07:37:59 -0400, Peter Relson wrote:

>>Are you saying we are better off, using our IBM assigned message 
>>prefix ..which is MDI ...as part of our Token we use ?
>
>Yes, definitely.
> 
How should this apply to items in the UNIX filesystem?  I know there are 
pathnames like .../com.ibm..., which follows a convention used more broadly in 
the industry than only by IBM.

Are assigned prefixes case sensitive?  I assume "IBM" is registered to IBM by 
IBM.  Does this include all 8 letter case variants?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

IBM Component Codes. was: Re: IBM customer anchor

[Graeme Gibson]

Brian, all,

ASE has been using IBM's component code assignment service for many years and 
we now have several assigned to us.

Just email "elem...@us.ibm.com" and request the 3-character component code that 
you desire.   These K.C. entries explain all :

https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.gimb100/gimpkg80125.htm

https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.gimb100/gimpkg80127.htm

Cheers,
Graeme Gibson
--/
Graeme Gibson.Director - enterprise systems services
Australian Systems Engineering Pty. Ltd.  ("ASE")
cell:  0427 328 937 internat:  +61 427 328 937
LTXF, OMCS, SLIKSFTP, SLIKSFTM, SLIKZIP //_http://www.ase.com.au_/ 
///_http://www.slikzip.com_/ 
On 2/07/2017 1:00 PM, Brian Westerman wrote:

What IBM assigned message prefix?  I never heard that we were supposed to 
request one, we have been using SYZpnnnX for almost 30 years and I don't think 
I have heard that we ever needed or received an assignment.

Who do I need to speak with to get ours reserved?

Brian





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Paul Gilmartin]

On Fri, 30 Jun 2017 07:37:59 -0400, Peter Relson wrote:

>>Are you saying we are better off, using our IBM assigned message prefix
>>..which is MDI ...as part of our Token we use ?
>
>Yes, definitely.
> 
How should this apply to items in the UNIX filesystem?  I know there
are pathnames like .../com.ibm..., which follows a convention used
more broadly in the industry than only by IBM.

Are assigned prefixes case sensitive?  I assume "IBM" is registered to
IBM by IBM.  Does this include all 8 letter case variants?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Paul Gilmartin]

On Sat, 1 Jul 2017 22:00:14 -0500, Brian Westerman wrote:

>What IBM assigned message prefix?  I never heard that we were supposed to 
>request one, we have been using SYZpnnnX for almost 30 years and I don't think 
>I have heard that we ever needed or received an assignment.
>
>Who do I need to speak with to get ours reserved?
> 
I think this was discussed very recently in this forum, but I couldn't find
it in the archives.  Something about email to ??@IBM.com.  So I
did a Google search for "vendor prefix site:ibm.com".  Still no luck.  This
shouldn't be secret; I submitted an RCF and already have Thank you for
your feedback":

Hello, MHVRCFs,

In :• z/OS 2.1.0
• z/OS MVS
• z/OS MVS Programming: Sysplex Services Guide
• Sysplex Services for Communication (XCF)
• SA23-1400-00
• Using XCF for client/server communication
• Defining and starting a server
• Overview of IXCSRVR
• Server naming conventions
I read:
... component prefix. For other software vendors, this is the unique prefix
assigned by IBM to the vendor. ...

This should explain to the "other software vendor" how to go about
obtaining an assigned component prefix.

This omission may affect other publications.

Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Brian Westerman]

What IBM assigned message prefix?  I never heard that we were supposed to 
request one, we have been using SYZpnnnX for almost 30 years and I don't think 
I have heard that we ever needed or received an assignment.

Who do I need to speak with to get ours reserved?

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Peter Relson]

>If my company has a 3 character prefix reserved with 
>the VSE group, does that cross into z/OS?

I do not know what "reserved with the VSE group" translates to.
My guess woult be that the assignment of prefix is operating system 
agnostic.
And that there is only one reservation process. But that's just a guess.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[J R]

The right thing to do is obvious.  The major problem, though, is that the right 
thing being done is on the honor system.  Obviously, some of the biggest 
players in the arena are antisocial enough to believe that being honorable and 
doing what's right are not applicable to them. 

> On Jun 24, 2017, at 00:33, Brian Westerman  
> wrote:
> 
> When you think about it though, we really could not force them to do 
> anything, we could have complained to Peter or IBM, but that doesn't really 
> mean that they (IBM) have any real pull with a place like CA either.  In the 
> end it has to be that the person or vendor who was violating the policy has 
> to "do the right thing".

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[scott Ford]

Peter,
Thank you for your help much appreciated.

Scott
IDMWORKS

On Fri, Jun 30, 2017 at 7:44 AM, Tony Thigpen  wrote:

> Peter,
>
> Stupid question. If my company has a 3 character prefix reserved with the
> VSE group, does that cross into z/OS? Or, do we need to reserve one though
> the z/OS side also. (We are considering porting one of our products to
> z/OS.)
>
> Tony Thigpen
>
>
> Peter Relson wrote on 06/30/2017 07:37 AM:
>
>> Are you saying we are better off, using our IBM assigned message prefix
>>> ..which is MDI ...as part of our Token we use ?
>>>
>>
>> Yes, definitely.
>>
>> When name collisions would be a problem, the best approach is to begin
>> with "your" prefix.
>>
>> In general, names beginning with A-I and SYS are reserved for use by IBM.
>>
>> Peter Relson
>> z/OS Core Technology Design
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Tony Thigpen]

Peter,

Stupid question. If my company has a 3 character prefix reserved with 
the VSE group, does that cross into z/OS? Or, do we need to reserve one 
though the z/OS side also. (We are considering porting one of our 
products to z/OS.)


Tony Thigpen

Peter Relson wrote on 06/30/2017 07:37 AM:

Are you saying we are better off, using our IBM assigned message prefix
..which is MDI ...as part of our Token we use ?


Yes, definitely.

When name collisions would be a problem, the best approach is to begin
with "your" prefix.

In general, names beginning with A-I and SYS are reserved for use by IBM.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Peter Relson]

>Are you saying we are better off, using our IBM assigned message prefix
>..which is MDI ...as part of our Token we use ?

Yes, definitely.

When name collisions would be a problem, the best approach is to begin 
with "your" prefix.

In general, names beginning with A-I and SYS are reserved for use by IBM.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Paul Gilmartin]

On Thu, 29 Jun 2017 23:02:22 +, scott Ford wrote:
>
>Are you saying we are better off, using our IBM assigned message prefix
>..which is MDI ...as part of our Token we use ?
> 
I believe he was more specific:
On Mon, 26 Jun 2017 08:28:06 -0400, Peter Relson wrote:
>... it has always been recommended that things like module and 
>macro names, message IDs, name/token names, dynamic exit names, and many 
>other things all begin with a prefix owned by the company that is using 
>the name/ID.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[scott Ford]

Peter,

Are you saying we are better off, using our IBM assigned message prefix
..which is MDI ...as part of our Token we use ?

Scott

On Wed, Jun 28, 2017 at 7:47 AM Peter Relson  wrote:

> >Yes, I agree, we use IDENTI...
>
> I would say that that is wholly unacceptable unless you own the prefix
> IDE. If IBM creates a token that happens to collide then we may expect and
> require you to change. Is that likely? No. Is it conceivable? Yes. Some
> prefixes within the IBM range that had been appropriated by ISV's were
> grandfathered for use by the "offender". That was quite a long time ago
> now. I don't see that happening again since the process for an ISV to
> obtain a prefix has also existed for a long time now.
>
> A protocol is only as good as those who follow it. The naming protocol has
> served the platform well for 50-ish years. You should make an effort not
> to break it.
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Peter Relson]

>Yes, I agree, we use IDENTI...

I would say that that is wholly unacceptable unless you own the prefix 
IDE. If IBM creates a token that happens to collide then we may expect and 
require you to change. Is that likely? No. Is it conceivable? Yes. Some 
prefixes within the IBM range that had been appropriated by ISV's were 
grandfathered for use by the "offender". That was quite a long time ago 
now. I don't see that happening again since the process for an ISV to 
obtain a prefix has also existed for a long time now.

A protocol is only as good as those who follow it. The naming protocol has 
served the platform well for 50-ish years. You should make an effort not 
to break it.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[scott Ford]

Brian,

Yes, I agree, we use IDENTI...

Scott

On Tue, Jun 27, 2017 at 12:42 AM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> With the NAME/TOKEN, it would be pretty hard to accidentally use the same
> token name (assuming you give your token a non-generic name).  For ours
> they all start with "Syzygy_somthing" or "Syz_somethingelse" and since you
> have 16 bytes to play with you would have to try pretty hard to
> "accidentally" use it.
>
> At first we were worried that "Syz" was close to "Sys" but when it came
> down to it, there were too many other characters in the name(s) that
> chances of reusing someone else's was deemed to be extremely low.
>
> I have since noticed that a lot of vendors even use non-readable
> characters to be really sure they are unique.  We have considered doing
> something like that, but decided that seeing Syz was important if we ever
> actually had a problem that warranted a dump.
>
> Brian
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Brian Westerman]

With the NAME/TOKEN, it would be pretty hard to accidentally use the same token 
name (assuming you give your token a non-generic name).  For ours they all 
start with "Syzygy_somthing" or "Syz_somethingelse" and since you have 16 bytes 
to play with you would have to try pretty hard to "accidentally" use it.  

At first we were worried that "Syz" was close to "Sys" but when it came down to 
it, there were too many other characters in the name(s) that chances of reusing 
someone else's was deemed to be extremely low.  

I have since noticed that a lot of vendors even use non-readable characters to 
be really sure they are unique.  We have considered doing something like that, 
but decided that seeing Syz was important if we ever actually had a problem 
that warranted a dump.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Peter Relson]

>What precludes collisions of name/tokens? 
>Simply bigger name space?

Nothing precludes collisions of anything. This is one big sometimes-happy 
family among IBM, ISVs, and customers and I think that those who play by 
the rules tend to be happiest.

This is why it has always been recommended that things like module and 
macro names, message IDs, name/token names, dynamic exit names, and many 
other things all begin with a prefix owned by the company that is using 
the name/ID.

Regarding clobbering of someone's customer anchor table slot:
Of course that's possible since anyone in key 0 can clobber anything 
(whether accidentally or maliciously or even intentionally with misguided 
but not malicious intent). And that includes your name/token name (it's 
just harder to find) which, if changed, would then make your name/token 
retrieve fail.

Some overlays can be detected and corrected, others have limited effect, 
others might bring the system down.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[scott Ford]

We belong to Partnerworld and I sent a request and Peter responded so we
now have an anchor address.

Scott


On Sat, Jun 24, 2017 at 12:33 AM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> I think it was just a matter of who sent the letter.  When it came from a
> competitor, they were aggressive, but when it came from a lawyer,
> especially as it was from a big firm, they gave up fairly quickly.
>
> When you think about it though, we really could not force them to do
> anything, we could have complained to Peter or IBM, but that doesn't really
> mean that they (IBM) have any real pull with a place like CA either.  In
> the end it has to be that the person or vendor who was violating the policy
> has to "do the right thing".
>
> Brian
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Brian Westerman]

I think it was just a matter of who sent the letter.  When it came from a 
competitor, they were aggressive, but when it came from a lawyer, especially as 
it was from a big firm, they gave up fairly quickly.

When you think about it though, we really could not force them to do anything, 
we could have complained to Peter or IBM, but that doesn't really mean that 
they (IBM) have any real pull with a place like CA either.  In the end it has 
to be that the person or vendor who was violating the policy has to "do the 
right thing".

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Mike Schwab]

If they register a three letter message prefix with IBM then they are left
with 5 characters for individual products/requests.

On Thursday, June 22, 2017, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 22 Jun 2017 01:00:46 -0500, Brian Westerman wrote:
>
> >I know we had to contact CA and Sterling, as well as Landmark Systems
> about using our offset.  The only one that gave us a hard time about it was
> CA, who told us they "had it first", and then tried both money and threats
> to have us give it up and go back and ask for another one.  I believe our
> legal-eze, highly professional response was something like "pound salt".
> >
> I assume that worked.  Good.  What was your legal ground:
> o Implied warranty of merchantability?  But any clever vendor will
>   expressly disclaim that "to the extent permitted by state law".
> o Contract language to that effect?
> o Pound salt?
>
> Had CA squatted on their claim before IBM established a registry?
>
> >... we decided that name/tokens were probably a better way to go ...
> >
> What precludes collisions of name/tokens?  Simply bigger name space?
> But remember the birthday problem -- pretty soon someone will suffer.
> "com.syzygyinc.xx"?  (16 isn't enough!)
>
> --gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>


-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Gord Tomlin]

On 2017-06-22 13:04, Paul Gilmartin wrote:

Had CA squatted on their claim before IBM established a registry?


IIRC Peter Relson established the registry when he first established the 
table.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Paul Gilmartin]

On Thu, 22 Jun 2017 01:00:46 -0500, Brian Westerman wrote:

>I know we had to contact CA and Sterling, as well as Landmark Systems about 
>using our offset.  The only one that gave us a hard time about it was CA, who 
>told us they "had it first", and then tried both money and threats to have us 
>give it up and go back and ask for another one.  I believe our legal-eze, 
>highly professional response was something like "pound salt".
>
I assume that worked.  Good.  What was your legal ground:
o Implied warranty of merchantability?  But any clever vendor will
  expressly disclaim that "to the extent permitted by state law".
o Contract language to that effect?
o Pound salt?

Had CA squatted on their claim before IBM established a registry?

>... we decided that name/tokens were probably a better way to go ...
> 
What precludes collisions of name/tokens?  Simply bigger name space?
But remember the birthday problem -- pretty soon someone will suffer.
"com.syzygyinc.xx"?  (16 isn't enough!)

--gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Brian Westerman]

I know we had to contact CA and Sterling, as well as Landmark Systems about 
using our offset.  The only one that gave us a hard time about it was CA, who 
told us they "had it first", and then tried both money and threats to have us 
give it up and go back and ask for another one.  I believe our legal-eze, 
highly professional response was something like "pound salt".

I could be missing some vendors, but I think the rest of the times we had to 
debug the problem were "normal" sites that they themselves decided the offset 
was "safe" to use.  They would just choose another "safe to use" one and 
sometimes we helped them re-write and we would never have that particular issue 
again, but it became a big enough issue over time that we decided that 
name/tokens were probably a better way to go for most of the new features we 
add and we stopped adding things to our table.  We still use it though, but I 
think the direction we are moving is to eventually eliminate it's use.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Paul Gilmartin]

On Wed, 21 Jun 2017 08:36:17 -0400, Peter Relson wrote:

>>one problem we kept running into was that not everyone 
>>registered their use with IBM and apparently we had some 
>>people's favorite offset number, so occasionally we 
>>would have people step on us.
>
>If you have any detailed information on this (such as anything that might 
>identify the culprit), perhaps you could share it offline with me.
>
>I truly find it rather hard to believe that anyone would be so 
>irresponsible as to do this..
> 
And there's little practical defense.  Requiring authentication won't
work because the offender was probably APF-authorized.  Is this
perhaps a license violation?  But it's not worth the legal fees to
pursue.

Name/token has a similar weakness.  Might the vendor rely on
embedding a registered trademark or domain name (16 characters
is too few) in the name?  But enforcement remains a problem.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Peter Relson]

>one problem we kept running into was that not everyone 
>registered their use with IBM and apparently we had some 
>people's favorite offset number, so occasionally we 
>would have people step on us.

If you have any detailed information on this (such as anything that might 
identify the culprit), perhaps you could share it offline with me.

I truly find it rather hard to believe that anyone would be so 
irresponsible as to do this..

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[scott Ford]

Guys:

My friend another vendor says it was good as a jumping off point , aka
Vector to point to for example our routines.
I can see advantages and advantages to NAME/TOKEN,  we use that now.  What
started this process was we need a way to pass information to an exit like
LOGEVX01 or TSSINSTX and the first item came to mind was NAME/TOKEN, then
my asso ciate mentioned anchor table...we all ready have our xxx product
codes.

Scott

On Thu, Jun 15, 2017 at 10:10 AM, Charles Mills <charl...@mcn.org> wrote:

> > occasionally we would have people step on us
>
> We have not run into that problem, fortunately.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Westerman
> Sent: Wednesday, June 14, 2017 5:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IBM customer anchor
>
> We have several products on the market and while we exclusively used to
> use the anchor when we start(ed) our Syzygy subsystem, it's now just one of
> several way we keep track of things.  We still support it being there
> (after all we "own" the registration of the slot), but we mostly use the
> name/token facility now (one for the subsystem and one per product, and
> then each of the products has between 1 and "many" that can be active at a
> time).  Actually our IBM anchor points to a Vtable which includes those
> name/token addresses (we didn't trust the name/token facility at first so
> we keep track of everything we do with them 'just in case") and we have a
> name/token that points back to the anchor (just in case).
>
> There are advantages to the anchor entry, but one problem we kept running
> into was that not everyone registered their use with IBM, and apparently we
> had some people's favorite offset number, so occasionally we would have
> people step on us.  Debugging who that was was not always easy at all.
> Especially when it was something that one of the local site sysprogs
> "copied" from one of their old job sites.
>
> So, while the anchor is very useful and quite simple to maintain, so are
> name/tokens and we don't have to ask anyone to use them.  If you are
> marketing software that can use the anchor, I highly suggest you ask for a
> slot, but you may not end up using it to the extent that you think you will.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Charles Mills]

> occasionally we would have people step on us

We have not run into that problem, fortunately.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Wednesday, June 14, 2017 5:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM customer anchor

We have several products on the market and while we exclusively used to use the 
anchor when we start(ed) our Syzygy subsystem, it's now just one of several way 
we keep track of things.  We still support it being there (after all we "own" 
the registration of the slot), but we mostly use the name/token facility now 
(one for the subsystem and one per product, and then each of the products has 
between 1 and "many" that can be active at a time).  Actually our IBM anchor 
points to a Vtable which includes those name/token addresses (we didn't trust 
the name/token facility at first so we keep track of everything we do with them 
'just in case") and we have a name/token that points back to the anchor (just 
in case).

There are advantages to the anchor entry, but one problem we kept running into 
was that not everyone registered their use with IBM, and apparently we had some 
people's favorite offset number, so occasionally we would have people step on 
us.  Debugging who that was was not always easy at all.  Especially when it was 
something that one of the local site sysprogs "copied" from one of their old 
job sites.

So, while the anchor is very useful and quite simple to maintain, so are 
name/tokens and we don't have to ask anyone to use them.  If you are marketing 
software that can use the anchor, I highly suggest you ask for a slot, but you 
may not end up using it to the extent that you think you will.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Brian Westerman]

We have several products on the market and while we exclusively used to use the 
anchor when we start(ed) our Syzygy subsystem, it's now just one of several way 
we keep track of things.  We still support it being there (after all we "own" 
the registration of the slot), but we mostly use the name/token facility now 
(one for the subsystem and one per product, and then each of the products has 
between 1 and "many" that can be active at a time).  Actually our IBM anchor 
points to a Vtable which includes those name/token addresses (we didn't trust 
the name/token facility at first so we keep track of everything we do with them 
'just in case") and we have a name/token that points back to the anchor (just 
in case).

There are advantages to the anchor entry, but one problem we kept running into 
was that not everyone registered their use with IBM, and apparently we had some 
people's favorite offset number, so occasionally we would have people step on 
us.  Debugging who that was was not always easy at all.  Especially when it was 
something that one of the local site sysprogs "copied" from one of their old 
job sites.

So, while the anchor is very useful and quite simple to maintain, so are 
name/tokens and we don't have to ask anyone to use them.  If you are marketing 
software that can use the anchor, I highly suggest you ask for a slot, but you 
may not end up using it to the extent that you think you will.

Brian Westerman
Syzygy Incorporated

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[John McKown]

On Wed, Jun 14, 2017 at 10:25 AM, Charles Mills  wrote:

> NAME/TOKEN would be a lot more flexible and would not require IBM's
> involvement but I have to think the code path for the anchor is a heck of a
> lot shorter, at least not counting any validation of version, length, etc.
>
>  L 15,16Load CVT from PSA
>  L 15,X'8C'(,15)Load ECVT from CVT
>  L 15,X'CC'(,15)Customer Anchor Table from ECVT
>  ICM   15,B'',nnn(15)   Ptr f/Cust Anch
>  JZNotThere Not running
>
> Charles
>

​So, for a vendor with a product, the above is a very good solution. They
are likely already in "cahoots" with IBM anyway. And for somebody, such as
maybe me, who is doing something useful "for fun" (maybe even to distribute
via CBT), then NAME/TOKEN would be simpler and likely acceptable.​


-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Charles Mills]

NAME/TOKEN would be a lot more flexible and would not require IBM's involvement 
but I have to think the code path for the anchor is a heck of a lot shorter, at 
least not counting any validation of version, length, etc.

 L 15,16Load CVT from PSA
 L 15,X'8C'(,15)Load ECVT from CVT
 L 15,X'CC'(,15)Customer Anchor Table from ECVT
 ICM   15,B'',nnn(15)   Ptr f/Cust Anch
 JZNotThere Not running

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, June 13, 2017 6:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM customer anchor

On Tue, Jun 13, 2017 at 5:44 PM, Charles Mills <charl...@mcn.org> wrote:

> As a user of the word, you really, really want to think about upward 
> compatibility. Don't store the address of your product's anchor table 
> there. Assume you will someday have multiple products. You would want 
> to store the address of a vector of anchor table addresses. Think 
> about upward compatibility for the layout. Include a length and a 
> version number in your vector. Clear everything unused to zero. Think 
> about how your products will cooperate if product A starts up first; or if 
> product B starts up first.
>
> Think about how your customer will recover without an IPL if the 
> tables become corrupted.
>
> Charles
>

​Hum, I'm likely missing something, but my thought is to just use a global 
NAME/TOKEN pair​. Of course, I don't know the relative CPU efficiency of using 
that versus "chain chasing" from the CVT. If necessary, the NAME portion could 
be an initialization parameter just in case some other "product" used the same 
one. It could be set via a configuration CSECT, which is compiled into the 
execution library & LOADed. Or specified in the PARM= on the EXEC. Or even in a 
DSN specified using a DD. For the truly weird, make the "configuration 
repository" a "hard coded" UNIX file name such as /etc/.conf where 
 depends on what you call your product (e.g. /etc/sdsf.conf for the 
SDSF parameters).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[scott Ford]

Steve,

This is exactly as Charles stated we want to do.

Scott

On Tue, Jun 13, 2017 at 10:51 PM Steve Thompson  wrote:

> On 06/13/2017 09:06 PM, John McKown wrote:
> > On Tue, Jun 13, 2017 at 5:44 PM, Charles Mills  wrote:
> >
> >> As a user of the word, you really, really want to think about upward
> >> compatibility. Don't store the address of your product's anchor table
> >> there. Assume you will someday have multiple products. You would want to
> >> store the address of a vector of anchor table addresses. Think about
> upward
> >> compatibility for the layout. Include a length and a version number in
> your
> >> vector. Clear everything unused to zero. Think about how your products
> will
> >> cooperate if product A starts up first; or if product B starts up first.
> >>
> >> Think about how your customer will recover without an IPL if the tables
> >> become corrupted.
> >>
> >> Charles
> >>
> >
> > ​Hum, I'm likely missing something, but my thought is to just use a
> global
> > NAME/TOKEN pair​. Of course, I don't know the relative CPU efficiency of
> > using that versus "chain chasing" from the CVT. If necessary, the NAME
> > portion could be an initialization parameter just in case some other
> > "product" used the same one. It could be set via a configuration CSECT,
> > which is compiled into the execution library & LOADed. Or specified in
> the
> > PARM= on the EXEC. Or even in a DSN specified using a DD. For the truly
> > weird, make the "configuration repository" a "hard coded" UNIX file name
> > such as /etc/.conf where  depends on what you call your
> > product (e.g. /etc/sdsf.conf for the SDSF parameters).
> 
>
> Me thinks you are missing something.
>
> However, data set names and/or code paths are an interesting
> thing to hold in your storage that is anchored out of the User's
> Anchor Table.
>
> When I started working with this many years ago, I immediately
> started thinking about how to use that anchor point to allow
> cross product communications, should ACS ever acquire another
> company that had a product.
>
> So as Charles Mills said, one really needs to think about how to
> use this (and now I will add to what he said) before one paints
> themselves into a corner and this anchor point becomes a problem.
>
> That "Think about how your customer will recover without an IPL
> if the tables become corrupted." is a very interesting statement.
>
> So, running a chain to get to your anchor is not that big of a
> deal, AND, if your product is starting up, it can, from any
> address space, find out if it had been running, or if any of its
> compatriots are running and change its start up code paths
> accordingly.
>
> Regards,
> Steve Thompson
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Steve Thompson]

On 06/13/2017 09:06 PM, John McKown wrote:

On Tue, Jun 13, 2017 at 5:44 PM, Charles Mills  wrote:


As a user of the word, you really, really want to think about upward
compatibility. Don't store the address of your product's anchor table
there. Assume you will someday have multiple products. You would want to
store the address of a vector of anchor table addresses. Think about upward
compatibility for the layout. Include a length and a version number in your
vector. Clear everything unused to zero. Think about how your products will
cooperate if product A starts up first; or if product B starts up first.

Think about how your customer will recover without an IPL if the tables
become corrupted.

Charles



​Hum, I'm likely missing something, but my thought is to just use a global
NAME/TOKEN pair​. Of course, I don't know the relative CPU efficiency of
using that versus "chain chasing" from the CVT. If necessary, the NAME
portion could be an initialization parameter just in case some other
"product" used the same one. It could be set via a configuration CSECT,
which is compiled into the execution library & LOADed. Or specified in the
PARM= on the EXEC. Or even in a DSN specified using a DD. For the truly
weird, make the "configuration repository" a "hard coded" UNIX file name
such as /etc/.conf where  depends on what you call your
product (e.g. /etc/sdsf.conf for the SDSF parameters).



Me thinks you are missing something.

However, data set names and/or code paths are an interesting 
thing to hold in your storage that is anchored out of the User's 
Anchor Table.


When I started working with this many years ago, I immediately 
started thinking about how to use that anchor point to allow 
cross product communications, should ACS ever acquire another 
company that had a product.


So as Charles Mills said, one really needs to think about how to 
use this (and now I will add to what he said) before one paints 
themselves into a corner and this anchor point becomes a problem.


That "Think about how your customer will recover without an IPL 
if the tables become corrupted." is a very interesting statement.


So, running a chain to get to your anchor is not that big of a 
deal, AND, if your product is starting up, it can, from any 
address space, find out if it had been running, or if any of its 
compatriots are running and change its start up code paths 
accordingly.


Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[John McKown]

On Tue, Jun 13, 2017 at 5:44 PM, Charles Mills  wrote:

> As a user of the word, you really, really want to think about upward
> compatibility. Don't store the address of your product's anchor table
> there. Assume you will someday have multiple products. You would want to
> store the address of a vector of anchor table addresses. Think about upward
> compatibility for the layout. Include a length and a version number in your
> vector. Clear everything unused to zero. Think about how your products will
> cooperate if product A starts up first; or if product B starts up first.
>
> Think about how your customer will recover without an IPL if the tables
> become corrupted.
>
> Charles
>

​Hum, I'm likely missing something, but my thought is to just use a global
NAME/TOKEN pair​. Of course, I don't know the relative CPU efficiency of
using that versus "chain chasing" from the CVT. If necessary, the NAME
portion could be an initialization parameter just in case some other
"product" used the same one. It could be set via a configuration CSECT,
which is compiled into the execution library & LOADed. Or specified in the
PARM= on the EXEC. Or even in a DSN specified using a DD. For the truly
weird, make the "configuration repository" a "hard coded" UNIX file name
such as /etc/.conf where  depends on what you call your
product (e.g. /etc/sdsf.conf for the SDSF parameters).


-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Charles Mills]

As a user of the word, you really, really want to think about upward 
compatibility. Don't store the address of your product's anchor table there. 
Assume you will someday have multiple products. You would want to store the 
address of a vector of anchor table addresses. Think about upward compatibility 
for the layout. Include a length and a version number in your vector. Clear 
everything unused to zero. Think about how your products will cooperate if 
product A starts up first; or if product B starts up first. 

Think about how your customer will recover without an IPL if the tables become 
corrupted.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: Tuesday, June 13, 2017 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM customer anchor

On 06/13/2017 08:35 AM, scott Ford wrote:
> All:
> 
> I have a question about something called 'customer anchor table entry' 
> . My colleague said IBM can provide this entry to a ISV like use so we 
> can place an address there for routines.  I think it's like a vector 
> address .
> 
> Has anyone heard of this ?
> 

Yes I know about it and I kinda know the history of it. I'm not sure but I 
think I was the first one if not one of the first to apply for an entry when it 
was announced back in the mid-'90s when I was still working on ACS/WYLBUR and 
attended the "Vendor Disclosure Meeting"s in POK.

It solves the problem of the TCBUSER field in the TCBs, and the CVTUSER in the 
CVT. The problem being, who owns it and who can use it and NOT step on someone 
else.

It gives you an ANCHOR address where you can do a GETMAIN/STORAGE OBTAIN for 
CSA/SQA storage and store the address of that storage in your slot.

How you serialize it, use it, etc., is your problem as an ISV with multiple, or 
just one, product.

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Steve Thompson]

On 06/13/2017 08:35 AM, scott Ford wrote:

All:

I have a question about something called
'customer anchor table entry' . My colleague said IBM can provide this
entry to a ISV like use so we can place an address there for routines.  I
think it's like a vector address .

Has anyone heard of this ?



Yes I know about it and I kinda know the history of it. I'm not 
sure but I think I was the first one if not one of the first to 
apply for an entry when it was announced back in the mid-'90s 
when I was still working on ACS/WYLBUR and attended the "Vendor 
Disclosure Meeting"s in POK.


It solves the problem of the TCBUSER field in the TCBs, and the 
CVTUSER in the CVT. The problem being, who owns it and who can 
use it and NOT step on someone else.


It gives you an ANCHOR address where you can do a GETMAIN/STORAGE 
OBTAIN for CSA/SQA storage and store the address of that storage 
in your slot.


How you serialize it, use it, etc., is your problem as an ISV 
with multiple, or just one, product.


Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Charles Mills]

Yep!

That's what we did.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Tuesday, June 13, 2017 5:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM customer anchor

Recently came across this too. In CBT841 files:

"CONTACT PETER RELSON, rel...@us.ibm.com FOR YOUR OWN OFFSET IN THE CUSTOMER 
ANCHOR TABLE. ONCE YOU HAVE RECEIVED YOUR ASSIGNED VALUE MODIFY.."

Also, in the same CBT:

"A possible address off the Customer Anchor Table, X'CC' off the ECVT, 

  could be X'228' (assigned to a particular customer by IBM, but this 

  is an example address). 

 

  This is just an example.  For your site, you have to ask IBM to 

  assign this address for your site, and they are obligated to do so, 

  for a CUSTOMER.  Besides the fullwords that are assigned for VENDORS, 

  there are also four fullwords that are assignable to customers, if 

  they need a permanent address in the system to anchor some function. 

 

  At the time of this writing, Peter Relson of IBM is in charge of 

  assigning these addresses to either vendors or customers. 

 

  You are obligated to make sure that no program or product at your 

  site is already using this address.  "

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM customer anchor

[Tony Thigpen]

Recently came across this too. In CBT841 files:

"CONTACT PETER RELSON, rel...@us.ibm.com FOR YOUR OWN OFFSET IN THE
CUSTOMER ANCHOR TABLE. ONCE YOU HAVE RECEIVED YOUR ASSIGNED VALUE
MODIFY.."

Also, in the same CBT:

"A possible address off the Customer Anchor Table, X'CC' off the ECVT, 

 could be X'228' (assigned to a particular customer by IBM, but this 

 is an example address). 




 This is just an example.  For your site, you have to ask IBM to 

 assign this address for your site, and they are obligated to do so, 

 for a CUSTOMER.  Besides the fullwords that are assigned for VENDORS, 

 there are also four fullwords that are assignable to customers, if 

 they need a permanent address in the system to anchor some function. 




 At the time of this writing, Peter Relson of IBM is in charge of 

 assigning these addresses to either vendors or customers. 




 You are obligated to make sure that no program or product at your 


 site is already using this address.  "

Tony Thigpen

scott Ford wrote on 06/13/2017 08:35 AM:

All:

I have a question about something called
'customer anchor table entry' . My colleague said IBM can provide this
entry to a ISV like use so we can place an address there for routines.  I
think it's like a vector address .

Has anyone heard of this ?



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN