Shall we write work file into X-array variables? we have a variable declared in dynamic and expand those arrays in run time and write into work file but getting a nat error NAT6256 " X-arrays cannot specified in this context.
sample code
1 #name (A20/*)
expand array #name to (1:5)
write into work file 1 #name(1:5)
or
for #i 1 to 5
write into work file 1 variable #name(#i)
end-for
Hi
I’m not sure where you get the error, but tried to make an example based on yours
It’s for windows, so you will probably have to change the Define Work File to fit your env.
and with a few extra details it works - but not really related to X-arrays???
Finn
define data local
1 #name (A20/*)
1 #I (I4)
end-define
DEFINE WORK file 1 ‘c:\temp\x’ TYPE ‘ASCII’
expand array #name to (1:5)
move ‘xyz’ to #name(1:5)
write work file 1 variable #name(1:5)
*
for #i 1 to 5
write work file 1 variable #name(#i)
end-for
END
Thanks for your response, we were using Natural windows, we have used Define work file type as ‘CSV’. we received the error at the run time NAT6256. After changing the type from CSV to ASCII its working fine. Thanks for your help, Finn. So, we cannot write into work file for type CSV for X arrays is it correct?
CSV is a format for what you put into your file. It is not a type.
For Windows it is a file-extension, that is used to determine which programs is suitable for using the file. You can still put all kind of data in a CSV file, but then Excel or other programs will not be very happy.
Submit a ticket to SAG to find out whether the NAT6256 is a run-time bug. If you can write X-array entries to an ASCII file, why not to CSV? By specifying a specific number of array entries, isn’t this logically the same as a standard array?
Replace the X-array with a standard array. If the number of entries is growing over time, test for 90% usage and send a warning to the programmers for the array to be increased. In my experience, programmers use X-arrays because they want the experience, not because they can justify the overhead incurred by EXPAND ARRAY.
If you truly can justify the use of an X-array, use the mainframe technique of writing a CSV-compatible file. Here is an example. (USR2011N is needed only for a program which reads the CSV.)
DEFINE DATA LOCAL
1 #X (A5/1:*)
1 #RECORD (A100)
1 #Q (A1) INIT <'"'>
1 #D (A1) INIT <','>
1 #C (I4)
1 #I (I4)
1 USR2011
2 FUNCTION (A1) INIT <"S">
2 WORK-NUM (I1) INIT <01>
2 WORK-FILE (A253) INIT <'C:\Users\Ralph\rgz.csv'>
2 WORK-TYPE (A1) INIT <"B">
2 MAX-NUM (I1)
2 RESPONSE (I4)
2 EXTENDED-DATA (A1/1) INIT <H'00'>
2 WORK-ATTRIBUTES (A1000) INIT <"KEEP">
2 WORK-CODEPAGE (A64)
2 WORK-PROPERTIES (A1000) INIT <"SEPARATOR-COMMA">
END-DEFINE
OPTIONS TQMARK=OFF
ASSIGN #Q = '"'
OPTIONS TQMARK=ON
DEFINE WORK FILE 01 USR2011.WORK-FILE TYPE "ASCII-COMPRESSED" /* ATTRIBUTES "KEEP"
EXPAND ARRAY #X TO (1:50)
MOVE ALL '1' TO #X (1) UNTIL 1
MOVE ALL '3' TO #X (3) UNTIL 3
MOVE ALL '5' TO #X (5) UNTIL 5
ASSIGN #C = 5 /* determine # used entries
*
FOR #I = 1 #C
COMPRESS #RECORD
#Q #X (#I) #Q #D
INTO #RECORD LEAVING NO SPACE
END-FOR
WRITE WORK 01 VARIABLE #RECORD
PRINT '=' #RECORD
SKIP 1
CLOSE WORK FILE 01
*
RESET #X (*)
DEFINE WORK FILE 01 USR2011.WORK-FILE TYPE "CSV"
CALLNAT "USR2011N" USR2011
READ WORK 01 #X (1:#C)
DISPLAY #X (1:#C)
END-WORK
END
Thanks, Ralph, for providing the multiple options. we have used ASCII instead of CSV. I will try above logic as well. sure, I will a raise ticket to SAG for runtime NAT6256 error.