Re: RENT binder option

[Jim Mulder]

  YDNRC.  In general, the frame steal code has no knowledge
that a frame contains a program, or that  the program
is REFR.  The only exception to that is the PLPA and EPLPA 
virtual storage ranges, for which the frame steal code does 
steal without paging out, effectively treating everything in
those ranges as conceptually REFR for stealing purposes,
regardless of the load module attributes. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

"IBM Mainframe Discussion List"  wrote on 
08/25/2021 09:10:04 PM:

> From: "CM Poncelet" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/25/2021 11:21 PM
> Subject: Re: RENT binder option
> Sent by: "IBM Mainframe Discussion List" 
> 
> IIRC The page(s) of an LMOD marked REFR can be stolen without having
> first to back it up to cache, because it can be REFReshed from cache (or
> DASD) and continue to execute as if its page(s) had not been stolen -
> e.g. in the PLPA. If it modified itself, it would hit a S0C4-4. AFAIK A
> backup/swap-out would be needed if it was marked RENT but not REFR.



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

Re: LOAD with ADDR

[Jim Mulder]

  If you want to know what is going on, you should 
answer the questions that the z/OS 
diagnosis expert (me) already asked:

Was the module loaded from a PDS, or from a PDSE?

 What does the D DIAG  command display (or 
VERBX IGVDGNIP   under IPCS)? 

  What was the source address and length for the MVCL? 

  What was the target address and length for the MVCL?

  What was the Translation Exception Id?

  From a dump, what was the length and address from the 
system trace entry for the GETMAIN which obtained the module storage?

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on 
08/25/2021 10:41:37 PM:

> From: "Joseph Reichman" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/25/2021 11:18 PM
> Subject: Re: LOAD with ADDR
> Sent by: "IBM Mainframe Discussion List" 
> 
> That’s what originally had until I got a s0c4 noticed the length of 
> one of the load modules was off
> 
> 
> 
> > On Aug 25, 2021, at 10:37 PM, Tom Brennan 
>  wrote:
> > 
> > My old code that loaded common executables did a LOAD without 
> ADDR just to get the length, then a DELETE, then a GETMAIN for CSA, 
> then a LOAD with ADDR=
> > 
> > Don't know if this helps or not in your situation because all my 
> code was written in assembler.
> > 
> >> On 8/25/2021 7:01 PM, Joseph Reichman wrote:
> >>  Hi
> >>  I am just posting this to report the issue I had LOAD ing a program 
named
> >> OPENFILE (Its Metal C Im sure that's not the issue) I had posted that 
it
> >> gave me erroneous length of X'4000'
> >> When I did a browse in ISPF I saw it as 3530 same as the linkmap
> >>  I subsequently re-did my coding with help of those on the listserv 
did a
> >> BLDL to determine the length of all the programs I wanted to move to 
CSA.
> >>  I then did a STORAGE from SP=228
> >>  And started doing LOAD EPLOC= DCB = and more importantly ADDR= 
> (pointing it
> >> to the area I wanted to load the proram) when I got the program 
OPENFILE
> >> which had returned X'4000'  it now returned the correct length inR1 
X'6A6'
> >> multiply by 8
> >>  Is 3530
> >>   Thing is something is up Contents Supervisor (CSV)
> >>  thanks




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

Re: SCRT and SMF ID

[Attila Fogarasi]

Duplicate SMFID is supported now using SIDMAP to map each
model-serial/SMFID pair to a unique SID.  I think within a single CEC the
SMFID must be unique to feed the same SCRT.  Presumably this was done years
ago for country multiplex pricing capability.

On Thu, Aug 26, 2021 at 12:37 AM Radoslaw Skorupka 
wrote:

> I'm pretty sure there was a requirement to have unique SMF ID (sysid)
> for every system contributing SMF records to SCRT.
>
> However now I cannot find it in the documentation.
>
> Is it still valid requirement or it was relieved?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> 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: LOAD with ADDR

[Tom Brennan]

Interesting... I never had that problem.  In fact, I think that code 
assembled and worked first time.  Just kidding... I hope that thread is 
finished now.


On 8/25/2021 7:41 PM, Joseph Reichman wrote:

That’s what originally had until I got a s0c4 noticed the length of one of the 
load modules was off




On Aug 25, 2021, at 10:37 PM, Tom Brennan  wrote:

My old code that loaded common executables did a LOAD without ADDR just to get 
the length, then a DELETE, then a GETMAIN for CSA, then a LOAD with ADDR=

Don't know if this helps or not in your situation because all my code was 
written in assembler.


On 8/25/2021 7:01 PM, Joseph Reichman wrote:
  Hi
  I am just posting this to report the issue I had LOAD ing a program named
OPENFILE (Its Metal C Im sure that's not the issue) I had posted that it
gave me erroneous length of X'4000'
When I did a browse in ISPF I saw it as 3530 same as the linkmap
  I subsequently re-did my coding with help of those on the listserv did a
BLDL to determine the length of all the programs I wanted to move to CSA.
  I then did a STORAGE from SP=228
  And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
to the area I wanted to load the proram) when I got the program OPENFILE
which had returned X'4000'  it now returned the correct length in R1 X'6A6'
multiply by 8
  Is 3530
   Thing is something is up Contents Supervisor (CSV)
  thanks
   _
  Scanned by McAfee
  and confirmed virus-free.
--
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: LOAD with ADDR

[Joseph Reichman]

That’s what originally had until I got a s0c4 noticed the length of one of the 
load modules was off



> On Aug 25, 2021, at 10:37 PM, Tom Brennan  wrote:
> 
> My old code that loaded common executables did a LOAD without ADDR just to 
> get the length, then a DELETE, then a GETMAIN for CSA, then a LOAD with ADDR=
> 
> Don't know if this helps or not in your situation because all my code was 
> written in assembler.
> 
>> On 8/25/2021 7:01 PM, Joseph Reichman wrote:
>>  Hi
>>  I am just posting this to report the issue I had LOAD ing a program named
>> OPENFILE (Its Metal C Im sure that's not the issue) I had posted that it
>> gave me erroneous length of X'4000'
>> When I did a browse in ISPF I saw it as 3530 same as the linkmap
>>  I subsequently re-did my coding with help of those on the listserv did a
>> BLDL to determine the length of all the programs I wanted to move to CSA.
>>  I then did a STORAGE from SP=228
>>  And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
>> to the area I wanted to load the proram) when I got the program OPENFILE
>> which had returned X'4000'  it now returned the correct length in R1 X'6A6'
>> multiply by 8
>>  Is 3530
>>   Thing is something is up Contents Supervisor (CSV)
>>  thanks
>>   _
>>  > mail_content=emailclient?utm_medium=email_source=link_campaign=s
>> ig-email_content=emailclient>Scanned by McAfee
>> > mail_content=emailclient?utm_medium=email_source=link_campaign=s
>> ig-email_content=emailclient>  and confirmed virus-free.
>> --
>> 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: LOAD with ADDR

[Tom Brennan]

My old code that loaded common executables did a LOAD without ADDR just 
to get the length, then a DELETE, then a GETMAIN for CSA, then a LOAD 
with ADDR=


Don't know if this helps or not in your situation because all my code 
was written in assembler.


On 8/25/2021 7:01 PM, Joseph Reichman wrote:
  


Hi

  


I am just posting this to report the issue I had LOAD ing a program named
OPENFILE (Its Metal C Im sure that's not the issue) I had posted that it
gave me erroneous length of X'4000'

When I did a browse in ISPF I saw it as 3530 same as the linkmap

  


I subsequently re-did my coding with help of those on the listserv did a
BLDL to determine the length of all the programs I wanted to move to CSA.

  


I then did a STORAGE from SP=228

  


And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
to the area I wanted to load the proram) when I got the program OPENFILE
which had returned X'4000'  it now returned the correct length in R1 X'6A6'
multiply by 8

  


Is 3530

  

   

  


Thing is something is up Contents Supervisor (CSV)

  


thanks


   _

  
Scanned by McAfee
  and confirmed virus-free. 

--
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: LOAD with ADDR

[Joseph Reichman]

I need these programs to be addressable from every address space 

BTW I checked and didn’t have 2 copies of that program which gave me a 
different length 

> On Aug 25, 2021, at 10:08 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Wed, 25 Aug 2021 22:01:17 -0400, Joseph Reichman wrote:
>>   ...
>> And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
>> to the area I wanted to load the proram) when I got the program OPENFILE
>> which had returned X'4000'  it now returned the correct length in R1 X'6A6'
>> multiply by 8
>> 
> How much are you saving by doing this?
> 
> -- 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: LOAD with ADDR

[Paul Gilmartin]

On Wed, 25 Aug 2021 22:01:17 -0400, Joseph Reichman wrote:
>...
>And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
>to the area I wanted to load the proram) when I got the program OPENFILE
>which had returned X'4000'  it now returned the correct length in R1 X'6A6'
>multiply by 8
> 
How much are you saving by doing this?

-- gil

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

LOAD with ADDR

[Joseph Reichman]

 

Hi

 

I am just posting this to report the issue I had LOAD ing a program named
OPENFILE (Its Metal C Im sure that's not the issue) I had posted that it
gave me erroneous length of X'4000' 

When I did a browse in ISPF I saw it as 3530 same as the linkmap

 

I subsequently re-did my coding with help of those on the listserv did a
BLDL to determine the length of all the programs I wanted to move to CSA.

 

I then did a STORAGE from SP=228

 

And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
to the area I wanted to load the proram) when I got the program OPENFILE
which had returned X'4000'  it now returned the correct length in R1 X'6A6'
multiply by 8 

 

Is 3530

 

  

 

Thing is something is up Contents Supervisor (CSV)

 

thanks


  _  

 
   Scanned by McAfee
  and confirmed virus-free.

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

Re: RENT binder option

[CM Poncelet]

IIRC The page(s) of an LMOD marked REFR can be stolen without having
first to back it up to cache, because it can be REFReshed from cache (or
DASD) and continue to execute as if its page(s) had not been stolen -
e.g. in the PLPA. If it modified itself, it would hit a S0C4-4. AFAIK A
backup/swap-out would be needed if it was marked RENT but not REFR.

On 25/08/2021 22:41, Paul Gilmartin wrote:
> On Wed, 25 Aug 2021 15:56:33 -0500, Barry Lichtenstein wrote:
>
>> ... (NORENT and REFR).  The binder treats reusability as a hierarchy, REFR 
>> implies RENT, ...
> They saved a bit by allowing the reusability  to have 4 values instead of 8.
> (NORENT and REFR) could have made sense if a programmer had
> relied on them to serialize access to shared data areas.  Well, no.  CSV
> would simply load another instance.
>
>
>> On Sun, 15 Aug 2021 18:47:26 -0400 Steve Smith wrote:
>>> Seems like deja vu.  For all practical purposes, RENT and REFR (which
>>> implies RENT) have the same effect (that may be a tautology).
>>>
>>> For whatever reasons, RENT & REFR ... or for the ability to
>>> tolerate a refresh.  Neither of those things absolutely requires
>>> non-modification, so one wonders why IBM wandered off into those tangents.
>>>
> I'm trying to envision what is needed for modified code to tolerate a 
> refresh.  Field the protection exception; proceed with the refresh; 
> and re-drive the failed operation ab ovo?  I suppose.
>
> -- 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: display alias definition

[Paul Gilmartin]

On Wed, 25 Aug 2021 19:24:09 -0400, James Crudele wrote:

>The listcat will show the symbol
>
It's a pity that the SYMBOLICRELATE name *must* contain a symbol.
There are a couple distinctive behaviors of symbolic aliases that would
be valuable even if the related name contained no symbol.

-- gil

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

Re: even an old mainframer can do it

[David Crayford]

On 24/08/2021 9:25 pm, Ed Jaffe wrote:
Yeah, ad hominem and ludicrous stereotypes. "It seems like a waste of 
time to get mainframers to think that there is anything that will 
ever be as great as JCL." says everything necessary. I devoutly hope 
that he gets to work with people who fit that caricature.


Frank is a great supporter of the mainframe -- especially z/OS. Always 
has been, always will be.


I suspect his poor choice of words on Reddit (he left out a word and 
should have said "SOME mainframers") was prompted by an understandable 
frustration with certain intransigent "Luddites" who refuse to accept 
reality and actively rail against open source, DevOps, agile 
development, automated testing, modern languages, hybrid cloud, or any 
other technology adoption by the IBM Z community intended to keep the 
mainframe relevant and growing instead of withering away...



Well said! We're going through the process of transitioning from our 
traditional tooling to a modern stack using DevOps tools such as Git, 
Jenkins, Artifactory etc. It's a requirement for us to scan all of our 
code for vulnerabilities using IBM scanners for authorized code or 
Polaris and Black Duck for C/C++, Java etc. Having automation kick in to 
perform these tasks when merging a Git branch is a game changer. The 
days of a sysprog running some JCL job are well and truly over. I have 
noticed in my team a split between those who buy in to the new way and 
those who don't understand why the way they have been working for the 
last 40 years isn't good enough any more. You picked the perfect word 
with "intransigent". For the mainframe to survive in the world of cloud 
computing is hard enough without the negative reaction to change from 
seasoned mainframers. Ironically, the guys pushing the changes are some 
our most experienced mainframe guys, including Distinguished Engineers 
who work on some of the trickiest systems level code in the company.



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

Re: display alias definition

[James Crudele]

The listcat will show the symbol


> On Aug 25, 2021, at 17:39, Bill Giannelli  wrote:
> 
> how might I display or report how an alias is defined?
> I am trying to determine is a system symbol was used to create the alias and 
> "resolve" the name i.e.
> 
> ALIAS "*.RTE.LINK" points to "*.RTE2104.LINK"
> but I want to make sure it was defined with "*.RTE$SYMBOL..LINK"
> thanks
> Bill
> 
> --
> 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: display alias definition

[Retired Mainframer]

Would the LISTCAT ALL output for the alias show a SYMBOLICRELATE rather than a 
RELATE parameter?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Wednesday, August 25, 2021 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: display alias definition

how might I display or report how an alias is defined?
I am trying to determine is a system symbol was used to create the alias and 
"resolve" the name i.e.

ALIAS "*.RTE.LINK" points to "*.RTE2104.LINK"
but I want to make sure it was defined with "*.RTE$SYMBOL..LINK"
thanks
Bill

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

Re: RENT binder option

[Paul Gilmartin]

On Wed, 25 Aug 2021 15:56:33 -0500, Barry Lichtenstein wrote:

>... (NORENT and REFR).  The binder treats reusability as a hierarchy, REFR 
>implies RENT, ...

They saved a bit by allowing the reusability  to have 4 values instead of 8.
(NORENT and REFR) could have made sense if a programmer had
relied on them to serialize access to shared data areas.  Well, no.  CSV
would simply load another instance.


>On Sun, 15 Aug 2021 18:47:26 -0400 Steve Smith wrote:
>>
>> Seems like deja vu.  For all practical purposes, RENT and REFR (which
>> implies RENT) have the same effect (that may be a tautology).
>>
>> For whatever reasons, RENT & REFR ... or for the ability to
>> tolerate a refresh.  Neither of those things absolutely requires
>> non-modification, so one wonders why IBM wandered off into those tangents.
>>
I'm trying to envision what is needed for modified code to tolerate a 
refresh.  Field the protection exception; proceed with the refresh; 
and re-drive the failed operation ab ovo?  I suppose.

-- gil

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

display alias definition

[Bill Giannelli]

how might I display or report how an alias is defined?
I am trying to determine is a system symbol was used to create the alias and 
"resolve" the name i.e.

ALIAS "*.RTE.LINK" points to "*.RTE2104.LINK"
but I want to make sure it was defined with "*.RTE$SYMBOL..LINK"
thanks
Bill

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

Re: RENT binder option

[Barry Lichtenstein]

The linkage editor treated the reusability attributes individually and they 
could potentially be set independently (NORENT and REFR).  The binder treats 
reusability as a hierarchy, REFR implies RENT, RENT implies SERIALLY REUSABLE, 
so it will never set them that way.  In GOFF object modules and program objects 
reusability is treated as a single-value field, not individual bits.

The binder simply sets the attributes, there's no attempt by the binder to do 
anything but complain if the sections (CSECTs) are not consistent with the 
REUSability option set by the user.  If the option specified is more 
restrictive the binder will give a warning message (IEW2609W) , but still set 
the module reusability according to the option specified.  The default is 
always REUS=NONE.

Unlike the binder, the linkage editor may honor the module reusability over the 
option set by the user.  Note that while it is only in the PDSDE directory 
entry of load modules (not in the ESD information of load modules or OBJ object 
modules), it is available to the binder in the ESD information in program 
objects and GOFF object modules, as well as in the PDS and PDSE (PMAR) 
directory entries. And actually the binder can be told to honor the reusability 
within the module as well, by using the option COMPAT(LKED). Then the binder 
will issue an informational message (IEW2664I) instead of a warning message, 
and honor the "downgraded" reusability.

Also the binder will take the most restrictive reusability specified as a 
simple option name, regardless of order (I know of no other binder options that 
work this way).  So PARM='REFR,NORENT' gets you REFR.  To "reset" to 
non-reentrant you'd have to use the binder syntax REUS(NONE) (or equally 
REUS=NONE).

To the original DLL question: Languages like C may have data/variables which 
are writable (residing in the writable-static area, WSA). There was a time and 
I think in some cases it is still true, where the load point of the module is 
used by LE to determine that the module was already loaded for a given enclave. 
LE may use that information to decide whether it should create a new WSA 
instance associated with that DLL (module), which is shared for the entire LE 
enclave.  Thus not having the module marked as RENT could cause problems, with 
multiple instances of data/variables are seen in different 
modules/procedures/functions of the entire DLL application.

On Sun, 15 Aug 2021 18:47:26 -0400 Steve Smith  wrote:
>
> Seems like deja vu.  For all practical purposes, RENT and REFR (which
> implies RENT) have the same effect (that may be a tautology).
>
> For whatever reasons, RENT & REFR were defined such that they didn't
> accurately describe how they were implemented.  What the OS wanted was
> protected memory for programs (and good programmers want that too).  In
> effect, both mean that program storage cannot be modified during
> execution.  But the module attribute definitions go on about the ability
> for multiple tasks to simultaneously use the module, or for the ability to
> tolerate a refresh.  Neither of those things absolutely requires
> non-modification, so one wonders why IBM wandered off into those tangents.
>
> On the converse, it's not that hard to write read-only code that is not
> reentrant (thread-safe in newspeak).  And nothing in z/OS cares a bit...
> you just get unpredictable results.  Actual reentrancy requires interlocked
> access to any shared memory; avoiding variables embedded within the program
> module is just the beginning.
>
> The bottom line is that Program Fetch allows RENT modules to be shared,
> REUS is just a weird ENQ trick, and otherwise you get multiple copies.  I
> really don't know if REFR has any effect over RENT.  Perhaps it's required
> for PLPA modules.
>
> sas

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

Re: New RFE - enhance man -k processing

[Lionel B. Dyck]

Sadly, the complexity of the MANPATH is just part of doing business in OMVS 
with anything more than the IBM supplied environment. And with Rocket's 
approach using Conda it can be even more complex depending on how much is under 
conda control, in which case the MANPATH may not be active for the user until 
they activate a conda environment.


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, August 25, 2021 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New RFE - enhance man -k processing

On Wed, 25 Aug 2021 09:47:30 -0500, Lionel B. Dyck  wrote:
>...
>The gist of the RFE is for IBM to enhance the 'man -k' process to 
>support multiple whatis files (e.g. whatis.vendora, whatis.vendorb, .) 
>within the MANPATH.
>
>The URL is
> 
>152155>
>
I notice that on Linux such man pages appear in /usr/local/share/man/.  The 
z/OS analogue might be /usr/lpp/man/.

And on MadOS I have:
547 $ echo $MANPATH
/usr/local/share/man:/usr/share/man

548 $ ls -a /usr/local/share/man/man1 | wc
 231 2312303
-- a bunch; mostly symlinks to supplier installation directories.

Your suggestion avoids the name collision if different vendors supply products 
with identical names at the cost of burdening the end user with a complex 
MANPATH.

-- 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: New RFE - enhance man -k processing

[Paul Gilmartin]

On Wed, 25 Aug 2021 09:47:30 -0500, Lionel B. Dyck  wrote:
>...
>The gist of the RFE is for IBM to enhance the 'man -k' process to support
>multiple whatis files (e.g. whatis.vendora, whatis.vendorb, .) within the
>MANPATH.
>
>The URL is
> 
>
I notice that on Linux such man pages appear in /usr/local/share/man/.  The 
z/OS analogue
might be /usr/lpp/man/.

And on MadOS I have:
547 $ echo $MANPATH
/usr/local/share/man:/usr/share/man

548 $ ls -a /usr/local/share/man/man1 | wc
 231 2312303
-- a bunch; mostly symlinks to supplier installation directories.

Your suggestion avoids the name collision if different vendors supply products 
with
identical names at the cost of burdening the end user with a complex MANPATH.

-- gil

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

New RFE - enhance man -k processing

[Lionel B. Dyck]

I've submitted an RFE for your consideration (and vote if you agree).  

The gist of the RFE is for IBM to enhance the 'man -k' process to support
multiple whatis files (e.g. whatis.vendora, whatis.vendorb, .) within the
MANPATH.

The URL is
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=152155

Thank you for your votes - feel free to add to the comments of the RFE if
you and agree.

_
Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

"Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are."   - - - John Wooden

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

SCRT and SMF ID

[Radoslaw Skorupka]

I'm pretty sure there was a requirement to have unique SMF ID (sysid) 
for every system contributing SMF records to SCRT.


However now I cannot find it in the documentation.

Is it still valid requirement or it was relieved?

--
Radoslaw Skorupka
Lodz, Poland

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

Re: How do we post files here?

[Paul Gilmartin]

What are you replying to?  I see no related prior ply.

On Wed, 25 Aug 2021 13:44:21 +, Robert Prins wrote:

>On 2021-08-24 20:23, Donald Johnson Jr. wrote:
>> Hey fans! I have a couple example files I want to post here, but don't want
>> to  lose the formatting... one of them is a notoriously long 250-line Rexx 
>> program
>> :) and the other is a small JCL file.
>
Various answers:

o Get a better mailer; one that doesn't screw with your formatting; 
smart-quote; etc.

o Post via the web  interface.  It seems to respect one's formatting.  Long 
lines and non-ASCII characters such as "π" may result in Q-P encoding.  But 
that's revertible.

o Add a fictitious ".txt" extension to your file (e.g. program.JCL.txt) and 
post it as an attachment.  Once I posted a MIME-encoded binary file using a 
technique such as that and successfully decoded it when I received it.

Or, one of Robert's suggestions:

>Keep the LRECL to 72 characters or less, and end every line with a hard cr/lf.
>
>Better, get a free account on neocities.org, or any other provider of (free)
>webspace, and create a few simple pages, feel free to copy and adapt my z/OS
>pages below.

-- gil

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

Re: Programs that work right the first time.

[Peter Vander Woude]

I think the only time I wrote something that ran correctly the first time, was 
back in college coding in assembler on a Univac EXEC O/S system, where I was 
writing a program for a class, and I did have the program working, but didn't 
like how I had written one section, and completely rewrote the section of code, 
at the terminal (we only could use the terminal for like 30 minutes at a time), 
just working the logic in my head.  Submitted job to assemble and run and no 
assembly errors and the section I rewrote ran perfectly.

Nowadays, I do most of my development in rexx and some of them have some tricky 
logic in them.  Yes there are some that are small, but a number of them are 
close to 2,000 lines of code (with comments) and of course those longer ones do 
not usually run right the first time.

Peter

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

Re: Relocatability (was: Load Library Module Length ...)

[Seymour J Metz]

1024 in OS/360; 2048 in OS/VS1.

Yes, IEHIOSUP. I'm pretty sure that only O/C/EOV had WTF tables.

TSO worked just fine on SVS; BTDT,GTTS.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Greg Price [greg.pr...@optusnet.com.au]
Sent: Tuesday, August 24, 2021 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Relocatability (was: Load Library Module Length ...)

On 8/24/2021 8:23 AM, Seymour J Metz wrote:
> OS/360 and OS/VS1 had SVC transient areas. No adcons were allowed in type 3 
> and 4 SVC routines.

1024-byte storage areas, perhaps?

PGM=IEHIOSUP anyone?

Did I get the name right?
It was for zapping TTRs into SYS1.SVCLIB members whenever the members
were moved such as after a compress, IIRC.

Yep - sure glad I started on MVS and not earlier systems.
Imagine not having TSO (with your own address space) to play on...

:)

Cheers,
Greg

--
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: Relocatability (was: Load Library Module Length ...)

[Seymour J Metz]

My recollection is that only O/C/EOV had Where To Go (WTG) tables/. All type 
IV, pretty much by definition.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe 
Monk [joemon...@gmail.com]
Sent: Tuesday, August 24, 2021 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Relocatability (was: Load Library Module Length ...)

IEHIOSUP only applied to Type IV SVCs, IIRC.

Joe

On Tue, Aug 24, 2021 at 10:28 AM Greg Price 
wrote:

> On 8/24/2021 8:23 AM, Seymour J Metz wrote:
> > OS/360 and OS/VS1 had SVC transient areas. No adcons were allowed in
> type 3 and 4 SVC routines.
>
> 1024-byte storage areas, perhaps?
>
> PGM=IEHIOSUP anyone?
>
> Did I get the name right?
> It was for zapping TTRs into SYS1.SVCLIB members whenever the members
> were moved such as after a compress, IIRC.
>
> Yep - sure glad I started on MVS and not earlier systems.
> Imagine not having TSO (with your own address space) to play on...
>
> :)
>
> Cheers,
> Greg
>
> --
> 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: How do we post files here?

[Robert Prins]

On 2021-08-24 20:23, Donald Johnson Jr. wrote:

Hey fans! I have a couple example files I want to post here, but don't want
to  lose the formatting... one of them is a notoriously long 250-line Rexx 
program
:) and the other is a small JCL file.


Keep the LRECL to 72 characters or less, and end every line with a hard cr/lf.

Better, get a free account on neocities.org, or any other provider of (free) 
webspace, and create a few simple pages, feel free to copy and adapt my z/OS 
pages below.


Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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