Tony: Sorry for being such a dork, but have to ask any-way. I have my 
migration.bp file on R83 with SAVE.RESTORE.AT, 1,2,3 ETC and also XBASIC.  I 
tried to "BASIC" the SAVE.RESTORE.AT item, but came up with a bunch of compiler 
errors, So I attempted to repair the code, but then realized that perhaps I 
should leave it alone and run XBASIC on it .  I attempted to compile XBASIC, 
but got some errors, and patched so it will run.  So it is now asking me for 
following and my responses are: File name > MIGRATION.BPItem.name> 
SAVE.RESTORE.ATOperating Environment > R83Precompile for R83 > YLeave Source ? 
YPrecompiling SAVE.RESTORE.AT FOR R83...Compiling SAVE.RESTORE.AT .....*I331*  
(IT STOPPED HERE)so I ended it.*END> So, I suppose I should restore 
MIGRATION.BP items to your original code and run XBASIC on them again as 
above.?? In orther words, can you confirm that I should start over and follow 
the XBASIC ROUTE ?  Dave   > From: [email protected]
> To: [email protected]
> Subject: RE: Pick r83 to jbase conversion
> Date: Mon, 19 Mar 2012 18:01:07 -0700
> 
> Responses in-line…
> 
> From: David Grenfell
> 
> >Tony: 
>  >Couple of questions to make sure I'm on the right tack here. 
>  >Do I create the MIGRATION.BP both in R83 and in jBase?
> 
> 
> Yes. And the R83 side is already done for you. Note also that the R83 code is 
> broken into a number of  includes to keep it below the 32k item size limit, 
> but for jBase you can use the one-item program.
> 
>  
> >When I run the "save" while logged in R83, is the saved info stored on the 
> >XP box ?
> 
> Yes, it’s pulled from AccuTerm and stored in a directory local to your client 
> PC where AccuTerm is running. The idea is that you would open a session into 
> jBase as soon as a R83 save is complete, and then push that data, back 
> through Accuterm, and out into new jBase files.
> 
>  
> >I haven't used ACCUTERM before, so I might be silent for a couple of days 
> >while I try to figure it out.
> 
> IMO, it’s the best MV emulator available.
> Quick primer:
> You have a layout which is a container for sessions.
> Then you have sessions which represent individual connections.
> A layout is like a web browser, and sessions are like tabs on the browser 
> which point to individual websites.
> So you can open one session to R83, another to jBase, and then save them as a 
> single layout. Open the layout again and your connections are instantly 
> re-established.
> 
> Once you have a connection there are many features allowing for data movement 
> between sessions or to/from the PC running a session. There are also GUI 
> features and others which are irrelevant for this exercise. AccuTerm does not 
> include non-MV features like AnzioWin or others, but all of the same 
> functionality is possible using scripting. (I’m not using scripting in the 
> migration code, just file transfers.)
> 
> I just got off the phone with a colleague and we were going over their GUI 
> options. For a simple GUI effort, there are around 4 options in AccuTerm for 
> varying degrees of quality. All of those can be done by a BASIC programmer. 
> From there the next step is to consider other technologies and products, so 
> there are Lots of options for cost, time, and skills when someone says “I 
> need a new GUI”. For our purposes, the point here is that AccuTerm is much 
> more than a simple terminal emulator, so  you may want to consider using it 
> for a variety of purposes.  Feel free to email with questions.
> 
>  
> >I have your SAVE.RESTORE programs T-DUMPED to a floppy, so am ready to put 
> >them to good use.
>  
> Wish this was just a simple conversion from R83 to jbase, but my jbase 
> version has  a lot of new code (25 years of updates and modifications), and 
> also a lot file structure changes too that I will have to compensate for.  
> 
> Source code will come over from program files. Make sure you have backups in 
> jBase, and look at the code to see how it decides whether to over-write 
> existing files.  Rather than trying to pull data into an application account 
> that has been prepared for application processing. I recommend creating a new 
> account in jBase, pulling all data over, and then working with the results.  
> This separates tasks, with data migration being one, and application upgrade 
> being another.
>  
> >Thanks again for help thus far.  I am doing a detailed documentation of what 
> >I am doing, so I can forward to you when finished.
>  
> >Dave.
> 
> Now THAT is great news, thanks. Your docs and code updates will be posted for 
> others.  Please don’t hesitate to email with basic questions – or to ask your 
> client if we can put something more significant on the clock. ☺
> T
> 
> Tony Gravagno
> Nebula Research and Development
> TG@ remove.pleaseNebula-RnD.com 
> 
> 
> -- 
> IMPORTANT: T24/Globus posts are no longer accepted on this forum.
> 
> To post, send email to [email protected]
> To unsubscribe, send email to [email protected]
> For more options, visit this group at 
> http://groups.google.com/group/jBASE?hl=en
                                          

-- 
IMPORTANT: T24/Globus posts are no longer accepted on this forum.

To post, send email to [email protected]
To unsubscribe, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/jBASE?hl=en

Reply via email to