Re: z/XDC Release z1.12 now avaiable

[David Cole]

I'm curious. What did you find?

At 1/20/2011 03:47 PM, Edward Jaffe wrote:

On 1/18/2011 1:46 PM, David Cole wrote:

z/XDC release z1.12 is now fully available. Major new features include:


Installed and operational here. Already found a use for one of the 
new facilities. Great job, Dave!


--
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/XDC Release z1.12 now avaiable

[David Cole]

I'm betting you will use that a lot...


At 1/21/2011 02:36 PM, Edward Jaffe wrote:

On 1/21/2011 10:40 AM, David Cole wrote:

I'm curious. What did you find?


Programmer can now (fairly easily) display storage being accessed in 
a JES2-owned data space by an SRB-mode program.


--
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Recent maintenance for z/XDC

[David Cole]

I have posted new maintenance for z/XDC. For details please visit our 
Facebook page. You can find it by going onto Facebook and searching 
for ColeSoft.


Thank You,

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)

[David Cole]

Why are vendors and organizations using Facebook for professional 
use?  I am seeing this more and more often.


Our use of Facebook is experimental at this stage... We are trying it 
for several reasons. First, because I (and a LOT of other people) do 
use Facebook socially, so I (and a LOT of other people) are somewhat 
familiar with it.


Second, it is a very convenient way for us to "push" information and 
for interested recipients to receive that information...
   * Recipients (customers, usually but anyone actually) can opt in 
or opt out of our posts by "liking" or "unliking" (awful terms!) our 
ColeSoft page.

   * So the recipient list is self-selecting. We don't have to maintain it.
   * In fact, we do not have (and there is no way we could have) a 
complete list of people who use z/XDC and are interested in its 
developments. Our Facebook page gives such unknown people an easy way 
to stay abreast of z/XDC developments if they choose to.
   * Recipients can react to our announcements or even create their 
own postings there, so the Facebook page can also serve us as a product forum.
   * Posting information on Facebook does not require web 
programming skills, so it widens the range of people here at ColeSoft 
that can be assigned to maintain the presence.
Third, this kind of posting does not appear at our website because 
customers don't frequent colesoft.com anywhere near as much as they 
frequent social websites, especially Facebook. So only the most 
important information goes there.








But we do have access to LinkedIn (as of "yesterday", anyway).


I prefer Facebook over LinkedIn simply because I don't use LinkedIn, 
don't know how to use LinkedIn and have no interest in learning 
LinkedIn. Why? Primarily because it seems to me to be just a 
redundancy to Facebook. And more people use Facebook than LinkedIn, 
so why bother?







And no, I'm not going to give Facebook my details just to chase down 
company announcements.


About the only real information you have to give Facebook is an 
eaddress. There is nothing else that they require you to give.







I'm not a z/XDC user, but I didn't see the information on your web 
site. At least not in any obvious place.


Customers know to look in our Support area for maintenance details. 
My Facebook post contains additional prose regarding the fixes.







I'm not a z/XDC customer either, but if I was I would consider this 
to be a problem. I do not use Facebook and I have no intention to do so.


Major announcements will still find a place at our website and a 
brief mention in IBM-MAIN and ASSEMBLER-LIST.







By definition, it [Facebook] is primarily used for networking with 
friends, not professional contacts. You're posts are an exception.


Ummm, I find that a very large number of both local and national 
businesses have growing Facebook presences. So I don't agree that my 
posts are an exception.  After all, if "half a billion" people are 
"on Facebook", then by definition(!), that's where your customers are...


Personally, I use Facebook more to keep up with local (Nelson County) 
events than for following friends...






Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)

[David Cole]

At 5/23/2011 03:44 PM, Rick Fochtman wrote:
I'd also be concerned about too many "wanna be's" cluttering a 
professional's mailbox with inappropriate and/or senseless replies 
to legitimate technical questions.


(a) Could happen. (b) Might not. Personally, I doubt it will be a problem.

But if I choose "a", I certainly will learn less than if I choose "b".

I'll choose "b".


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)

[David Cole]

Thanks for the smile, Ed.


Dave


At 5/23/2011 05:49 PM, Ed Finnell wrote:

_http://www.dilbert.com/2011-05-22/_ (http://www.dilbert.com/2011-05-22/)


In a message dated 5/23/2011 4:47:15 P.M. Central Daylight Time,
dbc...@colesoft.com writes:

But if I  choose "a", I certainly will learn less than if I choose  "b".


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)

[David Cole]

FWIW, I just checked and the number of opt-ins ("likes" in Facebook 
parlance) is up a bit over 20% since my post. So there's some opinion 
out there that's not been expressed in this thread. Just saying...


But the total is still a substantial minority of our customer base, 
so all you Eff-book phobes out there don't have to worry ... yet.


[;)]
Dave

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)

[David Cole]

At 5/23/2011 09:26 PM, Doug wrote:

Cole,

The 'Rants and Raves' of the list really do show a unique, though 
somewhat 'mainframe' view. Glad to see you are still hard at it! Let 
the Good Karma flow and just sit back and enjoy!


Doug


Thanks for the encouragement Doug. I appreciate it. [:)]





At 5/23/2011 10:03 PM, Ted MacNEIL wrote:
It's not necessarily phobic. Don't you get it? It's the fact that 
most of your customers' management have policies in place to block.


-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL


"Most"? (a) Perhaps. (b) Perhaps not. But Ummm, that's not a "fact" 
Ted, that's just a speculation.


"Some" would be a demonstrated fact. And it certainly is a fact that 
I will have to take into account going forward.


As I said, the Facebook presence is an experiment, but so far, it is 
an experiment that I'm happy with.


But the experiment will fizzle if it does not gain wider acceptance, 
both in the specific case of my own efforts and in the wider audience 
of our industry in general.


But if I had to guess, I'd guess [obviously] that acceptance will 
broaden. And that already is a "fact" WRT my own efforts, but only a 
speculation WRT the industry. [FWIW, the particular Facebook posting 
of mine in question has garnered 171 impressions since yesterday. I'm 
quite happy with that...]


For those of you who are blocked by company firewalls, I bet that as 
I and others take to Facebook, you could mount arguments against that 
blockage. And I bet that some of you could win that argument quickly, 
and I speculate that most of you could win that argument over the 
long term. (unless of course your employer is the government... [sigh])


In any case, I'll learn far more by going with "b" than "a". So yes, 
I think I do "get it".








At 5/24/2011 07:37 AM, Elardus Engelbrecht wrote:
For example, my company blocks gamesites, FB, youtube, twitter and 
lots of others, but not google, wikipedia and linkedin. This is the 
normal trend here in sunny South Africa. ;-D


Groete / Greetings
Elardus Engelbrecht


Blocking web categories is about as good an idea as cutting diamonds 
with sledgehammers would be...




Another reason is that your company network must be available as 
much for their customers for, ahem, cough-cough, work purposes!


... but I see I'm preaching to the choir here.





For example, my company blocks [...] FB [...] but not [...] linkedin.


Maybe I'll have to reconsider my disdain for LinkedIn...






At 5/24/2011 08:34 AM, Thomas David Rivers wrote:

It is surprising how direct e-mail no longer works. [snip][snip][snip]


Thanks, Dave, for expending the effort to articulate what I was too 
tired to express. You are absolutely right. People do get tired of 
having more stuff (email, etc.) pushed to them than they can possibly 
deal with. In my case, there is a vast(!) amount of information 
reaching my in-box that I would actually find good, useful and 
interesting to read. BUT even the valuable stuff overwhelms my 
ability to deal with it. So a lot of very good stuff (such as well 
over 99% of IBM-MAIN posts) never gets past the subject line with me.


I don't agree that our Facebook page would replace our web site, but 
I do hope it becomes a very good supplement. And as I said in my very 
first post to this thread, one attraction Facebook has for us is that 
it is very easy for customers (not blocked by management) to opt-in 
and, therefore, receive our push because they want(!) to receive our push.


Thanks, Dave, for your encouragement.






Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)

[David Cole]

Please add a third question to your poll...

"LinkedIn Specifically"?

Thanks



At 5/24/2011 01:41 PM, Ted MacNEIL wrote:

>Most"? (a) Perhaps. (b) Perhaps not. But >Ummm, that's not a "fact"
>Ted, that's just a speculation.

Actually, it's not.
The Toronto Star did a survey a while back and found that a vast 
majority of corporations block all forms of social media.



While F-B was not specified, it is a social site.

I do not believe it to be speculation to extrapolate to include, at 
least, the States.
Especially, with all the posts I've seen stating that they can't get 
there from there.


Don't get me wrong, I'm not denigrating social media (I actually 
subscribe to a lot of them; I have FaceBook, LinkdIn & Twitter 
active on my BlackBerry Torch [9800] all the time.

What I don't understand is why choose a channel that is likely blocked?

But, I have no intention of making this thread into another drawn 
out argument -- you are obviously successful with your product and 
dissemination of information.


But, I will do something I don't normally do.
I shall volunteer to conduct a straw poll, open until Friday @ 1800 
EST (Canada).


To not clutter this list, and my usual inbox, io have created a 
(throw away) e-mail account for this purpose.


If you wish to participate in the survey, send your response to 
edwardamacn...@yahoo.ca.


The survey says:

Does your company block access to:
1. Social Media, in general?
2. FaceBook, specifically?

-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Facebook for professional usage (was Re: Recent maintenance for z/XDC)

[David Cole]

At 5/26/2011 10:32 AM, Ralph Robison wrote:
In the context of this debate, you may find it interesting to read 
"IBM Social Computing Guidelines" at 
http://www.ibm.com/blogs/zz/en/guidelines.html


Great find, Ralph!



Thanks,

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Problems with TSO TEST

[David Cole]

At 5/24/2011 02:36 PM, Binyamin Dissen wrote:

TEST 'SYS1.LINKLIB(IEFBR14)'
TEST
L  +0
   +0  1BFF07FE
TEST
L  +0 I
IKJ57245I INVALID INSTRUCTION CODE AT +0
TEST
AT +0
IKJ57306I NO BREAKPOINT ESTABLISHED AT +0 +
IKJ57306I INVALID OP CODE
TEST
END

Any ideas?


Yeah, try z/XDC... (sorry, couldn't resist [;)] )






At 5/26/2011 09:28 AM, Sam Bass wrote:
Many years ago IEFBR14 was moved from LINKLIB to LPALIB. You cannot 
modify modules in LPA, which is what AT command does. You would have 
to copy IEFBR14 to you own load library and test from there.


Sam Bass


FWIW, z/XDC can...






At 5/26/2011 10:11 AM, Binyamin Dissen wrote:
TEST has absolutely no problem testing modules from LPALIB. It loads 
them into private storage for testing.


Ok, for problem mode testing. Seriously problematic for APF 
authorized testing...


z/XDC, when authorized, security permitted and done with suitable 
case and intelligence, can test PLPA programs running in place... 
[recommended, of course, only when playing in a sandbox...]








Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Problems with TSO TEST

[David Cole]

At 5/29/2011 12:59 PM, David Cole wrote:

[snip]
z/XDC, when authorized, security permitted and done with suitable 
case and intelligence, can test PLPA programs running in place... 
[recommended, of course, only when playing in a sandbox...]


Sorry, that should be "suitable CARE and intelligence" ... [damned typos!]

dbc

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Assembler variable with @

[David Cole]

I sometimes use a trailing @ (in a symbol's name) as a personal 
convention to indicate that the field contains an address. But as 
noted elsewhere, the Assembler treats the @ (and the $ and the #) no 
differently from an alphabetic letter.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658




On Tue, 16 Feb 2010 16:44:40 +0100, MONTERO ROMERO, ENRIQUE ELOI 
 wrote:

Hi team,

Hope you are well,

This time is an assembler coding question. What does it means an 
at-sign (@) at the end of a constant?


Example :

R1  EQU 1
R2  EQU 2
R3  EQU 3
LIST@   EQU 4<--- ?
R5  EQU 5
R6  EQU 6
PARM@   EQU 7<--- ?
R8  EQU 8
R9  EQU 9
R10 EQU 10
R11 EQU 12
...
...


Also in this code :

L   PARM@,0(LIST@)  <--- ?
MVC DSNAME+4(44),0(PARM@)   <--- ?

Is there some especific situation to put the @ ?

Thannks a lot in advance,

Enrique Montero


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Need tool to zap core

[David Cole]

It's not free, but z/XDC will do the trick. Even more, it can also 
zap storage that's been made
"read only" (such as the PLPA, "read-only" sections of the nucleus, 
and any other page that has been made read-only by the PGSER macro).


If your client has z/XDC, then this would be an easy way to 
accomplish what you want.


Dave Cole

At 2/24/2010 11:21 AM, Pinnacle wrote:
I have a need to zap core, but my client does not have OMEGAMON.  I 
searched the CBT mods tape and came up empty.  What we're trying to 
do is a SETPROG LPA,ADD, but of course, there's a vector table that 
needs to be updated with the address of the new module.  This is not 
an SVC, so my only recourse to install this without an IPL is to zap 
core.  Are there any freeware tools out there for zapping core?


Regards,
Tom Conley


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

z/XDC z1.13 is now Generally Available

[David Cole]

z/XDC release z1.13 has finally been published! It supports z/OS 
R1.13 and the debugging of code located above the bar.


More information can be found at our Facebook page. When on Facebook, 
just search for "Colesoft Marketing", and then "like" us.


A press release can be found at 
http://www.colesoft.com/PressRelease/111014_z113release.html.


Thank You.

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

ABEND0F8-20

[David Cole]

Does anyone know what an abend s0F8-20 means?

Code 20 is not documented even in R1.13's MVS System Codes manual.

I suspect it means that you cannot issue an SVC instruction from 
above the bar. Can anyone confirm or deny that?


Thanks,

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ABEND0F8-20

[David Cole]

Thanks Peter.

Your answers are directly on point.

I appreciate it.
Dave


At 10/26/2011 07:48 AM, Peter Relson wrote:
Due to a screw-up on our part many of the z/OS 1.13 "RMODE 
64"-related updates to the books did not make it. This was one. 
While the books themselves might not get updated for some time, 
there will likely be an info APAR directing you to some web location 
where you can find all the missing information. That is not in place yet.


I can confirm that ABEND0F8-20 is indeed "you issued an SVC other 
than SVC X'D' (ABEND) from code that resides >= 2G"


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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Testing g RTM routine

[David Cole]

At 10/28/2011 11:43 AM, Bill Fairchild wrote:
After following the advice in all the other previous answers, sooner 
or later you will still need to know how to test your SRB and its 
recovery routine.  You probably won't be able to instruction-step or 
trace either very easily with TSOTEST or XDC.


FWIW: z/XDC has *explicit* support for testing SRB code that is 
actually running within SRB environments. This support includes the 
ability to step through SRBs instruction by instruction, ... and 
includes the ability to debug locked code!


Yes, there are some limitations, but they are less that what you 
might think, and within those limitations, z/XDC can be unexpectedly useful!




Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.xdc.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

z/XDC: Important Maintenance

[David Cole]

I have just posted to www.colesoft.com some important maintenance for 
the z1.13 release of z/XDC. Customers should please download and 
APPLY it at their earliest convenience.


For more information, visit ColeSoft Marketing's Facebook page.

Thank you,

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Debugging CICS Global User Exits

[David Cole]

Hi Mike,

I don't know a thing about CICS, but I do know a little about z/XDC. 
If you can give me detailed information about a Global User Exit's 
runtime environment, I might be able to help you out.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658



At 1/7/2012 11:12 PM, Micheal Butz wrote:

Hi,

 Would anyone know the best method to debug CICS Global User Exits For MVS I
usually used XDC

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

Announcement: Release z1.10 of z/XDC is now available

[David Cole]

For Assembler Programmers:

I have just posted our latest release (z1.10) of z/XDC. For more 
information, contact Bob Shimizu at r...@colesoft.com.


Thanks
Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Partners  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Mainframe hacking (getting back on topic)

[David Cole]

Does anyone here recall any published news articles or incidents 
involving mainframe hacking (any flavor of VM, VSE or MVS)?  Do you 
personally know of any incidents?


Or have any such been kept on the QT?



A couple of years ago, there was a thread called "Back doors". I 
posted something there about the vulnerability of z/OS to hacking. 
Here's the link:


http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=2F4EDA1D0DDA5823A7-&Y=dbcole%40colesoft.com

(The resulting silence was deafening.)



Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Partners  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Mainframe hacking (getting back on topic)

[David Cole]

Steve,

Yeah, that link goes to IBM-MAIN's archives, and you need a your 
email address (which IBM-MAIN already has) and a password to access 
that post and the thread in which it lives.


I've made a copy of my post at my own website. Here's that link:
http://www.dbcole.com/misc/rebackdoors.html

Dave Cole



At 7/20/2009 02:03 PM, Steve Comstock wrote:

Dave,

It sounds really interesting. But the link takes me to a page where 
it is asking me to login and it has pre-filled in your email 
address. Just a heads up.


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.



David Cole wrote:
Does anyone here recall any published news articles or incidents 
involving mainframe hacking (any flavor of VM, VSE or MVS)?  Do 
you personally know of any incidents?


Or have any such been kept on the QT?


A couple of years ago, there was a thread called "Back doors". I 
posted something there about the vulnerability of z/OS to hacking. 
Here's the link:
http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=2F4EDA1D0DDA5823A7-&Y=dbcole%40colesoft.com 



(The resulting silence was deafening.)


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Partners  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Mainframe hacking (getting back on topic)

[David Cole]

At 7/20/2009 04:49 PM, Patrick O'Keefe wrote:
I think you were saying that you have the keys to the realm if you 
are an authorized program and IBM requires authorization for far too 
many services, so it is far too easy to stick back-door code in a 
program that "needs" to be authorized.


Basically, yes.






That certainly is a hole in mainframe security, but I don't think of 
that as a "hacking" issue.   (I'm going to assume the "hacking" in 
the original posting was meant to imply a breaching of MVS security 
by outsiders where "outsiders"  could be either outside the company 
or outside the group of legitimate users - a meaning real hackers 
would find very offensive.)


My issue is mainframe security and what seems to me to be a rather 
complacent and unfounded attitude that MVS security is bulletproof. 
It is not bulletproof for the reasons that I discussed in my prior post.


To divide the issue by the distinction of "insider" vs. "outsider" 
obscures the threat.


First of all, WRT an inside threat, I grant that a person posing such 
a threat would first have to get past many (well, hopefully many) 
other security barriers before being able to exploit the authorized 
libraries vulnerability. But I don't think that therefore one should 
be unconcerned about the vulnerability.


WRT an "outside" threat, I am willing to accept (and I acknowledged 
this in my prior post) that the z/OS's defense against non-APF 
authorized threats is "bulletproof". But then to just leave the issue 
there is, I think, complacent.


The presumption seems to be that no "outsider" would have the ability 
to put a program into APF authorized libraries. Well, what about 3rd 
party vendors? We certainly provide the motivation to induce 
"insiders" to place our programs into authorized libraries. But what 
are we? "Insiders"? "Outsiders"?


(As mentioned in my prior post, one technical way to partially 
address this exposure would be for IBM to reduce the number of 
reasons requiring a program to run authorized.)







That certainly is a hole in mainframe security, but I don't think of 
that as a "hacking" issue.


I dunno. Wouldn't "Trojan Horse" fall into the category of "hacking"?







I think "hacking" around or through MVS security is very rare.


I certainly hope so... But by no means would I consider myself 
qualified to make that assertion.







FWIW, this sort of vulnerability is by no means limited to 
mainframes. The PC world is plagued by this problem. In other words, 
the model is out there. If "Western Civilization Runs on the 
Mainframe", then it's only a matter of time before someone will find 
that it's worth the effort to write a "gotta have" Trojan Horse.




Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Partners  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658





At 7/20/2009 04:49 PM, Patrick O'Keefe wrote:

Maybe the result was silence that time but the general topic has 
been discussed a number of time in a number of venues.   I think you 
were saying that you have the keys to the realm if you are an 
authorized program and IBM requires authorization for far too many 
services, so it is far too easy to stick back-door code in a program 
that "needs" to be authorized.


That certainly is a hole in mainframe security, but I don't think of 
that as a "hacking" issue.   (I'm going to assume the "hacking" in 
the original posting was meant to imply a breaching of MVS security 
by outsiders where "outsiders"  could be either outside the company 
or outside the group of legitimate users - a meaning real hackers 
would find very offensive.)


Writing a back door is "an inside job".  It could be an interesting 
hack, but I don't think that's what the OP meant.


MVS security (when used) does a good job of keeping outsiders out, 
but no system on any operating system is safe from those that are 
given the authority to bypass the security.


Pat O'Keefe

I think  "hacking" around or through MVS security is very rare.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

New DSCOPY Program Posted

[David Cole]

I have just posted to ColeSoft's website a new version of my DSCOPY 
program. The link is www.colesoft.com/Downloads/downloads_utilities.html.


DSCOPY and everything else that you find on that page is free.



DSCOPY is a generalized sequential file copying program. It features 
include the following:


1.) DSCOPY can perform any number of separate copies in one jobstep.

2.) Input datasets may be sequential, direct, or individual members 
of partitioned data sets, or a concatenation of any combination of 
the above with any combination of DCB attributes (RECFM, LRECL, and BLKSIZE).


3.) Unlike-concatenations of input files are fully supported. Any 
input file may be a concatenation of any supported datasets having 
any combination of DCB attributes.


4.) Any record format is allowed (fixed, variable, undefined) for 
input, and it may be changed to any other record format for output. 
In addition, logical record lengths and/or block sizes may also be 
changed. All such changes are automatically accommodated for.


5.) All information needed is specified through JCL or through the 
PARM field. No control dataset (SYSIN, for example) is needed.


6.) Optionally, all 1st-quadrant bytes codes can be changed to 
periods or blanks.


7.) Optionally, a large number of date related built-in symbols are 
supported that can be replaced by either UTC-time related or 
local-time related date/time values.


8.) DSCOPY contains basic support for copying only a portion of a dataset.



(Sam, if you're here, could you do me a favor? If DSCOPY is still on 
the CBT mods tape, could you take it off and replace it with the 
above hyperlink? Thanks.)







I need a short break from the code this afternoon, so I'm going to 
indulge myself with a brief walk down memory lane. The more 
here-and-now guys among you might want to stop reading at this point. 
For the rest ...


I have been using DSCOPY for almost exactly 40 years now! I wrote the 
first version in 1969. I had just changed jobs. I had been working 
for the University of Pennsylvania's Computer Center (UPCC), and was 
beginning a new job for one of their commercial customers in downtown 
Philadelphia.


UPCC was running MFT with HASP (JES2's predecessor), and the SYSPROGs 
there had written an RYO charge-back system that was completely 
implemented as locally written mods to HASP. (HASP was a perfect 
place to measure CPU seconds, I/O bytes, cards read/punched and lines 
printed because it had intercepts all over the system, including in 
the various interrupt new PSWs.)


Anyway, while working at UPCC, I discovered that their charge back 
system had an interesting flaw: It did not begin to accumulate 
accounting stats for any job until that job did it's first read/write 
from/to a card reader, card punch or line printer (spool, actually). So...


If you could put all your "sysin" into files and write all your 
"sysprint" out to temporary files, and then have a single, final 
jobstep that would write all of those files, regardless of DCB 
attributes, to the printer, then you could save a boatload of money! 
(Real money, in the case of a commercial customer ...)


So I wrote DSCOPY... Needless to say, it did not take UPCC long to 
find/fix their bug.



DSCOPY was one of my earliest Assembler programs. I had just begun to 
learn Assembler only a year or two before. (I was a FORTRAN 
programmer before that.) When I wrote DSCOPY, there were two things I 
wanted to achieve. One was to be able to copy any number of 
sequential files having any arbitrary DCB attributes, and to 
transform those attributes in any way reasonable and as needed by the 
output files/devices. So I learned a lot about DCB OPEN exits.


The other was to make it blindingly fast! At the time, pretty much 
the only sequential copying program available from IBM was IEBGENER, 
and it was abysmally slow! The way it did I/O basically led it to 
read/write exactly one physical block per revolution of the DASD 
device. If the file happened to be unblocked then oh my gawd!


So in the process of trying to make DSCOPY fast, I had to learn about 
such things as DCBs, DEBs, IOBs, PCI CCW programming, chained 
scheduling and track capacity calculations. (A 2314, for example, 
held forty 80-byte blocks per track.) I still wound up just using 
QSAM, but I did it right. I used PUT-LOCATE mode buffering, I used 
OPTCD=C, and I used NCP=nnn where nnn was (where possible) the exact 
number of blocks that could fit on a track. So DSCOPY would usually 
be able to read/write an entire track's worth of data on a single rotation.


Nowadays, DSCOPY is still fast, but so is everyone else, so speed no 
longer is its advantage. But IMO it's still awful damned useful! Feel 
free to take it, try it, and use it. Let me know how it goes ...


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft   WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX: 

DCBs and DCBEs - Could IBM have done it any worse?

[David Cole]

I just shot a bug in z/XDC that occurred only 
rarely, but once it occurred, it drove me nuts! 
And frankly, I don't think it's even "my fault". 
It comes from what seems to me (to put it as 
politely as I can) to be IBM's clear violation of 
the principle of least surprise...


Ok, first of all, here it is around 3 decades(!) 
after the introduction of 31-bit addressing, and 
DCBs still must reside in 24-bit storage?? 
And the best "solution" to this intransigence is 
the DCBE??? [sigh...]But I digress. That's a 
subject for an entirely different rant. 





What's got me going today is this. For very good 
reasons, I have created my DCB and DCBE (as well 
as a host of other data areas and control blocks) 
in key-9 storage. But my code (z/XDC), when 
running non-authorized, runs with execution 
key-8. So when I open my dataset, OPEN does the following:


  - OPEN services opens the key-9 DCB just fine, no complaints, not a peep.
  - But when OPEN sees that:
  - It's caller (z/XDC) is running in problem state,
  - And it's caller is running in execution key-8,
  - But the DCBE is in key-9 storage,
OPEN zero's out the DCBDCBE field (the DCB's link to the DCBE),
and proceeds to open the DCB without the DCBE.

Nevermind that key-9 storage is problem program storage.
Nevermind that problem state key-8 programs are 
free to write to key-9 storage no matter what.

Nevermind that OPEN has no complaint about the key-9 DCB.
Nevermind that neither GET nor PUT nor READ nor WRITE nor CHECK nor FIND
  have ever complained about the key-9 DCB and DCBE.
  (How do I know WRT the DCBE? See below...)
Nevermind that CLOSE has ever had a problem with the key-9 DCB and DCBE.
OPEN simply blows away the DCBDCBE field as if nobody would care...

Worse, OPEN gives no notice that it has done this!
  - OPEN does not abend.
  - OPEN does not fail to open the dataset.
  - OPEN does not set any return or reason code.
  - OPEN does not set any error, warning or informational flag.
OPEN just proceeds as if the DCBE simply does not matter...
[It's just unbelievable!]

So I never noticed this issue until I had a 
broken file that resulted in s001 abends, which, 
I knew, "couldn't happen"... [Boy, I wish I had a 
dime for every time I've heard that...]


So when I investigated, it took me a rather long 
time to figure it all out. Particularly because I 
couldn't believe that OPEN would do such a stupid 
thing! I was, well... surprised!





Well, it turns out that there is a pretty simple 
workaround. Out of desperation, after OPEN completed, all dumb and happy,

  - I just slammed @'DCBE back into the DCBDCBE field,
  - And I turned DCBH0 and DCBH1 flags back on,
  - And voilà, my 31-bit EODAD and SYNAD routines now work just fine.

Now, I don't use any of the other advanced 
services of the DCBE, so I don't know if this 
kludge would work with respect to those, but as 
far as I/O errors and end of data are concerned, 
my code is now happy, so I'm happy too [sort 
of... at least until IBM decides to "fix" against my workaround...]


But come-on IBM, can't you do better than this


I want to thank IBM for the wonderful life they 
and their software have given me for the past 45+ 
years! It's things like this that help sell z/XDC [;)]




Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DCBs and DCBEs - Could IBM have done it any worse?

[David Cole]

At 6/8/2011 04:25 PM, Scott Rowe wrote:

Dave,

I was happy to see that you are only "barking: at the hand that feeds you
;-)

Have you opened a PMR with IBM on this to see if it is WAD?


Well, it's certainly WAC...

For reason's I cannot get into, I am unable to open PMRs... Maybe my 
rant will move someone else to do so.


In any case, I've got my workaround, and now you do too...

Dave

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DCBs and DCBEs - Could IBM have done it any worse?

[David Cole]

At 6/8/2011 05:10 PM, Pommier, Rex R. wrote:

Dave,

But doesn't everything WAC?  (I presume you mean Works As Coded).  :-)

Rex


Uh-huh...


Way back in the '70s, when a colleague tried to file an APAR 
(remember what that actually stands for?) over some now forgotten 
issue, IBM refused to do so, saying "It doesn't need 'fixing' because 
[you guessed it] it works as coded..."


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DCBs and DCBEs - Could IBM have done it any worse?

[David Cole]

At 6/10/2011 12:37 AM, Edward Jaffe wrote:
This issue, and IBM's resolution intended for a release not yet 
generally available, was covered at the April 2010 TDM (session 36, pp. 84-85).


Ah. You, sir, obviously are far more able to stay awake at those 
meetings than I.


Your cite is exactly on point. THANK YOU!

[:)]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DCBs and DCBEs - Could IBM have done it any worse?

[David Cole]

At 6/11/2011 01:29 AM, Jim Mulder wrote:
The particular documentation to which Ed refers is available only to 
ISVs who are under nondisclosure.  Dave Cole is among those, and 
thus he should have access to it.


For the rest of the IBM-MAIN folks, I will say that it just 
describes the issue which Dave Cole has very accurately described, 
and says that it has been resolved in z/OS 1.13.


Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY


Thanks Jim. I, of course, was not free to make that disclosure. I 
appreciate your doing so for the list's benefit.



Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DCBs and DCBEs - Could IBM have done it any worse?

[David Cole]

Hi Peter,

Although I have a lot of disagreement over the original design of 
silently blowing away the DCBE for one (not disclosed) reason from a 
list of (disclosed much later) reasons, I can certainly understand 
not wanting to change that behavior now that it has been released 
into the wild.


However, that does not foreclose all possible solutions. One that 
occurs to me would be to create a new option (perhaps in the DCB, 
perhaps the new 31-bit OPEN plist) whereby the developer can 
explicitly request a more reasonable handling of a "bad DCBE" error.


WRT creating an option flag in the DCB, in regards to signalling the 
presence of the DCBE, you deftly finessed the "no available flag" 
problem by using a 2-bit signal. I bet you can do something like that 
for this as well.


In any case, you know as well as I that downward compatible solutions 
can be created. I expect at this point the real issue is 
cost-vs-benefit (ie, "resources" which is just a synonym for money 
and commitment).


Dave



At 6/13/2011 08:44 AM, Peter Relson wrote:

IBM very rarely will change an existing RC=0 to some non-0 value. This is
for compatibility reasons.
Even rarer (if ever) would be to do this in the service stream.

We would not want to break some potentially critical application that had
a "correct" program such as

OPEN
If R15 not-equal 0 then abend

When the application had, in effect, wanted the long-standing (somewhat
strange) behavior of ignoring the DCBE because of its key (or any of the
other reasons why a DCBE might be ignored).

Likely? No. Impossible? No.

z/OS is full of horrible defaults and behaviors that are legacy behaviors
that we don't dare change and instead must make a user overtly request new
behavior.

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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Lines, Bars and ... mini-bars???

[David Cole]

So I'm working on XDC adding support for debugging execution "above 
the bar", when I run into a nomenclature problem...


"Above the line" means >16M.
"Above the bar"  means >4G.

But AMODE(31) supports execution in only the zero to 2G range. For 
the 2G to 4G range, you need AMODE(64).


So what is the name for the 2G to 4G range of storage? Ok, you guys 
can go ahead and fight it out. Me? I'm just going to call it "above 
the mini bar".


[;)]

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Lines, Bars and ... mini-bars???

[David Cole]

At 7/5/2011 12:02 PM, Paul Gilmartin wrote:

Again, not the hardware, but a construct of z/OS which scrunches the
PSW to 64 bits, discarding the upper 32 bits of the program address.


LPSW loads "scrunched" PSWs... "LPSW" is sorta "in the hardware", isn't it?

Just saying...


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Lines, Bars and ... mini-bars???

[David Cole]

Hi Bruno,

It seems useful to me to have a distinct 
shorthand way to refer to the 2G line vs. the 4G 
line. Since "bar" already refers to the 4G line, 
using "mini-bar" to refer to the 2G line appeals to me.


As regards to a "name" for the 2G-4G area, 
"DEADZONE" is something I came up with back in 
2004 for use by z/XDC. But now the dead zone isn't so dead anymore, is it...


Since 2G-32G is now reserved for use by JAVA, 
maybe the "JAVAHUTT"???  ("Jabba_the_Hutt" is probably a bit too long.)


Dave





At 7/5/2011 02:24 AM, Bruno Sugliani wrote:

"So what is the name for the 2G to 4G range of storage? Ok, you guys
can go ahead and fight it out. Me? I'm just going to call it "above
the mini bar"."

Kiss principle :

Why don't you call it "the bar" like it should be ?

Or are you a toetotaller ?



--
Sincères salutations / Best regards

Bruno SUGLIANI


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Lines, Bars and ... mini-bars???

[David Cole]

So... what exactly is "the bar"? There seems to be some disagreement. 
And that's natural since, being technology developers, we make up our 
nomenclature as we go along, so variations in nuances (nuancai?) can 
easily arise...





To some, "the bar" is the 2G line...

At 7/5/2011 11:00 AM, Tom Marchant wrote:
I think that "above the bar" means >2G.  It is true that the bar was 
once described as having a thickness of 2G as IARV64 would not 
create a memory object in that area. I think that is now obsolete.


At 7/5/2011 11:49 AM, John McKown wrote:
z/OS hurls if the PSW instruction address is above the bar. [[[... 
That would be any address >=2G, so I guess John holds to the 2G line 
view. -dbc]]]


At 7/5/2011 11:51 AM, Cheryl Walker wrote:

Above the bar > 2G.


At 7/5/2011 01:10 PM, Bill Fairchild wrote:
Regardless of other restrictions that IBM may add to the use of 
storage above the bar, "the bar" is still the virtual address 2GB.





And to many, "the bar" is the very thick 2G to 4G area...

At 7/5/2011 08:11 AM, Gene Hudders wrote:
Isn't the reason it is called a Bar is because it is 2 GB in size 
and not a simple 1 byte from 16 MB to 16+1 MB? [[[... I think that 
reasin it's called a "bar" is simply becuase it is a word that is 
different from "line" -dbc]]]


At 7/5/2011 09:07 AM, Mark Zelden wrote:
Since the bar is 2G thick (or it used to be before Java started to 
use it), maybe it can be called "in the bar".


At 7/5/2011 09:34 AM, Mohammad Khan wrote:
Since bars unlike lines do have some thickness I like to think of 
the bar being the range from 2G - 4G but that's just me. [[[... No, 
apparently it's not just you. -dbc]]]


At 7/5/2011 11:32 AM, John McKown wrote:
Java uses memory "in the bar"? An IBMer stated that is impossible. 
[[[... It used to be impossible -dbc]]]


At 7/5/2011 12:02 PM, Paul Gilmartin wrote:

I vote for "within the bar".


At 7/5/2011 07:43 PM, Gibney, Dave wrote:
I've never had a problem considering it "within the bar". I always 
thought of the "bar" as being 2G thick as opposed to the 2 dimensional "line".


At 7/6/2011 06:46 AM, Jan MOEYERSONS wrote:

It's called "the bar". The bar being 2GB thick.





And some have followed their own road altogether... [;)]

At 7/5/2011 01:10 PM, Bill Fairchild wrote:

[...] above the 2G proto-bar
but possibly below the 4G quasi-bar,
or even up to the 32G neo-bar.


[[[... Well actually Bill goes on to state that he believes "the bar" 
is the 2G line. But I do like his creativity here. [;)] -dbc]]]





And to still others, "the bar" is the 4G line. That's my own view, 
and the view of ...


Oh-oh! Apparently no others? Woh!

Am I really going to have to change my whole world view here?
Or could I stick to my guns and bring all you other misguided souls 
around to my self-evidently correct view? [Sorta like the Casey 
Anthony jury, right?]


Are there any supporters out there of the >4G view?

Just wondering...
Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Lines, Bars and ... mini-bars???

[David Cole]

At 7/10/2011 03:47 PM, Justin R. Bendich wrote:
I agree with Scott and Walter that it must be above the bar if it's 
not addressable in AMODE 31. Understand that that's below GAGALAND, 
but, yeah, i guess you need another name.


What?? That didn't catch on either

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HLASM Manuals

[David Cole]

John, Thanks for asking...

How to improve the Assembler manuals? Well, one thing that comes 
leaping to mind: WRT the Reference, I would really love it if you 
would put individual build-in functions in the TOC. You do this for 
Assembler statements and even system variables... Why not for 
built-in functions as well. (This is something that has irked me for DECADES!)




But more than that...

Over all I think the Assembler Reference is very poorly organized. It 
is hard to find things within. It is hard to understand the 
implications of described functionality. The descriptions are laconic 
(to say the least), and the examples are classically awful. They 
cover only the fewest and the simplest, most obvious cases; they fail 
to illustrate useful ranges of capabilities.


I love Assembler. I've been programming in it for nearly 50 years. I 
cannot say the same for the Reference. In the entire time I've been 
programming Assembler, the organization and structure of the 
Reference has not changed one iota! Yes, new functionality has been 
added, but I don't think that more than a handful of words of the 
original text has been changed since the 1960s!


IMO, the Reference basically needs to be thrown out and rewritten 
from scratch with totally fresh eyes. And it needs to be usability 
tested along the way by an audience of people who do not already know 
the language inside and out (or by those who can at least think that way).


I hear all the time that "Assembler is hard". It is not hard. C is 
hard; Assembler is easy. It's just the manual that is hard.


I also hear grumbles that IBM manuals in general are hard. I do not 
agree. Many of them have improved quite a lot in recent decades. But 
not the Assembler Reference. It remains mired in its initial design, 
and for whatever reason, it has escaped a competent rewrite.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658





At 8/18/2011 07:00 PM, John Ehrman wrote:

On June 6, John Walker noted that IBM manuals don't make it easy to find
information you need.

If you have suggestions for improving the HLASM manuals, please let me
know, either on or off this list.

Thanks for your help.

John Ehrman,  ehr...@us.ibm.com


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Opening up Boulder Doc to user comments??? (was a new POP)

[David Cole]

There is a germ of an interesting idea here...

What about IBM changing the Boulder online doc 
(http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp) 
to permit moderated annotations/commentary arising from user experience???


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658




At 8/19/2011 02:00 PM, Kirk Talman wrote:

the root cause of most complaints about any form of documentation today is
that we have been spoiled by search engines and that we have a lot less
time to do what is right over what is expedient.  the method I have been
trying to sell on my job is use wikis as connective tissue to hold and
make effective the flesh and bones of other documentation formats.  the
response has been blank looks, sneers and ugly words.

The community that consists of the members of this list could just build
the future by making a site which represents their cumulative knowledge.
It would require managed access to fend off trolls.

Example:  IBM has a nice site for a glossary for terms.  But because it
represents knowledge gathered from across the enterprise, it appears to be
less than current and has omissions.

If wikimedia software (or the equivalent) were made to have a separate
permission list for each namespace,, and if automatic disambiguation were
implemented, the contributions of disparate groups could seamlessly (or
almost so) be merged into one knowledgebase - completely w/o a donnybrook
over who is right about, oh, say, USS.

pup

Our greatest danger in life is in permitting the urgent things to crowd
out the important. - Charles E. Hummel
Efforts and courage are not enough without purpose and direction. - John
F. Kennedy

IBM Mainframe Assembler List  wrote on
08/19/2011 01:14:25 PM:

> From: Steve Comstock 
> To: assembler-l...@listserv.uga.edu
> Date: 08/19/2011 01:16 PM
> Subject: Re: a new POP (was HLASM Manuals )
> Sent by: IBM Mainframe Assembler List 
>
> On 8/19/2011 10:55 AM, Martin Trübner wrote:
> > While I am happy with the L.R. I like to comment on Kens'
> >
> >>> The "assembler" manual I would like to see rewritten is the
"Principles
> > of Opeertations"
> >
> > Absolutly while POP (the way it is) may have its place- I have a
> > hard time reading about a certain instruction (when I need to).
> >
> > It is IMHO more than counterproductive (I dare to say confusing)
> > for the reader (but time saving for the authors of the
hardware/micro-code)
> > to have identical instructions with only variations in a-mode and/
> or targets in one
> > paragraph- this results in very subtle changes in the wording
> > for the various flavours. I would prefer (even if this would
> > create a manual three times as big) every instruction in a
> > separate text.
> >
> > For illustration look at TRxx (xx="OT/OO/TT/TO") - or (for a simpler
> > sample) look at AH/AHY/AH/AGHI.
> >
> > It would make life easier for everyone using this book if each of
> > these instructions would be explained in a different chapter. The way
> > it is now is that the reader is challenged to read all the fine print.
> >
> > To me it means reading the instructions at least twice (if not more).
> > (and all the AH is explained in different text.
>
> It is an inherently complex topic. It takes work to 'get it'. And
> even then, subtleties are easily missed. Who on this list has not
> written an Assembler program and then five years (or even six months)
> later wondered how they could write this crap? :-)
>
> It takes practice and experience. I'm not sure the authors can do
> much better without skimming over points that come back to bite
> the unsuspecting programmer later.
>
> Of course, a class can help speed the process.   :-)
>
>
> >
> > --
> > Martin
> >
> > Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
> > more at http://www.picapcpu.de
> >
>
>
> --
>
> Kind regards,
>
> -Steve Comstock
> The Trainer's Friend, Inc.
>
> 303-393-8716
> http://www.trainersfriend.com
>
> * Special promotion: 15% off on all DB2 training classes
>  scheduled by September 1, taught by year end 2011
>
> * Check out our entire DB2 curriculum at:
>  http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm


-
The information contained in this communication 
(including any attachments hereto) is 
confidential and is intended solely for the 
personal and confidential use of the individual 
or entity to whom it is addressed. If the reader 
of this message is not the intended recipient or 
an agent responsible for delivering it to the 
intended recipient, you are hereby notified that 
you have received this communication in error 
and that any review, dissemination, copying, or 
unauthorized use of this information, or the 
taking of any action in reliance on the 

z/XDC release z1.13

[David Cole]

Sometime in September (guess when), we will be publishing release 
z1.13 of z/XDC.


There is more information at our Facebook page. To access it, get 
onto Facebook, search for "ColeSoft Marketing" and "Like" (i.e. opt 
in to) our page there.


Thanks,

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.xdc.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

z/XDC release z1.12 is NOT! supported in z/OS R1.13 Systems (repost)

[David Cole]

[Damn! I'm constantly forgetting that these lists don't like HTML 
formatted posts... sigh]




Because of some changes that IBM has made in z/OS R1.13, there is a 
potential for System corruption when older releases of z/XDC (z1.12 
and older) are run in z/OS R1.13.


I want to emphasize that it is not(!) likely that other z/OS software 
will have the same issues that z/XDC does.


I also want to emphasize that these issues have been corrected in our 
z1.13 release of z/XDC, and that z1.13 will be made available both 
when z/OS R1.13 is G.A.'d and to anyone else amongst our customers 
who is running a pre-release version of z/OS R1.13.


I also want to emphasize that the problems that z1.12 and older 
releases of z/XDC have in z/OS R1.13 are intermittent and can be 
hidden and can be remote from z/XDC.


Accordingly, we will not support the running release z1.12 (and 
older) of z/XDC in z/OS R1.13, and recently we have even gone so far 
as to post maintenance for z1.12 that, once applied, will prevent 
z1.12 from even running within z/OS R1.13.


If you are currently running z/OS R1.13 and also running z/XDC z1.12 
(or older), please immediately contact us privately so that we may 
send you our beta of z1.13.


Thank You,
Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658


At 8/30/2011 10:54 AM, David Cole wrote:

The best I can say, Ed, is that I find that "surprising". More privately.

Dave


At 8/30/2011 10:22 AM, Edward Jaffe wrote:

On 8/30/2011 4:25 AM, David Cole wrote:

Sometime in September (guess when), we will be publishing release
z1.13 of z/XDC.

There is more information at our Facebook page. To access it, get
onto Facebook, search for "ColeSoft Marketing" and "Like" (i.e. opt
in to) our page there.


We have been using z/XDC z1.12 under z/OS 1.13 since January 
without any obvious

problems. I guess we've just been lucky. Either that or we're not very
sophisticated users. ;-)

--
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

TCBFX vs. TCBNOIRB

[David Cole]

Can anyone tell me the difference in purpose or management between 
the TCBFX flag and the TCBNOIRB flag?


As far as I know they both are supposed to prevent the queuing of 
IRBs. In the IKJTCB macro they each are doc'd as follows:



TCBNOIRB EQU   X'40' - If on, IRBs will not be queued to this TCB. @08A
*  A program setting this flag MUST save its
*  current value and restore that value either
*  when that program can tolerate IRBs being
*  queued or before the current RB terminates.




TCBFXEQU   X'01' - PROHIBIT QUEUEING OF ASYNCHRONOUS EXITS FOR
*  THIS TASK



So why do they both exist?


Thanks,

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Who uses RBGRSAVE in a task's *oldest* RB?

[David Cole]

Here's an interesting question... Given that when a task is interrupted:

(1) It's registers (Rn, RHn and ARn) are saved in the TCB and STCB

(2) When the interrupt (such as SVCs or program checks or certain 
asynchronous ones) leads to the creation of a new RB, those saved 
registers are eventually copied into the *newly created* RB and XSB


... it would seem that the RBGRSAVE, XSBARS and XSBG64H fields for 
the *oldest* RB and XSB would remain forever unused.


HOWEVER, I ran a test. From an instance of an authorized XDC running 
under a newer RB, I manually zapped the contents of the *oldest* 
RBGRSAVE to garbage values to see what would happen when said oldest 
RB (two RBs removed from XDC's RB) was later resumed. To my surprise, 
trouble did not wait. My aspace crashed instantly! (s333-20).


So somebody's using that oldest RBGRSAVE in an unexpected way. I'm 
just wondering if anybody knows who...


Thanks,

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: TCBFX vs. TCBNOIRB

[David Cole]

Hi Jim,

Thanks for taking a stab at this. I've looked at the APARs you 
suggested, but if the offer clues to my question, I'm not seeing them...


As far as I know, TCBFX and TCBNOIRB both serve the same function: 
When either is on, the queuing of IRBs to the task is deferred. Both 
of the APARs you suggested, discuss problems when such deferrals are 
not managed properly.


What I want to know is, why the redundancy? Why are there two flags 
that serve the same purpose? There must be subtle differences... What are they?


What am I missing?

Thanks,
Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658




At 9/30/2011 02:04 PM, Jim Thomas wrote:

Sir,

For TCBNOIRB, I'd suggest scanning thru an old APAR (OA19796) and 
perhaps following on to some of the other related APAR's (please 
keep in mind, 'IRB').


For TCBFX, I'd suggest, OA16342 and related (please keep in mind, 
'asynchronous').


From the little I've used these flags, it's more a question of whom 
the 'setter/reset r' is and obviously, what is being done.



Kind Regards

Jim Thomas
617-233-4130 (mobile)
636-294-1014(res)
j...@thethomasresidence.us (Email)

-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of David Cole
Sent: Friday, September 30, 2011 5:01 AM
To: IBM-MAIN@bama.ua.edu
Subject: TCBFX vs. TCBNOIRB

Can anyone tell me the difference in purpose or management between 
the TCBFX flag and the TCBNOIRB flag?


As far as I know they both are supposed to prevent the queuing of 
IRBs. In the IKJTCB macro they each are doc'd as follows:


TCBNOIRB EQU   X'40' - If on, IRBs will not be queued to this TCB.
*  A program setting this flag MUST save its
*  current value and restore that value either
*  when that program can tolerate IRBs being
*  queued or before the current RB terminates.


TCBFXEQU   X'01' - PROHIBIT QUEUEING OF ASYNCHRONOUS EXITS FOR
*  THIS TASK


So why do they both exist?

Thanks,
Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: TCBFX vs. TCBNOIRB

[David Cole]

Ok, that's a policy difference and is good to know. Thanks.

I'd still like to know what the functional difference is (if any).


Thanks,
Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658




At 9/30/2011 02:50 PM, Tom Harper wrote:

David,

I believe that TCBNOIRB is within TCBFLGS8 which is part of the 
programming interface whereas TCBFX is within TCBFLGS1 which is not.


Tom


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: TCBFX vs. TCBNOIRB

[David Cole]

Interesting...

How old is your "Stage 3 exit Effector Logic" manual? (I'm guessing 
at least a couple of decades.) I *think* that the TCBNOIRB flag might 
be newer than your manual.


I don't know when it was introduced, but I became aware of TCBNOIRB 
only within the past year. The TCBFX flag I've known about for several decades.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658




At 9/30/2011 04:01 PM,   wrote:
Is it possible that TCBFX is used to suppress the scheduling of all 
asynchronous exit for a task, whereas TCBNOIRB specifically 
suppresses IRBs but not SIRBs. Stage 3 exit effector logic manual 
indicates TCBFX=1 prevents all asynchrounous scheduling to the task 
but has no mention of TCBINOIRB.


Thanks,
Raymond Wong


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: TCBFX vs. TCBNOIRB

[David Cole]

At 9/30/2011 04:12 PM, Jim Thomas wrote:
The focus is not on IRB's but mainly, the ability to use SRB's .. 
(this is where I tried to point out IRB vs SRB .. IOW ... with 
TCBNOIRB ... you can still ... IIRC, use SRB's).


"SRBs"? or "SIRBs"?

I would be surprised if a TCB setting such as TCBFX would have any 
affect at all on SRBs. But I think maybe Faye Huang maybe has 
something when she said: "...whereas TCBNOIRB specifically suppresses 
IRBs but not SIRBs".


I actually don't know anything about "System Interrupt Request 
Blocks" (SIRBs). I know that they exist, but I don't know what 
they're used for. Can anyone enlighten me on this issue as well?







If you'd like to go into detail .. perhaps explain what you're 
trying to do and such ... please feel free to contact / email me .. 
(after the weekend though please) directly and please understand 
that my current access to MVS (or z/OS or whatever the hell you want 
to call it) is rather limited so my responses might be slooow


Thanks for the offer. At the moment, though, I'm just researching.



Kind Regards

Jim Thomas
617-233-4130 (mobile)
636-294-1014(res)
j...@thethomasresidence.us (Email)


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: TCBFX vs. TCBNOIRB

[David Cole]

That puts it at z/OS R1.5


At 9/30/2011 04:36 PM, Jim Mulder wrote:

> Wow, it actually dated back 1981, 1983. I do not even realize TCBNOIRB
> didn't exist then. Do you know what z/OS version it was introduced?

  "Use the source, Luke".


I don't always think to look in MACLIB...

Would that I had your level of access to the source, Jim.



Can you shed any link on my TCBFX vs TCBNOIRB question?

Dave






 BROWSESYS1.MACLIB(IKJTCB)Li
 Command ===>
.*  $08=OW47908  HBB6605  010129  U2IAXZ:  Add TCBNOIRB

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: TCBFX vs. TCBNOIRB

[David Cole]

Thanks for the link, Jim. I'll take a look.

Dave

At 9/30/2011 04:41 PM, Jim Thomas wrote:

Sir,

Try this ... I think (like Ray) that I have the same manual ...

http://www.bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/plm/GY28-6616-9_OS_IO_Su
perv_PLM_R21.7_Apr73.pdf

and yes ... it is old ... but for the most part, still very much valid (that
I know of).


Kind Regards

Jim Thomas
617-233-4130 (mobile)
636-294-1014(res)
j...@thethomasresidence.us (Email)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: File 120 now has 2 new articles

[David Cole]

WOW! Of all the tools available on PCs for writing and packaging 
content, why on EARTH would you choose .XMI !


That certainly will keep your circle of readers ... umm ... "exclusive".


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658






At 6/7/2010 11:13 PM, Sam Golob wrote:

Hi Folks,

   Since I stopped writing for NaSPA's "Technical Support" 
magazine, it doesn't mean that I've stopped writing articles 
completely.  On File 120 of the Updates page of www.cbttape.org, 
the articles prefixed by member names:  BM** are owned by me, 
and NaSPA doesn't have any connection with them.  There are two new 
articles there now (on the Updates page), with member names 
BM1005MY and BM1006JN.  I trust you will find them interesting.


   All the best of everything to you and yours

Sincerely,Sam Golob

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

z/XDC announcement: Release z1.12 is now available for beta test

[David Cole]

z/XDC release z1.12 is now available for beta testing. Major new 
features include:


  - SRB debugging support improvements

  - New reporting commands regarding access lists and data spaces

  - The ability to access (display and zap) data spaces that 
previously were not accessible


  - Improvements in formatted storage displays

  - New Helper Dialogs for assisting with various debugging 
processes (in progress)


  - New z/Enterprise machine instructions (planned)

  - Infrastructure for planned new capabilities

For more details, please check www.colesoft.com/News.



Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PoPs

[David Cole]

Rick,

The -08 edition of the PoPs won't be out until September sometime. 
Meanwhile, what *IS* published is this:

http://share.confex.com/share/115/webprogram/Session7034.html

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658





At 8/22/2010 04:37 PM, Rick Fochtman wrote:
Could one of you fine ladies or gentlemen kindly download the PF of 
the latest Principles of Operations and E-Mail it to me as an 
attachment? (I'd also accept BookManager format, but I'm told that 
it's not available.)


I am having no end of difficulty in getting any sort of access to 
that page. It asks me to sign up, then tells me I'm already signed 
up. When I try the reset password mechanism, it tells me that I'm 
not a registered user. Can we say "Circular logic"???


Rick


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Slightly crazy idea to speed up EX instructions (XDC issue?)

[David Cole]

On Feb 19, 2009, at 14:43, David Cole wrote:
The reverse case, though, is problematic: When you EX the 
immediately following instruction, z/XDC's tracing process can get 
stuck. Years ago, though, I had one customer who actually liked 
this "defect". When he learned of this, he immediately started 
using such code sequences as "gatekeepers" to try to keep an XDC 
user out of code that he wanted to keep "secret". (Or at least make 
tracing it exceedingly inconvenient.)


At 2/19/2009 05:04 PM, Paul Gilmartin wrote:
Oops?  Breakpoint code overlays the EX target?  A suitably enhanced 
z/XDC should be able to handle this.


Hi Paul, In all cases *except* the "EX *+4" case, XDC does handle 
things correctly. In particular, XDC is perfectly fine with setting a 
breakpoint either on the EX or on its target or on both! (In the 
"both" case, XDC will receive control first for the breakpoint on the 
EX, then second for the breakpoint on the target, before allowing the 
code to move on [.org].)







But I'll readily agree if you say it's worth neither the execution 
overhead nor the coding resource.


Coding a solution for the "EX *+4" case was not, as they say, 
"commercially feasible". (Coding solutions for the other cases was, 
in my youthful exuberance, fun!)


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Partners  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3270 Emulator Software

[David Cole]

David Cole ✆ to IBM
show details 6:19 AM (25 minutes ago)
Quoting from " http://tinyurl.com/3xybhe8":
>"Each individual Samsung LCD has a 19-inch diameter screen"

Uh ... Diagonal?





On Sat, Aug 28, 2010 at 7:52 PM, Edward Jaffe
wrote:

> Ed Finnell wrote:
>
>> Don't be such a  piker
>>  http://tinyurl.com/3xybhe8
>>
>>
>
> Now you're talking! 8-)
>
>
> --
> 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: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS V1.12 differences and z196 (the new mainframe) impacts

[David Cole]

At 9/13/2010 09:23 AM, Paul Gilmartin wrote:

On Mon, 13 Sep 2010 06:35:45 -0600, Steve Comstock wrote:
>
>* GETMAIN now returns address of gotten area in R1 with the
>   leftmost word being all binary zeros, so address can be
>   treated as a 64-bit address
>
Unconditionally?  That would break subroutines that don't
save/restore high order parts.  (Or does R1 not matter?)

-- gil


Gil,

I once raised a similar question with Peter Relson. He unequivocally 
asserted that no program can rely upon any part of (including the 
high halves of) the volatile registers (r15, r0 and r1) being 
preserved across system interfaces (unless the interface doc states 
otherwise).


Here's the quote:
At 3/18/2007 08:07 AM, Peter Relson wrote:

Dave,

Except for regs 0,1,15 your assertion is true.

The high halves of those regs are not preserved across any interface 
unless otherwise documented.


This is documented in the assembler services guide

2.1 Saving the Calling Program's Registers
 [snip]


This is in contradiction to a verbal statement he made at a 
presentation several years earlier wherein he flatly stated that no 
preexisting AMODE(24/31) program would ever behave differently (due 
to the widening of the registers) when run in z/OS vis-a-vis OS/390. 
Unfortunately, I don't have "the video".




Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

z/XDC release z1.12, beta #2 posted: z/Enterprise machine instructions supported

[David Cole]

Hi All,

I have just posted beta build #2 for z/XDC's upcoming release z1.12.

z/XDC is a development and debugging tool for Assembler Language 
code. This build includes support for the new z/Enterprise machine 
instructions (all of them).


Also, this release includes a growing set of "Helper Dialogs" (sorta 
like "Wizards") to help with using some of z/XDC's more complex features.


More information can be found at 
www.colesoft.com/PressRelease/100816_z112beta.html. Existing z/XDC 
customers can get access to the beta by contacting me.


Thanks,

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Please disregard prior email from LEA COLE. It's biogus. We got hacked. Sorry

[David Cole]

If you just now received an URGENT HELP NEEDED email from my wife, Lea Cole,
please disregard it. Here gmail account got hijacked. We're trying to fix it
now.

Sorry,
Dave Cole

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Mainframe hacking?

[David Cole]

At 10/13/2010 10:26 AM, Greg Shirey wrote:

I liked this article, and it's fairly recent.  (Jan 2010)

http://www.mainframezone.com/it-management/mainframe-hacking-fact-or-fiction/P1

Greg


I read that article, and it is a good one. Interestingly (to me at 
least), on the article's third web page, there is an excerpt from a 
post I made here in 2006. It's nice to know that someone is paying attention.


My entire post can be found at: 
http://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=147B1F23465267AA41&Y=dbcole%40colesoft.com


I think the information in that post are highly relevant to the 
current thread.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: When will MVS be able to use cheap dasd - 24/7 DASD on PCs

[David Cole]

At 10/8/2010 03:35 PM, Rick Fochtman wrote:

--
My 2 cents worth: the "cheap DASD" doesn't live up to the 
reliability standards that IBM demands for z/OS. Stop and think, 
really hard, about the demands on z/OS DASD storage, as opposed to 
the "standards" you enjoy with your PC DASD. How many of your PC's 
stay up, with DASD spinning, on a 24/7 basis, for several years 
without problems?


Rick


FWIW: We've run around 10 PCs 24/7... for years! One for a decade! 
The hard drives do just fine...



Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Mainframe hacking?

[David Cole]

At 10/14/2010 12:24 PM, Chris Craddock wrote:
(as Bob knows) it is impossible to create/install a malicious FLIH 
or SVC or PC without already having the keys to the kingdom anyway. 
That is the foundation of integrity and the reason why the 
installation has to appropriately protect system datasets and APF libraries.


Well that's just the problem, Chris, isn't it... The keys to the 
kingdom really are not well guarded. That's what my 2006 post was all about.




Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Mainframe hacking?

[David Cole]

At 10/14/2010 07:54 PM, Rick Fochtman wrote:



For example, why do IDCAMS and IEBCOPY have to be authorized?  The
IEBCOPY replacement doesn't have to be authorized.  Would it be
worthwhile for both vendors and users to see what they can do to
reduce the amount of code that has to be authorized?


[snip]

Also, IIRC, IEBCOPY uses I/O appendages that require authorization, 
since they are loaded from SYS1.SVCLIB.


When IEBCOPY was converted from MVT to MVS, the developers at the 
time wanted to make it run "as fast as possible". Also, IEBCOPY might 
have been a good vehicle for testing/experimenting with those 
wonderful new interfaces.


Certainly, there is no technical reason in the world (at least I 
don't know of one) why a functionally identical could not be written 
that did not require authorization...


It's probably a matter of "It ain't broke, so for god's sake don't fix it!"

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why does TEST ... (Comments WRT z/XDC)

[David Cole]

At 11/9/2010 04:23 PM, Binyamin Dissen wrote:

Why does TEST cancel breakpoints on BRC instructions?

Any ideas why this weird restriction exists?


z/XDC does not have this restriction.






At 11/9/2010 05:45 PM, Rick Fochtman wrote:
I seriously doubt if TEST has been updated in "donkey's years". I've 
noticed other restrictions.


z/XDC continues to be actively developed. Example: When IBM GA'd the 
z/Enterprise this past September (which has over 100 new machine 
instructions), we released to beta test our support for those new 
instructions only 3 days later.







At 11/9/2010 05:52 PM, Starr, Alan wrote:
I'm reasonably sure that TEST / TESTAUTH establish a breakpoint by 
actually replacing your code at that address with X'0A3D' (i.e. SVC 61).


Almost correct. The breakpoint SVC is 97, not 61. SVC 61 is used in 
deferred breakpoint support. When TEST is running (TCBTCP=1), 
Contents Supervisor issues SVC 61 (after it places a load 
module/program object into user storage) so that deferred 
breakpoints, if any, can be set.







At 11/9/2010 05:52 PM, Starr, Alan wrote:
This [the breakpoint SVC] is the fundamental reason why there are 
some instructions which may not be breakpointed (e.g. EX or the target of EX).


z/XDC does not have either of these restrictions. We fully support 
breakpoints both on an EX (and EXRL) or on their targets or on both 
the EX/EXRL and their targets simultaneously.


Support for doing this is simplified because we use 1-byte wide X'00' 
"opcodes" for our breakpoints, not 2-byte wide SVCs. Imagine what 
happens when an EX target is replaced by an SVC 97. When the EX is 
issued, the SVC number can be changed from 97 to a large number of 
other values. Thus, a random SVC would be issued, not SVC 97. And so, 
not only would TEST not receive control, but random wonderment would 
also ensue.


Now imagine the same scenario but in XDC's case where only one byte 
is changed (to X'00'), not two bytes. Then when the EX is issued, an 
0C1 occurs, not a random SVC. Thus, XDC will always receive control 
and will recognize and process the 0C1 as a breakpoint, just like normal.







At 11/9/2010 07:47 PM, Brian Kennelly wrote:
The offset in a BRC is relative to the instruction, whether it is 
executed directly or by EX, so you cannot easily execute it out of 
line without recalculating the offset or simulating execution.  It 
is easier to restore the instruction and execute inline.


Bingo!

In any case, z/XDC does not have this problem because all 
breakpointed instructions are run by actually running them in place 
in their true execution environments (not EX'ing them from the 
debugger's environment). Accordingly, z/XDC has had mechanisms from 
day one [back in 1980!] for restoring ATs once execution has moved past them.


This design permits z/XDC to support placing breakpoints on EVERY 
machine instruction that z/Systems supports! regardless of how it 
affects the execution flow or environment. (Well... every instruction 
that I know about. And... uh... not on SIE. Sorry).


But even for unpublished instructions, z/XDC breakpoints will work as 
they should just so long as those instructions don't branch.







Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.xdc.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

z/XDC Release z1.12 now avaiable

[David Cole]

z/XDC release z1.12 is now fully available. Major new features include:

   - SRB debugging support improvements

   - New reporting commands regarding access lists and data spaces

   - The ability to access (display and zap) data spaces 
that  previously were not accessible


   - Improvements in formatted storage displays

   - New Helper Dialogs for assisting with various debugging 
processes (in progress)


   - Full support for all of the new z/Enterprise 196 machine instructions

   - Infrastructure for planned new capabilities

For more details, please check 
www.colesoft.com/PressRelease/110118_z112release.html. (Or just go to 
colesoft.com and navigate from there.)


I want to thank those of you who made our beta program a success. 
Your comments and suggestions were quite helpful.




Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Name/tokens

[David Cole]

At 9/10/2008 09:50 AM, Rob Scott wrote on IBM-MAIN:

Peter,

In the past, I have seen software that uses part of the "name" as a 
constant prefix and then places variable information in the later 
part of the name (maybe ASID, TCB or subsystem "instance" or 
whatever the developer wanted) - I imagine this can happen when the 
"token" part is already full. In this case the ability to list the 
name/tokens for search purposes would be desirable.


Ditto.

z/XDC used to keep track of certain control data via ENQs. The RNAMEs 
all were control data that started with an identifying keyword 
followed by specific data. I could then use GQSCAN to search for and 
return all instances of a desired control data type simply by 
specifying a GENERIC scan for the first n bytes of the RNAME.


Some 6 or 8 years ago, I had reason to switch from using enqueues and 
GQSCAN to using name/token services. What should have been a rather 
straightforwards conversion turned out to be immensely complicated by 
the fact that name/token services did not in any way support generic searches!


It was a major P.I.T.A.!

That's my nickel's worth.

Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.xdc.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Name/tokens

[David Cole]

This is a bizarre response, Peter. Several of us have documented our 
need for a name/token list/search service, a need that we've felt 
strongly enough about to actually go to the trouble of writing 
complicated workarounds to your failure to fulfill that need. What 
more do you want by way of demonstrating a need?




it seems pretty clear to me that you should not take an approach 
that requires such a service.


Our needs dictate our approaches, Peter. If you feel that my product 
does not "need" a list/search service, then feel free to quit IBM and 
come work for me and find a better way to code to my product's needs.


If you feel that we are not competent enough to correctly determine 
our own needs, then why are you even talking to us?


David Cole







At 9/11/2008 07:28 AM, Peter Relson wrote:

Every response to my query seems to have missed the point and put the "cart
before the horse".

I don't disagree that it is desirable to have a "list" service for
name/tokens. What I question is the need.
Since a list service does not exist, it seems pretty clear to me that you
should not take an approach that requires such a service.

You are welcome of course to ask for such a service and, after/if it is
made available, exploit it.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Deleting named ISPF edit profiles

[David Cole]

Does anyone know if there is a way to delete a no longer needed named 
ISPF edit profile?


TIA

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


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

Re: Deleting named ISPF edit profiles

[David Cole]

Well, thank you, John! That was almost exactly the information I 
needed. With the following adjustments, I was able to get the job done.
   * It doesn't look like I need to start with "ISPF TEST". Just 
"ISPF" seems to work just fine.

   * On my system, the Tables Utility is at =3.16.
   * Once within the Utility, to get at the EDIT profiles, I needed 
to provide the ddname "ISPPROF".

   * And on my system the table name is, indeed, "ISREDIT".
   * If I omit the "Option" and "Table Name" fields on the "ISPF 
Table Utility" page:

   * I am shown a list of all profile members
   * I than can issue "E" on the "ISREDIT" line to open that 
table for editing.

   * This displays a named list of profiles within "ISREDIT".
   * I can then use the "D" line command to delete the profiles I 
want to get rid of.


So thanks, John, for putting me on the right track.

Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658






At 3/1/2012 08:18 AM, McKown, John wrote:

I'm sure somebody does. Is that your question? 


The edit profiles individual rows in the ISREDIT table. You can 
manually deleted by using ISPF TEST, option 4 (Tables). But the 
table is not "keyed", so you must search it for the proper row 
number to delete.


Well, I "lied" a bit (if "not 100% complete truth" == "lie"). 
ISREDIT is the "normal" table name, but the ISR prefix can be 
different if the ISPF application is not "ISR". Eg, when you edit in 
SDSF, the prefix is ISF instead of ISR. So the table name is then 
ISFEDIT. In general, it is abcEDIT where abc can vary.


--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential 
or proprietary information. If you are not the intended recipient, 
please contact the sender by reply e-mail and destroy all copies of 
the original message. HealthMarkets(r) is the brand name for 
products underwritten and issued by the insurance subsidiaries of 
HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), 
Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM




> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Cole
> Sent: Thursday, March 01, 2012 5:57 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Deleting named ISPF edit profiles
>
> Does anyone know if there is a way to delete a no longer needed named
> ISPF edit profile?
>
> TIA
>
> Dave Cole  REPLY TO: dbc...@colesoft.com
> ColeSoft Marketing WEB PAGE: http://www.colesoft.com
> 736 Fox Hollow RoadVOICE:540-456-8536
> Afton, VA 22920FAX:  540-456-6658
>
> --
> 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


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

Re: Program FLIH backdoor - This is a criminal breach of security!

[David Cole]

Ed,

Let me quote to you what Bill Fairchild posted earlier on this thread:

At 2/23/2012 05:42 PM, Bill Fairchild wrote:
I found a similar (and maybe the same) vendor hook in 1996, 
disassembled the code, and discovered that one of its purposes was 
to put an unauthorized caller into various protect keys, supervisor 
state, etc., based on the contents of a register.   I alerted the 
vendor that using a hook such as this was not the optimal way to get 
into some authorized state.  Literally anyone could have 
disassembled the code enough to see how to exploit the hook and get 
an unauthorized program into supervisor state and key 0.  The vendor 
made some changes shortly thereafter and claimed that the 
enhancement was now much better.


[***===>] I didn't have time to disassemble the new version and 
figure out how to hack into it, but a colleague of mine did and said 
it was still relatively easy to subvert. [<===***]


This vendor has many products which are typically installed in a 
system all at the same time, and many of their products make use of 
this program FLIH hook to do authorized things.


That is the genesis of my very strong reaction to this thread.

Certainly hooking xFLIH or SVCs or whatever is not, in and of itself, 
evil. However, then using said hook to grant "your" programs 
authority is where it all goes very very south! As Fairchild's 
colleague demonstrates, such backdoors generally can be subverted.


That fact that "we" do not "know" that the code is still subvertable 
is no excuse for inaction. The threat, as described in this thread, 
is significant. Doing nothing is just burying one's head in the sand.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658






At 3/1/2012 11:52 AM, Edward Jaffe wrote:

On 3/1/2012 6:52 AM, David Cole wrote:


This is not just despicable, under today's law, it is actually criminal! Any
vendor who does this could be (and should be) jailed in criminal courts and
sued out of existence in civil courts.

I do not know who is doing this, but I believe utmost pressure must 
be brought
to bear upon that vendor so that it will commit every resource to 
removing the

breach from its products.


Just to clear: intercepting the FLIH does not itself constitute an 
exposure and,

as far as state changes go, the checking and requirements could be complete
enough to avoid any integrity problem. For example, the methodology could be
similar to that employed by IBM's IGX00011 "magic" SVC and its 
intended caller.
Unless someone can prove there really is an exposure, which to my 
knowledge has

not been done, I suggest that passing such judgment is premature.

--
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: Program FLIH backdoor - This is a criminal breach of security!

[David Cole]

John Gilmore wrote:
even though, as I believe, the the offender's code itself commits no 
substantive offense it it is, I think, guilty of the admittedly much 
subtler offense of providing a template for others, who are bent on 
mischief, to use.


If the PFLIH hook is (as it has been described earlier in these 
threads) a mechanism by which a non-authorized process can become 
authorized, then its very existence is a "substantive offense" in and 
of itself. It is not just "a template", it doesn't just show the way. 
It *is* the way.


I fervently hope that the existence of this thread has gotten the 
attention of the ISV who has created this obscenity and that it will 
commit immediate resources to purging this from its products.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658





At 3/1/2012 04:54 PM, John Gilmore wrote:

I don't want to put words in EJ's mouth; but if 'an exposure' were
replaced by what I should call 'misuse' what he said is correct and
not even controversial.

I think there is an exposure, in the sense that this device lends
itself very readily to abuse.  I have seen no evidence that it has
actually been misused in any but the tenuous sense that it adds
clandestine overhead to the processing of every interrupt.

The device itself has been much misused elsewhere.  A number of
viruses have, for example, used a Windows scheduled task---PC Health
Data Collection is a favorite---to hijack PCs.

Moreover, now that its use has been publicized here, the scheme it
embodies---not, a fortiori, the offender's code itself---is all but
certain to be used irresponsibly by others; even though, as I believe,
the the offender's code itself commits no substantive offense it it
is, I think, guilty of the admittedly much subtler offense of
providing a template for others, who are bent on mischief, to use.

John Gilmore, Ashland, MA 01721 - USA

--
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: Program FLIH backdoor - This is a criminal breach of security!

[David Cole]

At 3/1/2012 06:46 PM, Skip Robinson wrote:
For years we ran a 'channel extender' product call RDS. It worked by 
front-endng FLIH for I/O interrupts to determine whether the I/O was 
to or from a supported device as defined to RDS. If not, the I/O was 
passed along for normal processing. If so, RDS redirected the I/O to 
its own network device for transmission (out); or written to the 
intended device (in). It sounds kludgy, but it worked amazingly 
well. The vendor was very forthright about the internals. We had 
occasional hardware problems with RDS, but I never once saw an OS 
failure caused by this technique.


This sort of thing is best not done at home.


This also is a example of a "legitimate" use of an intercept. It does 
not confer authority upon its caller. All it does is perform a 
service on behalf of a caller and which the caller itself does not 
have the authority to perform on its own. In this sense it is no 
different from any other system service (OPEN, WTO, GETMAIN, etc.) 
performed by the OS.








JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

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

Re: Program FLIH backdoor - This is a criminal breach of security!

[David Cole]

At 3/2/2012 10:25 AM, Edward Jaffe wrote:

On 3/2/2012 1:29 AM, David Cole wrote:
If the PFLIH hook is (as it has been described earlier in these 
threads) a mechanism by which a non-authorized process can become 
authorized, then its very existence is a "substantive offense" in 
and of itself. It is not just "a template", it doesn't just show 
the way. It *is* the way.


I keep coming back to IGX00011. It's presence on z/OS systems PROVES 
that the very existence of a "magic" SVC service, while arguably not 
a 21st-century best practice, is NOT considered an exposure or 
"substantive offense" when done correctly. (Those last three words 
are very important!)


A "magic" PFLIH technique is not substantially different, from an 
integrity standpoint, than a "magic" SVC except that the code gets 
control for EVERY interrupt and so has the potential to slow things 
down if not implemented efficiently.


The real question is whether an unintended third party can use the 
code to become authorized.


Yes. That absolutely is the "real question".
And absolutely, that is what Bill Fairchild's post asserts.
So that absolutely is why I am concerned.






Unlike the "magic" SVCs of the past, I'm confident that IGX00011 
cannot be exploited by unintended third parties.


That is good to know.







The same might very well be true of the PFLIH approach being discussed here,
despite any third-party hearsay from Bill Fairchild's colleague 
claiming otherwise.


Certainly, the "hearsay" could be wrong. And I do hope that it is wrong.
But it is a better course to assume that the charge is right and 
raise awareness to the point where it will be investigated and PROVEN 
to be right or wrong...


... than it is to assume that the charge is wrong and just sit back 
and *hope* that nothing bad happens.


In other words, I think that being noisy about this issue will have a 
more constructive result than being silent will.








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


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


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

Re: Secret Service Guide

[David Cole]

Have you tried just Googling the manual numbers?


At 3/16/2012 10:45 AM, R.S. wrote:

W dniu 2012-03-16 14:44, Zaromil Tisler pisze:

Service Guide, IBM System z10 Enterprise Class (GC28-6866-05)

<  http://www-01.ibm.com/support/docview.wss?uid=pub1gc28686605>


Thank you, I appreciate it.
I just downloaded it.

I also found doc number for older machines:
z9 EC Service Guide GC28-6841
z9 BC Service Guide GC28-6853
z990 Service Guide G229-9039
z900 Service Guide G229-9027

I also found z9EC Service Guide in hardcopy (still looking for sofcopy).

So, I'm still looking for Guides for z990, z900 and maybe older machines.

I also revealed that the publications usually 
were delivered on CD/DVD with the CPC.




Regards
--
Radoslaw Skorupka
Lodz, Poland


--
Tretej wiadomoci moe zawierainformacje prawnie 
chronione Banku przeznaczone wycznie do uytku 
subowego adresata. Odbiorcmoe byjedynie jej 
adresat z wyczeniem dostpu osób trzecich. Jeeli 
nie jesteadresatem niniejszej wiadomoci lub 
pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej 
rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest 
prawnie zabronione i moe bykaralne. Jeeli 
otrzymaetwiadomoomykowo, prosimy niezwocznie 
zawiadominadawcwysyajc odpowiedoraz trwale 
usuntwiadomowczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.


This e-mail may contain legally privileged 
information of the Bank and is intended solely 
for business use of the addressee. This e-mail 
may only be received by the addressee and may 
not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or 
the employee authorised to forward it to the 
addressee, be advised that any dissemination, 
copying, distribution or any other similar 
activity is legally prohibited and may be 
punishable. If you received this e-mail by 
mistake please advise the sender immediately by 
using the reply facility in your e-mail software 
and delete permanently this e-mail including any 
copies of it either printed or saved to hard drive.
BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, 
tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, 
www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII 
WydziaGospodarczy Krajowego Rejestru Sdowego, nr 
rejestru przedsibiorców KRS 025237, NIP: 
526-021-50-88. Wedug stanu na dzie01.01.2012 r. 
kapitazakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


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

Re: Secret Service Guide

[David Cole]

You might try www.archive.org.




At 3/16/2012 03:41 PM, Farley, Peter x23353 wrote:
I did just that in addition to searching within the IBM websites 
(but I have no access to ResourceLink).  Google finds "header pages" 
for each of these documents on the IBM websites, but all the links 
to actually download the manuals are either gone (404) or circular.


Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of David Cole
> Sent: Friday, March 16, 2012 3:20 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Secret Service Guide
>
> Have you tried just Googling the manual numbers?
>
>
> At 3/16/2012 10:45 AM, R.S. wrote:
> >W dniu 2012-03-16 14:44, Zaromil Tisler pisze:
> >>Service Guide, IBM System z10 Enterprise Class (GC28-6866-05)
> >>
> >><  http://www-01.ibm.com/support/docview.wss?uid=pub1gc28686605>
> >
> >Thank you, I appreciate it.
> >I just downloaded it.
> >
> >I also found doc number for older machines:
> >z9 EC Service Guide GC28-6841
> >z9 BC Service Guide GC28-6853
> >z990 Service Guide G229-9039
> >z900 Service Guide G229-9027
> >
> >I also found z9EC Service Guide in hardcopy (still looking for sofcopy).
> >
> >So, I'm still looking for Guides for z990, z900 and maybe older machines.
> >
> >I also revealed that the publications usually
> >were delivered on CD/DVD with the CPC.
> >
> >
> >
> >Regards
> >--
> >Radoslaw Skorupka
> >Lodz, Poland
--


This message and any attachments are intended only for the use of 
the addressee and may contain information that is privileged and 
confidential. If the reader of the message is not the intended 
recipient or an authorized representative of the intended recipient, 
you are hereby notified that any dissemination of this communication 
is strictly prohibited. If you have received this communication in 
error, please notify us immediately by e-mail and delete the message 
and any attachments from your system.


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


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


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

Re: Secret Service Guide

[David Cole]

Wow, that's pretty limited. Sorry it didn't work out.

Dave

At 3/16/2012 06:08 PM, Farley, Peter x23353 wrote:
The wayback machine only has 147 IBM pages, all from 2010, with the 
link address that appears on the "header" pages but has no similar 
IBM pages before that, and nothing at all for the four manual 
numbers that the OP listed.


But thanks for the suggestion.

Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of David Cole
> Sent: Friday, March 16, 2012 4:31 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Secret Service Guide
>
> You might try www.archive.org.
>
> At 3/16/2012 03:41 PM, Farley, Peter x23353 wrote:
> >I did just that in addition to searching within the IBM websites
> >(but I have no access to ResourceLink).  Google finds "header pages"
> >for each of these documents on the IBM websites, but all the links
> >to actually download the manuals are either gone (404) or circular.
> >
> >Peter
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> > > Behalf Of David Cole
> > > Sent: Friday, March 16, 2012 3:20 PM
> > > To: IBM-MAIN@bama.ua.edu
> > > Subject: Re: Secret Service Guide
> > >
> > > Have you tried just Googling the manual numbers?
> > >
> > >
> > > At 3/16/2012 10:45 AM, R.S. wrote:
> > > >W dniu 2012-03-16 14:44, Zaromil Tisler pisze:
> > > >>Service Guide, IBM System z10 Enterprise Class (GC28-6866-05)
> > > >>
> > > >><  http://www-01.ibm.com/support/docview.wss?uid=pub1gc28686605>
> > > >
> > > >Thank you, I appreciate it.
> > > >I just downloaded it.
> > > >
> > > >I also found doc number for older machines:
> > > >z9 EC Service Guide GC28-6841
> > > >z9 BC Service Guide GC28-6853
> > > >z990 Service Guide G229-9039
> > > >z900 Service Guide G229-9027
> > > >
> > > >I also found z9EC Service Guide in hardcopy (still looking for
> sofcopy).
> > > >
> > > >So, I'm still looking for Guides for z990, z900 and maybe older
> machines.
> > > >
> > > >I also revealed that the publications usually
> > > >were delivered on CD/DVD with the CPC.
> > > >
> > > >
> > > >
> > > >Regards
> > > >--
> > > >Radoslaw Skorupka
> > > >Lodz, Poland


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

Re: Malicious Software Protection

[David Cole]

At 3/27/2012 11:19 AM, Pinnacle wrote:
There is a mainframe product that protects against malicious 
software. It's called SAF, and it interfaces with ESM's like RACF, 
or ACF2, or TopSecret.


"SAF" is not a product. It stands for "System Access Facility" and it 
is nothing more than an interface within z/OS into which a security 
system (such as ACF2, TopSecret and any ryo security system) can plug 
into to receive and respond to security calls. It really has nothing 
to do with anti-virus protection. For more information, see 
"http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsecurity/zsecc_030.htm 
"







It [z/OS] is the only operating system out there with built-in 
anti-virus protection. On top of that, the hardware itself actively 
protects against damage through storage keys, protected memory, etc.
You have to explain to the auditors that anti-virus software is not 
needed on z/OS, because it's intrinsic to the operating system and 
the hardware.


I think you seriously misunderstand what a virus is...

Yes, z/OS has exceptional security (and integrity and reliability) 
features for protecting against non-authorized programs. But I must 
emphasize... -->NON<--authorized programs!


When it comes to AUTHORIZED programs, z/OS's integrity (which is what 
you are talking about with "storage keys" and such) is very good, but 
of course not bulletproof. Worse though, when it comes to SECURITY, 
there are some real problems! Because with the proper knowledge, it 
is TRIVIALLY EASY FOR AN AUTHORIZED PROGRAM TO SUBVERT SECURITY COMPLETELY!


This is what mainframers constantly forget regarding security. For 
authorized programs there is no security. All that is necessary for a 
malicious program to do is to Trojan-horse its way (with the AC(1) 
attribute) into an authorized library, and you're done for!


This is something I've brought up on this listserv from time to time 
before. In particular, for more information, please read a prior post 
of mine at 
"https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches 
".


And please... stop confusing security with integrity. They are not 
the same. The "hardware protections" that so many people mention are 
not security protections, they are integrity protections. They help 
to keep careless programs from accidentally breaking things. When it 
comes to authorized programs, these "hardware protections" offer no 
protection at all!







As far as I know there is no serious anti-virus program for 
mainframes. I believe strongly that there needs to be one, but I 
don't know of one. And at this stage of the mainframe culture, I 
would be seriously suspicious of the efficacy of any program that 
claimed to be anti-virus. I don't think that a serious mainframe 
anti-virus program can exist unless and until IBM itself makes a 
commitment to support an effort to make the mainframe anti-virus proof.



Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


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

Re: Malicious Software Protection

[David Cole]

I'm sorry Tom. I did not intend my remarks to be 
personal. I deeply regret that you feel hurt by 
them. Please don't let my words deter you from 
future contributions. Your thoughts generally are more valuable than most.


I just wanted to emphasize the APF Trojan horse 
vulnerability. It is real, it is serious, yet for 
decades everyone seems to want to pretend that it 
does not exist... It mystifies me.







www.zassure.com is the closest thing I've seen 
to an MVS anti-virus program.  After seeing a 
demo, I would have bought it, or recommended it 
to a client.  Check it out, you will be surprised, if not shocked.


Thank you for this. I will check it out.






[Regarding SAF] I do take issue with your last 
sentence.  SAF and an ESM have everything to do 
with anti-virus protection, provided they are 
configured to correctly protect APF-authorized resources.


Perhaps. However, all an APF authorized program 
has to do is flip a bit or two in certain RACF 
control blocks, and voilà! He's suddenly a 
supervisory program and, as such, is given a pass 
on all RACF calls... Alternatively, a malicious 
APF program can simply dynamically front-end 
certain supervisory programs, and again voilà! 
(As I'm sure you know, APF programs can fairly 
easily defeat all hardware storage protections.)


Yes, SAF is still called even for APF programs, 
but an APF program can still subvert those calls.







I've never forgotten this [APF libraries]. 
That's why my APF-authorized libraries are 
severely limited in scope, and audited for any and all updates.


Enforcing trust is a technical issue. RACF is 
very good at that. Deciding who to trust is a 
management issue. Even at shops that allow only 
trusted vendor software into APF authorized 
libraries is implicitly trusting the hundreds or 
even thousands of people involved in the development of that software.


Again, I go into more detail about this in my 
prior post: 
"<https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches>https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches 
".







Again, please accept my apology, Tom. It was not 
intended to be personal. I'm sorry it came out that way.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658






At 3/27/2012 02:21 PM, Pinnacle wrote:
Replies like this are why I seldom post to 
IBM-Main anymore.  The fact that it comes from 
someone who I respect and consider a friend 
hurts all the more.  Bottom line is that I work 
for a living, and I often don't have time to 
respond in gory detail to everything posted.  My 
primary objective here was to stress that the 
z/OS architecture is inherently hardened against 
viruses.  The fact that I did not go into 
explicit protections for APF-authorized programs 
appears to have been my fatal flaw, according to 
Mr. Cole.  Regardless of what comes back, this 
will be my last post on the subject.  My comments below.


Regards,
Tom Conley




On 3/27/2012 1:06 PM, David Cole wrote:

At 3/27/2012 11:19 AM, Pinnacle wrote:
There is a mainframe product that protects 
against malicious software. It's called SAF, 
and it interfaces with ESM's like RACF, or ACF2, or TopSecret.


"SAF" is not a product. It stands for "System 
Access Facility" and it is nothing more than an 
interface within z/OS into which a security 
system (such as ACF2, TopSecret and any ryo 
security system) can plug into to receive and 
respond to security calls. It really has 
nothing to do with anti-virus protection.


SAF is not a product, you're right.  Please 
forgive my use of the term "product", I should 
have said "feature".  I do take issue with your 
last sentence.  SAF and an ESM have everything 
to do with anti-virus protection, provided they 
are configured to correctly protect APF-authorized resources.


It [z/OS] is the only operating system out 
there with built-in anti-virus protection. On 
top of that, the hardware itself actively 
protects against damage through storage keys, protected memory, etc.
You have to explain to the auditors that 
anti-virus software is not needed on z/OS, 
because it's intrinsic to the operating system and the hardware.


I think you seriously misunderstand what a virus is...

Yes, z/OS has exceptional security (and 
integrity and reliability) features for 
protecting against non-authorized programs. But 
I must emphasize... -->NON<--authorized programs!


When it comes to AUTHORIZED programs, z/OS's 
integrity (which is what you are talking about 
with "storage k

Re: Malicious Software Protection

[David Cole]

At 3/27/2012 04:06 PM, Joel C. Ewing wrote:
The concept of allowing average-Joe user to be able to download data 
from arbitrary sources in arbitrary formats and being able from that 
to somehow introduce executable code into the system in ways that 
will execute with special privileges so as to introduce a virus or 
trojan is an issue that is endemic to Windows platforms but foreign to z/OS.


Hmmm, excellent point!

I guess part of the problem with Windows systems is that there are so 
many file types that in one way or another are executables, including 
many file type that you do not expect to be executable! Example: I 
was blown away when I learned only a few years ago that .PDFs could 
be an executable! Who knew? Not me. But the Chinese did... (It was 
interesting to see the flurry of fixes that Adobe published over the 
two years or so following the attack against Google...)


Not only are so many file types executable, they often are executed 
by default! So it is a lot easier to let something maliscious slip in 
on a Windows system than it is on a mainframe.


On mainframes files generally do not get executed by default. It 
generally takes an intentional and direct act to run a program. So 
worrying about random files upload to the mainframe is an unnecessary 
distraction.


Dave

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

The care and feeding of dongles (was: Progress Toward z/OS Personal Use License)

[David Cole]

Dongles certainly can be fragile, and longer ones, such as the 
z/PDT's (around 2 inches or so) can easily be accidentally torqued 
and broken (or break the socket, whatever).


For that reason, I keep a supply of 6" long M/F USB cables which I 
use to separate the dongle from the PC chassis. That solves both the 
bump-it-and-break-it problem as well as damage from constant 
removal-and-reinsert.


Dongles are valuable. 6" USB cables are cheap.

Just saying...
Dave Cole


At 4/25/2012 11:43 AM, Joel C. Ewing wrote:
A dongle definitely could be an issue for some.  Might be less of an 
issue on Linux, but my experiences on Windoze has been less than 
ideal and makes me regard any application that requires a dongle as 
more of a gamble.  While the dongle may be regarded as "nice license 
insurance" from the software vendors standpoint, it is essentially 
just another point of failure for the user and lowers the value of the product.


My wife has some very expensive Embroidery software that requires a 
dongle.  The license does entitle her to run the software on 
multiple platforms, both her laptop and desktop, since the dongle 
prevents concurrent use. After a year or so the dongle case became 
too loose to remove the dongle from the USB port - the only way now 
is grasp and pull the dongle base with a pair of needle-nose pliers, 
which works, but is certainly not the advertised convenience. The 
only "support" provided by the application vendor to remedy this 
situation is to re-purchase the software at full price to get a new dongle.


Other than using standard Windows GUI interfaces, this software does 
nothing that special at the Operating System level, except for the 
dongle support that requires a hardware driver written by yet a 
different vendor.  Logic would suggest that this application should 
be able to migrate from Win XP to Win 7 without a problem, provided 
one can find support for the dongle on Win 7.  My initial attempts 
to migrate have so far failed because the dongle vendor's current 
drivers for Win 7 are not compatible with the older version dongle 
that came with the application.  I haven't given up, but unless I 
can locate a compatible driver that is also compatible with Win 7 
this expensive application is toast on Win 7.  A nice result for the 
application vendor if I'm forced to do an otherwise unnecessary 
upgrade at great cost, but from the user's standpoint this is a very 
poor outcome, apparently forced by the decision to require a dongle.


--
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: Where to find out about "PER zero-address detection"?

[David Cole]

At 4/25/2012 11:19 AM, Bill Fairchild wrote:
When all else fails, try Google.  [...] Next I would suggest you 
Google and/or search IBM books for "PER-ZAD".


Bill Fairchild
Programmer
Rocket Software


ZAD = "Zombie Awareness Day" (See 
http://www.urbandictionary.com/define.php?term=zad)


[;)]

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

Re: STCBSST bit of STCBFLG1 of STCB DSECT

[David Cole]

Justin R. Bendich wrote:

 10.  Invoke XDC via its SVC HOOK.


Walt Farrell wrote:
but have you considered the possibility that step 10 takes you out 
of subspace mode until you return from the SVC?


I write:

I know it's not clear from the posts, but... XDC does not run within 
an SVC. The SVC, when reached by execution, establishes a 
caller-owned ESTAE with XDC as the exit routine. It (the SVC) then 
sets a trap (an X'00' opcode which will cause an 0C1) at the caller's 
resume address. Finally, the SVC terminates back to the caller (the 
user code) so that the trap get's immediately executed.


So the environment within which XDC runs is a simple ESTAE 
environment for the code being debugged. The SVC is long gone.


But what effect this might have on the STCBSST flag, I do not know.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

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

Re: SLIP sliding away

[David Cole]

At 10/9/2007 12:36 PM, Rick Fochtman wrote:

[snip]
But I don't believe that a user (That's a four-letter word, I know.) 
should have to ...


[snip]
I've looked at XDC, but it doesn't seem to lend itself easily to 
imbedding in an application that might very well be a "OEM Software 
Product". It appears to be a great debugging tool, but I question 
the advisability of imbedding it in a fee-based product.


Dude! Here's another four letter word: HOOK!

z/XDC allows you, at execution time, to dynamically insert a hook 
into live code that creates a debugging session on the fly! There is 
no need to modify product code (either source or object) if you don't 
want to...


Talk to Bob. Take one of his classes. He will show you how to do it...



Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

Bob Shimizu
[EMAIL PROTECTED]
800-XDC-5150

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SLIP sliding away

[David Cole]

At 10/9/2007 01:19 PM, Binyamin Dissen wrote:

I don't think that he can count on his end-users having an XDC license.

Do you provide a license where he can supply some run-time material for his
clients?


We can do that. Talk to Bob.

Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SLIP sliding away

[David Cole]

At 10/9/2007 03:06 PM, Edward Jaffe wrote:
What Dave was trying to say was that z/XDC is not linked with or 
installed with your code at all. The risks you allude to don't exist.


When you decide you want to debug a program, you can HOOK it on the 
fly (even if it hasn't been LOADed yet). The debugger dynamically 
overlays part of your program with a sequence of instructions that 
allows it to gain control and pause your program. After it gets 
control, it restores the instructions that were there to begin with. 
Then, you can step through your program instruction-by-instruction 
and, if you keep your ADATA around for the module being debugged, 
you can even use full source-level debugging (like stepping through 
an assembler source listing). You can change registers on the fly, 
change data on the fly, change instructions on the fly, take 
branches, don't take them, jump anywhere in the code ... you name it!


Well said, Ed. I couldn't have said it better myself. (In fact I 
didn't say it nearly as well.)


Thanks,

Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SLIP sliding away

[David Cole]

At 10/9/2007 02:53 PM, Ed Gould wrote:
Not speaking for Rick, but in agreement with him. As he mentioned 
the viability of putting into production a $$ tool . I have seen 
various programmers try to put various debugging tools into 
production and have seen it slip by (into production once or twice) 
don't go there. Being called (as a sysprog) at xx AM because the 
tool doesn't work or its causing production stoppage is not fun and 
it gets really nasty when it comes to politics at someone else on 
the list says BTDTGTS . IF you let the tool run loose heaven help 
you if the tool expires at xx AM and trying to get a hold of the 
vendor that does 9-5 in another time zone or even worse in on the 
other side of the pond (Atlantic or Pacific). NO THANKS and another BTDTGS.


Ed


Hi Ed,

Perhaps I've been reading things too hurriedly. Maybe I missed the 
thrust of Rick's comment.


What you are concerned about is the possibility of letting a 
distribution copy of a product get out the door with a debugging 
interface still activated. That, of course, can lead to unhappy 
situations at customer sites should the debugging interface get 
executed. I agree. That sort of thing must never be allowed to happen.


But to my mind, avoiding such a situation is very easy: Just make the 
debugging interface "fail-safe". Code it so as to require some 
additional action of environmental characteristic without which the 
interface simply does nothing, NOPs as if it did not exist. And there 
are any number of ways to do that:
One way is to code a closed permanent branch around the interface 
activation code. Then a manual zap by the developer would be 
required, without which the code could never be executed.
Another might be to require the presence of a secret keyword ddname, 
example //DEBUGME DD DUMMY. Then a simple TIOT scan would be all that 
was needed for the debugging interface to know whether it should 
allow debugging or just step aside.
Another might be to check the environment for your own computer's 
local SYSPLEX name, SMF name, CPU id/serial#, TSO userid, RACF 
ownerid, ... whatever. Absent the right value, the debugging 
interface would not permit debugging.
I really don't see that there is a serious problem here. (Or am I 
still missing the point?)




Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SLIP sliding away

[David Cole]

At 10/9/2007 03:46 PM, Ed Gould wrote:
[snip] BTW after thinking it through I would rather not have the 
dependancies name you mentioned as DR comes into play [...]


Yep. That's a good point.


The secret DDNAME does not work unless it changes say every week (or 
so) as people let the cat out of the bag without thinking...


I was thinking of "secret" from customers so that they would not 
accidently and unexpectedly be confronted with a debugging interface 
for which they would not have the background knowledge for using said 
interface.


But "secret" was too strong a word for me to use. What I really was 
talking about was a ddname that was unlikely to be used accidently by 
a customer. Nothing more than that.


If a customer wants to intentionally inflict such pain upon himself 
(debugging code for which he has no source), why would that be of 
particular concern? I just don't get why this would be a "cat" that 
had to be kept in a "bag"...




In any case, this is all beside the point. I was just giving some 
examples of how a developer might keep a customer from accidentally 
having to cope with an internal debugging interface that he should 
never have to see anyway. There are maybe thousands of other ways to 
afford this sort of protection, ranging from very simple to very 
complex. If you find shortcomings in my suggestions, well you're a 
smart person. If you wanted to, I'm sure you could find a way to both 
enjoy the benefits of an interactive debugger (such as z/XDC) and 
keep it from appearing in the wrong context.




[snip] If people (ie programmers) were really honest it would not be 
an issue but programmers have this attitude what ever I can get away 
with I will and point fingers if he can't. While I can say its not 
just programmers its a fair share as programmers are bright and they 
can/do squeeze through any loop hole that can be found ...


Wow! I'm sure glad I've never had to work with the lowlife that 
you've suffered with!




Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: In defense of z/XDC

[David Cole]

At 10/16/2007 06:54 PM, Leonard D Woren wrote:

Does this mean that you use z/XDC to debug z/XDC?  That must be fun.


Yes, of course I do. And yes, even after 29 years, it STILL is fun!

[:)]
Dave



Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Announcement: z/XDC z1.9 released

[David Cole]

Hi All,

We have posted our latest release (z1.9) of z/XDC. For more 
information, see "www.colesoft.com/pr071015.shtml".


For access to the download page, please contact Wendie Wyant at 
[EMAIL PROTECTED]


Thanks,
Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OPTABLE option of Disassembler

[David Cole]

Because sometimes opcodes change meanings? Correct me if I'm wrong, 
but it seems to me that some of the new opcodes that came out in the 
late 90s were the same as some of the old vector processor opcodes. ...


Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658





At 11/8/2007 02:43 PM, Roland Schiradin wrote:

Hi Gene,

doesn't make sense to me. If an instruction exists in the code the 
disassemble

should decode them based on the latest level of possible opcodes. Why would
you limit this?

Rolan


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

T3 Sues IBM To Break its Mainframe Monopoly

[David Cole]

As Ralph Johnson noted in his post to the FLEX-ES listserv, "Interesting!"

http://www.sys-con.com/read/468626.htm

IBM's intransigence in its so called "negotiations" with FSI, its 
belligerence with PSI, its bullying of T3 and its total shunning of 
Hercules has created a substantial threat to my business and the 
business of a hundred or two other small mainframe developers.


I no longer believe that IBM is acting in the long term interest of 
the z/OS industry. Or more accurately, I believe that IBM's focus on 
z/OS has changed from growth to consolidation, and that they see 
themselves less as a hardware/software company and more as services 
company. Their actions with respect to the z/OS world are utterly 
anti-competitive and in total disregard of what is needed to nurture 
the long term health of this portion of their business.


I have options. I will survive this threat. But as the z/OS options 
continue to narrow, many other small developers will either fail or 
shift their energies to more open arenas.


This is a sad time for the mainframe business.


Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: T3 Sues IBM To Break its Mainframe Monopoly

[David Cole]

At 12/1/2007 11:34 AM, David Day wrote:
Yes, there actions are anti-competitive.  But, isn't that part of 
being in business.  You do what you can to help yourself,


Certainly true. And when companies succeed too much in this strategy 
they become monopolistic, then the pressures to reduce price and to 
innovate decline, and so the capitalistic self-interest begins to 
diverge from the common good. This (in theory at least) is why we 
have democratic government, so that in can, in representing the 
common good, promulgate regulation to curb monopolistic self-interest 
to the extent that it conflicts with the broader community interest. 
[blah blah blah].


It doesn't seem to be working too well in recent years, though...



Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: T3 Sues IBM To Break its Mainframe Monopoly

[David Cole]

At 12/3/2007 05:04 PM, Dave Kopischke wrote:
With all due respect, I don't believe IBM has an obligation to you 
or any of us to act responsibly nor fairly in this matter. This is 
IBM's property and they are entitled to sell it or allow access to 
it or give it away in any way they see fit. And that includes 
protecting it in any manner and with whatever ferocity they feel appropriate.


WADR (BTW, I hate that phrase...) WADR: I don't believe I said 
anything at all about IBM "having an obligation...". Of course they 
don't. I was only describing the current circumstances as I see them.


But even though I understand that IBM does not have an "obligation", 
I don't therefore believe that we, who are adversely affected by this 
non-obligation, should simply stand silently by and let this 
deterioration of our community just happen.


Like most of what happens in this world, this is just a struggle 
between competing interests, and IBM is just one player in this 
struggle. Unfortunately, the struggle is somewhat out of balance. 
Especially if we just stand by and let it happen. Also unfortunately, 
in this struggle the major power is too short-term goal bound to see 
the long range benefits of broadening this community instead of 
strangling it. (And other large powers are too complacent to help out.)


Still, those of us who are directly affected have options for 
influencing IBM's decision process:
The law is one such. That's what PSI and T3 are trying to use by 
going to the courts.


Negotiation is another such tool. FSI was trying to follow that path, 
but it doesn't look like it's working so well. (I wouldn't be 
surprised if we saw FSI filing suit in the near future as well.)


Collective action is another such path. The PWDFLEXES group 
(tech.groups.yahoo.com/group/pwdflexes) is trying to take action 
along those lines.


"Interesting times" ...


Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658




At 12/3/2007 05:04 PM, Dave Kopischke wrote:

On Sat, 1 Dec 2007 05:43:41 -0500, David Cole wrote:

As Ralph Johnson noted in his post to the FLEX-ES listserv, "Interesting!"

http://www.sys-con.com/read/468626.htm

IBM's intransigence in its so called "negotiations" with FSI, its 
belligerence with PSI, its bullying of T3 and its total shunning 
of >Hercules has created a substantial threat to my business and 
the business of a hundred or two other small mainframe developers.


I no longer believe that IBM is acting in the long term interest of 
the z/OS industry. Or more accurately, I believe that IBM's focus 
on z/OS has changed from growth to consolidation, and that they see 
themselves less as a hardware/software company and more as services 
company. Their actions with respect to the z/OS world are utterly 
anti-competitive and in total disregard of what is needed to 
nurture the long term health of this portion of their business.



With all due respect, I don't believe IBM has an obligation to you 
or any of us
to act responsibly nor fairly in this matter. This is IBM's property 
and they are
entitled to sell it or allow access to it or give it away in any way 
they see fit.

And that includes protecting it in any manner and with whatever ferocity they
feel appropriate.

But I also whole-heartedly agree with your sentiment as it relates 
to the good

of our industry and our profession. Protectionist policies rarely stimulate
growth. I think many on this list have complained about this for years.

I think there's a better and more profitable business model to embrace. One
that stimulates growth, encourages education in the platform, and allows for
long-term growth and stability. That would include a no- or low-cost personal-
use version that can be used for educational purposes. Low-cost entry-level
hardware such as that offered by PSI. And special consideration for
independent developers and their products.

It would be interesting to pose this kind of option to a vote of IBM's
shareholders. Protectionist anti-growth business model or a business model
that embraces the future. I can't agree that IBM is obliged to do any of this
though. If IBM feels it is in their best interest to stifle growth 
in z/OS and

embrace policies that ensure extinction, that is their right.

If you elect me president, CEO and chairman of IBM, I promise things would be
different.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Open Source Security Risks (was T3 Sues IBM To Break its Mainframe Monopoly)

[David Cole]

I think you have the open source security risks backwards, Herbie.

One of the features of open source is that the source code is public. 
This means that ANYONE can read it, study it, find bugs in it, AND 
find trap doors in it! And "anyone" means anyone in the whole world!


Thus, the risk of malicious code being discovered and publicized is 
far greater for open source code than it is for OCO code.


From a security point of view, I'd much rather have open source code 
than OCO code any day.


Dave Cole


At 12/5/2007 07:16 AM, Van Dalsen, Herbie wrote:
In my opinion, what makes IBM code safe in terms Auditing risk, is 
the fact that only IBM labs work on it. You need a really P'd-off 
IBMer to plant a Trojan in the code, and a few P'd-off testers to 
miss it during testing. So I would not be in favor of open source 
for the mainframe. I think too many companies depend on the current 
quality level of the software. What I would be in favor of is a 
platform where developers outside of IBM can present new software 
designs/ideas to be included after proper securitization.


Regards

Herbie


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

New SCHEDRUN posted

[David Cole]

It always surprises me how persistently interest still runs in this 
nearly 30-year old program of mine. But a couple of times a year, 
someone I never heard of before emails me with a question or two.


Anyway, I've just posted an updated release (2.8) at 
"www.colesoft.com/utilities.shtml", so if you want a dead-simple 
job/commands scheduling system, check it out.


Best of all, it's still free.

[:)]

Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Finding the last IPL time

[David Cole]

Hi All,

Is there a way (an API or a cblock field) by which a program an find 
out the local time of the last IPL?


Thanks,

Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Finding the last IPL time

[David Cole]

Thanks Rob, That's EXACTLY what I was looking for.

Dave Cole



At 6/25/2007 02:51 PM, you wrote:

SMCAITME and SMCAIDTE in the SMCA (IEESMCA is the mapping macro - SYS1.MACLIB)

SMCA pointed to by CVTSMCA


Rob Scott
Rocket Software, Inc
275 Grove Street
Newton, MA 02466
617-614-2305
[EMAIL PROTECTED]
http://www.rs.com/portfolio/mxi_g2


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Finding the last IPL time (Why I wanted to know)

[David Cole]

Thanks for the additional info, Mark.

What I was specifically looking for was the local time of the IPL, so 
the SMCA fields seem to be the ticket.


I have discovered that the CVTTZ field (for converting from UTC time 
to local time) is not reliable. We run a FLEX-ES system on a laptop 
here. The system suffers from MAJOR clock drift. The TOD clock will 
drift out of true by a couple of DAYS per week! So for 
auto-scheduling purposes, I periodically need to issue a SET 
DATE/CLOCK command to correct the local time. Since doing that, I've 
discovered that the CVTTZ field does get updated, but not by a large 
enough value. (I'm guessing that it gets updated by the clock change 
but not by the date change.)


Anyway, I also discovered that my SCHEDRUN program's clock knowledge 
was getting screwed up. When I looked at the code, I found that it 
was basing all of its date arithmetic upon TOD clock values adjusted 
by the CVTTZ value. Well, because the CVTTZ was not coping with the 
massive SET DATE/CLOCK change commands, the resulting scheduling was wrong two.


So I've been recoding SCHEDRUN's clock knowledge to use local time 
(TIME BIN,ZONE=LT) as well as the System routines for time/date 
conversions (STCKCONV and CONVTOD). One of the things that SCHEDRUN 
needs to know is the local time of the last IPL, hence my initial query.


Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658



At 6/25/2007 03:36 PM, you wrote:

As mentioned, my IPLINFO exec displays it - using those fields from the
SMCA.  They have been there *a long time*.

But there is also a field in the IPA -  IPAICTOD - defined as when
system initialization ended.  It is slightly before the time in the SMCA and
is GMT, not local.   IPAICTOD also matches what you see when you use the
"D IPLINFO" operator command.

Another place it is, that I have seen defined as "when initialization
began", is the SHID_TODCL field in the SHID.  It is also in GMT.

Regards,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group:  G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Finding the last IPL time (Why I wanted to know)

[David Cole]

Wished I'd know about that before.

But then I've also converted to using IBM supported interfaces 
(CONVTOD and STCKCONV routines), so it's all good.


Thanks, Rob.
Dave


At 6/26/2007 08:02 AM, you wrote:

Dave,

Try using CVTLDTO instead of CVTTZ.


Rob Scott
Rocket Software, Inc
275 Grove Street
Newton, MA 02466
617-614-2305
[EMAIL PROTECTED]
http://www.rs.com/portfolio/mxi_g2


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is there any way that i can practice mainframe related subject without having access to one?

[David Cole]

At 8/1/2007 09:10 AM, you wrote:

Thanks for this, Don.  I've been looking at it.  Very nice.

How difficult would it be to create a full screen XDC / Xpediter 
like debugger?


Lindy


Not very easy. [;)]


Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: C++ Workable Mainframe Debuggers

[David Cole]

Cole Software's z/XDC - no


We are on the verge of publishing C Source code support ("c/XDC") to 
beta testers.


More soon.
Dave Cole


At 4/13/2008 05:53 AM, you wrote:

If you're debugging C/C++ on z/OS:

1. There's dbx for UNIX System Services (only):

http://www.ibm.com/servers/eserver/zseries/zos/unix/bpxa1dbx.html

No charge.

2. IBM Debug Tool for z/OS is available. IBM has introduced a new version
annually for years now, so you want to stay current and take a fresh look
if you remember an old version. Version 7, in particular, introduced some
substantial C++ related improvements. Version 8 is current. I see a lot of
old Debug Tool installed out there, unfortunately.

You can license Debug Tool as MLC or, in the form of the Debug Tool
Utilities & Advanced Functions superset product, as OTC with subscription.
As you prefer.

Unfortunately for z/OS 1.5 you'll be limited to Debug Tool (or DTU&AF)
Version 7, so please try to get your z/OS release updated as soon as you
can, at least for the development LPAR(s) where you're most likely to be
debugging. You may be able to work with IBM to order DT or DTU&AF Version 8
and arrange temporary use of Version 7; can't hurt to ask. Actually, as I
write this Debug Tool V7 MLC is still orderable so no harm there, but for
reasons of subscription you'll want to order DTU&AF V8 if you go the OTC
route.

For graphical debugging use Rational Developer for System z (or WebSphere
Developer Debugger for System z) in conjunction with Debug Tool (or
DTU&AF). I think those tools also provide graphical debugging with dbx now.
Very slick.

A certain popular IBM-MAIN training firm has a course on C/C++ debugging.
Details here:

http://www.trainersfriend.com/C_courses/N735descr.htm

3. There are a number of commercial debugger products for z/OS, most
already mentioned. However, many (all?) of them don't support C++. Here's
the latest information I have, and someone please correct me if my
information is out of date:

Cole Software's z/XDC - no
CA-InterTest - no
Compuware's Xpediter - C yes, C++ ?
Gary Bergman Associates' Advanced Debugging System (ADS) for CICS - C yes,
C++ ?
Macro4's Tracemaster - no
MacKinney Systems' Track and Xray - no
ASG's (formerly Viasoft's) SmartTest - no
Serena's StarTool ATD - product withdrawn?

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FW: Workable Mainframe Debuggers

[David Cole]

At 4/14/2008 04:57 PM, Tom Ross wrote:

By the way, I think IBM has the only debugger for IBM C and C++ on z/OS.


Not for much longer.





Cheers,
TomR  >> COBOL is the Language of the Future! <<


Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

Coming soon: c/XDC for C and C++

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: A Refreshing Change (Was: switch from CA-SYSVIEW to SDSF)

[David Cole]

At 4/24/2008 03:08 AM, Edward Jaffe wrote:
I realize it's a fine line ISVs tread within an open technical 
discussion. I try not to cross it (don't know if I'm always 
successful) as did the late Bruce Black, and as do Chris Craddock, 
Wayne Driscoll, Rob Scott, Bob Shannon, Tom Harper, Scott Fagen, 
Steve Pryor, Martin Treubner, Dave Cole, Tom Marchant, and other ISV 
regulars on this list. And, while their software might indeed be 
considered "world class" by their customers, I've never heard any of 
them describe it that way on IBM-MAIN!


z/XDC is a SUPERIOR WORLD CLASS(!) Assembler Debugging Tool!

[sorry, i just couldn't resist]

Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html