How to prepare a map without sending it to the terminal?

Simone Salzmann · Posted: Mon Nov 26, 2012 10:45 pm

Hello from a newbie here,

the idea behind my question is the following:
We have to archive all the data (including history) from an application.
The idea arose to simply "capture" all screens, as we would have to "re-invent" a lot of the existing code otherwise.
As we'll deal with several millions of screens (using 170 different types of maps) we want to avoid using a physical screen at all.

At the moment I am testing with a slightly modified CICS program using the usual map.
Savin the data returned to a DB2 table works.
Here my problem begins:
Sending the map in the usual way and receiving it with RECEIVE... ASIS BUFFER returns an almost perfectly designed data stream. But the data is sent to the physical screen as well.
Sending the map using the SET option returns the map to the program without using the physical screen. But the data stream has the structure of the SDFII data structure which doesn't match the screen built.

I am aware of the possibilities of using a printer as terminal but haven't tested it yet - simply wasn't able to define one instead of my screen.

We use are CICS 3.2 and SDFII.

I've spent a lot of time in the handbooks lately and haven't found the right topics though.
To save time and nerves and to know if it makes sense to go forward with this idea please give me some hints:

- Will/could I be successful with a background transaction?
- What definitions should/could I change?
- Where's the big error in my approach, if there's one?

Thanks a lot in advance, Simone

Bill Woodger · Posted: Mon Nov 26, 2012 11:24 pm

Simone,

Can you please make another attempt at describing the business function you are trying to implement? I've read the first part several times, and am still very uncertain about what you are trying to do.

Pandora-Box · Posted: Mon Nov 26, 2012 11:46 pm

Just to add on to what Bill said if you are able to visualise what you need you should be able to explain better

If you couldnt explain then it is very likely that you are not sure what you want

Robert Sample · Posted: Mon Nov 26, 2012 11:46 pm

I think your biggest issue is that you are confusing DISPLAY with ARCHIVE. Is this part of a project to get rid of a mainframe?

Generally, archive is simple: there are products to back up data -- even DB2 data. However, if your site wants to be able to display that data (especially if wanting to do so using the original CICS maps) then your issue becomes VASTLY complicated. The simplest solution is to maintain a z-architecture machine with CICS and the data in order to simplify access to the data. There may -- or may not -- be other solutions possible, depending upon your site and what is available to it. However, do not expect any solution to be "cheap" (keeping a mainframe around as long as the data is needed may well be the cheapest solution possible) and if you pull data from a mainframe to a Unix or Windows platform, be prepared to deal with data representation issues (EBCDIC on the mainframe versus ASCII on the other platforms), among other issues.

dick scherrer · Posted: Tue Nov 27, 2012 1:28 am

Hello and welcome to the forum,

I've gotten lost and would appreciate a bit of clarification

Do you want to "capture" live transactions starting at some particular (future) time or do you want capture all of the data so it can be seen later?

Simone Salzmann · Posted: Tue Nov 27, 2012 1:33 am

Thanks for your answers as far and sorry for my bad English.
(Though I am neither good in explaining in German)

There is no attempt going on to get rid of mainframe.
We want to get rid of one single application containing contracts dating back as far as 1980 and even before.
The last active contracts have been migrated to a newer system, without history.
So we have an application with only inactive contracts.
Though it's the cheapest and easiest way to keep this old application as an information system, that's no issue, it will be taken out of service, all components will be deleted.

There is a big BUT: Lots of the contracts have to be kept with all their history in order to be able to cope with late claims.
Electronic document archiving was implemented much later than this application and we can’t be sure which documents are already archived and which aren’t.
So we will archive the contracts again to make sure we have all relevant information.

Normal technical ARCHIVE isn’t appropriate as the data can’t be read and interpreted properly. (Or I would keep the database)
To simply produce and archive all defined documents once more isn’t feasible either - too many changes have taken place in the printing system since the beginning of the application.

So it seemed worth-wile to try and save all screens instead of building a complete batch application to handle a dead system.

dick scherrer · Posted: Tue Nov 27, 2012 1:42 am

Hello,

Simone Salzmann · Posted: Tue Nov 27, 2012 2:08 am

Pandora

I'll try to visualize the thingie tomorrow.

Hi, Dick

it's no issue to move the contract history to another system.
It had been considered for several data migrations and put aside each time again.
Too expensive and to tight restrictions in the new system.

"try to save all screens"
My idea is to prepare an input list defining the exact screen sequence for each contract and time slice. Working through this I can prepare what I called "all screens".

enrico-sorichetti · Posted: Tue Nov 27, 2012 2:13 am

Simone Salzmann · Posted: Tue Nov 27, 2012 7:02 pm

Hi, Enrico

I don't quite get it, sorry. Most possibly I did explain to badly.

What's my problem: I want is to create completely formatted maps independent of any physical screen - that includes emulators which serve a PC screen as well and surely that includes any other interfaces.
So I am quite at a loss which terminal test tool will help me working without a terminal.

Pandora-Box · Posted: Tue Nov 27, 2012 7:20 pm

Simone,

You mean something like a non-terminal CICS program??

When you say independent of physical screen where are you going to use the data that was sent to screen when in terminal

Simone Salzmann · Posted: Tue Nov 27, 2012 7:36 pm

Pandora

yes I mean that and next I'll do is to build a background transaction and see if it does what I want.

The last goal is to create a "print" document per contract with two or three print screens per page (depends on the font size available) which will be sent into our electronic document archive.

This way the data is more or less understandable and accessible without technical knowledge.
(And the effort seems to be the smallest compared to other solutions)

Pandora-Box · Posted: Tue Nov 27, 2012 7:41 pm

I think I got your requirement very clear now

If yes , Then I guess Initially you wanted to something which could take a snapshot of CICS screens so you could avoid recreating a similar batch with report generation ??

Simone Salzmann · Posted: Tue Nov 27, 2012 8:42 pm

Hi, Pandora

thanks for trying to understand my language.

You've got the idea more or less.

It's yes and no to your question:
Yes to avoiding recreating a similar batch.
No-o to taking actual snapshots of CICS screens.

No - because some of my colleagues have vast experience with mass processings via emulator (macros) and also with the disadvantages of it. We are convienced that we'd face a lot of problems taking snapshots wth an external tool. (and even being dependent on an emulator)

NB: It isn't my idea in fact but I said I could imagine that it's possible - so I am the one to try.

Pandora-Box · Posted: Tue Nov 27, 2012 8:49 pm

May for reporting purpose why not think of using EXCI interfaces and reuse the existing interface called via Batch using EXCI and report

Google EXCI for more information

Bill Woodger · Posted: Tue Nov 27, 2012 9:24 pm

What do you users have to say about this? You're going to have to talk to the "archiving" people, to establish that they will be able to cross-reference the information, or it will be another task for you if they can't. Have you covered all legal and any regulatory aspects of this?

A user is not going to be happy with "it's somewhere in that pile of stuff" and your archiving probably expects report-format data, perhaps with specific information in specific places for cross-referencing. I'd hope that the "headings" on the screens are fairly consistent, but you speak of 170 different ones.

Find out how the users would get to specific data, which screens they'd use, what sort of information they'd need for "mass queries",then try to reflect that in the "layout" of the archive and definitely through cross-referencing.

One thing you might like to consider is exporting from the database as a "CSV", "joining" things together where necessary, so that the data is available for someone to do something with if it is needed at some point in the future. If you do this, make sure you have "column headings" which can be linked to existing system documentation of the data.

Simone Salzmann · Posted: Tue Nov 27, 2012 9:40 pm

Hi, Pandora

thanks a lot, will check into the use of EXCI.

Simone Salzmann · Posted: Wed Nov 28, 2012 2:37 pm

Hi, Bill

thanks a lot for the side information to my problem. Yes, that's stuff that has to be regarded or the thing will go wrong. It's not the first application we're taking out of service, though, and the general approach is tested and confirmed, including legal aspects and the needs of the users.

There won't be any mass queries any more. There won't be any database any more. There won't be any system documentation any more. There won't be nothing than single contracts in a properly labeling archiving system with a helpful frontend (which is used for everyday backup of our documents as well).
(data warehouse and so on are regarded and have their own way to deal with the absence of the late application)

Only difference to the prior explementations (does this word exist in English?) - we would like to save the contract data in a sequence of screens instead of building a batch application to prepare the data.

Simone Salzmann · Posted: Wed Nov 28, 2012 8:15 pm

Hello,

thanks a lot to all for your input.
At last my CICS contact in my own company found time to research into the issue.
He suggests that it's not EXCI but FEPI what I need and another branch of the company has a vast experience with it.
He will update himself in the matter and we'll test the solution.

dick scherrer · Posted: Wed Nov 28, 2012 9:41 pm

Thanks for the update.

Good luck!

Someone will be here if there additonal "opportunities"

d