mainframe sas 8.2 dataset creation

[deleted_user]

I apologize if this is a stupid question. I am accustomed to using PC SAS but in current job, I use mainframe sas.

I have a very long program that creates a sas dataset on which I want to do analysis. From my understanding, when you create a dataset in mainframe sas, it is only active while you are running analysis in the same code file in which you put the dataset together.

Thus, I want to take the dataset I've created and spit it out so that it is an actual mainframe sas dataset sitting in my FA list allowing me to do the analysis without having to run the entire dataset creation first.

Surely there is a simple way to do this, but I have searched and not found anything on this subject.

Any help is greatly appreciated.
cormans

[sbb]

When you mention "mainframe SAS", is that a TSO (interactive) session or a submitted (batch) jobstream?

Suggest you review the SAS companion documentation for z/OS (IBM mainframe) and the LIBNAME usage where you code DISP=(NEW,CATLG) along with other UNIT= and SPACE= parameters, possibly. The OPTIONS ERRORABEND setting has an important use/factor here for your consideration.

And if you are running SAS mainframe batch jobs, you may consider using JCL DD statements to allocate your permanent SAS data library outside the SAS environment.

Again, the LIBNAME statement with mainframe-related keywords will ensure that you have a permanent allocation for your SAS data library on SAS z/OS MVS (also previously called OS/390).

Also, you really need to get up to a "supported" SAS version, such as SAS 9.1.3 SP4 or SAS 9.2 phase 2.

Scott Barry
SBBWorks, Inc.

[deleted_user]

Well, honestly, I am not sure about the TSO versus batch although my guess is TSO.

I had no clue you could create libraries in mainframe sas. No one I work with uses the options you mentioned. I'll have to search for that companion documentation.

We are moving to PC SAS in July or August. So, I really just want to learn quick ways to get things done in this current SAS environment.

A coworker suggested I do a full proc print, send it to my FA list and then edit the file to create the sas dataset... but now as I think about that, I wonder how one changes a sas program file into a sas dataset file. meh.

thanks for your help.
cormans

[sbb]

Regarding SAS environment differences (PC vs mainframe), suggest you seek technical assistance and guidance with colleagues who do use the IBM mainframe environment. And if you are unsure about whether it's done with TSO versus batch, honestly, that's pretty fundamental -- so are you helping someone else or doing the function/work-task yourself?

For my education, what is "FA list"?

Also, it's unclear what you mean by the statement: "...I wonder how one changes a sas program file into a sas dataset file."?? What

And, if you are moving to SAS PC, it's likely that you will have SAS environment "objects" -- to start, consider: SAS data libraries, FORMAT/FORMATC, INFORMAT, possibly various meta-data catalogs, stored views which need special attention to re-create them in the target OS environment, possibly mainframe-specific application specifications, some of which may need to be re-architected for the new OS platform. You may have SAS application (ODS code) that makes use of mainframe-specific output generation, such as HTML and graphic-images which need attention as well. Also your SAS application backup strategy will need serious review and revision, in my experience.

So, if you are migrating your current SAS mainframe environment to SAS PC, you need to consider the topic about migrating a different OS platform -- you will want to make use of the SAS support http://support.sas.com/ website as well as these SAS forum archives.

Scott Barry
SBBWorks, Inc.

[deleted_user]

sbb,

I believe the FA is an in-house naming convention because some ppl that have worked here for over 20 yrs have files on drives A and B. Thus FA would be the list of files on drive A.

TSO vs batch may very well be a fundamental piece of knowledge. However, it is not something that has come up in conversation with my boss. I am learning to run/write sas programs from examples of previous files given to me. The majority of the datafiles I work with require an infile statement such as

infile F0011 VSAM FILE=FILEEND ;

and then the typicla input statement with column locations of variables being brought in.

So, this would actually suggest batch files, yes? There is other code I've never seen before. I can import a dataset from excel and have to use the cards ; statement above the dataset. We also use 'bits' here which I have not and hope I do not have to mess with since we are migrating so soon.

Specifically with respect to moving to PC SAS, it has been suggested that what I will be doing is exporting our data files and then importing them into PC SAS. However, some of these files are compressed by IT and I have not been able to get an actually look at these data files to understand how they are compressed. It is going to be a difficult process, I suspect, with much trial and error.

Including myself, there are only 5 SAS users on campus. My boss is the only one that really knows the mainframe SAS system well and is often too busy to explain some things to me. This is why I am asking here.

No one here uses libraries. So, I need to dig deeper into the data we have and consider much of what you've brought up as well as much more, I am sure. I believe a lot of the sas programs will have to be rewritten or heavily edited to accomodate PC SAS ie creation of libraries, creating the formats etc for data we use frequently etc etc. All of this is more complicated by the fact that the college is moving from a mainframe student information system to Datatel's Colleague around the same time we'll be moving to PC SAS.

I have much work ahead of me, I know, but for now I just need to find the easiest way to create a permanent sas dataset. So...

sbb and flip, I will give the library code a shot. One of the many frustrations with this software is that only one person can run a sas program at a time and they take forever to run. So, it may be a while before I get back to you about whether your suggestions worked.

I appreciate your help,
cormans

[sbb]

The VSAM file-structure on the IBM mainframe is neither specific to batch or TSO. The distinction with TSO/batch is similar to SAS PC where you can have an interactive SAS PC session or you can initiate a SAS batch request to run, however it is in your PC environment - with mainframe batch the job-execution occurs outside of your TSO session environment altogether.

Also, you mentioned: "...frustration with this software is that only one person can run a sas program."

Are you referencing your SAS environment on the PC (with remote access to a SAS sever on another machine) or are you referring to SAS on the mainframe? With SAS (on TSO), yes, you have a single-thread (mostly) program execution environment. But if a SAS batch jobstream is submitted, there is a job-scheduling (JES) subsystem which controls/threads your batch job executions and it is typically possible to have more than one executing at a time as long as those job-names are unique and also that there is no library/file conflicts present with your own files and others as well.

For your SAS migration strategy, I would encourage you to inventory all SAS-related environment components (code, data libraries, SAS sequential datasets which may reside on mainframe tape, SAS catalogs, any required external files considering both output and input types, batch job/task scheduling flow criteria, end-user interaction possibly needed to supply external data-points) -- with this information documented, establish a business-priority and migration-ranking (separate notations) assessment for each attribute/component.

Oh, don't forget the learning-curve consideration for individuals' expected to move their SAS interactions from the mainframe to the PC.

And if mission-critical, consider the overall Disaster/Recovery strategy impact with such a OS platform migration.

These are some key considerations to help make the overall transition and migration project a roaring success or a failure.

And do take necessary action to get mgmt involvement at all levels with signature concurrence on any business-process impact you may encounter.

I've seen these types of "emotional" decisions in the past when mgmt makes an attempt to "get off the mainframe", and it tends to reflect poorly on the individuals in the trenches rather than the managers, unless sufficient CYA is applied.

Scott Barry
SBBWorks, Inc.

[deleted_user]

Have mercy... As I am not a SAS programmer, but a user, I am sure I am in over my head here. Nevertheless, I will forge on.

I am referring to SAS on the mainframe. We are able to schedule jobs ahead of time to run at future dates i.e. I have one job set to run every sunday night at 6pm through the end of the current semester. Those types of jobs just sit in the schedule list until they are executed.

If any one of us 5 users wants to run a sas job during work hours, we can only do is if another sas job is not already running. I can edit a sas program while that same program is running as there is some sort of separation once the job has been executed, but neither I nor anyone else can actually execute/run a sas job while my program is running. It shows as 'RUNNING' in the schedule list and there can only be one with that status at a time.

And as I said, no one here uses libraries. So there are no permanent datasets. Every dataset must be reread in before data manipulation, subsetting, merging analysis can be done.

Thank you for the migration strategy suggestions. I will print this out and begin investigation and documentation asap.

Ironically, my boss just sent out some info she just received from SAS regarding the PC product we'll be purchasing and what support is available for it.

No clue about the disaster/recovery strategy. I'll have to ask the boss about that.

I'm with you on the CYA. Moving from mainframe sas to pc sas and mainframe SIS to Colleague at the same time is already causing many many headaches with the promise of many more to come. I will be asking for a direct SAS lifeline for the migration prep and process. We'll see if I get it.

thanks,
trench veteran

[Flip]

Cormans;
You have my sympathy. And welcome to the 1980s. I have not seen a setup like that since 1984.

[Flip]

The basics of creating a permanent SAS dataset are the same on PC and mainframe.
You need a libname statement, that you must figure out on your own system depending on the OS and the file structure. Then use a 2 level name

data LIBNAME.DATASET;