Re: cpu / machine identification

[Shane]

On Sat, 31 Dec 2011 21:16:17 -0800 Edward Jaffe wrote:

> --reasoning that led to the creation of the 'IBM License
> Manager for z/OS' debacle.

Wash your mouth out fella    ;-)
Well that's just ruined a potentially wonderful nascent year.

Shane ...

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

Re: cpu / machine identification

[Edward Jaffe]

On 12/27/2011 5:55 AM, Mark Zelden wrote:

In my own personal experience as a sysprog, I know some of the
same things have happened unintentionally.   Consolidations, moving
LPARs around, creating / cloning new LPARs can lead to this and
when the software doesn't check it's easy for the "techies" to
make mistakes since they often (usually?) don't know the T's and
C's of all the software contracts.

So even though it can be a pain, I actually prefer that any vendor that
cares, checks the CPU id for authorization.


Many years ago, one of our largest customers, with a complex and ever-changing 
configuration, requested that we perform robust and exhaustive checking of the 
execution environment in which (E)JES executes. This checking includes CPU 
serial/type/model, LPAR names, z/VM guest names, etc. Violations begin with 
subtle warnings and escalate over time (days) to eventually become a 
non-scrolling console message.


Apparently, they made similar requests to other vendors as well. Their intent 
was to automate license compliance and limit liability. They argued that such 
messages would ensure no out-of-policy product execution could go unnoticed by 
their operators and system administrators. They have been very pleased with our 
implementation.


This checking by various products leads to quite a bit of redundancy. A 
centralized approach to license compliance would seem superior--reasoning that 
led to the creation of the 'IBM License Manager for z/OS' debacle.


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

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

Re: cpu / machine identification

[Shane]

A while back (years) as part of an install we asked for a phone link
for the "dial-home" on the machine.
No - and take the dialing mechanism out of the machine.
Say what ???.

Being a new customer site (a bank), they were accommodated. Later on
they needed factory support for a hardware issue. The factory wanted to
dial *into* the machine. This was (eventually) acceded to.

So you just never know which way customers are going to jump.

Shane ...

On Sat, 31 Dec 2011 22:24:41 -0500 zMan wrote:

> Uh. And then of course you'll find that your request (a) doesn't work
> because it's blocked and (b) triggers IDS alarms, which you then get
> to explain. Not something I'd recommend trying.
> 
> > Actually, we had thought of putting in a module to request the key
> > automatically, the code was fairly simple to request a new key from
> > our server via TCP, and as long as the product had not expired the
> > whole thing could be generated within a short transaction.  When we
> > floated it to some of our customers, they mostly responded back
> > with  "why?".
> >
> > So it wasn't worth the time to finish the code, but I kept the
> > original prototype just in case we changed our minds later.

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

Re: Question on adding an SVC routine dynamically to a running system

[Greg Price]

Dave Day wrote:
> The SVC in question has but one purpose.  To generate a system trace 
> table entry.  The code within the SVC clears r15, and then branches r14. 
> Nothing more.

Then why not use SVC 50 (x'32')?

Cheers,
Greg

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

Re: cpu / machine identification

[zMan]

Uh. And then of course you'll find that your request (a) doesn't work
because it's blocked and (b) triggers IDS alarms, which you then get
to explain. Not something I'd recommend trying.

On Sat, Dec 31, 2011 at 9:25 PM, Brian Westerman
 wrote:
> Actually, we had thought of putting in a module to request the key 
> automatically, the code was fairly simple to request a new key from our 
> server via TCP, and as long as the product had not expired the whole thing 
> could be generated within a short transaction.  When we floated it to some of 
> our customers, they mostly responded back with  "why?".
>
> So it wasn't worth the time to finish the code, but I kept the original 
> prototype just in case we changed our minds later.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: cpu / machine identification

[Brian Westerman]

Actually, we had thought of putting in a module to request the key 
automatically, the code was fairly simple to request a new key from our server 
via TCP, and as long as the product had not expired the whole thing could be 
generated within a short transaction.  When we floated it to some of our 
customers, they mostly responded back with  "why?".

So it wasn't worth the time to finish the code, but I kept the original 
prototype just in case we changed our minds later.

Brian

On Sat, 31 Dec 2011 20:11:17 -0600, Mike Schwab  wrote:

>Here is an idea:  How about the message to the operator has reply
>value of ACK or ENTER.
>ACK would stand for acknowledge that you need a new key.
>ENTER would start a dialog to enter a new key.
>Reply with a 800 number to call and a customer number for the company.
>When the operator calls, you look them up and give them a license key
>for the new machine.
>
>On Sat, Dec 31, 2011 at 6:43 PM, Brian Westerman
> wrote:
>> So the question should be, who should bear the cost of that?  The vendor, 
>> who has no control over the choices, or the site that wants to run the 
>> software?
>>
>> Unfortunately, this whole thread has sparked a heated debate internally 
>> here.  There are those that are for scrapping the licensing code, and those 
>> that want it increased so that it's tighter with an easier way to extend 
>> things, (which seems counter productive to me).  As with most arguments, the 
>> ones that develop the code have one mindset, and the ones that support the 
>> code have another, with the one that don't do either sitting on the fence 
>> cheering for blood:).
>>
>> Brian
>>
>>
>> On Fri, 30 Dec 2011 21:55:37 -0500, Robert A. Rosenberg  
>> wrote:
>>
>>>At 20:42 -0600 on 12/29/2011, Brian Westerman wrote about Re: cpu /
>>>machine identification:
>>>
We have  DR support in our software, but I was under the impression
that most of the DR sites were running the OS under VM and they
simulated the serial anyway.

I suppose their are sites that do not run the DR under VM, but don't
the sites who don't run under VM know the serial number ahead of
time, and wouldn't it be already built into the software, or they
have a already setup job to enter the new serial(s)?  I know I would
have it set up if it were me.
>>>
>>>Knowing the Serial Number of the machine you are going to run DR on
>>>and having it already built into the software is being too
>>>optimistic. Not only can you have multiple DR Sites to go to and
>>>choosing one based on who can service you when you need DR Services
>>>but even if it was only one site, I am sure that they have multiple
>>>machines and you would not want to list all of them. Until you get
>>>there, you would not know which machine that is going to be assigned
>>>to you.
>>>
>>>--
>>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.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...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: cpu / machine identification

[Brian Westerman]

Apparently we seem to be getting closer and closer to that.

Brian

On Sat, 31 Dec 2011 18:36:52 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In
>,
>on 12/29/2011
>   at 11:11 PM, Mike Schwab  said:
>
>>Would some of the macro worms be possible to infect some Linux
>>products with macros on x86 and x64 and S390x?
>
>That's a concern for workstations, but who runs, e.g., Firefox,
>OpenOffice on z?
>
>--
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
>We don't care. We don't have to care, we're Congress.
>(S877: The Shut up and Eat Your spam act of 2003)
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: cpu / machine identification

[Brian Westerman]

I 100% agree.  Having been a systems programmer for most of my life, I'm used 
to the 24x7 mode of support.  A lot of vendors are not.  Or even worse, have a 
support number in India that will "page" someone, to get back to you.

Brian

On Sat, 31 Dec 2011 17:57:44 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In <9482792948874353.wa.brianwestermansyzygyinc@bama.ua.edu>, on
>12/29/2011
>   at 08:29 PM, Brian Westerman  said:
>
>>The one thing I do know is that vendors have the right to protect
>>their software and as long as it's reasonable protection, I don't see
>>why a site would complain about it.
>
>What do you mean by reasonable protection? From a customer
>perspective, it's not reasonable if it interferes with anything that's
>permitted by the license. That's why it's important for a vendor to
>consider failure modes and to have 24x366 coverage if he's going to
>use any sort of license-key mechanism.
>
>--
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
>We don't care. We don't have to care, we're Congress.
>(S877: The Shut up and Eat Your spam act of 2003)
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: cpu / machine identification

[Mike Schwab]

Here is an idea:  How about the message to the operator has reply
value of ACK or ENTER.
ACK would stand for acknowledge that you need a new key.
ENTER would start a dialog to enter a new key.
Reply with a 800 number to call and a customer number for the company.
When the operator calls, you look them up and give them a license key
for the new machine.

On Sat, Dec 31, 2011 at 6:43 PM, Brian Westerman
 wrote:
> So the question should be, who should bear the cost of that?  The vendor, who 
> has no control over the choices, or the site that wants to run the software?
>
> Unfortunately, this whole thread has sparked a heated debate internally here. 
>  There are those that are for scrapping the licensing code, and those that 
> want it increased so that it's tighter with an easier way to extend things, 
> (which seems counter productive to me).  As with most arguments, the ones 
> that develop the code have one mindset, and the ones that support the code 
> have another, with the one that don't do either sitting on the fence cheering 
> for blood:).
>
> Brian
>
>
> On Fri, 30 Dec 2011 21:55:37 -0500, Robert A. Rosenberg  
> wrote:
>
>>At 20:42 -0600 on 12/29/2011, Brian Westerman wrote about Re: cpu /
>>machine identification:
>>
>>>We have  DR support in our software, but I was under the impression
>>>that most of the DR sites were running the OS under VM and they
>>>simulated the serial anyway.
>>>
>>>I suppose their are sites that do not run the DR under VM, but don't
>>>the sites who don't run under VM know the serial number ahead of
>>>time, and wouldn't it be already built into the software, or they
>>>have a already setup job to enter the new serial(s)?  I know I would
>>>have it set up if it were me.
>>
>>Knowing the Serial Number of the machine you are going to run DR on
>>and having it already built into the software is being too
>>optimistic. Not only can you have multiple DR Sites to go to and
>>choosing one based on who can service you when you need DR Services
>>but even if it was only one site, I am sure that they have multiple
>>machines and you would not want to list all of them. Until you get
>>there, you would not know which machine that is going to be assigned
>>to you.
>>
>>--
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: cpu / machine identification

[Brian Westerman]

So the question should be, who should bear the cost of that?  The vendor, who 
has no control over the choices, or the site that wants to run the software?

Unfortunately, this whole thread has sparked a heated debate internally here.  
There are those that are for scrapping the licensing code, and those that want 
it increased so that it's tighter with an easier way to extend things, (which 
seems counter productive to me).  As with most arguments, the ones that develop 
the code have one mindset, and the ones that support the code have another, 
with the one that don't do either sitting on the fence cheering for blood:).

Brian 


On Fri, 30 Dec 2011 21:55:37 -0500, Robert A. Rosenberg  
wrote:

>At 20:42 -0600 on 12/29/2011, Brian Westerman wrote about Re: cpu /
>machine identification:
>
>>We have  DR support in our software, but I was under the impression
>>that most of the DR sites were running the OS under VM and they
>>simulated the serial anyway.
>>
>>I suppose their are sites that do not run the DR under VM, but don't
>>the sites who don't run under VM know the serial number ahead of
>>time, and wouldn't it be already built into the software, or they
>>have a already setup job to enter the new serial(s)?  I know I would
>>have it set up if it were me.
>
>Knowing the Serial Number of the machine you are going to run DR on
>and having it already built into the software is being too
>optimistic. Not only can you have multiple DR Sites to go to and
>choosing one based on who can service you when you need DR Services
>but even if it was only one site, I am sure that they have multiple
>machines and you would not want to list all of them. Until you get
>there, you would not know which machine that is going to be assigned
>to you.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: cpu / machine identification

[Brian Westerman]

Sorry Shmuel, I mind works on a different level than my fingers sometimes.  I 
apologize for the mistake on your name.

I'm still not too sure that there is a way to conduct an audit that would 
satisfy the vendor, that the site would agree to.  I don't think disrupting a 
site is what the vendor would be trying to do, but if you limit the audit, then 
it's not an audit.  i.e. I have a dollar in my pocket, but if you can't see the 
dollar then I am broke and you can look at me to prove that I am broke, but you 
cannot look into my pocket, because that might be disruptive. :}

The audit would have to allow a search of all load libraries at a minimum, and 
would entail loading each and every module to check internally, not doesn't 
that sound like a lot of fun, it would be cost prohibitive for both the vendor 
and the site.

The cost (in manpower) to enter a new license key is trivial compared to the 
cost of preparing for the audit.  Then you would have to multiply it by the 
total software vendor base.  I think most would go for the key after that.

Brian


On Sat, 31 Dec 2011 17:47:17 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In <8724193196442157.wa.brianwestermansyzygyinc@bama.ua.edu>, on
>12/29/2011
>   at 08:03 PM, Brian Westerman  said:
>
>>I'm sorry Schmuel,
>
>That's Shmuel!
>
>>giving a vendor access to their site
>
>There's a difference between permitting an audit and allowing
>unrestricted access. I've certainly been at sites that allowed audits,
>but the auditors were limited to the relevant data.
>
>>In this case I hardily agree with the view that the the vendor would
>>be told to go pound salt.
>
>Perhaps by the bean counters, although I haven't seen that happen.
>What I have seen is shops where the presence of a licensing key is a
>deal breaker[1].
>
>>Imagine the security issues
>
>BTDTGTTS. The Devil is in the details, and it's not rocket science.
>
>There is a type of "audit" that I'd consider unacceptable: when trade
>organizations threaten to get a court order and conduct a deliberately
>disruptive search in order to extort payment of money that is not due.
>But that's not what is under discussion here.
>
>[1] In the sense that they would only license the product if there
>were contract terms that no vendor would ever agree to.
>
>--
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see 
>We don't care. We don't have to care, we're Congress.
>(S877: The Shut up and Eat Your spam act of 2003)
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Eight-character TSO Userid Support

[Edward Jaffe]

On 12/30/2011 2:25 PM, Paul Gilmartin wrote:

Good question.  How would he get the notification?  But did you try:

o ftp MVS
   user LONGUSER
   password
   quote site FILE=JES
   put ...?

o //STEP  EXEC  PGM=IKJEFT01  with that owner?
   (possibly in the job submitted via FTP)


I used FTP PUT to send the following:

//LONGUSER JOB 1,JAFFE,CLASS=A,MSGCLASS=T,NOTIFY=&SYSUID
// EXEC PGM=IKJEFT01,REGION=64M
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
 LISTA STA HI
//

As it should, the job received a JCL error indicating NOTIFY was too long:

IEF642I EXCESSIVE PARAMETER LENGTH IN THE NOTIFY FIELD

Once I removed that, the job ran to completion exactly as expected:

IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
READY
 LISTA STA HI
--DSORG--CREATED-EXPIRES-SECURITY--DDNAME---DISP--
LONGUSER.LONGUSER.J0256439.D00A.?
   SYSTSPRT DELETE
IKJ58300I HISTORY NOT AVAILABLE+
IKJ58300I LOCATE ERROR CODE 08
LONGUSER.LONGUSER.J0256439.D009.?
   SYSTSIN  DELETE
IKJ58300I HISTORY NOT AVAILABLE+
IKJ58300I LOCATE ERROR CODE 08
READY
END



   - Invoke ISPF LM services under that TMP?


ISPF LM services should work fine. They don't depend on TSO services.


o ssh LONGUSER@MVS
   then, in Rexx,
   address TSO time


>./timerexx
IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
IKJ56650I TIME-04:44:34 PM. CPU-00:00:00 SERVICE-268 SESSION-00:00:00 DECEMBER 
31,2011


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

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

Re: cpu / machine identification

[Brian Westerman]

You may have a point, but our view is that good software shouldn't have to cost 
an arm and a leg to be good.  Mainly we are a consulting firm, and software 
started as a "sideline", but once you get over a couple hundred clients, you 
have to devote more time and people resources to it, so now it's a whole 
separate "division".  We make sure that our software does what "theirs" does 
plus extra features.  We have a good number of clients running it, but IBM and 
CA, even though they are far more expensive, and with less features in some 
cases, still has a far greater market share.

I'm not sure hiking the price will help in this case.  We try to cater to the 
sites that want value, and we would be only hurting them by upping to price to 
see if it would increase our market share.

We have two new products coming out this year, maybe since neither one has any 
competition we should put a outrageously high price on them:).  I seriously 
doubt that we will do that though, it just isn't the way we work.

Brian



On Fri, 30 Dec 2011 18:48:14 -0600, Chase, John  wrote:


>
>There still exists a mindset that believes, for example, that since
>functionality ABC "normally" costs between $xxxK and $yyyK, then "your"
>offer of functionality ABC at $xxxK/20 "can't be very good", or "you
>don't have the resources to provide the kind of support we need", etc.
>
>IOW, maybe your product's price is "too cheap".
>
>-jc-
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: RSU Apply Error in PTF

[Shmuel Metz (Seymour J.)]

In
,
on 12/31/2011
   at 10:47 AM, saurabh khandelwal 
said:

>Below is my JCL used for apply process

That doesn't answer the question. It's your target zone that's
relevant, not your JCL. The DDDEF for SYSLIB should specify all of the
target libraries needed to run your assemblies, including MTS.

You also need to review the assembler output, including those in
joblog.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IBM Manuals

[Shmuel Metz (Seymour J.)]

In
,
on 12/30/2011
   at 05:12 PM, "Chase, John"  said:

>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz (Seymour
>J.)
>> 
>> In
>> ,
>> on 12/27/2011
>>at 12:37 PM, Mike Schwab  said:
>> 
>> >Maybe they think everyone should be using 32 inch 1080P TVs as
>> >monitors?
>> 
>> 1920p, Shirley.

>Nope.

"No, they don't think so", or only "No, not everyone has 1920p"?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: RSU Apply Error in PTF

[Shmuel Metz (Seymour J.)]

In <00d101ccc72b$7ea9f350$7bfdd9f0$@mindspring.com>, on 12/30/2011
   at 02:44 PM, Lizette Koehler  said:

>His DDDEF statements show what I would call Production not SMP/E Tlib
>datasets.

That's definitely wrong.

>In the assembly section is has NO ASSEMBLY ERRORs, however it is an
>RC04. This might be as simple of saying an RC04 in Assembler is
>okay. 

Could you show the actual output, including assembler message4s in
joblog??

>I did not find any ERROR or ASMA messages in the listing from the
>assembly of ISFDA. 

I don't know of any way to get RC 4 from HLA without any warning
messages. Did you look at the messages in his assembly or run your
own? Did you check for an ASMA message WTO?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Semiprivileged instructions, part 1 (3)

[Shmuel Metz (Seymour J.)]

In
,
on 12/30/2011
   at 01:20 PM, Chris Craddock  said:

>Additional *SOFTWARE* architectural conditions may have to be
>satisfied in order for the instruction to complete,

ITYM that additional software conditions must be met before the OS
will set the necessary control register fields to allow execution of
the instructions. If the control registers are set then the
instructions will operate accordingly, regardless of any software
conditions.

>The often cited example is that the TRAP
>instructions are not supported by z/OS at all.

Sort of. You can use, e.g., ESTAE, to intercept the special operation
exception. It would be nice, however, if you could use ESPIE to trap
special operation exceptions.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In <9482792948874353.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/29/2011
   at 08:29 PM, Brian Westerman  said:

>The one thing I do know is that vendors have the right to protect
>their software and as long as it's reasonable protection, I don't see
>why a site would complain about it.

What do you mean by reasonable protection? From a customer
perspective, it's not reasonable if it interferes with anything that's
permitted by the license. That's why it's important for a vendor to
consider failure modes and to have 24x366 coverage if he's going to
use any sort of license-key mechanism.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In <0713029417803027.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/29/2011
   at 08:42 PM, Brian Westerman  said:

>I suppose their are sites that do not run the DR under VM, but don't
>the sites who don't run under VM know the serial number ahead of
>time, and wouldn't it be already built into the software, or they
>have a already setup job to enter the new serial(s)?  I know I would
>have it set up if it were me.

You can't set it up; you can only ask your vendor to set it up. Then
when it doesn't work at the DR site you get to call your vendor and
try to get it taken care of. I didn't get a tee shirt, only scars.

>This also has nothing to do with the question, but I have always
>thought that the vendor should be compensated for support of the DR
>testing anyway.  (this will probably cause a lot of angry
>responses).

I'm sure that it will. The customer only uses the DR site a few days a
year, and the only significant support he normally needs is for bugs
in the licensing keys that are not for the customers' benefit in the
first place.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Looking for Mailing List

[Shmuel Metz (Seymour J.)]

In <00a001ccc661$730bc3e0$59234ba0$@comporium.net>, on 12/29/2011
   at 02:38 PM, "John P. Baker"  said:

>Can anyone offer any suggestions?

Here or IBMTCP-L.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In
,
on 12/29/2011
   at 11:11 PM, Mike Schwab  said:

>Would some of the macro worms be possible to infect some Linux
>products with macros on x86 and x64 and S390x?

That's a concern for workstations, but who runs, e.g., Firefox,
OpenOffice on z?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IDCAMS APF auth question.

[Shmuel Metz (Seymour J.)]

In , on 12/29/2011
   at 09:35 PM, Scott Ford  said:

>I would say you will have to allocate the sysin dataset and sysprint.

Yes, although he can override the ddnames. However, he still needs APF
authorization for certain AMS functions.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: cpu / machine identification

[Shmuel Metz (Seymour J.)]

In <8724193196442157.wa.brianwestermansyzygyinc@bama.ua.edu>, on
12/29/2011
   at 08:03 PM, Brian Westerman  said:

>I'm sorry Schmuel, 

That's Shmuel!

>giving a vendor access to their site

There's a difference between permitting an audit and allowing
unrestricted access. I've certainly been at sites that allowed audits,
but the auditors were limited to the relevant data.

>In this case I hardily agree with the view that the the vendor would
>be told to go pound salt. 

Perhaps by the bean counters, although I haven't seen that happen.
What I have seen is shops where the presence of a licensing key is a
deal breaker[1].

>Imagine the security issues

BTDTGTTS. The Devil is in the details, and it's not rocket science.

There is a type of "audit" that I'd consider unacceptable: when trade
organizations threaten to get a court order and conduct a deliberately
disruptive search in order to extort payment of money that is not due.
But that's not what is under discussion here.

[1] In the sense that they would only license the product if there 
were contract terms that no vendor would ever agree to.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Date and time of IPL API?

[Mark Zelden]

On Sat, 31 Dec 2011 12:47:30 -0500, Peter Relson  wrote:

>While the SMCA (IEESMCA) may have existed "forever", SMCAITME / SMCAIDTE
>were added in OS/390 R3., one release *after* the introduction of the IPA
>(IHAIPA).

You had me really confused there for a while.   I wrote my first "IPLINFO" 
program
when I was trying to learn assembler and control blocks as a fairly new sysprog
under MVS/XA and I'm pretty sure I used SMCAIDTE in the original (which I later
converted to REXX around the same time period).   Looking at the comments
in IEESMCA I can see that it became GUPI in OS/390 R3, but how long has it
actually existed?

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: Question on adding an SVC routine dynamically to a running system

[Binyamin Dissen]

I would have  bigger question - why an SVC at all? SVC's are limited
resources. If you will only be working when a server a/s is up, it would make
more sense to use a PC.

On Sat, 31 Dec 2011 12:53:42 -0600 Dave Day  wrote:

:>Peter,
:>
:>The SVC in question has but one purpose.  To generate a system trace
:>>>table entry.  The code within the SVC clears r15, and then branches r14.
:>> Having an SVC that is like that is surely a bad idea if used in a customer
:>> shop
:>> in production where malicious use of that SVC could compromise system
:>> serviceability.
:>
:>I don't understand your comment.  Unless by malicious use you mean that 
:>the SVC would be executed over and over, just driving up overhead?
:>
:>I honestly don't see that happening.  The code to execute the SVC is 
:>supplied by me, within a macro.  The SVC number will be supplied by my 
:>server code in my vendor table.  The code dropped out by the macro  checks 
:>that my vendor entry is there, and that the SVC number is not 00's.  And, I 
:>would expect anyone assembling the macro into their code would certainly 
:>control the logic flow with some kind of parm setting/flag byte convention. 
:>If one of my customers ships their code to their customer with my code 
:>embedded, and without any check on its execution, it wouldn't do anything 
:>without my server being there, and up and running.  And, if my server is 
:>there, it would be pretty easy to identify the fact that the code in 
:>question is executing this SVC without any controls on it.
:>
:>I can't see any need to set a slip, or find it using IPCS in a dump.
:>> That strikes me as a bit short-sighted unless this will never be used in a
:>> customer shop.
:>
:>Why is that short-sighted?  Why would I ever set a slip on a BR R14?  If 
:>I need to know where the code is located in a dump, I can get the number 
:>from my own data area, compute the offset into the SVC table, and then go 
:>get it from that table.

--
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.

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

Re: Semiprivileged instructions, part 1

[Peter Relson]

The principles of operation requires very careful reading.  As I would 
guess have most,  I have failed to be careful enough many times.

>The table, Figure 5-6, titled "Summary of Authorization
>Mechanisms" includes semiprivileged instructions _and_
>some others; Looking carefully, I cannot discern which
>of these 36 instructions are the 23 semiprivileged
>instructions.

This table is not intending to show all 23 semiprivileged instructions. 
And it does not. It is intending to show what it says it shows, a summary 
of authorization mechanisms. 
Does it do this correctly or not? 

(It appears that RP ought to have the Q3 designation but doesn't; if true, 
we can get that corrected)

There are 23 instructions in table 10-1 that are designated as "Q"..
(BSA, EPAR, EPAIR, ESAR, ESAIR, IAC, IPK, IVSK, MVPG, MVCP, MVCS, MVCDK, 
MVCK, MVCOS, MVCSK, PTFF, PC, PT, PTI, RP, SAC, SACF, SPKA,)

MVPG, MVCK, PTFF are the instructions in 10-1 that are not in 5-6.

(It wouldn't shock me if some day TRAP2/TRAP4 were added to 5-6, with a 
new column for the TRAP-enabled bit in DUCT byte 47.)

Peter Relson
z/OS Core Technology Design

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

Re: Question on adding an SVC routine dynamically to a running system

[Dave Day]

Peter,

The SVC in question has but one purpose.  To generate a system trace

table entry.  The code within the SVC clears r15, and then branches r14.

Having an SVC that is like that is surely a bad idea if used in a customer
shop
in production where malicious use of that SVC could compromise system
serviceability.


   I don't understand your comment.  Unless by malicious use you mean that 
the SVC would be executed over and over, just driving up overhead?


   I honestly don't see that happening.  The code to execute the SVC is 
supplied by me, within a macro.  The SVC number will be supplied by my 
server code in my vendor table.  The code dropped out by the macro  checks 
that my vendor entry is there, and that the SVC number is not 00's.  And, I 
would expect anyone assembling the macro into their code would certainly 
control the logic flow with some kind of parm setting/flag byte convention. 
If one of my customers ships their code to their customer with my code 
embedded, and without any check on its execution, it wouldn't do anything 
without my server being there, and up and running.  And, if my server is 
there, it would be pretty easy to identify the fact that the code in 
question is executing this SVC without any controls on it.


I can't see any need to set a slip, or find it using IPCS in a dump.

That strikes me as a bit short-sighted unless this will never be used in a
customer shop.


   Why is that short-sighted?  Why would I ever set a slip on a BR R14?  If 
I need to know where the code is located in a dump, I can get the number 
from my own data area, compute the offset into the SVC table, and then go 
get it from that table.


   --Dave


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

Re: Question on adding an SVC routine dynamically to a running system

[Peter Relson]

>CSVDYLPA allows you to request dynamic LPA services. Be aware, however, 
that 
>changes to LPA itself are not actually done. This set of services truly 
only 
>lets you add modules to, and delete modules from, common storage. When 
>searching by module name, the system will locate the copy of a module 
added 
>by dynamic LPA services even if it was present in PLPA, MLPA, or FLPA.
>And then  noting that the SVCUPDTE had an EP=  parameter to allow for 
>specification by entry point address, it prompted my question.
I don't follow why that prompted your question, but perhaps that is not 
important.
This is saying little more than that dynamic LPA modules are not literally 
in the 
area built for LPA modules during IPL, but they are in LPA as far as 
system
services are concerned. 

>The SVC in question has but one purpose.  To generate a system trace 
>table entry.  The code within the SVC clears r15, and then branches r14. 
Having an SVC that is like that is surely a bad idea if used in a customer 
shop
in production where malicious use of that SVC could compromise system 
serviceability.

> I can't see any need to set a slip, or find it using IPCS in a dump.
That strikes me as a bit short-sighted unless this will never be used in a 
customer shop.

>By "known" I presume you mean the SVC number has been specified, as 
>opposed to searching the SVC table for an open slot?
yes (or "after" you have searched, although it's not clear exactly what 
you'd search for, as 
the value in an unused SVC table slot is not documented and may not stay 
what it is "today".

Peter Relson
z/OS Core Technolgogy Design

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

Re: Date and time of IPL API?

[Peter Relson]

While the SMCA (IEESMCA) may have existed "forever", SMCAITME / SMCAIDTE 
were added in OS/390 R3., one release *after* the introduction of the IPA 
(IHAIPA). These are in "TIME BIN" format.
IPAICTOD was provided in the base IPA. IPAILTOD was added in OS/390 R10. 
These are in STCK format. 

The IPA field identifies the end of the IPL/NIP phase.
The SMCA fields actually identify when the SMF address space starts, and 
is set via the "TIME BIN" service. 

DISPLAY IPLINFO uses IPAILTOD (it originally used IPAICTOD).

The closest-to-true-start-of-IPL time is formatted by the IEAVFTED exec 
"Timed Event Data Report" which shows various IPL statistics.  The value 
used is not in a programming interface field.

Peter Relson
z/OS Core Technology Design

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

Re: IBM Manuals

[Anne & Lynn Wheeler]

jcew...@acm.org (Joel C. Ewing) writes:
> If you can get a text-based PDF document from the original source,
> that would certainly be preferable, as that allows text searching
> capability. But, if all you have is a hard copy, none of the current
> freely-available OCR tools come close to preserving the original
> document as accurately as image-based PDF, unless you have the time
> for extensive manual editing.  Bitsavers.org uses a modified archive
> approach that uses higher resolution to allow possible future OCR; but
> compensates for higher resolution by using black/white threshold
> images that sacrifice quality of embedded document illustrations.  I
> prefer to go with lower resolution adequate for human reading and
> preserve gray scale, and even color, where its use is significant.

I finally got approval for putting up scan'ed (original done at 600dpi)
copy of Share 1979 LSRAD report: 
http://bitsavers.org/pdf/ibm/share/

I sent them a 4mbyte & 150mbyte PDF versions and they put up the
150mbyte ... although I don't notice lot of difference. I did do some
image post processing from the original scan to bring out letters/text
(including forcing b/w threashold; before conversions to pdf) ...  I
find that resulted in much better reading quality, more than the
difference between 4mbyte & 150mbyte.

i did put up the cover in color/jpg at very low resolution (<7kbytes)
http://www.garlic.com/~lynn/lsradcover.jpg 

Early spring 2009 I was asked to HTML'ize the Pecora hearings (30s
congressional hearings into the '29 crash ... glass-steagall, etc) that
had been scanned the previous fall at boston public library ... doing
lots of internal HREFs index/links as well as lots of HREFs between what
happened then and what happened this time (some expectation that the new
congress might have some appetite for the subject). I spent a lot of
time with "free" OCR programs ... but there was lots of problems. In any
case, after doing quiet a bit of work, got a call that it wouldn't be
needed after all (wallstreet pouring enormous amount of money into
congress)

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: IBM Manuals

[Scott Ford]

Joel,
Totally agree , pdf is much easier
Regards,
Scott

Sent from my iPad

On Dec 31, 2011, at 9:56 AM, "Joel C. Ewing"  wrote:

> On 12/30/2011 10:30 AM, Shmuel Metz (Seymour J.) wrote:
>> In<4efdc973.3050...@acm.org>, on 12/30/2011
>>at 08:23 AM, "Joel C. Ewing"  said:
>> 
>>> First thing I do with new equipment/appliance manuals is either find
>>> and  save an on-line pdf version
>> 
>> Why? I know that in some cases PDF is all that's available, but
>> certainly not in all.
>> 
> 
> I want a form that preserves for my personal use, and has the ability to 
> recreate if necessary, the original multi-page documents for human viewing.  
> PDF was designed with precisely that in mind and does it very well.  I want a 
> format with a proven track record of continued support over an extended time 
> period on multiple hardware platforms and operating systems.  The PDF specs 
> are openly available, free PDF readers are available for multiple 
> environments from multiple independent sources.  Ditto for free print-to-PDF 
> converters, and direct PDF creation support is now built into many 
> applications as well.
> 
> There are other formats that are useful or even "better" in specific 
> environments, but nothing at this point is as ubiquitous as PDF, and I have 
> no idea what systems I may be running ten years from now.
> 
> If you can get a text-based PDF document from the original source, that would 
> certainly be preferable, as that allows text searching capability. But, if 
> all you have is a hard copy, none of the current freely-available OCR tools 
> come close to preserving the original document as accurately as image-based 
> PDF, unless you have the time for extensive manual editing.  Bitsavers.org 
> uses a modified archive approach that uses higher resolution to allow 
> possible future OCR; but compensates for higher resolution by using 
> black/white threshold images that sacrifice quality of embedded document 
> illustrations.  I prefer to go with lower resolution adequate for human 
> reading and preserve gray scale, and even color, where its use is significant.
> 
> -- 
> Joel C. Ewing,Bentonville, AR   jcew...@acm.org
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: IBM Manuals

[Joel C. Ewing]

On 12/30/2011 10:30 AM, Shmuel Metz (Seymour J.) wrote:

In<4efdc973.3050...@acm.org>, on 12/30/2011
at 08:23 AM, "Joel C. Ewing"  said:


First thing I do with new equipment/appliance manuals is either find
and  save an on-line pdf version


Why? I know that in some cases PDF is all that's available, but
certainly not in all.



I want a form that preserves for my personal use, and has the ability to 
recreate if necessary, the original multi-page documents for human 
viewing.  PDF was designed with precisely that in mind and does it very 
well.  I want a format with a proven track record of continued support 
over an extended time period on multiple hardware platforms and 
operating systems.  The PDF specs are openly available, free PDF readers 
are available for multiple environments from multiple independent 
sources.  Ditto for free print-to-PDF converters, and direct PDF 
creation support is now built into many applications as well.


There are other formats that are useful or even "better" in specific 
environments, but nothing at this point is as ubiquitous as PDF, and I 
have no idea what systems I may be running ten years from now.


If you can get a text-based PDF document from the original source, that 
would certainly be preferable, as that allows text searching capability. 
But, if all you have is a hard copy, none of the current 
freely-available OCR tools come close to preserving the original 
document as accurately as image-based PDF, unless you have the time for 
extensive manual editing.  Bitsavers.org uses a modified archive 
approach that uses higher resolution to allow possible future OCR; but 
compensates for higher resolution by using black/white threshold images 
that sacrifice quality of embedded document illustrations.  I prefer to 
go with lower resolution adequate for human reading and preserve gray 
scale, and even color, where its use is significant.


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: IBM Manuals

[Calvin Thanga]

Sent from my BlackBerry® wireless device

-Original Message-
From: "Shmuel Metz (Seymour J.)" 
Sender: IBM Mainframe Discussion List 
Date: Fri, 30 Dec 2011 11:30:00 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: IBM Manuals

In <4efdc973.3050...@acm.org>, on 12/30/2011
   at 08:23 AM, "Joel C. Ewing"  said:

>First thing I do with new equipment/appliance manuals is either find
>and  save an on-line pdf version

Why? I know that in some cases PDF is all that's available, but
certainly not in all.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

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

Re: Date and time of IPL API?

[Charles Mills]

Thanks, all. I think I will go with the time in the SMCA. It's only two hops
away from x'0010' and it makes no difference which specific IPL
component's start time I get.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Barry Merrill
Sent: Saturday, December 31, 2011 6:24 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Date and time of IPL API?

And, reading the time of an SMF ID=0 record will NOT prove that the system
was IPL'd.

The ID=0 (for MANY years) is written when SMF is STARTED or RESTARTED, and
there's no flag to indicate which.

The only SMF records that are guaranteed to report a SYSTEM IPL are the
ID=90, subtype 8 (IPL PROMPT) or subtype 10 (IPL SRM).

And, the IPLTIME field in those ID=90's is on GMT, with NO GMT OFFSET
provided, so the SMFTIME, in the SMF header, which is on the local time
zone, must be used.

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

Re: Date and time of IPL API?

[Barry Merrill]

And, reading the time of an SMF ID=0 record will NOT prove that the system
was IPL'd.

The ID=0 (for MANY years) is written when SMF is STARTED or RESTARTED, and
there's
no flag to indicate which.

The only SMF records that are guaranteed to report a SYSTEM IPL are the
ID=90,
subtype 8 (IPL PROMPT) or subtype 10 (IPL SRM).

And, the IPLTIME field in those ID=90's is on GMT, with NO GMT OFFSET
provided,
so the SMFTIME, in the SMF header, which is on the local time zone, must be
used.

Merrilly New Year,

Barry Merrill

Herbert W. Barry Merrill, PhD
President-Programmer
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
214 351 1966 tel
214 350 3694 fax
http://www.mxg.com
ba...@mxg.com

MXG Support:   supp...@mxg.com
MXG Admin:  ad...@mxg.com

Standard Answers: http://www.mxg.com/administration
What's Supported:   http://www.mxg.com/changes

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

Re: XML Generate String Length

[Mike Schwab]

On Fri, Dec 30, 2011 at 6:21 PM, Chase, John  wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of Kopischke, David G.
>>
>> Greetings,
>>    One of our developers is performing an XML GENERATE with a string
> that's variable. When it gets
>> above about 100K, it ASRA's. No error codes or anything.
>>
>>    Is there a maximum message length ??? 100K seems too small for an
> IBM limit, so there's probably a
>> parameter somewhere that I'm missing. I'm still looking, but let me
> know if you can point me to a
>> manual reference.
>
> AFAIK, "ASRA" is unique to CICS, so since you seem to "ASRA" at about
> 100K characters, I'd wager your underlying abend code is 0C4 because
> your program is trying to write past the end of allocated storage.
>
Isn't there a memory size parameter on the CICS program entry?
-- 
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...@bama.ua.edu with the message: INFO IBM-MAIN