Re: z/TPF questions

[Timothy Sipples]

Radoslaw Skorupka got some good answers to his questions, but I can fill 
in some gaps:

2. While z/TPF can certainly run as a z/VM guest, that's at least not 
common for production instances.

3.1. There's a base z/TPF license plus some popular options such as the 
z/TPF High Performance Option (HPO) and z/TPF Database Facility (z/TPFDF). 
There are some other software products that are popular add-ons to the 
z/TPF -- some no additional charge, some not.

3.2. As many have mentioned, z/TPF tends to be extremely efficient in its 
real world implementations. Pricing only partially reflects its 
efficiency, i.e. most of its efficiency accrues to the benefit of its 
users.

4. I'm not aware of any particularly special LPAR definitions other than 
what has already been mentioned.

5. z/TPF can have speciality engines, but they're not zIIPs. As Parwez 
mentioned, in the unlikely event you ever need more SAPs than the standard 
system-provided default number, z/TPF is the most likely candidate to 
drive such a requirement (although even with z/TPF it's not a given). 
There's also the interesting concept of "specialty CPs" -- CPs that are 
technically CPs but that are priced and licensed for specific workloads. 
However, z/TPF isn't unique in this respect.

7. There's an active z/TPF users group called TPFUG:

http://www.tpfug.com

They're holding their next conference next month (April, 2021).

8. The most common industries using z/TPF are "T&T" (travel and 
transportation, including hospitality) and financial services 
(particularly in payments).

Regarding an earlier comment about programming languages, yes, the "big 
three-ish" programming languages for z/TPF are Assembler, C and C++, and 
Java. However, in principle any programming language that can run on the 
Java Virtual Machine is also available. Examples include Clojure, Kotlin, 
Jython, jRuby, NetRexx, Groovy, Scala, and Nashorn (JavaScript). Also, 
z/TPF can host the MySQL database. Thus SQL is a programming language 
for/on z/TPF.

Also, while it's popular for many reasons to pair z/TPF with z/OS, it's 
not strictly required.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

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

Re: Contents of TOD Programmable Field under z/OS?

[Gibney, Dave]

A 64 bit (or longer)  binary counter?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Timothy Sipples
> Sent: Sunday, March 21, 2021 8:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Contents of TOD Programmable Field under z/OS?
> 
> It's possible for a random number generator to produce duplicate output.
> Statistically speaking, a duplicate (random number collision) is
> guaranteed if you keep generating random numbers and merely wait long
> enough. If you combine a time of day number (which is generally assumed
> monotonically increasing, unless someone does something particularly
> "clever") with a "long" random number then collisions are improbable but
> technically not altogether impossible.
> 
> Do you need *guaranteed* uniqueness? If you do, the Db2 suggestion is a
> very good one if you have Db2 or get it. Broadly comparable facilities are
> available in MQ if you want a guarantee of Sysplex-wide uniqueness. (This
> is a well solved problem in z/OS-based middleware.) Or you could check
> each new time+random value against running lists of past time+random
> values where time=time, discarding the prior list when new time > old
> time. This roll-your-own approach takes some effort if you want it to be
> robust.
> 
> Yet another approach is that you voluntarily allow and require time to
> elapse before generating the next time+random value. If you wait long
> enough, there's no time collision. But then you probably wouldn't use a
> random add-on but rather a dimensionally "big" sequence string, unless the
> random portion is somehow useful. For example your string could be in the
> format:
> 
> A + B + C
> 
> where A is the finest grained time of day you can get, B is a unique
> program instance ID (e.g. in a 2-way Sysplex with a maximum of 2 instances
> of the program running, this could be "X" or "Y"), and C is a "long"
> sequence string. While A = A, you simply increment through C. In the
> extraordinarily improbable event you ever get to the end of C (since
> you've made it dimensionally big enough for even Year 8000 computing
> power), you refuse to keep processing and yield even discretionary
> dispatching until A must have incremented. (Which you still verify with an
> A new v. A prior comparison.)
> 
> Or, instead of an explicit B, you vary the C list depending on program
> invocation context, which amounts to the same thing.
> 
> Lots of options! I don't quite understand the end goal, though, so it's a
> bit difficult to decide which one of these approaches, or some other, is
> the best fit.
> 
> - - - - - - - - - -
> Timothy Sipples
> I.T. Architect Executive
> Digital Asset & Other Industry Solutions
> IBM Z & LinuxONE
> - - - - - - - - - -
> E-Mail: sipp...@sg.ibm.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Contents of TOD Programmable Field under z/OS?

[Timothy Sipples]

It's possible for a random number generator to produce duplicate output. 
Statistically speaking, a duplicate (random number collision) is 
guaranteed if you keep generating random numbers and merely wait long 
enough. If you combine a time of day number (which is generally assumed 
monotonically increasing, unless someone does something particularly 
"clever") with a "long" random number then collisions are improbable but 
technically not altogether impossible.

Do you need *guaranteed* uniqueness? If you do, the Db2 suggestion is a 
very good one if you have Db2 or get it. Broadly comparable facilities are 
available in MQ if you want a guarantee of Sysplex-wide uniqueness. (This 
is a well solved problem in z/OS-based middleware.) Or you could check 
each new time+random value against running lists of past time+random 
values where time=time, discarding the prior list when new time > old 
time. This roll-your-own approach takes some effort if you want it to be 
robust.

Yet another approach is that you voluntarily allow and require time to 
elapse before generating the next time+random value. If you wait long 
enough, there's no time collision. But then you probably wouldn't use a 
random add-on but rather a dimensionally "big" sequence string, unless the 
random portion is somehow useful. For example your string could be in the 
format:

A + B + C

where A is the finest grained time of day you can get, B is a unique 
program instance ID (e.g. in a 2-way Sysplex with a maximum of 2 instances 
of the program running, this could be "X" or "Y"), and C is a "long" 
sequence string. While A = A, you simply increment through C. In the 
extraordinarily improbable event you ever get to the end of C (since 
you've made it dimensionally big enough for even Year 8000 computing 
power), you refuse to keep processing and yield even discretionary 
dispatching until A must have incremented. (Which you still verify with an 
A new v. A prior comparison.)

Or, instead of an explicit B, you vary the C list depending on program 
invocation context, which amounts to the same thing.

Lots of options! I don't quite understand the end goal, though, so it's a 
bit difficult to decide which one of these approaches, or some other, is 
the best fit.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

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

Re: Overlapped I/O completion

[Charles Mills]

Implementing overlapped I/O is what QSAM does. You don't even need to code
BUFNO. IMHO it is one of the two main points of QSAM, the other being
blocking and de-blocking.

I agree on GET LOCATE. PUT LOCATE on the other hand is a PITA (IMHO, of
course).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Sunday, March 21, 2021 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Overlapped I/O completion

So implementing asynchronous I/O in  QSAM is as simple as having BUFNO= the
right number

thanks   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Michael Stein
Sent: Sunday, March 21, 2021 5:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Overlapped I/O completion

On Sun, Mar 21, 2021 at 04:54:45PM -0400, Joseph Reichman wrote:
>  Just to make sure I am understanding correctly I use GETPOOL/GETBUFF  
> with QSAM it will use Asynchronous/overlapped i/o right ?

You should only need DCB/OPEN/CLOSE/GET.  

Let most everything default, QSAM knows what to do for a DASD dataset.
The RECFM/BLKSIZE/LRECL will be obtained during OPEN from the existing
dataset.

xxDCB   DSORG=PS,MACRF=GL,EODAD=myeof,DDNAME=mydd

Do set BUFNO= to some number, perhaps the number of *blocks* in a cylinder
via the DCB keyword, dynamic allocation, or JCL DD DCB=BUFNO=.

Use MACRF=GL, get locate mode.  On a GET call, QSAM returns the address of
the next *record* (not block) in R1 (R1 points to the RDW if RECFM V).

You can reference this record until you issue the next GET for this DCB.
Locate mode avoids anyone having to copy the data -- it's in QSAM's I/O
buffer.

If you don't need the storage, for a first try, just run R24/A24.

Then you don't need to deal with things like the DCB has to be R24 and need
the DCBE for various A31 things (EOD/SYNAD A31, buffers above the line,
etc).

For A31 access you will likely need a DCBE and more care with which mode
(OPEN/CLOSE MODE=31, calling GET A31, still need DCB in R24 storage).

The related manuals are (the QSAM related sections of):

  z/OS DFSMS Using Data Sets
  z/OS Macro Instructions for Data Sets

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

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

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

Re: Overlapped I/O completion

[Joseph Reichman]

So implementing asynchronous I/O in  QSAM is as simple as having BUFNO= the
right number

thanks   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Michael Stein
Sent: Sunday, March 21, 2021 5:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Overlapped I/O completion

On Sun, Mar 21, 2021 at 04:54:45PM -0400, Joseph Reichman wrote:
>  Just to make sure I am understanding correctly I use GETPOOL/GETBUFF  
> with QSAM it will use Asynchronous/overlapped i/o right ?

You should only need DCB/OPEN/CLOSE/GET.  

Let most everything default, QSAM knows what to do for a DASD dataset.
The RECFM/BLKSIZE/LRECL will be obtained during OPEN from the existing
dataset.

xxDCB   DSORG=PS,MACRF=GL,EODAD=myeof,DDNAME=mydd

Do set BUFNO= to some number, perhaps the number of *blocks* in a cylinder
via the DCB keyword, dynamic allocation, or JCL DD DCB=BUFNO=.

Use MACRF=GL, get locate mode.  On a GET call, QSAM returns the address of
the next *record* (not block) in R1 (R1 points to the RDW if RECFM V).

You can reference this record until you issue the next GET for this DCB.
Locate mode avoids anyone having to copy the data -- it's in QSAM's I/O
buffer.

If you don't need the storage, for a first try, just run R24/A24.

Then you don't need to deal with things like the DCB has to be R24 and need
the DCBE for various A31 things (EOD/SYNAD A31, buffers above the line,
etc).

For A31 access you will likely need a DCBE and more care with which mode
(OPEN/CLOSE MODE=31, calling GET A31, still need DCB in R24 storage).

The related manuals are (the QSAM related sections of):

  z/OS DFSMS Using Data Sets
  z/OS Macro Instructions for Data Sets

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

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

Re: Overlapped I/O completion

[Michael Stein]

On Sun, Mar 21, 2021 at 04:54:45PM -0400, Joseph Reichman wrote:
>  Just to make sure I am understanding correctly I use GETPOOL/GETBUFF
>  with QSAM it will use Asynchronous/overlapped i/o right ?

You should only need DCB/OPEN/CLOSE/GET.  

Let most everything default, QSAM knows what to do for a DASD dataset.
The RECFM/BLKSIZE/LRECL will be obtained during OPEN from the existing
dataset.

xxDCB   DSORG=PS,MACRF=GL,EODAD=myeof,DDNAME=mydd

Do set BUFNO= to some number, perhaps the number of *blocks* in a cylinder
via the DCB keyword, dynamic allocation, or JCL DD DCB=BUFNO=.

Use MACRF=GL, get locate mode.  On a GET call, QSAM returns the address
of the next *record* (not block) in R1 (R1 points to the RDW if RECFM V).

You can reference this record until you issue the next GET for this DCB.
Locate mode avoids anyone having to copy the data -- it's in QSAM's
I/O buffer.

If you don't need the storage, for a first try, just run R24/A24.

Then you don't need to deal with things like the DCB has to be R24 and
need the DCBE for various A31 things (EOD/SYNAD A31, buffers above the
line, etc).

For A31 access you will likely need a DCBE and more care with which mode
(OPEN/CLOSE MODE=31, calling GET A31, still need DCB in R24 storage).

The related manuals are (the QSAM related sections of):

  z/OS DFSMS Using Data Sets
  z/OS Macro Instructions for Data Sets

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

Re: z/TPF questions

[Radoslaw Skorupka]

The rules is *sometimes* true. But not always.

Few examples:
Tapes: 726, 727, 728, 729, 7330 ...24xx family, 34xx family, 3480, 3490 
---> 3590, 3592.

CPC: 9671, 20xx, 390x, 856x
Libraries: 3995, 3994, 3584, 3995...
Disk: 5444, 1405
and 7302 - not a disk...
2301 is a drum - DASD, but not disk


However fortunately this is finite list. And documented quite well. Of 
course similar and somehow consecutive names are easier to remember: 
when we talk about 3390, 3380, 3350, or 3330 we actually have to 
remember only one character. Things become worse when talking about 
93... yes. 93-something.



--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland



W dniu 21.03.2021 o 22:19, Charles Mills pisze:

x2yz would be a terminal type device (e.g. 2260, 3270)
x3yz would be a disk type device (e.g. 2301, 2311, 2314, 3330, 3390)
x4yz would be a tape type device (e.g. 2400)
x5yz would be a card type device (e.g. 2540)
x7yz would be telecommunications type device (e.g. 2701, 2780, 3780)

In all cases x=2 would be "second generation," i.e. System 360; x=3 would
the "third generation," i.e. System 370.

x=1 would be first generation and is a different numbering scheme -- e.g.
1052 is a console, 1403 is a printer.

IIRC the S/360 CPUs were, e.g., 2040 for the 360/40 and the S/370 CPUs were,
e.g., 3155 for the 370/155

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Sunday, March 21, 2021 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/TPF questions


The 3215 was the s/360 console printer keyboard

No; the 1052-7 was the console typewriter for various S/360 models. The 3210
and 3215 were console typewriters for low end S/370 models, eventually
replaced by special models of the 3270, e.g., 3278-2A, 3279-2C.

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


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

Re: Overlapped I/O completion

[Joe Monk]

If youre using GETPOOL/GETBUF then youre not doing QSAM. GETBUF is for
BSAM. You would be OPENING the  file then using READ macros to read  in
your records.

If youre doing QSAM,  then you just issue the OPEN followed by a GET.
There is no READ. The system takes care of the READs and buffers.

Joe

On Sun, Mar 21, 2021 at 3:55 PM Joseph Reichman 
wrote:

> Joe
>
>  Just to make sure I am understanding correctly I use GETPOOL/GETBUFF with
> QSAM it will use Asynchronous/overlapped i/o right ?
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Joe Monk
> Sent: Sunday, March 21, 2021 1:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Overlapped I/O completion
>
> "The queued access technique provides GET and PUT macro instructions for
> transmitting data within virtual storage. These macro instructions cause
> automatic blocking and deblocking of the records stored and retrieved.
> Anticipatory (look-ahead) buffering and synchronization (overlap) of input
> and output operations with central processing unit (CPU) processing are
> automatic features of the queued access technique.
>
> Because the operating system controls buffer processing, you can use as
> many input/output (I/O) buffers as needed without reissuing GET or PUT
> macro instructions to fill or empty buffers. Usually, more than one input
> block is in storage at any given time, so I/O operations do not delay
> record processing.
>
> Because the operating system synchronizes input/output with processing,
> you need not test for completion, errors, or exceptional conditions. After
> a GET or PUT macro instruction is issued, control is not returned to your
> program until an input area is filled or an output area is available. Exits
> to error analysis (SYNAD) and end-oC-volume or end-of-data (EODAD) routines
> are automatically taken when necessary.
>
> The GET macro instruction obtains a record from an input data set. It
> operates in a logical sequential and device-independent manner. As
> required, the GET macro instruction schedules the filling of input buffers,
> deblocks records, and directs input error recovery procedures. For
> sequential data sets, it also merges record segments into logical records.
> After all records have been processed and the GET macro instruction
> detects an end-of-data indication, the system automatically checks labels
> on sequenti'1l data sets and passes control to your end-of-data (EODAD)
> routine. If an end-of-volume condition is detected for a sequential data
> set, the system provides automatic volume switching if the data set extends
> across several volumes or if concatenated da~a sets are being processed. If
> you specify OPTCD=Q in the DCB, GET causes input data to be translated from
> ASCII to EBCDIC."
>
> http://www.bitsavers.org/pdf/ibm/370/OS_VS2/Release_3.8_1978/GC26-3875-0_OS_VS2_MVS_Data_Management_Services_Guide_Rel_3.8_Jun79.pdf
>
> Joe
>
> On Sun, Mar 21, 2021 at 12:16 PM Seymour J Metz  wrote:
>
> > > When I do a qsam get the physical I/O is for 1 block every get just
> > > ups
> > a pointer
> >
> > No. When you do a GET, QSAM not only returns a logical record, it also
> > does whatever housekeeping is necessary. That includes scheduling the
> > I/O for subsequent blocks if necessary. Further, the number of CCWs is
> > not the same as the number of physical blocks. Further, the channel
> > program may include CCWs for multiple physical blocks. The scheduling
> > for QSAM is the same as the scheduling for BSAM. The advantage of QSAM
> > is that it requires less programming, at the expense of not supporting
> > FIND, NOTE, POINT or STOW.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> > behalf of Joseph Reichman [reichman...@gmail.com]
> > Sent: Sunday, March 21, 2021 10:21 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Overlapped I/O completion
> >
> > I don’t understand what the statement “QSAM does overlapped I/O
> > automatically”
> >
> > When I do a qsam get the physical I/O is for 1 block every get just
> > ups a pointer
> >
> > BSAM allows me to do multiple Reads each with their own DECB
> >
> > So I already initiate lots of physical I/O mainly because I have lots
> > of records or blocks
> >
> > I find it hard to believe that a qsam get does anything more than read
> > 1 block
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subsc

z/TPF Questions

[Barry Merrill]

MXG Support for TPF:

 

Change 17.200  Support for IBM's TPF Operating System.

EXTPFxxForty datasets are created from the fifty or so records.

FORMATSSome datasets are written at monitor initialization to

IMACTPFmap things, but the interval records are deaccumulated

TPFINTRV   and written as individual PDB datasets, and then TPFINTRV

TYPETPFis invoked to summarize into PDB.TPFINTRV.  This support

VMACTPFhas been tested with data from one system, and TPFINTRV

VMXGINIT   intervals the SA/NX/SX/SU/SP/MD/MG/FV/FS/SC records.

VMXGTPFI   This is preliminary support, but TPFINTRV and its input

Aug  2, 1999   datasets have been tested extensively; there are still a

   number of questions and some variable names may change.

  For over two years I have requested the DSECTS for the

  TPF records; it took a vote of the TPF Users Group to

  "convince" IBM it would be worthwhile to allow MXG to

  support this high-speed transaction processing system.

  Formerly know at the Airline Control Program, it can

  drive 30,000 I/Os per second on an 8-engines CPC!

   The initial development of the VMACTPF code took 40 hours

   across four days to write about 4,000 lines of SAS code.

   Another 40 hours were required to add the roughly 400

   lines to deaccumulate and validate the PDB.TPFINTRV data.

   Thanks to Jack Opgenorth, Sabre, USA.

   Thanks to Linda Tallent, Sabre, USA.

 

Last Change:

 

Change 28.152  Support for zTPFC, TPF Continuous Monitoring has a few

EXTPFC92   fields added to existing datasets and two new datasets

EXTPFC98   added by this change

IMACTPFC

VMACTPFC  DDDATASET   Description

Jul  2, 2010

Jul 21, 2010  TPFC92TPFC92LPAR UTILIZATION

  TPFC98TPFC98DASD SERVICE TIME

   Thanks to Bob Wilcox, HP, USA.

 

Herbert W "Barry" Merrill, PHD

President-Programmer

Merrill Consultants

MXG Software

10717 Cromwell Drive

Dallas, TX 75229

www.mxg.com  

214 351 1966 

 

ad...@mxg.com   for business questions

supp...@mxg.com   for technical questions

ba...@mxg.com    

 


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

Re: z/TPF questions

[Charles Mills]

x2yz would be a terminal type device (e.g. 2260, 3270)
x3yz would be a disk type device (e.g. 2301, 2311, 2314, 3330, 3390)
x4yz would be a tape type device (e.g. 2400)
x5yz would be a card type device (e.g. 2540)
x7yz would be telecommunications type device (e.g. 2701, 2780, 3780)

In all cases x=2 would be "second generation," i.e. System 360; x=3 would
the "third generation," i.e. System 370.

x=1 would be first generation and is a different numbering scheme -- e.g.
1052 is a console, 1403 is a printer.

IIRC the S/360 CPUs were, e.g., 2040 for the 360/40 and the S/370 CPUs were,
e.g., 3155 for the 370/155

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Sunday, March 21, 2021 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/TPF questions

> The 3215 was the s/360 console printer keyboard

No; the 1052-7 was the console typewriter for various S/360 models. The 3210
and 3215 were console typewriters for low end S/370 models, eventually
replaced by special models of the 3270, e.g., 3278-2A, 3279-2C.

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

Re: Contents of TOD Programmable Field under z/OS?

[Charles Mills]

> STCKF is better for cases where you do not need that uniqueness

Can't emphasize that enough. If you are using STCK and all you need is "the
time," not "a time that is not identical to any other possible STCK" then
you are wasting LOTS of CPU cycles -- use STCKF instead.

In fact, I guess you could extend that to say that *every* STCK is probably
a waste of CPU time. If you don't need a unique time, use STCKF. If you DO
need a unique time, modify your logic to allow the use of STCKE. (STCKF is
"plug compatible" with STCK; STCKE is not.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Sunday, March 21, 2021 6:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Contents of TOD Programmable Field under z/OS?

The STCKE result, like the STCK result, is architecturally guaranteed to 
be unique across all the CPUs used by an operating system image (i.e., 
within an LPAR). This is not a sysplex statement; sysplex is not an 
architectural construct. The STCKF result, on the other hand, is not 
guaranteed unique; using STCKF is better for cases where you do not need 
that uniqueness. The STCK instruction might have to spin in some cases 
where the same CPU issues consecutive STCK's very close together. STCKE 
theoretically might have to do so too but in practice I think does not, 
due to the significantly greater granularity.

Peter Relson

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

Re: Overlapped I/O completion

[Joseph Reichman]

Joe

 Just to make sure I am understanding correctly I use GETPOOL/GETBUFF with QSAM 
it will use Asynchronous/overlapped i/o right ?   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Sunday, March 21, 2021 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Overlapped I/O completion

"The queued access technique provides GET and PUT macro instructions for 
transmitting data within virtual storage. These macro instructions cause 
automatic blocking and deblocking of the records stored and retrieved.
Anticipatory (look-ahead) buffering and synchronization (overlap) of input and 
output operations with central processing unit (CPU) processing are automatic 
features of the queued access technique.

Because the operating system controls buffer processing, you can use as many 
input/output (I/O) buffers as needed without reissuing GET or PUT macro 
instructions to fill or empty buffers. Usually, more than one input block is in 
storage at any given time, so I/O operations do not delay record processing.

Because the operating system synchronizes input/output with processing, you 
need not test for completion, errors, or exceptional conditions. After a GET or 
PUT macro instruction is issued, control is not returned to your program until 
an input area is filled or an output area is available. Exits to error analysis 
(SYNAD) and end-oC-volume or end-of-data (EODAD) routines are automatically 
taken when necessary.

The GET macro instruction obtains a record from an input data set. It operates 
in a logical sequential and device-independent manner. As required, the GET 
macro instruction schedules the filling of input buffers, deblocks records, and 
directs input error recovery procedures. For sequential data sets, it also 
merges record segments into logical records.
After all records have been processed and the GET macro instruction detects an 
end-of-data indication, the system automatically checks labels on sequenti'1l 
data sets and passes control to your end-of-data (EODAD) routine. If an 
end-of-volume condition is detected for a sequential data set, the system 
provides automatic volume switching if the data set extends across several 
volumes or if concatenated da~a sets are being processed. If you specify 
OPTCD=Q in the DCB, GET causes input data to be translated from ASCII to 
EBCDIC."
http://www.bitsavers.org/pdf/ibm/370/OS_VS2/Release_3.8_1978/GC26-3875-0_OS_VS2_MVS_Data_Management_Services_Guide_Rel_3.8_Jun79.pdf

Joe

On Sun, Mar 21, 2021 at 12:16 PM Seymour J Metz  wrote:

> > When I do a qsam get the physical I/O is for 1 block every get just 
> > ups
> a pointer
>
> No. When you do a GET, QSAM not only returns a logical record, it also 
> does whatever housekeeping is necessary. That includes scheduling the 
> I/O for subsequent blocks if necessary. Further, the number of CCWs is 
> not the same as the number of physical blocks. Further, the channel 
> program may include CCWs for multiple physical blocks. The scheduling 
> for QSAM is the same as the scheduling for BSAM. The advantage of QSAM 
> is that it requires less programming, at the expense of not supporting 
> FIND, NOTE, POINT or STOW.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Joseph Reichman [reichman...@gmail.com]
> Sent: Sunday, March 21, 2021 10:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Overlapped I/O completion
>
> I don’t understand what the statement “QSAM does overlapped I/O 
> automatically”
>
> When I do a qsam get the physical I/O is for 1 block every get just 
> ups a pointer
>
> BSAM allows me to do multiple Reads each with their own DECB
>
> So I already initiate lots of physical I/O mainly because I have lots 
> of records or blocks
>
> I find it hard to believe that a qsam get does anything more than read 
> 1 block
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: CMS equivalent of ISPF SRCHFOR?

[Binyamin Dissen]

Thanks. Had to change the unprintable's but it works fine.

On Sat, 20 Mar 2021 19:35:49 -0400 Tony Thigpen  wrote:

:>There is not a 'standard' search tool in VM. There are numinous versions 
:>that are available for the asking. Just post a request on the VM list. 
:>Almost all of them are just a rexx wrapper for the xedit locate function.
:>
:>I have attached one of my may versions, the one I use mostly.
:>
:>Tony Thigpen
:>
:>Binyamin Dissen wrote on 3/20/21 4:09 PM:
:>> Is there a CMS command which will search a minidisk (or group of minidisks)
:>> for files containing a specific string?
:>> 
:>> Don't see anything obvious in the CMS manual.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: CMS equivalent of ISPF SRCHFOR?

[Binyamin Dissen]

Well, I downloaded and tried FERRET and it never found anything.

Unfortunately it is compiled so I could not figure out what was wrong.

Tried a single minidisk as well as multiple disks. Tried CAPS, tried lower
case, etc.

On Sat, 20 Mar 2021 23:05:11 -0400 Phil Smith III  wrote:

:>I just found my version of the SEARCH4 code on
:>
:>http://ukcc.uky.edu/~tools/1998/
:>
:>so anyone who wants it can get it there. Obviously let me know if that 
doesn't work.
:>
:> 
:>
:>Hint: the Sterling email addresses will NOT work!
:>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: z/TPF questions

[Seymour J Metz]

> The 3215 was the s/360 console printer keyboard

No; the 1052-7 was the console typewriter for various S/360 models. The 3210 
and 3215 were console typewriters for low end S/370 models, eventually replaced 
by special models of the 3270, e.g., 3278-2A, 3279-2C.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Attila Fogarasi [fogar...@gmail.com]
Sent: Saturday, March 20, 2021 4:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/TPF questions

Programs on ACP were limited to 4k size originally, and files were limited
to 2 record sizes (short and long), the sizes being optimized for 3211 disk
geometry.  Those limitations were removed 40 years ago :)  However the
speed of zTPF comes from not allowing applications to do things that
require expensive services, such as z/OS provides.
The 3215 was the s/360 console printer keyboard (much faster than a
typewriter -- it had to keep up).  z/TPF still supports 3215 protocol via
OSA card, but also has 3270 support.  The 3215 protocol has some big
advantages when its a computer at the other end doing automation, so still
popular.

On Sat, Mar 20, 2021 at 3:35 PM Tom Brennan 
wrote:

> Ah... that makes sense.  Then they might have been going over that 32 CP
> limit fairly soon after the limit was changed.  Being the first on your
> block to run new code is no fun at 2 in the morning.
>
> On 3/19/2021 8:15 PM, Mike Schwab wrote:
> > I think the limit was 32 z processors in an LPAR.  They might have
> > raised it by now.  z15 can have 190 in high capacity order.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: z/TPF questions

[David Spiegel]

You're right -- probably 2311 (DASD)
3211, however, was a printer.

On 2021-03-21 15:08, Radoslaw Skorupka wrote:

W dniu 20.03.2021 o 09:47, Attila Fogarasi pisze:
Programs on ACP were limited to 4k size originally, and files were 
limited
to 2 record sizes (short and long), the sizes being optimized for 
3211 disk

geometry.  Those limitations were removed 40 years ago :) However the
speed of zTPF comes from not allowing applications to do things that
require expensive services, such as z/OS provides.


Excuse me, but what is 3211?
I suspect a typo, but I found nothing similar.
2311 is too old IMHO (1964).
Maybe 3330-11 ?




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

Re: z/TPF questions

[Bill Johnson]

Xerox produced a 3211 cartridge disk system.


Sent from Yahoo Mail for iPhone


On Sunday, March 21, 2021, 3:09 PM, Radoslaw Skorupka  
wrote:

W dniu 20.03.2021 o 09:47, Attila Fogarasi pisze:
> Programs on ACP were limited to 4k size originally, and files were limited
> to 2 record sizes (short and long), the sizes being optimized for 3211 disk
> geometry.  Those limitations were removed 40 years ago :)  However the
> speed of zTPF comes from not allowing applications to do things that
> require expensive services, such as z/OS provides.

Excuse me, but what is 3211?
I suspect a typo, but I found nothing similar.
2311 is too old IMHO (1964).
Maybe 3330-11 ?


-- 
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

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




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

Re: z/TPF questions

[Seymour J Metz]

"3211" was presumably a typo for 2311, since the 3211 is an impact printer, 
substantially faster than the 1403 and with a forms control buffer (FCB) 
instead of a carriage tape.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Radoslaw Skorupka [r.skoru...@hotmail.com]
Sent: Sunday, March 21, 2021 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/TPF questions

W dniu 20.03.2021 o 09:47, Attila Fogarasi pisze:
> Programs on ACP were limited to 4k size originally, and files were limited
> to 2 record sizes (short and long), the sizes being optimized for 3211 disk
> geometry.  Those limitations were removed 40 years ago :)  However the
> speed of zTPF comes from not allowing applications to do things that
> require expensive services, such as z/OS provides.

Excuse me, but what is 3211?
I suspect a typo, but I found nothing similar.
2311 is too old IMHO (1964).
Maybe 3330-11 ?


--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

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

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

Re: Any z/OS sandbox available for a university student I know?

[John McKown]

atry this on a Windows Intel box . http://www.z390.org/

On Tue, Mar 16, 2021 at 11:55 AM Support, DUNNIT SYSTEMS LTD. <
supp...@dunnitsys.com> wrote:

> Hi all,
>
> I was approached by a university student who wants self study z/OS
> architecture and Assembler - including 64 bit programming - as an
> extra-ciricular activity. The guy is on a shoestring budget. Is there
> anything out there for such an aspiring mainframer? Thanks.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Overlapped I/O completion

[Seymour J Metz]

> Unless you are reading multple files (multiple DCBs) at once (each 
>with their own group of pending READs) issuing WAIT before 
> CHECK is just wasted effort/CPU time.

No. You may have CPU intensive work you can do.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Michael Stein [m...@zlvfc.com]
Sent: Saturday, March 20, 2021 11:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Overlapped I/O completion

On Fri, Mar 19, 2021 at 03:35:39PM -0400, Joseph Reichman wrote:
> So this is what I will do
>
> I’ll do 3 reads in the first since i need to get myself going I’ll issue the
> WAIT using the ECB from the DECB

Limiting the pending reads to 3 will limit the performance to worse
(or at least no better) than QSAM.

You did set NCP to a value at least high enough for the number of
pending READs you would have at any time, right?

Also keep in mind that you need to issue the wait/check on the
DECBs in exactly the same order as you did the READs.

See the section "Using Overlapped I/O with BSAM" in DFSMS Using Data Sets
(in Chapter 22 Accessing Records).

> Than when I finish processing that buffer and need to go to the second
> I/O I’ll issue a WAIT for that

Unless you are reading multple files (multiple DCBs) at once (each with
their own group of pending READs) issuing WAIT before CHECK is just
wasted effort/CPU time.

This is because you have to issue the CHECKs for each DCB in the order
you did the READs and they will complete in that order.

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

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

Re: z/TPF questions

[Radoslaw Skorupka]

W dniu 20.03.2021 o 09:47, Attila Fogarasi pisze:

Programs on ACP were limited to 4k size originally, and files were limited
to 2 record sizes (short and long), the sizes being optimized for 3211 disk
geometry.  Those limitations were removed 40 years ago :)  However the
speed of zTPF comes from not allowing applications to do things that
require expensive services, such as z/OS provides.


Excuse me, but what is 3211?
I suspect a typo, but I found nothing similar.
2311 is too old IMHO (1964).
Maybe 3330-11 ?


--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

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

Re: Overlapped I/O completion

[Seymour J Metz]

Basic EOV is transparent, but if you have the "unlike attributes" bit set, 
things happen that you must be aware of.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Michael Stein [m...@zlvfc.com]
Sent: Saturday, March 20, 2021 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Overlapped I/O completion

On Fri, Mar 19, 2021 at 08:08:28PM -0500, Paul Gilmartin wrote:
> On Fri, 19 Mar 2021 21:50:57 +, Seymour J Metz wrote:
>
> >> Is there any reason to do a WAIT before the CHECK?
> >EOV processing.

Normally a CHECK just waits on the ECB and does a minimal amount of
processing.

If there is some sort of error, end of file, or EOV case then
it can take longer.

EOV processing can involve an internal CLOSE/OPEN say for example the
next dataste in a concatenation.  This take much more time than just
checking an ECB for 7F (I/O complete normally).

If you had lots of work which was independent you could do other work
after the READ(s) and before any WAIT or CHECK.

Then after doing some other work, you could test the ECB in the DECB
to see if was done.  If it's done you could issue CHECK knowing that
it usually won't delay you.  And process that block and then issue
another READ.

If you ran out of work to do and none of your pending READs had completed
You could (for example) issue a WAIT with a list of ECBs which included
your pending READs along with other unrelated work which is pending.

When you wake you check the ECBs and do more processing related to
whatever got done...

By doing this you can get other processing done while the READs are
running.  You still need to issue CHECK for each READ but you avoid the
explicit WAIT inside of CHECK but not the error processing or EOV/EOF
processing.

> It was long ago and I no longer have the code.  IIRC, I coded a CHECK,
> but never a WAIT.  It was specialized code, and I may not have accounted
> for EOV.

EOV would be transparent, just a delay.

> What ill at EOV befalls a programmer who codes a CHECK but not a WAIT.

Nothing.


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

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

Re: CMS equivalent of ISPF SRCHFOR?

[Seymour J Metz]

SuperC is also included in ISPF. Of course, ISPF is not ubiquitous in the VM 
world the way that it is in the MVS world; if you don't have it, it's a lot 
less expensive to go the HLASM Toolkit route.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Attila Fogarasi [fogar...@gmail.com]
Sent: Saturday, March 20, 2021 4:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CMS equivalent of ISPF SRCHFOR?

I normally use SuperC which is sold as part of the HLASM Toolkit.  I don't
know if there is a free version.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Overlapped I/O completion

[Paul Gilmartin]

On Sun, 21 Mar 2021 10:08:13 -0500, Joel C. Ewing wrote:

>Believe it.  
>
Performance is unsatisfactory.

I must do something.

BSAM is something.

Therefore I must do BSAM.

-- gil

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

Re: Overlapped I/O completion

[Joe Monk]

"The queued access technique provides GET and PUT macro instructions for
transmitting data within virtual storage. These macro instructions cause
automatic blocking and deblocking of the records stored and retrieved.
Anticipatory (look-ahead) buffering and synchronization (overlap) of input
and output operations with central processing unit (CPU) processing are
automatic features of the queued access technique.

Because the operating system controls buffer processing, you can use as
many input/output (I/O) buffers as needed without reissuing GET or PUT
macro instructions to fill or empty buffers. Usually, more than one input
block is in storage at any given time, so I/O operations do not delay
record processing.

Because the operating system synchronizes input/output with processing, you
need not test for completion, errors, or exceptional conditions. After a
GET or PUT macro instruction is issued, control is not returned to your
program until an input area is filled or an output area is available. Exits
to error analysis (SYNAD) and end-oC-volume or end-of-data (EODAD) routines
are automatically taken when necessary.

The GET macro instruction obtains a record from an input data
set. It operates in a logical sequential and device-independent manner. As
required, the GET macro instruction schedules the filling of input buffers,
deblocks records, and directs input error recovery procedures. For
sequential data sets, it also merges record segments into logical records.
After all records have been processed and the GET macro instruction detects
an end-of-data indication, the system automatically checks labels on
sequenti'1l data sets and passes control to your end-of-data (EODAD)
routine. If an end-of-volume condition is detected for a sequential data
set, the system provides automatic volume switching if the data set extends
across several volumes or if concatenated da~a sets are being
processed. If you specify OPTCD=Q in the DCB, GET causes input data to be
translated from ASCII to EBCDIC."
http://www.bitsavers.org/pdf/ibm/370/OS_VS2/Release_3.8_1978/GC26-3875-0_OS_VS2_MVS_Data_Management_Services_Guide_Rel_3.8_Jun79.pdf

Joe

On Sun, Mar 21, 2021 at 12:16 PM Seymour J Metz  wrote:

> > When I do a qsam get the physical I/O is for 1 block every get just ups
> a pointer
>
> No. When you do a GET, QSAM not only returns a logical record, it also
> does whatever housekeeping is necessary. That includes scheduling the I/O
> for subsequent blocks if necessary. Further, the number of CCWs is not the
> same as the number of physical blocks. Further, the channel program may
> include CCWs for multiple physical blocks. The scheduling for QSAM is the
> same as the scheduling for BSAM. The advantage of QSAM is that it requires
> less programming, at the expense of not supporting FIND, NOTE, POINT or
> STOW.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Joseph Reichman [reichman...@gmail.com]
> Sent: Sunday, March 21, 2021 10:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Overlapped I/O completion
>
> I don’t understand what the statement “QSAM does overlapped I/O
> automatically”
>
> When I do a qsam get the physical I/O is for 1 block every get just ups a
> pointer
>
> BSAM allows me to do multiple Reads each with their own DECB
>
> So I already initiate lots of physical I/O mainly because I have lots of
> records or blocks
>
> I find it hard to believe that a qsam get does anything more than read 1
> block
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Overlapped I/O completion

[Seymour J Metz]

> When I do a qsam get the physical I/O is for 1 block every get just ups a 
> pointer

No. When you do a GET, QSAM not only returns a logical record, it also does 
whatever housekeeping is necessary. That includes scheduling the I/O for 
subsequent blocks if necessary. Further, the number of CCWs is not the same as 
the number of physical blocks. Further, the channel program may include CCWs 
for multiple physical blocks. The scheduling for QSAM is the same as the 
scheduling for BSAM. The advantage of QSAM is that it requires less 
programming, at the expense of not supporting FIND, NOTE, POINT or STOW.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Joseph Reichman [reichman...@gmail.com]
Sent: Sunday, March 21, 2021 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Overlapped I/O completion

I don’t understand what the statement “QSAM does overlapped I/O automatically”

When I do a qsam get the physical I/O is for 1 block every get just ups a 
pointer

BSAM allows me to do multiple Reads each with their own DECB

So I already initiate lots of physical I/O mainly because I have lots of 
records or blocks

I find it hard to believe that a qsam get does anything more than read 1 block
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Overlapped I/O completion

[Seymour J Metz]

For GET it's BUFNO, for READ it's NCP.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Joseph Reichman [reichman...@gmail.com]
Sent: Sunday, March 21, 2021 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Overlapped I/O completion

Thank you does the number “GET” ahead I/o depend on Buffno
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Overlapped I/O completion

[Seymour J Metz]

OPTCD=C chained scheduling goes all the way back to OS/360, and was not limited 
to DASD. Starting with SAM-E, a more efficient type of chained scheduling was 
automatic for DASD. BSAM and QSAM chain new requests to the current channel 
program and reschedule them if channel program terminates too soon. There was 
documentation, e.g., MVS/Extended Architecture SAM Logic Data Facility Product 
5665-XA2 Version 2  Release 1.0, LY26-3967-0,  
http://bitsavers.org/pdf/ibm/370/MVS_XA/DFP_Version_2/LY26-3967-0_MVS_XA_DFP_Version_2_Release_1.0_SAM_Logic_Apr1985.pdf,
 but I'm not aware of any current documentation.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Joel C. Ewing [jce.ebe...@cox.net]
Sent: Sunday, March 21, 2021 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Overlapped I/O completion

Believe it.

Even before emulated DASD,  MVS QSAM would read multiple blocks with a
single channel program to eliminate rotational delays on native DASD and
do anticipatory reads for the next set of buffers even while you were
still processing records in blocks from the previous read, as long as
you specified enough buffers.  You could prove this with native
3380/3390 by measuring real execution time and increasing the number of
buffers.  Once physical and virtual memory space were not a limiting
factor, the recommendation was to specify enough buffers to at least do
full-track reads as a minimum for all sequential files.  Not sure what
the upper bound was -- probably the max number of blocks per physical
read was 1 cylinder, but could have been less.  The real time effects
were incredibly dramatic if you found an application with smaller block
size and an inadequate buffer specification and fixed the JCL.

Pretty sure with emulated DASD that QSAM is smart enough to communicate
to the DASD subsystem that it is doing pure sequential access and needs
to pre-stage data into cache in the DASD subsystem.   Since BSAM doesn't
have to be purely sequential, it may not be as good at communicating
future intent to the DASD Subsystem.   Obviously with emulated DASD, the
z/OS concepts of device track and cylinder boundaries don't really
apply, but the DASD subsystem can see the sequential access intent and
translate that into whatever access maximizes data transfer on its
internal physical disks.

So yes, I would expect properly tuned QSAM I/O to out perform even an
incredibly well designed overlapped BSAM I/O access strategy on pure
sequential access, and with much less work.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: This Call-Assembler-inside-COBOL technique works, but is it risky to use?

[Seymour J Metz]

The code will be hard to maintain. It would be more maintainable to write a 
well commented subroutine in assembler. If you don't have the staff to 
understand and update that, then you also don't have the staff to understand 
the embedded machine code.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, March 17, 2021 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: This Call-Assembler-inside-COBOL technique works, but is it risky to 
use?

I discovered that one can code and call extremely simple assembler code from 
completely within a COBOL source program, but it is a two-step process which I 
will describe below.

My question is whether using a technique like this is "risky" in the sense that 
it may someday, under a future incarnation of the compiler, stop working?

The technique:

Code a simple assembler program like the following and browse the resulting 
listing that shows the generated object code:

COBSTCKE CSECT ,
 L 15,0(,1)  GET ARGUMENT ADDRESS
 STCKE 0(15) STCKE INTO ARGUMENT AREA
 XR15,15 SET RETURN CODE = 0
 BR14RETURN TO CALLER

Then copy the generated object code into a COBOL source program as follows:

   ID DIVISION.
   PROGRAM-ID. COBSTCKE.
   ENVIRONMENT DIVISION.
   DATA DIVISION.
   WORKING-STORAGE SECTION.
   01  WS-TOD-VALUE  PIC  X(16).

   01  WS-GETTOD-PROGRAM.
  * GET ARGUMENT ADDRESS L  15,0(,1)
   05  FILLER   PIC  X(04) VALUE X'58F01000'.
  * STCKE INTO ARGUMENT AREA STCKE 0(15)
   05  FILLER   PIC  X(04) VALUE X'B278F000'.
  * SET RETURN-CODE = 0  XR 15,15
   05  FILLER   PIC  X(02) VALUE X'17FF'.
  * RETURN TO CALLER BR 14
   05  FILLER   PIC  X(02) VALUE X'07FE'.

   01  WS-GETTOD-PTR.
   05  GETTOD-ADDRPROCEDURE-POINTER VALUE NULL.
   05  FILLER REDEFINES GETTOD-ADDR.
   10  GETTOD-ADDR1   POINTER.
   10  GETTOD-ADDR2   POINTER.

   PROCEDURE DIVISION.

   SET GETTOD-ADDR1 TO ADDRESS OF WS-GETTOD-PROGRAM.
   CALL GETTOD-ADDR USING WS-TOD-VALUE.
   DISPLAY FUNCTION HEX-OF (WS-TOD-VALUE).
   GOBACK.

Peter

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

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

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

Re: Epoch Index

[Paul Gilmartin]

On 2021-03-21, at 07:52:27, Peter Relson wrote:
> 
> The software will not have to do anything in order to get the epoch index 
> to increase to 1 in September 2042. ...
>  
Thanks.  I saw that cleearly in the PoOps.

> The clock comparator remains an 8 byte entity. But the OS will be able to 
> indicate that the CC is to be treated as signed, so that _ 
> will be "later" than (the negative) _. That exploitation 
> of the multiple epoch facility does require OS action. And probably 
> requires a converse action every 70 years or so when the high bit of the 
> TOD clock changes.
>  
I had envisioned a ±70-year window implemented by continually performing
a Subtract Logical TOD - Comparator and testing the sign.  The behavior
would be more continuous, not requiring "action every 70 years or so".

Any implementation is likely to have hazards when:

o A programmer sets comparator to 0 to indicate "immediately".

o A programmer sets comparator to maximum to indicate "never".

o An expiry time is set very near maximum and the CPU is not
  dispatchable at that time.

There is a legend (reported here a few years ago?) of a program
that used a value of decimal one billion to indicate "never"
and looped when that time occurred.

Thanks again,
gil

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

Re: Any z/OS sandbox available for a university student I know?

[Seymour J Metz]

Linux and Unix happily coexist in mainframes. Big chunks of z/OS use Unix 
System Services, there's lots of Linux use in IFL and z/VM, and it is common to 
have Linux communicating with z/OS.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mike Wawiorko [014ab5cdfb21-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, March 17, 2021 1:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any z/OS sandbox available for a university student I know?

Same stories go round every 10 years or so.

In mid-1980s Unix was going to wipe out mainframes within 5-10 years.

Now Linux threatens Unix...
and for large shops mainframe thrives.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CMS equivalent of ISPF SRCHFOR?

[Jim Elliott]

Binyamin,

Not a command, but a full screen utility. Check out my FERRET package at 
http://www.vm.ibm.com/download/packages/descript.cgi?FERRET

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

Re: Overlapped I/O completion

[Ed Jaffe]

On 3/21/2021 7:21 AM, Joseph Reichman wrote:

I don’t understand what the statement “QSAM does overlapped I/O automatically”

When I do a qsam get the physical I/O is for 1 block every get just ups a 
pointer


QSAM does overlapped I/O (and has done for many, Many, MANY years).

If you want to see for yourself, set up a GTF I/O trace. You'll see I/O 
right away at OPEN time even before you issue your first GET.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Overlapped I/O completion

[Tom Harper]

Yes. Default varies by type of device. 

Sent from my iPhone

> On Mar 21, 2021, at 11:08 AM, Joel C. Ewing  wrote:
> 
> Believe it.  
> 
> Even before emulated DASD,  MVS QSAM would read multiple blocks with a
> single channel program to eliminate rotational delays on native DASD and
> do anticipatory reads for the next set of buffers even while you were
> still processing records in blocks from the previous read, as long as
> you specified enough buffers.  You could prove this with native
> 3380/3390 by measuring real execution time and increasing the number of
> buffers.  Once physical and virtual memory space were not a limiting
> factor, the recommendation was to specify enough buffers to at least do
> full-track reads as a minimum for all sequential files.  Not sure what
> the upper bound was -- probably the max number of blocks per physical
> read was 1 cylinder, but could have been less.  The real time effects
> were incredibly dramatic if you found an application with smaller block
> size and an inadequate buffer specification and fixed the JCL.
> 
> Pretty sure with emulated DASD that QSAM is smart enough to communicate
> to the DASD subsystem that it is doing pure sequential access and needs
> to pre-stage data into cache in the DASD subsystem.   Since BSAM doesn't
> have to be purely sequential, it may not be as good at communicating
> future intent to the DASD Subsystem.   Obviously with emulated DASD, the
> z/OS concepts of device track and cylinder boundaries don't really
> apply, but the DASD subsystem can see the sequential access intent and
> translate that into whatever access maximizes data transfer on its
> internal physical disks.
> 
> So yes, I would expect properly tuned QSAM I/O to out perform even an
> incredibly well designed overlapped BSAM I/O access strategy on pure
> sequential access, and with much less work.
> Joel C Ewing
> 
>> On 3/21/21 9:21 AM, Joseph Reichman wrote:
>> I don’t understand what the statement “QSAM does overlapped I/O 
>> automatically”
>> 
>> When I do a qsam get the physical I/O is for 1 block every get just ups a 
>> pointer 
>> 
>> BSAM allows me to do multiple Reads each with their own DECB
>> 
>> So I already initiate lots of physical I/O mainly because I have lots of 
>> records or blocks 
>> 
>> I find it hard to believe that a qsam get does anything more than read 1 
>> block 
>> 
>> Thanks 
>> 
>>> On Mar 20, 2021, at 2:49 PM, Binyamin Dissen  
>>> wrote:
>>> 
>>> On Fri, 19 Mar 2021 14:09:59 -0400 Joseph Reichman 
>>> wrote:
>>> 
>>> :>When doing overlapped I/O is there a way to tell if the I/O had completed 
>>> on the subsequent reads 
>>> 
>>> :>I check to see if the first fullword has been populated by the BDW
>>> 
>>> Did you try without overlapping I/O?
>>> 
>>> Post the code.
>>> 
>>> --
>>> Binyamin Dissen 
>>> http://www.dissensoftware.com
>>> 
>>> Director, Dissen Software, Bar & Grill - Israel
>>> 
> ...
> 
> -- 
> Joel C. Ewing
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Overlapped I/O completion

[Joel C. Ewing]

Believe it.  

Even before emulated DASD,  MVS QSAM would read multiple blocks with a
single channel program to eliminate rotational delays on native DASD and
do anticipatory reads for the next set of buffers even while you were
still processing records in blocks from the previous read, as long as
you specified enough buffers.  You could prove this with native
3380/3390 by measuring real execution time and increasing the number of
buffers.  Once physical and virtual memory space were not a limiting
factor, the recommendation was to specify enough buffers to at least do
full-track reads as a minimum for all sequential files.  Not sure what
the upper bound was -- probably the max number of blocks per physical
read was 1 cylinder, but could have been less.  The real time effects
were incredibly dramatic if you found an application with smaller block
size and an inadequate buffer specification and fixed the JCL.

Pretty sure with emulated DASD that QSAM is smart enough to communicate
to the DASD subsystem that it is doing pure sequential access and needs
to pre-stage data into cache in the DASD subsystem.   Since BSAM doesn't
have to be purely sequential, it may not be as good at communicating
future intent to the DASD Subsystem.   Obviously with emulated DASD, the
z/OS concepts of device track and cylinder boundaries don't really
apply, but the DASD subsystem can see the sequential access intent and
translate that into whatever access maximizes data transfer on its
internal physical disks.

So yes, I would expect properly tuned QSAM I/O to out perform even an
incredibly well designed overlapped BSAM I/O access strategy on pure
sequential access, and with much less work.
    Joel C Ewing

On 3/21/21 9:21 AM, Joseph Reichman wrote:
> I don’t understand what the statement “QSAM does overlapped I/O automatically”
>
> When I do a qsam get the physical I/O is for 1 block every get just ups a 
> pointer 
>
> BSAM allows me to do multiple Reads each with their own DECB
>
> So I already initiate lots of physical I/O mainly because I have lots of 
> records or blocks 
>
> I find it hard to believe that a qsam get does anything more than read 1 
> block 
>
> Thanks 
>
>> On Mar 20, 2021, at 2:49 PM, Binyamin Dissen  
>> wrote:
>>
>> On Fri, 19 Mar 2021 14:09:59 -0400 Joseph Reichman 
>> wrote:
>>
>> :>When doing overlapped I/O is there a way to tell if the I/O had completed 
>> on the subsequent reads 
>>
>> :>I check to see if the first fullword has been populated by the BDW
>>
>> Did you try without overlapping I/O?
>>
>> Post the code.
>>
>> --
>> Binyamin Dissen 
>> http://www.dissensoftware.com
>>
>> Director, Dissen Software, Bar & Grill - Israel
>>
...

-- 
Joel C. Ewing

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

Re: Overlapped I/O completion

[Joseph Reichman]

Thank you does the number “GET” ahead I/o depend on Buffno


> On Mar 20, 2021, at 11:31 AM, Michael Stein  wrote:
> 
> On Fri, Mar 19, 2021 at 03:35:39PM -0400, Joseph Reichman wrote:
>> So this is what I will do 
>> 
>> I’ll do 3 reads in the first since i need to get myself going I’ll issue the 
>> WAIT using the ECB from the DECB 
> 
> Limiting the pending reads to 3 will limit the performance to worse 
> (or at least no better) than QSAM.  
> 
> You did set NCP to a value at least high enough for the number of
> pending READs you would have at any time, right?
> 
> Also keep in mind that you need to issue the wait/check on the
> DECBs in exactly the same order as you did the READs.
> 
> See the section "Using Overlapped I/O with BSAM" in DFSMS Using Data Sets
> (in Chapter 22 Accessing Records).
> 
>> Than when I finish processing that buffer and need to go to the second
>> I/O I’ll issue a WAIT for that
> 
> Unless you are reading multple files (multiple DCBs) at once (each with
> their own group of pending READs) issuing WAIT before CHECK is just
> wasted effort/CPU time.
> 
> This is because you have to issue the CHECKs for each DCB in the order
> you did the READs and they will complete in that order.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Overlapped I/O completion

[Tom Harper]

From Jim Mulder:



Jim Mulder
2/4/17
to 
There are no coding requirements for the application, When you do 
a QSAM OPEN for Input, the first read-ahead I/Os are scheduled by OPEN, 
and the application program can proceed without waiting after the OPEN at 

least to the point of doing the first GET. Subsequent read-ahead I/Os can 

overlap with the application program processing. 
Sent from my iPhone

> On Mar 21, 2021, at 10:21 AM, Joseph Reichman  wrote:
> 
> I don’t understand what the statement “QSAM does overlapped I/O automatically”
> 
> When I do a qsam get the physical I/O is for 1 block every get just ups a 
> pointer 
> 
> BSAM allows me to do multiple Reads each with their own DECB
> 
> So I already initiate lots of physical I/O mainly because I have lots of 
> records or blocks 
> 
> I find it hard to believe that a qsam get does anything more than read 1 
> block 
> 
> Thanks 
> 
>> On Mar 20, 2021, at 2:49 PM, Binyamin Dissen  
>> wrote:
>> 
>> On Fri, 19 Mar 2021 14:09:59 -0400 Joseph Reichman 
>> wrote:
>> 
>> :>When doing overlapped I/O is there a way to tell if the I/O had completed 
>> on the subsequent reads 
>> 
>> :>I check to see if the first fullword has been populated by the BDW
>> 
>> Did you try without overlapping I/O?
>> 
>> Post the code.
>> 
>> --
>> Binyamin Dissen 
>> http://www.dissensoftware.com
>> 
>> Director, Dissen Software, Bar & Grill - Israel
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.


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

Re: Overlapped I/O completion

[Joseph Reichman]

I don’t understand what the statement “QSAM does overlapped I/O automatically”

When I do a qsam get the physical I/O is for 1 block every get just ups a 
pointer 

BSAM allows me to do multiple Reads each with their own DECB

So I already initiate lots of physical I/O mainly because I have lots of 
records or blocks 

I find it hard to believe that a qsam get does anything more than read 1 block 

Thanks 

> On Mar 20, 2021, at 2:49 PM, Binyamin Dissen  
> wrote:
> 
> On Fri, 19 Mar 2021 14:09:59 -0400 Joseph Reichman 
> wrote:
> 
> :>When doing overlapped I/O is there a way to tell if the I/O had completed 
> on the subsequent reads 
> 
> :>I check to see if the first fullword has been populated by the BDW
> 
> Did you try without overlapping I/O?
> 
> Post the code.
> 
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
> 
> Director, Dissen Software, Bar & Grill - Israel
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Epoch Index

[Peter Relson]

The software will not have to do anything in order to get the epoch index 
to increase to 1 in September 2042. It will happen when the clock wraps, 
as long as you're running on a machine that supports the multiple epoch 
facility (maybe the OS has to enable something, but that would be about 
it). Of course a lot of OS changes need to be in place when that does 
occur.

The clock comparator remains an 8 byte entity. But the OS will be able to 
indicate that the CC is to be treated as signed, so that _ 
will be "later" than (the negative) _. That exploitation 
of the multiple epoch facility does require OS action. And probably 
requires a converse action every 70 years or so when the high bit of the 
TOD clock changes.

In the future, one would expect a z/OS release to document that it is OK 
to set the clock so that it can cross the 2042 epoch end (or be later than 
the epoch end), and similarly the 2038 time related to the z/OS Unix clock 
wrap point. Until such a time, do not do that.

There will be no expectation initially that you can work with times beyond 
the 2nd epoch. There is likely no expectation of results if a system stays 
up for over 70 years. And it will be the case that you are expected not to 
have data that is over 140-ish years old when you need to work with an 
8-byte timestamp (many cases will use a windowing approach, not using a 
16-byte timestamp).

Peter Relson
z/OS Core Technology Design


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

Re: Contents of TOD Programmable Field under z/OS?

[Peter Relson]

The STCKE result, like the STCK result, is architecturally guaranteed to 
be unique across all the CPUs used by an operating system image (i.e., 
within an LPAR). This is not a sysplex statement; sysplex is not an 
architectural construct. The STCKF result, on the other hand, is not 
guaranteed unique; using STCKF is better for cases where you do not need 
that uniqueness. The STCK instruction might have to spin in some cases 
where the same CPU issues consecutive STCK's very close together. STCKE 
theoretically might have to do so too but in practice I think does not, 
due to the significantly greater granularity.

Peter Relson
z/OS Core Technology Design


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

Re: z/TPF questions

[Radoslaw Skorupka]

Charles,
I know Tom Brennan's Vista. I even got one from him. For free. (I didn't 
ask for it! It was a part of longer story, related to polish codepage). 
And I have no doubt he knows there are both 3270 and 5250.


However lurking or peeking is not the best method, especially you 
sometimes see that only awhile, from distance.

It has nothing to do with my or Tom's knowledge.

BTW: My wife was really upset when she heard what I found in a store, 
instead of jacket...


Regards
--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland




W dniu 21.03.2021 o 00:40, Charles Mills pisze:

My wild guess is that Tom Brennan knows a TN3270 client when he sees one.

@Tom: Was it yours?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Radoslaw Skorupka
Sent: Saturday, March 20, 2021 3:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/TPF questions

W dniu 20.03.2021 o 17:42, Tom Brennan pisze:

On 3/20/2021 7:09 AM, Radoslaw Skorupka wrote:


To be honest, out of curiosity I always peek the systems in use when
I'm served as customer.

Me too!  When I first started going to Kaiser the doctors had
Attachmate running with a long row of PF key buttons across the bottom
of the screen.  Years ago they switched to a GUI system. But... in
Southern California there's a beer/wine/liquor store called BevMo and
when I recently asked about a particular bottle, I looked over and the
guy was typing on a TN3270 screen.  I guess if something works, why
change it?

Curious: are you sure it is 3270, not 5250? AS/400 family is quite
popular in retail.
I had many false detections.
BTW: Our blood donation system use AS/400 system. Several years ago they
used real (hard) terminals. Now it is PCOMM. However doctor told me
there are plans to replace it with new shining gui&mobile system. As far
as I know they saw some prototype and they are very unhappy about the
change. Current system is simple and even new personnel have no problem
with that.  The new one will be modern, with all possible
modern features - malware, ransomware, data lost, logic errors,
administrative interface for PFCSKs connected via Internet...



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