Re: Rexx (was: OT? ... "deliberately unfriendly")

[Arthur T.]

On 29 Nov 2013 08:47:35 -0800, in bit.listserv.ibm-main 
(Message-ID:<0895521555071176.wa.paulgboulderaim@listserv.ua.edu>) 
paulgboul...@aim.com (Paul Gilmartin) wrote:


(But it would be useful to be able to read a file into a 
compound
variable with a single instruction rather than coding a 
loop.

Hmmm... I wonder how this works if infile is a terminal?)


For anyone just joining, this was about Regina REXX on a 
PC.


To do a single read of a file into a compound variable:

 
call rxfuncadd 'sysloadfuncs','RexxUtil','sysloadfuncs'
call sysloadfuncs
call RegStemRead file, inline.
 

The 1st two lines are needed only once per execution, not 
once per file read.



--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" pobox "dot" com

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

Re: IEFIIC question

[ibmmain]

> Drilling down into Mainview, the program has allocated 10 MB, and IEFIIC has 
> taken an additional 21 MB.  What is IEFIIC doing with all this storage?
My guess is that IEFIIC hasn't done *anything* to get that much storage. 
Something in the TCBs attached under IEFIIC used IEFIIC as 'owner' of it's own 
storage, either explicitly or defaulted, so it just looks like IEFIIC did 
something. Remember abend822? That happens when something in a batch program 
allocated storage under IEFIIC and did not free it at the end of the step. One 
of the next batch jobs that happen to run in that initiator will get the 822, 
when the actual culprit may have run a lng time ago.

As was suggested: Take a dump of that address space when you can see all that 
storage allocated and use IPCS. But also run a GM/FM trace on some/any/all 
subpools in that address space to later find out which TCB did the actual 
getmain.

Barbara

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

Re: Curiosity: ETXR exit code (ATTACHX macro)

[Gerhard Postpischil]

On 11/29/2013 7:57 PM, John McKown wrote:

terminating child TCB. Or does RTM itself serialize the ETXR code so that a
second instance is not driven until the first instance finishes (by
exiting, thus going back to the parent's "main loop").


Unless the manual explicitly specifies that or how an exit is 
serialized, assume the worst - exit must be re-entrant and you are 
responsible for any needed serialization.


While it was a different set of exits, I was asked to diagnose an 0Cx of 
a commercial product on the market since the mid-seventies - two exits 
were invoked concurrently, and they used the same save area!


Gerhard Postpischil
Bradford, Vermont

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

Re: CRONTAB and SYSLOGD

[Jon Perryman]

SYSLOGD and CRON work the same as on UNIX. Talk to your UNIX admin about these 
to get a solution that is suitable for your environment. If you have an MVS 
automation product or job scheduler, then you can use it in place of CRON. 

Jon Perryman.



>
> From: Fred Kaptein 
>
>
>We are looking for the statements to insert into  /etc/syslog.conf   to do the 
>following
>    - retain the unix syslog in a file directory /xxx/  
>       (we have not yet decided on a directly, but please let us know if there 
>is an IBM recommended directory)
>    - only retain 30 days of the unix syslog data (it is not important if the 
>data is lost across IPLS)
>

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

Re: Curiosity: ETXR exit code (ATTACHX macro)

[Robert A. Rosenberg]

You're welcome. I hope that you can add the missing pieces to my 
overview set of instructions. The basic idea is to get a few subtasks 
running, have them end while delaying the launch of the EXTR routine 
until all are ended, and then have the routine do the check for you. 
I attempted to suggest a way that this criteria was met (the lower 
priority, etc.).


After you try it, a report here on your findings might be welcome to 
those who are interested in this issue.


At 21:30 -0600 on 11/29/2013, John McKown wrote about Re: Curiosity: 
ETXR exit code (ATTACHX macro):



I can try that. Thanks.
On Nov 29, 2013 8:33 PM, "Robert A. Rosenberg"  wrote:


 At 18:57 -0600 on 11/29/2013, John McKown wrote about Curiosity: ETXR exit
 code (ATTACHX macro):

  I think the former. with ETXR#2 interrupting ETXR#1 is what really

 happens.
 I can't think of a way, off hand to test this.



 To test, attach a few subtasks (which have a dispatching Priority lower
 than the main task) which each wait on their own ECB. Have the main task
 post the ECBs (since it is the higher priority, all the POSTs will fire
 before the WAITs get satisfied). Now do a STIMER for 45 seconds in the main
 task so the sub tasks can run and complete (ie: exit when the ECB got
 POSTed). Have the EXTR run the CB chain and report if there is more than
 one IRB. Log the results so you know if one IRB waited to occur once the
 prior one was over or if there was a chain of IRBs.

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



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


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

Re: Curiosity: ETXR exit code (ATTACHX macro)

[John McKown]

I can try that. Thanks.
On Nov 29, 2013 8:33 PM, "Robert A. Rosenberg"  wrote:

> At 18:57 -0600 on 11/29/2013, John McKown wrote about Curiosity: ETXR exit
> code (ATTACHX macro):
>
>  I think the former. with ETXR#2 interrupting ETXR#1 is what really
>> happens.
>> I can't think of a way, off hand to test this.
>>
>
> To test, attach a few subtasks (which have a dispatching Priority lower
> than the main task) which each wait on their own ECB. Have the main task
> post the ECBs (since it is the higher priority, all the POSTs will fire
> before the WAITs get satisfied). Now do a STIMER for 45 seconds in the main
> task so the sub tasks can run and complete (ie: exit when the ECB got
> POSTed). Have the EXTR run the CB chain and report if there is more than
> one IRB. Log the results so you know if one IRB waited to occur once the
> prior one was over or if there was a chain of IRBs.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Mike Schwab]

A-Z@#$: 29 characters for the first character, plus 0-9 for up to 7
additional characters.
29 One character.
1,131 Two character.
44,109 Three character.
1,720,251 Four character.
67,089,789 Five character.
2,616,501,771 Six character.
102,043,569,069 Seven character.
3,979,699,193,691 Eight character.
4,084,428,119,840 1-8 character level.



On Fri, Nov 29, 2013 at 12:49 PM, Gerhard Postpischil
 wrote:
> On 11/29/2013 12:36 PM, Paul Gilmartin wrote:
>>
>> There is no "limitation ... of ... 5 levels"  Hasn't been for a long
>> time; perhaps never was.
>
>
> While I don't remember a 5-level limit, there always was (and will be?) a
> practical limit. Using every possible legal name, even at a single level,
> exhausts space available on any early DASD.
>
> Gerhard Postpischil
> Bradford, Vermont
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Curiosity: ETXR exit code (ATTACHX macro)

[Robert A. Rosenberg]

At 18:57 -0600 on 11/29/2013, John McKown wrote about Curiosity: ETXR 
exit code (ATTACHX macro):



I think the former. with ETXR#2 interrupting ETXR#1 is what really happens.
I can't think of a way, off hand to test this.


To test, attach a few subtasks (which have a dispatching Priority 
lower than the main task) which each wait on their own ECB. Have the 
main task post the ECBs (since it is the higher priority, all the 
POSTs will fire before the WAITs get satisfied). Now do a STIMER for 
45 seconds in the main task so the sub tasks can run and complete 
(ie: exit when the ECB got POSTed). Have the EXTR run the CB chain 
and report if there is more than one IRB. Log the results so you know 
if one IRB waited to occur once the prior one was over or if there 
was a chain of IRBs.


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

Re: Curiosity: ETXR exit code (ATTACHX macro)

[Charles Mills]

I *think* the latter. I seem to recall that exits don't get re-entered. Not
an expert.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John McKown
Sent: Friday, November 29, 2013 4:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Curiosity: ETXR exit code (ATTACHX macro)

Suppose that I have a program which is heavily multitasking. There is the
parent task and multiple subtasks, all direct children of the single parent.
The ATTACHX macro uses the ETXR parameter, which specifies a single routine
which does housekeeping of some sort. Also assume that the subtasks are
being created and ending "randomly". That is the main task is "doing its
thing", then a subtask ends and drives the ETXR code under the parent TCB (I
think under an IRB). Now this can happen anywhere in the parent's "main
loop", so I know that I need to serialize properly between the "main loop"
code and the ETXR code. Assume that I have done so. I am wondering if a
second child terminates while the parent TCB is in the ETXR code for a
child, will the ETXR code be interrupted and "redriven" for the newly
terminating child TCB. Or does RTM itself serialize the ETXR code so that a
second instance is not driven until the first instance finishes (by exiting,
thus going back to the parent's "main loop").

I.e. can the RB chain at some point look like:

PRB of parent, IRB of ETXR #1, IRB of ETXR #2, IRB of ETXR #3 for a time
line like:

main TCB loop running
child #1 ends, ETXR#1 starts running on main TCB child #2 ends, ETXR#2
starts running on main TCB (EXTR#1 interrupted)
ETXR#2 ends, ETXR#1 resumes where it left off
ETXR#1 ends, main TCB code loop resumes from where it was interrupted.

or is the second ETXR "deferred" until the previous invocation does an SVC
3 to return to the main routine. Timeline like:

main TCB loop
child ends, causing ETXR to be invoked on main TCB child ends while ETXR
active, is queued ETXR #1 ends queued ETXR starts execution ETXR #2 ends
main TCB loop resumes


I think the former. with ETXR#2 interrupting ETXR#1 is what really happens.
I can't think of a way, off hand to test this.

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

Curiosity: ETXR exit code (ATTACHX macro)

[John McKown]

Suppose that I have a program which is heavily multitasking. There is the
parent task and multiple subtasks, all direct children of the single
parent. The ATTACHX macro uses the ETXR parameter, which specifies a single
routine which does housekeeping of some sort. Also assume that the subtasks
are being created and ending "randomly". That is the main task is "doing
its thing", then a subtask ends and drives the ETXR code under the parent
TCB (I think under an IRB). Now this can happen anywhere in the parent's
"main loop", so I know that I need to serialize properly between the "main
loop" code and the ETXR code. Assume that I have done so. I am wondering if
a second child terminates while the parent TCB is in the ETXR code for a
child, will the ETXR code be interrupted and "redriven" for the newly
terminating child TCB. Or does RTM itself serialize the ETXR code so that a
second instance is not driven until the first instance finishes (by
exiting, thus going back to the parent's "main loop").

I.e. can the RB chain at some point look like:

PRB of parent, IRB of ETXR #1, IRB of ETXR #2, IRB of ETXR #3 for a time
line like:

main TCB loop running
child #1 ends, ETXR#1 starts running on main TCB
child #2 ends, ETXR#2 starts running on main TCB (EXTR#1 interrupted)
ETXR#2 ends, ETXR#1 resumes where it left off
ETXR#1 ends, main TCB code loop resumes from where it was interrupted.

or is the second ETXR "deferred" until the previous invocation does an SVC
3 to return to the main routine. Timeline like:

main TCB loop
child ends, causing ETXR to be invoked on main TCB
child ends while ETXR active, is queued
ETXR #1 ends
queued ETXR starts execution
ETXR #2 ends
main TCB loop resumes


I think the former. with ETXR#2 interrupting ETXR#1 is what really happens.
I can't think of a way, off hand to test this.


-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

Maranatha! <><
John McKown

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Paul Gilmartin]

On Fri, 29 Nov 2013 17:35:04 -0500, Gerhard Postpischil wrote:

>On 11/29/2013 3:00 PM, Paul Gilmartin wrote:
>> It should be easy to relax the 8-character maximum (except,
>> perhaps on the HLQ) without incompatibility with existing data
>> areas, even was done for the antetypical 5-level maximum.
>
>This could be done except for TSO, due to unfortunate dependences on
>both the high and low portion of the data set name. The designers, in
>their infinite wisdom, chose to define the PSCB to contain a 7-byte user
>id (or user specified prefix), followed by a one byte length. For OS/360
>MVT, the Technion had zaps to get around the limitation (Shmuel may have
>a better idea just how many modules they modified). For the last level,
>TSO EDIT and possibly other programs, rely on a table of data
>characteristics by name (e.g., DATA, CNTL) that also would require changes.
> 
Hmmm.  That somewhat proves my point.  Under TSO, I was able to
allocate a data set with both HLQ and LLQ of 8 characters; edit it
(with ISPF) and browse it.  I couldn't catalog it because I don't know
of an 8-character HLQ to which I have access, but I believe that's
an administrative limitation, not anything imposed by the OS.  This is
a good example of not letting the limitations of one component (TSO)
impose a restriction on many others.

And earlier, I neglected to laud IBM for a likewise good decision.  Early
in the history of Unix System Services, Allocation and JCL were enhanced
to support allocating a UNIX pathname to a DDNAME, regardless that
a data set so allocated would be unusable by BLDL, STOW, BSAM, QSAM,
ATTACH, LINK, STEPLIB, and many others.  But doing so opened the way:
BLDL (but not STOW or DESERV), BSAM, and QSAM, at least now support
data sets allocated to UNIX pathnames.  This could not have happened if
IBM had chosen to allow the limitations of many components to restrict
enhancement of another.  I'm eagerly waiting for the support to grow.

Bye.  Gotta go delete my uncatalogued data set.

-- gil

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Gerhard Postpischil]

On 11/29/2013 3:00 PM, Paul Gilmartin wrote:

It should be easy to relax the 8-character maximum (except,
perhaps on the HLQ) without incompatibility with existing data
areas, even was done for the antetypical 5-level maximum.


This could be done except for TSO, due to unfortunate dependences on 
both the high and low portion of the data set name. The designers, in 
their infinite wisdom, chose to define the PSCB to contain a 7-byte user 
id (or user specified prefix), followed by a one byte length. For OS/360 
MVT, the Technion had zaps to get around the limitation (Shmuel may have 
a better idea just how many modules they modified). For the last level, 
TSO EDIT and possibly other programs, rely on a table of data 
characteristics by name (e.g., DATA, CNTL) that also would require changes.


Gerhard Postpischil
Bradford, Vermont

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Shmuel Metz (Seymour J.)]

In
,
on 11/29/2013
   at 02:16 PM, John Gilmore  said:

>Under OS/360 the notional, antetypical 'longest' index had the syntax

>

I can't speak for release 1, but certainly in OS/360 R14 there was no
such limit.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Shmuel Metz (Seymour J.)]

In <0378217484586824.wa.zatlas1yahoo@listserv.ua.edu>, on
11/29/2013
   at 11:47 AM, "Ze'ev Atlas"  said:

>Again, you discuss the shortcoming of a specific system while I have
>a broad view.

You're specific systems; I'm still trying to figure out what it is in
them that you want to change.

>There would always be the need to disambiguate.

Then what behavior do you want to change? For normal use in Unix,
including z/OS, and for legacy z/OS data sets, the user just gives a
name and the system figures out where it is.

>That's correct and that's where I took the idea from.  That concept
>needs improvements

No doubt, but so far you haven't identified any defect that a new type
of catalog would resolve.

>Another great idea from the z/OS that deserve implementation in 
>that context (i.e. Central System Catalog) is the famous GDG.  
>Whenever I explain the concept to my Unix friends they agree that 
>such a brilliant idea should have been implemented in Unix as well.

They'd do better stealing the idea from DEC, specifically from VMS.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: TCBJLB doesn't point to a DCB

[Shmuel Metz (Seymour J.)]

In <5737414652770988.wa.woodagozemail.com...@listserv.ua.edu>, on
11/29/2013
   at 11:25 AM, Andy Wood  said:

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

Whoops! 

That would be a 24-bit address, not a 31-bit address, and bits 0-7
should be zeroed. Which still leaves the question of whether DESERVE
will make a special case of the linklist DCB.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Paul Gilmartin]

On 2013-11-29, at 12:16, John Gilmore wrote:

> Under OS/360 the notional, antetypical 'longest' index had the syntax
> 
> 
> 
> Then, since  values could be at most 8 characters in length, 5
> x 8 + 4 yielded the maximal character count of 44.  The 44-character
> and 8-character maxima remain; the 5-level maximum does not.
>  
It should be easy to relax the 8-character maximum (except,
perhaps on the HLQ) without incompatibility with existing data
areas, even was done for the antetypical 5-level maximum.

In an article here about a week ago that I haven't the stamina
to find, the writer argued that the customary syntactic limits
should be retained in new or upgraded components for reasons
of some sort of compatibility.

Hmmm.  Called from Assembler, allocation, BLDL, STOW, and I
suspect (haven't tried) ATTACH, LINK, LOAD, and XCTL support
far beyond the customary majuscule alphameric plus a handful
of special characters.  Similarly for Binder with CASE(MIXED)
and for catalog with DISABLE(DSNCHECK) in effect.

I disagree with that writer.  In an environment where facility
A accepts a more tolerant syntax and facility B accepts only a
more restrictive syntax, if I were crafting an application that
might interact with either A or B, what should I do?  I might
choose to support the syntax of A, aware of the risk that I
might create objects that would be inaccessible to B, or I
might choose to support only the syntax of B, aware of the
risk that I would be unable to access objects created by A.

I would unhesitatingly choose A's syntax; in fact the union of
all the grammars I might need to deal with.

-- gil

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[John Gilmore]

Todd Burrell is right.  The secondary-school algebra is immediate:

n x 1 + n - 1 = 44, 2n - 1 = 44, n = 45/2 = 22.5, floor(22.5) = 22.

Twenty-two levels is of course clumsy for human use, but
program-constructed indices having so many levels may well be useful
in some situations.

John Gilmore, Ashland, MA 01721 - USA

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

[Gerhard Postpischil]

On 11/29/2013 10:26 AM, MichealButz wrote:

The documentation says the TCBJLB points to a DCB of the first library
searched for a LOAD module for a program running under that task


Can you provide a reference - the statement may be true in some limited 
context. But for tasklibs, the DCB is set for EXCP (or could be BPAM if 
user provided) and can support up to 16 libraries, with a total extent 
limit of 256.



I have looked at various TCB's PSATOLD ASXBFTCB and if that address were a
DCB at offset X'28' there would be a CL8 DDname


I just tried this on my system. FTCB has 0 for TCBJLB (region control 
task). LTCB actually turned up some DCBs, all of which were open and 
pointed to an EXCP DCB.


Re Shmuel's earlier comment - TCBJLB and DCBDDNAM coincidentally both 
have an offset of x'28'.


Gerhard Postpischil
Bradford, Vermont

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)]

Should be 22 levels (A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.R.S.T.U.V is a valid 
DSN).

Todd Burrell, PMP, ITIL Expert | Project Manager | ITSO AHB | Centers for 
Disease Control and Prevention (CDC)
Contractor - HP Enterprise Services | 1600 Clifton Rd, Building 21, MS D24, RM 
1300 | Atlanta, GA 30338 | 404-971-7275 (Blackberry) 404-723-2017 (Mobile) | 
z...@cdc.gov


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is for use only by the intended recipient. If you received this in 
error, please notify the sender and delete the communication from all computers.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Babonas
Sent: Friday, November 29, 2013 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

I don't recall the "official" limit.  I did just allocate 
USER123.A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.RS
Not sure what this proves..




On 11/29/2013 12:49 PM, Gerhard Postpischil wrote:
> On 11/29/2013 12:36 PM, Paul Gilmartin wrote:
>> There is no "limitation ... of ... 5 levels"  Hasn't been for a long 
>> time; perhaps never was.
>
> While I don't remember a 5-level limit, there always was (and will 
> be?) a practical limit. Using every possible legal name, even at a 
> single level, exhausts space available on any early DASD.
>
> Gerhard Postpischil
> Bradford, Vermont
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[John Gilmore]

Under OS/360 the notional, antetypical 'longest' index had the syntax



Then, since  values could be at most 8 characters in length, 5
x 8 + 4 yielded the maximal character count of 44.  The 44-character
and 8-character maxima remain; the 5-level maximum does not.

John Gilmore, Ashland, MA 01721 - USA

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Tony Babonas]

I don't recall the "official" limit.  I did just allocate
USER123.A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.RS
Not sure what this proves..




On 11/29/2013 12:49 PM, Gerhard Postpischil wrote:

On 11/29/2013 12:36 PM, Paul Gilmartin wrote:

There is no "limitation ... of ... 5 levels"  Hasn't been for a long
time; perhaps never was.


While I don't remember a 5-level limit, there always was (and will be?)
a practical limit. Using every possible legal name, even at a single
level, exhausts space available on any early DASD.

Gerhard Postpischil
Bradford, Vermont

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


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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Gerhard Postpischil]

On 11/29/2013 12:36 PM, Paul Gilmartin wrote:

There is no "limitation ... of ... 5 levels"  Hasn't been for a long
time; perhaps never was.


While I don't remember a 5-level limit, there always was (and will be?) 
a practical limit. Using every possible legal name, even at a single 
level, exhausts space available on any early DASD.


Gerhard Postpischil
Bradford, Vermont

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

Re: OT? Opinion article on software design being "deliberately unfriendly"

[Farley, Peter x23353]

Most interesting talk.  Many thanks for the link.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, November 29, 2013 11:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT? Opinion article on software design being "deliberately 
unfriendly"

On Wed, 27 Nov 2013 14:21:47 -0500, John Gilmore wrote:

>Shmuel characterizes my notion that there is an ineluctable conflict
>between power andease of use as "a copout".
>
>I wish it were; but here the microsoft view that choices are the enemy
>is often correct.
>
>Users do not ordinarily know "what they want to do" in any
>constructive sense.  They have global ease-of-use and performance
>goals, functional objectives.  They seldom have even a vague notion
>what processing strategies are in use and what effects the
>parameterizations/choices available to them will have on performance
>or resource use.
>...
http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html

--


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


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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Ted MacNEIL]

You can (in theory -- I have) create a dataset:
A.B.C...
Which would limit you to 22 levels.
The level is not the limit: it's the combination of node length (8 bytes) and 
DSN length (44) that determines 'levels'.
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: Paul Gilmartin 
Sender:   IBM Mainframe Discussion List 
Date: Fri, 29 Nov 2013 11:36:21 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

On Thu, 28 Nov 2013 20:08:59 -0600, Ze'ev Atlas wrote:
>
>What I envision is a central system catalog that any file name created 
>(reasonably or virtually no limitations on file names, level of hierarchies or 
>any other such limitations [obviously more, much more than 44 characters and 5 
>levels])
> 
There is no "limitation ... of ... 5 levels"  Hasn't been for a long time;
perhaps never was.

-- gil

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

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Ze'ev Atlas]

>Mount point is dynamic, not static. Its more analogous to volser than
to device address.

Again, you discuss the shortcoming of a specific system while I have a broad 
view.  Implementation would have to take things like volser, mount points or 
whatever and hide them once and for all from the user

>>Once such a thing is implemented, all you need to do is mention the
>>file name or alias, regardless of where in the system or file system
>>you are. 

>When I ask for 'SYS1.LINKLIB', which of my 20 SYS1.LINKLIB data sets
do I get?

There would always be the need to disambiguate.  That need would either be 
answered either automatically by the system examining the context, or, and I've 
mentioned it, one may add hints to lead the system to the one file he or she 
needs.  The example given by Shmuel is z/OS specific and if the user is 
sophisticated enough to need a specific SYS1.LINKLIB, he or she would probably 
be sophisticated enough to provide hinting information.  Otherwise, whatever 
the system chooses is probably the correct one.

>>For people who are not techno-geeks this is much simpler than
>>anything available today.

>In what way is it simpler than the catalog and directory structures
that currently exist? The ordinary user does not need to worry about
creating user catalogs or about mounting file systems on empty
directories. It's all transparrent to him.

That's correct and that's where I took the idea from.  That concept needs 
improvements which many in this conversation  had alluded to.

Another great idea from the z/OS that deserve implementation in that context 
(i.e. Central System Catalog) is the famous GDG.  Whenever I explain the 
concept to my Unix friends they agree that such a brilliant idea should have 
been implemented in Unix as well.

ZA

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

Re: CRONTAB and SYSLOGD

[Fred Kaptein]

Hello,

We are looking for the statements to insert into  /etc/syslog.conf   to do the 
following
- retain the unix syslog in a file directory /xxx/   
   (we have not yet decided on a directly, but please let us know if there 
is an IBM recommended directory)
- only retain 30 days of the unix syslog data (it is not important if the 
data is lost across IPLS)

Thank you.

 

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Paul Gilmartin]

On Thu, 28 Nov 2013 20:08:59 -0600, Ze'ev Atlas wrote:
>
>What I envision is a central system catalog that any file name created 
>(reasonably or virtually no limitations on file names, level of hierarchies or 
>any other such limitations [obviously more, much more than 44 characters and 5 
>levels])
> 
There is no "limitation ... of ... 5 levels"  Hasn't been for a long time;
perhaps never was.

-- gil

--
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.) 
 wrote:

>In <0717adf1-8fde-41db-940d-77a882817...@optonline.net>, on 11/29/2013
>   at 10:45 AM, Micheal Butz  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: DFSMSHSM TAPESECURITY(RACF)

[Arye Shemer]

Thank you Elardus,
Yes, i meant Control-T.
We are using physical cartridges no VTS.
Thanks for your suggestions and for sharing your settings.

Best regards,
Arye Shemer


On 28 November 2013 08:07, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Arye Shemer wrote:
>
> >He intial request was to take the strictest security method HSM
> provide (TAPESECURITY(RACF)).
>
> What we're using:
>
> SETSYS NORACFIND
> SETSYS TAPESECURITY(RACF)
> SETSYS NOERASEONSCRATCH
> SETSYS NOPROFILEBACKUP
>
> These settings are practical for us with good security. YMMV.
>
> >After some thoughts and discussion he seems to prefer that his tape
> managemnet system (CNTL-T) would take care of the security (as suggested
> here on the thread).
>
> Are you referring to Control-T? If so, yes, using tape management for
> security is a good idea. You will need some profiles in FACILITY class to
> turn on security as well some exits. Just remember these things in RACF:
> TAPEDSN and TAPEVOL.
>
> How many volsers do you have? This will determine on how you define
> profiles in TAPEVOL. Are you using VTS or physical cartridges?
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Paul Gilmartin]

On Wed, 6 Nov 2013 10:06:23 +0800, David Crayford wrote:

>On 6/11/2013 8:31 AM, Jon Perryman wrote:
>
>> ... standard security on z/OS is provided by a single programming interface 
>> regardless of the ESM you are using.
>
>It's a shame to same can't be said of the file system. In Unix
>everything is a file and shares the same API. I use the same interface
>for files, sockets, printers, terminals, modems or any other device.
>I wish OS/360 had a similar unifying design principle back in the day.
> 
I believe OS/360 started out with the right idea: all I/O was done via
DCBs.  But as capabilities were extended, the designers elected to
develop alternatives rather than broadening existing interfaces.
E.g. TSO's terminal I/O's spurning DCBs.

-- gil

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

Re: Rexx (was: OT? ... "deliberately unfriendly")

[Paul Gilmartin]

On Fri, 29 Nov 2013 20:59:26 +1100, Paul Gillis wrote:

>I have been using Regina Rexx for some years, started when I was to teach a
>Rexx course and wanted a good Windows Rexx capability. The OS interfaces are
>different, but easy enough to use, and it is well documented. It can be
>found at http://regina-rexx.sourceforge.net/ it is obviously being updated
>regularly as I am using 3.5 and 3.7 is available and the price is right.
>Sample of I/O code below. Other OS interfaces I have not used, no need yet.
> 
IOW, it uses Rexx-standard I/O instead of z-peculiar I/O.

>/* Read the file into an array */
>INFILE1  = "C:\WineBase32\TextFile\WineList.csv"
>lines = 0
>do while lines(infile1)>0
>   lines = lines + 1
>   iline.lines = linein(infile1)
>end
>iline.0 = lines
> 
(But it would be useful to be able to read a file into a compound
variable with a single instruction rather than coding a loop.
Hmmm... I wonder how this works if infile is a terminal?)

Disastrously, the z/OS Rexx provides two instances of the
standard Rexx I/O.  One, adjunct to the Rexx compiler, deals
only with legacy data sets; the other, adjunct to Unix System
services, deals only with UNIX files.  Conway's law.  I wonder
whether CMS Rexx deals alike with MDFS, SFS, and BFS flles, 
accessing SFS files via directory paths rather than filemodes.

-- gil

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

Re: DESERV function get DCB address

[Shmuel Metz (Seymour J.)]

In , on 11/29/2013
   at 11:29 AM, Micheal Butz  said:

>Using TCBJLB as the input DCB
>For DESEREV I get a return code of 
>X'0C' reason X'421' invalid DCB 

Yes, but you wrote that you got incorrect results from BLDL; it was
those details that I asked about.

As for DESERVE, it would appear that linklist DCB's don't get special
treatment; it might be reasonable to submit a requirement to IBM for
DESERVE support of the link list, either the way that BLDL supports it
or by making a special case in the validity checking.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: OT? Opinion article on software design being "deliberately unfriendly"

[Paul Gilmartin]

On Wed, 27 Nov 2013 14:21:47 -0500, John Gilmore wrote:

>Shmuel characterizes my notion that there is an ineluctable conflict
>between power andease of use as "a copout".
>
>I wish it were; but here the microsoft view that choices are the enemy
>is often correct.
>
>Users do not ordinarily know "what they want to do" in any
>constructive sense.  They have global ease-of-use and performance
>goals, functional objectives.  They seldom have even a vague notion
>what processing strategies are in use and what effects the
>parameterizations/choices available to them will have on performance
>or resource use.
>...
http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html

-- gil

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

[Shmuel Metz (Seymour J.)]

In <0717adf1-8fde-41db-940d-77a882817...@optonline.net>, on 11/29/2013
   at 10:45 AM, Micheal Butz  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.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: DESERV function get DCB address

[Micheal Butz]

Using TCBJLB as the input DCB
For DESEREV I get a return code of 
X'0C' reason X'421' invalid DCB 

Sent from my iPhone

> On Nov 29, 2013, at 11:10 AM, "Shmuel Metz (Seymour J.)" 
>  wrote:
> 
> In
> ,
> on 11/28/2013
>   at 02:00 PM, MichealButz  said:
> 
>> I having been using BLDL to get program directory information I found
>> the macro to not give correct results.
> 
> Please be more specific.
> 
> -- 
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see  
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: TCBJLB doesn't point to a DCB

[Shmuel Metz (Seymour J.)]

In
,
on 11/29/2013
   at 10:26 AM, MichealButz  said:

>The documentation says the TCBJLB points to a DCB of the first
>library searched for a LOAD module for a program running under that
>task

>I have looked at various TCB's PSATOLD ASXBFTCB and if that address
>were a DCB at offset X'28' there would be a CL8 DDname

No; you have to open a DCB before you use it as a tasklib, so the
relevant layout is that for an open DCB, not that for a closed DCB.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Rexx (was: OT? ... "deliberately unfriendly")

[Shmuel Metz (Seymour J.)]

In <002701ceece9$b17baa90$1472ffb0$@pc-link.com.au>, on 11/29/2013
   at 08:59 PM, Paul Gillis  said:

>Sample of I/O code below.

The I/O code is the same as for any other ANSI compliant Rexx; the
magic word is stream.

Regina, BTW, is pretty much the default implementation of ANSI Rexx.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers

[Shmuel Metz (Seymour J.)]

In <2290167024549142.wa.zatlas1yahoo@listserv.ua.edu>, on
11/28/2013
   at 08:08 PM, "Ze'ev Atlas"  said:

>What I envision is a central system catalog that any file name
>created (reasonably or virtually no limitations on file names, 
>level of hierarchies or any other such limitations [obviously 
>more, much more than 44 characters and 5 levels]) would be 
>transparently cataloged into (by the kernel itself.)  Obviously, 
>that catalog entry would have to record (hard coded information 
>such as volser, mounting point or whatever have you) where is 
>that file resides in an absolute manner.

Mount point is dynamic, not static. Its more analogous to volser than
to device address.

>Once such a thing is implemented, all you need to do is mention the
>file name or alias, regardless of where in the system or file system
>you are. 

When I ask for 'SYS1.LINKLIB', which of my 20 SYS1.LINKLIB data sets
do I get?

>For people who are not techno-geeks this is much simpler than
>anything available today.

In what way is it simpler than the catalog and directory structures
that currently exist? The ordinary user does not need to worry about
creating user catalogs or about mounting file systems on empty
directories. It's all transparrent to him.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: DESERV function get DCB address

[Shmuel Metz (Seymour J.)]

In <0c0cd1f6-1815-4b07-8465-c57f54ae0...@optonline.net>, on 11/28/2013
   at 03:31 PM, Micheal Butz  said:

>Binyamin I saw a previous post by you

>Instructing a user to use TCBJLB
>For TSOLIB I thought that TSOLIB
>Was a task library while TCBJLB 
>Points to the joblib DCB 

[JOB|STEP]LIB is a tasklib. You need to run through the TCB chain
trying each tasklib in turn, or use BLDL to find out which is
relevant. You didn't say what the incoorect results were; is the
concatenation number wrong?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: TCBJLB doesn't point to a DCB

[Rob Scott]

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

Post-OPEN DCBs do NOT have an address at offset x'28' - it contains the DCBTIOT 
field and DCBMACRF

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Micheal Butz
Sent: 29 November 2013 15:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TCBJLB doesn't point to a DCB

Can I use what's pointed to by TCBJLB as a param for DESERV 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

Sent from my iPhone

> On Nov 29, 2013, at 10:38 AM, Rob Scott  wrote:
> 
> The DCB foundation is a different format before and after OPEN and the 
> DCBDDNAM (and other fields) are overlaid by post-OPEN fields - for 
> example DCBTIOT
> 
> Rob Scott
> Lead Developer
> Rocket Software
> 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
> Tel: +1.781.684.2305
> Email: rsc...@rs.com
> Web: www.rocketsoftware.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of MichealButz
> Sent: 29 November 2013 15:26
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TCBJLB doesn't point to a DCB
> 
> The documentation says the TCBJLB points to a DCB of the first library 
> searched for a LOAD module for a program running under that task
> 
> 
> 
> I have looked at various TCB's PSATOLD ASXBFTCB and if that address 
> were a DCB at offset X'28' there would be a CL8 DDname
> 
> 
> 
> Thanks
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: DESERV function get DCB address

[Shmuel Metz (Seymour J.)]

In
,
on 11/28/2013
   at 02:00 PM, MichealButz  said:

>I having been using BLDL to get program directory information I found
>the macro to not give correct results.

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

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

Re: TCBJLB doesn't point to a DCB

[Micheal Butz]

Can I use what's pointed to by TCBJLB as a param for DESERV
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

Sent from my iPhone

> On Nov 29, 2013, at 10:38 AM, Rob Scott  wrote:
> 
> The DCB foundation is a different format before and after OPEN and the 
> DCBDDNAM (and other fields) are overlaid by post-OPEN fields - for example 
> DCBTIOT
> 
> Rob Scott
> Lead Developer
> Rocket Software
> 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
> Tel: +1.781.684.2305
> Email: rsc...@rs.com
> Web: www.rocketsoftware.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of MichealButz
> Sent: 29 November 2013 15:26
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TCBJLB doesn't point to a DCB
> 
> The documentation says the TCBJLB points to a DCB of the first library 
> searched for a LOAD module for a program running under that task
> 
> 
> 
> I have looked at various TCB's PSATOLD ASXBFTCB and if that address were a 
> DCB at offset X'28' there would be a CL8 DDname
> 
> 
> 
> Thanks
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Rob Scott]

The DCB foundation is a different format before and after OPEN and the DCBDDNAM 
(and other fields) are overlaid by post-OPEN fields - for example DCBTIOT

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of MichealButz
Sent: 29 November 2013 15:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TCBJLB doesn't point to a DCB

The documentation says the TCBJLB points to a DCB of the first library searched 
for a LOAD module for a program running under that task

 

I have looked at various TCB's PSATOLD ASXBFTCB and if that address were a DCB 
at offset X'28' there would be a CL8 DDname

 

Thanks


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

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

TCBJLB doesn't point to a DCB

[MichealButz]

The documentation says the TCBJLB points to a DCB of the first library
searched for a LOAD module for a program running under that task

 

I have looked at various TCB's PSATOLD ASXBFTCB and if that address were a
DCB at offset X'28' there would be a CL8 DDname

 

Thanks


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

Re: Rexx (was: OT? ... "deliberately unfriendly")

[Paul Gillis]

I have been using Regina Rexx for some years, started when I was to teach a
Rexx course and wanted a good Windows Rexx capability. The OS interfaces are
different, but easy enough to use, and it is well documented. It can be
found at http://regina-rexx.sourceforge.net/ it is obviously being updated
regularly as I am using 3.5 and 3.7 is available and the price is right.
Sample of I/O code below. Other OS interfaces I have not used, no need yet.

/* Read the file into an array */
INFILE1  = "C:\WineBase32\TextFile\WineList.csv"
lines = 0
do while lines(infile1)>0
   lines = lines + 1
   iline.lines = linein(infile1)
end
iline.0 = lines

Paul

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Scott Ford
> Sent: Friday, 29 November 2013 6:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Rexx (was: OT? ... "deliberately unfriendly")
> 
> Gil,
> 
> Haven't used Regina , but have used Open Object Rexx and like the Linux
> interface.
> 
> Scott ford
> www.identityforge.com
> from my IPAD
> 
> 'Infinite wisdom through infinite means'
> 
> 
> > On Nov 28, 2013, at 11:20 AM, Paul Gilmartin 
> wrote:
> >
> >> On Thu, 28 Nov 2013 07:41:14 -0600, Mike Schwab wrote:
> >>
> >> http://www.rexxinfo.org/
> >> http://www.rexxla.org/links/
> >>
> >>> On Thu, Nov 28, 2013 at 3:29 AM, Elardus Engelbrecht wrote:
> >>> 
> >>> I miss Rexx in command line for OS/2. I believe there are Rexx for
> windoze, but I haven't looked at it.
> >> 
> > Google finds many hits for REGINA CYGWIN.  But any Rexx stands or
> > falls on the quality of its host command interfaces.  THE?  Would you
> > want a comand interface to Notepad?
> >
> > I am very pleased with the SYSCALL command environment of Rexx for
> > z/OS (called TSO, but I can forgive that).
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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