Service request number: 53570 082 000 Title: IBM REXX and USS SYSCALL routines (Results) Status: Open Product: z/OS Version 2 Release 3~5650ZOS ~230 Component: z/OS UNIX System Services Kernel and File System [5695SCPX1] [7B0] Agreement: 4541122 [United States] Contact: Roger Suhr Severity: 4 System is down: No Request type: Software Usage Support Operating system: z/OS Customer tracking ID: Service request update history STATE OF INDIANA Update 7/9/19 2:36 PM *** Electronic submission by customer via SR tool, version 3.4.16d *** Preferred contact method: Email-address. . Problem Details . Product or Service: z/OS UNIX System Services (USS) Shell and Utilities including XVFB Component ID: 5695SCPX2 . Operating System: z/OS . Problem title IBM REXX and USS SYSCALL routines (Results) . Problem description and business impact Hello, I'm trying to write REXX programs accessing the directory and file information using SYSCALL routines (readdir, gmtime, etc) The routines offer stem variables containing the file attributes: ST_SIZE File size for a regular file, in bytes. If file size exceeds 2^31-1 bytes, size is expressed in megabytes, using an M (for example, 3123M). 66 z/OS Using REXX and z/OS UNIX System Services So I interpret this that if I fine st_size is equal to 5828M, I need to compute 5828 * (1024 *1024) to get the real file size. But when I compare my result with ISFP I find different results: 1 3 6111100928 2019-07-01-19:46:17 2019-07-09-14:39:01 /opt/smpnts/ORD00081-01July2019-15.38.14.634/SMPPTFIN/S0001.SHOPZ. S5668895.SMPMCS.pax.Z 1 3 1387008 2019-07-01-19:46:16 2019-07-01-19:46:16 /opt/smpnts/ORD00081-01July2019-15.38.14.634/SMPHOLD/S0002.SHOPZ. S5668895.SMPHOLD.pax.Z 1 3 824527872 2019-07-01-13:07:12 2019-07-01-13:07:17 /opt/smpnts/ORD00078-01July2019-09.06.09.114/SMPPTFIN/S0001.SHOPZ. S5668394.SMPMCS.pax.Z 1 3 1387008 2019-07-01-13:07:11 2019-07-01-13:07:12 /opt/smpnts/ORD00078-01July2019-09.06.09.114/SMPHOLD/S0002.SHOPZ. S5668394.SMPHOLD.pax.Z 1 3 824527872 2019-07-01-18:03:04 2019-07-01-18:03:08 /opt/smpnts/ORD00079-01July2019-14.01.58.976/SMPPTFIN/S0001.SHOPZ. S5668819.SMPMCS.pax.Z 1 3 1387008 2019-07-01-18:03:04 2019-07-01-18:03:04 /opt/smpnts/ORD00079-01July2019-14.01.58.976/SMPHOLD/S0002.SHOPZ. S5668819.SMPHOLD.pax.Z XXXCLEAN 2019-07-09 13:50:06 Directory_count = 45 ISDPROD z/OS UNIX File Information Command ===> Pathname . . : /opt/smpnts/ORD00081-01July2019-15.38.14.634 /SMPPTFIN/S0 + General Data Mode Fields File Type . . : File Permissions . : 775 File Size . . : 6111221760 Set User ID . : NO Links . . . . : 1 Set Group ID : NO Inode . . . . : 68 Sticky Bit . : NO File Format . : ---- Last Modified : 2019-07-01 15:46:49 Extended Attributes Last Changed : 2019-07-09 13:58:49 Shared AS . . : YES Last Accessed : 2019-07-09 13:58:27 APF Auth . . : NO Created . . . : 2019-07-01 15:46:17 Pgm Control . : NO CCSID . . . . : Shared Lib . : NO Text Convert : NO Audit Owner Auditor . . . : --- File . . . . : BPXROOT(0) User . . . . : fff Group . . . . : SFRGROUP (101) Device Data Device Number : 37 Major Device : Minor Device : Why? Where di I go wrong, or which number is correct? Thank you Roger . *** --- FOR SR USE ONLY --- *** XRQXSRprNode2691562696839815 *** CAG19 ENG Y *** MTS *** 5650ZOS:230/5695SCPX2:7B0 (ENT) IBM Update 7/9/19 4:15 PM changing CompID to Unix System Servies - 5695SCPX1 - per DaveG. IBM Update 7/9/19 5:49 PM Hello Roger, I see that your main question here is how to retrieve the correct size for very big files that are not shown exactly via "st_size". See the following example for explanation. I created a big file of size 3123M+5 and use an interactive REXX routine named "rexx" from within a z/OS UNIX shell... $> rexx SH> numeric digits 10 SH> "pwd" /u/hering/test SH> "ls -l bigfile" -rw------- 1 HERING SYS1 3274702853 Jul 9 17:08 bigfile SH> s "stat bigfile st." OMVS Return Value (retval) = 0 SH> say st.st_size 3123M SH> say 3123*1024*1024 3274702848 SH> say Stream("bigfile","c","size") 3274702853 SH> exit $> -------------------------- Comments and statements... -------------------------- - For such big file sizes, using "stat" and "st.st_size" does not give you a precise size value unfortunately as you see in comparison with the "ls -l" output that includes the exact value. - However, from USS you can instead use the z/OS UNIX REXX function "stream" to get the exact value. So, if you hit such a value like 3123M use the "stream" function instead as shown in the example sequence. Action taken: Suggested to use Stream() for files with such a big size value from a z/OS UNIX REXX routine. Action plan : Waiting for feedback and/or further comments or questions. Kind regards, Robert Hering (z/OS UNIX and zFS support) IBM Update 7/10/19 3:06 AM IBM Z will be moving to a new Support site to replace the IBM Service Request Tool. Click http://ibm.biz/Zsupport STATE OF INDIANA Update 7/10/19 8:43 AM *** Electronic submission by customer via SR tool, version 3.4.16d *** Preferred contact method: Email-address. . Additional comments Hi Robert, Thank you for the quick response. I appreciate your efforts. I will certainly try the stream() function to obtain the correct file size. Just a question: Since you admit that there is a discrepancy between the ST_SIZE variable and the "real" file size, wouldn't that be a case for an APAR to fix this discrepancy? Thank you Roger . IBM Update 7/10/19 10:10 AM Hello Roger, unfortunately this is not a hit for an APAR to fix this discrepancy. It clearly works as designed and as described. The decision had been taken when creating the all the initial set of REXX syscall commands. For simplicity the decision was taken just to handle a value on a single word length. The real length of this data is a double word. You can see that in the z/OS UNIX Assembler documentation, for example, at ... https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/ com.ibm.zos.v2r3.bpxb100/elst.htm and especially ... https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/ com.ibm.zos.v2r3.bpxb100/ystat.htm So, you would need to open an RFE to address this request. However, it could get complex to change this as needed. Action taken: Explained why this is not a defect and will not get changed via APAR and PTF. Action plan : Waiting for feedback or further questions again... Kind regards, Robert Hering (z/OS UNIX and zFS support)