RE: IND$FILE

Hi Paulo Hi Laddie

Thanks for trying it yesterday.
Appreciate your investing the effort.

I actually just got home from the New Years celebation when I saw your
E-mails. It was after 12:00 at night and I was also suffering from too much
driving and too much wine.

This morning first thing I did some checking.

I downloaded the VISTA Emulation that you both were using.

Very nice tool - Too bad I only got a free thirty day subscription.
This means that I have to hurry up and resolve the problem :-)

Some background.:

The Emulator that I use is much older but the File transfer which onl works
CUT MODE has many more options on the screen.
For instance I actually get to see the command that is being sent.

And I can pick and and choose if I want ASCII or EBCIDIC and weather I want
CRLF or not,
I can choose between FIXED or VARIABLE output and I can decide what  the
output LRECL size will be.
(the size that all fixed length records get padded to and the max size for
variable)

So in theory I could choose andASCII TEXT FILE But ignore the CRLF and block
it at a length that I choose
Or I can choose a FIXED length output file and Pad it with blanks if the CR
LF comes first/ or split the lines if a long record comes.

In the VISTA I don t see all those options.
At least the version that I downloaded this morning only has TEXT or BINARY.

My trace shows that when I choose TEXT it defaults to the following.

 IND$FILE PUT TEMP UPLOAD A ( ASCII CRLF  )   ---> from the trace

I do not see any way to change that in the emulator.

Which would mean that I have to change the defaults I currently using to
VARIABLE and CRLF and leave the MAX the default LRECL field blank.
That is very simple. 

I still have to leave the detailed routine in bacause other emulators may
work differently but I guess they assume that that is the default -- and
since the real IND$FILE works with VISTA that must be correct.  


Not at all familiar with the VISTA is there any way to change that?

HOW DO you upload fixed length FILE?


By the way the TRACE showed that VISTA is using a very ineffecient transmit
block size on the screen

1030  data positions -- in CUT MODE is what the trace shows
My old EMULATOR uses 1970

I' ll make the default fixes this morning and let you know the results.

However its still a Holiday here and wife may have other plans for me.

Thanks again for investing the time to try it out

Rocky





 

-->-----Original Message-----
-->From: [email protected] [mailto:[email protected]] 
-->Sent: Thursday, September 09, 2010 02:58 
-->To: [email protected]
-->Subject: RE: IND$FILE
-->
-->Hi Rocky, 
-->
-->I tried an UPLOAD on CMSUSER; I could UPLOAD a little EXEC 
-->file, (said FILE TRANSFER COMPLETE), but I couldn't find it 
-->in A DISK.
-->
-->I tried some fixed length files  (programs), both with or 
-->without ASCII-EBCDIC translation (I downloaded them from 
-->VM/SP5 with or without
-->EBCDIC-ASCII translation) and I got:  ** FSWRITE ERROR   
-->DEC=00008,HEX=0008 
-->after about 2000 bytes.
-->
-->I used the excellent (alas not free;-) Tom Brennan's VISTA 
-->TN3270 in CUT mode.
-->
-->BTW I'm sure you can transfer files bot in CUT and DFT mode 
-->to VM/SP5 under Hercules (TN3270 supports both).
-->
-->WC3270 file transfer only works in DFT mode (it has the FT 
-->CUT logic but I could not select it).
-->
-->Tomorrow I'll give a try to GIND under VM/SP5.
-->
-->By all means I'll be glad to have a skeleton.
-->
-->It's late and my wife is calling me to bed (only to sleep of 
-->course...;-)
-->
-->BFN
-->
-->Paulo
-->
-->>Not sure that DFT is going to work on Hercules That's more 
-->a part of 
-->>the how we do the attachement DFT needs a dft controller 
-->and then all 
-->>the definitons have to be made there
-->>
-->>I think that Hercules defaults to a simulated CUT MODE terminal.
-->>For DFT you would a simulated 3174 or 3274 DFT controller 
-->or something 
-->>thatis channel atached.
-->>
-->>Anyway I don't have that on VM/SP5 even though I do remember a DFT 
-->>controller on the real hardware.
-->>
-->>Do me a favor and give the IND$FILE a try with your emulator
-->>
-->>Take a small file or program  try using a Variable RECFM 
-->and reclen of 
-->>something about 120 Ascii and CRLF and tell me if it works
-->>
-->>My emulator was working - But a lot fo the code came from 
-->my traces and 
-->>that might be emulator dependent
-->>
-->>
-->>Remember that GCIC is using SIO
-->>
-->>I uploaded a file of 1,700,000 bytes this afternoon and 
-->that took up 
-->>the whole "A" disk Deleted it about an hour ago
-->>
-->>Give the IND$file a try
-->>
-->>As for your routines - Glad to help - but I think you will need to 
-->>start of slowly
-->>
-->>Suggest you take the FLIST Program and Just add a call to another 
-->>program as starter You can look whre I did the call to XFER 
-->- that was 
-->>just a PFKEY and L 15,=V( ) and a balr.
-->>
-->>Then just send one map to get the feel of it.
-->>Take xfer program rename it throw everything except the 
-->first map and 
-->>send that Wait for the attention interrupt
-->>
-->>And then send again Until you hit PF3
-->>
-->>If you want I can prepare a skelton that will do just that  
-->- No logic 
-->>in about 15 minutes Easy to understand and then you can start from 
-->>there
-->>
-->>Just add a PF function to the FLIST program to call it and 
-->you willhave 
-->>a starter
-->>
-->>Rocky
-->>
-->>
-->>Roc
-->>
-->>
-->>
-->>-->-----Original Message-----
-->>-->From: [email protected] [mailto:[email protected]]
-->>-->Sent: Thursday, September 09, 2010 02:00
-->>-->To: [email protected]
-->>-->Subject: Re: IND$FILE
-->>-->
-->>-->Hi Rocky,
-->>-->
-->>-->Sorry for the long delay (some real job and real life...)
-->>-->
-->>-->I saw you managed to start your GIND file transfer program.
-->>-->
-->>-->I more or less finished the conversion of IND$FILE into 
-->an assembler 
-->>-->source; I could see the logic using a SVC trace.
-->>-->
-->>-->I'd like to convert it into a GCIC task,so all the logic of 
-->>-->host-3270 file transfer would already be present (CUT and DFT).
-->>-->
-->>-->Rather a hard task I think; but perhaps with your help I 
-->could try.
-->>-->
-->>-->IND$FILE uses DMSCCSVC functions to 'talk' to 3270; 
-->unfortunately 
-->>-->the module DMSCCS isn't available as source but only as TEXT (I 
-->>-->guess it was written in PL/S).
-->>-->
-->>-->But surely you already resolved these problems in GCIND.
-->>-->
-->>-->Any help wolud be welcome.
-->>-->
-->>-->Regards.
-->>-->
-->>-->Paulo
-->>-->
-->>-->>Hi Paulo -
-->>-->>
-->>-->>I think I started to figured it out.....
-->>-->>
-->>-->>I am rewriting ny trace routine and using My Emulator on
-->>-->VM/SP5 to do
-->>-->>traces I also downloaded the X3270 'C" code and am 
-->doing a bit of 
-->>-->>reverse engineering.
-->>-->> 
-->>-->>I have figured out what the first five bytes are in the 
-->first field.
-->>-->>So far I am only analyzing what the PC sends to the host...
-->>-->>
-->>-->>Also how the chksum and the length fields are built
-->>-->>
-->>-->>
-->>-->>Found this in the X3270 code.
-->>-->>
-->>-->>#define O_UP_DATA_CODE 2 /* offset to data code */      
-->>-->Byte 1 of data
-->>-->>#define O_UP_FRAME_SEQ 3 /* offset to frame sequence */
-->>-->Byte 2 of data
-->>-->>#define O_UP_CSUM 4 /* offset to checksum */            
-->>-->Byte 3 of data
-->>-->>#define O_UP_LEN 5 /* offset to length */               
-->>-->Bytes 4-5 of data
-->>-->>#define O_UP_DATA 7 /* offset to start of data */       
-->>-->First byte of real
-->>-->>data (could be a code)
-->>-->>#define O_UP_MAX (1919 - O_UP_DATA) /* max upload data *
-->>-->>
-->>-->>I also found the routine where it builds the checksum and the 
-->>-->>length
-->>-->>
-->>-->>It really is offset and not absolute. But the question is
-->>-->from where in
-->>-->>the buffer.
-->>-->>
-->>-->>My new logic says that the positons for the length are
-->>-->offset 3&4 or
-->>-->>absolute 4&5 Of the data fld - which itself is an offset to
-->>-->something
-->>-->>in the buffer.
-->>-->>
-->>-->>Using the defines as a starting point and my trace and the
-->>-->routine in
-->>-->>the C code that builds the buffer
-->>-->>
-->>-->>The number that I get from the routine is the total data
-->>-->length(from my
-->>-->>trace) of the fld Minus the cursor position on the screen. 
-->>-->(again from
-->>-->>the
-->>-->>trace) That is the number that they are putting in bytes  4-5
-->>-->>
-->>-->>Used a combination of my trace and the "C" to figure that out.
-->>-->>
-->>-->>Actually wrote the small 'c' program and ran it in
-->>-->debugging mode with
-->>-->>the loop to see what those number meant. (had to install
-->>-->the "C" but
-->>-->>that was not a problem.
-->>-->>
-->>-->>I am pretty sure that I have that part right now.
-->>-->>
-->>-->>I am going back to working on the trace, and that should
-->>-->take me until
-->>-->>tomorrow to get it working properly in both directions.
-->>-->>
-->>-->>I'll need that for the rest of the reverse engineering
-->>-->>
-->>-->>Still need to undertand the ACK/NAK process And the end of
-->>-->record process.
-->>-->>
-->>-->>and
-->>-->>
-->>-->>Since there is only one 3270 fld in the buffer-- the 
-->rest of the 
-->>-->>breaking down of the data into records must be dependent on
-->>-->codes in
-->>-->>the data field
-->>-->>
-->>-->>I will check that after I get the trace working properly.
-->>-->>Problem is that I will hae to relean "C" for that.
-->>-->>
-->>-->>As soon as I have a real trace in both directions I'll send
-->>-->it to you
-->>-->>if you want.
-->>-->>
-->>-->>Did you download the "C" code for the X-3270. I really
-->>-->would like to
-->>-->>pick your brain there.
-->>-->>My "C" is very insuffeceint
-->>-->>
-->>-->>But this is a lot of fun ---- and work
-->>-->>
-->>-->>Any help or pointers as always are appreciated.
-->>-->>
-->>-->>Roc
-->>-->>
-->>-->
-->>
-->
-->