Re: CeBIT and mainframes

[Tony Harminc]

On 19 March 2016 at 10:29, Mick Graley  wrote:

> Nah, not letting him off that easily!
> The word "coded" is the same in both languages, and BCD ¬= BSD.
> Like us Brits tend to say "kicks" and the Americans tend to say "see,
> eye, see, ess" but it's still actually CICS :-)
>

Often enough in the US "kicks" is "see, ah, see, ess"... What the linguists
might call "monophthongal I".

Tony H.

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

Re: Why sort (was Microprocessor Optimization Primer)

[Tony Harminc]

On 3 April 2016 at 02:50, Andrew Rowley  wrote:
> One question that puzzles me (maybe it's my lack of an application
> programming background): Why is sort used so much on z/OS?

As others have pointed out, sort on z/OS (whether IBM's or other
vendors') can be used for all sorts (heh) of general I/O with high
performance. But "sort" also covers the notion of merge, and more
generally of collation. Many languages have constructs that implicitly
sort, and all relational (and probably other) databases will sort
implicitly as required, whether they implement their own sorts, or
call the system one. The database product I worked on 20 years ago had
three levels of sort: for a few rows it did its own in-storage sort,
for thousands of rows it did it's own with work files, and for bigger
stuff it called the system sort. Today those thresholds would be x10
at least because of much cheaper and bigger main storage, but the
concept holds.

A historical reason for use of sort on z/OS may be that "way back in
the days of steam powered computing", main storage was very expensive,
disk was expensive, and tape was cheap. It was not unusual for sort to
use tapes for work files; how else would you sort tens of millions of
records on a machine with, say, 512 kB of storage and a few hundred
megabytes of disk?

UNIX and indeed most other systems didn't start out doing commercial
data processing, and to this day don't do batch processing very well.

Tony H.

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

Re: New to RACF

[Tony Harminc]

On 21 April 2016 at 12:01, Tracy Adams  wrote:
> seteuid 0
> Error codes: 0 -1 A4 B7F1C00
> EMVSSAF2ERR: SAF/RACF error
>
> Dubious nothing has changed in the RACF world and this use to work.  The only 
> thing I can find is that the userid needs acc(read) to bpx.superuser which it 
> does.  Where do I begin to debug this RACF error?

Are you sure the line with the error codes was copied accurately? I
would expect the last piece to have 8 hex digits; it's the errno2
value. The A4 (EMVSSAF2ERR) is saying it's a RACF error encountered by
the UNIX seteuid() service. The last two bytes (4 digits) of that 8
character hex string should be the RACF return and reason codes from
the RACF IRRSEU00 callable service, described in the RACF Callable
Services book.

If it's really coming out as 7 digits, then I'd call IBM and complain.
If it got mangled or typo'd, then look up the corrected version in the
Callable Services book and see if that leads you further. All this
seems to have to do with authorization to change the effective UID.

Tony H.

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

Re: got to have it! device (pen shaped) with 32 GiB flash, flashlight, stylus, & ball point pen.

[Tony Harminc]

On 22 April 2016 at 10:02, Nims,Alva John (Al)  wrote:
> Second, the USB drive built into a pen is not so new, PNY had created one and 
> I think it had only about 2gb or smaller.  You took the cap off to get to it. 
>  I had one, but many, many years ago.

I have a USB-drive-in-a-pen that IBM gave away for answering some
survey over ten years ago. Only 128 MB, iirc. But the pen does write.

Tony H.

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

Re: An explanation for branch performance?

[Tony Harminc]

On 29 April 2016 at 11:50, Charles Mills  wrote:
> What about substituting a branch relative for the branch on base register? 
> Trivial code change to make.

I was about to suggest that too. All the IBM published material I've
seen on this suggests that

-- all else being equal  (heh), untaken branches are faster than taken
ones (even if the prediction is correct),
and
-- the penalty for misprediction is lower for relative branches than
register-based ones.

Tony H.

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

Re: An explanation for branch performance?

[Tony Harminc]

On 29 April 2016 at 12:06, David Crayford <dcrayf...@gmail.com> wrote:
> On 29/04/2016 11:55 PM, Tony Harminc wrote:
>>
>> On 29 April 2016 at 11:50, Charles Mills <charl...@mcn.org> wrote:
>>>
>>> What about substituting a branch relative for the branch on base
>>> register? Trivial code change to make.
>>
>> I was about to suggest that too. All the IBM published material I've
>> seen on this suggests that
>
>
> It was a simple test case to exercise our legacy code base which issue
> non-relative unconditional branches over eye-catchers. It's non-trivial to
> change and test a huge code base  and certainly you wouldn't want to without
> understanding the problem.  But there's certainly an issue as our customers
> have reported.

You quoted me, but snipped out everything I actually said... Which I
think does partly address your question.

Tony H.

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

Re: An explanation for branch performance?

[Tony Harminc]

On 29 April 2016 at 12:59, Jim Mulder  wrote:
>   The relevant comparison is not conditional branch vs.
> unconditional branch.  It is branch not taken vs. branch taken.
> Sequential execution is always best.  Branch prediction tries to
> mitigate some of the effects of nonsequential execution.

Right. And presumably even an "unconditional" branch that is actually
a branch on condition with a CC mask of 15 can be mispredicted, in
theory. And therefore the instruction fetch stream at the address
following the branch will keep on fetching, even though it fully
expects to switch to the new stream at the branch target address. And
then that first stream will have to be thrown away, which presumably
isn't free.

In the tiny example case, the stream after the branch is not only a
valid instruction (which it might or might not be in the case of
branching over an eyecatcher), but it's another branch, which
presumably gets predicted in its own right, even though it's at the
same address as the first branch's target.

Now what about a truly unconditional branch, i.e. one that doesn't
depend on the condition code? Would BRAS perform better in this regard
than even J, or is the cost of saving stuff in r1 very high? Surely
there is no reason to continue fetching after such an instruction. It
can't not branch, and it can't program check.

Tony H.

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

Re: Following IBM-MAIN on iOS (or Android, for that matter)

[Tony Harminc]

On 29 April 2016 at 02:23, Martin Packer  wrote:
> Other than using an email client on iOS has anyone found a good way of
> participating in LISTSERV groups on iOS?
>
> To keep this interesting for about half of y'all, same question for Android.

I don't use Apple products so can't comment, but I find little trouble
using the Gmail client on Android to read LISTSERV lists. Replying to
postings is more problematic; quoting nicely is less than easy, and
avoiding top-posting almost impossible. But I often enough read lists
on the way to work, and mark things for reply when I get to my desk.

Why do you find an email client inadequate for this?

Tony H.

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

Re: New to RACF

[Tony Harminc]

On Apr 21, 2016 9:33 PM, "Anthony Thompson" 
wrote:
>
> The error reason is actually 0B7F1C00, it's the C/C++ library functions
being called from within copytree command (like printf, fprint, etc) that
drop leading zeroes. I've seen it many times in error messages from z/UNIX
commands . It is fixable in C/C++ code, but the programmer needs to count
the number of digits to be output...

So X'1C'  = 28 = SAF RC = revoked.

Seriously, the failure to display the proper reason code should be APARed.

Tony H.

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

Re: What was a 3314? (was: Whither VIO)

[Tony Harminc]

On 19 May 2016 at 16:56, Martin Packer  wrote:
> The whole disk is NOT in your virtual storage; The track window IS (IIRC).

Well I wasn't thinking *your* (the caller's) virtual storage;
obviously it can't all be there. I was thinking there would be a VSM
mapping of the whole device in *some* virtual space, but clearly this
wouldn't have worked with 24-bit addressing. So I guess my mental
model for this is wrong; presumably VIO is a driver of ASM at the same
level as VSM is. And there must be a track (or some larger or smaller
page-multiple) buffer that forms the interface to ASM.

Well I guess going and looking at the code would be best; MVS 3.8 is
still out there for the reading.

Tony H.

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

Re: What was a 3314? (was: Whither VIO)

[Tony Harminc]

On 19 May 2016 at 01:44, Martin Packer  wrote:
> It's sort of come back to me:
>
> A small track size limits the virtual storage window (probably usually
> below the line in 1989 when I looked at this). Or it might've been
> cylinder. But I think it was track.
>
> I'm wondering if anyone else remembers something like this.

I'm not sure I get the "virtual storage window" idea. VIO emulates an
entire disk drive in virtual storage. So where is there a window? The
whole disk has to be in virtual storage at once. Well, I suppose there
could be logic to not allocate Virtual until used, but that would
surely better be left to VSM's and RSM's expertise at managaing their
respective kinds of storage.

Now maybe VIO was changed much later (surely there wasn't expanded
storage in 1989...?) to use or perhaps favour expanded storage, in
which case a window model could make some sense. But only if VIO was
directly dealing with expanded storage rather than just requesting
that RSM use it to back virtual storage used to hold the VIO disk
data.

Tony H.

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

Re: Whither VIO?

[Tony Harminc]

On 11 May 2016 at 12:05, Jesse 1 Robinson  wrote:
> One question I have. In a previous life, we defined VIO (I believe) to device 
> 3314 even though we had none left on the floor. The device type was still 
> valid in IOGEN at that time, and I was told that device architecture was more 
> suitable for VIO than 3380. VIO here is currently defined to 3390. Is there 
> any difference?

I'm not sure about the device architecture, but the traditional reason
for choosing a particular and perhaps obsolete device type for VIO was
to limit the space available. This was before SMS or any other
controls, and if you set up 3350 or 3380 as VIO device types, an
application could easily allocate and try to fill up the entire
virtual disk, with potentially disastrous results for the paging
system. One trick was to specify the VIO device as 2305 (the old
fixed-head disk, sometimes incorrectly called a "drum"), which was
very small - 5 or 10 MB, depending on the model. The 2314 was next on
the list - much bigger, but still only 30 MB or so. The 2311 or 2301
might have been an even better bet, but neither was ever supported on
MVS.

It may be that the "device architecture" is referring to the number of
4K pages needed to hold a track image for the device in question, with
how much wastage. It's kind of the opposite calculation to what makes
a good paging device, i.e. how many pages fit on a track with how much
left over.

Tony H.

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

Re: Whither VIO?

[Tony Harminc]

On 11 May 2016 at 10:07, Martin Packer  wrote:
> The nasty answer to "what happened to VIO?" is "nothing". :-) :-(
>
> Seriously, it remains as before but implemented in central storage rather
> than expanded.

VIO long predates the existence of expanded storage. It was original
with MVS (2.0 in iirc 1972), and at the time there was nowhere for it
to go but the paging system. Expanded storage is one of those things
that, for a combination of technical and marketing reasons, had its
day in the sun and has gone, while VIO continues.

The biggest reason to use VIO rather than the various alternatives
mentioned is that it is compatible. An existing application need know
nothing about it, and can be offered improved performance with no code
changes. In these days of large memory it may seem quaint, but it has
its place.

Tony H.

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

Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

[Tony Harminc]

On 16 May 2016 at 15:47, Jerry Whitteridge
 wrote:
> I'd reply to the Auditor "Please define Admin access as there is no one 
> privilege  that grants all access"

But there are several -- perhaps many -- privileges that grant access
to grant all access. For instance, anyone with READ access to
BPX.FILEATTR.APF in the FACILITY class can own your entire system.

Tony H.

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

Re: How well does z/OS handle large, but sparse, memory objects?

[Tony Harminc]

On 16 May 2016 at 11:29, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> In circumvention, AIX introduced a nonstandard signal, SIGDANGER,
> thrown when backing storage was (FSVO) nearly exhausted.

OT, but are signals "thrown"? I know that in C++ and Java, exceptions
are objects and are "thrown" (and perhaps "caught"), where in PL/I and
some other languages they are states and are "raised". But signals...?
[Just to compund things, PL/I (and REXX) has a SIGNAL verb that raises
an exception.]

Tony H.

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

Re: How to copy one pack IPL'able z/OS to DVD.

[Tony Harminc]

On 13 May 2016 at 19:19, R.S.  wrote:
> It's absurd. Completely ridiculous.
> Pendrive from IBM is not likely to have a virus.

True. But it's related to the argument that airline pilots should not
be security screened at airports. Of course it's not about screening
pilots, but rather those who *look like* pilots.

If you buy in quantity, I'm sure these people will put a logo of your
choice on your "pen drive":

http://hakshop.myshopify.com/products/usb-rubber-ducky-deluxe

Or probably the clip is a standard size, and an IBM one can easily be
substituted for the duck one.

Tony H.

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

Re: was I in a coma when this was discussed: z/OS FBA Services

[Tony Harminc]

On 20 April 2016 at 12:16, John McKown  wrote:
> Apparently for the DS8700 and above with an option called zDDB.
>
> http://www.ibm.com/support/knowledgecenter/api/content/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa800/fbaasm.htm?locale=en

FBA on z/OS? Well I don't know if you were in a coma at the time, but
you did comment on it in Sept 2013 when it was first discussed here...

Tony H.

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

Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Tony Harminc]

On 22 July 2016 at 11:14, Peter Hunkeler  wrote:
> I got a CEEDUMP and an analysis from StartTool DA. Both tell me the failing 
> PSW is 478D0400 A31A7BB8
> Looking at the SVC dump at the PRB/XSB which is now producing the SVC dump 
> (WLIC is 00020033), I see:
> XSB+00E0  PSW16 47850400  8000    231A7BB8

Just curious that the PER bit is on. Was someone running a SLIP of a
PERish sort? Any chance of a dump or trace from that, or is the toy
dump all you have to work with?

Tony H.

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

Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes

[Tony Harminc]

On 22 July 2016 at 14:32, Ed Jaffe  wrote:
>> Just curious that the PER bit is on. Was someone running a SLIP of a
>> PERish sort?
>
> These days the PER bit is *always* on, in any serious development/test
> environment, because of the ever-present ZAD SLIP in effect.

Sure - I'm used to seeing the bit on on my own systems. But I
understood -- perhaps incorrectly -- that this dump came from a
customer environment, and that that at least partly explains the
difficulty in getting a "real" SVC/SLIP dump. Presumably a production
environment is far less likely to have any kind of PER running.
Certainly we rarely see it on in customer dumps unless it's from a
SLIP we've asked them to set.

Tony H.

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

Re: C/C++ maximum number of arguments on a function prototype

[Tony Harminc]

On 12 August 2016 at 13:20, Charles Mills  wrote:
> Holy moly! 303 parameters? Can someone actually keep track of what they are 
> coding? Is this a best programming practice?

One hopes that such a thing is program-generated, and not coded by
some hard working programmer.

"Computers should work; people should think."

Tony H.

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

Re: Interface to query length of storage allocated with CEEGTST LE service

[Tony Harminc]

On 20 July 2016 at 16:14, Peter Hunkeler  wrote:
> When using LE service CEEGTST to allocate a piece of heap storage, the length 
> is provided by the caller of the service and the address of the storage is 
> returned by the service. To free that storage CEEFRST is called. Only the 
> addressof the area, as returned by CEEGTST, has to be passed to the service. 
> LE remembers the length of the area.
>
> Is there an interface or any other documented way to get the length of an 
> area at a given address?

I very much doubt it. I don't see anything in the LE Vendor Interfaces
book. But in any case, would you expect to always see the same length
as what you originally asked for? I believe in all languages supported
by LE and having the notion of "heap", there is nothing to say the
amount allocated cannot exceed the amount asked for. I imagine this is
exactly what will happen; the amount will be rounded up to the nearest
cell size both to avoid fragmentation and to avoid having to keep two
lengths around.

I'm curious; what will you do with this info if it is available?

Tony H.

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

Re: AW: Re: IBM Knowledge Centre

[Tony Harminc]

On 7 July 2016 at 11:01, Sue Shumway  wrote:
> Just out of curiosity, if ePubs of z/OS books provided all the same 
> functionalities as PDFs (same technical content, same methods for 
> obtaining/saving, etc.), plus had added benefits such as visual scaling and 
> accessibility, would you still be so adamant about keeping PDFs?

It seems to me that the great claim-to-fame of PDFs is "print
fidelity", i.e. if you print or display a PDF document it looks
exactly the same as what the author intended, and is the same for
everyone on every device. Well everyone has seen this fail to some
extent, but still, it is a fundamental goal of the format. So fonts,
column spacing, page breaks, and of course colours on suitable devices
are *the same*, subject only to scaling and maybe font substitution if
necessary.

Other presentation formats have quite different goals. In particular,
HTML and friends are geared more to matching the content suitably to
the available presentation device, and I gather the ereader formats
are similar in this respect. For example exact pagination is not
maintained when you read a book on a Kindle; the text flow is more
important when you are reading a novel. Perhaps the author can enforce
some degree of fidelity, but I don't think it's a fundamental feature.

I'm not sure how important these goals are when talking of IBM pubs.
In the old .BOO format, tables often lost their alignment, and so for
example the descriptions of RACF return codes which have three levels
were often very hard to interpret in .BOO books, but always correct
(at least as correct as the author made them) in PDFs. Clearly reading
a print-fidelity document on a very small screen requiring much
windowing is no fun. But the layout does have to be maintained in
order to keep the technical results clear; these are for the most part
not novels or general text.

May I suggest you look at the RACF manual I mentioned above? It's
"SA23-2294-01 z/OS Security Server RACROUTE Macro Reference Version 2
Release 1". Drill down to "Chapter 3 System macros", then "RACROUTE
REQUEST=VERIFY (standard form)", and then "Return codes and reason
codes". The PDF version is "correct". See if/how you can get the
return and reason codes with their text descriptions to be readable on
several devices with various screen sizes.

Thanks,

Tony H.

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

Re: IPCS error help

[Tony Harminc]

[Yes, I realize I'm replying to an old posting]

On 11 February 2015 at 09:28, Nick Jones  wrote:

> We saw this internally recently--
> I believe this specific 878-10 is due to the installation of a ++APAR for 
> OA43495 which I think is for new hardware toleration.  Either some versions 
> of the ++APAR don't have part IOSVFMTC included which has updates to IOS 
> formatters that are called as part of IP STATUS, or IOSVFMTC wasn't applied 
> to the miglib that IPCS brings up.
>
> see canceled apar OA45781: ABEND878-10 on IPCS ANALYZE or IPCS IOSK, due to 
> zero ULUT pointer in an analyzed dump
>
> This should be corrected by making sure your miglib has the updated IOSVFMTC 
> in it, or making sure you are on the latest ++APAR build.
> --
> Nick Jones
> z/OS Service Aids

I've bumped into this a couple of times recently. I'd like to fix it,
but it's not obvious to me what needs to be done. We look at dumps
from all sorts of z/OS levels, so on our main Support image (currently
running z/OS 2.2) we have a list of MIGLIBs and a little bit of REXX
to present a menu and set IPCS up for the appropriate dump. Just now
I'm looking at a customer dump from z/OS  2.1, and getting the bogus
GETMAIN for X'7FFF4000' bytes. Do I understand correctly that the
problem lies in the 2.1 MIGLIB I'm using on this z/OS 2.2 system? If
so, how can I get a suitable 2.1 MIGLIB to copy to this image - in
other words how can I ensure that the fix is applied? Do I need to
make sure OA43495 (or its 2.1 PTF) is applied on a 2.1 system, and
only then recopy MIGLIB? Or is there a way I can apply the maintenance
directly to the 2.1 MIGLIB on the 2.2 system? Clearly the copy used
just for IPCS doesn't need to be formally maintained, though it would
doubtless be a good idea.

Or... Have I misunderstood: Is the problem not with the 2.1 MIGLIB at
all? Is there perhaps maintenance needed to z/OS 2.2 IPCS itself?

Also FWIW, APAR OA45781 is not known to any IBM service I have access to.

Thanks for any pointers!

Tony H.

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

Re: IBM Knowledge Centre

[Tony Harminc]

On 3 July 2016 at 18:35, Charles Mills  wrote:
> I can understand the move away from BookManager (as much as some of us loved 
> it). It was a proprietary
> technology and I am sure expensive to maintain.

I bet if IBM open-sourced Book Manager, or at least the ,BOO data
formats, it would get a lot better. Surely they aren't still making
money by selling that technology?

> But PDF is an industry standard. The technology is maintained by Adobe.

The problem I have is that IBM seems to be in bed with Adobe, and
depends on their specific implementation of PDF viewing capability.
Sort of like companies used to require Internet Explorer for their web
pages. I don't use the Adobe reader (I find it is ever more slow,
bloated, and bug-riddled), but some of the light weight and much
faster readers don't work with the IBM Adobe-proprietary index scheme.
I have asked IBM to not require Adobe's reader, and they don't seem
interested.

Tony H.

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

Re: Help identifying source of SMF 80 record

[Tony Harminc]

On 5 July 2016 at 11:43, Charles Mills  wrote:
> I am looking at an SMF 80 record from a customer that I am having trouble
> making sense of. The customer is definitely a RACF user, not a TSS user. The
> customer I believe is on z/OS V2R1.
>
> It is a valid SMF 80 record. The event.qualifier is 2.0. There are three
> relocatable sections: a 49 (User Name) that says "Detection Status", a 17
> (Class name) that says "EK$CLASS" and a 1 (Resource Name) that says
> "EKCA.SECURITY.DETECTION". The record is 2959 bytes long, long for a RACF
> SMF record.
>
> So what's odd about it?
>
> 1. It is missing the RACF version SMF80VRM at offset 80 that was added to
> RACF around OS/390 V1R2. That leads me to believe the record was not
> produced by RACF.

Yup. We've encountered a handful of ISV products over the years that
write "RACF" SMF records on their own initiative. None of them is
fully "correct", either in that the record itself would never be
written by RACF, or that it wouldn't be written in the context it is.

> Does anyone have an idea what might be producing this record and where its
> format might be documented?

>From the names I'd guess it to be an EKC product. I'm not aware if
they have product(s) that work with RACF rather than ACF2 (I
understand the company was founded by one of the ACF2 initial
developers), but it seems likely.

http://www.ekcinc.com

Tony H.

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

Re: Multithreaded output to stderr and stdout

[Tony Harminc]

On 29 June 2016 at 14:00, John McKown  wrote:

> I may be blowing smoke here, if so I'm sure someone will point it out :-}.

I think you're on the right (write...?) track.

[...]
>  A DD pointing to a sequential data set is _not_ designed to be
> written to by two different DCBs concurrently. What I do in this case is
> write to a UNIX file. Why? Because it works more like a JES2 sysout, which
> is subject of the next paragraph.
>
> Now, with JES2 (or UNIX output), what happens? Well, it's more like a data
> base. You still have two DCBs, but the actual write sends the data to JES2
> and tells it to place it in the SPOOL file. So JES2 is accepting and
> interleaving the data for you. As JR said, this is like what would happen
> on a line printer.

I don't think this part is quite accurate... JES2 doesn't work like
HASP of old, where SYSOUT data was written to a virtual line printer,
line at a time.

> It would accept and print each line as it is generated
> and so would interleave the lines. This is also what happens with UNIX
> files. The data is not sent to the disk, but to the UNIX kernel which
> places it in a buffer and eventually writes it out. The UNIX kernel, like
> JES2, is maintaining a "unified buffer" architecture behind the scenes.

Well... When you use QSAM on a JES2 SYSOUT dataset, most of the
buffering is done locally in a so-called unprotected buffer. Only when
that buffer is filled does the access method PUT routine issue SVC 111
(or a more modern PC, iirc?) to copy the buffer to one owned by JES2,
which is eventaully written to disk. Those disk writes of blocks would
be centrally serialized, so that there would be no possibility of
overlaying already-written data. But it would mean that groups of
records would be interleaved rather than individual ones, and that
might or might not be easily discernible looking at the output.

What puzzles me in all this, though, is how it works fine at the
developer's site but not at the customer's. Could it be that there is
no blocking going on locally, but large(r) buffers are in use at the
customer site?

Tony H.

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

Re: Query regarding MVCSK/MVCDK

[Tony Harminc]

On 7 February 2017 at 12:03, Binyamin Dissen 
wrote:

> POPs is not clear as to whether R1=0 will allow access to all keys. It does
> seem logical, but is it true?
>

Although it perhaps doesn't say so explicitly in the descriptions for
MVCSK/MVCDK, I think it is completely clear from the use in those
instruction definitions (and others) of the phrase "access key", when read
with the description of Key-Controlled Protection in Chapter 3. Storage,
which uses the same phrase, and says "The keys are said to match when the
four access-control bits of the storage key are equal to the access key, or
when the access key is zero."

Tony H.

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

Re: BSAM vs QSAM

[Tony Harminc]

On 6 February 2017 at 09:22, R.S.  wrote:

> W dniu 2017-02-06 o 14:59, Ron Burr pisze:
>
>> As far as I know, reading a physical sequential (or partitioned dataset
>> member) in reverse order can only be done using BSAM (via the BSP macro).
>> Not that many applications require that mode of processing. But if one
>> does, well then, that appears to be the only option. Mind you, there are
>> some restrictions inherent in using BSP, as the manual explains.
>> The COBOL manual states that you can process a QSAM tape dataset in
>> reverse order by doing an OPEN REVERSED, but I suspect that the dataset
>> will actually be processed using BSAM, not QSAM.
>>
>
> It's worth to mention that performance of reverse processing dataset on
> real tape is worse than horrible.
> And IMHO it's not argument for using virtual tapes but for not using
> datasets on tape for applications. Tapes are for backup and ML2.
>

Are you two perhaps mixing reading in "reverse order" of records with "read
backward"? Read Backward is a CCW that (on old reel-to-reel tapes, at
least) moves the tape backwards past the read head and transfers data into
main storage in byte-by-byte decreasing address order. So the data ends up
in normal order in storage, but if your app knows somehow that the tape is
positioned at the end of the data, it doesn't have to rewind or backspace
and then read forward.

I have no idea if any modern real or virtual tape supports this, or if
COBOL or even BSAM/QSAM ever did.

Tony H.

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

Re: Clarification on Recognizing My SubSystem Interface (ssi) Function Rou tines

[Tony Harminc]

On 30 January 2017 at 09:39, esst...@juno.com <esst...@juno.com> wrote:
> Tony Harminc wrote
>
>>That's up to you. You look at the command text and decide if you are
>>interested. If you want to process only commands prefixed by the
>>command character you specified, then check for that and ignore
>>anything that doesn't start with that character.

> That works fine for Function Code 10, which I only used as an example.

Sorry, it wasn't obvious that 10 was only an example.

> If I look at Function Code 8 (End-of-Memory) call there is no command text.

Indeed, because EOM is not logically related to a command. Rather,
that call includes the ASID of the ending address space, and some
other handy odds and ends. You will know if this address space's going
rhrough EOM is of interest to you because you surely made some kind of
record somewhere globally accessible when you built data structures or
had code running in that address space that you now need to clean up.
The EOM subsystem call knows nothing about if or why why you are
interested in knowing about this particular EOM event.

> Are You saying each function code needs to be determined differently ?
> Using a different technique ?

I'm still not getting whatever it is that you're not getting. You have
some functional reason to want to be called for one or more subsystem
call types. You install a routine for each such, and set the value
appropriately so that you will be called. Some of those calls (e.g.
commands, WTOs, EOMs) are broadcast; others (e.g. Open or Allocate)
are only for you. Regardless, your routine gets control, and you do
whatever it is you want to do.

> Wouldn't the SSCVT have the Target SubSystem ID ?

Um, yes... but your routine surely inherently already knows that.
Unless you are using common code for multiple subsystem call types,
which is not something you've mentioned, and which I think is
generally a pretty unlikely thing to want to do.

So I'm afraid I'm still not understanding the problem you are
encountering or anticipating.

Maybe give an example of how your EOM routine needs some information
you don't see being provided. Why would it need more than the ending
ASID?

Tony H.

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

Re: Clarification on Recognizing My SubSystem Interface (ssi) Function Rou tines

[Tony Harminc]

On 27 January 2017 at 19:21, esst...@juno.com  wrote:
> My understanding is for broadcast requests, the SSI checks every
> subsystem to determine if each subsystem is interested in the requested 
> function.
> .
> If the SSI finds a subsystem that is interested in the requested broadcast
> function the SSI pass control to the respective function routine specified in 
> the IEFSSVTI macros.
> The process is repeated for each subsystem interested in handling the 
> requested function.
> .
> Is my assessment correct ?

Yes.

> What is not clear from "MVS Using The Subsystem Interface" is how to exactly
> determine if the requested function is to be handled by my subsystem.

That's up to you. You look at the command text and decide if you are
interested. If you want to process only commands prefixed by the
command character you specified, then check for that and ignore
anything that doesn't start with that character. In that case you
would return RC=0 meaning that you are not interested. If you want to
process the command, then do so, and return RC=4 to say that you have
handled it.

Nothing stops you from looking at and acting on commands that don't
start with your character, but you can't do a lot of synchronous
processing because you will delay the "rightful owner" in getting the
command. So if, e.g., you want to notify your mainline program
whenever someone issues a certain command, you can do that.

There are all kinds of flags available as well as the command text.

> For Example:
> I have a member in IEFSSNxx SYS1/PARMLIB for My Subsystem Called ABC1
> it also specifies an INIT Routine (ABCINIT) And a Commmand Prefix as a 
> prameter.
> .
> My Subsystem Initialization Routine (ABCINIT) does issues a IEFSSVT 
> REQUEST=CREATE
> to create the SSVT.
> The Respective IEFSSVTI macros specify a Function Code of 10 and a Program 
> called
> ABC@CMDS.
> .
> My understanding is the SSI will invoke my Function Routine (ABC@CMDS) for 
> Function
> Code 10. It is up to MY Routine (ABC@CMDS) to determine if it is interested 
> in processing
> this request code 10.

Yup.

> Im trying to determine the recommended methods for determining this.

 [talk of name/token pairs]

I'm kind of lost here... What are you trying to correlate using the
N/T stuff? Just look at the text and do something or don't. If you
want only to process commands starting with your character, you might
do just as well to use the MODIFY interface, rather than going through
the much riskier and difficult setting up of a subsystem, with all the
potential of causing problems for other subsystems if you get it
wrong. So instead of, say,

*mycommand

you would use

f myprog,mycommand

You don't even need APF authorization to do this.

Tony H.

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

Re: Blockchain

[Tony Harminc]

On 26 January 2017 at 12:43, Cannaerts, Jan  wrote:
> z/Series machines are not geared towards floating point operations the way
> commodity GPUs, FPGAs, or purposely built BitCoin miners are. So you surely
> would spend more money on electricity powering the machine than you'd gain
> through mining BitCoins, as is already the case for GPUs.

Bitcoin mining, except just possibly with special purpose hardware,
can no longer be done at a profit unless your electricity is free.
This could be solar PV (but will you pay off the capital cost?), or
somewhere where hydroelectricity is heavily subsidized as a nighttime
heating fuel, and so on. But of course there are other kinds of
"free". Perhaps your office lease has electricity included, and says
nothing about what you use it for. And of course there are all kinds
of botnets and such out there that mine using their victims' compute
power/electricity.

But regardless, mining is slowly but surely on its way out as a direct
money maker, by design. Five years ago you could make a little money
using a simple GPU in a desktop PC; now that's impossible.

Tony H.

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

Re: VSMLIST

[Tony Harminc]

On 21 February 2017 at 19:01, Joe Reichman  wrote:
> I am Looking for Storage that was GetMain'ed and Page'ed out

It's just not a sensible thing to be looking for, unless perhaps for
some kind of performance measurement. And that's not the sort of thing
you can just write as an application program without a huge amount of
knowledge of the internals of the system.

So why do you want to know that a page is GETMAINed and paged out?
What will you do differently if your program finds this out? There are
other possibilities; a page can be accessible but not GETMAINed.

VSMLIST can tell you if a page is GETMAINED, and LRA[G] can tell you
if it's paged in or out, but those things can change the moment you
look away, or even as you are looking, in a multiprocessor
environment. Unless you are running disabled or hold locks that you
probably shouldn't be holding.

What are you trying to accomplish? Answer that and probably someone
will suggest the best approach.

Tony H.

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

Re: Maximum size of a PDSE library?

[Tony Harminc]

On 21 February 2017 at 19:51, Anthony Thompson
 wrote:
> There was a Redbook entitled 'Partitioned Data Set Extended Usage Guide', 
> document number SG24-6106-01, dated May 2005 (so it very much pre-dated PDSE 
> V2).
>
> That Redbook stated that that PDSE directories entries were organised in a 
> balanced B-tree, and that the PDSE pages were either directory pages, or data 
> pages, not mixed. That information may no longer be accurate, of course.
>
> I say was, as I searched on the Redbooks site in an effort to provide a link, 
> using both the document title and number as search terms, but didn't find it.

It's still there (as of 2017-02-21 20:31 GMT-5) as a viewable online
book, but the PDF does seem to have disappeared. Get it while you can,
I guess...

https://www.redbooks.ibm.com/redbooks/SG246106/wwhelp/wwhimpl/js/html/wwhelp.htm

Tony H.

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

Re: Unterse for 64 bit LINUX?

[Tony Harminc]

On 17 February 2017 at 14:55, Gary Jacek  wrote:
>
> Is there software available for 64 bit LINUX that is compatible with a file 
> that is tersed using AMATERSE
> on zOS 2.1 ?

64 bit Linux on what platform? Intel? z? ARM?

> The vendor who wants to unterse the file has tried Google but cannot find any 
> leads.

Perhaps they should Google on "terse" rather than AMATERSE. IBM has
terse for a number of platforms, but to my knowledge has not
officially released any of them except for z/OS and z/VM. There are
copies floating around out there, but they are not something I would
suggest incorporating into any kind of production situation!

I'm puzzled that a vendor (an ISV?) wants to deterse data from z/OS on
a Linux platform. Could it not just be FTP'd or otherwise transferred
in some more ordinary way? Maybe ZIP'd or tar'd on z/OS if you need
the compression?

Tony H.

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

Re: VSMLIST

[Tony Harminc]

On 22 February 2017 at 11:16, Joseph Reichman  wrote:
> I know if you specify GSPV or SHPSV on the attach tasks can Share ? A subpool
>  If this is not specified on the attach would a subtask get  a S0C4 for 
> referencing storage
> Obtained by the originating task

Use of subpools (I'm speaking of ordinary subpools in the range of
0-127 - not CSA or the like), and whether they're shared or not, has
to do with storage management, not with access control. You can ATTACH
a subtask without sharing a subpool, that task can GETMAIN some
storage, and the ATTACHing task can then reference it. Likewise the
ATTACHed task can reference storage acquired by the ATTACHing task.
This is perfectly legitimate, but it's up to you to make sure that one
task doesn't free storage that the other will access. You need to
design and write this stuff; MVS won't manage it for you.

By default, when you ATTACH a subtask, subpool 0 is shared, and no
others are. And since subpool 0 is the default for GETMAIN in most
cases, if your subtask obtains storage, that storage will not go away
when the subtask terminates, because it's owned by the ATTACHing task.
So you can easily make the mistake of ATTACHing the same subtask
multiple times, and if the subtask doesn't free its storage, you will
have a memory leak. It can be convenient either to not share subpool 0
(SZERO=NO), or to have the subtask use a different unshared subpool
(123 or something) for working space it gets, and then there is no
need for cleanup in the subtask. Again, none of this relates directly
to access to the storage, S0C4s or the like.

Tony H.

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

Re: S/390 G6 SE Driver Disk

[Tony Harminc]

On 22 February 2017 at 10:28, Jim Stefanik  wrote:

> I guess I'll have to wait and see what their support says; although the one I 
> talked to yesterday seemed to suggest that I can't get a support contract 
> until the machine works, which makes zero sense...unsure if this is true on 
> not...I'll have to see what they say today now that they have a serial number.

I think what that's about is whether the machine is eligible for a
support contract. If the machine has always had IBM maintenance, then
it's just a matter of IBM looking that up, and then you can pay them
some serious bucks to continue it (assuming they are willing to
support it at all). But if it has been out of support, then IBM
typically wants to evaluate the machine hands-on to see if it's been
well treated, not modified by a third party with non-IBM parts, etc.
Of course you will also pay serious bucks for this service.

Overall it seems to me you have two possible routes: the commercial
one, where you will pay big bucks for all the above, if they are
willing to deal with such a machine at all, or the hobbyist approach
where you try to be Connor-II and convince some friendly IBMers to
help you out. Indeed for the latter you might do better to approach
one of the museums, formal or informal, who collect these things. They
will probably have much better luck with IBM than a lone hobbyist.

Tony H.

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

Re: IBM LinuxONE Rockhopper

[Tony Harminc]

On 12 February 2017 at 19:50, Timothy Sipples  wrote:

> IBM's CFO also reported 8 new customers in the quarter, 29 in 2016, and 80
> since
> introduction of the IBM z13.
>

Is that "net new" or just plain "new"?

Tony H.

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

Re: Job Loyalty

[Tony Harminc]

On 11 February 2017 at 07:35, Salah Balboul  wrote:

> This is "Capitalism", making money is king. Every large corporation tries
> to sell this "Job Loyalty" to workers, however, rest assured this is a one
> sided affair. They want you to be loyal.


>From way back on January 13, 1997 in The New Yorker:
http://imagecache5d.allposters.com/watermarker/60-6005-PDFB100Z.jpg

Tony H.

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

Re: JZOS calling a 64 bit class

[Tony Harminc]

On 18 August 2016 at 10:37, Kirk Wolf  wrote:
> FWIW, there aren't such things as "64-bit classes".The class files
> (byte code) is not architecture specific.

I wondered what Janet meant by that, but figured I'd missed one of the
many changes going on in the Java world lately. She said "The class
I'm invoking is definitely 64 bit and I've confirmed that by printing
out the bitmode in the program and running it from the USS command
prompt." So what does this mean?

Tony H.

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

Re: Assembly Error IEAMSCHD I can't see it may be you can and can Help thanks

[Tony Harminc]

On 26 February 2017 at 00:21, Joe Reichman  wrote:
> I just cut and past the "RTMRADDR"  from the documentation site and it
> assembled don't understand

The keyword is RMTRADDR= . If you had posted the complete error
messages from your assembly, this might have been resolved faster.

BTW, the order of keyword operands on a macro invocation is
irrelevant. In this case you were supplying what looks like a keyword
RTMRADDR=, but since no such keyword was defined in the macro, it was
taken to be a positional, and was then rejected by conditional
assembly code in the macro. Good thing IBM put that in there...
Otherwise your "keyword" would have been silently ignored.

Tony H.

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

Re: Loading Java dump into IPCS

[Tony Harminc]

On 22 August 2016 at 16:53, Janet Graff <
004dc9e91b6d-dmarc-requ...@listserv.ua.edu> wrote:

> Can someone point me to a manual on how to read a JVM dump?


I have little experience in this, and none current. But IBM has had some
tools and doc on JVM dumps going back 10+ years, and maybe it's been
updated. For a doubtless-obsolete start, there's an SVCDUMP and FindRoots
package on the z/OS UNIX Tools & Toys site.
http://www-03.ibm.com/systems/z/os/zos/features/unix/bpxa1ty2.html I seem
to remember that a newer version was shipped as part of Websphere, bit even
that may be out of date.

Google finds references to FindRoots and related Java diagnostic tools, but
most of them are -- predictably -- not for z/OS. There is an old Redpaper
at http://www.redbooks.ibm.com/abstracts/redp3950.html that describes some
IBM Java tools, and that in turn leads to en Eclipse-based meory analyser
http://www.eclipse.org/mat/

Hopefully some knowledgable IBMer will jump in here...

Tony H.

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

Re: IBMLINK SR Application Unusble

[Tony Harminc]

On 25 August 2016 at 08:22, Doug Henry
<012e22efeed4-dmarc-requ...@listserv.ua.edu> wrote:
> Print this page
> E-mail this page
> Digg
> Facebook
> Twitter
> Delicious
> Linked In
> Stumbleupon
> Google+

A good ad blocker makes short work of those "social media" buttons.
And is good for privacy and security to boot. Do you really want
Facebook et al knowning about every visit you make to SR?

Tony H.

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

Re: LE CEEDUMP "doing too many favors"

[Tony Harminc]

On 31 August 2016 at 10:22, Charles Mills  wrote:
> Here's an example. How does it know the high halves of the registers are
> irrelevant just because I am AMODE 31? Maybe I was in AMODE 64 a second ago.
> Maybe I am supposed to be in AMODE 64 and need clues as to why I am not.
> Maybe I am doing 64-bit arithmetic. Maybe I am using some of the new "high
> word" instructions.

Perhaps because it's showing you values from a save area that doesn't
have room for 64-bit regs? But then why would it put in _
before the values? Maybe there's a common formatting routine. With LE,
who knows...

Tony H.

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

Re: rexx CEXE eye catcher format ?

[Tony Harminc]

On 8 September 2016 at 00:55, Itschak Mugzach  wrote:
> I am interested in ibm's Rexx compiler eye-catcher. Can you point me to the 
> document that the information you mentioned described there?

As I said, it's in the TSO/E Customization book. The edition I have
here is SA32-0976-02 z/OS V2R2 TSO/E Customization. It's in Chapter 43
"Routines and interfaces to support a REXX compiler".

But I don't think the exact format of the eyecatcher is documented
there or anywhere else. The Customization book is about customizing
TSO/E rather than the REXX compiler. This book is agnostic about the
compiler; you can in theory write or buy one from anywhere, and it
might have a different eyecatcher from IBM's, or none at all. For that
matter, there is nothing I can see to require that the CEXEC file must
begin with executable code. When TSO/E runs a CEXEC, it doesn't branch
to the start of the CEXEC, but rather it calls the routine whose name
is in columns 13-20. That routine invokes the CEXEC code, but that
code could be in Java bytecodes or any other scheme, as far as I can
tell.

Tony H.

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

Re: TSO User ID Rules (Was: z/OS and code pages)

[Tony Harminc]

On 14 September 2016 at 02:05, Timothy Sipples  wrote:

> (a) If you want your RACF ID to be usable within MVS subsystems, the first
> character cannot be a numeric digit (0 through 9).

What, in this context, is an MVS subsystem? And what does "to be
usable within MVS subsystems" mean? And where is this text from --
evidently not the RACF Security Administrator's Guide?

Tony H.

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

Re: z/OS and code pages

[Tony Harminc]

On 14 September 2016 at 14:53, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>But Katakana shares the same hex values as lower case English letters. I have 
>>always had upper case User IDs and passwords. Perhaps it is a RACF 
>>restriction?
>>
> What technical concern (I presume there was one) motivated EBCDIC's
> usurping the Latin minuscule code points for non-Latin characters, rather
> than first employing the code points left uncommitted in the s360 Principles
> as the ISO8859-x family did?

Memory, or rather, lack thereof, presumably in the 3277 terminal and
its control unit. Plus IBM's famous early indifference to non-US
character requirements. Each country/region got a locally designed
(maybe even locally implemented, at first?) character set (glyph) ROM
and mapping table for the characters thought to be needed. Since the
3277 did not display lower case Latin letters anyway, it probably
seemed reasonable to use those positions for the fairly large Katakana
set. Perhaps keyboard mapping also contributed. If there existed
typewriters with both Latin and Katakana, that keystroke mapping with
the ability to lock the keyboard into one or the other mode would be
someting to be preserved.

Tony H.

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

Re: Bypassing s322

[Tony Harminc]

On 14 September 2016 at 16:34, Bill Woodger  wrote:

> When IBM decided to use "character" comparisons where possible for numerics, 
> they had to ban the negative zero.
> Although in a decimal compare a zero is zero, no matter how signed, in a 
> character compare it is not. Ergo -ve zero could
> not be allowed to exist. (you can of course screw things up by being 
> deliberate, but no calculation in COBOL will ever
> generate a -ve zero result, nor will any truncation).

So in COBOL, +0 times -5 is +0, i.e the rules of algebra don't apply?
The generated code must go out of its way to accomplish this.

Tony H.

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

Re: A Programing language called Scala?

[Tony Harminc]

On 8 September 2016 at 16:07, Kirk Wolf  wrote:
> Tony,
>
> Everyone can have their own opinion.   Mine is that the statement means
> that Java byte code is eligible; otherwise it is inconsistent and already
> violated by many, many cases and organizations including IBM themselves.
>  I am pretty sure that my IP attorney would say that the language is poorly
> written.

I'm not sure that it's poorly written as much as that it's ambiguous
and incomplete -- perhaps intentionally so. Probably it was rushed out
after the Neon affair. But it doesn't matter.

> For example:  I am reasonably certain that Websphere can't violate the zAAP
> eligibility license terms, but Websphere includes byte code that did not
> originate from Java-language source code.Also, IBM's own tooling
> converts annotations into byte-code modifications (those are not part of
> the "Java language") - would you argue that those are not zAAP eligible?

I'm not arguing it one way or another. I raised the issue in the Scala
context only because it seemed a bit surprising that no one else had.
(Though I am pretty sure that IBM's own code doesn't have to conform
to any rules in a customer licence agreement.)

With respect, I think you -- like Gil -- are thinking like a
programmer rather than a lawyer. I  like to think that way too. Your
arguments make complete sense, but are, imho, not relevant. We
programmers tend to think that Legal Reasoning is what The Law is all
about. It's not - it's only a tiny part of what lawyers do for a
living.

May I point you to an old article that I think has been mentioned here before:
http://www.forbes.com/asap/2002/0624/044.html (warning - may not play
well with ad and tracker blockers)

The details are quite different (the article is on the face of it
about patents, and I'm not bring those into this discussion), but it
perhaps gives the flavour of what I am trying to say about the
futility of arguing over such a document..

> If you are really worried, then open an ETR or get an IBM representative to 
> clarify the eligibility terms.

I'm not at all worried; it really doesn't concern me. I'm just trying
to point out that this is not a case of a technical agreement that can
be argued algorithmically to come out with a binding answer. If IBM
sufficiently dislikes the result, they will change the agreement. If
the result doesn't bother them, they won't. The agreement didn't exist
at all until an unexpected result bothered them. Simple as that.

Tony H.

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

Re: z/OS and code pages

[Tony Harminc]

On 13 September 2016 at 19:09, zMan  wrote:
> This is probably a dumb question, but that's never stopped me before:

:-)

> If my name were "*Étienne*", would I be able to have that as a TSO userid?

No.

> Or would I have to suffer through just "*Etienne*", sans accent aigu?

Yes. Or of course some other id entirely, since there is nothing in
place to reliably translate Étienne into Etienne if you are sending
userids between other systems (e.g. Windows) that do support "fancier"
characters, and z/OS.

> Does the MVS side of z/OS "do" code pages in any meaningful way? I don't
> mean in DB2 or some other application. I think I read that WTO really only
> does code page 037, which suggests that the answer is "no".

No, not really. RACF, in particular, effectively supports a small
subset of CP 037 only. There are specific and quite restrictive rules
for what byte values are allowed in userids, passwords, and password
phrases. (I say byte values rather then characters, because RACF
specifies the allowed characters this way, rather than in terms of
e.g. Unicode u+ or IBM GCGIDs.) There are also implicit
restrictions on other fields such as the user name. While an
authorized application program may well be able to write unsupported
byte values into the database, there is no real support in the RACF
commands for them, and results may get strange if you write an app
that does this.

> Any pointers to doc welcome; of course "z/os" and "code page" (or
> "codepage") gets a zillion hits, too many to be particularly useful.

The doc updates for RACF APAR OA43999 (in the z/OS 2.2 base doc) do
contain the allowable characters in passwords, and their hex values.
But I don't think there is really much, since z/OS, as you say,
doesn't really support code pages.

Tony H.

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

Re: Converson of hex value to character

[Tony Harminc]

On 12 September 2016 at 11:52, Bernd Oppolzer
 wrote:
> You need two additional bytes after ONEBYTE and TWOBYTE,
> so that UNPK can do its nibble switching thing there.

If you have many bytes to convert (say, more than 7), the TROT
(TRanslate One to Two) instruction with a 512 byte table can do it all
in one step with effectively unlimited length. Whether this is faster
than a loop of UNPKs and TR fixups (of course you need only one TR for
up to 256 bytes), I don't know. Certainly it's conceptually easy to
understand.

A warning, though. The fine print in the instruction description says
"The translation table is *treated as being* on a double-word
boundary" [my emphasis]. This means TROT silently ignores the
rightmost 3 bits of the table address, so make sure you actually put
it on a doubleword boundary. HLASM cannot warn about this, because the
address is in a register. (Ask me how I know about this problem...)

Tony H.

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

Re: rexx CEXE eye catcher format ?

[Tony Harminc]

On 11 September 2016 at 21:18, Scott Ford  wrote:
> I have limited experience with compiled, while the interpreted I have written 
> since before
> dinosaurs roamed the earth

There were dinosaurs roaming in 1983...?

Tony H.

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

Re: TSO User ID Rules (Was: z/OS and code pages)

[Tony Harminc]

On 15 September 2016 at 02:41, Timothy Sipples <sipp...@sg.ibm.com> wrote:
> Tony Harminc wrote:
>>What, in this context, is an MVS subsystem? ...And where is this
>>text from -- evidently not the RACF Security Administrator's Guide?
>
> You are allowed to take a look at the Administrator's Guide. :)

I already had, and the phrase "MVS subsystem" does not appear in that book.

> But here's a copy/paste:
>
> "TSO and MVS also require that the first character of user IDs be uppercase
> A - Z, # (X'7B'), $ (X'5B'), or @ (X'7C')."

That says nothing about "subsystem". You appear to have inserted the
word, and I'm just trying to understand why and with what meaning.

> So what does "MVS" mean in this context? The Administrator's Guide doesn't
> say. "Not z/OS UNIX System Services" is a reasonable answer, but it might
> be a partial one.

I obviously wasn't clear: It's the "subsystem" part I'm asking about,
not the "MVS" part. I know at least a couple of meanings of the word
"subsystem" in MVS. But I don't know of any such usage that sets these
additional requirements for userids. Unless you are using it with some
trivial meaning like "stuff that runs on MVS that isn't UNIX or TSO
and somehow, you know, does stuff with userids".

Tony H.

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

Re: What is the STCB?

[Tony Harminc]

On 12 September 2016 at 10:16, Charles Mills  wrote:
> What is the STCB? For example,
>
> 312 (138) ADDRESS 4 TCBSTCB ADDRESS OF STCB

General purpose above-the-line extension of the TCB, conforming to
more modern standards (eyecatcher, 31-bit clean pointers, etc.)

It's been around long anough that I find a number of fields routinely
useful for debugging. And a couple even during normal operation, e.g.
STCBOTCB.

Tony H.

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

Re: How do you say "z/OS"?

[Tony Harminc]

On 25 September 2016 at 16:40, Bill Woodger  wrote:
> The *letter* is pronounced "zed". The sound of the letter is zzz. Zoo, Zorro, 
> zero.

"How do you spell ZEE?"

"ZED EEE EEE".

"How do you spell ZED?"

"ZEE EEE DEE".

Tony H.

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

Re: Question About ATTACHX and ECB

[Tony Harminc]

On 4 October 2016 at 16:15, Steve Thompson  wrote:
> Yes. So that would mean that I got, xx40.

I'm not sure what the above means, but I agree with Charles that you
are way overcomplicating this. CALLDISP and SVC 50?. Could you not
tell us the actual content of your ECB, as asked a couple of times?
And if you can't show the actual code, give at least a clear outline
without bringing new things into the mix, and without omitting
anything other than truly irrelevant items. Perhaps something like:

  XC  MYECB,MYECB
  ATTACHX EP=blah, ECB=MYECB
  ST  R15,RC
  LOG  'ATTACHX finished with RC=', RC
* Here there are a few instructions that do not call any system
service or modify MYECB.
  WAIT 1,ECB=MYECB
  LOG  'Returned from WAIT'
  LOG  'MYECB content =',MYECB

and then show us the value of MYECB here.

Also, when you say "SYSPRINT shows IDCAMS got CC=0", that doesn't say
that the ATTACHed subtask has finished; it just says that IDCAMS
printed a message about its status.

Tony H.

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

Re: Bypassing s322

[Tony Harminc]

On 15 September 2016 at 16:24, Bill Woodger  wrote:
> February this year, in the Archives, "COBOL Code Gened for MOVE COMP-3 S9(9) 
> to S9(8)"

Got it, thanks.

Tony H.

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

Re: Bypassing s322

[Tony Harminc]

On 14 September 2016 at 18:05, Bill Woodger  wrote:
> Yes, the compiler generates additional code to ensure that a -ve zero cannot 
> be the result of anything in COBOL.

This would surely have potentially as much overhead as using CP rather
than CLC in the first place. Do you by any chance have an example of
the generated code for this? I don't write COBOL, so it would take me
roughly forever to come up with an example.

Tony H.

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

Re: How do you say "z/OS"?

[Tony Harminc]

On 16 September 2016 at 16:22, Porowski, Kenneth  wrote:
> DOS was always 'doss'
>
> OS/360 was 'oh ess 360'
> SVS was 'ess vee ess'
> MVT was 'em vee tee'
> MVS was 'em vee ess'

Except perhaps in "PARTURIENT MONTES, NASCETVR RIDICVLVS MVS", where
it would sound like "moose".

http://www.mxg.com/thebuttonman/html/button190.htm

> ESA was 'eee ess aaa'
> OS/390 was 'oh ess 390'

Tony H.

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

Re: z/OS TCP/IP question: name resolution order/override

[Tony Harminc]

On 21 September 2016 at 18:40, Phil Smith  wrote:
> I had some vague idea that on z/OS, the Resolver can use some or all of:
>
> 1. DNS
>
> 2. Its own configuration data sets, via GLOBALIPNODES statements
>
> 3. /etc/hosts
>
> I just spent some time looking at IBM doc, and what I found seems to support 
> this. What I couldn't seem to grok was whether you can control the *order* in 
> which the three are used: that is, can you say "OK, we use the DNS server at 
> this IP, but we want to look in /etc/hosts *first*"?

There is a LOOKUP statement in the TCPDATA member/file.

; LOOKUP indicates the order of name and address resolution.  DNS means
; use the DNSs listed on the NSINTERADDR and NAMESERVER statements.
; LOCAL means use the local host tables as appropriate for the
; environment being used (UNIX System Services or Native MVS).

You may be able to point a particular app at its own TCPDATA (DDNAME
SYSTCPD or via the various UNIXy search orders), which in turn can
contain not only its own LOOKUP statement, but perhaps even point to a
different DNS server than the system-wide default. In particular, you
could run your own tiny DNS on the same z/OS image, perhaps listening
on a highish port so you don't run into trouble with not being allowed
to listen on a well known one. But probably this is overcomplicated.

Tony H.

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

Re: k4t4949b (September 2016 refresh of the z/OS 2.2 manuals)

[Tony Harminc]

On 20 September 2016 at 12:18, Alan Young  wrote:

> This is correct. 7zip is not the problem. The problem is the end user's
> unzip application. The zip specification has been extended over time to
> support additional compression methods. See
> https://support.pkware.com/display/PKZIP/APPNOTE and
> https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT.  Section
> 4.4.3.2 has a quick summary of the feature versions. The current PKzip
> program will unzip the doc file created by 7zip.

This would all be fine if the file in question was a ZIP file.
According to my reading of even the latest version of the APPNOTE.TXT
file, IBM's file does not meet the specs for a ZIP file. In
particular, a required signature element is missing. Whether or not a
particular commercial product from PKWARE will decode this file misses
the point. It's not a question of new compression types; the entire
file wrapper is plain wrong.

Tony H.

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

Re: k4t4949b (September 2016 refresh of the z/OS 2.2 manuals)

[Tony Harminc]

On 19 September 2016 at 14:31, Kevin Minerley  wrote:
> Unfortunately, this is working as designed.  If indeed it's the sk4t-4949-xx 
> deliverable, it is large.  As a matter of fact, were
> it to be be put on a dual-layer DVD it wouldn't fit (at least in this pass).

The file as I just downloaded it is about 1GB (1,118,616.064 bytes
according to Windows). This would fit comfortably on even a
single-layer DVD. It isn't even all that much bigger than a CD. Maybe
IBM has smaller DVDs than most of us...

But in any case I have a good deal of trouble seeing why this is relevant.

> Most modern zip utilities work against it.  Personally, I use 7-zip but when 
> manufactured it's the same zip utilities we have
> been using since the days of physical media.

Really? I think of Winzip as *the* standard commercial Windows-based
zip utility, and it doesn't accept it. Neither does the Windows
built-in zip handling in Windows explorer. Neither does the java
command. And the reason is clear: it's not a zip file. The first two
bytes of the file are X'377ABCAF' or ASCII "7z..". The zip file
specification
https://support.pkware.com/display/PKZIP/Application+Note+Archives
requires that a zip file start with a header of X'504B0304' or ASCII
"PK..", no matter what the compression method within the file.

So opening this file pretty much requires that 7-zip or some other
compatible decompressor be installed. If that's really what IBM
intends, then the file should not be marked as .zip .

Tony H.

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

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Tony Harminc]

On 25 August 2016 at 12:11, Janet Graff
<004dc9e91b6d-dmarc-requ...@listserv.ua.edu> wrote:

> I have XGR'd GPR2 and GPR3 before the abend and GPR5 definitely does not 
> contain a bunch Beees.

I'm not sure quite what you mean by this. Your own code (that you know
has run not long before the abend?) XGR'd both G2 and G3 with
themselves, i.e. zeroed them? Or XGR'd with each other? Or...?

Perhaps interesting that X'B' is the inverse of X'4'. But I don't see
any convenient X'BF's in any of those regs to go with the X'40's.

Tony H.

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

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Tony Harminc]

On 25 August 2016 at 12:47, Charles Mills  wrote:
> I am generally very happy with the CEEDUMP and find it quite satisfactory.

My experience with CEEDUMP is that it's all just fine until it isn't.
It seems not to cope at all well with anything other than a simple
failure within your own code. If anything the least bit subtle happens
- a stack overlay, a failure in a library routine, abend in a UNIX
kernel or other z/OS system routine - it just can't be relied on to
give you the information needed to find the root cause. Then you have
to disable all LE exception handling, set a SLIP trap, and go back to
debugging with a "real" dump.

> Are you XPLINK or standard linkage?

I believe DOWNSTACK implies XPLINK.

Tony H.

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

Re: How to obtain diagnostics for EDC5241S Load request for fetch load module unsuccessful?

[Tony Harminc]

On 26 August 2016 at 12:27, Kirk Wolf  wrote:
> EDC5241S Load request for fetch load module unsuccessful.
> errno2 = C407003B
>
>> bpxmtext C407003B
> JrEdcFtchFcfailed01: The program called fetch() to load a module. The load 
> failed.

but...

On 26 August 2016 at 15:39, Jerry Callen  wrote:
> JRNotSysRoot
> A relative pathname is allowed only for processes.

I'm confused... The description in 'SYS1.MACLIB(BPXYERNO)' for reason
code 3B (= dec 59) is indeed JRNotSysRoot. There is no entry for
JrEdcFtchFcfailed01. I gather these "errno2"s are not unique...?

Ah - to answer my own question... BPXMTEXT does some triage on the
reason code and calls one of three routines:  EDCMTEXT for the LE
range, emits boilerplate text for UNICODE, and falls through to
strerror() assuming it's UNIX.

if substr(code,1,1)='C' & length(code)=8 then /* if LE rsn code

if substr(code,1,2)='E4' & length(code)=8 then/*UNICODE rsn code

Learn something every day.

Tony H.

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

Re: Dump in 64 bit mode "Storage around GPR2 is invalid."

[Tony Harminc]

On 25 August 2016 at 17:52, Janet Graff
<004dc9e91b6d-dmarc-requ...@listserv.ua.edu> wrote:
> I don't know if I'm XPLINK or standard linkage.

The fact that your dump says DOWNSTACK DSA almost certainly implies
XPLINK.  In the LE Debugging guide where I went to verify this, there
is this interesting note under "Finding XPLINK information in a
Language Environment dump":

"It is important to understand that the registers saved in an upstack
DSA are those
saved by a routine that the DSA-owning routine called. Typically
register 15 is the
entry point of the routine that was called, and register 14 is the
return address into
the DSA-owning routine. In contrast, the registers saved in an downstack DSA are
those saved by the DSA-owning routine on entry. Register 7 is the return address
back to the caller of the DSA-owning routine. Register 6 may be the
entry point of
the DSA-owning routine."

Regardless, I don't think these are *your* registers at time of failure.

> Regarding overlays, anything is possible but it's highly unlikely.  I've been 
> forcing dumps every couple of instructions to make sure things are clean. The 
> registers in the downstack area don't all reflect the actual state of things 
> when I force the abends.  Can do a LA R5,186 and the dump will still show R5 
> containing all Beees.

>  I wish I could use TSO TEST but I don't know how to get it to run on a USS 
> executable.

If you don't know TEST, I wouldn't start now... For one thing, the
support for anything 64-bit is somewhere between none and minimal. But
if you know TEST, then it should be possible to copy your executable
(program object in a UNIX file) into a PDSE member and then run it
under TEST. But then you won't have a UNIX shell, and who knows what
else may be missing; it may take you down a rathole. But I *have* done
this copy of a program that was written by non-MVS C programmers into
a PDSE and run it under TSO successfully, so at least that part can
work.

Good luck.

Tony H.

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

Re: z/OS bookshelves in weird order in KC

[Tony Harminc]

On 3 October 2016 at 15:16, Peter Hunkeler  wrote:
> I would prefer if a) the shelves are named exactly as the products are, and 
> b) if the list is kept in strict alphabetic order by product name.

Being the old mainframe hack that I am, in Softcopy Reader I am used
to sorting the shelves by their file names, which in effect are the
product prefixes, such as IEF or GIM or BPX or IKJ. I don't suppose
we'll ever see that in KC

Tony H.

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

Re: Question About ATTACHX and ECB

[Tony Harminc]

On 3 October 2016 at 19:52, John McKown  wrote:
> On Mon, Oct 3, 2016 at 6:35 PM, Steve Thompson  wrote:
>
>> It is 0. I know this because I do a compare for anything other than zero
>> going to S0C3 (  EX  0,*).
>>
>
> I used to do that. I really prefer my "new" method (which I think I got
> from someone here).
>
>LT Rx,ECBADDR
>JZ *+2  # THIS ABENDS S0C1

There are many. For a change I like
LE0,*+4
SQER  0,0

which produces, on z/OS, a 0E0-1D abend (square root exception). Not
too many of those happen in a typical app.

But I think we had a strong discussion of these "cute" abends some
years ago. Just issue an appropriate user ABEND macro and be done with
it, was the mainstream thinking.

Tony H.

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

Re: Question About ATTACHX and ECB

[Tony Harminc]

On 30 September 2016 at 19:05, Steve Thompson  wrote:
> I'm doing some work and needed to do an ATTACHX with an ECB.
>
> So for test purposes I'm attaching IDCAMS. It runs and gives CC=0.

OK

> Ok, in the main task, I've done the ATTACHX with the ECB and then went and
> did a few instructions and then did a WAIT for the ECB.

Did you zero the ECB before you did the ATTACHX? If the POST bit
(X'40') is already on when you WAIT...

> CPU trace shows I don't get dispatch again until the POST is effected for the 
> ECB.

OK. What does the POST trace entry look like? R0 contains the value to
go in the ECB.

> I've looked at the ECB

After you regain control after the POST, I assume...

> and my understanding of the doc for ATTACHX is that
> it gets posted with the CC from the sub task, or ABEND if it is that the
> program ABENDed.

OK

> My ECB has, what appears to be, an RB address.

Is the POST bit (X'40') on? The WAIT bit (X'80')? Perhaps tell us the
exact content of the ECB.

> Now I did have it giving me back the zero (hey, ATTACH IEFBR14, it works).

> But now with IDCAMS or an internal program (written to give S0C3 to test
> what happens), I'm getting other than what is documented.

I'm not sure what this means. When you ATTACH IEFBR14, your ECB looks
good when your main wakes up? But when you ATTACH IDCAMS or other
programs, it has an RB address? Or something else?

Are you quite sure the ECB you WAITed on is one and the same as the
ECB you gave to ATTACHX? Particularly if neither is initialized, or is
in use for some other purpose, there's room for lots of trouble.

> I've taken various dumps, I've been tracing using SVC 50 (originally
> documented as NOP now reserved, but it still works as NOP).

How does SVC 50 play into this? As a trace table entry marker?

> I tried capturing the contents of the ECB before issuing the DETACH in the
> case it gets changed by the effect of the DETACH, but it is the same before
> and after.

DETACH shouldn't affect this ECB.

> I'm just baffled.

So far, so am I. But I'll bet there's a simple problem here that
you're not seeing.

Tony H.

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

Re: intermittent errors using FTP program Interface EZAFTPKS

[Tony Harminc]

On 9 October 2016 at 11:17, Joseph Reichman  wrote:
> As aside do you know where the doc is for IND$FILE
>
> Seems like it's a TSO command processor
> Maybe I can invoke via IKJTSOEV

There is no single official document for IND$FILE. Over the almost
three decades that it has existed, a large handful of people (maybe
two handfuls) have made it their business to understand the complete
protocol. One of the earliest I know of was Pierre Goyette, then at
McGill U. Of course all the independent makers of TN3270 terminal
software have implemented some version or another in their products.
One of the early discussions is in the VMSHARE archives from 1990-1992
at http://vm.marist.edu/~vmshare/browse?fn=IND$FILE=PROB

As is currently the case with IBM's Media Manager, there were rumours
that the full IND$FILE protocol doc was available for $1M or
something. Well, who knows - in those days reverse engineering was not
proscribed the way it often is now, and I doubt anyone paid the big
bucks.

There is also a good and reasonably current summary with more recent
pointers to doc at
http://gsf-soft.com/Documents/IND$FILE.html

And one or two of the handful are still around and maybe even still
talking... Check out http://www.cbttape.org/ftp/cbt/CBT607.zip for one
person who is currently (2016) updating his product..

But I imagine you have little interest in the protocol details. Yes,
you should be able to invoke IND$FILE via IKJTSOEV, but to what end?
Your 3270 emulator has to be expecting the resulting data stream, so
it's normal for the emulator to issue the IND$FILE "command" when you
invoke its "file transfer" menu.

Tony H.

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

Re: Implementing ICSF - FOTS1949 PRNG is not seeded

[Tony Harminc]

On 21 October 2016 at 08:11, R.S.  wrote:
> 1. Chinese algorithm
> Is is some new algorithm or just device with backdoor for Chinesese Three 
> Letter Agency?
> What's so REGIONAL in the algorithm or crypto device? Why there are no
> REGIONAL disks, CPUs, RAM DIMMs, etc?  :-)))

I take your point, of course. But there *were* other regional devices
back in the Bad Old Days. Each country had its own (usually monopoly)
telecom carrier(s), and very many of those had non-standard (or
rather, local standard) interfaces of their own invention. So in the
1960s-70s there were endless regional feature codes for the 37x5 comms
controllers to connect to these different lines. Even somewhat more
recently, North America used the "T1 interface, at 1.544 Mb/s which
can carry 24 voice calls at 64 kb/s, while Europe and most of the Rest
Of World (ROW) used "E1" at 2.048 Mb/s to carry usually 30 phone
channels. T1 and E1 also have different and incompatible protocols at
several levels, so there was no question of just plugging in like an
Ethernet cable, and each end negotiates the best connection.

Very amusing to see an IBM box with a connector labelled "customer
equipment" plugged into a Telco box connector also labelled "customer
equipment". All in one's point of view. I digress, but it's Friday.

Tony H.

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

Re: Watson

[Tony Harminc]

On 7 November 2016 at 21:32, zMan  wrote:
> Yes, but you must start your conversation with either "Siri..." or "OK,
> Google..."

> (ok, or "Alexa..." or "Whatever TF Microsoft's Windows 10 thing is
> called...Cortana, yeah, that's it...")

Wouldn't that be "Hey, Thomas" ?

Tony H.

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

Re: DAIR error 0470 allocating internal reader

[Tony Harminc]

On 8 November 2016 at 22:04, Jim Mulder  wrote:
> The  OA50565 fix changed  the TSO/E environment service to turn on PSCBJCL
> when running in an APF authorized jobstep (i.e. when JCSBAUTH is on).
> IDCAMS is linked in SYS1.LINKLIB with AC(1), so an EXEC PGM=IDCAMS jobstep
> is APF authorized.

One might expect that to keep behaviour as much the same as possible,
IKJTSOEV would check for a TSO segment in RACF and honour the JCL (and
MOUNT and even OPER etc.) setting in that. If there is no TSO segment,
then why not fall back to standard batch job behaviour? What is the
rational for newly restricting JCL permission in a batch job? JCL has
not historically depended on being APF authorized in a non-TSO batch
job.

Tony H.

Tony H.

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

Re: z/VSE Connector Client

[Tony Harminc]

On 7 November 2016 at 01:32, Timothy Sipples  wrote:
> Paul Allen, Bill Gates, and Monte Davidoff famously created their first
> BASIC compiler in 1975 for the MITS Altair machine without having an
> Altair. They had to write an Altair emulator first then code on top of
> that. Then Paul Allen flew to MITS in New Mexico to run his very first
> test. They forgot to write the bootstrap code, so he had to write it during
> the plane ride. Coding to the z/VSE Connector Client should be a lot
> easier. :)

Whereas when, not many years ago, a small company wrote an emulator
for IBM's z Architecture machines, IBM sent them a threatening letter
complaining of (mostly bogus) patent violations. :-(

Tony H.

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

Re: JES2 Mods

[Tony Harminc]

On 7 November 2016 at 12:50, Larry Martin  wrote:
> Our system has a lot of JES2 local modifications and among them is an old 
> package named J/TIP (from Univ. of Illinois Chicago).  When applying our last 
> maintenance the SYSAFF= function on the JOBPARM card stopped working.  I 
> think that the J?TIP mods are involved.
>
> Has anyone seen anything similar?  Is anyone else still using J/TIP.

Wow! I last played with JTIP in 1979 or 1980. My mind boggles at the
thought that it would still work on a current JES2, given the coding
changes in both style and detail over the last 35+ years. IIRC there
were large inline updates to JES2 mainline code, and fitting them back
then to a system that already had signficant mods was a lot of work.
Has that all been moved to exits, or are you still fitting and
refitting...?

Tony H.

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

Re: Implementing ICSF - FOTS1949 PRNG is not seeded

[Tony Harminc]

On 19 October 2016 at 12:10, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> Ouch!  But there's a widespread belief that availability of encryption is a 
> security threat.
>
> I used to read that France much restricted use of encryption.  Nowadays
> that would seem to prohibit iPhones and much limit E-commerce.

OT, but the "You are now in France" attack, followed by the "You are
still in France" attack, was a hot topic in 1998-1999.

http://catless.ncl.ac.uk/Risks/19/74#subj8  You are now in France
http://catless.ncl.ac.uk/Risks/20/17#subj1  France allows strong crypto
http://catless.ncl.ac.uk/Risks/20/20#subj8  You are still in France

Tony H.

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

Re: Language Environment LIBVEC layout?

[Tony Harminc]

On 20 October 2016 at 08:47, Tony Thigpen  wrote:
> If you are a vendor, you should have access to the LE vendor manual. Some of
> the pointer locations can be deduced from it. If you are not a vendor, you
> don't have access to the manual.

The LE Vendor Interfaces manual, SA38-0688 is no secret. It's part of
the standard collection of LE books. It's also the book that Pete just
mentioned in its KC version.

Unless you know of some other *truly secret* LE Vendor book...

Tony H.

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

Re: diagnose 8 / interesting dilemma

[Tony Harminc]

On 18 October 2016 at 13:15, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>   I find:
> z/OS 2.2.0
> z/OS MVS
> z/OS MVS Programming: Assembler Services Guide
> Understanding 31-bit addressing
> Understanding the use of central storage
> Central storage considerations for user programs
> Load real address (LRA) instruction

As suggested, you need to look at the Principles of Operation. LRA is
a matter of hardware, not MVS. Of course the MVS environment
potentially affects some things, but LRA is entirely defined by the
hardware.

> Woe be unto anyone who did LRA; LA in AMODE 24  (But why?.  And it
> doesn't discuss AR mode.  Perhaps elsewhere, but my curiosity is exhausted.

POO.

> Which leaves a historical question.  Was AMODE 31 antedated by the
> availability of real storage >16 MiB,

Assuming you mean the hardware addressing mode, rather than the MVS
Assembler and Binder's notion of AMODE for modules, Yes. But in a
quirky way. In the pre-XA era, there was a time when 64 MB of real
storage could be addressed by DAT tables, but not by channels or
instructions running with DAT off.

> or was AMODE 64 antedated by the availability of real storage >2GiB?

How is this an "or"? You sound like a lawyer at bar: "My client did
not kill Mr X, or in the alternative, if he did kill Mr X he did it
with justification." Maybe I just need to apply De Morgan to your
sentence...

> How did LRA(G) operate in those eras?

LRA provided a 26-bit real address (padded on the left to 32 bits) in
the 64 MiB era.

> And in a virtual guest with shadow page tables, does LRA return the
> real real address or a virtual real address?

Always a virtual real address.

> I suppose it's all emulated by CP anyway, so it depends.

No, it doesn't depend. What sense would it make to return a real real
address to LRA? If you want a real real address you need to use a
conceptually different level of query; a meta-query, one might say.
Normally this would be a Diagnose.

> Or maybe SIE.  My head hurts.

With (XA+) or without (370 pre-XA) SIE, the result is the same. With
SIE it's all handled by the "hardware". Pre SIE, since LRA is
privileged, and the guest always runs in real problem state, CP
provides the answer.

Tony H.

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

Re: Is LLILF effectively "Grande"?

[Tony Harminc]

On 21 October 2016 at 10:48, Charles Mills  wrote:
> Got it! Thanks all. I will add a comment where I use it.

Also a good place (well, everywhere is a good place) to be using HLASM's
TYPECHECK(REGISTER) option, which is anyway the default. Not that it
replaces a comment, but the mere fact that you are using a register name
like G4 or GR4 or whatever rather than R4 tends to make the point when
reading the code. And if you fail to do so...

  LocObject Code  Addr1Addr2Stmt  Source Statement
0004   1 G4   EQU4GR64
0004   2 R4   EQU4GR32
 C04F  3039    4  LLILF  G4,12345
0006 C04F  3039    5  LLILF  R4,12345
** ASMA323W Symbol R4 has incompatible type with general register field


Tony H.

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

Re: CSVDYNEX in IPCS?

[Tony Harminc]

On 21 October 2016 at 09:02, Peter Relson  wrote:

> >Is there IPCS support, e.g. VERBX or toolkit or the like for chasing
> >and displaying the kind of information that can be obtained on a live
> >system using either CSVDYNEX REQUEST=LIST or the console D PROG,EXIT
> >command?
>
> Not that I know of.
>
> Someone in IBM L2 might well have an exec to do that, but it is not
> provided with z/OS (or with the tools-and-toys execs that you can access
> via IPCS 2.6i).


Thanks, Peter. I don't suppose the necessary control blocks are documented,
are they? I'm not seeing any CSV CBs (other than calling argument lists) in
MACLIB or MODGEN or in the Data Areas. :-(

If you maintain a list of would-be-nice items for IPCS 2.6i, maybe this
could be added for consideration. When we get a dump from a customer for a
situation that suggests an exit of ours wasn't running, and it's too late
to issue the D PROG, EXIT, then it would be great if we could find out if
the exit is there, or another exit is configured to suppress its return
code, or what...

Tony H.

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

Re: When does compare-and-swap-and-store facility 2 come along?

[Tony Harminc]

On 21 October 2016 at 13:41, Charles Mills  wrote:

> PSA and the IHAPSA macro alphabetized in MVS Data Areas under P. IHAPSAE
> alphabetized under I. No wonder I'm confused.
>

A long standing problem with a number of control blocks. Perhaps an
index...?  Yeah, I know - just search in KC.  :-(

Tony H.

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

CSVDYNEX in IPCS?

[Tony Harminc]

Is there IPCS support, e.g. VERBX or toolkit or the like for chasing
and displaying the kind of information that can be obtained on a live
system using either CSVDYNEX REQUEST=LIST or the console D PROG,EXIT
command?

I'm thinking I've seen it in there somewhere, but right now I'm not
finding anything.

Thanks!

Tony H.

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

Re: Does >4K PGFIX make sure the frames are contiguous? (was: diagnose 8 / interesting dilemma)

[Tony Harminc]

On 18 October 2016 at 18:27, Peter Hunkeler  wrote:
> Below discussion triggered a question I could not answer by RTFM. I had never 
> thought about this before in this detail,
> but now that I do, I wonder if the following is correct.
>
> Program allocates >4k of virtual storage. The real frames backing it may or 
> may not be contiguous. The program wants to
> use this area with some interface (I/O, etc) that will use real addresses 
> when accessing the storage, so it does a PGFIX.
> PGFIX would move the possibly non-contiguous frames guaranteeing the area is 
> backed by contiguous frames. After all,
> the interface using real addresses would expect the the frames to be 
> contiguous.
>
> Am I wrong? I would have expected to find this documented with the PGFIX or 
> PGSER FIX macros, but did not find it.

I do not believe there is such a service documented. As Jim Mulder
pointed out, there are 1M pages available above the bar, but that's
relatively new stuff. And there are unexposed RSM services to manage
pairs of frames (and quads, I think he said).

If you want to do I/O to your real storage, that is what IDAWs are
for. Perhaps there are undocumented (or at least not publicly
documented) IBM facilities -- I'm guessing things like crypto,
compression, newer non traditional I/O -- that take real addresses and
need more than a page at a time, but I don't know of any. In this
sense, VM's Diagnose interface is an outlier.

Tony H.

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

Re: REXX determine library that is executed from

[Tony Harminc]

On 22 November 2016 at 13:52, John McKown  wrote:
> Just to be my normal weird self, none of this will work in a REXX exec is
> run by reading it / creating it dynamically in memory and passing the
> in-memory EXEC to IRXEXEC.

Well, for some value of "none of this will work". If you are invoking
an EXEC that you have loaded into memory then it is your
responsibility to supply the info for Parse Source in the EXEC_BLK.
Put the appropriate info into into fields EXEC_DSNPTR and EXEC_DSNLEN.
In my experience you don't have to follow any particular rules, i.e.
it doesn't have to look like an actual DSNAME as long as it doesn't
exceed 54 characters. If that's not enough, you can pass up to 4096
characters in EXEC_EXTNAME_PTR, EXEC_EXTNAME_LEN. I have not played
with these latter fields.

Tony H.

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

Re: A true discussion in today's world (at least here)

[Tony Harminc]

On 23 November 2016 at 12:33, Jesse 1 Robinson  wrote:
> When I get flak about the churn of staying current with maintenance, I climb 
> my soapbox. Look, I say, I've calculated that on balance it's cheaper to 
> drive your car as long as it runs rather than take in for periodic 
> maintenance, which is both time consuming and out-of-pocket costly. Most 
> likely it will fail somewhere down the road ;-) but getting it fixed then 
> will be cheaper and quicker overall.
>
> Well, I say, if you wouldn't think of managing your car that way, why would 
> you think it makes sense for a computer system?

The analogy is cute, but I think it fails The problem is that in some
circumstances that's a perfectly reasonable way to manage a car.
Depending on the age, how much you depend on it, whether you ever
drive a significant distance from home, etc. etc. there may be nothing
wrong with deferring or not doing some maintenance.

I live in a city, mostly walk or use transit, and I have very little
need for reliability in a car. So generally on my cars I do oil
changes and have safety systems (e.g. brakes) inspected and serviced
*as necessary*, but otherwise I do "drive it as long as it runs". This
works for me and the way I use a car; obviously not so well for
someone who lives in a rural area, drives a long commute to work,
and/or has no easy backup options for transport.

There is even a credible argument that many kinds of so-called
preventative maintenance cause more harm than good. For example,
taking apart and repacking a wheel bearing on a routine periodic basis
may well cause earlier failure than leaving it alone. It depends.

If you want the best possible reliability from a car (which is not, of
course, the only reasonable goal), probably the semiconductor
"bathtub" curve roughly applies: you should buy one that is past its
"burn-in" period, but not too much, and then keep it only until some
time before it reaches its predicted wear-out failure rate increase.
I'm guessing these numbers would be perhaps 3 months and 24 months, or
equivalent distance travelled, respectively.
https://en.wikipedia.org/wiki/Bathtub_curve   But little if any of
this applies to software.

[There is a lot of stuff on Google about maintenance and cost/benefit
analysis as applied to various kinds of hardware, typically industrial
machinery and of course aircraft. Unfortunately a great deal of it is
written by people whose business it is to sell the benefits of PM, so
it takes very careful reading, even of academic articles.]

There's also a very good argument that calling software fixes and
their application "maintenance" is a logical or category error.
Software does not "wear out" the way hardware does, and it also cannot
be replaced to solve a problem (at least in the sense of installing an
identical new copy as you can with a car or an aircraft engine), but
rather *must* be fixed.

Please note that I am *not at all* saying that routine fixes should
not be applied to software, or that the management attitudes you
complain of are good. It's the analogy I'm quibbling with, not good
software practice.

Tony H.

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

Re: Which STEPLIB concatenation is not authorized?

[Tony Harminc]

On 18 November 2016 at 06:26, Charles Mills  wrote:
> As a software vendor, on new installs we often get customers saying "your
> product puts out a message saying it is not authorized but we're sure we
> authorized the library" and it is often a painful process taking them
> through checking each concatenation.
[...]
It's been an interesting discussion. But may I ask why you are in the
position of having your customers with a big pile of datasets in their
STEPLIB concatenation for your product? Well, you didn't say it's a
big pile, but if were one or two you surely wouldn't be asking...

Tony H.

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

Re: LRECL=255 vs LRECL=259

[Tony Harminc]

On 15 November 2016 at 13:59, Ed Jaffe  wrote:
> Of course, my personal observations and experiences provide nothing more
> than anecdotal evidence. Like a man with two watches being unsure of the
> time, I am now unsure if LRECL=259 is widespread practice or if I was
> observing only outliers.

My 40ish years of anecdotal evidence suggests 255.

But does it matter much? Concatenating or copying between VB 255 and
VB 259 should "just work" in almost all cases, whereas trying to mix &
match either of those with FB 80 is trouble.

Tony H.

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

Re: How set CVTLSO?

[Tony Harminc]

On 31 October 2016 at 09:04, Giliad Wilf
<00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:
> Atomic clock ticks at an absolutely constant rate of some 9192631770 
> oscillations
> per second (Cesium-133 atom oscillating between two energy ground levels),
> while Earth sidereal day gets slower(*) by 1.4 milliseconds a day per century.
> This lagging behind accumulates over time and mounts to almost a complete
> second over approx. 500 days.

I'm a little confused about what kind of units "1.4 milliseconds a day
per century" would be in.

Tony H.

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

Re: Rexx and hex data strings

[Tony Harminc]

On 27 October 2016 at 12:56, Itschak Mugzach  wrote:
> What I am trying to reference a comment block in a rexx program. The
> SOURCELLNIE() function does work, including if program is compiled.  Still
> have a problem with some odd number of '/*' or '*/' that may be included in
> the text, but I can manage that by replacing it the another pair of
> characters.

You might do better to safely encode the binary (hex) data using
something like BASE64. This is easy, though it does enlarge the data
by a factor of 1.3...

Tony H.

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

Re: How set CVTLSO?

[Tony Harminc]

On 2 November 2016 at 17:03, George Kozakos  wrote:
>>Not any computer systems I work with. They use either 1900 or 1970
>>as their epoch. What uses 1972?
>
> The "epoch" on z/OS systems is 1900.

The TOD epoch is 1900. The UNIX epoch -- z/OS UNIX or any other -- is 1970.

Tony H.

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

More Knowledge Centre frustration

[Tony Harminc]

(Or Knowledge Center, I suppose)

Can it really be the case that the zArch Principles of Operation is
not there? Certainly there are links to various apparently arbitrary
levels of the PDF, but the content itself doesn't seem to be in there.
Here's a case where I'd like to take advantage of one feature of KC
that actually sounds useful, and provide a URL to a specific paragraph
in the POO to someone else to explain what I'm talking about, rather
than say "find the PDF and then navigate to the section called "blah",
and look down two paragraphs. No such luck, it seems.

As well, when I do a "product" search, it seems that no variation on
"system z", "z systems" or "z arch" finds anything remotely related to
the POO. And a general (not product) search on KC for the string
"z/architecture principles of operation" (which is the exact title of
the book) says "Your search query did not match any documents. Try
modifying the search keywords or filters.".

Come on, folks!

Tony H.

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

Re: How set CVTLSO?

[Tony Harminc]

On 1 November 2016 at 13:44, Giliad Wilf
<00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:
> On Tue, 1 Nov 2016 13:03:27 -0400, Tony Harminc <t...@harminc.net> wrote:

>>I'm a little confused about what kind of units "1.4 milliseconds a day
>>per century" would be in.
>>
>>Tony H.
>>
> This means that  every 100 years, the day gets about 1.4 thousandths of a 
> second
> longer, compared to the length of the day measured the moment atomic clocks
> became available commercially, at 1957, and since then, 36 leap seconds were
> counted.

Sure - I understand what's going on. It's just that, typically, one
can "see" the nature of the units involved in such a statement. Often
enough, when some politician or news reporter makes a statement like
"Ontario exported 2.5 GW of electricity last year", or "an electric
kettle uses about 1.5 kWh", the meaninglessness jumps right out
because the units make no sense in the context.

And in the familiar case where the numerator is in a length unit (say,
m), and the denominator in a time unit (say, s), we have names for
each level: distance, speed, acceleration, jerk.

In this case we have time/time/time, which just fails to jump out at
me. Maybe my imagination, visual or otherwise, is lacking.

> The epoch being used in computer systems is 1972, with 26 leap seconds 
> counted since then.

Not any computer systems I work with. They use either 1900 or 1970 as
their epoch. What uses 1972?

Tony H.

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

Re: ABO Automatic Binary Optimizer

[Tony Harminc]

On 13 October 2016 at 06:41, Timothy Sipples  wrote:
> OK, about testing. For perspective, for over two decades (!) Java has
> compiled/compiles bytecode *every time* a Java class is first instantiated.

That seems a little, uh, optimistic. The Java Programming Language
book, and the corresponding Java Virtual Machine Specification, first
editions, were both published in 1996. Did IBM even have a mainframe
Java at that point (beyond perhaps compiling Sun's published C code on
MVS), let alone one doing JIT optimization?

> The resulting native code is model optimized depending on the JVM release
> level's maximum model optimization capabilities or the actual machine
> model, whichever is lower. Raise your hand if you're performing "full
> regression testing"(*) before every JVM instantiation. :-) That's absurd,
> of course. I'm trying to think how that would even be technically possible.
> It'd at least be difficult.
>
> ABO takes the same fundamental approach. From the perspective of an IBM z13
> machine (for example), ABO takes *COBOL* "bytecode" (1990s and earlier
> vintage instructions) and translates it to functionally identical native
> code (2015+ instruction set). It's the core essence of what JVMs do all the
> time, and IBM and others in the industry have been doing it for over two
> decades. Except with ABO it's done once (per module), and you control when
> and where.

Well... Sort of. Seems to me the problem is that while the JVM
instruction stream is architected as a whole (i.e. it's not just the
definition of what each instruction does, but an entire Java class
that must match the specs), the output of an old COBOL compiler can't
be said to be architected like this. (Probably there is some internal
doc describing what the compiler generates (and of course the old
compiler source code is definitive) but I'm willing to bet that it's
nowhere close to the standards of any generation of the Principles of
Operation.) The Principles of Operation defines very accurately and
completely what each instruction emitted by the old compiler does, but
lacks any notion of larger groupings along the lines of Java class
files. But the ABO product is certainly not just translating
individual old instructions into newer ones. Rather, it is surely
identifying COBOL paradigms based on some kind of pattern matching,
and then retranslating those COBOLy things into modern machine code.
Presumably it effectively reverse engineers the byte codes (whether
back into COBOL, or much more likely into an intermediate
representation that is already accepted by later stages of the modern
compiler middle or back end) and generates a new object module. If it
really was just converting old instructions into better performing
modern ones, the input would not be constrained to be COBOL-generated.
Any object code could be optimized this way.

This all says that the analogy between converting Java bytecodes into
native instructions and converting old COBOL object code into modern,
is weak. And it follows that the need for testing isn't the same.
There is much more to go wrong in the ABO process than there is with
JITing Java.

Tony H.

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

Re: ABO Automatic Binary Optimizer

[Tony Harminc]

On 13 October 2016 at 14:47, Bill Woodger  wrote:
>
> No, it doesn't turn the machine-code (ESA/370) into anything intermediate.

Are you quite sure?

> Yes, it knows something of the internals, and yes it knows things it can and 
> can't do with that knowledge.
>
> "There is much more to go wrong in the ABO process"
>
> Why, and with what supporting information?

As I said, the JVM class file format is extremely well documented, and
was designed to be interpreted and verified. The output of various old
COBOL compilers much less so. Well, no, I don't have the negative
supporting evidence (lack of doc on the COBOL object code), but I'm
willing to bet...

To be clear, I think ABO is a great idea with great potential. And
probably it works really well. But if worked at a bank or insurance
company, I wouldn't be quick to say "oh it's still the same program,
it'll work fine, just bang it into production".

Tony H.

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

Re: intermittent errors using FTP program Interface EZAFTPKS

[Tony Harminc]

On 9 October 2016 at 20:03, Charles Mills  wrote:
> I would guess you could invoke SUBMIT from an assembler program but the
> obvious and simple way to submit a job from within a running program is to
> write the JCL to a QSAM dataset allocated SYSOUT=(,INTRDR). That is what
> SUBMIT does under the covers.

SUBMIT surely uses the VSAM-like (RPL) JES interface so that it can
get the jobid upon ENDREQ, which it reports to the user. Not that QSAM
doesn't work just fine, but there is no direct way to get the jobid as
part of submitting.

Tony H.

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

Re: Changing the primary AUTHID using RACROUTE

[Tony Harminc]

On 12 October 2016 at 18:25, Janet Graff
<004dc9e91b6d-dmarc-requ...@listserv.ua.edu> wrote:

> I changed the TERMID to point to a D'0' but I'm getting the same error message
>
> ICH408I JOB(JIGRACF ) STEP(RUN )  944
>   LOGON/JOB INITIATION - USER AT TERMINAL  NOT RACF-DEFINED
> IRR012I  VERIFICATION FAILED. USER PROFILE NOT FOUND.
>
> Which I think implies that it thinks I'm a terminal user, even though it has 
> binary zeros for the TERMINAL value in the ICH408I message.

It *does* think you're a terminal user, but that's because you used
TERMID= in the first place. Just don't specify it at all. If you
specify it as D'0', RACINIT (invoked by RACROUTE) will generate a
non-zero pointer to it, and then it will get mentioned in any
messages, and possibly used as part of logon checking. But as Walt
points out, the problem is not with the TERMID, but with the userid.
One could argue that the ICH408I message is a bit unclear, but it's
the standard "userid not found" that happens to mention the (null)
terminal name in passing.

Also... These are problematic if they are this way in your actual
source. (Of course I understand you may have posted an abbreviated
example here):

 MVC   USERLEN,8
 MVC   USERID,=CL8'MYUSER   '
 MVC   PSWLEN,8
 MVC   PASSWD,=CL8''

Those two length MVCs should almost certainly be MVIs. Or you can use
MVC with =FL1'8' if you prefer. (While you're there, turn on the HLASM
option "PAGE0". I know it has saved me much debugging angst, and it
may do the same for you some day even if this isn't part of the
current problem.) And the length you tell RACF for the userid (and
password, for that matter) must match the actual userid's length - not
that of the blank-padded field it's in.

> Also I suspect I might be archaic by using RELEASE=1.9.2, is there a more 
> appropriate value for this decade?

I've been using 7730 for some time. Certainly 7730 is of this
millennium, but it's probably time that I looked into its antiquity
too.

Tony H.

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

Re: System REXX and UNIX

[Tony Harminc]

On 12 October 2016 at 13:56, Kirk Wolf  wrote:
> You are correct: you don't need an LE environment to use the BPX kernel 
> service calls.

Indeed. I do it from non-LE assembler all the time.

> REXX doesn't have/use an LE environment AFAIK. I don't know
> much about the System REXX environment, but I would assume kernel service
> calls would work fine.   The REXX SYSCALL environment uses these, so I'm
> not sure why it wouldn't work.

I think the problem will come if there's a question of file access
permissions. For that the kernel has to ask RACF/ACF2/TSS, and that
requires a userid, which may not always be present, or may not have a
UNIX UID, GID, etc. Depends on how it's invoked, I think.

Tony H.

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

Re: ABO Automatic Binary Optimizer

[Tony Harminc]

On 14 October 2016 at 02:30, Timothy Sipples  wrote:

> No, not optimistic. Mere fact. Sun Microsystems made Java 1.0 generally
> available for download on January 23, 1996, for the Windows 95, Windows NT,
> and Solaris operating systems (three different operating systems across two
> different processor architectures). That was over two decades ago.

We're not debating the existence of Java in 1996. What you said that I
disagree with is this:

 >For perspective, for over two decades (!) Java has
> compiled/compiles bytecode *every time* a Java class is first instantiated.
> The resulting native code is model optimized depending on the JVM release
> level's maximum model optimization capabilities or the actual machine
> model, whichever is lower.

This just isn't correct. The Java made available by Sun in 1996 was a
pure interpreter. They wrote C code to implement a JVM, and the
related (and in fact much larger) baggage of class loaders and such.
This C code could be compiled for just about any architecture, but it
did no converting of JVM bytecodes into native instructions. It was a
lot like the many interpreters that existed for decades before, such
as UCSD Pascal's P-code, and a number of offerings from IBM and many
others ( APL, CPS-BASIC and CPS-PL/I), TSO classic CLISTs, Rexx, and
more. In pass 1 source code is converted into some kind of internal
representation, and in pass 2 that representation is then interpreted
by native code. What the intermediate form looks like with respect to
the source language differs. Either it's a lot like the source,
cleaned up for easier machine processing (CLIST, Rexx, most BASICs),
or it's more of an easy-to-interpret virtual machine (UCSD, JVM), but
by definition it's not the native instruction set of the eventual
target machine. Sun's JVM, as documented in the 1996 book, did define
some pseudo-ops for performance reasons, but they were entirely
optional and in no way can be called compiling (JIT or otherwise).

Back in 1996, while I'm sure there were bright people thinking about
JIT compilation of JVM bytecodes into existing instruction sets, the
more general musing (in the Sun JVM book, even) was about building
hardware to directly execute -- rather than interpret --  JVM
bytecodes. That didn't happen in any commercial way to my knowledge.

> Java isn't the earliest example of a bytecode-to-native technology. IBM's
> Technology Independent Machine Interface (TIMI) proved the concept much
> earlier. TIMI traces its roots to the IBM System/38 introduced in August,
> 1979.

I'd say its roots go much further back to the failed Future System
(FS), that Lynne Wheeler has mentioned here many times.

> The latest TIMI technologies are found in the IBM i platform, another
> platform deservedly famous as a stable, reliable home for applications.
> Before program execution (just before, if necessary) TIMI automatically
> translates the bytecode to native code tailored for that particular
> hardware model environment, persists it, and runs it.

You're describing the Original Programming Model (OPM), which has
largely been deprecated in recent years in favour of compiling
directly into native (p-series) instructions, probably via some quite
different intermediate representation.

> TIMI is arguably even closer to ABO conceptually than Java is.

Sure. It wouldn't surprise me at all to find that the intermediate
representation used by ABO is the very same one used on the IBM i.
Certainly ABO and the IBM i compilers all come from the same lab.

Tony H.

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

Re: diagnose 8 / interesting dilemma

[Tony Harminc]

On 17 October 2016 at 13:47, Jim Mulder  wrote:

>  There is IARV64 GETSTOR with TYPE=FIXED and PAGEFRAMESIZE=1M.

It's perhaps not 100% clear how it uses the 64-bit registers, but z/VM
does seem to support AMODE 64 for the caller of Diagnose 8, so I think
this could work. I suppose these days a megabyte of fixed storage here
or there doesn't count for much.

Of course there's the question of whether z/VM yet supports the large
pages (EDAT-1) needed to make this work. I don't believe it does as of
6.3, though I may have missed an announcement.

Tony H.

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

Re: How to Identify modules as C/C++ or Cobol, or ASM from dump (SYSMDUMP)

[Tony Harminc]

On 29 November 2016 at 05:00, Peter Hunkeler  wrote:
> My problem is to find which of the 500+ are C/C++ modules. So far I could not 
> find a way to determine this from the dump. LE remembers which runtime 
> environments (Cobol, C/C++) are active because some such code has been active 
> in the enclacve. So I'm hoping that LE keeps some kind of list of modules 
> loaded by "type", i.e. the various languages it supports.

I'm probably not understanding the question, because I know you know a
bunch about this (probably more than I do). If you know the entry
point of each of these modules, you should be able to chase down the
language ID from the PPE and such. Whether you can compose a RUNCHAIN
for it is doubtful, but a little bit of REXX shouldn't be at all hard.

If you want the layout, I can post it. No secret - it's in the LE books.

Tony H.

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

Re: JES2 Changes in z/OS V2.2 - Presentation from 2015

[Tony Harminc]

On 6 December 2016 at 10:40, Lizette Koehler 
wrote:


>JES2 Growth: Grow from 400K to 1M Active jobs


It seems such a short time ago that job numbers had three digits... You
could purge everything with $PJ1-999 .

Tony H.

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