Exspans Systems Inc Logo home
 
Forum
Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 1 of 2      1   2   Next
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #1 
Recently a situation has arisen that a user needs to allocate and write to a dataset to collect status information in response to system messages. A user suggested adding ALLOC, WRITE and DEALLOC statements to GAL so that REXX is not needed to record status to the file. I would like to solicit opinions on the addition of file handling statements to the language, and the form they should take.
0
Zamin

Avatar / Picture

Member
Registered:
Posts: 67
Reply with quote  #2 
How about

ALLOC DDNAME(ddname) DSN(dataset.name) disposition

DEALLOC (DDNAME)

WRITE DDNAME(ddname) 'text'/variable name

Where ddname and dataset.name are variables or strings containing variables (like TO email addresses)

The ALLOC would allocate but not open the file. The first write would open and write. The DEALLOC would close and unallocate the dataset.

I don't think that input with READ would be needed, because there is the READVARS facility to get data into variables. There is probably no need for new datasets, because it would be reasonable to expect that for status recording the datasets would have already been created in expectation of receiving status, so in the first cut of this facility the disposition would be MOD/SHR/OLD.
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #3 
File handling has the capacity to eventually become complex, so starting with simple behaviour like this, as a base, is a good idea. Then as we see how it works, it can be added to. Probably next week there will be an Alpha for users to try and comment on.
0
rakesh

Member
Registered:
Posts: 52
Reply with quote  #4 
my another thought is,
1) to allow users to allocate the datasets in AUTOMAN proc itself with a ddname and write to it when ever the event happens. This will eliminate ALLOC and DEALLOC of the file for every occurance of the file.

That dataset may/may not be available to read/update until the AUTOMAN comes down, but that is just user problem. He may not need to read it when the STC is up.

2) i feel we need to have array/stem kind of variables to store multiple lines and write them all at once using WRITE to DDNAME. This will be useful in manipulating the data.
0
Zamin

Avatar / Picture

Member
Registered:
Posts: 67
Reply with quote  #5 
If you follow this suggestion you would need a way to identify the DDNAME to the script, so that it knows which file to write to. That could be an ENVIR parameter. When you release a dataset really only depends on when you need to look at the data. It would not work for me, because AutoMan is up for months at a time, and we cannot run with it down. With the scheme of using ALLOC and DEALLOC commands, there should be no need for them to be contiguous. You could put the ALLOC and DEALLOC in separate command lists and just run them from the console when you need to deallocate. In fact now that I am thinking about it, you could put the ALLOC in the initialization command list, to allocate when it comes up, then have a command list with DEALLOC when you need to look at it, and another one to re-ALLOC if you wanted.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #6 
I believe that adding file I/O to GAL would be a big plus. A file I/O feature should start out simple and add functions as needed. Before we begin with the initial simple features, we should think about a wide range of possible features. It would be advantageous for early implemented features to be easily extendable and not conflict with more complex features later. We should try to ensure that the syntax and semantics of new features remains aesthetically pleasing with the other GAL statements and features as this will help keep the language easy to learn and be user friendly.

For example, multiple GAL procedures can run concurrently. GAL allows multiple instances of the same GAL procedure. This could be lead to multiple instances using the same variables, file handles, etc. Therefore the user needs to be aware of resource serialization issues and techniques.

A list of multi-tasking issues to think about:
1.         Should GAL procedures be allowed concurrent file access with other z/OS address spaces?
DISP=SHR, OLD, MOD, or NEW

2.         Should multiple GAL procedures be allowed concurrent access to the same file?
If you don’t allow concurrent access, then the user does not have to worry about that.
If you do, then you want GAL procedure level options analogous to address space level DISP=SHR, OLD, MOD, and NEW

3.         If concurrent access is allowed, is it up to the user to handle record level serialization issues, or should there be GAL functions/features provided?

4.         Should GAL procedures use DDNAMEs as the file access handle, or should GAL have its own file access handle separate from the z/OS DDNAME?
For example, GAL instance 1 could have:
ALLOC FILE(SYSPRINT) SYSOUT(a) …
which would be separate from GAL instance 2:
ALLOC FILE(SYSPRINT) SYSOUT(a) …
This would be analogous to two separate z/OS address spaces using the same DDNAME SYSPRINT, but the files in each address space are unrelated.

Perhaps GAL could use a local variable (SYSPRINT in example above) as a file handle where ALLOC FILE(local-variable) would use the dynamic allocation’s generated DDNAME (the SYSnnnnn) to be assigned to the local-variable.

If you did not want to use a generated DDNAME you might use a string constant:
ALLOC FILE(‘SYSPRINT’) ...
or perhaps use a DDNAME option:
ALLOC FILE(MYFILE) DDNAME(‘SYSPRINT’)…
would assign variable MYFILE the DDNAME SYSPRINT.

Of course, multi-tasking features are not simple, and should probably be added later. We probably would not want to have an initial file handle syntax that would prevent the later addition of multi-tasking features.

__________________
zboxassist
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #7 
It is going to take time to develop a full blown I/O feature, but by starting simple, with a view to increasing future complexity we could easily have something that satisfies rakesh's requirement by next week on an Alpha test basis. I agree with Zamin's suggestion that the ALLOC and DEALLOC can be done anywhere under user control, from a command list if need be, or a user defined console command. So we will go with the use of ALLOC and DEALLOC for the time being. After seeing how that works, we will discuss how useful a JCL solution might be. I agree with xboxassist that an early implementation should be simple and allow for future expansion. There is an interesting complexity that presents itself, when reading xboxassist's comment. That is the possibility of that someone might try using the AutoMan SYSOUT feature to capture its own file output. I will add a prohibition on this to the specifications.

Why should a user care about the actual DDNAME used internally. A file handle is only needed to identify the file internally to the programmer. So I am going to experiment with these two formats:

ALLOC DDNAME(ddname) and
ALLOC FILE(filehandle) The DDNAME could be the actual DDNAME used and FILE could generate a DDNAME internally. This then raises the question about variable usage for DDNAMEs and FILE handles. GAL has a very powerful text replacement function that can take strings with variables and replace them, and keep replacing them until there are no variable names left in the string. Thus it is potentially possible to make ddname or filehandle to be or contain variables.

On the question about concurrency, GAL attempts to allow the programmer sufficient freedom that they can get themselves into trouble, if they want, so does not try to restrict how something is done. There are serialization commands in GAL which can be used to control concurrency, and I think the user should choose when to use them.
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #8 
I have this working at STAGE=2

MSG=XXX403I
VAR &LIST LEN 80
LET &LIST=$$MSGTXT
ALLOC DDNAME(NEWDDN) DSN(TEST.V33.DATA) MOD
WRITE DDNAME(NEWDDN) 'TEXT TO BE WRITTEN'
WRITE DDNAME(NEWDDN) &LIST
DEALLOC DDNAME(NEWDDN)
*

I need to sort out text lengths so that padding takes place if the data to be written is shorter than the record length. I will let long records truncate. I also need to test the dataset full and other things surrounding error conditions, but will likely have something that does what rakesh is looking for by the middle of next week. It will not be earlier because of a variety of commitments tomorrow and at the weekend. This will form the base of further development.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #9 
What kinds of files should GAL support:

1.         Data Set Organization: Sequential, Partitioned, VSAM, UNIX,…
Of course, initially just sequential.

2.         Record formats: Fixed/variable, blocked/unblocked, spanned/non-spanned,…
Initially, just RECFM=FB

3.         Data formats: text, binary (integers, floating-point, packed decimal,…), or a mixture
Initially, text only

4.         Higher level data formats: CSV, quoted strings, columnar data,…
Not initially. However, many people might like CSV formatting to allow easy importing into a spreadsheet.

5.         Data flow: Byte stream or record (pad short records and truncate or wrap long records)

Should GAL have a READ statements?

Should GAL allow explicit OPEN/CLOSE statements? This would allow a user to:
1.         Allocate a file
2.         Open it for output
3.         Write to it
4.         Close it
5.         Open it for input
6.         Read it
7.         Close it
8.         Deallocate it

__________________
zboxassist
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #10 
We are not a very imaginative bunch here, we usually try to find out what people actually want to do, before doing it. So if someone has a real world problem they want to solve, we tend to do that. I would have to be convinced that someone actually needs to use some of the more complex data and record formats before putting the time into trying to work out how to do it. I have wondered about the READ statements, and other then the READVARS which it currently supports to obtain variable initializations saved between runs, I ask myself, why would anyone want to read data into an automation program. I was also wondering about the separate OPEN/CLOSE statement. rakesh ran into a problem with REXX when it refused to deallocate, because his file was still open. My current stab at it does not do that. It sees that it is open and closes it before deallocating. If it is allocated but not open, it opens it on the first write. I now have working code that will do what he wants, quite efficiently, without any REXX intervention as he had before.

I am hoping that users will say why they need these formats, and read commands, and if I am convinced, I will make them happen. For the time being, however I have solved all the problems rakesh is having.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #11 
I agree that features should be needed by a customer before the developer invests significant time and money to create a solution. And sometimes the reverse happens, the vendor creates a solution for a problem the customer did not know he had. I have had more than a few situations that I never realized I could improve until after discovering some new feature or function I was not searching for.

You have solved rakesh's problem. Someone else may see the new feature then realize they can use it to improve their situation. Or they may have a similar problem where they wish to collect status data all day long, but then at the end of day need to reformat that data into a csv file that they can download into a spreadsheet. If AutoMan had a READ function and a csv feature, then AutoMan could read the status file and create a csv file. However, if the customer already had SAS which has a csv feature, then that might be a better solution; but AutoMan could be used to submit the batch SAS job.


__________________
zboxassist
0
rakesh

Member
Registered:
Posts: 52
Reply with quote  #12 
I just wrote my first code using ALLOC/WRITE commands

If the string lenght is smaller than record length of the file, WRITE command is padding the string with HEX'00'. Any reason why are we not using HEX'40' as padding?
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #13 
No reason at all. But I bet that if we did, someone would ask for it differently. Why do you want spaces?
0
rakesh

Member
Registered:
Posts: 52
Reply with quote  #14 
just a standard across different products. If we use the output file for further manipulation with different tools then HEX'00' may be treated as different than HEX'40'. Most of the tools uses HEX'40' to find end of line.
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #15 
It is done. It now pads with blank spaces instead of null values.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!