Re: RENT binder option

[Greg Price]

On 8/31/2021 11:35 AM, Jim Mulder wrote:

Yes, I know the lines from that show from having
played in the orchestra for it here:

https://countyplayers.org/icpdb/shows/0502.html


I expect you chatted about diagnostic techniques with Dave during breaks 
in rehearsal...


O-O
\_/

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

Re: UPDTE - CBTTAPE 093

[Greg Price]

On 8/30/2021 5:35 PM, Robert Prins wrote:

I'm clueless, so I've created

https://prino.neocities.org/temp/pc.h-hx.xmit
https://prino.neocities.org/temp/v496.file093.xmit

https://prino.neocities.org/temp/h-h.zall.xmit
https://prino.neocities.org/temp/h-h.cntl.xmit

1) The PDS containing four members that hang SuperC
2) The original version of UPDTE I'm using
3) The PC uploaded file containing the four members in 1)
4) The JCL to load the PDS with the PC uploaded data - need to change a
"vol=ref"


Rob, it seems that pc.h-hx.xmit is really another copy of the UPDTE source.

Any chance that the XMIT of it did not work?
Perhaps because it was corrupt?

Anyway, predictably, UPDTE writes the length of the input record to the 
output block.  BPAM/BSAM do not deblock - as long as the BDW length 
indicator does not exceed DCBBLKSI, they are happy.


QSAM is not happy when the RDW length indicator exceeds DCBLRECL.

ISPF obviously just copied the LRECL-based data width from the start of 
the long records for presentation purposes.


REVIEW complains about lengths in general without showing the data, and 
the VERIFY subcommand of PDS reports:

PDS813E RECORD LENGTH OF300 EXCEEDS THE MAXIMUM DCB LRECL


Cheers,
Greg

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

[Greg Price]

On 8/26/2021 1:54 PM, Jim Mulder wrote:

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.


I have a memory that decades ago a CLPA failed because at least 1 PLPA 
module was not linked with RENT.


Anyone know if a non-RENT marked PLPA module would stop a CLPA these days?

TIA.

Cheers,
Greg

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

[Greg Price]

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

Re: Load Library Module Length and Load Macro Module Length different Values

[Greg Price]

On 8/23/2021 10:20 AM, Joseph Reichman wrote:

Wonder how ISPF determines the size


I expect it looks at the directory entry like the rest of us...
:)

PDS2STOR is what I use.

Cheers,
Greg

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

Re: Filemanger abend and dynamic allocation

[Greg Price]

On 8/13/2021 8:26 AM, Sri h Kolusu wrote:

I got a soc9 divide exception

S0C9 abend is usually due to divide by zero.


Can also get it from a CVB where the decimal number is too big for 
32-bit binary, as I recently found out in one of my efforts...

:)

Cheers,
Greg

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

Re: Concatenated datasets

[Greg Price]

On 7/19/2021 3:43 AM, Mario Bezzi wrote:
Greg that's very interesting.. Could you please point me at the doc 
which explains how to get there? I have been reading the description of 
the CSVQUERY services, but while I see an OUTPATHNAM option, I can't 
find anything about the source loadlib for a regular load module.


That precise facility is not documented as such... (AFAIK)

I'd recommend you get HCL Z Asset Optimizer (aka ZAO) where its Usage 
Monitor component has done all that work for you. If your site runs IBM 
Z Software Asset Management then that will also do it.


Basically, the plan is to ascertain the DD, and then chase the relevant 
control blocks to determine the data set name.


CSVQUERY OUTPDATA often contains a DD name for load modules, and a 
pointer of interest for program objects. I don't know what an FMD is, 
but I imagine it is a Fetched Module Descriptor.


Cheers,
Greg

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

Re: Concatenated datasets

[Greg Price]

On 7/18/2021 3:32 AM, Paul Gilmartin wrote:

On Fri, 16 Jul 2021 18:59:03 -0700, Charles Mills wrote:


Yeah, it is one of those problems that seems like it should have a simple
answer "what DSN was this module loaded from? How hard is that?" but in
reality has unlimited subtleties.


Sounds like an RFE candidate.  CSV should preserve the needed information
and provide an API to access it.

What about LPA?  Original data set and member?

What should happen if the program object is replaced in the interim?


Yeah, but...

CSVQUERY gives you access to all that.

The only thing you can't find out is which library in the LPALST a 
specific module in PLPA came from. With some poetic license (assume that 
the LPALST libraries are cataloged and have not changed since CLPA time) 
then you can search that yourself.


Also, GETMAINed chunks of storage which are subsequently declared as a 
program to the system have no information about from whence they came.


If the provider is AOSL then you know it came from the program loader 
and was not fetched directly from a data set.


For UNIX a pointer to the path name is available.  If the UNIX program 
has been replaced or deleted since then then I guess you can't go look 
at it any more. For PDS/PDSE then you can compare the TTR (MLT) with the 
TTR (MLT) in the PDS/PDSE to verify if it is the same if you really want 
to obsess about it.


But most of the time you just want to know where it came from (whether 
or not it is current, because presumably it was current at fetch time) 
so most of that extra stuff can be ignored. Program size is also a good 
ad hoc test for program level matching.


Cheers,
Greg

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

Re: ISPF Edit Macro Regular Expression

[Greg Price]

On 5/28/2021 10:10 PM, Tom Brennan wrote:
I see my current code page 1047 showing up as 0417 hex - highlighted at 
the bottom of this image:

http://www.mildredbrennan.com/mvs/termtest.png


Right...
Well done to spot it there!
SYMSET0 should break that out (still in hex sorry to say) on the second 
screen line so it's a bit clearer to see.
I get CGCSGID=02B9-0417 for SYMSET0 and CGCSGID=03C3-0136 for SYMSET1 
which is the APL or graphic character set.

Greg

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

Re: ISPF Edit Macro Regular Expression

[Greg Price]

On 29/05/2021 7:30 am, Tom Brennan wrote:
But years ago I remember a bit of free code that displayed many more 
terminal characteristics.  I'm not talking ISPF terminal types (I'd 
recommend using type 3 with PCOMM, some others tell ISPF to sends 
graphic characters to the screen).  I'm talking about things like screen 
x/y size, color options, whether it can do underlining, character sets, etc.


Tom,
Might that have been TERMTEST from CBT file 134/135 ?
Cheers,
Greg

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

Re: New Spectre Vunerability

[Greg Price]

On 3/05/2021 1:16 am, David L. Craig wrote:

https://engineering.virginia.edu/news/2021/04/defenseless
doesn't mention if zArchitecture is immune, but I suspect
it is not.  Does anybody know for sure?



My mud-brain can barely comprehend this stuff, but...

1. Does this new development rely on "powerful" instructions (as they 
exist in application object code) being broken down to simpler 
instructions? ("millicode"?)


2. Was not the IBM solution on the Z platform (when activated by the 
system's owner) to slow down the whole she-bang such that there was no 
timing difference based on the data? (That is, does not the "fix" simply 
stop the look-ahead based on predictiveness by just waiting for the real 
answer on stuff such that no illegal data access actually occurs?)


3. Does that mean the effectiveness of such previously implemented 
"solutions" relies on the "level" at which they are implemented?
So if IBM implemented the "solution" at the "millicode" level then it 
might be a real fix not affected by this new scenario, but if it is/was 
implemented at a "Princples of Operations" level then it might be 
susceptible?


Or have I totally misunderstood the new information?  (Ok, let's take 
that as read, but cue someone who understands it...)

:)

Cheers,
Greg

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

Re: And the survey says...

[Greg Price]

On 29/04/2021 7:41 pm, Alexander Huemer wrote:

I was just pointed to this document: [1].
Definitely not the 3179G book you mentioned, but it seems to contain
information related to 3270 vector graphics. Maybe it helps.

-Alex

[1]https://www.slac.stanford.edu/vault/collvault/greylit/cgtm/CGTM205.pdf


Thanks Alex - I've downloaded a copy to peruse...

I read the section on the 3179-G - the author was not very complimentary 
about the device or the available documentation about it. Given his 
comparison to other graphics devices (DEC, Tektronics, etc.) I'm 
inclined to agree.


Cheers,
Greg

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

Re: And the survey says...

[Greg Price]

On 28/04/2021 2:33 am, Seymour J Metz wrote:

GDDM and PGF are the primary programs for 3270 graphics. I don't know whether 
SAS Graph requires GDDM.


Well, I've coded programmed symbols and I've coded some native vector 
graphics, but I don't know the protocols to code PC-LINK graphics. I 
gather the latter is where the host offloads more of the work to the 
workstation.


The spec for programmed symbols is documented in the 3270 Data Stream 
Programmer's Reference, but for the other two you'd probably need to do 
a VTAM trace of GDDM terminal I/O to figure out.


Native vector graphics used to be documented in the 3179G book, but that 
disappeared after the 3179G was discontinued. (If anyone has one they'd 
like to sell then please let me know.) I'd say it is very close to the 
codes that GDDM uses itself internally.


If you have a 3270 graphics application that could be made to work with 
GDDM then I'd recommend you do so because then you can let GDDM figure 
out which graphics protocol to use for any given terminal and how to 
convert your requests to the appropriate data stream orders.  I would 
guess that SAS Graph would call GDDM, but that's just a guess.


I've "assisted" (badgered?) two TN3270 client authors in adding 
programmed symbol graphics support to their products (really just 
clarified the spec and provided testing feedback). One decided the 
potential for support cases wasn't worth the effort/risk, and the other 
(Nexus Terminal) has retained it in the product.


As someone said, Nexus is very fast, and the support is very responsive 
to customers.


(Disclaimer: Both TN3270 client authors generously waived the fee to 
allow me to use their products, both of which are of excellent quality.)


The REVIEW command (available from CBT and elsewhere - release 50 should 
be coming out soon) has some code to render bitmaps (.BMP, .PCX, .GIF) 
on 3270 graphics screens (LPS and native vector graphics only) without 
using GDDM.  (GDDM will be called for PC-LINK.) Don't expect true-color 
rendering. Haven't tested large pictures lately, but small ones work 
pretty well AFAICT.


Cheers,
Greg

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

Re: IBM snew DOC Web SIte

[Greg Price]

On 10/04/2021 3:24 am, Geoff Smith wrote:

The link ishttps://ibm.biz/Bdf23Y.


Downloaded here in about 8 minutes - a bit over 2MB/s.

I must say I do like the "Open" hyperlink to the left of the title - in 
the past I have selected the wrong manual by failing to correctly follow 
the horizontal lines across to the right screen edge.


I also like the 3 metadata columns to the right of the book's title.

Very nice - best since the first 2.3 one IMO.

Cheers,
Greg

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

Re: Help please - SSIBJBID aka Job Identifier

[Greg Price]

On 2021-02-10 5:11 AM, Mario Bezzi wrote:
> Hello,
>
> I am trying to get the Job Identifier for the AS I run in.
>
> As far as I understand it is available in the SSIBJBID field of the
> Subsystem Identification Block (SSIB). This field is defined as GUPI.
> To get to the SSIB I follow the following path: psatold->tcb,
> tcbjscbb->jscb, jscbssib->ssib.
>
> In my experience this works for regular STCs, JOBs, TSUs, while it
> doesn't (returns all zeros) for USS A.S. created by fork or exec.
>
> Anyone knows if this is the expected behavior, and if for these the Job
> Identifier is available somewhere else?
>
> Thank you in advance,
> mario

I think the JSAB is the place most folks look for that, these days.

BTW, you will get more responses if you post to the list rather than the 
USENET echo of it.


Cheers,
Greg

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

Re: TSO XMIT and no member list

[Greg Price]

On 2021-01-20 10:56 AM, R.S. wrote:

I want to switch off member list when TSO XMIT ... DA(SOME.PDS) is running?
I just want to issue the command and I don't want to see loong 
member list on the screen.

Any clue?


What is PARMLIB->IKJTSOnn->TRANSREC->SYSOUT set to?

Default of * goes to terminal.

We use X which is a HELD SYSOUT class, so you can look at it later if 
there is a glitch, or ignore it if no problem.


Cheers,
Greg

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

Re: Request for help with removing sequence numbers from PDS members

[Greg Price]

On 2021-01-11 8:06 PM, Sean Gleann wrote:

Can anyone point me at some sort of solution that I might adapt, please?
Perhaps there is something on the CBT tape that might help...


I am sure the original problem has been resolved by now, but for 
completeness I will mention a couple of things which I did not see 
previously mentioned - apologies if they were.


If you want to use CBT tape utilities, I'd recommend OFFLOAD and 
PDSLOAD.  OFFLOAD the the PDS to a sequential data set and then:


Option 1: edit the sequential data set and in the edit session issue 
RENUM followed by UNNUM, and then reload the members using PDSLOAD.


Use TSO EDIT (work file) or REVIEW's Edit (data space) if the the data 
is too large for an ISPF Edit session.


Don't want to use Edit?

Option 2: After the initial OFFLOAD, use PDSLOAD (or even IEBUPDTE if 
you don't care about ISPF statistics) to reload the member to a PDS 
which has LRECL=72. Then OFFLOAD again to an LRECL=80 sequential data 
set and reload by PDSLOAD/IEBUPDTE to a PDS with LRECL=80.



BUT, I think the obvious solution is to
1. Create a new PDS with similar space but with LRECL=72.
2. Use ISPF option 3.3 to copy all of the members to the new PDS.
3. Prepare your permanent result LRECL=80 PDS (make a new one or empty 
and compress the old one).
4. Use ISPF option 3.3 to copy all of the members from the LRECL=72 PDS 
back to the LRECL=80 PDS.



Cheers,
Greg

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

Re: Isolating a CSECT within a load module

[Greg Price]

On 2021-01-04 9:46 PM, Steff Gladstone wrote:

an anyone suggest a method of isolating or extracting a CSECT
(statically-linked called program) from a load module?


Well, if it really is a load module, I'd suggest delinking it into an 
object deck. Potentially suitable delinkers are available at cbttape.org.


The one I'm most familiar with is David Noon's delinker which ended up 
being called DELINKI (to distinguish it from the the OS/360 era DELINK0, 
which I believe was enhanced in due course to cater for 31-bit modes).


The reason I am more familiar with it is because REVIEW can invoke it 
dynamically. In this usage scenario, you would display the member list 
with a REVIEW program.library command, tag the relevant member(s) with 
the necessary T selection code(s) (or else have every member delinked), 
and then issue the DELINK primary command.


Program DELINKI would be dynamically invoked to delink the selected 
program(s) into the nominated output data set (a detail which I did not 
mention before).


For your situation, I'd expect that you would be better off just 
downloading and "installing" CBT file 90 and figuring out how to run it 
as a stand-alone utility to delink the CSECT of interest. If I can 
figure out how to call it dynamically, it can't be that hard to run it 
in its own job step.


Cheers,
Greg

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

Re: Question About the Binder SETSSI statement

[Greg Price]

On 2021-01-03 3:54 AM, esst...@juno.com wrote:

Should I see the
value of the SETSSI when I browse the load module ?


No, you should see it when you (ISPF) browse the member list because (as 
Seymour indicated) the SSI is stored in the directory entry and not in 
the member contents.


If the SSI is not in view, try left/right scrolling.

I don't think ISPF shows SSI for non-program members, but the REVIEW and 
PDS commands do.


If you store your programs in a PDSE then REVIEW and PDS can show you 
the date/time stamp of the programs in the member list because they can 
be extracted from the directory entry (unlike for PDS load modules).


Cheers,
Greg

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

Re: Compiler options in object code?

[Greg Price]

On 2020-12-21 6:52 AM, Charles Mills wrote:

Saved Options String

Is it there? Does anyone know where the format of that string is documented?
Is there a utility that will display it?


I believe the PL/I version of the sos was recently added to the 
Enterprise PL/I book - and is also shipped in a PDS member in the latest 
release.


Where these things reside is generally documented in the z/OS LE Vendor 
Interfaces manual.


In REVIEW ('H' member selection code) I use the entry point to report 
some compiler options.  For C/C++ this is limited to ARCH and OPT (not 
TUNE, sorry).  For Enterprise PL/I and Enterprise COBOL more stuff is 
shown, but not everything that could be shown.


IBM Z Software Asset Management (5698-AA4) attempts to get some 
information for each compile unit (when requested), which is a slightly 
different process compared to a single report per program based on the 
entry point.


Cheers,
Greg

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

Re: IEA213A DUPLICATE VOLUME

[Greg Price]

On 2020-11-20 1:18 PM, Steve Lee wrote:

IEA213A DUPLICATE VOLUME 'RP@C03' FOUND ON DEVICES 3404 AND 4802.
IEA213A REPLY DEVICE NUMBER WHICH IS TO REMAIN OFFLINE


My memory is that you could even get these messages re duplicate volsers 
for the IPL volume.  3 guesses as to which one we wanted to keep - the 
answer being the one we were IPLing from.


At least the Fujitsu MVS-like OS would simply issue a message reporting 
which device was being put offline without requiring human instruction.


Cheers,
Greg

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

Re: UNIX fork() performance (was: SMF to capture ... )

[Greg Price]

On 2020-10-28 12:41 AM, Paul Gilmartin wrote:

(Pro tip: I use ": >>broken/$f" rather than "touch broken/$f" when I create a
file but don't need to update its timestamp.  Fewer forks; fewer keystrokes.)


Are you saying "different strokes for different forks"?

:)

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

Re: IEASYS problem

[Greg Price]

On 2020-10-04 3:20 PM, Brian Westerman wrote:

That's incorrect,  IEASYS00 is read automatically IF you don't specify anything 
else, it's just a default.  I would be in big trouble if it worked your way. :)


I think Steve was referring to:

"The system always processes the IEASYS00 member first, regardless of 
where you specify IEASYSxx suffixes. If the same parameter appears in 
both IEASYS00 and a specified alternate IEASYSxx list, the value in the 
alternate list overrides the value in IEASYS00. Also, a parameter value 
in a later specified IEASYSxx list overrides the same parameter in an 
earlier specified list."


from MVS Initialization and Tuning Reference, Chapter 1 System 
Tailoring, section: Operator entry of parameters


Cheers,
Greg

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

Re: Searching MLPA module

[Greg Price]

On 2020-09-19 12:17 AM, Peter wrote:

if LPA and MLPA are same


LPA covers PLPA, MLPA, FLPA and DLPA.

PLPA is built when CLPA is specified at IPL time.

MLPA and FLPA are built every IPL time when required - they may have 
zero size if no modules are loaded there - the modules to be load in 
MLPA and FLPA are specified by locally customized system parameters.


DLPA is for LPA modules that are dynamically loaded by programs issuing 
CSVDYLPA macros or by system SETPROG LPA commands, after IPL and after 
the storage address ranges of the various address space parts have been 
determined.  In terms of these address space parts of virtual storage, 
DLPA modules physically reside in CSA and not in PLPA, MLPA or FLPA, the 
latter 3 being optimized to use the minimum storage to hold the required 
modules and so have no "spare" space to add additional modules after IPL.


I believe DLPA is the way to go if you want a program object (as opposed 
to a load module) made resident in LPA.


DLPA was introduced in OS/390 in the 1990s so it's older than this 
century.  Do some reading to find out all you need.


If you want to track program usage including the data set name of the 
libraries from which they were originally fetched, the IBM product 
called Tivoli Asset Discovery for z/OS (how many products still have 
Tivoli in their name?) does a good job of tracking application program 
use including application programs residing in any type of LPA.


Cheers,
Greg

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

Re: rename a dataset in acs routine?

[Greg Price]

On 2020-09-18 5:36 PM, Brian Westerman wrote:

would dynamically make it HLQ.FICHE.TAPE.D091720.T1123


I don't suppose the hard-coded data set name can be changed to include 
dynamic system symbols in new low-level qualifiers which would be 
resolved to the current date and time?


Cheers,
Greg

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

Re: Architectural Level Sets

[Greg Price]

On 2020-09-05 2:11 AM, Jim Mulder wrote:

   MVS had simulation for DAS in its program check handler, which
allowed SP1.2 and its successors to run on machines which did not
have DAS.  DAS was first implemented via a microcode update
on the 3033.  It was never implemented on 158 and 168.


Well, that explains it!
:)
Cheers,
Greg

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

Re: Constant Identifiers

[Greg Price]

On 2020-09-05 3:01 AM, Paul Gilmartin wrote:

 If the number 3.1416 is used in more than one place in the program,
 or if it requires specific data or precision attributes, you must declare
 it as a named constant.


In the olden days - years before the iPhone 6 was a thing - there were 
people called Technical Writers. Now-a-days we have Information 
Developers, referred to as ID.  A few years back there seemed to be a 
religious phase where IBM ID went on a crusade to remove weasel words 
from documentation.


(I'm no longer at IBM, so I don't know if this "phase" persists or not.)

This seemed to take the form of global changes whenever a new version of 
the manual was being prepared, where every instance of a word on the 
"weasel list" was replaced by its more definite counterpart.


For example, something like:
"If the PDS directory is corrupt then the library scan may abend."
became
"If the PDS directory is corrupt then the library scan will abend."

The latter sentence implies that if the library scan did not abend then 
the PDS directory cannot be corrupt in any way, which was not the 
original information that the author was trying to convey.


You can -> You must
It may -> It will
It should - It will

That last one is probably the sort of thing they were really trying to 
fix, I expect, as in:

"If there is an I/O error, the scan should skip the bad block."
"If there is an I/O error, the scan will skip the bad block."

As it was, whole sections of text I wrote for our product took on 
meanings I hadn't intended, and sometimes the "edited" text became 
outright lies.


Anyway, in case you haven't guessed yet, that's what I think happened in 
the quoted item from the PL/I LRM.


Cheers,
Greg

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

Re: Architectural Level Sets

[Greg Price]

Hi - regarding several points in this thread...

What I think I know:

MVS 3.8 had:
- MF/1 (component prefix IRB) writing the SMF type 7n records
- physical swapping only
- sequential SMF data sets ("TCLOSE" anyone?)

SE1 and SE2 were free (as in zero dollars) but licensed.

MVS/SE2 had
- RMF (component prefix ERB) writing the SMF type 7n records
- physical and logical (at least for swap types TI and TO)
- VSAM SMF data sets (flagged by the high-order (or sign bit) of CVTSMCA 
being set)


Does anyone know if any of those things were delivered in SE1 (which I 
never saw AFAIK)?


Where I worked ran a 370/158 MP (6MB real) on MVS/SE2 3.8H (1983?)
- they also got an Amdahl V7B->V7A->V7->V8 ("got all cylinders firing")

I was very surprised when MVS/SP 1.2 ran on the 158 because I would have 
thought that DAS required extra hardware that was not thought of when 
the 158 was first designed and built.


When I heard of the 4300 series, I heard of:
4331 - lower end
4341 - a bit more "oompf"
both came in Group I or Group II - don't know what the difference was.

A 4331 could not run MVS.

The 4300 series were geared toward the VM/VSE crowd.

Was there a 4361 ?

In 1987 I worked on an MVS/XA system (SP2.1 -> SP2.2) on a 4381.


I'd welcome any corrections to - or even confirmations of - any of the 
above factoids.



And also...

Is not one of the main points of an ALS is that the the BCP (et al) 
coders can assume that the newer instructions in place at that level can 
be freely used within the object code of their components?


Cheers,
Greg P.

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

Re: z/os d,a,l --- What does "owt" mean ?

[Greg Price]

On 2020-05-02 8:24 AM, Wayne Bickerdike wrote:

As a Yorkshireman, it means "anything ". Nowt means "nothing".


Ha ha ha ha - very good!


For this sort of stuff I like to look at the swap reason code.

TI - TSO input wait
TO - TSO output wait (3-asterisk syndrome?)

US - unilateral swap
EX - exchanged swap

Remember the pre-WLM SRM WLM recommendation values?
When was the last time anyone ever saw an exchange swap?

Back in the day:
OT - OUT and ready - physically swapped out but ready to be swapped in.

Of course, with z/OS, there are no physical swaps any more - it's all 
logical swaps, where the LSQA (and probably most of the working set, 
subject to page stealing, which probably only happens on very heavily 
loaded systems) still resides in real storage.


For years on z/OS, I was always amazed afresh every time I saw all the 
local page data sets have zero used slots.  I guess the amount of real 
storage that comes on z boxes has increased from the early 370/XA/ESA days.


:)

Cheers,
Greg

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

Re: Question on dynamic concatenation

[Greg Price]

On 2020-04-23 4:58 AM, Tony Harminc wrote:

So is that record of the previous allocation kept in some
private/undocumented place by allocation, or do TIOT entries remain in
place (perhaps flagged somehow) and provide all the necessary info?


Deconcatenation is pretty much just restoring the DD names held in the 
SIOT (SCTDDNAM) to the TIOT (TIOEDDNM) and resetting some concatenation 
flags in the relevant DSABs.


Cheers,
Greg

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

Re: UPDTE - CBT tape 496

[Greg Price]

On 2020-04-22 11:06 PM, Robert Prins wrote:
UPDTE still works, but for whatever reason, membernames in the resulting 
PDS are screwed up with what seem to be (part of) the initial RDW and in 
case the filename on windows was only 2 characters, the first two 
characters of the next record. The member data itself is correct.


CBT file 496 does not seem to contain anything relevant.

The UPDTE program from CBT file 93 processes IEBUPDTE-like input with 
less strict DCB restrictions.


The parsing logic of the NAME= parameter does not consider the case of 
when the record ends before the 8 characters of the member are loaded. 
It does look for a delimiter in the form of a blank or a comma.


Since text transfers typically discard trailing blanks, I suggest that 
one way to circumvent the problem would be to alter the REXX to place a 
comma after the member name.  In fact, you could probably place any 
character sufficiently far away so that it is a comment but would be a 
placeholder to ensure that at least 1 blank followed the member name.


Cheers,
Greg

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

Re: How to change the default '.java' extension to '.jav'?

[Greg Price]

On 2020-04-11 11:34 PM, Paul Gilmartin wrote:

Does anyone know how to change this default '.java' extension to a
3-char one, such as '.jav',  that DOS and SPF/PC could then edit,
compile and run?
  

WTF?  Windows hasn't suffered the 8.3 restriction for many releases now.


I think DOS and SPF/PC can be considered as "pre-Windows" software.

My question would be: Does anyone still use DOS or SPF/PC?

And no, I am not seeking to pry it from anyone's fingers be they living 
or dead.  If you got it and want to use it, then go ahead.

:)

Cheers,
Greg

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

Re: Bringing up skills learned on z/OS Hercules in interview?

[Greg Price]

On 2020-04-10 11:21 PM, Jackson, Rob wrote:

The first time I ever encountered Hercules it was running z/OS 1.9 on an IBM 
employee's IBM-owned laptop.


My understanding is that IBM generally considered IBM employees to be 
licensed to run IBM software in the course of their work for IBM. So, 
for example, an IBMer wishing to see if some licensable IBM software 
could run under Hercules by actually trying it out would not be subject 
to penalty from IBM - BUT if anyone who was not working for IBM tried it 
then it may well be a VERY different story.


Just my opinion...

Cheers,
Greg

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

Re: PDSE V2 data set info

[Greg Price]

Hi Robin,

I'm sure others will jump in if I am not up to date, but AFAIK, you 
cannot get these pieces of information without opening the data set and 
issuing a ISITMGD macro.


A few folks have opined that it should be possible to acquire this data 
without an OPEN, but it remains as it was.


Commiserly yours,
Greg


On 2020-01-28 9:48 PM, Robin Atwood wrote:

I have a requirement in my queue to include the PDSE Version and the MAXGEN
limit in the DSINFO report our server sends

to workstation clients. I checked the F1 DSCB, IGGCSI00 output fields, SMDEs
and found nothing. Searching only produced Lionel Dyck's

PGSEGEN utility but that works in an ISPF environment and can obtain the
values from ISPF variables (ZDSDSNV, ZDSNGEN). I resorted to a brute force
search of SYS1.MACLIB and SYS1.MODGEN using "MAXG" but that only found the
DFA and some allocation support. Is

this information actually publically available and, if so, can someone tell
me where?

  


Thanks

Robin




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

Re: what is DSSUMON?

[Greg Price]

On 2019-12-10 7:57 AM, Tony Thigpen wrote:
I have an auto-started initiator running DSSUMON and I don't know what 
it is doing. Anybody know what this program does? I think it's a vendor 
program that we don't license anymore. The messages don't supply any 
vendor name.




Word on the street is that module DSSUMON is from a product called 
QuickTAPE from Texas Digital Systems Inc.


Cheers,
Greg

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

Re: In what context/amode BSAM/BPAM READ with SF64

[Greg Price]

On 2019-11-17 5:40 PM, Joseph Reichman wrote:

I  normally do all I/O in amode 24 because of the EODAD of AL3 the open
having an AL3 for the  DCB


Unless you have an old ESA or even older XA system, there's no need to 
do I/O in amode24 these days.  Just use amode31.


The AL3 pointers will restrict you to rmode24, but that's a different story.

If the only DCB exits you use are EODAD and/or SYNAD, and you want to go 
rmode31 (or rmodeany if you prefer) then you can supply their 4-byte 
address in the DCBE macro.  But you do not need 4-byte pointers to them 
to use amode31.


About the only amode24 code for z/OS I write these days is for exits 
where only amode24 is supported.  DCB exits pointed to by DCBEXLST may 
be in this boat, as are the SYSIN and SYSPRINT (and other DD ??) exits 
used for supplying data to and consuming data from calls to the IDCAMS 
program.


Sometimes in rmode31 programs I GETMAIN BTL storage and load the code 
for DCB exits, but this technique is not required for EODAD and SYNAD 
exits due to their DCBE support.


Cheers,
Greg

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

Re: IBM SSI Function Codes 16 and 17

[Greg Price]

On 2019-10-05 5:24 AM, Lionel B Dyck wrote:

SMF will give the close time but I've found nothing that will give me the open 
time.


Well, SMF14OPE tells you something...

Cheers,
Greg

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

Re: Adding/replacing PDS member with QSAM, BLDL, and STOW

[Greg Price]

On 2019-08-20 12:46 AM, Kirk Wolf wrote:

1) This is confusing, since I had thought that I couldn't use MACRF=PM with
DSORG=PO.   But with DSORG=PS, I don't think that I can use STOW.   But,
under "STOW - Update the Directory",  it says that you can.   Maybe I need
to use DSORG=PS?



I read that a BLDL can be done for any DSORG, so probably this is true 
for STOW as well.  After all, they don't need much data from the DCB 
since they are dealing with the directory and the DCB is mainly tracking 
the data blocks within the member.



*2) Referring to the following pseudocode:*  where do I get the TTR for
STOW for the new member location?   DCBRELAD/DCBRELA right after OPEN?



You might want to open it for INOUT or some such... and do the BLDL 
first to get the old stats.  Then start writing data and construct the 
new stats after the final data block WRITE and do a STOW A (ADD) with 
the new stats.  And maybe OUTPUT is sufficient given that BLDL should 
work for any DSORG, but I would do the BLDL before any WRITEs.  The STOW 
A means that you do not have to keep track of the TTR.  STOW will pick 
it up from DCBRELAD.



3) DD question:   I think that having the member name in the DD is what
causes OPEN (OUTPUT) to starting writing onto the end of the PDS, right?


Well, I think stories of overwriting PDS directories with IEBGENER are 
legend, so yes.  You could OPEN it for EXTEND, I suppose, but you really 
want QSAM to know that it is writing to a PDS, and then it will work for 
a PDSE as well.



Cheers,
Greg

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

Re: Instruction speeds

[Greg Price]

On 2019-08-14 8:40 PM, Raphaël Jacquot wrote:
that's what they said in 1965 when they were storing years in dates on 2 
digits...
hilarity ensued in 1999 when they were all panicked that their 1964 
vintage cobol code world would crumble...


Yeah...

Didn't Fred Brooks in "The Mythical Man Month" complain that OS/360 
wasted 24 bytes by catering for a leap year changing from 28th Feb to 
29th?  The operator could manually fix that without OS help - after all, 
it only happened once every four years.


So, you are updating your master file with millions of records and for 
each record you go through 5 excess instructions (say) to cater for the 
year 2100.  How long extra will several lots of 5 million instructions 
take on today's BIPS engines?  Less than a thousand I/O operations?


It's nice to reduce path length overhead, but it's also nice to be 
future proof - or at least future tolerant.


Cheers,
Greg

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

Re: CPU time cost of dynamic allocation

[Greg Price]

On 2019-08-09 2:08 PM, Jesse 1 Robinson wrote:

Then MVS was changed to simulate an OPEN/CLOSE on a new allocation so that a 
later read would get immediate EOF.


My flakey memory says that is only for SMS-managed data sets - or at 
least that was the case when it was originally brought in.


Cheers,
Greg

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

Re: ISPF Question - browsing variable length records

[Greg Price]

On 2019-08-08 10:46 PM, Steve Smith wrote:

View. like Edit, shows blanks all the way to the maximum LRECL, even if
they're not there.  I don't know why.


Steve, I'd genuinely be surprised if you don't know why.

Surely the simplest editor design is to provide an area as large as the 
record can be for the user to type in new data during the edit session, yes?


Cheers,
Greg

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

Re: FAST PATH (IEWBFDAT) SQ CALL Fail 10800029

[Greg Price]

On 2019-08-07 10:59 PM, Joseph Reichman wrote:

Thanks would IEWBIND work with load modules



Yes, IEWBIND - the "full" Binder API - can process PDS load modules as 
well as program objects from a PDSE and from the UNIX file system.


Cheers,
Greg

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

Re: CPU time cost of dynamic allocation

[Greg Price]

On 2019-08-07 6:36 PM, Lennie Dymoke-Bradshaw wrote:

However, I think standard TSO ALLOCATE does perform that check


Yes, I was probably basing my opinion on my observations of the 
behaviour of the ALLOCATE command.


Cheers,
Greg

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

Re: FAST PATH (IEWBFDAT) SQ CALL Fail 10800029

[Greg Price]

On 2019-08-07 5:37 AM, Joseph Reichman wrote:

The program is not a program object, anomalies were found in its

structure, or the program is PO1 (program object, version 1) and the

program contains overlay structures. The request was rejected


So, would you swear on a stack of PLMs that MYMOD is neither a load 
module from a PDS nor a segment overlay program object?


If so, then it is time to post the entire parameter list passed to IEWBFDAT.

Cheers,
Greg

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

Re: CPU time cost of dynamic allocation

[Greg Price]

On 2019-08-07 5:08 AM, Carmen Vitullo wrote:

I suspect dynamic allocation may be doing more that the IEFBR14 possibly?


Well, DYNALLOC is certainly doing more that the job step initiation when 
it comes to allocation.


Device allocation at step-start time is a largely CPU-bound affair with 
the only I/O usually being for catalog look-ups.  That is why something like

//MY DD DD DSN=FRED,DISP=OLD,UNIT=3390,VOL=SER=MYVOL1
will get a S213-04 at OPEN time when FRED does not exist.

DYNALLOC will check that FRED exists on the volume - yes! it does "lots" 
of I/O to the data set's volume which batch device allocation does not 
perform.


Data set name enqueue is done before device allocation, and most of it 
is done at job start time for data sets mentioned in JCL.  DYNALLOC has 
to do the ENQ when it is called before looking at devices.


Cheers,
Greg

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

Re: Getting ABEND reason code from attached subtask

[Greg Price]

On 2019-08-04 4:06 AM, Kirk Wolf wrote:

I'm curious.
Say that I have something like:

ATTACH EP=MYPROG,ECB=MYECB
LTR R15,R15
BZ ATTERR
ST R1,MYTCB
WAIT 1,ECB=MYECB
DETACH MYTCB

I know that I can get either the subtask return code or ABEND completion
code(s) from the ECB.  But in the case of an ABEND, is there an easy way to
get the reason code?
Or do I need an ESTAI routine on the ATTACH to capture that?
Similarly, what about the normal completion reason code (R0)?


Should that be
BNZ ATTERR
?

By the time control returns after the ATTACH, you don't really know if 
the subtask has started, is running, or has completed unless you have 
organised some inter-task protocol.


After the WAIT on the ECB has popped, you know the task has completed. 
Further, the subtask's resources that it owned such as virtual storage 
and probably ENQs and maybe even Name/Token pairs and such have also 
gone.  The programs it loaded have been deleted, and it is no longer on 
the TCBTCB chain.


All that you are entitled to assume is that the TCB and the STCB are 
still extant, and it is still in the TCBOTC/TCBLTC+TCBNTC tree.


The TCB and STCB will be deleted by the DETACH.  Before issuing the 
DETACH, you can harvest the TCBCMP word and the TCBARC word.  I have 
also been known to extract the task's CPU time before issuing DETACH.


The TCBRV316 bit in the TCBCMPF byte will tell you if the abend actually 
set a reason code.


For the occasions that I code both the attaching task and the attached 
task, I have been guilty of knowing that the attached task does not 
issue any user abends, and have consequently used logic which assumes an 
abend only if the 12 system abend code bits are not all zeros.  I expect 
I should have used the TCBENDINGABNORMALLY bit in the TCBFLGS8 byte.


Cheers,
Greg

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

Re: JCL COND Parameter

[Greg Price]

On 2019-07-13 10:42 AM, Steve Smith wrote:

Whenever
multiple CONDs are present, I'm lost.  Is it OR or AND and is that in the
positive or negative sense?



When I started I was told:
Always say "Bypass this step if" and then begin reading the COND parameter.

Cheers,
Greg

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

Re: Use of "trap" facility in z/OS?

[Greg Price]

On 2019-06-21 4:59 AM, Tony Harminc wrote:

I'm not sure that any of the hardware architecture has been
implemented specifically for Linux.


ISTR hearing that the primary impetus for implementing 20-bit 
displacement instructions came from the Linux direction.


Cheers,
Greg

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

Re: VTOC reading

[Greg Price]

On 2019-06-14 7:58 AM, Mike Shaw wrote:
CVAF is much slower than BSAM, alphabetical order or not. EXCP with 
chained CCWs is much faster, then just sort the DSNs yourself.


In the "LOAD/LINK exit" thread, Graeme mentioned the products named 
Dorana and SoftAudit.


SoftAudit was from Isogon (who also produced SPIFFY and probably other 
products I can't recall). Isogon was acquired by IBM, around the 2005 
time frame.


Dorana was started by Ubiquity because they could not get a good 
distribution deal for SoftAudit in Australia. I wrote the first program 
for it in 1996, which was the DASD scanner.


SoftAudit could not make a new sale outside the US pretty much so IBM 
acquired the Dorana product in 2006 with a view to kill the competition, 
at least as we thought. (Dorana could not be sold in the US because of a 
lack of funds to bust a patent which Isogon did not actually use, but 
for which it was assumed they would claim infringement. It was thought 
that if the funds were available then the patent could almost certainly 
be busted, but that, of course, remains conjecture. That particular 
patent has now expired.)


In 2007 I was hired (in Australia) by IBM New York because, it turns 
out, they thought I was someone else. (I think that's funny.) 
Unfortunately for them, I was not the C++ coder who wrote the one bit of 
Dorana they were interested in - a component called the Match Engine - 
but merely an assembler guy, and they already had lots of assembler 
talent. (I also do a bit of PL/I. The current IBM product still ships a 
couple of PL/I programs - probably a rarity these days.)


But a contract is a contract, and so I was still on the books when IBM 
grew dissatisfied with the ex-Isogon team to the extent that they gave 
the whole project to IBM ADL.


The ADL team preferred Dorana over SoftAudit (perhaps they thought DB2 
was superior to ISPF tables as a scalable DBMS), and were happy enough 
to retain the services of an original developer.


IBM had renamed SoftAudit to Tivoli License Compliance Manager for z/OS, 
or TLCMz for short. Dorana was renamed to Tivoli Asset Discovery for 
z/OS which I was told had no official abbreviation but the unofficial 
one of TADz soon became its de facto handle.


(Actually, the original IBM name for it was Hardware and Software 
Identification for z/OS or HSIz for the limited release of 7.1, but by 
7.2 it was TADz. It still uses the component prefix of HSI.)



And now I finally get to the thread relevance - reading VTOCs. When I 
wrote the "Inquisitor" as I called it, it used a routine sourced from an 
Amdahl SE-supplied program called SUPERLST, which was really just a 
version of XVTCLIST as found on the CBT tape.


The relevant subroutine - XVTCREAD - uses a CCW chain to read an entire 
track in a single EXCP, so this seemed like a good routine to use - even 
better because it was in the public domain, put there by a couple of 
very large US corporations who had separately donated the code to the 
CBT tape in the 1980s.


As TLCMz level 3 from 2008 until it went EOS in 2010, I was interested 
to see that they had used the same routine in their DASD scanner - the 
"Surveyor".


So, XVTCREAD - the VTOC reading routine originally written around 
1966/1967 - has given and is still giving grand service today in 2019, 
over 50 years later.  Now that's compatibility!



Cheers,
Greg


Disclaimer: The recollections, views and opinions stated above are my 
own and do not represent any official statement. No guarantees as to 
their accuracy are given.


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

Re: MODGEN vs AMODGEN

[Greg Price]

On 2019-05-08 2:39 PM, Peter wrote:

Does it really makes any difference between the two ?


That depends on what maintenance you have applied but not accepted.

I would guess that JCL using AMODGEN in the assembler SYSLIB 
concatenation dates from (or is cloned from JCL that dates from) the 
time when MVS did not have a SYS1.MODGEN data set.


In those days, to be sure to be sure that you were getting the latest 
level of those macros for your system's maintenance level, placing 
SMPMTS ahead of AMODGEN (and AHASPSRC etc. - that is, any macro DLIB 
which did not have a corresponding SYSLIB) was the convention that was 
supposed to be observed, even if it seldom was.


The creation of the relevant macro SYSLIBs such as MODGEN now places 
them on an equal footing with libraries such as MACLIB in that regard.


For practical purposes these days, for assembler SYSLIB DD data sets 
just change all AMODGEN references to MODGEN.


Anyone referenced AGENLIB lately?

:)

Cheers,
Greg

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

Re: Crazy concatenation mystery

[Greg Price]

On 2019-05-03 12:15 PM, David Spiegel wrote:

Steve said: "... but the received wisdom is that all load libraries should
have blksize=32K-8. ..."

For optimal space usage, however, the BLKSIZE should be 27998 (i.e. half-track 
blocking).


You might think that, but for load modules, you have to realize that 
in-between the text blocks (which could be 27998 bytes long in your 
scenario) there are RLD and/or CTL records which means that no single 
track could contain 2 full-sized text blocks.


Because of the "random" sizes of CSECTs and RLD usage (where "random" 
means not really knowable at load library data set creation time) it is 
not possible to know the best block size to use to minimize the disk 
space used by a set of programs without doing some sort of analysis on 
the load modules to be housed in that library.


I mention CSECT because once a text block has some data to the end of a 
section, the next section will not be started in that block unless the 
whole section will fit in that block. That is why you see short text 
blocks even though there is plenty more object text that follows on.


And even though the linkage editor may make good use of remaining track 
space, what happens when the blocks a shifted around by a data set copy 
or a compress?


So, it may be that BLKSIZE=32760 really is the best advice. At least you 
could reasonably hope to minimize the amount of disk space wasted on 
inter-block gaps.  (Of course, inter-block gaps may well be emulated 
away these days, but they still exist for 3390 CKD accounting purposes.)


And as for PDSE program object libraries - how about this?

If the BLKSIZE value doesn't matter in terms of how programs are stored 
in the PDSE and fetched at run time, what about using BLKSIZE=4096 for 
PDSE load libraries?


Why? Because if you browse a program object in a PDSE and scroll right, 
you will notice that all of the blocks end at column 4096. So to read 
that member you have acquired 32760-byte buffers when 4096-byte buffers 
would have sufficed.

:)

In practice, 32760 for all program libraries is probably the best choice 
to remove any block size hassles even if occasionally it causes more 
storage to be used. After all, I keep hearing that storage is cheap.


Just my thoughts, of course...

Cheers,
Greg

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

Re: Crazy concatenation mystery

[Greg Price]

On 2019-05-02 9:51 AM, Jesse 1 Robinson wrote:

This is almost nutty enough to be a weekend post, but it's a live production 
environment, so here goes. We have a prod job (batch Db2) that has run daily 
for years. Suddenly on 14 April it started abending with this message from 
Fault Analyzer:

IEW2541S 471A MEMBER CUA625 IDENTIFIED BY DDNAME JOBLIB WITH CONCATENATION
  NUMBER  1 CONTAINS A BLOCK OF SIZE  32760 WHICH IS LONGER THAN THE
  DATA SET BLKSIZE.
IDI0010E IEWBIND error INCLUDE  CUA625   rc=83000507
IDI0002I Module CUA625, program CUA625, offset X'7712': Abend U3003

So this is all absolutely true. The module*is*  32760 while the PDS*is*  
19069-the ancient 3350 track size that was fairly standard for load libraries 
in the Dark Ages. So what's the mystery? How on earth did the 13 April and*all 
previous*  runs work OK?


Here's my theory...

So you have this set up all ticking over nicely, and it works for years.

And then one day the application has a problem (an abend?) which causes 
Fault Analyzer to wake up and think: "I better look into this!"


So then FA decides to make some Binder API calls to get the low-down on 
this application program, and it is this I/O which does not work 
properly because of the block size in the data set label being smaller 
than an actual block in the program.


Of course, program fetch does not care about such niceties because he 
makes his own channel programs with numbers from control information and 
therefore ignores DCB attributes in the VTOC entry.


So, no application problems means that the block size mismatch is not 
exposed.  Application problems means that the automatic application 
problem looker-at-er tries to do "normal" I/O to the library which 
exposes the block size mismatch.


Cheers,
Greg

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

Re: Unable to reconnect TSO session after VPN disconnect

[Greg Price]

On 2019-02-08 9:29 AM, John Szura wrote:

However, now we can no longer reconnect to a session when the VPN disconnects,


I'm not a network guy, but I think it depends where the disconnect 
occurs. If I Alt-F4 my TN3270 session I get an immediate S622. If I lose 
the internet (over which I connect using a VPN) then there is no 
feedback to the host that there is any loss of connectivity, and so I 
can LOGON RECONNECT successfully when I get internet back.


Sometimes I don't lose internet, but I think the organization's gateway 
does not have a large enough pipe for the network traffic, and so the 
packet flow between my PC and z/OS ceases so long that my TN3270 client 
times out, but when it clears I can usually LOGON RECONNECT successfully.


So, IMO, something is telling z/OS TN3270 that the session has been 
dropped, and so the S622 follows on in quick time. "The fix" you need 
may depend on what is telling the host that the session has been dropped.


Time for a network trace???

I know it's annoying, so I hope you find out what's going on.

Cheers,
Greg

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

Re: Cause of CsvdylpaRsnBadVersion?

[Greg Price]

On 2019-02-01 11:59 AM, Charles Mills wrote:

Do others here agree with that advice? Eschew MF=(E,...,COMPLETE) ?


Numerous newer (in geological terms) macros simply define a storage area 
with MF=L. For these I use PLISTVER=MAX with MF=L when it's available, 
and in these cases I also use COMPLETE on the associated MF=E form when 
that is available. I think this maximizes the chances of getting good 
macro plists for these cases. Just IMO. YMMV.


Cheers,
Greg P.

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

Re: Where is the EPA offset of a program in the Binder API data?

[Greg Price]

On 2018-12-02 2:49 PM, Jesse 1 Robinson wrote:

The original program had been assembled with END EP-name. That name was not 
defined with external reference otherwise. With no source to reassemble, we 
could not get it to link with just the load module alone.


Hmm, may have been fixable by a delinker which could reconstruct the 
object deck, and then you could have edited the END card, perhaps?

If you had a delinker handy, of course...

Cheers,
Greg P.

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

Re: Where is the EPA offset of a program in the Binder API data?

[Greg Price]

On 2018-12-01 4:01 AM, Farley, Peter x23353 wrote:

But the question still remains -- Where (if anywhere) is an EPA indicator in 
the returned Binder API data?


I guess I should have spoken more plainly.

I'd say it's not there because it is not needed.

If you are including the module for subsequent saving, you can preserve 
the entry point by using ATTRIB=YES on the INCLUDE. And you can specify 
entry points when you add new aliases. But you can't AFAIK extract what 
the current entry point is set to.


It is not needed because it does not affect the internal structure of 
the module.


You do know the entry point will be in the first class - the one at 
offset zero when the module is loaded - so it is reasonably easy to 
determine the entry point symbol (or at least a symbol at the same 
offset), but I agree it is not quite as simple as being told "the 
answer" directly.


Cheers,
Greg P.

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

Re: Where is the EPA offset of a program in the Binder API data?

[Greg Price]

On 2018-11-30 4:01 AM, Farley, Peter x23353 wrote:

The PDS/E directory entry for a program contains, among other information, the 
EPA offset within the program.

The EPA offset is also contained in the SMDE/PMAR information returned by 
DESERV.

After much RTFM however, I cannot seem to find anywhere in the Binder API data 
areas an indication of which section/label is the entry point for the program.

In particular, I would have expected that an LD entry in the ESD table would 
contain such an indicator, but I do not see one anywhere.


Wasn't PDS/E the first commercial version of free PDS command?
PDS/E was later renamed PDSTOOLS and then StarTool, IIRC.

Both a PDS and a PDSE program member directory entry contain the EPA 
offset. Typically the EPA is chosen from label and section ESDs because 
it matches a real or alias member name, or was explicitly named on a 
Binder ENTRY statement, or was some sort of default.


I think that no change is made to the relevant external symbol's 
recorded details as a result of being selected to be the entry point.


Often a tool will report one of several symbols with matching offsets as 
the entry point simply because it was the first symbol found which had 
the correct offset, even if the reason the entry point was chosen was 
because of another symbol at the same offset address.


I'll propose that it's a bit like a NOTE list TTR stored in the 
directory entry. Such a TTR may record the location of an "important"
block within the member, but the block itself is not changed simply 
because something recorded its location.


Cheers,
Greg P.

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

Re: Display utilisation of logrec

[Greg Price]

On 2018-11-29 4:28 AM, Lizette Koehler wrote:

Logrec is not only preformatted, but it is a wrap around datasets.

So it (LOGREC) always knows where the last record was written in the file.

If it gets to the point of overlaying the data, I think an IFC message is 
produced to let you know you are about to lose data.


When IFCDIP00 is used to initialize SYS1.LOGREC, it writes 2 40-byte 
records (also blocks since RECFM=U), the first containing the CCHH range 
of the data set and the CCHHR of the 90% full mark and the next CCHHR to 
be used for a new record. The second record is what I call (rightly or 
wrongly) the "3 minute currency record" which I've observed gets updated 
every 3 minutes or so with a new current timestamp.


When the LOGREC data set gets to 90% full message IFB080E is issued.

When the LOGREC data set becomes full message IFB082I is issued.

You can offload the contents and make the data set available for more 
data by running IFCEREP1 (with the appropriate control inputs), or you 
can throw the data away and reinitialize LOGREC with IFCDIP00.


If you really want to know how full it is in a reasonably convenient 
fashion then you can write a program to read the first record and 
calculate and report the fullness, or get a program which already does 
this. One such program is the public domain data set browser called 
REVIEW which will format and display some summary data from each LOGREC 
record when the LOGREC data set is browsed and EREP ON is specified.


Cheers,
Greg P.

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

Re: ASMA034E

[Greg Price]

On 2018-11-16 1:47 AM, Ward Able, Grant wrote:

Can someone point me to a reasonably simple example?


If you can do branch instructions then you can do branch-relative 
instructions. Apart from RR instructions (BR, BASR, BALR, BASSM, BSM, 
BAKR and any others I've missed) replace the B that starts the branch 
instruction mnemonic with BR, or as I prefer to do, with J (for jump).


eg. BNH -> JNH and BCT -> JCT and BAS -> JAS etc.

Put all the stuff which needs to be cover by a base register after all 
the instructions, and start the area with a label, and "use" that.


eg.
LARL R11,Static
USING Static,R11
...

Static DC 0D  My module's constants and literals and non-RENT variables


Then all you need to cover is code generated by macros, which is why 
Peter mentioned ARCHLVL (look up the SYSSTATE macro) to cover macros 
with logic to test it, and the IEABRCX macro to cover the rest.


IEABRCX DEFINE
will define and activate the facility where the older "branch" 
instructions will be converted to newer "branch relative" instructions 
when encountered by the assembler in the source code.  With IEABRCX you 
could even leave the old branch source code as-is, but personally I 
prefer to use the newer mnemonics to make it obvious that the code is 
probably not covered by a base register, and to keep the listing a bit 
tidier.


IEABRCX is "better" than IEABRC because you can turn it on and off as 
needed. The most well known scenario where you might was to turn it off 
(I'd say) is if you have a branch table where you use the index register 
of the branch-on-condition instruction to provide an index into a table 
of branch (or even jump) instructions.


That's probably enough to get you started.  Have fun with it.

Cheers,
Greg P.

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

Re: load library lrecl=??

[Greg Price]

On 2018-09-06 1:41 PM, Brian Westerman wrote:

Apparently some of the libraries shipped by some vendors or at least the 
directions to define them specify RECFM=U,LRECL=256.


Maybe the vendor instruction writers looked at their data sets and 
copied the attributes they saw.


So, I had this TSO command called REVIEW which read PDS directories 
using RECFM=F,LRECL=256,BLKSIZE=256 with QSAM. Years later I noticed 
that it seemed to be setting the LRECL of RECFM=U data sets to 256, 
although I maintain that it did not do that when first developed.


So, with DCB attribute merging, the VTOC entry got zero fields updated 
from the JFCB even though it was only opened for INPUT. Or maybe I added 
a feature which could update the PDS, and it was on these occasions 
which added a non-zero LRECL to the VTOC entry. The result was that my 
RECFM=U data sets processed by this program ended up with LRECL=256.


Whatever the actual details were that caused this update, the 
LRECL-changing phenomenon all went away when I removed the LRECL value 
from the directory-reading DCB. Looking at the source now, it says 
RECFM=F and BLKSIZE=256, but the "problem" as not occurred with this combo.


Once the LRECL is set, it won't go away unless removed by "unnatural" 
means. So maybe someone used this or a similar program on their library 
at some stage.


Cheers,
Greg

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

Re: Jes2 Initiator number

[Greg Price]

On 2018-08-08 5:58 AM, Cieri, Anthony wrote:

The audit trail is needed to determine what job(s) instigate the S822 ABENDs.


Well, maybe that audit trail will work now (and maybe it won't)- but it 
definitely would not have been reliable in the past.


In the olden days - even before the iPhone 6 was invented - the JES2 
INIT number was more of a logical concept or a virtual queue - and did 
not mean any particular address space.


For example, suppose the "INIT 2" address space A1 was doing job 
termination.  Then "INIT 2" would be eligible to run a new job.  But 
suppose there were other started initiators that had no work in their 
assigned classes, and so address spaces A2 and A3 were idle initiators.


JES2 may well start the next job under "INIT 2" in address space A2 or 
A3 as JES2 saw fit, perhaps before address space A1 had become truly idle.


S822 abends are probably caused by LSQA fragmentation, where LSQA is 
sloppy terminology for "private high" virtual storage.  If you want to 
find out who the "culprit" is, you need to track the ASID, not the INIT 
number, in my view.


In a previous life as a sysprog, I wrote and implemented an MPF exit to 
append the ASID to the STARTED and ENDED messages - the ones produced by 
the MONITOR or MN command IIRC, but it might also work for the JES2 
messages.  It reported the ASID for started tasks and TSO users as well, 
without actually increasing the number of messages.


You may not be interested in messages as such, but the most convenient 
window into the past I had at the time was the SYSLOG.  If you want to 
look at SMF, then you probably do not need to change much because the 
ASID is in the type 30 (SMF30ASI).


Even if my observations about JES2 INIT numbers are out of date or even 
totally incorrect, ASID is still a valid thing to track when trying to 
track storage fragmentation within the private area of an individual 
address space, so you still don't need to audit JES2 INIT numbers.


And don't forget there is always the el cheapo version of the 
therapeutic IPL - just drain and restart all the initiators every so 
often when convenient for pristine unfragmented private storage for your 
batch jobs.


Cheers,
Greg

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

Re: PDS with 1 directory block

[Greg Price]

On 2018-06-22 7:53 AM, Jesse 1 Robinson wrote:

I have a dim memory of learning ages ago that a PDS with 1 directory block is 
somehow 'different', that certain updates to it require fiddling with the VTOC 
in addition to changing data on a track. Sound familiar?


Once the last directory block has started to be used, its unused 
capacity is maintained in the data set VTOC entry. If there is only one 
directory block then then it is also the last directory block and so any 
member addition or deletion will also require a VTOC entry update.


Cheers,
Greg

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

Re: GETMAIN LOC=32

[Greg Price]

On 2018-05-11 9:41 PM, Tom Marchant wrote:

On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote:


SG24-7605-00
z/OS Version 1 Release 10 Implementation
April 2009
Pages 6 and 104
Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private.

That illustration in that Redbook is incorrect.



I disagree!!

I think that illustration is correct - and I think it shows the address 
space structure introduced by MVS/XA and which persists till now.


Ok, before z the PSA was only 4K, and not 8K, but apart from that the 
diagram could be for MVS/XA, MVS/ESA or z/OS (BTB).


BTW, I could not see anything relevant on page 6 (maybe I didn't look 
closely enough) but the diagram on page 104 is very plain to see!


The "problem" under discussion is not extended common - it is ELSQA. 
That was why I was rabbiting on about private app storage starting low 
and going higher, and private system storage starting at the "top" and 
growing downwards.


To move ELSQA gets back to the issue of why XA went with AM31 and not 
AM32 in the first place.


Answer: to minimize problems while co-existing with pre-XA software.

And so we come to the central dichotomy of this whole thread.

Yes, you CAN write programs which would work using the same logic in 
AM24, AM31, AM32, AM64, and AM-anything-else, but generally speaking 
NOBODY HAS. (Specific counterexamples do not invalidate the point - we 
are talking about the bulk of application software.)


Further: Nobody wants to go back and change all their programs so that 
they can work in all these AMODEs.  But then you may say that no-one is 
asking them to.


To the final kybosh, then:

Nobody who is paying is prepared to risk any reduction in system and/or 
application availability just so that features they will never need or 
use can be added to the system and then debugged by APAR/PTF iterations 
in the service stream. This is on top of the old: the folks who could do 
it won't do it because there is no financial upside on offer.



You got a "if only things had been different" software itch you want to 
scratch?  Sure, explore it, look it over, discuss it, write your own 
software pertaining to it. But don't expect anyone to abandon what they 
are paid to do because you (or I) think they should be more intrigued 
with your (or my) "great computer idea".



Disclaimer:  Much of the above is my opinion and may not be "fact".

But anyway, I do not think there is anything incorrect in the diagram in 
the redbook mentioned above.


Cheers,
Greg P.

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

Re: GETMAIN LOC=32

[Greg Price]

[Warning: long post.  No world records, but feel free to skip it.]

Paul,

I think your request is unrealistic.  I raise the following points - 
some of which have been mentioned or alluded to by others - for your 
consideration:


- IMO, IBM will not perceive any ROI from your request sufficient to 
make them consider it.  I'm not an insider, but I expect them to have 
ideas which they think are far more lucrative than yours to pursue. 
Such ideas probably include some which, although they may not have the 
elegance of yours from an application programmer p-o-v, are being 
requested by companies which pay IBM many more dollars than the likes of 
you or me.


My conclusion: IBM will see the potential for incurring cost (at first 
from the initial development effort, and then on-going from the 
potential increase in PMRs where such a facility is used) without any 
obvious resultant potential increase in revenue.


- Virtual storage below the 2GB bar is generally managed down to a 
doubleword granularity.  Whether the macros used to make requests to get 
some of it or free some of it are called GETMAIN and FREEMAIN, or 
STORAGE, it is the same set on control blocks that are updated to keep 
account of it.  When managing storage at the doubleword level, it 
becomes possible for a significant fraction of total storage consumed to 
be used to track all the storage consumed.


- When scaling up storage to create the 64-bit address space size, 
managing storage at the doubleword atom size is just not a wise choice 
in terms of overhead.  For this reason, virtual storage above the 2GB 
bar is managed in chunks of 1MB.


My conclusion: Applications cannot get the conventional GETMAIN/FREEMAIN 
storage granularity natively in the 2GB-4GB address range.  You would 
have to add some intermediate storage administration layer - which may 
not even be that difficult to do, as long as your 32-bit program 
"compiler" generated code to call it for storage management calls.


- MVS private storage admin has "always" relied on user apps building 
storage usage from the bottom of the private area up (the "region"), 
while the system's use of private storage starts at the top and grows 
downward.  When the two meet, private storage is exhausted and the job 
crashes.  This process is occurring both below and above the 16MB line.


- For the ATL or extended private area, the "top" is the underside of 
the 2GB line where important control blocks reside, possibly including 
page and segment tables.  (This was true for XA, dunno if it is still 
true for z/OS, although what else is using all those megabytes reported 
by IEF032I (which used to be IEF374I) ?? )


My conclusion: Without a radical reengineering of the bottom-up-for-apps 
and top-down-for-system paradigm, ELSQA up to the 2GB bar is unmovable, 
and so the prospective 32-bit application will never be able to acquire 
a single 3GB chunk of storage entirely below virtual address 4GB.


There were enough hassles flowing from latent bugs exposed by the VSM 
(GETMAIN/FREEMAIN if you prefer) logic change circa z/OS 1.9 (or 1.10?) 
without adding some sort of AM32 to the mix.  That is why I think the 
PMR count could rise quite a bit giving a potential risk which is easy 
to avoid - simply by not making such a change.  Lots of subtle 
assumptions about the nature of the behaviour of the OS lie lurking in 
application code that is numerous years old, I think.  Sure, the bugs 
shouldn't be there, but why risk exposing them?



Overall, while I too like elegant programming models, at the end of the 
day, IBM and other vendors have to support their customers, and on this 
platform an important part of that is compatibility.  I certainly 
sympathise with the idea that there's an extra 2GB of storage for 
"existing" programs there for the taking, but in practice, I don't think 
it really is there in a z/OS environment.


And this opinion is from a bloke who still thinks that if the System/360 
CCW designer had not thought that a spare halfword would actually prove 
more useful than two separate spare bytes, then the high byte of the 
address word would have been available for XA to provide immediate AM31 
support for I/O macros in DFP V2.


But compatibility is important for vendors.  I happen to know of an IBM 
product (not in the z/OS package but acquired from an ISV and runs on 
z/OS) which uses a routine with logic unchanged since 1967.



I think z/OS has diverged too far from its MVS/370 predecessor where you 
could, perhaps, successfully implement your idea.


And just to opine about another point, I will predict that we will not 
see AM64 support for QSAM/BSAM/BPAM I/O macros inside 10 years from now. 
 (Gee, now I hope a DFSMS team are not currently working in this for 
the next release...  :/  )



Cheers,
Greg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Re: Managing JESYSMSG size

[Greg Price]

On 2018-03-05 5:50 PM, Robin Atwood wrote:

Greg-
The SVC 99s are under my control and that is very useful to know!

Thanks
Robin



Robin,

Great!
:)
But I was slightly inaccurate.
:(

It is not in a text unit, it is in the RB proper - bit S99MSGL0 in byte 
S99FLG11.


In a batch program (HSIPINQ) which allocates lots of DDs, I use the flag 
in both the allocation and deallocation requests to reduce spooled 
output size, as well as the number of pages one has to scroll down to 
get to the start of the SYSPRINT report. (Sometimes this is being viewed 
outside SDSF where N 3 works well.)


The main purpose I like all those allocation and data set disposition 
messages in the general case is so that I can quickly see which data 
sets are allocated at the time of an abend, and can usually figure out 
which DDs are allocated to which data sets.


Naturally, the data sets disposed of after the abend are the ones which 
were allocated at the time of the abend.


Of course, sometimes customer flower boxes from their IEFACTRT routine 
can be helpful in this area too.


Anyway, in the SYSPRINT report line which reports the data sets as they 
are processed I now also display the DD name just in case it's needed.


IIRC, I went looking for this flag one day when trying to figure out how 
BPXWDYN can do allocations and deallocations without generating such 
messages. Given its component prefix, perhaps it was written with a view 
to operating in spawned address spaces which usually leave no spooled 
relic of their existence.


Cheers,
Greg

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

Re: Managing JESYSMSG size

[Greg Price]

On 2018-03-02 9:53 PM, Robin Atwood wrote:

Is there anyway via
JES2 or SMS to suppress these messages? Preferably on a per-job basis rather
than globally


Would MSGLEVEL=(n,0) do the trick?

If the DYNALLOCs are under your control, you can request this in the 
relevant SVC 99 text unit.


Cheers,
Greg

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

Re: Graphic output on the mainframe

[Greg Price]

On 2017-11-27 7:22 PM, Bernd Oppolzer wrote:

run on my 3279 G display


And this time I'll get straight to the point.

I would pay money for a 3179-G manual.

Why?

Because while using programmed symbols is documented in a current 
manual, using 3270 vector graphics is not.


It used to be documented in the relevant hardware component manuals, but 
since those pieces of hardware are no longer marketed, the manuals have 
disappeared.


So how would TN3270 client writers figure out how to support vector 
graphics?  Probably with a lot of VTAM traces of GDDM applications' TPUT 
traffic.


Anyway, just sayin'.

BTW, did I mention that after 10 years, I'm out of IBM since the end of 
last August?  I wonder if they didn't think I was trendy or "with it" 
enough.  With my interest in bleeding edge technologies like 3270 
graphics, that can't be right.  Never mind blockchain - I say let's 
think block-mode terminals!


:/

Cheers,
Greg

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

Re: Shocking Bug in Latest PCOMM Release

[Greg Price]

On 2017-11-27 7:00 AM, Seymour J Metz wrote:

What is "GDDM graphics", APA or PSS?


"All Points Addressable" and "Programmable Symbol Sets" are what I take 
these acronyms (initializations?) to mean.


You could say that "GDDM graphics" is graphics performed by employing 
calls to GDDM.  If displaying the graphics on a TSO 3270 terminal, then 
GDDM will employ one of PSS (really raster graphics - the original 3270 
graphics) or what I call "native 3270 vector graphics" (no programmed 
symbols here - first supported by the 3179G I believe) or the even newer 
"enhanced PC handshaking vector graphics" implemented in the data stream 
after PCs pretending to be 3270 terminals became widespread.


(The "PC handshaking" as I call it, was known as DOSLINK, then later on 
as OS2LINK, then as PCLK, and was not used with any real 3270 hardware, 
AFAIK.)


Typically, the TSO terminal will only fully support one of these.  The 
support for these can be determined by an application from the response 
to a Read Partition (Query).  PCOMM3270 allows you to enable any one or 
none of these 3 3270 graphics options.


In a sense, PSS does provide APA, it could be argued.

Once you have the ability to specify the illumination of each pixel in 
any of the supported colors (ok, I want to say colours) independently 
from the illumination of any other pixel, you effectively have APA.


(The 3179G which supported vector graphics did also support single-plane 
programmed symbols - meaning monochrome - whereas only triple-plane 
programmed symbols can provide multiple colours in a single character.)


But really, with each symbol, you are specifying how a character display 
location is used whenever that symbol is displayed.  This is very 
efficient (I think) if you have symbols that you are going to reuse 
because you can specify (load) them once and then reuse them many times 
with relatively small overhead.


In practice, what were they used for?  Diagrams?  Text with custom 
symbols?  I think mainly for graphs and charts - probably mainly from 
MVS performance data.  There may well have been many other uses by 
applications, but I think it was MVS performance folks who were the 
majority of users.


So how do you make a graph or chart?  Well, I would make a big rectangle 
of pixels into which I would project the chart, and then I would map 
each 9x16 (or 8x10 or 10x8 or whatever the terminal - screen or printer 
- used) cell and load each symbol into consecutive codes points and then 
after the symbols were loaded then I would switch to that character set 
and display those points: x'4142434445446...FCFDFEFF' and then switch to 
the next character set and display those and so on until the whole chart 
was on display.


Or for vector graphics, you could effectively display a bitmap by 
sending rows of pixels - again the single plane (monochrome - meaning 
you choose the 1 3270 colour to use) or triple-plane (RGB - really GRB 
for 3270) concepts apply.


Anyway, enough of my waffle.  Most of what I know about 3270 graphics is 
described here:

http://www.prycroft6.com.au/misc/3270grfx.html

I am hardly a world authority on the topic, so if you spot anything 
which needs to be corrected then please let me know - preferably with 
the correction to be made.

:)

Recently I optimized the REVIEW display of pictures using programmed 
symbols where LPS recycle did not occur, and so I may have broken the 
display where LPS recycle did occur (ie. larger pictures) so if there is 
a bug in that which you would like fixed, give the relevant test 
conditions and I'll try to have a look at it.


REVIEW employs 3270 graphics to
- display PCX files
- display BMP files
- display GIF files
- don't do JPEGs because I don't understand how to decode them - 
assembler code donations welcome.



Programmed symbol and native vector graphics terminals are supported by 
assembler invocations of TPUT.  "PC handshaking" graphics is supported 
by calling GDDM.


In RFE (REVIEW Front End - poor man's PDF for use when ISPF is broken or 
not present) when a specific volume is selected in option 3.4 at the 
bottom of the data set list when geometry suits and programmed symbols 
are supported, a row of graphics is displayed depicting the space usage 
of the volume, where each vertical slice of pixels represents 1 
cylinder.  That is, the scale is 1 pixel per track.  Tracks addressed by 
the same head are in the same horizontal line of pixels.  Colour code 
indicates use.  (eg. white=VTOC, green=DSCB1/DSCB8 descriptors, 
yellow=DSCB3 descriptors, red=tracks in more than 1 extent (error) etc.)


For completeness I'll mention that the RFE main menu uses programmed 
symbols under MVS/370 to display:

- virtual storage page assignment
- UIC frame population bar graph
- real storage frame assignment.
The colour codes are documented in the TSO HELP member for the RFE command.

If you want to look at REVIEW, go ahead, but do not install releases 
47.5 to 47.7 into 

Re: Shocking Bug in Latest PCOMM Release

[Greg Price]

On 2017-11-27 7:42 AM, Tom Brennan wrote:

Years ago I was getting help from Greg Price


Probably circa turn of the century (before Vista was also a release of 
Windows) I thought it might be nice if one the the 
not-prohibitively-expensive TN3270 clients supported a form of 3270 
graphics, and so I sent an email or two to Tom with a view to convincing 
him that (a) programmed symbol graphics is fully documented in the 3270 
Data Stream Programmer's Guide and (b) it is a "simple matter of 
programming" to implement it.


Looking after a few data structure arrays must be bread-and-butter to 
anyone who can code up a reliable and function-rich TN3270 client, was 
my considered opinion, not that I really know about such things, of course.


Basically, the TN3270 client has to
- flag in the response to a Read Partition (Query) that it supports such 
functionality

- understand and digest the LPS (Load Programmed Symbols) data stream
- render loaded symbols into the screen buffer when SA or SFE orders 
request a switch to that character set.


A point to remember is that the TN3270 client cannot simply have a 
storage array for each RWS (read/write storage) being emulated.


An IBM 3279G will show the "green lightning" while an LPS data stream is 
being processed, but all of the RWSes added up cannot supply enough 
characters to paint an entire 32x80 screen.  So at least some of them 
are used more than once, in the usual case, before input-inhibit is 
reset (or the keyboard is unlocked, if you prefer) to allow a user response.


BUT - the symbols rendered when the "first lot" of symbols were in the 
RWSes must still be rendered that way, even though the relevant RWSes 
have been overlaid with a new set of symbol data, which is quite often 
used to render the bit-less-than-second-half of the screen.


So, symbol data must be remembered by the TN3270 client until BOTH of
- the symbols are no longer in any current RWS
- the symbols are no longer displayed on the screen
are true.

At the time, Vista 1.24 was the current release.

Once Tom took up the challenge, in fairly short order (no comment from 
me on how much work it did or did not take to do it) there was a quite 
impressive (to me) Vista 1.25 which did a very good job of displaying 
the graphics that I could produce.


But Tom has serious paying customers who don't really care for what I 
may or may not want in a TN3270 client and so I gather that these code 
changes were more of a prototype quality rather than production quality 
code and so were not copied into the product's code base used going forward.

(Tom can correct me here if I have any of this wrong, of course.)

I think it was Win7 that introduced the Program Data directory, yes?

Anyway, Tom had to make a change to Vista so it was a happy Win7 citizen 
(IIRC).  The net result of the new directory paradigm was that it was a 
pain to use the 1.25 version under Win7 and later so I gave it away in 
the end.


Hmmm, probably time to cast the net more widely...

I still refer anyone who asks me about Vista 1.25 to Tom.

I asked Paul Mattes about x3270 graphics support, and he said that it 
was a to-be-done thing and had been for years.  I gave him a TSO 
graphics program in my brief dialogue with him, and he said that he now 
had his sample application, the lack of which had been one of the 
stumbling blocks up till that time.  He seemed confident that rendering 
symbols constructed at run-time would not be a problem.  I can't see 
that much has been done in this area in the years since, though.  Still,
he does work on it without pay (I believe) so that's understandable. 
It's probably better to keep it running satisfactorily for the existing 
customer base that to appease a former MVS sysprog.


My next port-of-call was Hans Erik at Nexus Terminal.

I went through my shtick and he also took up the challenge.  Further, it 
is now part of the base product, and therefore officially supported, I 
believe.


So, for regular 3270 work, I have the choice of two great TN3270 
clients, both with expert support, and for my graphics work, there's 
Nexus Terminal.


(Bonus points for spotting that the map on the http://www.nexit.com/ web 
page is from one of my sample pictures available from the REVIEW (TSO 
command) home page and from CBT file 134.)



Cheers,
Greg

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

Re: Graphic output on the mainframe (was: Shocking Bug in Latest PCOMM Release)

[Greg Price]

On 2017-11-27 8:06 PM, Bernd Oppolzer wrote:

I guess, the original 3279 G displays had small (HP?) plotters
attached to them, so that the content of the display could
simply be hardcopied by pressing a certain key (or controlled
by the application, maybe).


Our SAS/MXG performance guy back in the day had a Memorex 3279G 
look-alike with its own printer that printed the screen image when the 
hardcopy print key on the terminal's keyboard was pressed.


IBM may have had similar hardware, but OEM stuff was cheaper.

We did have a real 3279G which exhibited the "green lightning" while the 
LPS (load programmed symbols) data stream was being processed.


Cheers,
Greg

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

Re: TADz or P-Tracker?

[Greg Price]

On 2017-08-22 11:24 PM, Dyck, Lionel B. , TRA wrote:

Can anyone comment on list or direct message about either TADz or P-Tracker for 
software asset management.


Hi Lionel,

I would imagine that the choice depends on what you want it to tell you, 
and how much you are prepared to pay (money, resources, etc.) to get it.


Do you want to know about programs, products or both?
Do you want to know about LPA program usage?
Do you want product identification?
Do you want product version/release details?
Do you want to know about UNIX programs?
Do you want to track Java usage?
Do you want to know what software may be lurking on DASD even if it's 
not being used?
Do you want to look at the data as an asset manager, or as a systems 
programmer, or both?

Do you want reporting to be browser-based, scheduled batch job(s), or both?
Do you want trend reports?

I expect there's plenty of other questions that could be added to the 
above list.


TADz requires a data base.  Most use DB2 but SQLite is also possible.
You only need the data base on 1 LPAR to which you send the collected 
information from all LPARs.  If DASD is shared then "sending" is easy.


Disclosure: I've spent my 10 years at IBM on the TADz team (Dev & L3).
I will be leaving IBM's employ at the end of this month (August 2017).
Actually, I was also the last maintainer (L3) of TLCMz (formerly 
Isogon's SoftAudit) until it went EOS in 2010 (but am not at all a TLCMz 
or SoftAudit usage expert).  The only other IBM software I ever 
supported was DLA for z/OS (2014-2016).


Cheers,
Greg

P.S. If you have any questions about TADz then feel free to email me and 
I'll endeavour to get the answer for you.  For the next week or so use

gpr...@au1.hal.com
where each letter of "hal" has to incremented to the next letter in the 
alphabet.

:)

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

Re: Useful recent changes to CBT File 300 (TSO commands)

[Greg Price]

On 2017-08-16 6:28 AM, PINION, RICHARD W. wrote:

I've looked through the CBT index and haven't found anything, but are you aware 
of
a program to release free space?


The RLSE/RELEASE TSO command on the CBT tape - yet another gem from Bill 
Godfrey - not only allows freeing all unused space, and specifying the 
number of tracks to leave, but also has the feature I enjoy most, which 
is to only free any extents which are completely unused.


Cheers,
Greg

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

Re: IEFUJI or IEFUJV sample %%%$$%#????

[Greg Price]

On 5/10/2014 4:00 PM, Brian Westerman wrote:

Thanks for reminding me that things like this seem to happen from time to time 
on all lists.


Yes, I there were fireworks-a-plenty on various OS/2 lists from years 
ago that I recall...


Anyway, Brian, I want to thank you (I believe it was you) for your JES2 
exit work from decades ago which gave us MAX COND CODE reporting in the 
JES2 NOTIFY messages (I didn't work on JES3 systems so I don't know the 
situation for that environment).  Eventually this functionality was 
shipped by IBM (a while ago, now, of course).  And thanks again for your 
rework of this for MVS 3.8 in more recent times.


Cheers,
Greg

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

Re: Mainframe jargon and acronyms wasRe: AMBLIST, AMASPZAP, and UNIX Program Objects

[Greg Price]

On 16/08/2014 10:10 AM, Shmuel Metz , Seymour J. wrote:

No. S/360 used read only storage for microcode until the 360/25,
except for a small amount on the 360/85. The term initial
micro-program load (IMPL) came in with the S/370; I don't recall when
they shortened the abbreviation to IML.


I'd say the early 1980s.

Any chance it was around the time of the 4300 series?


Cheers,
Greg

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

Re: AW: Retireiving DCB information for migrated datasets

[Greg Price]

On 31/07/2014 1:51 AM, Christian Birr wrote:

It came back with an RC of 4, contact your system support,

 which is mainly me and myself. I haven't the time to inspect
 the code more deeply, but could it be, there's a mismatch
 between you home grown MCD DSECT and the current one?
 The listing of the DESCT is right beside me and I'll look
 into it tomorrow, or might it be an error on my side?

Hi Christian,

My guess is that you did not change the hard-coded data set name of 
HSM.MCDS to the name of your MCDS before you assembled it.  Also ensure 
that the dsname length is correct.


If you are interested in reports, you may want to consider the 
wider-report version called $HMLISTW.


Cheers,
Greg

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

Re: Retireiving DCB information for migrated datasets

[Greg Price]

On 30/07/2014 4:56 PM, גדי בן אבי wrote:

Is it possible to retreive DCB information (LRECL, BLKSIZE, RECFM, DSORG) for 
migrated datasets, without recalling the dataset?


Check out the $HMLIST command in CBT file 134.
It reads the MCDS directly.
Output can go to the terminal or a data set.

Cheers,
Greg

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

Logon with neither BELL nor whistle

[Greg Price]

Anyone else noticed that the 3270 audible alarm has gone from the TSO/E 
full screen LOGON panel display?


Probably a good move...

First IEF374I becomes IEF032I and now this - it's a wild ride!



Cheers,
Greg

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

Re: Logon with neither BELL nor whistle

[Greg Price]

On 25/06/2014 8:31 PM, Elardus Engelbrecht wrote:

Anyone else noticed that the 3270 audible alarm has gone from the TSO/E full 
screen LOGON panel display?

No, last time I heard it was on a 3279 terminal. Hmmm, why must an alarm be 
sounded upon logon?



First IEF374I becomes IEF032I and now this - it's a wild ride!

More than a wild ride! IEF374I and IEF376I are discontinued and replaced by 
IEF032I and IEF033I on z/OS v1.13.


TSO/E for z/OS 1.12 still sounds the BEL (as perhaps I should have 
called it in the subject, recalling an S.Metz comment re NUL vs NULL) at 
the LOGON panel, whereas 1.13 and 2.1 do not.  That's what I observe, 
anyway.  YMMV


I guess it used to demand our attention with imperious authority decades 
ago, but perhaps now we're all laid-back internetters it can no longer 
do so.  What's next?  Conversion of IKJ messages to lower case?  *shudder*


:)

Cheers,
Greg

P.S.  I'm in the southern hemisphere, so that makes the time zone Friday 
here, right?


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

Re: CSVQUERY Anomaly

[Greg Price]

On 9/06/2014 2:43 PM, MichealButz wrote:

I set a program in all 3 places of LPA modified,fixed,pageable via the
SETPROG console command however in all instances the CSVQUERY returns a
X'04' in ATTR3 byte

Indicating the program is in CSA. Additionally I added the OUTVALID param
and it indicates that all three attribute bytes are valid


If you did it via the SETPROG command then it is in CSA.
To get it not be in CSA you have to get it loaded at IPL time before CSA 
exists.  AT least, AFAIK.


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

Re: Is there a DSECT macro that maps VSAM ACB MACR1, etc.?

[Greg Price]

On 23/05/2014 10:17 AM, Ed Jaffe wrote:

Hopefully, you're referencing target libraries (e.g., SYS1.MACLIB,
SYS1.MODGEN)


So, if you're not au fait with the likely component prefix of any 
potential macro member containing the DSECT, but you think you know what 
a potential member name would contain (the string 'ACB' in this case), 
use the free PDS command.


PDS 'SYS1.MACLIB' PAT ACB
and
PDS 'SYS1.MODGEN' PAT ACB
and check out any likely candidates it throws up.

Cheers,
Greg

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

Re: TPUT in FULLSCR problems

[Greg Price]

On 24/05/2014 7:16 AM, Gerhard Postpischil wrote:

E77F is row 32, position 80 (relative to 1,1)


ISTR that TCAM had some SBA order protocol that was recognized for full 
screen admin (TCAM escape sequences ??), which was not required in a 
VTAM context because of explicit SVC 94 VTAM macros to perform such 
functions.


Any truth to this, or did I just make it up?

Anyway, re the OP's concern, the changing font size indicates changing 
screen dimensions.  Ergo, there are two screen sizes involved (the 
primary and the alternate) which are different, and the thing that 
expects the larger size gets the error when the terminal is switched to 
the smaller size.


I will hazard that the situation is as follows:
1. User logs on to a 32x80 screen, and gets into ISPF or stays at the 
READY prompt.
2. User cranks up the full screen app under discussion which issues a 
full screen TPUT switching the screen to 24x80.
3. The full screen app terminates leaving the screen in the primary 
screen size (24x80).
4. ISPF or the TMP resume control, and a TPUT with an order such as SBA 
or RA is issued which is intended to address the highest screen 
location.  This location is larger than the current screen size and an 
error ensues.


The solution?
Put the screen size back to the way it was when the full screen app 
received control before terminating.

I am confident that replacing the
STFSMODE OFF
with
STLINENO 1,MODE=OFF
would fix it when the app is running from the READY prompt.

Or at least I would be, except that I now see there is such a macro 
listed in the posted code after the STFSMODE ON and before the TPUT 
FULLSCR.  Since the FM indicates that MODE=OFF is the default for 
STLINENO, the app's full screen I/O does NOT operate under VTAM's 
(screen) page protection, and the STFSMODE OFF at the end is a no-op.


That is, I conclude that the TPUT FULLSCR altered screen size while in 
line mode without telling the TMP.

Naughty, naughty [waving finger in admonishment].
:)

So, simply removing the STLINENO macro may fix it.

Perhaps the next screen management enhancement which could be slated for 
this app is to detect that if the screen has 80 columns then avoid any 
screen size change at all?  (That is, tolerate 80 column screens with 
more than 24 lines.  If you want to repeat blanks or nulls or any 
character to the end of the screen, use RA to location zero - this works 
for every screen size.)


Cheers,
Greg

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

Re: TSO 3270 Data Stream question

[Greg Price]

On 16/05/2014 7:53 AM, Micheal Butz wrote:

Yes but why these printable ebcdic codes


If you really want to know, look at
http://www.prycroft6.com.au/misc/3270.html
which I wrote when I thought I knew what I was talking about, but it 
turned out I didn't. HOWEVER, about a quarter of the way into it is an 
update from May 2010 in colored text which gives the real reason.


Cheers,
Greg

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

Re: TSO 3270 Data Stream question

[Greg Price]

I agree that decimal location 2260 could be addressed by using the 3270 
order x'11E3D4' in 12-bit addressing mode.


For a 24 by 80 screen, column 1 of row 5 means decimal location 4 x 80 
which is 320.  For this location I would expect the order x'11C540'.


Cheers,
Greg

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

Re: FINDING CLUSTER NAME

[Greg Price]

On 15/05/2014 11:42 PM, Staller, Allan wrote:

LISTC ENT(' HESP.BALFWD.DEFINE.DATA') ALL

The cluster name will be in the specified in the output.
The most likely name is ' HESP.BALFWD.DEFINE'


What Allan said

Of course, the catalog entry may not exist, hence the problem.
Also check for non-VSAM entries of the same name pointing to DFHSM 
migrated data sets (if you run DFHSM, of course).


If you would like proof of the cluster name without relying on the 
odds-on likelihood that the cluster name is the data component name with 
the trailing .DATA chopped off, then you could browse the contents of 
the VVDS where the names should appear in plain text.


I have not done so for years, but to browse VVDS - and BCS for that 
matter - files I used to use an APF authorized alias of the public 
domain REVIEW command. REVIEW contains no MODESET macros - the system 
lets normal VSAM OPEN process BCS and VVDS files (for INPUT, anyway) if 
the environment is APF authorized. At least, it did a few years back, 
and I have not heard of any changes in this area.


And I should also say that for every other use of REVIEW (available from 
the CBT tape) it is best to not run it APF authorized. For one thing, 
as a rule ISPF does not like its services being invoked in an APF 
authorized environment.


Topic drifting ever so slightly, time was when BSAM could read VSAM 
components. Around 1986 it even seemed to bypass RACF, but the RACF hole 
was soon plugged. DFP V2R4 introduced the requirement that DCB (input 
only) access to VSAM required APF authorization, but that only worked 
when the VSAM component being opened did not have more than 16 extents. 
Ah, good times...

:)

Cheers,
Greg

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

Re: curious: volsers 6 non-blank chars non-numeric tape

[Greg Price]

On 16/03/2014 2:53 AM, Paul Gilmartin wrote:

CA-1's support of non-number tape serials was difficult (needed some sort
of mapping exit as I recall).


Yes, because management got thousands of tape labels printed for the new
MVS system before the sysprogs heard about it.


Details?  Does the exit merely map non-number tape serials to numeric?


Yes, my recollection is that the exit's function was to  convert 
non-numeric characters to EBCDIC numeric characters and then pass it on 
for normal processing.  There may even have been a reverse the 
process exit - sysprogs who look after such a beast now would be able 
to say for sure.


The reason for the non-numeric characters?
Management thought it might be nice if the first two characters were 
alphabetics forming a common abbreviation of the corporation name.


Yes, this did limit the tape library to 10**4 carts (this was the epoch 
of 3480 cartridge drives), but that limit was not reached while I was there.


I am sure you can imagine our delight when we found out yet another 
little set up (the new system) task that could have been oh-so-easily 
avoided.  And yes, there were upgrades done for which we forgot about 
the exit - until jobs ran which could not use their tapes.  Oh for DLPA 
back then


Cheers,
Greg


---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com

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

Re: curious: volsers 6 non-blank chars non-numeric tape

[Greg Price]

On 15/03/2014 4:49 AM, John McKown wrote:

2) Has any commercial shop ever used non-numeric tape volume serials for
normal in-house tapes? If so, why? I ask because, at least historically,
CA-1's support of non-number tape serials was difficult (needed some sort
of mapping exit as I recall).


Yes, because management got thousands of tape labels printed for the new
MVS system before the sysprogs heard about it.

Delusions above their station in life, if you ask me...

And yes, we had to maintain that irritating exit...

:(



---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com

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

Re: Number of entries in the TIOT

[Greg Price]

On 6/02/2014 6:02 AM, Ed Finnell wrote:
 It is in LSQA,  key zero if I remember correctly.

Well, actually, key one, subpool 236
which is private high but not LSQA strictly speaking.

That is, I claim it is possible to take a page fault when
scanning the TIOT of a swapped in address space.
(No page faults are possible when accessing GETMAINed
subpool 255 storage of a swapped in address space.)

The TIOT subpool is taken from JSCBSWSP.
This is all from the Data Areas book.
(Book hints at subpool 237, but for my TSO session it is 236.)

BTW, re the XTIOT thread - the guts of an XTIOT
entry is the same as a TIOT entry, but XTIOT
entries are allocated in isolation as required.
(ie. They are not in a contiguous block like the TIOT.)
I expect someone already covered that.

*Danger!*  Possibly annoying free software plug follows!

If you go to
http://www.prycroft6.com.au/REVIEW/
and download the z/OS executables for
REVIEW Release 44.2
and make it a runnable TSO command,
then you can issue
REV 'ACTIVE'
to view your virtual storage.  Issue
L 21C%+C%
to view your TIOT and you will see the 3rd screen line has:
KEY 1SUBPOOL 236  OWNED BY IEESB605

You should be able to get the same information from IPCS
using a similar method, perhaps using the WHERE subcommand.

Cheers,
Greg




---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com

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

Re: DCB for load library

[Greg Price]

On 6/02/2014 11:25 AM, Micheal Butz wrote:

Is there any way of knowing a data set contains load modules

I know that it has a RECFM=U LRECL =0


I use

Lib:
RECFM=U - a gimme.
LRECL might be anything - if something makes it non-zero (easy to do) it 
will not usually get changed back to zero.

BLKSIZE1023 - Max BLKSIZE of 1024 output when linked with DC.

If PDSE verify it is a program (and not a DATA) PDSE using ISITMGD macro.

Member:
Need at least 9 halfwords of userdata for old OS module.
(Could assume modern load modules and increase accordingly.)
Need non-zero NOTE list count.
If more than 1 then OK.
If exactly 1 then do 2 checks:
Check 1: if OVLY or SCTR then not a load module.
Check 2: Check for IMS ACBLIB member.
2a: If PDS2INDC=x'2E' then it is ACBLIB member.
2b: If ACBLIB user data date stamp sign nibble is x'F' then it is an 
ACBLIB member.  (TM PDS2NL,X'0F' - BO NotPgm)


Cheers,
Greg


---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.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

[Greg Price]

On 28/11/2013 7:42 AM, Pommier, Rex wrote:

 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?

Which subpools are the 21MB in?

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

Re: free zIP/UNZIP in z/OS

[Greg Price]

Doesn't the GCC package ship the MINIZIP and MINIUNZ programs which can 
be used as stand-alone utilities? If you just want to zip up sequential 
and partitioned data sets, and optionally transfer to other platforms, 
they might fit the requirement.


One form of these programs is in CBT file 135 - note that file STDOUT 
must be allocated.


Cheers,
Greg

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

Re: Anyone know how to copy a PDS directory as a flat file?

[Greg Price]

On 8/09/2012 1:49 AM, Bob Shannon wrote:
 Since the format of PDSEs has never been published, and since directory space 
 can be created when 
needed in non-contiguous areas, I seriously doubt ISPF can read the directory 
as a PS data set.

Well, if reading the directory with QSAM or BSAM counts, then why not?

The REVIEW command can be used with the DATA operand
to browse the directory of a PDS or PDSE.  It uses BSAM so
the hardware keys can be seen as well.  You could then
use the CUT subcommand to copy it to a data set if that
was your fancy.

For a PDSE end-of-file is presented right after the last
used directory block, whereas for a PDS the unused
directory blocks can also be read before reaching
end-of-file.

Time was when the first QSAM GET to a PDSE directory
returned a buffer of mainly zeros, but the second GET
gave access to the first (mocked up by the system)
directory block.  That was fixed a decade or two ago.

So, if ISPF reads the directory sequentially (and I do not
know if it does or not, though SMF 14/15 records might
give a clue) it could acquire all of the ISPF stats and
usual load module attributes for PDS and PDSE members.

Of course, DESERV does give extra directory entry
information for program objects which are not present
in the data structure described by the IHAPDS macro.

OTOH, I agree that ISPF would not directly access the 4K
blocks on the tracks occupied by a PDSE and figure out
the stats and facts using logic which decodes the internal
PDSE data structures.

Cheers,
Greg Price

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