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: IBM-MAIN Digest - 15 Sep 2017 to 16 Sep 2017 (#2017-259)

[David S.]

On Sun, Sep 17, 2017 at 12:00 AM, IBM-MAIN automatic digest system <
lists...@listserv.ua.edu> wrote:

> There are 3 messages totaling 156 lines in this issue.
>
> Topics of the day:
>
>   1. STC - APF - confusion (2)
>   2. re-Initialize different types of VSAM files
>
> --
>
> Date:Sat, 16 Sep 2017 18:33:17 +
> From:scott Ford 
> Subject: STC - APF - confusion
>
> All,
>
> I have a COBOL written STC that is single thread socket server. It receives
> messages that are
> RACF commands and then calls a module which calls r_ admin. My question is
> this,
> when I initially started working with this code , it was AC (1) , I didn't
> think anything about it.
> But we are in the process of building a CI process the the STC main program
> was blinded as AC(0).
> The client made the RACF call failed Saf=8, RACF=16, RACF-reason-code=8,
> 'insufficient authority'.
> The calling module was AC(0) also , at this point I knew what it was
> re-assembled the called program to be
> AC(1) and everything in 'Dodge' was good, it worked.
>
>
> Now the question, I want to run a STC as AC(0) and have the caller as
> described above.
> I am concerned about the security hole that is open, the call last a few ms
> if that.
> The second question is about how it works. Since I am dealing with COBOL is
> the APF
> Arena, does it behave the same ?
>
> Thanks in advance,
>
> Scott
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
>
> Date:Sat, 16 Sep 2017 19:43:34 +
> From:"Blaicher, Christopher Y." 
> Subject: Re: STC - APF - confusion
>
> Here it is as simply as I can put it.
>
> If the first program executed by an EXEC PGM= is AC(1), AND ALL the
> STEPLIB libraries, if any, are APF authorized, then all the
> branched/LINK/LOAD or ATTACH programs run authorized.  If any library in
> the STEPLIB concatenation is unauthorized, it is like they were all
> unauthorized.
> OK.  There are always some caveats, so here is the one I remember.  If you
> LINK/LOAD/ATTACH a program from a library in the LNKLIST and you have only
> authorized individual libraries in the list, rather than the whole list,
> and you are calling a module in one of those unauthorized libraries, then
> your job (and I can't remember which) either becomes unauthorized or it
> fails with an abend.
>
> Now to the second part of your question.  It doesn’t matter what language
> the program was written in.
>
> And the third part.  If the STC (A) is authorized and listening on a
> socket, and another program (B) puts a message on the socket for program A
> to do something with it, no problem.  A stays authorized and it doesn't
> matter what state B is in.
>
> If the STC (A) is running AC(0) and (B) is authorized and puts something
> on the socket, (A) stays unauthorized.
>
> Remember, authorization occurs at the address space level.  And once you
> do something to lose authorization, it is gone for good.
>
> OK, I know there are those of you out there saying you can get it back,
> but that involves tricks of the trade that should not be present on a
> production or even test machine.  Maybe on your private sandbox machine,
> but not on a production one.
>
> Chris Blaicher
> Technical Architect
> Mainframe Development
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563
> Pearl River, NY 10965
> www.syncsort.com
>
> Data quality leader Trillium Software is now a part of Syncsort.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of scott Ford
> Sent: Saturday, September 16, 2017 2:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: STC - APF - confusion
>
> All,
>
> I have a COBOL written STC that is single thread socket server. It
> receives messages that are RACF commands and then calls a module which
> calls r_ admin. My question is this, when I initially started working with
> this code , it was AC (1) , I didn't think anything about it.
> But we are in the process of building a CI process the the STC main
> program was blinded as AC(0).
> The client made the RACF call failed Saf=8, RACF=16, RACF-reason-code=8,
> 'insufficient authority'.
> The calling module was AC(0) also , at this point I knew what it was
> re-assembled the called program to be
> AC(1) and everything in 'Dodge' was good, it worked.
>
>
> Now the question, I want to run a STC as AC(0) and have the caller as
> described above.
> I am concerned about the security hole that is open, the call last a few
> ms if that.
> The second question is about how it works. Since I am dealing with COBOL
> is the APF 

Re: Apache Spark on z listserver or forum?

[David S.]

Saw this in the LinkedIn "Performance & Optimization News..." group:
http://linkd.in/2i03y7v - "Spark Analytics on the Mainframe
Interesting article by Stephen D. Bartlett at the Clipper Group about
running Spark on the mainframe: IBM z Systems Get a Big Charge Out of Spark
Analytics."

Roger Lowe wrote:
> Our site is currently in the very early stages of dabbling with
> Apache Spark on z and was wondering if there is a Listserver
> or Forum specifically for Apache Spark on z.

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

How to Calculate %USED for PDSE?

[David S.]

[Also posted to the Linked-In "Mainframe Assembler Professionals" group at
http://linkd.in/1VjEST7 ]
I wrote a program to create a report of DASD usage by scanning the UCB
Table, then reading all the DSCBs from all the DASD Volumes for usage data
and summing by DSN. The output is essentially the same as a TSO
LMDINIT/LMDLIST sequence on each VOLSER, but runs a *lot* faster and is
*much* easier to manage. One of the items I calculate is %USED based on
DS1LSTAR as a percentage of the sum of all the extent values from all the
extents on all the allocated volumes. And for everything but PDSE, my
results are the same as LMDLIST, which I understand, since PDSEs don't use
DS1LSTAR.
Looking around the web, I see others coming up against this problem for at
least the last 10 years, but none have any proposed low-level coding
solution. There obviously *is* one, since facilities like ISPF 3.4 and
FDREPORT do it.

My best idea so far (which so far also isn't working) is to call LISTDSI...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a3a0/4.4.2 ...
using the IRXEXEC API:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/H1981605/APPENDIX1.F.1.2
 which the manuals suggest has some usage data for PDSEs I can then use to
do the calculation.
►z/OS 2.1 and up even returns SYSUSEDPERCENT:
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikja300/ldsi.htm
Any better suggestions??
http://www.fdr.com/pdf/itsf.pdf - Innovation Data Processing has been doing
it since at least 1992!
David Staudacher
co-mgr Mainframe Assembler Professionals group

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

Re: Conversion from Unisys Cobol file definitions to zOS

[David S.]

"... conversion utility or compiler directive to make the translation from
the Unisys implementation of Cobol FD's to Enterprise Cobol?"

If the data is *all* in character format, then conversion from ASCII to
EBCDIC is easy using OPTCD=Q on the DCB. Unfortunately, that's seldom the
case, which makes things *much* more complicated.  You mention the
half-byte alignment problem, so you're already aware of that one. There's
also the issue of how signed and unsigned decimal fields are handled
(Unisys=leftmost position or none, IBM=rightmost position always).

MCP was inherited from the Burroughs side of the Unisys family, so there
will likely be some detailed information on the proprietary data types
somewhere here:
http://bitsavers.trailing-edge.com/pdf/burroughs
Wish I could be more specific, but my depth of expertise is more on the IBM
side.
If anyone can point to a *specific* reference for Burroughs/Unisys data
types, please post it here.  I'd love to see it!

There was a recent discussion of specific Unisys to IBM conversion issues
on the "Mainframe Assembler Professionals" LinkedIn group, here:
http://www.linkedin.com/groups/1462937/1462937-6049636244294488065
BFX was mentioned (a Netex product), was mentioned as a solution, and the
person posting sounded very positive about it, but looking at their
documentation, I don't see a reference which specifically says it does
Unisys to IBM conversion - z/OS to Unisys, yes, but not the other way
around:
http://www.netexsw.com/nesi/support/ReleasedDocs/H21x/man-ref-H211-08.pdf
And if it is supported, it looks like you basically write the conversion
code yourself, in Assembler, around which BFX is basically just a
"wrapper".

For a fee, there are some companies which can do the conversion for you,
such as:
http://www.discinterchange.com



> Date:Tue, 12 Jan 2016 16:04:58 +
> From:"Ambros, Thomas" 
> Subject: Conversion from Unisys Cobol file definitions to zOS
>
> My apologies if there is a Cobol listserv that I should have subscribed to
> and submitted the question there, if someone knows of it please let me know
> so I can redirect to the correct place.
>
> Pardon me, also, if I use terms incorrectly in phrasing my question
> because I couldn't be weaker in application programming or Cobol
> idiosyncracies.
>
> Our site has occasion to import files from a Unisys site running 'MCP
> Level 57 Miser level 15.2', and integrate the data with the application
> datasets on the local system.  I do not know the Cobol product the Unisys
> site is using, I have inquiries out but no answers yet.  There are at least
> a few items causing our application programmers some difficulties.
>
> For example, it appears that the COMP fields in the Unisys file do not
> occupy storage the same as they do on zOS.   For example, a COMP field with
> three digits occupies one and one-half bytes on the Unisys file whereas on
> zOS it would be a halfword.
>
> Given the size and number of the files and descriptions to convert, coding
> a conversion by hand is not entirely practical.
>
> I realize this is a pretty vague request, but does anyone know of a
> conversion utility or compiler directive to make the translation from the
> Unisys implementation of Cobol FD's to Enterprise Cobol?   I have done some
> basic Google searching but nothing I find appears to address this sort of
> thing very closely.
>
> Thomas Ambros
> zEnterprise Operating Systems
> zEnterprise Systems Management
> 518-436-6433
>
>
>

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

Re: Conversion from Unisys Cobol file definitions to zOS

[David S.]

Paul Gilmartin wrote:

> Does OPTCD=Q work on all device types?
> I had got the impression it applied only to tapes.

Yes, tape is implicit. OPTCD=Q only works with tape.
ASCII conversion topic in "z/OS DFSMS: Using Magnetic Tapes":
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dgt2m320/3.7.1

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

Re: Publications Needed

[David S.]

> I'm looking for the following publications:
> IBM z13 Installation Manual, GC28-6936
> IBM z13 Service Guide, GC28-693
>

Found this one *outside* Resource Link:

GC28-6936:
http://www-01.ibm.com/support/docview.wss?uid=isg23d0fa54bd6d29c5885257dc400795260

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

Re: Publications Needed

[David S.]

On Mon, Jan 11, 2016 at 8:10 AM, David S. <dlstaudac...@gmail.com> wrote:


> Found this one *outside* Resource Link:
>
> GC28-6936:
>
> http://www-01.ibm.com/support/docview.wss?uid=isg23d0fa54bd6d29c5885257dc400795260
>

It comes up as GC28-6938, but found it using:
http://www.ibm.com/support/entry/myportal/search_results?sn=spe=GC28-6936

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

Re: COBOL Code Gened for MOVE COMP-3 S9(9) to S9(8)

[David S.]

I wish this question had been stated with greater precision and accuracy,
since the precision and accuracy of the answer directly depend on it.  Too
much guesswork.
(1) What *exactly* were the COBOL field definitions and the MOVE
statement?? The title just says "MOVE COMP-3 S9(9) to S9(8)". Does that
mean one field is COMP-3 and the other zoned decimal?  Or are both COMP-3?

(2) As Robert Rosenberg pointed out on Sun 13-Dec: "That should be ZAP
3672(5,5),1971(1,5) or you will only get the first byte of the source
field."  Thus, the validity of the copied assembler instructions themselves
are questionable.

I really hate having to guess and risk getting it wrong. I've found the
correct answer often comes from simply developing a precise and accurate
statement of the problem.

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