Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Seymour J Metz]

ObTRUNCEvery time someone says "I don't believe in theories", another theory 
dies.




-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Joel C. Ewing 
Sent: Saturday, November 11, 2023 11:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

On 11/11/23 21:03, Ed Jaffe wrote:
> On 11/11/2023 6:40 PM, Paul Gilmartin wrote:
>> On Sun, 12 Nov 2023 02:16:07 +, Seymour J Metz wrote:
>>
>>> Solves what problem? Unix doesn't have records, so you have to
>>> impose your own record structure and tell seek the byte offset.
>>>
>> He said FB.  That makes the calc simple.
>
> FB allows short blocks. FBS would be needed to do true skip-sequential.

But of course short blocks, other than the last block, will not be
present with RECFM=FB sequential datasets that are created by the usual
means with a single OPEN-CLOSE sequence -- internal short blocks only
happen when the dataset is created as multiple segments with subsequent
OPENs appending to existing records by opening the dataset with
DISP=MOD, as each CLOSE has the potential to create a short block.   So
in those contexts where you know from the way the dataset was created
that the "allowed" embedded short blocks cannot actually be present,
RECFM=FB works also.  If you wanted to verify whether a specific
FB-created dataset contained internal short blocks, i believe you could
run any utility that would read the entire dataset using JCL to override
the dataset RECFM with RECFM=FBS, and you should get some error
indication like IEB174I if internal short blocks are found.

 JC Ewing


--
Joel C. Ewing

--
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: Kinda fun

[g...@gabegold.com]

I'm pretty sure this happened with VM, though might have been with OS/360 and 
HASP.

User brought odd printout (1403 or 3211) to system programming, asked what 
happened. It showed two output streams overprinted -- like a double exposed 
photo. Clearly impossible, but there it was.

Research eventually revealed that someone had violated best practices and 
allowed a user into computer room. She had output, dropped it in a recycle box.

Except it wasn't recycle, was next box of paper to be used. So operator fed it 
through printer without noticing it had been used.

It was printed on again as part of someone else's output, which they received.

Go figure, offender was already a user not popular with either operators or 
system programmers so this was just another strike on the scorecard.

On Fri, 10 Nov 2023 23:12:23 -0800, Leonard D Woren  
wrote:

>Bob Bridges wrote on 11/8/2023 6:56 AM:
>> Reminds me of an old tagline:
>>
>> /* The more sophisticated the technology, the more vulnerable it is to 
>> primitive attack. People often overlook the obvious.  -Dr Who, 1978 */
>
>Long ago I was told why my shop didn't carpet the tape storage area.  
>Apparently some shop that did had a problem with unreadable tapes.  
>Eventually they figured out that all the unreadable tapes were on the 
>bottom row of the tape storage.  And the outside cleaning people used 
>a vacuum cleaner...
>
>
>Farley, Peter wrote on 11/8/2023 7:58 AM:
>> 1401N1 printer (the big beast) raised its hood automatically when it ran out 
>> of paper, no way to turn off that behavior.  NEVER put your coffee cup on 
>> top of that printer!!
>
>Supposedly the reason that IBM put that feature on the 1403 was some 
>big shops had a lot of 1403s and it helped the operator find the 
>printer that needed to be fed.  Unfortunately, the feature didn't have 
>a failsafe.  It was common to stack boxes of paper behind the 
>printer.  At least once at UCLA, someone had stacked it one box too 
>high, and when the printer cover went up, the back end of the cover 
>was blocked by the too-high stack, raising the printer off the floor.
>
>And BTW, the 3211 had a "raise cover" CCW.  I had some fun with that, 
>and one of the other IBM-MAIN readers probably remembers that, from 
>Post 360.

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Joel C. Ewing]

On 11/11/23 21:03, Ed Jaffe wrote:

On 11/11/2023 6:40 PM, Paul Gilmartin wrote:

On Sun, 12 Nov 2023 02:16:07 +, Seymour J Metz wrote:

Solves what problem? Unix doesn't have records, so you have to 
impose your own record structure and tell seek the byte offset.



He said FB.  That makes the calc simple.


FB allows short blocks. FBS would be needed to do true skip-sequential.


But of course short blocks, other than the last block, will not be 
present with RECFM=FB sequential datasets that are created by the usual 
means with a single OPEN-CLOSE sequence -- internal short blocks only 
happen when the dataset is created as multiple segments with subsequent 
OPENs appending to existing records by opening the dataset with 
DISP=MOD, as each CLOSE has the potential to create a short block.   So 
in those contexts where you know from the way the dataset was created 
that the "allowed" embedded short blocks cannot actually be present, 
RECFM=FB works also.  If you wanted to verify whether a specific 
FB-created dataset contained internal short blocks, i believe you could 
run any utility that would read the entire dataset using JCL to override 
the dataset RECFM with RECFM=FBS, and you should get some error 
indication like IEB174I if internal short blocks are found.


    JC Ewing


--
Joel C. Ewing

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

UNIX "BLKSIZE"?

[Paul Gilmartin]

Suppose I am writing with QSAM/BSAM to a UNIX file allocated
RECFM=FB,LRECL=80,FILEDATA=BINARY,PATH=...
Should I specify:
o BLKSIZE=80 for minimum latency for other jobs doing "tail -f"?
o BLKSIZE=32720 for fewest costly access method calls?
o BLKSIZE=0 and trust SDB (which will probably use 1/2 3390)?

-- 
gil

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Paul Gilmartin]

On Sat, 11 Nov 2023 19:03:01 -0800, Ed Jaffe wrote:

>On 11/11/2023 6:40 PM, Paul Gilmartin wrote:
>> On Sun, 12 Nov 2023 02:16:07 +, Seymour J Metz wrote:
>>
>>> Solves what problem? Unix doesn't have records, so you have to impose your 
>>> own record structure and tell seek the byte offset.
>>>
>> He said FB.  That makes the calc simple.
>
>FB allows short blocks. FBS would be needed to do true skip-sequential.
>
He said "Unix".  In UNIX there are no short blocks, even if the file has been
appended repeatedly.

(I was focusing on the "F", not the "B".  QSAM/BSAM write to a UNIX file
loses the block boundaries.)

-- 
gil

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Ed Jaffe]

On 11/11/2023 6:40 PM, Paul Gilmartin wrote:

On Sun, 12 Nov 2023 02:16:07 +, Seymour J Metz wrote:


Solves what problem? Unix doesn't have records, so you have to impose your own 
record structure and tell seek the byte offset.


He said FB.  That makes the calc simple.


FB allows short blocks. FBS would be needed to do true skip-sequential.

--
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: IBM APAR Names

[Ed Jaffe]

On 11/7/2023 3:52 AM, Radoslaw Skorupka wrote:

W dniu 06.11.2023 o 16:20, Ed Jaffe pisze:

On 11/5/2023 4:03 PM, Shaffer, Terri wrote:
So I am trying to apply maintenance and want to know the actual APAR 
to look up to see if its open closed, or what?


Slide 72 in SHARE New Orleans Bit Bucket X'42' explains the APAR and 
++APAR naming convention used most often with z/OS products and 
components.


The possible APAR prefixes are: OA, PH, PI, PK, PL, PM, PN, IO, PP, 
PQ, IR, OW, OY and OZ. The second letter of the ++APAR is the mapping.




What does it mean "mapping" ?


It means the second letter of the ++APAR tells you which of the above 
prefixes the APAR uses. For example:


1. If your ++APAR is AH23456, then the APAR number is PH23456.

2. If your ++APAR is AR34567, then the APAR number is IR34567.

--
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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Paul Gilmartin]

On Sun, 12 Nov 2023 02:16:07 +, Seymour J Metz wrote:

>Solves what problem? Unix doesn't have records, so you have to impose your own 
>record structure and tell seek the byte offset.
> 
He said FB.  That makes the calc simple.

>On 11/11/23 06:59:07, David S. wrote:
>> To help resolve a question posted to a LinkedIn group I manage:
>> http://www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
>> ... I'd like to find out if there's any way to achieve *true*
>> Skip-Sequential processing with a Fixed Block Sequential File with a fairly
>> short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?

-- 
gil

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

unable to access IPCS 64 bit storage using Storage map service

[Joseph Reichman]

A while I posted about accessing ipcs storage above the bar 64 bit as with
storage access I could only get 31 bit 

I got a number of responses but I decided to use the post By Adam Johanson
using storage map services below is my code 
I get a rc zero in r15 however storage area address XMSPBUFF contains all
zeros 

In IPCS I did a list subcommand from the value of double word value in
TSTAUVCT and it had the values I was expecting however using storage map
services I get zeros in the area pointed to by  XMSPBUF

*   
  LAR7,WORKMAP   
  USING MAP,R7   
  LAR10,WRKMPL   
  USING XMSP,R10 
  MVC   MAPRID,=C'SA'
  MVC   XMSPMODN,=C'TSTAIPCS'
  STR7,XMSPSAR   
  MVC   XMSPCODE,=Y(XMSPACC) 
  MVC   XMSPIDC,=C'XMSP' 
  MVI   XMSPIDL,C'1' 
  MVC   MAPAST,VIRTUAL#STORAGE Virtual storage address space 
  MVC   MAPAS2+2(2),ASID#
 *MVC   MAPDTD(30),=31C' '   
 *MVI   MAPDTE,C' '  
  MVC   MAPAS1,=F'-1'
  MVC   MAPLAD,TSTAUVCT  
  MVI   MAPDTY,ZZZDTYU   
  MVC   MAPFLE,=A(100)   
  OIXMSPPFL1,XMSPV64 
  LAR0,1000  
  STORAGE OBTAIN,LENGTH=(0),ADDR=(R5),SP=0   
  STR5,XMSPBUF   
  L 15,ADPLSERV  
 CALL  (15),((R8),MAP#SERVICE,(R10)),MF=(E,CALLLST)


*
PPR2 BLSUPPR2 DSECT=NO  IPCS expanded print parm list
XMSP BLSRXMSP DSECT=YES  
XMSPLEN EQU   *-XMSP 
MAP  BLSRSASY DSECT=YES,ABITS=64 


WORKAREA DSECT 
 DSXL144   
*EGSAVE  DSXL144   
WORKPACC DS 0D,CL(ADPLLACC)
WORKPPR2 DS 0D,CL(PPR2999-PPR2000) 
WORKESSY DS 0D,CL(ESSYHRL) 
WORKMAP  DS 0D,CL(MAPHRL)  
WRKMPL   DS 0D,CL(XMSPLEN) 
SNAMHXSV DS CL8
SNAMSAVE DS CL8
SNAMHXLN DS F  
CALLLST CALL ,(,,),MF=L


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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Seymour J Metz]

Solves what problem? Unix doesn't have records, so you have to impose your own 
record structure and tell seek the byte offset.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, November 11, 2023 5:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

On 11/11/23 06:59:07, David S. wrote:
> To help resolve a question posted to a LinkedIn group I manage:
> http://www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
> ... I'd like to find out if there's any way to achieve *true*
> Skip-Sequential processing with a Fixed Block Sequential File with a fairly
> short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
> For example: Begin sequential processing at record number 100, *without*
> having to read the first 99 records.
>
>
This feels like a job for DSFS.


UNIX readily solves the problem with seek() and DSFS is supposed
to mimic a UNIX file with the content of a Classic data set.

Where's the User's Guide for DSFS?

Is the skip count fixed, or is it dynamic, varying up or down
with successive executions of your program?

--
gil

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

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Paul Gilmartin]

On Sat, 11 Nov 2023 18:43:18 -0600, Michael Oujesky wrote:

>Does seek() actually do a direct access?  Or read, but skip the
>records from the start of the file?
> 


It doesn't say it reads.  IBM's documentation policy is to document what they do
and not do what they don't say they do.

Dies POINT "read, but skip the records from the start of the file?"  Does the
Services Ref contain an affirmative denial?

-- 
gil

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

Re: PC Interference from shredder Was: Kinda fun

[Mike Schwab]

Maybe if they covered the walls too?
https://www.amazon.com/Reducing-Wallpaper-Faraday-Copper-Radiation-Shielding/dp/B09BW3CYQB

On Sat, Nov 11, 2023 at 7:51 PM Steve Thompson  wrote:

> Many years ago at Hagerstown MD, they had a computer (I think it
> was an NCR3 or 3000, it's just been too long ago) that at odd
> points would just fail. My father was an RF tech working on
> radios, and had a contract for the Police Department... so I will
> make this short. It turns out that a few stories below this
> computer room was the door out of the garage where the police
> cars were parked. And so upon exiting the parking garage and
> entering the alley to the street, officers would key their mics
> to verify their radio was working and that would cause the
> computer system to lock up (machine check?).
>
> This was discovered by an NCR CE that had an Oscilloscope doing
> tracing trying to find what was causing this problem and just
> happened to be standing at the window looking down when a police
> car came out and the machine froze.  the police mobile radios
> were a harmonic of the system clock!! And were 100 Watts IRC.
>
> A sign was put at the exit of the garage informing anyone who
> keyed their mic for their radio before getting out of the alley,
> upon being discovered who they were, their pay check would be the
> last one to be passed out at the end of the month. This problem
> had been invariably happening during payroll runs and they had to
> be restarted from the beginning.
>
> Problem stopped.
>
> Steve Thompson
>
> Oh, and the windows did have a metal grid over them in an attempt
> to prevent things like this.
>
> On 11/11/2023 5:07 PM, Tom Brennan wrote:
> > Just before I worked with mainframes I drew maps on a computer
> > that had a big display, a small drawing pad and pen, and a
> > large light table with a "puck" for tracing existing maps into
> > the computer. Both the puck and pen worked by receiving a
> > magnetic signal from the pad or table in order to determine its
> > location.  About once a week someone would complain that their
> > pen was throwing the cursor all over the screen, so a new pen
> > was ordered at maybe $500.
> >
> > The light table had bunch of fluorescent bulbs inside, and you
> > could dim them with a knob if needed.  One day I noticed that
> > when the light was either full on or full off, there was no
> > problem with my pen.  But if the dimmer was in the middle, the
> > pen had issues.  Those dimmers used triacs which work by
> > holding back each AC wave a bit and then sharply rising.  The
> > sharp rise generates all sorts of EMF and that's what was
> > messing with the coil in the pen.
> >
> > On 11/11/2023 12:55 PM, Wayne Bickerdike wrote:
> >> On the subject of RF interference. Years ago we came back from
> >> living in
> >> California to Australia. We had a 110V coffee espresso
> >> machine. It worked
> >> well and we ran it from a voltage changer plugged into the
> >> socket. Early
> >> rise time, my wife would go into the kitchen and make a coffee.
> >>
> >> I'm in the habit of reading my email and surfing at that time
> >> (like now in
> >> Australia).
> >>
> >> For weeks and months my internet would go off and come back a few
> >> minutes later. I eventually tied it back to the coffee
> >> machine/voltage
> >> reducer. We stopped using it and all good. The wireless router
> >> runs on
> >> 2.4Ghz and is located in my study, maybe 30 feet from the
> >> kitchen and there
> >> is a double brick wall in the way.
> >>
> >> As an adjunct to this. I switch off my router at midnight and
> >> I get much
> >> better sleep.
> >>
> >> On Sun, Nov 12, 2023 at 6:11 AM Joel C. Ewing
> >>  wrote:
> >>
> >>> I think shielding of the PC itself is unlikely the problem,
> >>> unless the
> >>> case is not properly closed.  All PCs I have ever seen have
> >>> metal cases,
> >>> which if properly seated and grounded act as a RF shield,
> >>> inbound and
> >>> outbound.
> >>>
> >>> Any electric motor could be producing power transients at
> >>> power on/off
> >>> and possible RF interference from contact arcing (which can
> >>> increase
> >>> with motor age), which might travel over the house wiring, or
> >>> via air
> >>> and get picked up by other cables in the room which are
> >>> connected to the
> >>> PC.  Any magnetic effects of a motor should be minor by
> >>> comparison.
> >>>
> >>> If it's a large enough motor, start up may produce a
> >>> temporary dip in
> >>> voltage big enough to be a problem for a computer that is not
> >>> powered
> >>> through an Uninterruptible Power Supply (UPS).  If you notice
> >>> any lights
> >>> flicker when the shredder powers up, that definitely could be
> >>> an issue.
> >>> If you are not already using a UPS for your PC, you probably
> >>> should be,
> >>> for other reasons as well. The shredder definitely should not
> >>> be plugged
> >>> into the same outlet as your computer, and it would be best
> >>> if it were
> >>> on a 

Re: PC Interference from shredder Was: Kinda fun

[Steve Thompson]

Many years ago at Hagerstown MD, they had a computer (I think it 
was an NCR3 or 3000, it's just been too long ago) that at odd 
points would just fail. My father was an RF tech working on 
radios, and had a contract for the Police Department... so I will 
make this short. It turns out that a few stories below this 
computer room was the door out of the garage where the police 
cars were parked. And so upon exiting the parking garage and 
entering the alley to the street, officers would key their mics 
to verify their radio was working and that would cause the 
computer system to lock up (machine check?).


This was discovered by an NCR CE that had an Oscilloscope doing 
tracing trying to find what was causing this problem and just 
happened to be standing at the window looking down when a police 
car came out and the machine froze.  the police mobile radios 
were a harmonic of the system clock!! And were 100 Watts IRC.


A sign was put at the exit of the garage informing anyone who 
keyed their mic for their radio before getting out of the alley, 
upon being discovered who they were, their pay check would be the 
last one to be passed out at the end of the month. This problem 
had been invariably happening during payroll runs and they had to 
be restarted from the beginning.


Problem stopped.

Steve Thompson

Oh, and the windows did have a metal grid over them in an attempt 
to prevent things like this.


On 11/11/2023 5:07 PM, Tom Brennan wrote:
Just before I worked with mainframes I drew maps on a computer 
that had a big display, a small drawing pad and pen, and a 
large light table with a "puck" for tracing existing maps into 
the computer. Both the puck and pen worked by receiving a 
magnetic signal from the pad or table in order to determine its 
location.  About once a week someone would complain that their 
pen was throwing the cursor all over the screen, so a new pen 
was ordered at maybe $500.


The light table had bunch of fluorescent bulbs inside, and you 
could dim them with a knob if needed.  One day I noticed that 
when the light was either full on or full off, there was no 
problem with my pen.  But if the dimmer was in the middle, the 
pen had issues.  Those dimmers used triacs which work by 
holding back each AC wave a bit and then sharply rising.  The 
sharp rise generates all sorts of EMF and that's what was 
messing with the coil in the pen.


On 11/11/2023 12:55 PM, Wayne Bickerdike wrote:
On the subject of RF interference. Years ago we came back from 
living in
California to Australia. We had a 110V coffee espresso 
machine. It worked
well and we ran it from a voltage changer plugged into the 
socket. Early

rise time, my wife would go into the kitchen and make a coffee.

I'm in the habit of reading my email and surfing at that time 
(like now in

Australia).

For weeks and months my internet would go off and come back a few
minutes later. I eventually tied it back to the coffee 
machine/voltage
reducer. We stopped using it and all good. The wireless router 
runs on
2.4Ghz and is located in my study, maybe 30 feet from the 
kitchen and there

is a double brick wall in the way.

As an adjunct to this. I switch off my router at midnight and 
I get much

better sleep.

On Sun, Nov 12, 2023 at 6:11 AM Joel C. Ewing 
 wrote:


I think shielding of the PC itself is unlikely the problem, 
unless the
case is not properly closed.  All PCs I have ever seen have 
metal cases,
which if properly seated and grounded act as a RF shield, 
inbound and

outbound.

Any electric motor could be producing power transients at 
power on/off
and possible RF interference from contact arcing (which can 
increase
with motor age), which might travel over the house wiring, or 
via air
and get picked up by other cables in the room which are 
connected to the
PC.  Any magnetic effects of a motor should be minor by 
comparison.


If it's a large enough motor, start up may produce a 
temporary dip in
voltage big enough to be a problem for a computer that is not 
powered
through an Uninterruptible Power Supply (UPS).  If you notice 
any lights
flicker when the shredder powers up, that definitely could be 
an issue.
If you are not already using a UPS for your PC, you probably 
should be,
for other reasons as well. The shredder definitely should not 
be plugged
into the same outlet as your computer, and it would be best 
if it were

on a different house circuit as well.

If the problem only started occurring after adding RAM, maybe 
the PC
power supply is now working harder making it more sensitive 
to power
dips than before.  It's also possible the computer may be 
getting old
enough that the power supply is getting less effective at 
filtering out RF.


If for some reason the shredder motor is broadcasting more RF
interference than in the past, keeping it further away from 
any cables
connecting devices to the PC may help.  There are also some 
relatively
inexpensive ferrite beads that can be clipped onto 

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Michael Oujesky]

Does seek() actually do a direct access?  Or read, but skip the 
records from the start of the file?


Michael

At 04:21 PM 11/11/2023, Paul Gilmartin wrote:

On 11/11/23 06:59:07, David S. wrote:

UNIX readily solves the problem with seek() and DSFS is supposed
to mimic a UNIX file with the content of a Classic data set.

Where's the User's Guide for DSFS?

Is the skip count fixed, or is it dynamic, varying up or down
with successive executions of your program?

--
gil

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


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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Michael Oujesky]

I forgt to ask what the BLKSIZE is and why yhe need to skip reading 
just the first 99 records?


Michaet

At 09:34 AM 11/11/2023, Michael Oujesky wrote:

Just a thought as I have not done it, but use BDAM to access the file?

Michael

At 07:59 AM 11/11/2023, David S. wrote:


To help resolve a question posted to a LinkedIn group I manage:
www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
... I'd like to find out if there's any way to achieve *true*
Skip-Sequential processing with a Fixed Block Sequential File with a fairly
short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
For example: Begin sequential processing at record number 100, *without*
having to read the first 99 records.
Note: We already know certain VSAM formats can do this, but the file in
question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
requirement and cannot be changed. We also already know how certain
utilities such as SORT and REXX can *mimic* skip-sequential functionality
by *discarding* unwanted records until the specified record number is
reached. This is a likewise rock-solid requirement. Sequential processing
*must* begin at specified starting point and there can be *no* reading of
any records prior to that point.
My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
*might* be possible with RECFM=F, but efficiency would then be so
compromised it would  probably outweigh any advantage from *true*
skip-sequential processing.

--
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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Mike Schwab]

You can add KEYLEN with the length of the key (default 0)
https://www.ibm.com/docs/en/zos/2.1.0?topic=kp-syntax-4
and KEYOFF with the offset of the Key (default 0).

Copies the high key value from the block into the key field of CKD then you
can add skip sequential processing to Cobol, PL/I, ASM, or other languages
that support keyed access programs, and full read and write programs won't
be affected (beyond changing allocation at creation).  You will be reading,
writing existing blocks so adding or deleting records will not be
possible.

The elapsed time break even point is probably 5 records per cylinder
average over reading all the data. All emulated 3390s read whole tracks at
once.

On Sat, Nov 11, 2023 at 9:35 AM Michael Oujesky 
wrote:

> Just a thought as I have not done it, but use BDAM to access the file?
>
> Michael
>
> At 07:59 AM 11/11/2023, David S. wrote:
>
> >To help resolve a question posted to a LinkedIn group I manage:
> >www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
> >... I'd like to find out if there's any way to achieve *true*
> >Skip-Sequential processing with a Fixed Block Sequential File with a
> fairly
> >short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
> >For example: Begin sequential processing at record number 100, *without*
> >having to read the first 99 records.
> >Note: We already know certain VSAM formats can do this, but the file in
> >question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
> >requirement and cannot be changed. We also already know how certain
> >utilities such as SORT and REXX can *mimic* skip-sequential functionality
> >by *discarding* unwanted records until the specified record number is
> >reached. This is a likewise rock-solid requirement. Sequential processing
> >*must* begin at specified starting point and there can be *no* reading of
> >any records prior to that point.
> >My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
> >*might* be possible with RECFM=F, but efficiency would then be so
> >compromised it would  probably outweigh any advantage from *true*
> >skip-sequential processing.
> >
> >--
> >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
>


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

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Paul Gilmartin]

On 11/11/23 06:59:07, David S. wrote:
> To help resolve a question posted to a LinkedIn group I manage:
> www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
> ... I'd like to find out if there's any way to achieve *true*
> Skip-Sequential processing with a Fixed Block Sequential File with a fairly
> short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
> For example: Begin sequential processing at record number 100, *without*
> having to read the first 99 records.
> 
> 
This feels like a job for DSFS.


UNIX readily solves the problem with seek() and DSFS is supposed
to mimic a UNIX file with the content of a Classic data set.

Where's the User's Guide for DSFS?

Is the skip count fixed, or is it dynamic, varying up or down
with successive executions of your program?

-- 
gil

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

Re: PC Interference from shredder Was: Kinda fun

[Tom Brennan]

Just before I worked with mainframes I drew maps on a computer that had 
a big display, a small drawing pad and pen, and a large light table with 
a "puck" for tracing existing maps into the computer.  Both the puck and 
pen worked by receiving a magnetic signal from the pad or table in order 
to determine its location.  About once a week someone would complain 
that their pen was throwing the cursor all over the screen, so a new pen 
was ordered at maybe $500.


The light table had bunch of fluorescent bulbs inside, and you could dim 
them with a knob if needed.  One day I noticed that when the light was 
either full on or full off, there was no problem with my pen.  But if 
the dimmer was in the middle, the pen had issues.  Those dimmers used 
triacs which work by holding back each AC wave a bit and then sharply 
rising.  The sharp rise generates all sorts of EMF and that's what was 
messing with the coil in the pen.


On 11/11/2023 12:55 PM, Wayne Bickerdike wrote:

On the subject of RF interference. Years ago we came back from living in
California to Australia. We had a 110V coffee espresso machine. It worked
well and we ran it from a voltage changer plugged into the socket. Early
rise time, my wife would go into the kitchen and make a coffee.

I'm in the habit of reading my email and surfing at that time (like now in
Australia).

For weeks and months my internet would go off and come back a few
minutes later. I eventually tied it back to the coffee machine/voltage
reducer. We stopped using it and all good. The wireless router runs on
2.4Ghz and is located in my study, maybe 30 feet from the kitchen and there
is a double brick wall in the way.

As an adjunct to this. I switch off my router at midnight and I get much
better sleep.

On Sun, Nov 12, 2023 at 6:11 AM Joel C. Ewing  wrote:


I think shielding of the PC itself is unlikely the problem, unless the
case is not properly closed.  All PCs I have ever seen have metal cases,
which if properly seated and grounded act as a RF shield, inbound and
outbound.

Any electric motor could be producing power transients at power on/off
and possible RF interference from contact arcing (which can increase
with motor age), which might travel over the house wiring, or via air
and get picked up by other cables in the room which are connected to the
PC.  Any magnetic effects of a motor should be minor by comparison.

If it's a large enough motor, start up may produce a temporary dip in
voltage big enough to be a problem for a computer that is not powered
through an Uninterruptible Power Supply (UPS).  If you notice any lights
flicker when the shredder powers up, that definitely could be an issue.
If you are not already using a UPS for your PC, you probably should be,
for other reasons as well. The shredder definitely should not be plugged
into the same outlet as your computer, and it would be best if it were
on a different house circuit as well.

If the problem only started occurring after adding RAM, maybe the PC
power supply is now working harder making it more sensitive to power
dips than before.  It's also possible the computer may be getting old
enough that the power supply is getting less effective at filtering out RF.

If for some reason the shredder motor is broadcasting more RF
interference than in the past, keeping it further away from any cables
connecting devices to the PC may help.  There are also some relatively
inexpensive ferrite beads that can be clipped onto cables near the
computer to block RFI from entering via that route.

Assuming you are in a house, the simplest experiment is to try moving
the shredder to another room far away from the PC where it can be
powered from a different house circuit.  If that eliminates the problem
and having the shredder in a different room is acceptable, moving the
shredder away from the PC may be the simplest short-term solution.
Otherwise you can either try using a UPS for the PC and/or adding
ferrite RF filters on PC device cables that don't already include a
filter, especially if there are any cables that are routed close to the
shredder.

  JC Ewing


On 11/11/23 06:34, Bob Bridges wrote:

Hah!  A few years ago I had my hardware-geek son build my latest tower

PC.  It's pretty good - not water-cooled like the one he made for himself,
but a nice big monitor and I finally gave him permission to load me up on
RAM.  But ...


Do normal commercial PCs have Faraday cage around them, or something?  I

can't use my old paper shredder any more, because when it fires up within
the same room, the PC suddenly dies and has to be rebooted.  A minor EMP, I
take it.


---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The will to win is not nearly as important as the will to prepare to

win.  -R.M. Knight */


-Original Message-
From: IBM Mainframe Discussion List  On

Behalf Of Leonard D Woren

Sent: Saturday, November 11, 2023 02:12

Long ago I was told why my shop didn't carpet the tape storage area.

Re: PC Interference from shredder Was: Kinda fun

[Mike Schwab]

Microwaves can do that
https://www.theguardian.com/science/2015/may/05/microwave-oven-caused-mystery-signal-plaguing-radio-telescope-for-17-years


On Sat, Nov 11, 2023 at 2:55 PM Wayne Bickerdike  wrote:

> On the subject of RF interference. Years ago we came back from living in
> California to Australia. We had a 110V coffee espresso machine. It worked
> well and we ran it from a voltage changer plugged into the socket. Early
> rise time, my wife would go into the kitchen and make a coffee.
>
> I'm in the habit of reading my email and surfing at that time (like now in
> Australia).
>
> For weeks and months my internet would go off and come back a few
> minutes later. I eventually tied it back to the coffee machine/voltage
> reducer. We stopped using it and all good. The wireless router runs on
> 2.4Ghz and is located in my study, maybe 30 feet from the kitchen and there
> is a double brick wall in the way.
>
> As an adjunct to this. I switch off my router at midnight and I get much
> better sleep.
>
> On Sun, Nov 12, 2023 at 6:11 AM Joel C. Ewing  wrote:
>
> > I think shielding of the PC itself is unlikely the problem, unless the
> > case is not properly closed.  All PCs I have ever seen have metal cases,
> > which if properly seated and grounded act as a RF shield, inbound and
> > outbound.
> >
> > Any electric motor could be producing power transients at power on/off
> > and possible RF interference from contact arcing (which can increase
> > with motor age), which might travel over the house wiring, or via air
> > and get picked up by other cables in the room which are connected to the
> > PC.  Any magnetic effects of a motor should be minor by comparison.
> >
> > If it's a large enough motor, start up may produce a temporary dip in
> > voltage big enough to be a problem for a computer that is not powered
> > through an Uninterruptible Power Supply (UPS).  If you notice any lights
> > flicker when the shredder powers up, that definitely could be an issue.
> > If you are not already using a UPS for your PC, you probably should be,
> > for other reasons as well. The shredder definitely should not be plugged
> > into the same outlet as your computer, and it would be best if it were
> > on a different house circuit as well.
> >
> > If the problem only started occurring after adding RAM, maybe the PC
> > power supply is now working harder making it more sensitive to power
> > dips than before.  It's also possible the computer may be getting old
> > enough that the power supply is getting less effective at filtering out
> RF.
> >
> > If for some reason the shredder motor is broadcasting more RF
> > interference than in the past, keeping it further away from any cables
> > connecting devices to the PC may help.  There are also some relatively
> > inexpensive ferrite beads that can be clipped onto cables near the
> > computer to block RFI from entering via that route.
> >
> > Assuming you are in a house, the simplest experiment is to try moving
> > the shredder to another room far away from the PC where it can be
> > powered from a different house circuit.  If that eliminates the problem
> > and having the shredder in a different room is acceptable, moving the
> > shredder away from the PC may be the simplest short-term solution.
> > Otherwise you can either try using a UPS for the PC and/or adding
> > ferrite RF filters on PC device cables that don't already include a
> > filter, especially if there are any cables that are routed close to the
> > shredder.
> >
> >  JC Ewing
> >
> >
> > On 11/11/23 06:34, Bob Bridges wrote:
> > > Hah!  A few years ago I had my hardware-geek son build my latest tower
> > PC.  It's pretty good - not water-cooled like the one he made for
> himself,
> > but a nice big monitor and I finally gave him permission to load me up on
> > RAM.  But ...
> > >
> > > Do normal commercial PCs have Faraday cage around them, or something?
> I
> > can't use my old paper shredder any more, because when it fires up within
> > the same room, the PC suddenly dies and has to be rebooted.  A minor
> EMP, I
> > take it.
> > >
> > > ---
> > > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> > >
> > > /* The will to win is not nearly as important as the will to prepare to
> > win.  -R.M. Knight */
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > Behalf Of Leonard D Woren
> > > Sent: Saturday, November 11, 2023 02:12
> > >
> > > Long ago I was told why my shop didn't carpet the tape storage area.
> > Apparently some shop that did had a problem with unreadable tapes.
> > Eventually they figured out that all the unreadable tapes were on the
> > bottom row of the tape storage.  And the outside cleaning people used a
> > vacuum cleaner...
> > >
> > > --- Bob Bridges wrote on 11/8/2023 6:56 AM:
> > >> /* The more sophisticated the technology, the more vulnerable it is to
> > >> primitive attack. People often overlook the obvious.  -Dr Who, 1978 */
> > >
> > 

Re: PC Interference from shredder Was: Kinda fun

[Wayne Bickerdike]

On the subject of RF interference. Years ago we came back from living in
California to Australia. We had a 110V coffee espresso machine. It worked
well and we ran it from a voltage changer plugged into the socket. Early
rise time, my wife would go into the kitchen and make a coffee.

I'm in the habit of reading my email and surfing at that time (like now in
Australia).

For weeks and months my internet would go off and come back a few
minutes later. I eventually tied it back to the coffee machine/voltage
reducer. We stopped using it and all good. The wireless router runs on
2.4Ghz and is located in my study, maybe 30 feet from the kitchen and there
is a double brick wall in the way.

As an adjunct to this. I switch off my router at midnight and I get much
better sleep.

On Sun, Nov 12, 2023 at 6:11 AM Joel C. Ewing  wrote:

> I think shielding of the PC itself is unlikely the problem, unless the
> case is not properly closed.  All PCs I have ever seen have metal cases,
> which if properly seated and grounded act as a RF shield, inbound and
> outbound.
>
> Any electric motor could be producing power transients at power on/off
> and possible RF interference from contact arcing (which can increase
> with motor age), which might travel over the house wiring, or via air
> and get picked up by other cables in the room which are connected to the
> PC.  Any magnetic effects of a motor should be minor by comparison.
>
> If it's a large enough motor, start up may produce a temporary dip in
> voltage big enough to be a problem for a computer that is not powered
> through an Uninterruptible Power Supply (UPS).  If you notice any lights
> flicker when the shredder powers up, that definitely could be an issue.
> If you are not already using a UPS for your PC, you probably should be,
> for other reasons as well. The shredder definitely should not be plugged
> into the same outlet as your computer, and it would be best if it were
> on a different house circuit as well.
>
> If the problem only started occurring after adding RAM, maybe the PC
> power supply is now working harder making it more sensitive to power
> dips than before.  It's also possible the computer may be getting old
> enough that the power supply is getting less effective at filtering out RF.
>
> If for some reason the shredder motor is broadcasting more RF
> interference than in the past, keeping it further away from any cables
> connecting devices to the PC may help.  There are also some relatively
> inexpensive ferrite beads that can be clipped onto cables near the
> computer to block RFI from entering via that route.
>
> Assuming you are in a house, the simplest experiment is to try moving
> the shredder to another room far away from the PC where it can be
> powered from a different house circuit.  If that eliminates the problem
> and having the shredder in a different room is acceptable, moving the
> shredder away from the PC may be the simplest short-term solution.
> Otherwise you can either try using a UPS for the PC and/or adding
> ferrite RF filters on PC device cables that don't already include a
> filter, especially if there are any cables that are routed close to the
> shredder.
>
>  JC Ewing
>
>
> On 11/11/23 06:34, Bob Bridges wrote:
> > Hah!  A few years ago I had my hardware-geek son build my latest tower
> PC.  It's pretty good - not water-cooled like the one he made for himself,
> but a nice big monitor and I finally gave him permission to load me up on
> RAM.  But ...
> >
> > Do normal commercial PCs have Faraday cage around them, or something?  I
> can't use my old paper shredder any more, because when it fires up within
> the same room, the PC suddenly dies and has to be rebooted.  A minor EMP, I
> take it.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* The will to win is not nearly as important as the will to prepare to
> win.  -R.M. Knight */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of Leonard D Woren
> > Sent: Saturday, November 11, 2023 02:12
> >
> > Long ago I was told why my shop didn't carpet the tape storage area.
> Apparently some shop that did had a problem with unreadable tapes.
> Eventually they figured out that all the unreadable tapes were on the
> bottom row of the tape storage.  And the outside cleaning people used a
> vacuum cleaner...
> >
> > --- Bob Bridges wrote on 11/8/2023 6:56 AM:
> >> /* The more sophisticated the technology, the more vulnerable it is to
> >> primitive attack. People often overlook the obvious.  -Dr Who, 1978 */
> >
> --
> Joel C. Ewing
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: Well, I guess RESMGR is documented as only supporting 24/31 bit

[Paul Gilmartin]

On Sat, 11 Nov 2023 22:14:07 +0200, Binyamin Dissen  wrote:

>It does not check SYSSTATE AMODE64.
> 
Don't be impatient.  They're probably working on it.

-- 
gil

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

Well, I guess RESMGR is documented as only supporting 24/31 bit

[Binyamin Dissen]

It does not check SYSSTATE AMODE64.

But even so, as it ends up issuing a PC there is no real reason not to support
64 bit. Using LLGT to get the CVT address is common in other macros. Document
that parameters need to be below the bar.

In other cases I have used OPSYN to examine instructions and replace them,
i.e., change the 

  L 14,16(0,0)  

to 

   LLGT  14,16(0,0)

but 

Instead I will need to document the reason for the extra SAM's.

--
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: CEE3512S / CSV034I

[Henri Kuiper]

Yes!

seen the other reply too (thanks again Denis!) I'll verify and get in touch
with the 'documentation peeps' fo-sho :)

fingeres crossed this will workwith the larger REGION though :)


On Sat, Nov 11, 2023 at 2:40 PM Peter Relson  wrote:

> As Denis G suggested, you do not have sufficient storage for the system to
> acquire for holding the module you have asked to load. At a minimum you
> need a larger region size. If you have an aberrant program (such as one
> that does a getmain for the entire available region prior to loading this
> executable), you will have to change the program.
>
> Please submit feedback on CSV034I to ask to document the return code 14
> reason code 26110021 combination since that is a case that you can actually
> do something yourself about and does not need to be reported to IBM Support.
>
> 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
>

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

Re: CEE3512S / CSV034I

[Henri Kuiper]

Nice!

thanks... I will give that a try.


Met vriendelijke groeten,

*Henri Kuiper*

*zdevops*


On Fri, Nov 10, 2023 at 7:39 AM Denis <
01664d8ede6c-dmarc-requ...@listserv.ua.edu> wrote:

>  Hi Henri,
> if you google the reason code you find other entries that point to not
> enough region size. So try increasing the region size?
> Denis.
>
> On Thursday, November 9, 2023 at 10:31:52 PM GMT+1, Henri Kuiper <
> henrikui...@zdevops.com> wrote:
>
>  Heya Fellow Mainframers,
>
> I'm trying to do some 'normal ES256K' JWT token signage with python...
>
> on my 'test SYSPLEX' this works like a charm.yet one hop over I get the
> following
>
> CEE3512S An HFS load of module
> /.../site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
> failed. The system return code was 000157; the reason code was
> 0BDF019B.
>
> MSGTXT: CSV034I PGMF FETCH FAILED FOR THE REQUESTED MODULE. RETURN CODE 14,
> REASON CODE 26110021 PATHNAME =
> /../site-packages/cryptography/hazmat/bindings/_openssl.abi3.so
>
> I've checked all the obvious stuff : perms, openssl versions,
> module/package versions for cryptography, python version etc. and they're
> all the same...
>
> . Does anyone have another idea where to look?...
>
> Thanks!
>
> *Henri Kuiper*
> *zdevops*
>
> --
> 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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Michael Stein]

On Sat, Nov 11, 2023 at 08:59:07AM -0500, David S. wrote:
> ... I'd like to find out if there's any way to achieve *true*
> Skip-Sequential processing with a Fixed Block Sequential File with a fairly
> short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?

> question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
> requirement and cannot be changed. 

> Sequential processing *must* begin at specified starting point and
> there can be *no* reading of any records prior to that point.

I take this to mean that the support routines may read a few other records
or blocks but they should not be returned to the application program.

  (VSAM skip-sequential is going to read the whole CI which might include
  records before the one requested...)

> My gut feeling is it *cannot* be done - at least not with RECFM=FB. 

I'm assuming that the DSORG=PS RECFM=FB file is huge.  If the process
which creates the input file could be changed to make it FBS then previous
answers have covered what's necessary to calculate the correct block to
start the sequential reads via BSAM using point. 

If it is only FB and not FBS then it's a bit harder.  Perhaps it's 
been written DISP=MOD and thus is likely to have some short blocks.

Possible plans:

A. build an index of record number to position in the file and
   then use this to find where to start reading.

   If the index was kept around the huge file could be skip-seq read
   several times without rebuilding the index.  The index might be pretty
   small as it only needs to keep the record number for say each track
   or cylinder.

   The index could be built by reading the whole input file or the data
   transfer could be minimized by using EXCP with read count CCWs to
   collect block sizes and locations.  This might also minimize the real
   time as I'd expect that some "virtual disk" boxes might even be able
   to execute the read count CCWs without waiting for disk revolutions
   (and of course, not transfering the data, just the count fields).

B. guess where the record might be and adjust the guess as needed

   If the records have some identifying information in them so that the
   position in the file (record number) record number isn't really the
   only way to find the correct record, then it should be possible to
   guess a likely location and search the blocks around there.  If there
   are only few short blocks this might only involve reading a block or
   two more than the FBS case.

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

Re: PC Interference from shredder Was: Kinda fun

[Joel C. Ewing]

I think shielding of the PC itself is unlikely the problem, unless the 
case is not properly closed.  All PCs I have ever seen have metal cases, 
which if properly seated and grounded act as a RF shield, inbound and 
outbound.


Any electric motor could be producing power transients at power on/off 
and possible RF interference from contact arcing (which can increase 
with motor age), which might travel over the house wiring, or via air 
and get picked up by other cables in the room which are connected to the 
PC.  Any magnetic effects of a motor should be minor by comparison.


If it's a large enough motor, start up may produce a temporary dip in 
voltage big enough to be a problem for a computer that is not powered 
through an Uninterruptible Power Supply (UPS).  If you notice any lights 
flicker when the shredder powers up, that definitely could be an issue.  
If you are not already using a UPS for your PC, you probably should be, 
for other reasons as well. The shredder definitely should not be plugged 
into the same outlet as your computer, and it would be best if it were 
on a different house circuit as well.


If the problem only started occurring after adding RAM, maybe the PC 
power supply is now working harder making it more sensitive to power 
dips than before.  It's also possible the computer may be getting old 
enough that the power supply is getting less effective at filtering out RF.


If for some reason the shredder motor is broadcasting more RF 
interference than in the past, keeping it further away from any cables 
connecting devices to the PC may help.  There are also some relatively 
inexpensive ferrite beads that can be clipped onto cables near the 
computer to block RFI from entering via that route.


Assuming you are in a house, the simplest experiment is to try moving 
the shredder to another room far away from the PC where it can be 
powered from a different house circuit.  If that eliminates the problem 
and having the shredder in a different room is acceptable, moving the 
shredder away from the PC may be the simplest short-term solution.  
Otherwise you can either try using a UPS for the PC and/or adding 
ferrite RF filters on PC device cables that don't already include a 
filter, especially if there are any cables that are routed close to the 
shredder.


    JC Ewing


On 11/11/23 06:34, Bob Bridges wrote:

Hah!  A few years ago I had my hardware-geek son build my latest tower PC.  
It's pretty good - not water-cooled like the one he made for himself, but a 
nice big monitor and I finally gave him permission to load me up on RAM.  But 
...

Do normal commercial PCs have Faraday cage around them, or something?  I can't 
use my old paper shredder any more, because when it fires up within the same 
room, the PC suddenly dies and has to be rebooted.  A minor EMP, I take it.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The will to win is not nearly as important as the will to prepare to win.  
-R.M. Knight */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Leonard D Woren
Sent: Saturday, November 11, 2023 02:12

Long ago I was told why my shop didn't carpet the tape storage area. Apparently 
some shop that did had a problem with unreadable tapes. Eventually they figured 
out that all the unreadable tapes were on the bottom row of the tape storage.  
And the outside cleaning people used a vacuum cleaner...

--- Bob Bridges wrote on 11/8/2023 6:56 AM:

/* The more sophisticated the technology, the more vulnerable it is to
primitive attack. People often overlook the obvious.  -Dr Who, 1978 */



--
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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Joel C. Ewing]

If the question is whether there is direct z/OS support for this for FB 
PS datasets, the answer is probably no, although if you get down to 
assembler coding, there are ways to get close.


It looks like you could potentially design and implement an I/O 
interface routine (in assembler) using BSAM access macros and POINT for 
positioning to a block by calculating what block and record within a 
block to start processing.  Under the covers this is similar to what 
VSAM does -- determine starting block and logically skip over unwanted 
records in the first block .  Since the smallest physical read is for a 
block, you obviously can't avoid the overhead of a physical read of 
unwanted records in the first and last needed blocks on 
skip-sequential.  With VSAM, if you allow too much buffer space, you can 
even waste resources reading unneeded blocks beyond the last block 
needed if only a few records are read at each read point.


Of course the nasty part is, I believe, all higher-level programming 
languages are going to want to access the dataset using QSAM access for 
buffered I/O, and POINT is not supported for QSAM access.  A solution 
likely requires Assembler code.  A BSAM READ only reads a single block; 
so by default there is no buffered read-ahead for following blocks and 
no overlap between processing and disk block reads, and at best you only 
get one block per disk revolution.  If you want decent performance 
reading multiple sequential blocks in a single disk rotation and 
overlapping processing & I/O, I'm pretty sure you have to do your own 
buffer management and queue up multiple read requests to initiate 
reading blocks before they are needed, and only check for I/O completion 
on a block when the block is needed.  I think if multiple BSAM READs are 
issued for sequential blocks in the same dataset, and their channel 
programs are waiting in the queue for the channel, that zOS may chain 
the channel programs of queued requests for the same dataset together so 
that multiple blocks can be read in one disk revolution.  If that's not 
the case with BSAM access, and if each skip-sequential read sequence 
will require multiple blocks, then getting down to the level of building 
channel programs may be required for efficiency, and an efficient 
solution becomes an order of magnitude more difficult.


So the longer answer is that it can be done, but unless you can find 
assembler-level code that already provides this capability, this looks 
like a lot of work just to avoid looking at a VSAM solution.  Perhaps 
someone has already written code to do this type of access efficiently 
for FB PS datasets (check the CBT utilities?).


I would think whatever process generates a FB PS dataset could almost as 
easily generate an ESDS dataset.  Or perhaps an ESDS copy of the dataset 
could be made.


This all presumes the FB PS dataset is created in such a way that the 
only potentially-short block is the last.  The mention of UNIX files is 
an interesting thought, but I have no idea how clever that support may 
be on doing buffered reads of subsequent blocks to maximize I/O 
performance.  ESDS skip-sequential should by default pre-read following 
blocks based on number of buffers specified, which you can control.in 
the JCL


   JC Ewing

On 11/11/23 07:59, David S. wrote:

To help resolve a question posted to a LinkedIn group I manage:
www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
... I'd like to find out if there's any way to achieve *true*
Skip-Sequential processing with a Fixed Block Sequential File with a fairly
short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
For example: Begin sequential processing at record number 100, *without*
having to read the first 99 records.
Note: We already know certain VSAM formats can do this, but the file in
question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
requirement and cannot be changed. We also already know how certain
utilities such as SORT and REXX can *mimic* skip-sequential functionality
by *discarding* unwanted records until the specified record number is
reached. This is a likewise rock-solid requirement. Sequential processing
*must* begin at specified starting point and there can be *no* reading of
any records prior to that point.
My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
*might* be possible with RECFM=F, but efficiency would then be so
compromised it would  probably outweigh any advantage from *true*
skip-sequential processing.



--
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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Walt Farrell]

On Sat, 11 Nov 2023 08:59:07 -0500, David S.  wrote:

>To help resolve a question posted to a LinkedIn group I manage:
>www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
>... I'd like to find out if there's any way to achieve *true*
>Skip-Sequential processing with a Fixed Block Sequential File with a fairly
>short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
>For example: Begin sequential processing at record number 100, *without*
>having to read the first 99 records.

As another user mentioned, you can't really read portions of blocks, so 
whatever block contains record number 100 would need to be read, which might 
give you some extraneous data transfer.

The real issue is your RECFM=FB. With FBS it would be possible, as with FBS you 
know that all blocks up to the final one are the same size, and that would 
allow you to calculate the block you needed. But with FB you could have short 
blocks in the middle, making it impossible to calculate where record 100 is 
located.

Another issue, I suppose, is what language you're writing in, as I believe only 
some access methods would allow you to position the file based on a block 
number.

-- 
Walt

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Paul Gilmartin]

On Sat, 11 Nov 2023 08:59:07 -0500, David S. wrote:
>...
. Sequential processing
>*must* begin at specified starting point and there can be *no* reading of
>any records prior to that point.
>
That sounds absurd.  So if a block contains 10 records, you want to
be able to read the last 5 with "*no* reading of" the first 5!?
DASD don't work that way.

>My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
>*might* be possible with RECFM=F, but efficiency would then be so
>compromised it would  probably outweigh any advantage from *true*
>skip-sequential processing.

How about UNIX files with RECFM=FB,FILEDATA=BINARY and using
seek()?  (But that still reads entire blocks into a buffer.)

-- 
gil

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Michael Oujesky]

Just a thought as I have not done it, but use BDAM to access the file?

Michael

At 07:59 AM 11/11/2023, David S. wrote:


To help resolve a question posted to a LinkedIn group I manage:
www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
... I'd like to find out if there's any way to achieve *true*
Skip-Sequential processing with a Fixed Block Sequential File with a fairly
short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
For example: Begin sequential processing at record number 100, *without*
having to read the first 99 records.
Note: We already know certain VSAM formats can do this, but the file in
question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
requirement and cannot be changed. We also already know how certain
utilities such as SORT and REXX can *mimic* skip-sequential functionality
by *discarding* unwanted records until the specified record number is
reached. This is a likewise rock-solid requirement. Sequential processing
*must* begin at specified starting point and there can be *no* reading of
any records prior to that point.
My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
*might* be possible with RECFM=F, but efficiency would then be so
compromised it would  probably outweigh any advantage from *true*
skip-sequential processing.

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

Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[David S.]

To help resolve a question posted to a LinkedIn group I manage:
www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
... I'd like to find out if there's any way to achieve *true*
Skip-Sequential processing with a Fixed Block Sequential File with a fairly
short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
For example: Begin sequential processing at record number 100, *without*
having to read the first 99 records.
Note: We already know certain VSAM formats can do this, but the file in
question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
requirement and cannot be changed. We also already know how certain
utilities such as SORT and REXX can *mimic* skip-sequential functionality
by *discarding* unwanted records until the specified record number is
reached. This is a likewise rock-solid requirement. Sequential processing
*must* begin at specified starting point and there can be *no* reading of
any records prior to that point.
My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
*might* be possible with RECFM=F, but efficiency would then be so
compromised it would  probably outweigh any advantage from *true*
skip-sequential processing.

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

Re: CEE3512S / CSV034I

[Peter Relson]

As Denis G suggested, you do not have sufficient storage for the system to 
acquire for holding the module you have asked to load. At a minimum you need a 
larger region size. If you have an aberrant program (such as one that does a 
getmain for the entire available region prior to loading this executable), you 
will have to change the program.

Please submit feedback on CSV034I to ask to document the return code 14 reason 
code 26110021 combination since that is a case that you can actually do 
something yourself about and does not need to be reported to IBM Support.

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: Kinda fun

[Bob Bridges]

Hah!  A few years ago I had my hardware-geek son build my latest tower PC.  
It's pretty good - not water-cooled like the one he made for himself, but a 
nice big monitor and I finally gave him permission to load me up on RAM.  But 
...

Do normal commercial PCs have Faraday cage around them, or something?  I can't 
use my old paper shredder any more, because when it fires up within the same 
room, the PC suddenly dies and has to be rebooted.  A minor EMP, I take it.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The will to win is not nearly as important as the will to prepare to win.  
-R.M. Knight */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Leonard D Woren
Sent: Saturday, November 11, 2023 02:12

Long ago I was told why my shop didn't carpet the tape storage area. Apparently 
some shop that did had a problem with unreadable tapes. Eventually they figured 
out that all the unreadable tapes were on the bottom row of the tape storage.  
And the outside cleaning people used a vacuum cleaner...

--- Bob Bridges wrote on 11/8/2023 6:56 AM:
> /* The more sophisticated the technology, the more vulnerable it is to 
> primitive attack. People often overlook the obvious.  -Dr Who, 1978 */

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