Re: Each alias belongs which storage group
In the Interactive Storage Management Facility (ISMF) option in ISPF; you can use option 1 (dataset) and enter a storage group in the selection panel. This will list all the datasets within that storage group and give you a reasonable idea if what datasets (naming conventions) are going to what storage groups. Those datasets may have aliases that point to particular catalogs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Each alias belongs which storage group
...it has been awhile since I have played around with SMS ACS routines. I do not recall assigning an aliases to a storage groups? Dataset names and wild carding yes, but not aliases. Is this done? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Each alias belongs which storage group
Yes, that is how I recall it, not alias in the catalog sense, really a "wildcard" of a DSN if you will. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Programs in the PPT on z/OS 2.2
How does a program get added to the PPT? For example in SYS1.PARMLIB(SCHED**) has numerous programs are added to the PPT at say IPL time, but the console command D PPT display many more? Is there a default table of PPT programs? Other than looking at a SCHED** member, how would I determine which programs are in the PPT via a SCHED** member and which are in the PPT through some other means? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Programs in the PPT on z/OS 2.2
Yes, thanks. I just noticed that there is a "Default Values" section to the D PPT command output; so it looks like the command displays both default and SCHEDXX. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
USS mount history
What are some of the ways I could see the mount history of a given USS dataset? - Syslog messages - SMF records - ? Note: z/OS 2.2 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS mount history
Yes. I was also exploring the idea that if some of the USS paths and files that are contained within the mounted dataset were known; based on the access of those, it may be possible to indirectly deduce when a mount may have occurred. I was curious if there was any other means or additional information about USS mounts outside of the syslog or SMF records? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS mount history
...I found something helpful, not a mount history, but at least the last mount of a given dataset. Console command: D OMVS,FILE (gives date and time of last mount). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zowe?
I am still struggling with this question myself. The best I can tell; it is intended to be a framework or set of standards to access existing z/OS APIs (IBM z/OSMF) or create new APIs to access existing z/OS functionality, all done in a web browser; perhaps extending existing z/OS functionally. Currently I am thinking; same stuff, modern interface. Still learning… -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How to find what performed an OMVS unmount?
I have an OMVS dataset that was mounted via a batch job on a z/OS 2.2 LPAR:
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
PROF MSGID WTPMSG
MOUNT FILESYSTEM('CICSTS53.CICS.ESA1.HFS.FF') +
MODE(RDWR) TYPE(ZFS) NOAUTOMOVE +
MOUNTPOINT('/usr/lpp/cicsts53')
This job was run after the CICS region was already up and is used for CICS TS
5.3 web services. The web services were dynamically installed from this
successfully mounted dataset and worked fine.
Sometime over night the dataset (file) became un-mounted. How can I determine
what un-mounted the file? I do not see anything in the syslog or the CICS log.
Can I use SMF to determine this, what record type would be used?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to find what performed an OMVS unmount?
Thanks. I am researching what software I have available to work with those records. I am wondering if I can use MXG to go against those type 92 records and find what performed the un-mount. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to find what performed an OMVS unmount?
Yes, I tried using the zSecure product going against the SMF data for the time period, looking for activity against the mount point or the USS dataset name and did not find any RACF type records for the event. That is what makes me think if there is an answer to be found, it may be in the type 92 records. The only tool I think I have to do this in MXG. I am not very proficient with that tool; it’s going to take me awhile to figure out how to generate a report of all the mount and un-mounts in USS for a specific period of time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to find what performed an OMVS unmount?
Thanks for the suggestion on this topic. I have discovered that the LPAR that this un-mount occurred on does not cut type 92 (USS) records so I will be unable to use them to figure what un-mounted my file. Setting: SYS(NOTYPE(16:19,62:69,92) With the help of MXG staff, I was able to run a MXG report looking for type 80 (RACF) sub type 55 records, I did not find any. To me this means that either there were no un-mounts during the time period of the input or no sub type 55 records are cut. Is the above setting what controls the sub type records cut? Type 80 is not excluded so it’s being cut, is the default all 80 sub types? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to find what performed an OMVS unmount?
Thanks, that is an interesting SMF product using Java. We do not currently have that product, we have MXG. I went to you website and browsed a bit, the product looks powerful. Because we are licensed for MXG, I am really in a situation where I need to utilize it to the fullest to maximize our investment. Thanks for the information and recommendation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to find what performed an OMVS unmount?
Thanks for setting me straight on the difference between sub type and event code in the context of RACF. I will look into if there is a RACF unload for that time period and perhaps check with MXG about the handling of event codes as opposed to sub types. You mentioned RACF auditing options that would control which RACF event codes are cut? Where is that controlled? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SCLM build problem
We have a programmer getting this in their SCLM build job: FLM44500 - >> INVOKING BUILD TRANSLATOR(S) FOR TYPE: CCDEFMEMBER: CRPX8006 FLM06501 - TRANSLATOR RETURN CODE FROM ===> ALLOC CCMPLIST ===> 0 FLM06501 - TRANSLATOR RETURN CODE FROM ===> ALLOC LISTING===> 0 FLM06501 - TRANSLATOR RETURN CODE FROM ===> COBOL BATCH - EC ===> 802816 FLM06503 - PROBABLE SYSTEM/USER ABEND FOR TRANSLATOR: COBOL BATCH - EC HEXADECIMAL VALUE OF RETURN CODE: 000C4000 I am not seeing any other meaningful messages in the job. Where do I look up what this message means? Software Configuration and Library Manager (SCLM) Guide and Reference? Note: Running on z/OS 2.2 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCLM build problem
Thank you for your responses. We are now thinking that a problem in the Xpediter step is the root cause of that SCLM message. The building of Xpediter DDIO entries are part of our SCLM build jobs. We do not think we have an SCLM issue at this time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Program now working, but why?
We have an OS/VS COBOL program that calls an assembler program that runs fine in production (z/OS 2.2). We brought down the COBOL program to development and compiled the program using Enterprise COBOL 4.2. The compile output and link output look good, no concerning messages. I ran an AMBLIST on both the production and the newly created development load modules and they are identical in the "M O D U L E S U M M A R Y" report. The program gets a SOC4 (in the called assembler program) when run at the development level and runs fine at the production level, the only change is the compile. The programmer added code to bypass the header record on the first file read, now it runs at the development level. Scratching my head why... did not see anything in the migration guide that explained it to me. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Program now working, but why?
I have been looking at the dump capture in Abend-Aid. Is the assembler routine LE Compliant of Compatible? Not sure how to tell. Based on the assemble date (12 MAY 1989) I will say no. Does it use the CEE macros to establish the LE environment? No When was it last assembled? 12 MAY 1989 What does the summary dump look like? Is it S0C4-04? Just SOC4 according to Abend-Aid Abend-Aid suggestions: - Reference to a data area of a closed or unopened file. (Locate mode) - Reference to freemained or freepooled storage. - Corrupted base register. - Incorrect or missing USING or DROP statement. - Incorrect use of a branching instruction. (B, BC, BAL, BALR, BCT, BCTR, BASR, BASSM, etc.) Example: B R14 instead of: BRR14 - Failure to supply a SAVEAREA for a subprogram or supervisor service which requires one. - Reference to a JFCB using TIOEJFCB. (Look for an odd JFCB address). - Attempting to access storage above the 16m line when running amode 24. Is it an authorized program running in an unauthorized library? No -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Program now working, but why?
Yes, that is what I thought initial also, but I compiled and linked the program so that the load module is the same in that respect and confirmed with an AMBLIST on each module. The thing that got the program running was that coding change to bypass the header record on the file (not pass it to the assembler program on the call). Does not make sense to me… -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Program now working, but why?
The production assembler program is AM 24 and RM 24. The production COBOL program is AM 24 and RM 24. (runs, calls assembler program) The development COBOL program is AM ANY and RM 24. (does not run (SOC4 in assembler program), does run with mentioned coding change, calls assembler program) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Program now working, but why?
Good morning, great feedback overnight. I am going to go back to the beginning, reproduce the successful run and error run myself. Not that I do not trust the programmer, but I need to be sure of the order of events and the changes made. I will report back my findings. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Program now working, but why?
Job TNCA1300 runs three times on the same LPAR with the same data and id. Run 1 – production COBOL program, calls production assembler program, runs successfully. Bring production COBOL program into a development PDS and compile program without changes. Run 2- development program, calls production assembler program, fails with SOC4 in assembler program. Add these two lines of code to COBOL program to bypass header record on input dataset: IF WS-NA-RECORDS-READ EQUAL 1 GO TO 1200-READ-MASTER. Compile COBOL program with change. Compile output messages identical to first compile. Run 3 – development COBOL program (changed), calls production assembler program, runs successfully. Note: No overrides or changes to AMODE, RMODE or DATA during the test. Using the shops default compile and link settings. Program moves from the FD to WORKING-STORAGE before the call to the assembler program for all “input” parameters. I am missing something here; I do not see why this code would resolve the SOC4. Or has mentioned, missing something else… the unknown unknowns -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Program now working, but why?
Sorry not much help here, I do not know assembler. Here is the code snippet shown in Abend-Aid for the SOC4: 0072 47F0C0AC B 172(,R12) 0076 92404000 MVI 0(R4),X'40' 007A 47F0C0AC B 172(,R12) 007E 92004000 MVI 0(R4),X'00' NSI==> 0082 47F0C0AC B 172(,R12) 0086 1884 LR R8,R4 0088 5B80C178 S R8,376(,R12) 008C D20040008000 MVC 0(1,R4),0(R8) 0092 47F0C0AC B 172(,R12) Note: NSI is next sequential instruction. At this point I am thinking the coding change is required due a difference in how the COBOL compilers work. I was attempting to identify what that difference may be or find something in the migration guide that highlighted it. I do not want to take up more of other's time. Thank you for all the input and suggestions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Question about question
Where is the best place to post a question about REXX and SDSF coding and usage? I have some code that I have written and it’s not working "correctly". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about question
Yes, I saw that while searching around. The "mainframe" area did not appear to have much recent activity... My question/issue relates to REXX and SDSF. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
REXX and SDSF question
I have some rexx code that is working on one z/OS 2.2 LPAR and "partially" on another. The code determines if a CICS region is running and if the desired messages are found in the DD JESMSGLG. This code chunk is what goes out gets the SDSF output: CHECKCICSSTATUS: ADDRESS TSO "ALLOC F(FILEOUT) UNIT(VIO) NEW REUSE", "CYLINDERS SPACE(10 10) RECFM(F B A)" "ALLOC FI(ISFOUT) DUMMY" "ALLOC F(ISFIN) UNIT(VIO) NEW REUSE", "RECFM(F B) BLK(3120) LRECL(80)", "SPACE(5 5) CYLINDERS DSORG(PS)" QUEUE " DA ALL" QUEUE " OWNER" QUEUE " SYSNAME ESA1" QUEUE " PRE " CICSREGION QUEUE " FIND " CICSREGION QUEUE " ++?" QUEUE " FIND JESMSGLG" QUEUE " ++S" QUEUE " PRINT FILE FILEOUT" QUEUE " PRINT" QUEUE " PRINT CLOSE" QUEUE "" "EXECIO * DISKW ISFIN (FINIS" ADDRESS ISPEXEC "SELECT PGM(SDSF)" ADDRESS TSO "EXECIO * DISKR FILEOUT (STEM REC. FINIS" "FREE FI(ISFIN ISFOUT FILEOUT)" It returns all the output records in a stem variable REC. REC.0 contains the total number of records and REC.1 - REC.? contains each record. This works fine on one LPAR and works for something's (possibly just jobs) on another LPAR, but not STCs. Does anyone have a suggestion why I am not able to retrieve the output for STCs on one of the LPARs? Scratching my head... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about question
Thanks, question posted. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX and SDSF question
Yes, I have manually entered the SDSF commands for the STCs not working... and they work (output retrieved). I think that takes care of SDSF and RACF. The REXX exec runs under my id. I did see a difference with the WHO command...COMM=NOTAVAIL as opposed to COMM=ENABLED. Recall that this REXX exec is working for CICS regions that are running as jobs, but not for CICS regions running as STCs. It works for CICS regions running as STCs on another LPAR. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX and SDSF question
This is how it was coded in my starting example code from the Redbook. I changed it to your suggestion, no change, still not getting the output. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX and SDSF question
Yes, I have tried that, no change. Recall that this REXX exec is working on the LPAR for CICS regions running as jobs and the commands do work manually. I must be missing something... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX and SDSF question
I have found the issue. STC output is displayed differently (DDs displayed) on this LPAR when viewing it through SDSF launched via the ISPF menu option; compared to SDSF launched via TSO command line. I do not know why, researching. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX and SDSF question
This is now working for me. I added the SDSF command input on to see all DDs via TSO SDSF and ISPF SDSF: CHECKCICSSTATUS: ADDRESS TSO "ALLOC F(FILEOUT) UNIT(VIO) NEW REUSE", "CYLINDERS SPACE(10 10) RECFM(F B A)" "ALLOC FI(ISFOUT) SYSOUT(Q)" "ALLOC F(ISFIN) UNIT(VIO) NEW REUSE", "RECFM(F B) BLK(3120) LRECL(80)", "SPACE(5 5) CYLINDERS DSORG(PS)" QUEUE " DA ALL" QUEUE " OWNER *" QUEUE " SYSNAME ESA1" QUEUE " INPUT ON" QUEUE " PRE " CICSREGION QUEUE " FIND " CICSREGION QUEUE " ++?" QUEUE " FIND JESMSGLG" QUEUE " ++S" QUEUE " PRINT FILE FILEOUT" QUEUE " PRINT" QUEUE " PRINT CLOSE" QUEUE "" "EXECIO * DISKW ISFIN (FINIS" ADDRESS ISPEXEC "SELECT PGM(SDSF)" Thanks for all the suggestions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX and SDSF question
Yes, that API does sound nice. This is the technique documented in the Redbook for REXX and SDSF, which was the starting point for my REXX script. Thanks for the tip. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX and SDSF question (expanded API question)
Can someone point me to some documentation (coding examples) on how to use the SDSF API in REXX? I have my REXX/SDSF exec working, but it runs slow issuing those commands. I would like to try a different approach. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX and SDSF question (expanded API question)
Thanks, this will be a good starting point for me. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Utilization
This sounds like something that could be done with a product like BMC Mainview for z/OS or ASG TMON for z/OS (or other). I think alerts can be set for CPU usage in these products. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Spool Data Set Browse (SDSB) sample
I have written some REXX to inventory all running jobs and STCs on a given LPAR and search for certain messages in the JESMSGLG DD for each job/STC. This Redbook provided helpful examples: Implementing REXX Support in SDSF. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Ask the experts about running things
For an inquisitive programmer... what is a good definition for each of the following? How do they relate to each other? Address space Data space Subsystem Started task Job TSU (TSO) Process Enclave Note: My explanation will fall short of what IBM-Main can come up with. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ask the experts about running things
Thanks for the links and some of the definitions provided, I will pass this information along to the programmer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Deleting a dataset that GRS has enqueued.
A question about deleting a dataset that GRS (z/OS 1.13) has enqueued. We have two LPARs in a sysplex, each with their own catalog structure. There is a dataset named the same and cataloged in each LPAR on two different volumes. I would like to delete the dataset in one of the LPARs, but the name is in use by the other LPAR and enqueued by GRS. Any suggestions of how to delete the dataset in the LPAR (and on the volume) that is not being used? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
Yes. The owner (in use) of the dataset is known. GRS has an enq on that dataset name. I am trying to delete "that dataset name" in a different LPAR on a different volume. I am wondering if there is a way to "notify” GRS that it is OK to let me delete this "version" of the dataset. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
Good info thanks. Sadly the dataset is SMS managed. So reading the documentation you provided, it does not seem like that will work. Scratching head still.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
Yes, this is good. I will try that. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
We took the easy way out and brought down the two STCs that had the SMS dataset enqueued, then deleted the version of the dataset that was not being used. It was mentioned in this thread that GRS could have been modified to change the scope of the enqueue on the LPAR that the dataset was not being used on by making it local. Therefore no longer considered in use by GRS. I did not try this, but wonder if this was done for a dataset that was already enqueued if this would work... thoughts? I never found or saw mention a straight forward IBM supported way to delete or rename a SMS dataset in this situation. If someone comes across a way please post I am curious. Thanks for the help. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Catalog VVDS confusion
In z/OS 1.13 we have "usable" dataset (currently used by a CICS region) that has its VVDS entry pointing to a different user catalog than the one related to by its master catalog alias. This is not correct. Under what circumstances is this a problem? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog VVDS confusion
I was unable to find an exact answer to my question, but I found a number of references that in general suggest possible lurking problems. Introduction to Catalogs in manual z/OS DFSMS Managing Catalogs: "To successfully perform all possible operations on a cataloged data set using the catalog, all three elements, the VVDS, BCS, and VTOC, must be synchronized." Analyzing a Catalog for Synchronization Errors in manual z/OS DFSMS Managing Catalogs: "Catalog entries might become unsynchronized, so that information about the attributes and characteristics of a data set are different in the BCS, VVDS, and VTOC. These differences may make a data set inaccessible or otherwise unusable." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Default translation table
Does anyone know why an ftp job would be using the default translation table TCPIP.STANDARD.TCPXLBIN when DATASETPREFIX SYS1.TCPIP is specified in the TCPIP and RESOLVER parms? Note: z/OS 1.13 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Default translation table
Does anyone know why an ftp would be using the default translation table TCPIP.STANDARD.TCPXLBIN when DATASETPREFIX SYS1.TCPIP is specified in the TCPIP and RESOLVER parms? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Custom LE runtime parms for an entire batch job
How would I run a batch job (all steps) with a unique set of LE runtime parms without using CEEOPTS in each step? Could I point to a custom CEEDOPT via JOBLIB? Note: OS - z/OS 1.13 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
Yes, thanks. I was hoping reference CEEROPT in a batch job(s) by placing it in a PDS within the JOBLIB concatenation. Can I do this? ...or do I need to add a DD name to the JCL? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
Hmm, that's I what I thought. Does not seem to be picking up my LE changes? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
I have assembled CEEROPT into a PDS that is in the JOBLIB statement of the job. I have a small program running in the job that abends... when I look in the LE dump for the job at the current LE runtime settings, I do not see my changes (overrides). For example here is the report from the job… ALL31 should have been changed to on: Run-Time Options Report: LAST WHERE SET OPTION --- Installation default ABPERC(NONE) Installation default ABTERMENC(ABEND) PARMLIB(CEEPRM00) NOAIXBLD PARMLIB(CEEPRM00)ALL31(OFF) PARMLIB(CEEPRM00)ANYHEAP(32768,16384,ANYWHERE,FREE) Installation default NOAUTOTASK PARMLIB(CEEPRM00)BELOWHEAP(32768,16384,FREE) Installation default CBLOPTS(ON) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
I was able to get this working by issuing the SETCEE CEEROPT,ALL command. Now finding my custom CEEWROPT table within the JOBLIB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Determine the PDS a job was submitted from?
Does anyone have suggestions on how to determine the PDS a job was submitted from? In this case the ZEKE scheduler was used. I would interested in comments with and without scheduler. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Determine the PDS a job was submitted from?
Yes... I recall some discussion awhile back with the consensus being a “likely no”. I wanted to make sure I was not missing something. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Identify VS COBOL II compiled with NORES
We are upgrading to COBOL 5.2 and need to identify VS COBOL II compiled with NORES within our load libraries. Is there a string that I can scan for to identify these programs? I am already identifying OS/VS COBOL programs by scanning for the compiler eye-catcher: 5740CB103 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Identify VS COBOL II compiled with NORES
I will check it out, thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Identify VS COBOL II compiled with NORES
Kudos to Roland Schiradin author of CBT file 321. Program worked nicely and help me identify load modules to review for our COBOL 5.2 migration. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Read a PDS (all members) like PS dataset
Any suggestions on how to read though a PDS (all members) like PS dataset. Example, read via a program the trough a PDS finding every called or linked program statement without regard to PDS member name. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Read a PDS (all members) like PS dataset
For my purposes, IEBPTPCH should work fine. Anyway to work directly with the PDS? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMF type 89 records reporting RMF usage
Can anyone think of how a SMF type 89 record reporting RMF usage would be generated without running the RMF STC? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF type 89 records reporting RMF usage
Our SCRT reporting for IBM showed type 89 records that indicted that RMF was used. We do not run RMF, we run CMF. I am looking back at syslogs and SMF data; I am trying to determine what caused that (RMF usage) type 89 record to get cut. It does not appear that the RMF STC was started… wondering what else could be the cause. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF type 89 records reporting RMF usage
After some research... I am starting to think this might be the case. It appears we had RMF enabled in IFAPRD00, but were not running it. We are running CMF. Can a SMF type 89 record indicating RMF use be cut under these circumstances? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JVMSHRC336E Port layer error code = -308
Can someone point me in the direction within the IBM doc. for this message (the meaning of 308): JVMSHRC336E Port layer error code = -308 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JVMSHRC336E Port layer error code = -308
Thanks, I will kind that in mind...still looking for the documented meaning of 308. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JVMSHRC336E Port layer error code = -308
oops, I mean keep in mind -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JVMSHRC336E Port layer error code = -308
/tmp/javasharedresources is currently empty in my case... Here is the full error I get when trying to run the script (with -Xmx95M): FF00768:/cics/cmweb: >/usr/lpp/cicsts/cicsts41/lib/wsdl/DFHWS2L2 Running a modified z/OS proc and USS script, executed programs remains ws2ls CLASSPATH: /usr/lpp/cicsts/cicsts41/lib/wsdl/:xsd.jar:xsd.resources.jar:common.jar:common.resources.jar:ecore.change.jar:ecore.jar:w sdl4j.jar:XmlSchema.jar:woden.jar:dfjwsdl.jar:../dfjcdmn.jar:../bundle/dfjbundle.jar PATH: /usr/lpp/java/J6.0/bin:/bin:/usr/lpp/internet/bin:/usr/lpp/java/J5.0/bin:/usr/lpp/etldapv3:/usr/lpp/db2/db2910/db2910_jdbc/lib java version "1.6.0" Java(TM) SE Runtime Environment (build pmz3160sr9fp1-20110303_01(SR9 FP1)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 z/OS s390-31 jvmmz3160sr9-20110203_74623 (JIT enabled, AOT enabled) J9VM - 20110203_074623 JIT - r9_20101028_17488ifx3 GC - 20101027_AA) JCL - 20110203_01 Running /usr/lpp/cicsts/cicsts41/lib/wsdl/DFHWS2L2... JVMSHRC022E Error creating shared memory region JVMSHRC336E Port layer error code = -308 JVMSHRC337E Platform error message: EDC5129I No such file or directory. JVMSHRC320E Error recovery: destroying shared memory semaphores. JVMJ9VM015W Initialization error for library j9jit24(11): cannot initialize JIT JVMDUMP006I Processing dump event "abort", detail "" - please wait. JVMDUMP013I Processed dump event "abort", detail "". Here is the full error I get when trying to run the script (with -Xmx105M): FF00768:/cics/cmweb: >/usr/lpp/cicsts/cicsts41/lib/wsdl/DFHWS2L2 Running a modified z/OS proc and USS script, executed programs remains ws2ls CLASSPATH: /usr/lpp/cicsts/cicsts41/lib/wsdl/:xsd.jar:xsd.resources.jar:common.jar:common.resources.jar:ecore.change.jar:ecore.jar:w sdl4j.jar:XmlSchema.jar:woden.jar:dfjwsdl.jar:../dfjcdmn.jar:../bundle/dfjbundle.jar PATH: /usr/lpp/java/J6.0/bin:/bin:/usr/lpp/internet/bin:/usr/lpp/java/J5.0/bin:/usr/lpp/etldapv3:/usr/lpp/db2/db2910/db2910_jdbc/lib java version "1.6.0" Java(TM) SE Runtime Environment (build pmz3160sr9fp1-20110303_01(SR9 FP1)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 z/OS s390-31 jvmmz3160sr9-20110203_74623 (JIT enabled, AOT enabled) J9VM - 20110203_074623 JIT - r9_20101028_17488ifx3 GC - 20101027_AA) JCL - 20110203_01 Running /usr/lpp/cicsts/cicsts41/lib/wsdl/DFHWS2L2... JVMJ9VM015W Initialization error for library j9gc24(2): Failed to instantiate heap; 105M requested Could not create the Java virtual machine.
Re: JVMSHRC336E Port layer error code = -308
I never was able to find in the doc. a definition of what a 308 is. I had a feeling it was related to insufficient storage available. I continued to bump up the -Xmx parameter on the java statement until I got it to run (-Xmx195M). The first dev LPAR I tried this on was not setup to allow that much storage (not sure all the settings that control this), I tried on another dev LPAR that appears to be more generous and it ran. Still feel that JVMSHRC336E Port layer error code = -308 must be documented somewhere. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RACF sysplex communication
How do I tell if a given LPAR has RACF sysplex communication enabled? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF sysplex communication
Thanks. Got this message on in one plex: MEMBER IS SYSPLEX COMMUNICATIONS ENABLED & IN NON-DATA SHARING MODE. ICH15020I RVARY COMMAND HAS FINISHED PROCESSING. Did not get the message in two other plexs... thanks again. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SOC1 and SYSUDUMP and CEEDUMP
I have a COBOL program that is getting a SOC1 and produces a dump when the SYSUDUMP DD is code in the failing step. If CEEDUMP is coded instead of SYSUDUMP no dump is produced. This program is complied with the same COBOL parameters and run in the same LE environment as other COBOL programs which do produce a dump when using the CEEDUMP DD. Is there something about SOC1 abends that would cause the issues with CEEDUMP? What am I missing here? Note: z/OS 1.13 IBM ENTERPRISE COBOL FOR Z/OS 4.2.0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
LE runtime is TERMTHDACT(UADUMP,,96) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
Thanks for the good feedback. I had the programmer use the SYSUDUMP DD for this program... which did produce a SOC1 dump. This dump was sent to Abend-Aid and the programmer was able to make a correction to the code and get the program running cleanly. I still do not know what it is about that program that would not produce a CEEDUMP. As mentioned in my previous post, the identical compile and LE runtime will produce a CEEDUMP for other failing programs. I wrote a simple COBOL program (divide by zero… S0CB) to prove this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Batch cycle JCL standard... CEEDUMP or SYSUDUMP
Batch cycle JCL standard... CEEDUMP or SYSUDUMP. I think that if the LE runtime is running as TERMTHDACT(UADUMP,,96) an LE dump will be produced if a CEEDUMP DD is coded or not. But if you do not code the SYSUDUMP DD you will not get a dump is some cases were LE cannot produce one.. correct? What is a best practice standard practice for batch cycle JCL? Always code SYSUDUMP? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch cycle JCL standard... CEEDUMP or SYSUDUMP
My concern is that if CEEDUMP is coded instead of SYSUDUMP, that in certain cases (we just had a SOC1 like this) no dump is produced. The LE environment was not able to produce a dump. What about old COBOL programs or Assembler programs when using CEEDUMP? It would seem that coding SYSUDUMP in the JCL and running LE with something like TERMTHDACT(UADUMP,,96) would be the way to go. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
LPAR IPL order within a Sysplex
What things are built in a Sysplex by the first LPAR brought up in the Sysplex that would impact subsequent LPARs brought up in the Sysplex? Some possible examples... WLM, GRS, SMS etc. I am asking this question to elevate the need to maintain/preserve LPAR IPL order in a Sysplex and identify how a change in order could cause trouble. Note: All Sysplex LPARs running z/OS 1.13 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR IPL order within a Sysplex
This book has been suggested: SG24-2079-01 IBM z/OS Parallel Sysplex Operational Scenarios It has an excellent chapter (chapter 3) on IPL order. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR IPL order within a Sysplex
Thanks for the feedback. That Redbook I mentioned was able to answer most of my questions. We will be enforcing an IPL order for our Sysplex, in particular the first LPAR that is brought up. This will be done to ensure the structures built in the coupling facility will always be built by a particular LPAR. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR IPL order within a Sysplex
Yes… my understanding from the documentation is that the CF structures once built will remain intact for the duration of CF LPAR run. Not sure about the “disposition of delete” comment… I would have look into that. These LPARs are not in a Parallel Sysplex. We have an existing Sysplex with two larger LPARs and are adding a new smaller LPAR. The concern is/was that if the new LPAR came up first… say on POR, that something in the CF could be built differently and cause problems. As a precaution an IPL order procedure was put in place. We are using the same set of CDS datasets for all LPARs and have reviewed the GRSRNL member, but thought it was a good idea to insure the Sysplex gets built via the same LPAR as it has in the past. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR IPL order within a Sysplex
Sorry for the confusion... these LPARs are in a Parallel Sysplex (using CF), but not utilizing many of the Parallel Sysplex features. Reading through the documentation... I guess it might fall under the description of "BronzePlex". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Missing sections in CEEDUMP
Does anyone know what controls sections that appear in a CEEDUMP (COBOL batch)? We are no longer seeing the "WORKING-STORAGE" section of a CEEDUMP. I am thinking this is controlled (maybe) by LE options, but have had no luck finding it. Any suggestions? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing sections in CEEDUMP
Running IBM ENTERPRISE COBOL FOR Z/OS 4.2.0 on z/OS 1.13. Was working (working-storage appeared in dump) under z/OS 1.11, now it does not. That is what has me looking at a possible change in the LE runtime options betwwen releases. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing sections in CEEDUMP
Found it. TERMTHDACT defaulting to TRACE. Issued SETCEE CEEDOPT,TERMTHDACT=((UADUMP,,96),OVR), tested and appears to be working. Thanks Steve for pointing me in the right direction. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
tcpip reserved ports
Does anyone know how identify a tcpip port that has been reserved, meaning a port that has been specified in the tcpip profile. The STC assigned to the port is not currently running, I was looking to see if there was a command or something that would show me tcpip reserved ports. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: tcpip reserved ports
Ah! That did the trick. I was playing around with the D,TCPIP,TCIP,... command and could not find what I needed, thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
HEALTH CHECKER (USS_FILESYS_CONFIG)
Struggling to get HEALTH CHECKER check USS_FILESYS_CONFIG to a state of ACTIVE(ENABLED) on z/OS 2.4. Currently ACTIVE(DISABLED). Trying commands like: F HZSPROC,ADDREPLACE,CHECK=(IBMUSS,USS_HFS_DETECTED),USS=YES Is there a command to do this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HEALTH CHECKER (USS_FILESYS_CONFIG)
Sorry, did not included the error message: F HZSPROC,ADDREPLACE,CHECK=(IBMUSS,USS_HFS_DETECTED),USS=YES ASA101I SYNTAX ERROR: WAS SEEN, WHERE ONE OF 826 (CHECKROUTINE DATE EXEC INTERVAL REASON SEVERITY) WOULD BE CORRECT. DETECTING MODULE IS HZSIPMX -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HEALTH CHECKER (USS_FILESYS_CONFIG)
Not sure I follow? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HEALTH CHECKER (USS_FILESYS_CONFIG)
I have check with status (USS NOT AVAIL). I believe that needs to be cleared up before I can enable and run it... NAMECheckOwner State Status USS_HFS_DETECTEDIBMUSS ACTIVE(DISABLED) USS NOT AVAIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HEALTH CHECKER (USS_FILESYS_CONFIG)
Thanks for the posts. The fix was a RACF change to permit the id that Health Checker is running under access to BPX.SUPERUSER in the FACILITY class. The USS health checks are now running. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
GTF trace for a JCL error?
Under z/OS 2.4. I have a STC when started, fails with the following error in the SYSLOG: IEE132I START COMMAND DEVICE ALLOCATION ERROR Looking at the STC output in JES, there is a JCL error in the proc (dataset not found). Is there a way to "see" the JCL error without looking at the JES output? I have been researching and running a GTF trace with no success "seeing" the JCL error, not sure what GTF trace options to turn on or if it is possible to see that JCL error via a GTF trace. Is it possible to see that JCL error in a GTF trace, if so, what options (parms) do I need to run with? Note: We had an issue with VTAM not coming up on a LPAR and we were unable to access JES to see the JCL error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GTF trace for a JCL error?
Thanks for the tip, in this case, S ,sub=MSTR works. As in, writes the IEFA107I JCL error to the console. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GTF trace for a JCL error?
Dave, It was VTAM that would not come up due to a JCL error. We could not sign on to that LPAR and access JES. I was researching if I could see the JCL error via a GTF trace. Sounding like I will not be able to do that. In this case, starting the VTAM STC again with S , SUB=MSTR would write the JCL error to the console. The issue has been resolved, just researching what other methods I could have used… -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AUTOMOVE for root
On z/OS 2.4...
Our USS root is defined in BPXPRMxx (see below) as AUTOMOVE and no SYSLIST.
When the owner LPAR is shutdown, is there any algorithm or logic to determine
what LPAR will be given ownership?
ROOT FILESYSTEM('OMVS.SYSPLEX.ROOT')
AUTOMOVE
Unable to find a clear answer reading through:
https://www.ibm.com/docs/en/SSLTBW_2.4.0/pdf/bpxb200_v2r4.pdf
Just reading blurbs like "Moves the file system to any system"
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AUTOMOVE for root
Found in z/OS 2.4 File System Administration For zFS read/write sysplex-aware file systems, zFS takes responsibility for determining how to access the data. This means that zFS must have the concept of a file system owner to coordinate file requests. That system is the zFS owner. z/OS UNIX has its indication of owner, which is called the z/OS UNIX owner. The zFS owner is independent of the z/OS UNIX owner. The zFS owner is the system that coordinates file access. The z/OS UNIX owner generally does not have any performance implications when zFS runs sysplex-aware because file requests are sent to the local zFS rather than being function shipped to the z/OS UNIX owner. There are some cases when the z/OS UNIX owner is relevant (see “When is the z/OS UNIX owner important?” on page 51). In Figure 11 on page 50, SY2 is the z/OS UNIX owner and the zFS owner. This is typically the case for the system where the mount was issued. If SY2 goes down, a new zFS owner is chosen randomly (such as SY3) and a new z/OS UNIX owner is chosen randomly (such as SY1) assuming it was mounted with AUTOMOVE. Figure 11 on page 50 shows the situation after SY2 has come back up. (zFS on SY1 communicates directly with zFS on SY3.) The fact that SY1 is the z/OS UNIX owner is not important for performance in this case. For zFS non-sysplex aware file systems, the z/OS UNIX owner and the zFS owner are always the same system. ...sounds like the ownership transfer is random. -- 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
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
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
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
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
