Re: UTF-8 woes on z/OS, a solution - comments invited

[Andy Wood]

On Tue, 5 Sep 2017 22:30:59 +0800, Timothy Sipples  wrote:

...
>you can do what the Japanese have done for decades: Shift Out (SO), Shift
>In (SI).

ZCZC
DECADESQUERY


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

Re: IEFUTL Woes

[Andy Wood]

On Sat, 15 Apr 2017 12:51:58 +0100, Jeremy Nicoll 
 wrote:

>On Fri, 14 Apr 2017, at 18:05, Andrew Metcalfe wrote:
...
>
>Ages ago I worked in an installation that allowed TSO users to get one
>extension to 
>the timeout provided they themselves locked their screens.  The program
>that did 
>it issued a fullscreen TPUT saying it was locked (& named the userid and
>SMFID of
>the locked session - so that people logged into multiple systems could
>unlock the 
>right one as needed).   Password validation was in our case done by ACF2
>and the
>lock program also counted failed password uses and forced sessions to
>end if some
>user was trying to guess someone-else's password.
>
>At the point where a user's screen was locked by this program, a small
>flag block was 
>hung of the TCBUSER field of the job-step TCB.  If that couldn't be set
>up in the expected
>way the user just got 522ed.  Normally the flag block would contain
>'TSOLOCK' literals
>(so easily found in a dump) and a count field.  IEFUTL would look to see
>if a user had such
>a flag block, and if so if they'd not yet had too many timeout
>extensions.  If the block was
>there and the count low, it'd be incremented and they'd stay logged in. 
>Otherwise they'd
>get 522ed.
>
>
>So... could you in login processing attach a subtask that is a program
>that waits until some
>external trigger causes it to lock the user's screen?  Then when IEFUTL
>runs, identifies an 
>address space as a TSO user, checks some flag (stored off TCBUSER,
>maybe, or via name & 
>token services), to see if they are one of this special class of users,
>and if so either post the 
>ECB or 522 them.

I have a very distant memory of a similar LOCK command which IIRC avoided S522 
without requiring IEFUTL collusion, by simply waking up often enough. I sort-of 
recall that it took a bit of care to prevent being able to break out of the 
locked state by rapidly hitting ATTN.

I see a similar command, LOCKTERM in CBT file 183. That also does not require 
any assistance from IEFUTL because it sets ASCBTOFF (I'm not going to pass 
judgement as to whether that is a good idea).

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

Re: 0C4, 071, 822 abends in IEFACTRT after zOS 2.2

[Andy Wood]

On Thu, 30 Mar 2017 14:48:24 -0500, Joel M Ivey  wrote:

>I mis-spoke.  At the time of my first post we had NOT moved the fresh copy of 
>IEFACTRT from cbt109 into production.   We did this past weekend and  S071 
>abends were resolved.   (You were correct, the USING R15 was absent in the old 
>IEFACTRT.)   However, the 0C4 abends stlil occur within certain address spaces 
>with high utilization.   Also on these address spaces the output gets garbled: 
>  (Also notice the comma in front of EXCP TOTAL.)
>. . .

The problem in the recovery routine will only show up if some other abend 
causes it to be entered. Support did tell you that the recovery routine was 
entered because of a prior 0C4, but I don't know if they also said anything 
about the cause of the 0C4. 

As nobody else seems to have had this problem with the CBT109 IEFACTRT, you 
will have to look at what caused the 0C4. 

I took a very quick peek at the code in the CBT109 IEFACTRT that formats the 
EXCP TOTAL, and it appears that the leading comma is due to the 8 byte field in 
the line being too small for the value (it EDITs the value into a larger field, 
then moves only part of the result into the message, losing some of the 
high-order digits). I don't see a potential 0C4 there, but I might have missed 
something. I also don't know if the value it was tying to display is actually 
correct, but EXCP total could easily be greater than 999,999. Perhaps this has 
been happening for years but nobody noticed it.

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

Re: 0C4, 071, 822 abends in IEFACTRT after zOS 2.2

[Andy Wood]

On Fri, 24 Mar 2017 14:26:14 -0500, Joel M Ivey  wrote:

. . .
>+972 4140 0004 
>+976 1904 
>+978 4770 C986 <- 
>+97C 5802  
>+980 41F0 0004 
>+984 07FE 
>

I don't have the luxury of your assembly listing, but the ESTAE in the source 
code from cbttape.org looks like this:

RECOVERY DS0H   0844
 USING *,R15  SET UP ADDRESSABILITY 0845
 LAR4,4   PUT 4 IN REGISTER FOR COMPARE 0846
 CRR0,R4  IS SDWA PRESENT?  0847
 BNE   HAVESDWA   YES, BR TO PROCESS WITH SDWA  0848
 L R0,0(R2)   LOAD RETRY ADDRESS FROM PARAM LIST0849
 LAR15,4  SET RETCODE TO RETRY ADDR IN R0   0850
 BRR14RETURN TO PROCESSOR WITH RETRY ADDR   0851
HAVESDWA DS0H ENTER HERE IF SDWA PRESENT  

That code mirrors what support found, *except* it would appear that it is 
assembled from code which has the "  USING *,R15 " statement missing (in the 
object code, the BNE instruction is using R12, which is a mainline base 
register, not R15 as it should).

That makes me think that for some reason you are perhaps  *not* executing the 
version of IEFACTRT that you think you are, and that installing a new one, from 
SAMPLIB or elsewhere, is not going to help you until you figure out exactly why 
that is happening.  For a start, check your listing. You might have received a 
warning about an overlapping USING, but I think the correct code should still 
have been generated in this instance for the BNE instruction.

Over the years I saw problems like this many times when recovery (or retry) 
routines made unwarranted assumptions about the content of certain registers, 
particularly base registers, and the warning about the possibly dire 
consequences is justified. One such case is still firmly etched in my memory, 
well over ten years later - the wild branch there happened to take it part way 
into an instruction, which unfortunately was executed as a perfectly valid LCTL 
instruction. The results of loading rubbish into half of the control registers 
is not pretty.

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

Re: Fujitsu Mainframe Vs IBM mainframe

[Andy Wood]

>My €0.02:
>There are (were) both: hardware and OS software.
>
>Software: IBM OS/390, Fujitsu MSP, Hitachi VOS and AFAIK Siemens (don't 
>remeber the name)
>The clones were very similar, but not the same.
>
>Hardware: you could run IBM OS/390 on Hitachi or Amdahl machine, it was 
>both feasible, and legal (allowed by IBM).
>(in the older days the number of HW clones was higher: ITEL, Olivetti, 
>Comparex, etc.)
>
>-- 
>Radoslaw Skorupka
>Lodz, Poland
> ...

I believe Siemens at one time sold a system derived from the RCA Spectra.

I encountered the RCA Spectra in the guise of an ICL (English Electric) System 
4. I wrote assembly code for that which from my point of view was identical to 
S/360 assembly. 

The operating system, about which I knew very little (and now recall even 
less), must have been quite different because the machines had several 
interrupt states each with its own set of GP registers. No chance of running an 
IBM operating system on one of those. 

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

Re: TV news just now

[Andy Wood]

I am reminded of an occasion when trying to find some information about a 
certain well-known product, and I turned up a page that I needed to ask Uncle G 
to translate for me. 

The result was full of references to "Evening Aid / MVS".

Goodnight, Herr Abend.

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

Re: Error in a simple COBOL program

[Andy Wood]

On Wed, 13 Jul 2016 18:08:46 -0500, Bill Woodger  wrote:

> "IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
> unsuccessful."

That message is indeed specific, but it does not exactly scream out "... expect 
operation exception to follow this message."

> Program outside of TSO then gets an LE User Abend (U4038). No S0C1.

Cameron, the person with the original problem, got the S0C1 when running the 
program under TSO.

Frank, who was kind enough to recreate the situation, did not get the S0C1 but 
was running it as a batch job.

As far as I can see, and this is perhaps where I missed something, Cameron did 
not try the program in batch, and nor did Frank try it under TSO.  

Myself, I would not spend much time on it, but I wouldn't just ignore it 
either. But, enough said. 

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

Re: Error in a simple COBOL program

[Andy Wood]

On Wed, 13 Jul 2016 00:51:41 -0500, Bill Woodger  wrote:

> The S0C1 with that exact set-up does not "normally" happen in COBOL (by which 
> I mean,
> by COBOL running in batch).
>
> COBOL programs are not "normally" run under TSO.

You may consider it to not be normal, but there is no reason that Cobol 
programs cannot run under TSO, with or without ISPF. If you look in the right 
places, you will even find IBM-provided examples.

> There is an explicit run-time message which explains the issue.

I missed that message.

If you mean:

> Abend 0C1000 hex occurred processing command 'CALL'. 

I would interpret that as meaning that the CALL command, or, more likely, the 
program invoked by the CALL command, suffered a S0C1. That is not much of an 
explanation.

On the other hand, if you mean this message:

> CEE3201S The system detected an operation exception (System Completion 
> Code=0C1).  

That also does not explain much. Given it is an LE message, and the CALL 
command itself does not use LE, it perhaps gives support to my supposition that 
something below the CALL command is the likely source of the S0C1. Down a few 
notches in the levels of probability - perhaps there was more than one S0C1.

> The S0C1 is unexpected. 

No argument there.

> It is some artefact of running that program under TSO. 

Possible, but I don't see anything to prove that.

> It was easy to miss not through ignoring it because it always happens, but 
> through not hunting for something additional when you hit a message stating 
> the exact cause. 

I still have not hit that message. Where is it?

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

Re: Error in a simple COBOL program

[Andy Wood]

On Tue, 12 Jul 2016 00:04:15 -0500, Bill Woodger  wrote:

. . .
>
>There are no S0C1s from COBOL IO. 
>

For the reason that I explained previously, a missing DD statement can cause 
S0C1. As far as I am concerned, that should never happen, but I know it is an 
easy mistake to make in assembly code, where one has to explicitly check that 
the OPEN worked. Some OPEN errors cause Sx13 abends, but OPEN does not issue an 
abend for a missing DD.

I don't expect the same S0C1 from Cobol, and I pointed out that Cobol obviously 
does check that OPENs work, because it produced a message saying that the OPEN 
was unsuccessful. So, if that did not cause the S0C1, what did?

I guess I was just wondering if everybody was so conditioned to seeing a 
missing DD statement cause S0C1 that they no longer question it.

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

Re: Error in a simple COBOL program

[Andy Wood]

On Tue, 12 Jul 2016 00:29:08 +, Jesse 1 Robinson  
wrote:

. . .

> In my experience, S0C1 is the most likely consequence, I presume because some 
> location that
> should contain a valid instruction after open does not. The key to solving 
> this problem is the
> message 'file-name DD MISSING'. Figure out why that's happening, fix it, and 
> move on. 

The "traditional" cause is a program not checking that the OPEN was successful, 
and proceeding to issue an I/O request, say a PUT, to the DCB. The PUT involves 
calling a routine, the address of which would have been placed in the DCB by 
the OPEN, but which is not filled in if the OPEN fails. We can debate exactly 
what will happen as a result of this, but I think we can agree it is not going 
to end well.

Here, the IGZ0017S message clearly shows that the code does check if the OPEN 
succeeded, so you would hope that it would not proceed to try to use the DCB as 
if nothing had gone wrong. The fact that Frank did not see the same S0C1 as is 
visible in the original post here, when he recreated the situation, probably 
confirms that something else is also going wrong.

I'll agree that it is a fair bet that the S0C1 will go away then the missing DD 
statement issue is resolved, but there could be some other bug there, waiting 
for an opportunity to come out and bite.

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

Re: Error in a simple COBOL program

[Andy Wood]

On Mon, 11 Jul 2016 17:19:17 -0500, Bill Woodger  wrote:

>It's a Severe run-time error. Nothing can be done about it (except make the 
>appropriate correction). Well, possibly you could use an LE abend handler, but 
>why?
>
>Plain ACCEPT does not have a SELECT statement, so you can't specify FILE 
>STATUS. It is not a "file" to the COBOL program, I don't think you can get at 
>it with DECLARATIVES (I should check).
>
>I think you meant S0C4, not S0C1.

No, I didn't mean S0C4:

> CEE3201S The system detected an operation exception (System Completion 
> Code=0C1

Serve error or not, why confound things with an operation exception?

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

Re: Error in a simple COBOL program

[Andy Wood]

I have seen countless ABEND0C1s due to some rookie programmer not checking that 
an OPEN was successful.

Here, the code clearly does check:

> IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN was 
> unsuccessful.

Am I the only one here to question why it would then ignore this discovery? 

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

Re: TSO TEST and SYSOUTTRAP/SYSOUTLINE

[Andy Wood]

On Sun, 3 Jul 2016 09:32:18 -0400, Joseph Reichman  
wrote:

>I am basically trying to save the output of test i.e.
>Output of a test list command  into variables and compare them and based on 
>the result do a "AT"
>breakpoint command 
>
>Thanks 
>

You do know that the LIST subcommand output can be directed to a data set via 
"PRINT(...)" ?

That is something I used to do often, but never had occasion to try it from 
CLIST or REXX. It might perhaps give you some other options. 

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

[Andy Wood]

On Wed, 29 Jun 2016 13:00:10 -0500, John McKown  
wrote:

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

I'm not so sure about the extent of that.

A long time ago I had to sort out a problem in a multi-tasking utility, which 
could have several tasks, each with their own DCB, writing to the same DD, 
which was invariably allocated to JES2 SYSOUT (I don't recall trying pointing 
it to a DASD data set).

One of the symptoms of the problems was that SDSF would very occasionally get 
ABEND0C4 when browsing the SYSOUT from this utility. Later, perhaps after some 
JES2 enhancement, I think there were very occasional ABEND02As.

The solution was to wrap ENQ/DEQ around the writes to the DD in question.

I have no idea whether Java would provide any serialization. It is also 
possible that something has changed in JES2 since I encountered this issue 
(although I see one of the listed reasons for ABEND02A is "HASP access method 
detected a serialization error for a spool data set.")

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

Re: OT, funny. A good comic about "Code Quality"

[Andy Wood]

On Mon, 20 Jun 2016 09:46:44 -0500, Elardus Engelbrecht 
 wrote:

. . .
>
>"I tried APL once, back in 77.  I thought it was the perfect programming 
>language.  One could write an entire program on/in one line of code. "
>

The only thing I remember about APL is ")OFF".

For some reason (lost in the mists of time) we regularly had TSO users who 
managed to "accidentally" invoke the APL interpreter, which was almost 
impossible to terminate unless you knew the above magic incantation.

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

Re: MVS operator command issue

[Andy Wood]

On Sun, 24 Jan 2016 11:55:16 -0800, Charles Mills  wrote:

>It can be done but it is not easy. You don't actually need the front end (I 
>think -- more familiar with C than COBOL). But it is not "supported." S122's 
>are "unrecoverable."
>

I have no idea about either C or Cobol, but you can "intercept" x22 abends 
using TERM=YES on ESTAE - the ESTAE routine gets control but is not allowed to 
retry.

Since SP231 is being used, the code is presumably running authorised and could 
thus also make use of RESMGR to handle task and also address space termination.

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

Re: Strange 047 abend

[Andy Wood]

On Thu, 23 Jul 2015 02:16:59 -0400, Jim Mulder d10j...@us.ibm.com wrote:

...

  A 047 abend occurs when a MODESET SVC (x'6B') is issued while
you are not (APF Authorized or Supervisor State or Key 0).
And that is the expected state of affairs if you are running under
TSO TEST.

While MODESET is a very likely candidate, it could also occur when issuing some 
other SVC, if that SVC is flagged as requiring authorisation.

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

Re: Strange 047 abend

[Andy Wood]

On Wed, 22 Jul 2015 22:39:58 -0400, michelbutz michealb...@comcast.net wrote:

I am getting a 047 abend running a program 
That runs in production 
The 047 abend under both TSO TEST and debug tool happens with a STC 
instruction which tries to 
Modify the 2 lengths of a AP instruction

Is the EXECUTE instruction broken on your machine?

With what you are doing, you could possibly cause ABEND047 (or all sorts of 
other abends) not on the STC instruction, but on the AP instruction, if you had 
set a breakpoint on the AP under TSO TEST. That could happen because you would 
be changing the SVC number in the SVC instruction that replaces the first two 
bytes of the AP for the breakpoint. That could certainly cause some 
head-scratching.

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

Re: EOJ, literally.

[Andy Wood]

On Fri, 26 Jun 2015 11:44:38 -0700, Tom Brennan t...@tombrennansoftware.com 
wrote:

Ah!  The needle is used when you don't trust the sort machine!  Now I
get it.  I hope nobody thinks of these as The good old days :)


Wow! That reminds me of something I did over 50 years ago when I was still at 
school. 

By cutting a series of binary-coded holes and slots along the edge of ordinary 
playing cards, it was possible to sort the deck using a knitting needle.

I learned how to do this from a book called The Gentle Art of Mathematics, by 
Dan Pedoe, published in 1958.

I still have that book, and somewhere, hidden away in a box, I think I still 
have the deck of cards.

Good luck to Tony!

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

Re: Wait forever

[Andy Wood]

On Tue, 23 Jun 2015 05:43:20 -0700, Charles Mills charl...@mcn.org wrote:

You're right of course. I missed that. And I suspect Peter did also. A
comment on the DS A would be a help to code maintainers.

Strangely, I also missed seeing the first ECB, and nearly posted something 
silly about using STIMER WAIT instead of messing with exits and ECBs. 
Fortunately, I saw the error of my ways just in time...  

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

Re: AW: Re: Statement of Integrity and UNIX.

[Andy Wood]

On Sat, 13 Jun 2015 08:07:55 +0200, Peter Hunkeler p...@gmx.ch wrote:

...


What you wrote is true *if* BPX.DAEMON is *not* defined at all.


...

It is also true if even if BPX.DAEMON *is* defined, if you have a daemon that 
trusts the Unix file system. For example, when you have enabled cron.

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

Re: Statement of Integrity and UNIX.

[Andy Wood]

On Sat, 13 Jun 2015 10:36:05 -0500, Tom Marchant m42tom-ibmm...@yahoo.com 
wrote:

On Fri, 12 Jun 2015 19:28:01 -0500, Andy Wood wrote:


there were some weasel words in the documentation about 
not allowing privileged users to have OMVS segments.

I don't see any such words in the Statement of Integrity at
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=WHinfotype=SAhtmlfid=ZSL03361USENattachment=ZSL03361USEN.PDF

I did not mean to imply that it was was in the SOI.

UNIX System Services Planning, where it discusses BPX.DAEMON, says: Kernel 
services that change a caller's z/OS user identity require the target z/OS user 
identity to have an OMVS segment defined. If you want to maintain this extra 
level of control at your installation, you must choose which daemons to permit 
to BPX.DAEMON. You will also have to choose the users to whom you give the OMVS 
security profile segments.

The wording has changed somewhat over the years, but it seems to me that the 
potential exposure still exists. Actually, I think the new wording makes it 
less likely that you would realise exactly what they are getting at. 

It is a situation where having access to root spills over into the world of 
traditional z/OS security. So, if a user can surreptitiously gain access to 
root, there is the potential for them to gain access to anything.  People 
with a Unix background might say so what is new?, but the very existance of 
profiles like BPX.DAEMON to me indicates that such spill over was something the 
designers hoped to prevent.

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

Re: Statement of Integrity and UNIX.

[Andy Wood]

On Fri, 12 Jun 2015 16:36:41 -0500, Paul Gilmartin paulgboul...@aim.com wrote:

... 
Does this cover a UNIX user's escalating privileges to root?
...

It used to be the case that a root user, or a user with access to root, might 
be able to gain access to any resource, if there happened to be another user, 
with an OMVS segment, who had access to the resource. You might think that 
situation at least would be covered by the SOI, but there were some weasel 
words in the documentation about not allowing privileged users to have OMVS 
segments.

Given that those words are still in the documentation now, I suspect that 
situation has not changed.

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

Re: Mysterious U4088-63 from RPTSTG(ON)

[Andy Wood]

On Thu, 28 May 2015 07:56:03 -0700, Charles Mills charl...@mcn.org wrote:

. . .

I would assume C++ gets the stack at startup, not on the first external
call. Interesting thought.

I have this very vague recollection, that when RPTSTG is ON, things are set up 
so that the stack is always too small (or gives that appearance), so that 
routine gets called every time.

However, it has been a very long time since I was near anything like that, 
things may have changed, and perhaps I had the story wrong in the first place.

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

Re: XR vs SR

[Andy Wood]

On Wed, 4 Jun 2014 00:37:34 -0700, glen herrmannsfeldt g...@ugcs.caltech.edu 
wrote:

. .  .

Yes, but the S/360 timings are the only ones we have.


Are they?

The 370/145 Functional Characteristics manual, available on Bitsavers, gives 
the following times (in microseconds):

SLR   1.373
SR 1.575
XR 1.935

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

Re: ISPF storage protection

[Andy Wood]

On Tue, 4 Mar 2014 09:25:10 -0600, Paul Gilmartin paulgboul...@aim.com wrote:

. . .

Because it would be a major security breach.
 
That doesn't tell me much.

Why?  How?  Would it be any less a security breach to invoke such a program
from JCL with EXEC PGM=... which likewise causes it to run in the authorized
state?


Perhaps you could get away without AUTHPGM, but AUTHTSF is required. Actually 
when the TSO Service Facility was created, the designers did not see a need for 
this, and they made use of AUTHPGM, which together with AUTHCMD already existed 
at that time. Some time later they saw the error of their ways and an APAR 
added AUTHTSF.

For a long time the only place where the reason for this was explained was in 
the APAR that introduced it, and at some point even that was hidden from 
customers' view.

These days the reason is explained in the TSO/E documentation: 

... programs in this list (AUTHTSF) should not accept parameters that are 
pointers to code what is to be executed (such as exit routines) as this might 
introduce an integrity exposure.

Such parameters cannot be provided when executing the program using JCL. 

The documentation even goes on to mention that IDCAMS should never be added to 
AUTHTSF. IDCAMS was the specific program that prompted the APAR that introduced 
AUTHTSF, but any number of other programs could have the same issue.

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

Re: IBM assembler copybook

[Andy Wood]

On Tue, 25 Feb 2014 11:26:22 -0600, Ron Thomas ron5...@gmail.com wrote:

The vsam file we having one of the fields data is stored in bits , i.e each 
bit value has a specific meaning 1 means the store is active else 'no' . We 
have fileaid utlity to view files . The data i am saying here is defined as 
1250 bytes, so that 1 stores data can be stored . 

Suppose for testing if i want to view and edit the file , i believe if we can 
create PL/1 copybook then we can go and edit the file for one specfic store. 
please do let me know is this possible ? or we should not go and edit the bits 
in the file ?

Of course you can view and edit it. If all you are interested in is the state 
of a particular store, I don't quite see why you would need to used some 
copybook in the process, all you need is the offset of the bit map in the 
record (which you could tell from a glance at the assembly listing of one of 
the programs that process the file), and the store number.

If you don't have a tool that directly allows you to edit a VSAM file, REPRO it 
into a sequential file and work on that before converting it back to a KSDS.

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

Re: IBM assembler copybook

[Andy Wood]

On Tue, 25 Feb 2014 15:11:19 -0500, John Gilmore jwgli...@gmail.com wrote:

I think Ron Thomas has in mind the fact that Enterprise COBOL does not
[yet] support analogues of such PL/I constructions as

  declare byte aligned bit(8) based(bytep) ;

  declare bits8(8) bit based(bits8p) ;

which provide immediate programmatic access to the individual bits in
a byte.  They can be tested and set directly in PL/I and not in COBOL.


As far as I can see, Ron has no particular interest in Cobol.

He only mentioned Cobol to say that Fileaid supports it, in the context of that 
being of no use to him. It seems he has only an assembler DSECT for the record.

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

Re: IBM assembler copybook

[Andy Wood]

On Sun, 23 Feb 2014 10:53:58 -0700, Steve Comstock st...@trainersfriend.com 
wrote:

On 2/23/2014 10:23 AM, Ron Thomas wrote:
. . .


Really? I didn't think Assembler supported VSAM library source
for copy files.

Oh, wait. Are you z/OS or z/VSE?


I suspect he may mean that the copybook contains a DSECT for the layout of 
records in the KSDS.

If that is what he means, I'm not aware of something that will what he wants. 
Even if there is such a tool, I guess that the bit map mentioned is the famous 
ITMAP, which at best would be displayed in hex, as it was defined as XL1250.

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

Re: XL2 capacity (was: assembler)

[Andy Wood]

On Tue, 18 Feb 2014 10:38:11 -0600, Paul Gilmartin paulgboul...@aim.com wrote:

On Tue, 18 Feb 2014 11:26:41 -0500, John Gilmore wrote:

X L2 defines a two-byte field.  Its value can range from x'' to x''.

Viewed as unsigned this is a numeric range of 0 = u = 65535.  Viewed
as signed it is a numeric range of -32768 = s = +32767.

In either case the answer to your question is yes.
 
As I read it, the OP intends to count bits, not bytes, in which case the answer
is no.


I think we would need to see how ITMLNG is used to know for sure. 

A snippet of code given in a previous question (with an equally useful subject  
of Assembler code) inverted a bit in ITMAP without any reference to ITMLNG.


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

Re: assembler

[Andy Wood]

On Tue, 18 Feb 2014 13:41:08 -0500, John Gilmore jwgli...@gmail.com wrote:

. . .
Since, however, the storage is being declared/allocated in bytes, it
seems clear to me that the length is/ought to be expressed in bytes
too.  I do not see much rationale for your different view in this
particular context.


If the length, in bytes, of ITMAP was required, I would be inclined to use 
L'ITMAP.

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

Re: assembler

[Andy Wood]

On Tue, 18 Feb 2014 16:19:43 -0500, John Gilmore jwgli...@gmail.com wrote:

There is certainly no objection to using L'whatever in order to
ensure that the length in bytes of whatever is declared and must be
changed in only one place; but this usage 1) is available only at
assembly time and 2) is not a substitute for the explicit
specification of this length somewhere.



As it stands, increasing the size of the bit map beyond 10,00 bits requires 
re-assembly anyway. 

It would be instructive to see how the field ITMLNG is initialized.

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

Re: Assembler code

[Andy Wood]

On Tue, 4 Feb 2014 11:22:32 -0600, Ron Thomas ron5...@gmail.com wrote:

Ok Thanks .so what would be o/p of this statement TRBIT,TR@TAB  here ? 


When I look at that code, I am left thinking there has to be an easier way. I 
would have done a single CVB immediately after the PACK, and then split it up 
into the byte and bit displacements.

However to answer your specific question: The remainder, after dividing by 8, 
and which has been placed in BIT, is a number in the range 0 to 7. The TR 
converts 0 to X'80', 1 to X'40', 2 to X'20' etc, for use as the mask in the 
TM.

 

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

Re: Assembler code

[Andy Wood]

On Tue, 4 Feb 2014 13:08:25 -0600, Andy Wood woo...@ozemail.com.au wrote:

. . .

However to answer your specific question: The remainder, after dividing by 8, 
and which has been placed in BIT, is a number in the range 0 to 7. The TR 
converts 0 to X'80', 1 to X'40', 2 to X'20' etc, for use as the mask in the 
TM.


Ok, so I was mislead by the comments.  The X'80', X'40' etc is used in the XI, 
there being no TM instruction.

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

Re: ▶ One day, a computer will fit on a desk (1974) - YouTube

[Andy Wood]

On Sun, 29 Dec 2013 09:50:03 -0500, Anne  Lynn Wheeler l...@garlic.com wrote:


IBM 5100 1973 at Palo Alto Science Center
http://en.wikipedia.org/wiki/IBM_5100



Besides the IBM 5100, there were other desktop machines that could be called 
computers.

Two that I personally encountered were the Datapoint 2200 from 1971, and the HP 
9100 from 1968.

Some may say that the HP 9100 was only a calculator, but Bill Hewlett himself 
supposedly said that HP called it a calculator rather than a computer as a 
marketing ploy (knowing that potential customers could more easily justify the 
purchase of a calculator than of a computer.

In context of that video, the HP 9100 is particularly significant - Athur C. 
Clarke had been presented with one by HP in 1970.

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

Re: Un-authorized caller calling authorized services.

[Andy Wood]

On Tue, 3 Dec 2013 21:54:00 -0600, Robert A. Rosenberg hal9...@panix.com 
wrote:

Definitely a large positive number over 2^16-1 (so there is something
other than zeros in the high 2 bytes).

The low 2 bytes have to be between x and x0008 to pass the CH
R1,=H8 check.

As to negative numbers, that number also has to be within certain
boundaries so the low bytes meet the same range check.


At 12:59 -0600 on 12/03/2013, Ray Overby wrote about Re:
Un-authorized caller calling authorized services.:


I'm not sure what you are saying there. 

CH does not ignore the high order bytes of the register - in effect it 
sign-extendeds the halfword (H'8' there) to a fullword for comparison with the 
register. The problem is with negative function codes, not large positive 
ones. 

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

Re: Un-authorized caller calling authorized services.

[Andy Wood]

On Wed, 4 Dec 2013 16:57:29 +, DASDBILL2 dasdbi...@comcast.net wrote:

It appears that if R1 contains a -4, -8, or -12, then the code will go into an 
infinite loop.  This would not cause a security breach, but it is still an 
error. 
Bill Fairchild 
Franklin, TN 

That is true, but given the vast range it can be made to branch to, a loop is 
but one of probably thousands of different outcomes.

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

Re: Un-authorized caller calling authorized services.

[Andy Wood]

On Mon, 2 Dec 2013 13:36:43 -0600, Ray Overby ray.ove...@kr-inc.com wrote:

When creating authorized code I use the following guidelines:

-   It is not good enough that the authorized code functions as
designed. Authorized code has a higher standard that it must adhere to.
Your code must not allow malicious or uninformed users to make it do
things outside of its scope.
-   Pay attention to how you obtain your parameters.
  -Parameters should be accessed in the requesters PSW Key.
  -Make a copy of the parameters so that they cannot be changed
after you have validated them and before you use them (time of check 2
time of use vulnerability).
-Make sure sensitive data is kept in fetch protected storage.
-Make sure your design does not allow the requester to control where
the authorized code branches to:
  -By branching to a user specified address in an authorized state
  -By branching on a function code whose value is not verified
to be in a specific range
-Be careful issuing authorized services in your code AND allowing
user parameters to be specified in the authorized services parameter list.
-   Return data to requester in their PSW Key.
-   Don't return control to the requester with a higher level of authority
 -Don't dynamically  elevate their security credentials
 -Don't allow the requester the ability to MODESET
 -Don't return control in a different PSW Key or State


Ray Overby
Key Resources, Inc
Ensuring System Integrity for z/Series
(312) 574-0007


I've lost track of the number of issues I found in this sort of code over the 
years. A lot of those problems would have been avoided by following the advice 
above.

Some of the more common problems:

Flawed function code validation. Like this in an SVC routine that was 
supposed to be called with a function code of 0, 4 or 8 in R1.

 CHR1,=H'8'   IF FUNCTION CODE TOO LARGE
 BHRETURN THEN IGNORE IT
 B BTABLE(R1) USE BRANCH TABLE TO GO TO REQUIRED
* FUNCTION
BTABLE   B HERE   FUNCTION=0 
 B THERE  FUNCTION=4
 B EVERYWHERE FUNCTION=8
 
So what happens if it is called with a function code that is not a multiple of 
4? Actually, it has a bigger problem than that, can you spot it?

Still, that is better than the two SVC routines I encountered, both of which 
were only two bytes long, and that could have been called IEFBR15 and IEFBR1 
respectively, or the SVC which performed an MVCL using caller provided 
addresses and lengths, with absolutely no validation at all.

Another common problem was SVC routines that found it necessary to examine a 
CDE to assist with distinguishing the good guys from the bad (a notoriously 
difficult task if the bad guys refuse to cooperate). They followed a pointer 
from the caller's RB to locate the CDE, forgetting that not all RBs point to 
CDEs. The result was that they could be trivially deceived by calling them from 
an IRB.

Another issue was inadvertently making an assumption about the contents of some 
register. This was more common in PC routines but I also saw more than one SVC 
that started out with:
 STM   R14,R12,12(R13) 

Another flawed good guy test I saw over and over again was to assume that if 
you knew the location of your caller (say PLPA) or if the caller's code resided 
in system key storage, then they could be trusted. I suspect this false notion 
may have its roots in the original, and somewhat infamous SPFCOPY SVC.

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

Re: TCBJLB doesn't point to a DCB

[Andy Wood]

On Fri, 29 Nov 2013 11:32:45 -0500, Shmuel Metz (Seymour J.) 
shmuel+ibm-m...@patriot.net wrote:

In 0717adf1-8fde-41db-940d-77a882817...@optonline.net, on 11/29/2013
   at 10:45 AM, Micheal Butz michealb...@optonline.net said:

Can I use what's pointed to by TCBJLB as a param for DESERV

ObFoma Yes.

quite frankly the TCB's I have looked at the 4 byte field at offset
X'28' from the TCB doesn't look like a address

Why would you expect it to? Look at your DCBD macro expansion.

Why would you expect a TCB to match the DCB DSECT? Clearly, at that point he is 
talking about TCB+X'28, not DCB+X'28'.

I'm too lazy to check if that is a 4 byte address though, and not one of the 
three byte relics with something else in the top byte.



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

Re: DSNAME Syntax

[Andy Wood]

On 25 Sep 2013 07:33:25 -0700, Paul Gilmartin wrote:

So I infer that a DSNAME beginning with a period has some special 
significance

when in a format-4 DSCB.  Hmmm.  I'm pretty naive at this.  Looking in:

Title: z/OS V1R13.0 DFSMSdfp Advanced Services
Document Number: SC26-7400-14

 1.1.1.5 Format-4 DSCB

The only hint of something that might be a DSNAME is:

 Exception: The format-4 DSCB has a 44-byte key of X'04' bytes 
not shown in Table 4.



I have this vague memory of accessing the VTOC with a quoted DSN of 
X'040404...' on a DD card (and I do mean card, X'04' = 12-4-9 punch).


In any event, I thought that FORMAT4.DSCB was specific to xMASPZAP - 
something that it checked for and replaced with x'040404... if 
found. (guessing, by using RDJFCB and TYPE J OPEN).


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

Re: New Software Tool for z/OS Developers Announced by Arney Computer Systems

[Andy Wood]

On Wed, 10 Apr 2013 09:06:13 -0500, Kenneth Wilkerson redb...@austin.rr.com 
wrote:

TDF does not use traditional intercept technology. TDF never alters any
user code other than user specified breakpoints and it never alters any MVS
code in any way.

What about pointers to MVS code? Updating those is what I would call the 
traditional method, rather than dynamically altering a couple of instructions 
here or there (yes I have seen that too, when it went spectacularly wrong, but 
it is not very common).

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

Re: New Software Tool for z/OS Developers Announced by Arney Computer Systems

[Andy Wood]

On Fri, 5 Apr 2013 15:29:47 -0500, Ed Gould edgould1...@comcast.net wrote:

   
   ... It
uses the most advanced facilities of the System z hardware
architecture to create a modern debugging platform surpassing the
techniques used by older generations of debugging tools.

One wonders, or at least I wonder, if it does this with or without the 
assistance of z/OS.

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

Re: REFRPROT History Question

[Andy Wood]

On Fri, 1 Mar 2013 10:15:46 -0600, Paul Gilmartin paulgboul...@aim.com wrote:

. . .
But why, in the beginning, as soon as the REFR attribute was
available, were not all load modules, even from non-APF authorized
libraries, loaded into write-protected storage?


I'm not sure I totally understand what you are asking, but …

Perhaps protection of modules from APF libraries was deemed to be sufficiently 
important from a system integrity point of view, that they were prepared to 
endure the trouble caused due to existing load modules with incorrect 
attributes, while doing it for all load modules would have caused too much 
disruption to be worthwhile.

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

Re: Storage Obtained By an SRB

[Andy Wood]

On Sun, 9 Dec 2012 15:12:44 -0800, Edward Jaffe edja...@phoenixsoftware.com 
wrote:

On 12/9/2012 2:56 PM, Micheal Butz wrote:
 Can you issue STORAGE OBTAIN,LENGTH=LENGTH_VALUE,SP=0

 In Srb mode

RTFM. It took me less time to look up than it did to copy/paste below! :0

. . .

There could be more to it than that. 

If the question relates specifically to SP 0, rather than private area 
storage as originally stated, then although you *can* issue an OBTAIN for 
SP=0, I don't think that is what you would get. 

It is hard to imagine an SRB that does not run in supervisor state, and SP 0 
requests from supervisor state callers are translated to SP 252.  Depending on 
what the SRB is is going to do with the storage, that translation may or may 
not be to your advantage. You certainly would not want an SRB to be using 
actual SP 0 (often key 8 or other user key) storage as a general work area.

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

Re: Makes me love most of my z/OS software vendors.

[Andy Wood]

On Mon, 26 Nov 2012 10:01:38 -0600, Mark Zelden m...@mzelden.com wrote:

. . .  Things
like PSA overlays, UCB overlays etc.  Of course over the years IBM has added
lots of code and features to repair critical control blocks and there are 
captured
UCBs etc., so it less frequent. . . .

The introduction of captured UCBs was a backward step from a system reliability 
point of view, as it increased the chances of a UCB being overlaid, and could 
make it very difficult to catch the culprit. The much later Captured UCB 
Overlay Protection restored the reliability status quo.

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

Re: Relationship of C signals to z/OS terminology?

[Andy Wood]

On Fri, 13 Jul 2012 09:45:00 -0700, Charles Mills charl...@mcn.org wrote:

. . .

Yeah, in a perfect world there would be no bugs. But I had a bug in the field 
(the first in 18 months!) that resulted in a loop, a CANCEL, and a modest mess 
in CSA.

Yes, I will fix the root cause bug. Yes, I resolve to be more careful in the 
future -- maybe one error in the field every 36 months. But if this should 
happen again ...

Your suggestion for how to proceed?


For what you are doing, a MEMTERM resource manager is probably a good idea. 
That can be set up with the RESMGR macro, TYPE=ADDRSPC. The specified routine 
runs in ASID 1, and you can't access anything in the terminating address space, 
but you can free CSA and maybe do some other clean up there.  I know close to 
zilch about all this SIGxxx stuff, but I suspect there may not be an equivalent 
to RESMGR TYPE=ADDRSPC.  

While you are about it you could also look at RESMGR TYPE=TASK.

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

Re: Why is GRS ENQ needed in SMFDUMP program?

[Andy Wood]

On Thu, 21 Jun 2012 09:45:05 -0500, Elardus Engelbrecht 
elardus.engelbre...@sita.co.za wrote:

. . .
Not the SYSTEM level ENQ that you have shown, unless you have added IPOSMF01 
to the INCLude list in GRSRNKxx.

It is not there in GRSRNLxx (or GRSRNKxx which you wrote... ;-D ).


Any GRS exits?

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