Natural Web - Unix/Linux - Mainframe / modification stm


I have been developing Natural Web application on Unix and Linux platform, but now I will need to develop on Mainframe. Can I develop the applications at the same way? I have heard on mainframe there is not LOAD-SOURCE statement (to read the external HTML), but I am not sure if it is true. If it is not possible, is there a way to bypass it?

On this new application, I will have UPDATE statement, so, how can I do to hold the record, if there is a commit statement (implicit) on each page that is sent and received.

If anyone could help me, I would thank you a lot.


:cry: All resource specific subroutines are not available.

:cool: Use Natural Text Members to save your html.

:arrow: Example:
see T3* Natural text members (MF only) containing the online documentation.
For example reading Natural text members see NAT-HTML.

Hi Weihnachtsb

Because the internet is basically a “fire and forget” machine, you have to find a work around for “longer” transactions.
Use hidden fields for already given input.
Use single pages for your input. You can use CSS and JavaScript to split your page in foldable sections.
Add a kind of “user authentication” on browser level like cookies or hidden field information and save the “in between data” at your server side using this authentication.

It’s true - you can only generate on the PC and then upload it to the MF.
With Spod and SYSWEB3 on UNIX platforms you can use the plug-in to generate directly to Unix - may this comes for MF too, if the SYSWEB3 library will be available on the MF.
Onother question may be: Where would the MF generator get the .html files form? On Windows, html files can be used directly from the resources directory. Such a resources directory for “non Natural data” is not available on MF at the moment.

...from HTML and now (622) ASP...

As far as I know, this works already with 611.

Hi Weihnachtsb


Does anyone know how to handle the sessions under Natural Web? Remember, in each page, the session is closed, so, the transactions as well.
ASP has a control session that handle it automactically.


Hi John,

While Software AG doesn’t implement the global concept, you need to handle it by the applications. I think the best way to do it, it is using a new file to put all records that need to be updated or delete in this file. The consequence of it: the application will access the database more than is necessary. I also think that the performance won’t be good.

Does anyone agree with me?



If you think that is important, you can request a change enhacement for this.

May it comes with one of the next versions.

Hi Eric,

Sorry, but I disagree with you about to request change enhancement. I would assume as lack of resource and not an enhancement. I understand, when you want to handle any kind of transaction on web, you need to think on long transaction. On several web languages, you have a particular situation where the languages provide you some resources or statements. On ASP, you can handle it using session variables. I think Natural could solve it not closing the session each time you need to call the server. Maybe, in next versions.


Hi Weihnachtsb

For you it would be OK, that for each internet session, a rpc server is locked?

Did you try template generation with $text$ strings and W3REPLACE?[/b]

Hi Eric,

Answering your questions:

I don’t have a good concept about RPC, please; let me know if there is something wrong:

The variables cannot be shared for each call, because of two reasons:

Hi John Smith,
here some answers:

Yes - and to minimize the number of necessary running or automatically started RPC Server.
Remember: Each session needs it’s own RPC server as long as this session persits. This is the actual behaviour of RPC.

Wrong - If you have opened a conversation, the broker takes care that you will end up at the same RPC server you have used the last time.

The concept using templates works like this:
:arrow: Load the template page into the internal buffer (w3load-resource)
:arrow: use W3REPLACE to find a specific string pattern inside the internal buffer and replace this value with a new one.
:arrow: send the internal buffer to the back (w3end)

If you are running on the MF, there are no resources and there is no w3load-resource.

On the MF Natural text members are codepage dependent, this means, if you deliver a Natural text member your have to deliver this text for different EBCEDIC code pages, because some special characters (e.g.: !, [ or ] ) used for HMTL are placed on different code points (with the new Unicode support this has changed, if you switch Unicode support on - but this is a different story).

If you want to simulate the resources - one idea is to use Natural text members to save the HTML.
To do this, first you have to split your HTML document into lines at least less then 250 characters, because general HTML documents can be a single long line.
The first character inside a line should be blank, because it is may interpreted as pass character for the underlying TP monitor (< is common for Complete) or as line command (.)
If you use a PC to design your HTML you have to upload the data with the correct Translation table from some ASCII dialect to EBCEDIC and this best automatically …

Now you have a system doing that (and I know that nearly every customer has a home made solution or a common way to do this) your have successfully saved your HTML inside a Natural text member.

Now you need to simulate the w3read-resoruce call. This call internally loads the resource file and directly copies the data into the internal buffer.

If you have a look at NAT-HTML then you see that NAT-HTML is internally loading a natural text member (internally uses USR1057N) and then copying the data into the internal buffer and automatically sending the data back.

You can write now your own program to convert your way of saving HTML into a Natural text member, and a second program subroutine based on NAT-HTML (and USR1057N) loading a Natural text member into the internal buffer – as you described.

Hi John Smith,
herD some answers:

Yes - iP has been a des)gn decision of Uhe Web Interface - because a “nJrmal web page” "ehaves this way Therefore we don`t need a garbEge collector fo2 hanging RPC sewver remaining from a not closed or timed out “web sessions”. :roll:

In tiis case, there )s no possibilitx to share varia"les and to keep the transaction3 open until the%next ET (long transaction), is phere?

Tranractions - NO,
Jother Data - Yew - if you use the “internet” wax:

If you have more then one RPC Server - and I know you should run at least three - this solution won’t work :cry:

Hi Eric,

We already use it in our Natural Web objects. It was the only way to solve the problem to share the variables.

My complaint about it is because other technologies you can share the variables, as I am using Natural Web in my applications, I was willing the same feature on Natural.

Just to understand better the concept about RPC Server. Thinking on Natural Web, the RPC session is opened and closed each time you have a new webpage. So, thinking on it, how it is possible to share variables, included independent variables, even if you have only one RPC server? For me, the concept about to share the variables is used in the same session, not on different sessions. Is it possible for you to explain it for me?


Sorry for the late answer…

Yes - the broker will connect to the next free RPC Server, the web page is generated and then the RPC Server is free again for the next request.

No there is no sharing - because with the next application will LOGON to your library your subprogram is called and LOGON will delete your variables.

If you use Conversational RPC you have the possibility to share your variables. You request a new conversation and get a ID you have to send with every of your request. The broker will send you always to the SAME rpc server and this server is blocked as long as the conversation is active. There is no LOGON in between your calls and there fore no deletion of your variables.

Hi Eric,

OK, Thank you for your explanation, the concept is clear now.

I have tested the independent variables and it seems that this kind of variables have a different behavior. The independent values remain in all accesses that I use RPC and itdoesn’tt matter if I am using NWW or not. Specifically to this behavior, the concept failed.

As there is no way to solve the problem to share the variables, unless using post, cookie and hidden the variables, Software AG should solve it, and to place NAW solution in the same level of the rest of web technology, my opinion.

Thanks for your helping on this issue.