Hello Charles,

Thank you for telling me about the Dallas Remote Development program. From your description, it appears to provide exactly the type of environment Lua/TSO requires: an isolated system that can be configured freely, IPLed when necessary, and run with a current version of z/OS.

Unfortunately, a price of approximately $550 per month is too high for this project.

Lua/TSO is a non-commercial open-source project released under the Apache-2.0 license and developed independently by me. It has no sponsoring company, commercial customers, or institutional funding. At that rate, the environment would cost approximately $6,600 per year.

I am not developing the project for profit. I am interested in the architecture of z/OS and in creating a modern system automation environment for the platform. If the result proves useful to the IBM Z community, that would be the project's primary value.

Lua/TSO is also developed in my spare time outside my main job. Progress will inevitably be uneven: periods of active development may be followed by pauses lasting several days or weeks. During those pauses, I could shut down the LPAR or virtual machine completely so that it would not consume computing resources.

For that reason, a fixed monthly fee does not fit the actual usage pattern very well. A model based on actual runtime, with only storage costs while the environment is stopped, would be much more suitable for a project like this.

I do not need production capacity, high performance, an SLA, or permission for commercial use. A small isolated environment would be sufficient, provided that it allows me to:

• stop it during periods of inactivity;
• preserve its state and resume work later;
• pay for actual usage or a small storage fee while stopped;
• use it solely for development of the public Lua/TSO project;
• exclude performance testing and all production workloads.

Lua/TSO requires more than a normal user account because I need to validate installation procedures, RACF profiles, started tasks, authorized libraries, and integration with native z/OS system services. This requires a separate recoverable VM or LPAR, but it does not need to run continuously.

Do you know whether Dallas Remote Development offers any of the following?

1. A reduced-cost plan for independent open-source developers.
2. Billing based only on actual environment runtime.
3. The ability to stop the LPAR for extended periods and pay only for storage.
4. Sponsored access through IBM, the Open Mainframe Project, or another organization.
5. A contact who could review Lua/TSO as a non-commercial open-source project.

If Dallas is available only to commercial ISVs under a fixed monthly subscription, then unfortunately it does not solve the access problem for this project. However, it does show that the required technical environment already exists. What is missing is an affordable and legitimate path for independent open-source development.

I would appreciate any contact or possible alternative you can suggest.

Thank you again for the concrete lead.

Regards,

Ruslan Stepanenko
Lua/TSO project author
https://github.com/drblez/luaz

Hello Charles,

Thank you for telling me about the Dallas Remote Development program. From your description, it appears to provide exactly the type of environment Lua/TSO requires: an isolated system that can be configured freely, IPLed when necessary, and run with a current version of z/OS.

Unfortunately, a price of approximately $550 per month is too high for this project.

Lua/TSO is a non-commercial open-source project released under the Apache-2.0 license and developed independently by me. It has no sponsoring company, commercial customers, or institutional funding. At that rate, the environment would cost approximately $6,600 per year.

I am not developing the project for profit. I am interested in the architecture of z/OS and in creating a modern system automation environment for the platform. If the result proves useful to the IBM Z community, that would be the project's primary value.

Lua/TSO is also developed in my spare time outside my main job. Progress will inevitably be uneven: periods of active development may be followed by pauses lasting several days or weeks. During those pauses, I could shut down the LPAR or virtual machine completely so that it would not consume computing resources.

For that reason, a fixed monthly fee does not fit the actual usage pattern very well. A model based on actual runtime, with only storage costs while the environment is stopped, would be much more suitable for a project like this.

I do not need production capacity, high performance, an SLA, or permission for commercial use. A small isolated environment would be sufficient, provided that it allows me to:

• stop it during periods of inactivity;
• preserve its state and resume work later;
• pay for actual usage or a small storage fee while stopped;
• use it solely for development of the public Lua/TSO project;
• exclude performance testing and all production workloads.

Lua/TSO requires more than a normal user account because I need to validate installation procedures, RACF profiles, started tasks, authorized libraries, and integration with native z/OS system services. This requires a separate recoverable VM or LPAR, but it does not need to run continuously.

Do you know whether Dallas Remote Development offers any of the following?

1. A reduced-cost plan for independent open-source developers.
2. Billing based only on actual environment runtime.
3. The ability to stop the LPAR for extended periods and pay only for storage.
4. Sponsored access through IBM, the Open Mainframe Project, or another organization.
5. A contact who could review Lua/TSO as a non-commercial open-source project.

If Dallas is available only to commercial ISVs under a fixed monthly subscription, then unfortunately it does not solve the access problem for this project. However, it does show that the required technical environment already exists. What is missing is an affordable and legitimate path for independent open-source development.

I would appreciate any contact or possible alternative you can suggest.

Thank you again for the concrete lead.

Regards,

Ruslan Stepanenko
Lua/TSO project author
https://github.com/drblez/luaz

Hello Charles,

Thank you for telling me about the Dallas Remote Development program. From your description, it appears to provide exactly the type of environment Lua/TSO requires: an isolated system that can be configured freely, IPLed when necessary, and run with a current version of z/OS.

Unfortunately, a price of approximately $550 per month is too high for this project.

Lua/TSO is a non-commercial open-source project released under the Apache-2.0 license and developed independently by me. It has no sponsoring company, commercial customers, or institutional funding. At that rate, the environment would cost approximately $6,600 per year.

I am not developing the project for profit. I am interested in the architecture of z/OS and in creating a modern system automation environment for the platform. If the result proves useful to the IBM Z community, that would be the project's primary value.

Lua/TSO is also developed in my spare time outside my main job. Progress will inevitably be uneven: periods of active development may be followed by pauses lasting several days or weeks. During those pauses, I could shut down the LPAR or virtual machine completely so that it would not consume computing resources.

For that reason, a fixed monthly fee does not fit the actual usage pattern very well. A model based on actual runtime, with only storage costs while the environment is stopped, would be much more suitable for a project like this.

I do not need production capacity, high performance, an SLA, or permission for commercial use. A small isolated environment would be sufficient, provided that it allows me to:

• stop it during periods of inactivity;
• preserve its state and resume work later;
• pay for actual usage or a small storage fee while stopped;
• use it solely for development of the public Lua/TSO project;
• exclude performance testing and all production workloads.

Lua/TSO requires more than a normal user account because I need to validate installation procedures, RACF profiles, started tasks, authorized libraries, and integration with native z/OS system services. This requires a separate recoverable VM or LPAR, but it does not need to run continuously.

Do you know whether Dallas Remote Development offers any of the following?

1. A reduced-cost plan for independent open-source developers.
2. Billing based only on actual environment runtime.
3. The ability to stop the LPAR for extended periods and pay only for storage.
4. Sponsored access through IBM, the Open Mainframe Project, or another organization.
5. A contact who could review Lua/TSO as a non-commercial open-source project.

If Dallas is available only to commercial ISVs under a fixed monthly subscription, then unfortunately it does not solve the access problem for this project. However, it does show that the required technical environment already exists. What is missing is an affordable and legitimate path for independent open-source development.

I would appreciate any contact or possible alternative you can suggest.

Thank you again for the concrete lead.

Regards,

Ruslan Stepanenko
Lua/TSO project author
https://github.com/drblez/luaz

Hello Charles,

Thank you for telling me about the Dallas Remote Development program. From your description, it appears to provide exactly the type of environment Lua/TSO requires: an isolated system that can be configured freely, IPLed when necessary, and run with a current version of z/OS.

Unfortunately, a price of approximately $550 per month is too high for this project.

Lua/TSO is a non-commercial open-source project released under the Apache-2.0 license and developed independently by me. It has no sponsoring company, commercial customers, or institutional funding. At that rate, the environment would cost approximately $6,600 per year.

I am not developing the project for profit. I am interested in the architecture of z/OS and in creating a modern system automation environment for the platform. If the result proves useful to the IBM Z community, that would be the project's primary value.

Lua/TSO is also developed in my spare time outside my main job. Progress will inevitably be uneven: periods of active development may be followed by pauses lasting several days or weeks. During those pauses, I could shut down the LPAR or virtual machine completely so that it would not consume computing resources.

For that reason, a fixed monthly fee does not fit the actual usage pattern very well. A model based on actual runtime, with only storage costs while the environment is stopped, would be much more suitable for a project like this.

I do not need production capacity, high performance, an SLA, or permission for commercial use. A small isolated environment would be sufficient, provided that it allows me to:

• stop it during periods of inactivity;
• preserve its state and resume work later;
• pay for actual usage or a small storage fee while stopped;
• use it solely for development of the public Lua/TSO project;
• exclude performance testing and all production workloads.

Lua/TSO requires more than a normal user account because I need to validate installation procedures, RACF profiles, started tasks, authorized libraries, and integration with native z/OS system services. This requires a separate recoverable VM or LPAR, but it does not need to run continuously.

Do you know whether Dallas Remote Development offers any of the following?

1. A reduced-cost plan for independent open-source developers.
2. Billing based only on actual environment runtime.
3. The ability to stop the LPAR for extended periods and pay only for storage.
4. Sponsored access through IBM, the Open Mainframe Project, or another organization.
5. A contact who could review Lua/TSO as a non-commercial open-source project.

If Dallas is available only to commercial ISVs under a fixed monthly subscription, then unfortunately it does not solve the access problem for this project. However, it does show that the required technical environment already exists. What is missing is an affordable and legitimate path for independent open-source development.

I would appreciate any contact or possible alternative you can suggest.

Thank you again for the concrete lead.

Regards,

Ruslan Stepanenko
Lua/TSO project author
https://github.com/drblez/luaz

Hello Cameron,

Thank you very much for your response. I will follow your initiative closely for further updates.

Please feel free to contact me directly if there is any progress, if the project's status changes, or if input from an independent developer would be useful. I would be glad to contribute to the discussion and can provide a detailed description of Lua/TSO's requirements for an educational or research z/OS environment.

Thank you to you and your group for doing this work. Creating an accessible environment for students, researchers, and independent developers is a major and genuinely important contribution to the community. Without such access, many ideas for native z/OS software cannot progress from a concept to a working project.

Regards,

Ruslan Stepanenko
Lua/TSO project author
https://github.com/drblez/luaz

Hello Charles,

Thank you for telling me about the Dallas Remote Development program. From your description, it appears to provide exactly the type of environment Lua/TSO requires: an isolated system that can be configured freely, IPLed when necessary, and run with a current version of z/OS.

Unfortunately, a price of approximately $550 per month is too high for this project.

Lua/TSO is a non-commercial open-source project released under the Apache-2.0 license and developed independently by me. It has no sponsoring company, commercial customers, or institutional funding. At that rate, the environment would cost approximately $6,600 per year.

I am not developing the project for profit. I am interested in the architecture of z/OS and in creating a modern system automation environment for the platform. If the result proves useful to the IBM Z community, that would be the project's primary value.

Lua/TSO is also developed in my spare time outside my main job. Progress will inevitably be uneven: periods of active development may be followed by pauses lasting several days or weeks. During those pauses, I could shut down the LPAR or virtual machine completely so that it would not consume computing resources.

For that reason, a fixed monthly fee does not fit the actual usage pattern very well. A model based on actual runtime, with only storage costs while the environment is stopped, would be much more suitable for a project like this.

I do not need production capacity, high performance, an SLA, or permission for commercial use. A small isolated environment would be sufficient, provided that it allows me to:

• stop it during periods of inactivity;
• preserve its state and resume work later;
• pay for actual usage or a small storage fee while stopped;
• use it solely for development of the public Lua/TSO project;
• exclude performance testing and all production workloads.

Lua/TSO requires more than a normal user account because I need to validate installation procedures, RACF profiles, started tasks, authorized libraries, and integration with native z/OS system services. This requires a separate recoverable VM or LPAR, but it does not need to run continuously.

Do you know whether Dallas Remote Development offers any of the following?

1. A reduced-cost plan for independent open-source developers.
2. Billing based only on actual environment runtime.
3. The ability to stop the LPAR for extended periods and pay only for storage.
4. Sponsored access through IBM, the Open Mainframe Project, or another organization.
5. A contact who could review Lua/TSO as a non-commercial open-source project.

If Dallas is available only to commercial ISVs under a fixed monthly subscription, then unfortunately it does not solve the access problem for this project. However, it does show that the required technical environment already exists. What is missing is an affordable and legitimate path for independent open-source development.

I would appreciate any contact or possible alternative you can suggest.

Thank you again for the concrete lead.

Regards,

Ruslan Stepanenko
Lua/TSO project author
https://github.com/drblez/luaz

To give some context on where the idea for Lua/TSO came from, I would like to add a little about my professional background.

I have worked in software development and systems architecture since 1986. A significant part of my career has involved systems where continuity, predictability, and data integrity are critical. One of the payment-processing platforms I worked on for many years used a mainframe. Under real production workloads, it performed extremely well, particularly in terms of reliability and operational stability.

At the same time, within z/OS itself, I feel there is a lack of a modern and expressive automation tool operating directly at the level of TSO, JES, datasets, system services, and the operator console. I do not mean an external API or yet another layer around the platform, but a language capable of working naturally from within it.

REXX and System REXX are undoubtedly useful and deeply integrated with z/OS. In my opinion, however, they lack some of the expressiveness found in modern languages: convenient data structures, proper modularity, clear error handling, testability, and the ability to build reasonably large programs without the code quickly becoming a difficult-to-maintain collection of procedures and string operations.

That is why I started Lua/TSO. The idea is not to declare REXX obsolete or replace every existing tool. I want to explore whether it is possible to preserve the advantages of native z/OS automation while giving system programmers a more compact and expressive tool for working with the platform itself.

Such a project cannot be developed properly from documentation alone or with only a normal user account. It requires an isolated environment where system components can be installed, permissions, started tasks, and authorized libraries can be configured, experiments can be performed, and the system can be restored after unsuccessful changes. For Lua/TSO, access to a complete test z/OS environment is therefore not an optional convenience, but an essential part of the development process.

To give some context on where the idea for Lua/TSO came from, I would like to add a little about my professional background.

I have worked in software development and systems architecture since 1986. A significant part of my career has involved systems where continuity, predictability, and data integrity are critical. One of the payment-processing platforms I worked on for many years used a mainframe. Under real production workloads, it performed extremely well, particularly in terms of reliability and operational stability.

At the same time, within z/OS itself, I feel there is a lack of a modern and expressive automation tool operating directly at the level of TSO, JES, datasets, system services, and the operator console. I do not mean an external API or yet another layer around the platform, but a language capable of working naturally from within it.

REXX and System REXX are undoubtedly useful and deeply integrated with z/OS. In my opinion, however, they lack some of the expressiveness found in modern languages: convenient data structures, proper modularity, clear error handling, testability, and the ability to build reasonably large programs without the code quickly becoming a difficult-to-maintain collection of procedures and string operations.

That is why I started Lua/TSO. The idea is not to declare REXX obsolete or replace every existing tool. I want to explore whether it is possible to preserve the advantages of native z/OS automation while giving system programmers a more compact and expressive tool for working with the platform itself.

Such a project cannot be developed properly from documentation alone or with only a normal user account. It requires an isolated environment where system components can be installed, permissions, started tasks, and authorized libraries can be configured, experiments can be performed, and the system can be restored after unsuccessful changes. For Lua/TSO, access to a complete test z/OS environment is therefore not an optional convenience, but an essential part of the development process.

To give some context on where the idea for Lua/TSO came from, I would like to add a little about my professional background.

I have worked in software development and systems architecture since 1986. A significant part of my career has involved systems where continuity, predictability, and data integrity are critical. One of the payment-processing platforms I worked on for many years used a mainframe. Under real production workloads, it performed extremely well, particularly in terms of reliability and operational stability.

At the same time, within z/OS itself, I feel there is a lack of a modern and expressive automation tool operating directly at the level of TSO, JES, datasets, system services, and the operator console. I do not mean an external API or yet another layer around the platform, but a language capable of working naturally from within it.

REXX and System REXX are undoubtedly useful and deeply integrated with z/OS. In my opinion, however, they lack some of the expressiveness found in modern languages: convenient data structures, proper modularity, clear error handling, testability, and the ability to build reasonably large programs without the code quickly becoming a difficult-to-maintain collection of procedures and string operations.

That is why I started Lua/TSO. The idea is not to declare REXX obsolete or replace every existing tool. I want to explore whether it is possible to preserve the advantages of native z/OS automation while giving system programmers a more compact and expressive tool for working with the platform itself.

Such a project cannot be developed properly from documentation alone or with only a normal user account. It requires an isolated environment where system components can be installed, permissions, started tasks, and authorized libraries can be configured, experiments can be performed, and the system can be restored after unsuccessful changes. For Lua/TSO, access to a complete test z/OS environment is therefore not an optional convenience, but an essential part of the development process.

Thank you for the question. I do not see Lua/TSO as an alternative to Zowe, z/OSMF, zConfig, or Code4z - it occupies a somewhat different niche.

Most of those tools address access to z/OS, development, configuration, or system management from outside the platform. Lua/TSO is intended to be an execution environment inside z/OS itself, roughly in the area where REXX and System REXX are used today.

The idea is to make it natural for Lua code to work with things that are native to z/OS: execute TSO commands, work with datasets and ISPF services, access AXR and other system interfaces, run under IKJEFT01, be used from batch jobs, and eventually from system components.

So, in simplified terms:

Zowe / z/OSMF / Code4z help a person or an external system work with z/OS.

Lua/TSO is intended for writing automation programs that run inside z/OS.

Of course, there can be some overlap. In fact, I see these approaches as complementary. Zowe, for example, could provide an external interface to automation, while Lua/TSO could execute the actual logic on the z/OS side.

The main reason I started the project is fairly simple: REXX is very well integrated with the platform, but for larger tasks I miss the expressiveness of a modern language - data structures, modularity, function composition, more convenient error handling, and the ability to build reasonably complex logic without so much string-oriented and procedural code.

So Lua/TSO is essentially an attempt to preserve one of REXX's greatest strengths - its very close integration with z/OS - while providing that model through a more modern language.