SAS data libraries are not always cross-environment compatible -- you will want/need to read the companion documentation for the details; it has to do with EBCDIC and ASCII conversion. You can't expect to just zip-up a mainframe SAS data library, transport it in binary to another different OS platform, unzip it and expect to be able to read / process the data library as-is. Your ZIP documentation is not considering that this is an "application database" format, not a sequential file. I believe you are reading too much into the statement, as well -- I believe it means that a "zip archive" can be moved to another OS platform, unzipped and used there. Scott Barry SBBWorks, Inc. ... View more

It would be more useful to post your SAS-generated log with your 'executed code' revealed, rather than just the program statements itself -- the info posted is useful to a point. First off, the line below would normally generate a SAS ERROR (rather than generating some warnings or curious SAS notes): array ress[4] r1-r4; do i = 1 to 4; ress = 0; end; Here's the error: ERROR: Illegal reference to the array RESS. There is no reason to have the assignment statement for "RESS" -- the DO loop is not needed. Also, SAS numeric variables cannot be operated on when they have a missing value condition in some conditions -- your IF / THEN ; statement needs to be revised to use the SUM(R1,1); construct, as one example. Scott Barry SBBWorks, Inc. ... View more

Your SAS file will need to be converted go CEDA-format. Then it can be "moved" to another OS platform, as required. Check the SAS companion documentation for creating a "transport format" file which then can be zipped, then FTP'd to a foreign-host, all in one z/OS MVS batch jobstream. Scott Barry SBBWorks, Inc. move sas data different os site:sas.com transport format ceda site:sas.com ... View more

You will need to share info about your JCL with specific reference (allocation type: DASD, tape, otherwise?) - also, suggest reviewing allocation messages output and any JES log output diagnostics as well. Need more information. Has the SAS batch program/code/JCL worked before? Operating environment change? Scott Barry SBBWorks, Inc. ... View more

Not exactly true, the RUN; statement's position is key to the compilation processing sequence. By the way, my post mentioned INTERCEPT21 (as a SAS variable in WORK.DATA) and it should mention INTERCEPT. Of course, the OP mentions the SAS file has the variables resolved / identified as argument #2 to the CALL SYMPUT invocation. So, the key issue here is MACRO VARIABLE SCOPE -- that being either LOCAL or GLOBAL. And with the CALL SYMPUT being generated from within the macro itself, and not having a %GLOBAL definition, as mentioned by art297, these SAS macro variables will only be accessible / resolved from within the macro execution itself and not in open-code. By having the RUN; statement coded, SAS stops to compile the DATA step and then continues. So, had the OP coded the statement below, the macro variable INTERCEPT21 would be resolved as a local macro variable: %put &&intercept&stat_id ; Scott Barry SBBWorks, Inc. Suggested Google advanced search argument, this topic / post: MACRO VARIABLE SCOPE site:sas.com ... View more

With a SAS assignment you would use the PUT( ,best. -l) to tell SAS to convert a numeric variable to a character-formatted string (left-justified operand "-l" if needed). Scott Barry SBBWorks, Inc. Message was edited by: sbb ... View more

SAS has an AGE statement used with PROC DATASETS. You would input a WORK.filename0 (or something like that for consistency), then when finished processing, then SORT or whatever to copy out to your permanent SAS data library keeping the same member-name, and then use AGE to allow SAS to cycle up each of the file-names. Scott Barry SBBWorks, Inc. Suggested Google advanced search argument, this topic / post: proc datasets age site:sas.com ... View more

To the OP: are you stating that you have either a SAS database file (or an external file) with numeric values which you want to translate into related verbiage that conveys their "x to the power of y" in a report or some other type of output-display representation? It would be most helpful to demonstrate your interest/objective with this post by sending a post-reply with both INPUT and OUTPUT data representations that you would like to see as if it were in a SAS database file and variable situation. Of course, some additional info about how you intend to use this information would be a curious bit of extra-credit work on your part, especially given the attention gained with your intial post and how it was worded. Scott Barry SBBWorks, Inc. Message was edited by: sbb ... View more

What you are wanting to use is "macro variable" resolution within your DATA step. So, you want the SYMGET function within your DATA step and concatenate the character "Y" with the "input character variable YEAR_END. Scott Barry SBBWorks, Inc. Suggested Google advanced search argument, this topic / post: data step programming symget function site:sas.com Message was edited by: sbb ... View more

As has been suggested previously on this forum channel, suggest you start out first with a working SAS program to confirm the basic logic and code required (DATA, PROC steps, and within them any SAS functions needed). Then, based on what component(s) of your code is expected to be "variable", then consider leveraging the benefits of the SAS macro facility to create an suitable process that offers desired flexibility that's needed to suit our data filtering and analysis requirements. There are multiple approaches and SAS facilities to consider using, what with PROC SQL, PROC SORT, DATA step (using MERGE with a BY), and associated SAS functions like DAY( ). Especially considering that you are not familiar with SAS macro coding (as stated in your post), it's best to define the logic/process flow, then come back to the forum for additional guidance with evolving the code-piece into a macro, as required. Scott Barry SBBWorks, Inc. ... View more

Marius makes a very observant point that I overlooked. The OP has input data with a "blank delimiter", however the first data-field also "appears" to have embedded blanks, creating an "input logic" challenge. Given the prior post from Marius, I would submit that PROC IMPORT will not work. Also, with an HTML-formatted post for the OP, it's really impossible to interpret just how the external data file is formatted, either with "two or more blanks" separating each field, or a non-printable delimiter character, or ideally a fixed-format (column-controlled) data-file layout. To the question posed, if the input data is a fixed-format layout, where input fields occupy specific a column (or column range), the INPUT statement and the INFORMAT specification will be sufficient, such as $CHAR15. yields a SAS CHARACTER variable, length 15. Scott Barry SBBWorks, Inc. Additional suggested Google advanced search argument, this topic / post: data step programming input statement external file site:sas.com ... View more

Consider using OVERLAY, possibly also "subgroup", and assign unique SAS variable(s) in a DATA step to plot as needed based on your SAS input file conditions. Scott Barry SBBWorks, Inc. Suggested Google advanced search argument, this topic / post: gplot subgroup overlay join data points site:sas.com ... View more

The specific event reflected in answer "a" would only be relevant to action taken with an other INPUT statement (as coded in your SAS program). So that action would need to either have or not have the appropriate "@" or "@@" (or neither) coded to determine how the current input record buffer condition is changed by SAS -- it would not happen automatically, as in the case a single "@" and iterating to the top of a DATA step execution. Scott Barry SBBWorks, Inc. ... View more

If I understand correctly, you want to "input the data" from an external file (you list) using SAS. You have a few options, depending on what control you want to have, as follows for your review/decision: 1) PROC IMPORT 2) DATA step programming logic using an INFILE and INPUT statements. And, with option #1 above, SAS will generate the DATA step for you based on the external input data-field content. Scott Barry SBBWorks, Inc. Suggested Google advanced search arguments, this topic / post: proc import site:sas.com proc import txt file site:sas.com input external data site:sas.com data step programming site:sas.com ... View more

You need to add an explicit OUTPUT statement inside your DO/END loop. Scott Barry SBBWorks, Inc. Suggested Google advanced search argument, this topic / post: data step do loop output site:sas.com ... View more