Is there still a system automation list / group?

2023-05-15 Thread Vince Getgood
Just as per the title really,
Since the demise of Yahoo groups, Is there still a system automation list / 
group?

I'm trying to find any information on a set of SA supplied REXX (member names 
INGFIFxx) that apparently interface with the SA PDB to query information held 
in SA ISPF tables.   I'm told it's a kind of API, but I can't find any 
documentation or information on them anywhere...

Any help or assistance gratefully received!
Thanks in advance.

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


Re: Is there still a system automation list / group?

2023-05-15 Thread Steve Horein
They moved to groups.io:
https://groups.io/g/SAUsers
https://groups.io/g/NetView

On Mon, May 15, 2023 at 5:28 AM Vince Getgood <
04d5c094df74-dmarc-requ...@listserv.ua.edu> wrote:

> Just as per the title really,
> Since the demise of Yahoo groups, Is there still a system automation list
> / group?
>
> I'm trying to find any information on a set of SA supplied REXX (member
> names INGFIFxx) that apparently interface with the SA PDB to query
> information held in SA ISPF tables.   I'm told it's a kind of API, but I
> can't find any documentation or information on them anywhere...
>
> Any help or assistance gratefully received!
> Thanks in advance.
>
> --
> 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 there still a system automation list / group?

2023-05-15 Thread Vince Getgood
Excellent, Thanks.

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


zPCA users?

2023-05-15 Thread Dave Jousma
All,

We are discussing zPCA - IBM Performance and Capacity Analytics, and I'd like 
to trade some email or even a quick phone conversation with a shop that has had 
some hands-on experience?

Thanks, Dave

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


Re: System Rexx 2

2023-05-15 Thread Peter Ten Eyck
Simple exec:

/* REXX
   TRACE A 
   SAY 'Welcome to System Rexx'
exit 0 


Results:

NC000 EXPR 23135 08:43:37.27 FF00768  0290  F AXR,POCSYSR1  
  
N 020 EXPR 23135 08:43:37.29 STC02360 0281  $HASP100 AXR01ON 
STCINRDR 
N 400 EXPR 23135 08:43:37.30 STC02360 0090  $HASP373 AXR01
STARTED 
N 000 EXPR 23135 08:43:37.30 STC02360 0090  IEF403I AXR01 - STARTED 
- TIME=08.43.37   
N 0004000 EXPR 23135 08:43:37.31 STC02360 0290  -   
   --TIMINGS (MINS.)--
S -PAGING 
COUNTS  
N 0004000 EXPR 23135 08:43:37.31 STC02360 0290  -STEPNAME PROCSTEP
RC   EXCP   CONNTCBSRB  CLOCK   SERV
S   WORKLOAD  PAGE  SWAP   
VIO SWAPS  
N 0004000 EXPR 23135 08:43:37.31 STC02360 0290  - AXRPSTRT
00  5  0.00.00 .0 55
S   STCPROD  0 0
 0 0  
N 000 EXPR 23135 08:43:37.31 STC02360 0090  IEF404I AXR01 - ENDED - 
TIME=08.43.37 
N 0004000 EXPR 23135 08:43:37.31 STC02360 0290  -AXR01ENDED.  NAME- 
TOTAL TCB CPU TIME=.00
S   TOTAL ELAPSED TIME=
.0 
N 400 EXPR 23135 08:43:37.31 STC02360 0281  $HASP395 AXR01ENDED 
- RC= 
N 000 EXPR 23135 08:43:37.31  0290  IEA989I SLIP TRAP 
ID=X33E MATCHED.  JOBNAME=*UNAVAIL, ASID=0076.  
MR000 EXPR 23135 08:43:37.32 FF00768  0090  AXR0203I AXREXX 
INVOCATION OF POCSYSR1 FAILED. 558
DR558 0090  RETCODE=0010 
RSNCODE=0437100B 
DR558 0090  
REQTOKEN=4000DD4CBED05FDE9C00 
ER558 0090  DIAG1= 
DIAG2= DIAG3= DIAG4=   
N 000 EXPR 23135 08:43:37.32  0290  IEF196I 1 
//IEESYSAS JOB TIME=NOLIMIT,
N 000 EXPR 23135 08:43:37.32  0290  IEF196I   // 
MSGLEVEL=1\
   -DSLIST  *SDSF 
N 000 EXPR 23135 08:43:37.32  0290  IEF196I 2 //AXR 
 EXEC IEESYSAS,PROG=AXRINIT
N 000 EXPR 23135 08:43:37.32  0290  IEF196I  STMT NO. 
MESSAGE  
N 000 EXPR 23135 08:43:37.32  0290  IEF196I 2 
IEFC001I PROCEDURE IEESYSAS WAS EXPANDED USING SYSTEM
N 000 EXPR 23135 08:43:37.32  0290  IEF196I LIBRARY 
SYS1.IBM.PROCLIB   
N 000 EXPR 23135 08:43:37.32  0290  IEF196I 3 
XXIEESYSAS PROC PROG=IEFBR14 
N 000 EXPR 23135 08:43:37.32  0290  IEF196I 
  0005 
N 000 EXPR 23135 08:43:37.32  0290  IEF196I 4 
XXIEFPROC  EXEC PGM=&PROG
N 000 EXPR 23135 08:43:37.32  0290  IEF196I 
  0010 
N 000 EXPR 23135 08:43:37.32  0290  IEF196I   XX* 
THE IEESYSAS PROCEDURE IS SPECIFIED IN THE   
N 000 EXPR 23135 08:43:37.32  0290  IEF196I 
  0015 
N 000 EXPR 23135 08:43:37.32  0290  IEF196I   XX* 
PARAMETER LIST TO IEEMB881 BY MVS COMPONENTS 
N 000 EXPR 23135 08:43:37.32  0290  IEF196I 
  0020 
N 000 EXPR 23135 08:43:37.32  0290  IEF196I   XX* 
STARTING FULL FUNCTION SYSTEM ADDRESS SPACES.
N 000 EXPR 23135 08:43:37.32  0290  IEF196I 
  0025 
N 000 EXPR 23135 08:43:37.32  0290  IEF196I   
IEFC653I SUBSTITUTION JCL - PGM=AXRINIT  
N 000 EXPR 23135 08:43:37.32  0090  IEF403I IEESYSAS - 
STARTED - TIME=08.43.37 
N 000 EXPR 23135 08:43:37.32  0290  IEF196I IEFA111I

Re: System Rexx 2

2023-05-15 Thread Itschak Mugzach
Do you miss the closing comment on the first line by intent? it should be
/* rexx */

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Mon, May 15, 2023 at 5:04 PM Peter Ten Eyck <
04d3761a18a7-dmarc-requ...@listserv.ua.edu> wrote:

> Simple exec:
>
> /* REXX
>TRACE A
>SAY 'Welcome to System Rexx'
> exit 0
>
>
> Results:
>
> NC000 EXPR 23135 08:43:37.27 FF00768  0290  F AXR,POCSYSR1
>
> N 020 EXPR 23135 08:43:37.29 STC02360 0281  $HASP100 AXR01
> ON STCINRDR
> N 400 EXPR 23135 08:43:37.30 STC02360 0090  $HASP373 AXR01
> STARTED
> N 000 EXPR 23135 08:43:37.30 STC02360 0090  IEF403I AXR01 -
> STARTED - TIME=08.43.37
> N 0004000 EXPR 23135 08:43:37.31 STC02360 0290  -
> --TIMINGS (MINS.)--
> S -PAGING
> COUNTS
> N 0004000 EXPR 23135 08:43:37.31 STC02360 0290  -STEPNAME
> PROCSTEPRC   EXCP   CONNTCBSRB  CLOCK   SERV
> S   WORKLOAD  PAGE
> SWAP   VIO SWAPS
> N 0004000 EXPR 23135 08:43:37.31 STC02360 0290  -
>  AXRPSTRT00  5  0.00.00 .0 55
> S   STCPROD  0
>  0 0 0
> N 000 EXPR 23135 08:43:37.31 STC02360 0090  IEF404I AXR01 -
> ENDED - TIME=08.43.37
> N 0004000 EXPR 23135 08:43:37.31 STC02360 0290  -AXR01ENDED.
> NAME- TOTAL TCB CPU TIME=.00
> S   TOTAL ELAPSED
> TIME=.0
> N 400 EXPR 23135 08:43:37.31 STC02360 0281  $HASP395 AXR01
> ENDED - RC=
> N 000 EXPR 23135 08:43:37.31  0290  IEA989I SLIP TRAP
> ID=X33E MATCHED.  JOBNAME=*UNAVAIL, ASID=0076.
> MR000 EXPR 23135 08:43:37.32 FF00768  0090  AXR0203I AXREXX
> INVOCATION OF POCSYSR1 FAILED. 558
> DR558 0090  RETCODE=0010
> RSNCODE=0437100B
> DR558 0090
> REQTOKEN=4000DD4CBED05FDE9C00
> ER558 0090  DIAG1=
> DIAG2= DIAG3= DIAG4=
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I 1
> //IEESYSAS JOB TIME=NOLIMIT,
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I
>  // MSGLEVEL=1\
>-DSLIST  *SDSF
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I 2
> //AXR  EXEC IEESYSAS,PROG=AXRINIT
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I  STMT NO.
> MESSAGE
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I 2
> IEFC001I PROCEDURE IEESYSAS WAS EXPANDED USING SYSTEM
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I LIBRARY
> SYS1.IBM.PROCLIB
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I 3
> XXIEESYSAS PROC PROG=IEFBR14
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I
>0005
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I 4
> XXIEFPROC  EXEC PGM=&PROG
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I
>0010
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I
>  XX* THE IEESYSAS PROCEDURE IS SPECIFIED IN THE
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I
>0015
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I
>  XX* PARAMETER LIST TO IEEMB881 BY MVS COMPONENTS
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I
>0020
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I
>  XX* STARTING FULL FUNCTION SYSTEM ADDRESS SPACES.
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I
>0025
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I
>  IEFC653I SUBSTITUTION JCL - PGM=AXRINIT
> N 000 EXPR 23135 08:43:37.32  0090  IEF403I IEESYSAS -
> STARTED - TIME=08.43.37
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I IEFA111I
> IEESYSAS IS USING THE FOLLOWING JOB RELATED SETTINGS:
> N 000 EXPR 23135 08:43:37.32  0290  IEF196I
> SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB
> N 400 EXPR 23135 08:43:37.33  0090  AXR0101I SYSTEM
> REXX (AXR) IS ALREADY ACTIVE
> N 0004000 EXPR 23135 08:43:37.33  0290  -
> --TIMINGS (MINS.)--
> S -PAGING
> COUNTS
> N 0004000 EXPR 23135 08:43:37.33  0290  -STEPNAME
> PROCS

Re: System Rexx 2

2023-05-15 Thread Peter Ten Eyck
Yes, it is there, I missed it on my copy and paste, my bad. Rexx exec does run 
in TSO.

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


Re: System Rexx 2

2023-05-15 Thread Itschak Mugzach
and the dcb of the two libraries under sysrexx is identical? should be vb
255

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Mon, May 15, 2023 at 5:33 PM Peter Ten Eyck <
04d3761a18a7-dmarc-requ...@listserv.ua.edu> wrote:

> Yes, it is there, I missed it on my copy and paste, my bad. Rexx exec does
> run in TSO.
>
> --
> 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: System Rexx 2

2023-05-15 Thread Peter Ten Eyck
Yes.

RESPONSE=EXPR
 AXR0202I SYSREXX REXXLIB DISPLAY 715
 ENTRY VOLUME  DATA SET  
   1   TST001  SYSP.EXPR.SYSREXX 
   2   APRS02  SYS1.SAXREXEC 

Both are:

Organization  . . . : PO 
Record format . . . : VB 
Record length . . . : 255

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


Re: System Rexx 2

2023-05-15 Thread Itschak Mugzach
Interesting. the diag code says 'call IBM' ...

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Mon, May 15, 2023 at 5:45 PM Peter Ten Eyck <
04d3761a18a7-dmarc-requ...@listserv.ua.edu> wrote:

> Yes.
>
> RESPONSE=EXPR
>  AXR0202I SYSREXX REXXLIB DISPLAY 715
>  ENTRY VOLUME  DATA SET
>1   TST001  SYSP.EXPR.SYSREXX
>2   APRS02  SYS1.SAXREXEC
>
> Both are:
>
> Organization  . . . : PO
> Record format . . . : VB
> Record length . . . : 255
>
> --
> 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: System Rexx 2

2023-05-15 Thread ITschak Mugzach
It looks like that your AXRxx member of parmlib does not state the number
of active AXRxx tasks, so AXR01 is started after you enter the command.

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *




On Mon, May 15, 2023 at 5:46 PM Itschak Mugzach 
wrote:

> Interesting. the diag code says 'call IBM' ...
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS,
> zLinux and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*
>
>
>
>
>
> On Mon, May 15, 2023 at 5:45 PM Peter Ten Eyck <
> 04d3761a18a7-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Yes.
>>
>> RESPONSE=EXPR
>>  AXR0202I SYSREXX REXXLIB DISPLAY 715
>>  ENTRY VOLUME  DATA SET
>>1   TST001  SYSP.EXPR.SYSREXX
>>2   APRS02  SYS1.SAXREXEC
>>
>> Both are:
>>
>> Organization  . . . : PO
>> Record format . . . : VB
>> Record length . . . : 255
>>
>> --
>> 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: System Rexx 2

2023-05-15 Thread Peter Ten Eyck
Yes, I have opened a ticket with IBM based on that documented message. 
Scratching my head, a simple Rexx exec, either something is broken, or I have a 
misconfiguration.

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


Re: System Rexx 2

2023-05-15 Thread Steve Smith
"AXR0101I SYSTEM REXX (AXR) IS ALREADY ACTIVE":  It appears that instead of
starting a TSS task, it somehow is trying to start the main task again.

It acts like your AXRNN proc was replaced with the AXRPSTRT proc.

sas

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


how to name a JVM in z/OS

2023-05-15 Thread Szymanski, Patti
Wondering if anyone could provide a clue on how to change the default JVM name 
when submitting batch jobs under USS.



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


Re: System Rexx 2

2023-05-15 Thread Peter Ten Eyck
Thanks Steve, that is the issue. When I was getting things setup for System 
Rexx I mistakenly built the AXRNN proc with the contents of the AXRPSTRT proc, 
my bad. I corrected that, now working. Nice catch, error message did not give 
me much.

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


VBS file read in windows - end of record issue

2023-05-15 Thread Prashant Joshi
I am trying to read VB & VBS binary file in windows using python. I tried 
FTPing file directly, then using Terse and then XMIT but every time when I read 
the file in windows, I get random new line (CR/LF) inserted in record. I am not 
able to read complete record.

For some files, when I transfer using IND$FILE (option 6) using Binary and CRLF 
option checked, I gets record properly. But it does not work for every file. 
And due to different file sizes, IND$FILE may not be option for me.



Need your help to find, what am I missing?


Thanks,
Prashant

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


Re: VBS file read in windows - end of record issue

2023-05-15 Thread Michael Stein
On Mon, May 15, 2023 at 06:54:40PM +, Prashant Joshi wrote:
> I am trying to read VB & VBS binary file in windows using python. I
> tried FTPing file directly, then using Terse and then XMIT but every
> time when I read the file in windows, I get random new line (CR/LF)
> inserted in record. I am not able to read complete record.

Let's see if I understand the problem, here's a summary I see:

You tried 3 transfer mechanisms for the z/OS to your windows machine
(I'm assuming it's from z/OS since this is the mainframe list).

1. FTP -> what options did you use?

2. Terse & XMIT and then ? how did it get to windows?

   What do you have on windows which can process this combination
   of format?

3. IND$FILE which you decided isn't really a candidate due to file sizes.

On the windows machine you are trying to read the resulting file with
python.

Which python: python 2 or python 3?

Did you specify binary mode on the python open call?

The raw VB & VBS files sound relatively easy to read with python by
reading in binary mode and using the BDW/RDW information to separate
the records.  

I'm not sure how you would deal with undoing the XMIT and Terse
on windows once you got an intact file there.

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


Re: VBS file read in windows - end of record issue

2023-05-15 Thread Paul Gilmartin
On Mon, 15 May 2023 18:54:40 +, Prashant Joshi  wrote:
>...
>For some files, when I transfer using IND$FILE (option 6) using Binary and 
>CRLF option checked, I gets record properly. But it does not work for every 
>file. And due to different file sizes, IND$FILE may not be option for me.
>
CRLF should be irrelevant for binary files.


>Need your help to find, what am I missing?
>
Allocate your data set overriding to RECFM=U.  Tne BDWs and SDWs should appear 
ad data.

Transfer the file with a method that preserves those BDWs and SDWs.  (I don't 
recommend
IND$FILE.)

Decode the SDWs and translate to UTF-8  with your Python.

I hate EBCDIC!

-- 
gil

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


Re: VBS file read in windows - end of record issue

2023-05-15 Thread Michael Oujesky

Depend on what you need to do and there at least two levels to be addressed:
   * How variable length records appear on Windows
   * How to deal with SDW (spanned long record segments
If you want  both BDW and RDW/SDW present on Windows at least two approaches:
   * TERSE the file, binary transfer to windows, WWUNTERSE from 
Watson & Walker) on windows (-V option removes BDW)
   * FTP binary transfer from z/OS to Windows using //DD: and JCL to 
force RDCFM=U
Regular FTP binary transfer with "SITE RDW" will give you the file 
with just RDW/SDW (BDW is stripped off).  Without the "SITE RDW", you 
just get the data with no indication of where the record ends).


Then there is the issue of how to re-combine the segments into the 
full record length.


Does that help any?

Michael


At 01:54 PM 5/15/2023, Prashant Joshi wrote:
I am trying to read VB & VBS binary file in windows using python. I 
tried FTPing file directly, then using Terse and then XMIT but every 
time when I read the file in windows, I get random new line (CR/LF) 
inserted in record. I am not able to read complete record.


For some files, when I transfer using IND$FILE (option 6) using 
Binary and CRLF option checked, I gets record properly. But it does 
not work for every file. And due to different file sizes, IND$FILE 
may not be option for me.




Need your help to find, what am I missing?


Thanks,
Prashant

--
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: Listing empty HLQs - LISTCAT?

2023-05-15 Thread Mike Schwab
List datasets with 'HLQ.**'.

On Fri, May 12, 2023 at 10:24 AM Bob Bridges  wrote:
>
> I'm looking at a profile in Top Secret with a bunch of permissions to user
> HLQs that I suspect are no longer around, some of them at least.  I plan to
> write a REXX that'll identify the ones for which there are no datasets, or
> only a TSO alias.
>
> I thought to use LISTCAT for that, but I'm running into a problem.  I don't
> use LISTCAT all that often, but I thought this would work:
>
>   LISTCAT LEVEL(XXX)
>
> That nets me the same message whether or not an alias is present:
>
>   ENTRY XXX. NOT FOUND+
>   ** XXX NOT LISTED
>   LASTCC=4
>   ** VSAM CATALOG RETURN CODE IS 8
>
> But I want to distinguish whether or not there's an alias.  Ok, so I should
> add the ALIAS argument, right?
>
>   LISTCAT LEVEL(XXX) ALIAS
>
> But that gets me the exact same response, whether or not an alias is
> present.  What am I missing, here?
>
> And when I test that command on my own ID - I have both a TSO alias and some
> datasets - the screen blinks and comes back without giving me any response
> at all!  Most strange.  Am I broken?  Is LISTCAT broken?  Surely it's
> something basic I've misunderstood about LISTCAT.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* I know everyone thinks Republicans aren't funny. But if you get a bunch
> of us together, we can be a real riot.  -Nancy Mace at Washington Press Club
> */
>
> --
> 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: VBS file read in windows - end of record issue

2023-05-15 Thread Charles Mills
There are so many layers of issues here ...

If the data is "binary" (any or nearly any byte value is possible) then no 
approach that involves CRLF is going to work. Period. Software does not have a 
way to distinguish between a 0D0A that signifies the end of a record versus a 
0D0A that just happens to appear in the data -- say a halfword of 3338 decimal.

If you preserve the RDW keep in mind that the Z is a "big-endian" machine: 
x'0050' represents decimal 80, but Intel is "little-endian": decimal 80 is 
x'5000'. You will have to account for that in processing the data.

If the records contain decimal packed data there are not many programs in 
Windows that can process packed data.

If there are character fields in the data then they are going to have to be 
translated from EBCDIC to ASCII in order to be generally usable. That's a whole 
topic of its own.

I think without a real good understanding of the record conventions on both 
machines that success is unlikely.

Here is how I have done this

ftp> quote type i
200 Representation type is Image
ftp> quote mode s
200 Data transfer mode is Stream
ftp> quote site rdw
200 SITE command was accepted
ftp> get zos.vfromat.file

Then in my C++ code I read 4 bytes, decode the RDW accounting for the "endian" 
issue, and then read the rest of the record.

Charles

On Mon, 15 May 2023 18:24:12 -0500, Michael Oujesky  
wrote:

>Depend on what you need to do and there at least two levels to be addressed:
>* How variable length records appear on Windows
>* How to deal with SDW (spanned long record segments
>If you want  both BDW and RDW/SDW present on Windows at least two approaches:
>* TERSE the file, binary transfer to windows, WWUNTERSE from
>Watson & Walker) on windows (-V option removes BDW)
>* FTP binary transfer from z/OS to Windows using //DD: and JCL to
>force RDCFM=U
>Regular FTP binary transfer with "SITE RDW" will give you the file
>with just RDW/SDW (BDW is stripped off).  Without the "SITE RDW", you
>just get the data with no indication of where the record ends).
>
>Then there is the issue of how to re-combine the segments into the
>full record length.

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


Re: how to name a JVM in z/OS

2023-05-15 Thread David Crayford
You can do it by using JMX. I would suggest you carefully consider why you want 
to do this!

Check out https://github.com/nickman/jvm-name

> On 15 May 2023, at 11:26 pm, Szymanski, Patti 
> <04d6904bbe52-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Wondering if anyone could provide a clue on how to change the default JVM 
> name when submitting batch jobs under USS.
> 
> 
> 
> --
> 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: VBS file read in windows - end of record issue

2023-05-15 Thread Prashant Joshi
Thank you for your response, Michael,

1. FTP -> what options did you use? -- I use Binary and QUOTE SITE RDW

2. Terse & XMIT and then ? how did it get to windows? -- I used WWUNTERSE 
(>From Watson & Walker) for TERSE and XMIT manager (from CBT tape) for XMIT 

3. IND$FILE which you decided isn't really a candidate due to file sizes. -- 
That's correct

Which python: python 2 or python 3? -- Python 3

Did you specify binary mode on the python open call? -- Yes. And I can read the 
data. Its just that I don't get proper end of record. Hence every time I read 
record, I get random record length (multiple records/half records combined)

Thanks,
Prashant

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Stein
Sent: Tuesday, May 16, 2023 1:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: VBS file read in windows - end of record issue

On Mon, May 15, 2023 at 06:54:40PM +, Prashant Joshi wrote:
> I am trying to read VB & VBS binary file in windows using python. I 
> tried FTPing file directly, then using Terse and then XMIT but every 
> time when I read the file in windows, I get random new line (CR/LF) 
> inserted in record. I am not able to read complete record.

Let's see if I understand the problem, here's a summary I see:

You tried 3 transfer mechanisms for the z/OS to your windows machine (I'm 
assuming it's from z/OS since this is the mainframe list).

1. FTP -> what options did you use?

2. Terse & XMIT and then ? how did it get to windows?

   What do you have on windows which can process this combination
   of format?

3. IND$FILE which you decided isn't really a candidate due to file sizes.

On the windows machine you are trying to read the resulting file with python.

Which python: python 2 or python 3?

Did you specify binary mode on the python open call?

The raw VB & VBS files sound relatively easy to read with python by reading in 
binary mode and using the BDW/RDW information to separate the records.  

I'm not sure how you would deal with undoing the XMIT and Terse on windows once 
you got an intact file there.

--
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: VBS file read in windows - end of record issue

2023-05-15 Thread Prashant Joshi
Thank for your response, Paul.

I agree, CRLF irrelevant to binary files. Surprisingly, only after using CRLF 
option, I get those binary records in proper record length.
I tried to force it to U format but did not work for m. I will try again with 
different methods.

I can preserve RDW and BDW. How to preserve SDW? I did not see mention of SDW 
in these options. May be SDW is the key to maintain record length.

Thank you,
Prashant Joshi
Mainframe Architect
+91 9743 440 503 (Mobile) 


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, May 16, 2023 1:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: VBS file read in windows - end of record issue

On Mon, 15 May 2023 18:54:40 +, Prashant Joshi  wrote:
>...
>For some files, when I transfer using IND$FILE (option 6) using Binary and 
>CRLF option checked, I gets record properly. But it does not work for every 
>file. And due to different file sizes, IND$FILE may not be option for me.
>
CRLF should be irrelevant for binary files.


>Need your help to find, what am I missing?
>
Allocate your data set overriding to RECFM=U.  Tne BDWs and SDWs should appear 
ad data.

Transfer the file with a method that preserves those BDWs and SDWs.  (I don't 
recommend
IND$FILE.)

Decode the SDWs and translate to UTF-8  with your Python.

I hate EBCDIC!

--
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: VBS file read in windows - end of record issue

2023-05-15 Thread Prashant Joshi
Thank you, Michael,

I used WWUNTERSE for my terse file. I am able to get RDW & BDW and also able to 
read data after proper conversion. Problem is when I read file for each record 
(using loop), I get different record lengths for each record, in range of 
single digit to thousands. Seems it adds "new line" randomly in file. I can use 
record length field in RDW to read each records but this random "new line" 
breaks my loop.
I also tried to STRIP (remove additional space from end of record) these 
records to remove "new line" character and converted entire file as one single 
record. Now I get only one record and can use record length field in RDW to 
split file. But then this STRIP option removes some record information as well 
along with "new line" character. Hence it affects my real record length.



Thanks,
Prashant


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Oujesky
Sent: Tuesday, May 16, 2023 4:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: VBS file read in windows - end of record issue

Depend on what you need to do and there at least two levels to be addressed:
* How variable length records appear on Windows
* How to deal with SDW (spanned long record segments If you want  both BDW 
and RDW/SDW present on Windows at least two approaches:
* TERSE the file, binary transfer to windows, WWUNTERSE from Watson & 
Walker) on windows (-V option removes BDW)
* FTP binary transfer from z/OS to Windows using //DD: and JCL to force 
RDCFM=U Regular FTP binary transfer with "SITE RDW" will give you the file with 
just RDW/SDW (BDW is stripped off).  Without the "SITE RDW", you just get the 
data with no indication of where the record ends).

Then there is the issue of how to re-combine the segments into the full record 
length.

Does that help any?

Michael


At 01:54 PM 5/15/2023, Prashant Joshi wrote:
>I am trying to read VB & VBS binary file in windows using python. I 
>tried FTPing file directly, then using Terse and then XMIT but every 
>time when I read the file in windows, I get random new line (CR/LF) 
>inserted in record. I am not able to read complete record.
>
>For some files, when I transfer using IND$FILE (option 6) using Binary 
>and CRLF option checked, I gets record properly. But it does not work 
>for every file. And due to different file sizes, IND$FILE may not be 
>option for me.
>
>
>
>Need your help to find, what am I missing?
>
>
>Thanks,
>Prashant
>
>--
>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: VBS file read in windows - end of record issue

2023-05-15 Thread Prashant Joshi
Thank you for your response, Charles,

I preserve RDW and able to read record length field. I am also able to 
successfully covert EBCDIC to ASCII and Packed to decimal. So there is no issue 
with data conversion. As you correctly point out, intel/windows does not 
understand 0D0A. If it completely ignores 0D0A and treat entire file as single 
record, I am still ok with that as I can read records, based on record length 
field in RDW. My problem is, it adds random line break and so when I read each 
record in loop, it returns me records with record length between 1 to 
thousands. My records are in range of 150 to 250 length.

Thanks,
Prashant 


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Tuesday, May 16, 2023 5:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: VBS file read in windows - end of record issue

There are so many layers of issues here ...

If the data is "binary" (any or nearly any byte value is possible) then no 
approach that involves CRLF is going to work. Period. Software does not have a 
way to distinguish between a 0D0A that signifies the end of a record versus a 
0D0A that just happens to appear in the data -- say a halfword of 3338 decimal.

If you preserve the RDW keep in mind that the Z is a "big-endian" machine: 
x'0050' represents decimal 80, but Intel is "little-endian": decimal 80 is 
x'5000'. You will have to account for that in processing the data.

If the records contain decimal packed data there are not many programs in 
Windows that can process packed data.

If there are character fields in the data then they are going to have to be 
translated from EBCDIC to ASCII in order to be generally usable. That's a whole 
topic of its own.

I think without a real good understanding of the record conventions on both 
machines that success is unlikely.

Here is how I have done this

ftp> quote type i
200 Representation type is Image
ftp> quote mode s
200 Data transfer mode is Stream
ftp> quote site rdw
200 SITE command was accepted
ftp> get zos.vfromat.file

Then in my C++ code I read 4 bytes, decode the RDW accounting for the "endian" 
issue, and then read the rest of the record.

Charles

On Mon, 15 May 2023 18:24:12 -0500, Michael Oujesky  
wrote:

>Depend on what you need to do and there at least two levels to be addressed:
>* How variable length records appear on Windows
>* How to deal with SDW (spanned long record segments If you want  
>both BDW and RDW/SDW present on Windows at least two approaches:
>* TERSE the file, binary transfer to windows, WWUNTERSE from Watson 
>& Walker) on windows (-V option removes BDW)
>* FTP binary transfer from z/OS to Windows using //DD: and JCL to 
>force RDCFM=U Regular FTP binary transfer with "SITE RDW" will give you 
>the file with just RDW/SDW (BDW is stripped off).  Without the "SITE 
>RDW", you just get the data with no indication of where the record 
>ends).
>
>Then there is the issue of how to re-combine the segments into the full 
>record length.

--
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: VBS file read in windows - end of record issue

2023-05-15 Thread Paul Gilmartin
On Tue, 16 May 2023 04:45:32 +, Prashant Joshi  wrote:

>... If it completely ignores 0D0A and treat entire file as single record, 
>
By "ignores 0D0A" do you mean it deletes them, or treats them as ordinary 
characters?


>I... My problem is, it adds random line break and so when I read each 
>record in loop, 
>
What's a "line break"?

I don't know Python, but it might help others if you show your code.

-- 
gil

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


Re: VBS file read in windows - end of record issue

2023-05-15 Thread Michael Stein
On Tue, May 16, 2023 at 04:14:07AM +, Prashant Joshi wrote:
>> Did you specify binary mode on the python open call? -- 

> Yes. And I can read the data.

How are you reading the data.  Assuming an open like:

myfile = open("filename", "rb")

You need to either read it all into memory:

alldata = myfile.read()

or read specific lengths which is messier as you need to read specific
lengths, first 4 bytes for the RDW and then the length of the record
in the RDW-4 (as you already read the RDW).

The 4 byte RDW includes the length of the record in the first 2 bytes
(bigendian order) and the spanning bits in the last 2 bytes.

Either way you need to walk your way through the binary data, any code
looking for CR or NL or space isn't correct.

A description of VBS records formats:

z/OS 2.4 DFSMS Using Data Sets SC23-6855-40
https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc236855/$file/idad400_v2r4.pdf

pdf page 273 Variable-Length Record Formats 
(near bottom of page and continues on to more pages)

> its just that I don't get proper end of reord. Hence every time I
> read record, I get random record length (multiple records/half records
> combined) 

There aren't any "end of records" in a VBS file.  At the begining of
the file you know you are at the start of a RDW (Well, BDW/RDW but I'm
assuming the FTP removed the BDWs).

You can find the next record by going the length specified in the RDW
into the file -- that is the start of the next RDW.  Continue until
you've processed all the records.

More help will likely require you to show some code and/or data so
we can see what is going on...

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