rexx calls to utilities using dd list
for the records:-
/*===*/
/* Rexx - Invoke IEBUPDTE with alternate ddnames.*/
/*===*/
Iebupdte_Utility: Procedure
Call Write_Log "Iebupdte_Utility: start processing"
prog = 'IEBUPDTE'
parm = 'NEW'/* Standard PARM, as from JCL*/
ddlist = Copies('00'x, 8) ||, /* DDname 1 override: SYSLIN*/
Copies('00'x, 8) ||, /* DDname 2 override: n/a */
Copies('00'x, 8) ||, /* DDname 3 override: SYSLMOD */
Copies('00'x, 8) ||, /* DDname 4 override: SYSLIB*/
Left('UPDIN', 8) ||, /* DDname 5 override: SYSIN */
Left('UPDPRT',8) ||, /* DDname 6 override: SYSPRINT */
Copies('00'x, 8) ||, /* DDname 7 override: SYSPUNCH */
Left('INP', 8) ||, /* DDname 8 override: SYSUT1*/
Left('OUT', 8) ||, /* DDname 9 override: SYSUT2*/
Copies('00'x, 8) ||, /* DDname 10 override: SYSUT3*/
Copies('00'x, 8) ||, /* DDname 11 override: SYSUT4*/
Copies('00'x, 8) ||, /* DDname 12 override: SYSTERM */
Copies('00'x, 8) ||, /* DDname 13 override: n/a */
Copies('00'x, 8) /* DDname 14 override: SYSCIN*/
Address 'LINKMVS' prog 'PARM DDLIST'
linkmvs_rc = rc
Call Write_Log "Iebupdte_Utility: end processing. Return code:" linkmvs_rc
Return linkmvs_rc
/*===*/
/* Rexx - Invoke IEHLIST with alternate ddnames.*/
/*===*/
Iehlist_Utility: Procedure
Call Write_Log "Iehlist_Utility: start processing"
prog = 'IEHLIST'
parm = ''
ddlist = Copies('00'x, 8) ||, /* DDname 1 override: SYSLIN*/
Copies('00'x, 8) ||, /* DDname 2 override: n/a */
Copies('00'x, 8) ||, /* DDname 3 override: SYSLMOD */
Copies('00'x, 8) ||, /* DDname 4 override: SYSLIB*/
Left('LSTIN', 8) ||, /* DDname 5 override: SYSIN */
Left('LSTPRT',8) ||, /* DDname 6 override: SYSPRINT */
Copies('00'x, 8) ||, /* DDname 7 override: SYSPUNCH */
Copies('00'x, 8) ||, /* DDname 8 override: SYSUT1*/
Copies('00'x, 8) ||, /* DDname 9 override: SYSUT2*/
Copies('00'x, 8) ||, /* DDname 10 override: SYSUT3*/
Copies('00'x, 8) ||, /* DDname 11 override: SYSUT4*/
Copies('00'x, 8) ||, /* DDname 12 override: SYSTERM */
Copies('00'x, 8) ||, /* DDname 13 override: n/a */
Copies('00'x, 8) /* DDname 14 override: SYSCIN*/
Address 'LINKMVS' prog 'PARM DDLIST'
linkmvs_rc = rc
Call Write_Log "Iehlist_Utility: end processing. Return code:" linkmvs_rc
Return linkmvs_rc
/*===*/
Regards
Bruce
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using a v2.5 load on v2.3
Well, if you us the downlevel macro libraries then you should be fine. If you do something specific to 2.4 or 2.5 then you might have issues. Are the 2.3 and 2.5 systems on the same hardware? From: IBM Mainframe Discussion List on behalf of Bill Giannelli Sent: Saturday, March 25, 2023 5:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: using a v2.5 load on v2.3 I assembled and link/edited a module on a z/OS 2.5 system. Now I want to use or execute that module on a z/OS 2.3 system. Might that cause any issues? thanks Bill -- 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 z/OS Name/Token pair retrieval supported from REXX?
Anything whose parameters you can construct in REXX can be called with ADDRESS LINKPGM, and the STORAGE BIF helps, but for some things you need a supporting function in another language. Writing a REXX-aware routine is fairly straightforward. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NOTE POINT and DCBFDAD
After adding BLOCKTOKENSIZE=SMALL to the DCBE The return from the note worked Thank you > On Mar 25, 2023, at 3:04 PM, Binyamin Dissen > wrote: > > Before using a nuke to kill an ant, I would suggest verifying that the NOTE > is > being issued when you expect it to be issued and that the position is what you > expect. That you issued CHECK. > > Also, what device is the file on? > > On Fri, 24 Mar 2023 11:39:09 -0400 Joseph Reichman > wrote: > > :>For all those that asked why I was BSAM well. The data was not in the order > :>I wanted. >> > :>My Plan was to find what I want and than move it to a dataspce > > :>When I found what I wanted I would mark it with a NOTE (I did have > :>MACRF=RP) however NOTE always returned in R1 X'0100' no matter where I > :>stopped and when I used POINT and did another READ it pointed me to the > :>first record > > :>I am wondering since the POINT (for my BSAM VB) needs a TTR can I convert > :>DCBFDAD to that the comment in DCB says "FULL DISK ADDRESS IN THE FORM OF > :>MBBCCHHR" can I some how get this as input to the Point > > :>I would assume HH is the same as track. I guess I would need to know what > :>type of device I am using as that would tell me how many tracks per cylinder > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A question or two on zOS issues
From Figure 7-1, page 7-21 of SA23-7832-13, z/Architecture Principles of Operations, May, 2022: STORE CLOCK STCK S C ⁸ ⁹ A STORE CLOCK EXTENDED STCKE S C ⁸ ⁹ A Lack of a "P" in the " ⁸ ⁹ A" column of the table indicates instructions are not "privileged". The "⁸ ⁹" notes indicate usage may be restricted during short periods when in Transactional eXecution mode, but that does not preclude their use in non-privileged mode in other contexts. Back in S/370 days, texts on Assembly Programming might give passing mention to the existence of STCK and STCKE, but no guidance on usage, and in my experience they were not considered relevant topics for a semester programming course. With the proliferation of machine instructions since those days just to handle the many new data formats and relative addressing, I would expect the mention of STCK/STCKE in current instructional texts for Assembler Programming to be even less likely. Joel C Ewing On 3/25/23 12:29, Paul Gilmartin wrote: On Fri, 24 Mar 2023 23:35:56 -0500, Joel C. Ewing wrote: ... The STCK and STCKE instructions only provide read-only access to the TOD clock and are not privileged or restricted by hardware, but they are not taught in programming texts either. Citation needed. -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NOTE POINT and DCBFDAD
Before using a nuke to kill an ant, I would suggest verifying that the NOTE is being issued when you expect it to be issued and that the position is what you expect. That you issued CHECK. Also, what device is the file on? On Fri, 24 Mar 2023 11:39:09 -0400 Joseph Reichman wrote: :>For all those that asked why I was BSAM well. The data was not in the order :>I wanted. > :>My Plan was to find what I want and than move it to a dataspce :>When I found what I wanted I would mark it with a NOTE (I did have :>MACRF=RP) however NOTE always returned in R1 X'0100' no matter where I :>stopped and when I used POINT and did another READ it pointed me to the :>first record :>I am wondering since the POINT (for my BSAM VB) needs a TTR can I convert :>DCBFDAD to that the comment in DCB says "FULL DISK ADDRESS IN THE FORM OF :>MBBCCHHR" can I some how get this as input to the Point :>I would assume HH is the same as track. I guess I would need to know what :>type of device I am using as that would tell me how many tracks per cylinder -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A question or two on zOS issues
On Fri, 24 Mar 2023 23:35:56 -0500, Joel C. Ewing wrote: >... The STCK and STCKE instructions only provide >read-only access to the TOD clock and are not privileged or restricted >by hardware, but they are not taught in programming texts either. > Citation needed. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is z/OS Name/Token pair retrieval supported from REXX?
On Sat, 25 Mar 2023 08:27:37 -0700, Ed Jaffe wrote: >On 3/23/2023 12:52 PM, Steve Austin wrote: >> After lurking for on here for years, it's nice to have contributed something >> some found useful. > >Quite useful. Thanks! > Yes. That uses address LINKPGM in a fashion similar to the SAMPLIB example for ICSF. What other system services can similarly be called by LINKPGM? I'd guess any that don't require a parameter containing a pointer to obtained storage because REXX has no pointer type. Such support could be broadened, such as to the SMP/E API by a (user) function interface to STORAGE OBTAIN/RELEASE, accepting the hazard of storage leaks. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is z/OS Name/Token pair retrieval supported from REXX?
On 3/23/2023 12:52 PM, Steve Austin wrote: After lurking for on here for years, it's nice to have contributed something some found useful. Quite useful. Thanks! -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using a v2.5 load on v2.3
I assumed same hardware, different OS level. The answer is, as with most things, is it depends. Are you using any specific 2.5 operating system features/functions. Any LE services, was it link edited with LE, and so on. The best way to be sure is to run the program on a 2.3 system and see what happens. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com --- Original Message --- On Saturday, March 25th, 2023 at 9:31 AM, Mike Schwab wrote: > Archlevel might be too high for target machine. > > On Sat, Mar 25, 2023 at 4:31 AM Bill Giannelli billgianne...@gmail.com wrote: > > > I assembled and link/edited a module on a z/OS 2.5 system. > > Now I want to use or execute that module on a z/OS 2.3 system. > > Might that cause any issues? > > thanks > > Bill > > > > -- > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A question or two on zOS issues
http://www1.cuny.edu/events/fyei/spring_1998/humor.html On Sat, Mar 25, 2023 at 8:16 AM Peter Relson wrote: > > z/OS does not support setting the clock past the end of the first epoch. Some > forthcoming z/OS release will. > Until then it would probably not be a good idea to try to fake out the > system. Things will break. > z/OS does support expiration dates (such as mortgage end, etc) beyond the > first epoch. > > Interfaces are in place to allow you to provide a STCKE-format timestamp, but > that doesn't mean that applications have changed to do so. > > Joel E wrote > > I agree it would be a real rarity for any application code to have any > STCK vs STCKE issues. It would even be rare for ANY installation-written > code to work with TOD values, so much so that any cases would likely be > well known to the Technical Support staff. All application code I ever > saw using a timestamp value used something like the DB2 timestamp > format, not hardware-specific timestamps. > > > I don't think it is rare at all. > > Joel E wrote > > I don't see 2042 being much of a z/OS issue for anyone outside of > IBM, and maybe a few 3rd-party vendors. > > > You might need to reconsider. > > Joel E wrote > > I think the odds are extremely high that if IBM verifies there are no 2042 > issues in z/OS or in their other products that run on z/OS, that > individual installations will not have any issues with their z/OS > applications. > > > I on the other hand think the odds are extremely low. But it does primarily > come down to whether they use STCK/STCKF vs STCKE or interfaces that under > the covers use them. > > Gil wrote > > But most systems I use admirably do not allow non-privileged users to access > the hardware clock. > > > If by access you mean "write", sure. But I think this discussion is about > "read". > You cannot prevent non-privileged users from reading the clock whether by > STCK, STCKF, or STCKE. > > > > Many use cases within z/OS will continue to use STCK/STCKF for compatibility > reasons, providing a windowing approach that works for 71-ish years at a clip > (or maybe it's 142-ish years at a clip). For example, the windowing will > treat a STCK value with 0 in the high bit not as being between 1900 and 1971 > (the first half of the first epoch) but rather as being between 2042 and 2113 > (approximately) (the first half of the second epoch). And yes that means that > you might well not be able to reliably use data with timestamps that is older > than that (think SMF records). And come back in another 71 years and a STCK > value with 1 in the high bit will not be treated as between 1971 and 2042 but > rather 2113 and 2184 (approximately). > > Other use cases will change (or have changed) to use STCKE (which will can > cover dates well past the YK problem that no one here is going to spend > resources worrying about). > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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: using a v2.5 load on v2.3
Archlevel might be too high for target machine. On Sat, Mar 25, 2023 at 4:31 AM Bill Giannelli wrote: > > I assembled and link/edited a module on a z/OS 2.5 system. > Now I want to use or execute that module on a z/OS 2.3 system. > Might that cause any issues? > thanks > Bill > > -- > 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: A question or two on zOS issues
z/OS does not support setting the clock past the end of the first epoch. Some forthcoming z/OS release will. Until then it would probably not be a good idea to try to fake out the system. Things will break. z/OS does support expiration dates (such as mortgage end, etc) beyond the first epoch. Interfaces are in place to allow you to provide a STCKE-format timestamp, but that doesn't mean that applications have changed to do so. Joel E wrote I agree it would be a real rarity for any application code to have any STCK vs STCKE issues. It would even be rare for ANY installation-written code to work with TOD values, so much so that any cases would likely be well known to the Technical Support staff. All application code I ever saw using a timestamp value used something like the DB2 timestamp format, not hardware-specific timestamps. I don't think it is rare at all. Joel E wrote I don't see 2042 being much of a z/OS issue for anyone outside of IBM, and maybe a few 3rd-party vendors. You might need to reconsider. Joel E wrote I think the odds are extremely high that if IBM verifies there are no 2042 issues in z/OS or in their other products that run on z/OS, that individual installations will not have any issues with their z/OS applications. I on the other hand think the odds are extremely low. But it does primarily come down to whether they use STCK/STCKF vs STCKE or interfaces that under the covers use them. Gil wrote But most systems I use admirably do not allow non-privileged users to access the hardware clock. If by access you mean "write", sure. But I think this discussion is about "read". You cannot prevent non-privileged users from reading the clock whether by STCK, STCKF, or STCKE. Many use cases within z/OS will continue to use STCK/STCKF for compatibility reasons, providing a windowing approach that works for 71-ish years at a clip (or maybe it's 142-ish years at a clip). For example, the windowing will treat a STCK value with 0 in the high bit not as being between 1900 and 1971 (the first half of the first epoch) but rather as being between 2042 and 2113 (approximately) (the first half of the second epoch). And yes that means that you might well not be able to reliably use data with timestamps that is older than that (think SMF records). And come back in another 71 years and a STCK value with 1 in the high bit will not be treated as between 1971 and 2042 but rather 2113 and 2184 (approximately). Other use cases will change (or have changed) to use STCKE (which will can cover dates well past the YK problem that no one here is going to spend resources worrying about). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS v2.05 and v2.5
On our systems, I am seeing, "under z/OS V2.03", on the initial TSO screen. thanks Bill On Sat, 25 Mar 2023 12:32:39 +, Peter Relson wrote: >Could someone point out where they have seen "z/OS v2.05"? > >These are the things that I know to be the same: >z/OS 2.5 >z/OS v2r5 >z/OS 02.05.00 > >z/OS v2.5 would be the same but I don't think is an intended use. > >Peter Relson >z/OS Core Technology Design > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how to find the assembly or link edit date of a load module
If you browse a load module (not a program object) in hex, an early record (record 3 in some simple cases) has information such as Ø..5695PMB01 ^ 810DDCFF4002020035 05256957420102538F130F Where "23082F" is the julian yyddd date in packed decimal format, and "0103305F" is the time 0hhmmss in packed decimal format when the bind occurred. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS v2.05 and v2.5
Could someone point out where they have seen "z/OS v2.05"? These are the things that I know to be the same: z/OS 2.5 z/OS v2r5 z/OS 02.05.00 z/OS v2.5 would be the same but I don't think is an intended use. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
using a v2.5 load on v2.3
I assembled and link/edited a module on a z/OS 2.5 system. Now I want to use or execute that module on a z/OS 2.3 system. Might that cause any issues? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
