I may have caused an RACF violation

This forum provides the support of Dezhi Mainframe systems. Please post your questions about logon, usage of our mainframe environment.

Moderators: sysprog, prino, sfan, steve-myers, Tim001

I may have caused an RACF violation

Postby viridian » Fri 15 Nov 2013, 07:36

Username VIRIDIA

I happened to notice the file SYSFAN.FANDEZHI.ASM which I thought represented the "approved" proc for accessing Assembler on this system, so I tried to view it in order to see if it was, but it apparently was empty, and - by accident - I looked at the system log to look for something else and it shows in the system log that I tripped something. Apparently that is not what I thought it was and it's not a public file. Please forgive me for this error, I do not see anything on what the approved method of assembling programs are. There is lots of exact info on what procs to use for COBOL and PL/1 but nothing for assembler.

The thing is noticing my username in the system log with what looks like a big violation flag scared me so much that it made me forget what I was looking for in the first place!
viridian
 
Posts: 4
Joined: Fri 15 Nov 2013, 07:29

Re: I may have caused an RACF violation

Postby steve-myers » Fri 15 Nov 2013, 08:24

The data set contains programs the admins use to maintain the system.

The "approved" method to assemble Assembler programs is to use the procedures in SYS1.PROCLIB; either ASMAxx or HLASMxx. I doubt the ASMFxx procs will actually work any more.

I sent via XMIT to your ID a somewhat different solution to your lm program.
steve-myers
 
Posts: 452
Joined: Tue 04 May 2010, 15:43

Re: I may have caused an RACF violation

Postby viridian » Fri 15 Nov 2013, 10:39

steve-myers wrote:The data set contains programs the admins use to maintain the system.

The "approved" method to assemble Assembler programs is to use the procedures in SYS1.PROCLIB; either ASMAxx or HLASMxx. I doubt the ASMFxx procs will actually work any more.

I sent via XMIT to your ID a somewhat different solution to your lm program.


Thanks. My experience was mostly batch MVS and CONMAN on DOS VS/E. The market for BAL programmers kind of dried up when the PC came around, and this ISPF stuff is all new to me, but I'm kinda really surprised how it comes back. Windows even comes with a hex calculator, I don't know if you ever worked with assembly, but if you did, you probably remember the days when you did hex arithmetic by writing address calculations on greenbar listings. You got a program dump and a register dump and you did the calculations from the dump

And this place isn't even that automated. IBM's been running a bunch of videos on YouTube where they're, I can't think of the exact word, 'hybridizing' Windows with CICS so that you have tools that you use on a Windows PC that allow you to look at a mainframe as if it was another PC, and the jobs and partitions like directories or files in a windows folder, and just add and drop regions, partitions and events as easy as you move, add or delete files in explorer.

I'd always thought of CICS as being mostly 'green screen' stuff; I remember one city had 3270 terminals in the assessor's office if you wanted to look at property tax records, and they had a list of the transcodes to use for different functions. I think they had a pretty smart system's programmer, I knew about the CSSF transaction but he gimmicked the system somehow, signing off a terminal didn't matter, apparently they had it fixed so that you could still run things even if you weren't signed on, or else, I guess when you pushed a key when signed off it automatically signed some terminals back on.

Then I saw this video from IBM Hursley and it just made my jaw drop:

https://www.youtube.com/watch?v=EDkVuqbFVgM

So forgive me if I'm a little rusty, I haven't done a lot of mainframe work over the past few years. But I have the suspicion it's like riding a bicycle, you forget it until you need it again, and maybe you're wobbly for 30 seconds, but then it comes right back.
viridian
 
Posts: 4
Joined: Fri 15 Nov 2013, 07:29

Re: I may have caused an RACF violation

Postby steve-myers » Fri 15 Nov 2013, 11:07

viridian wrote:... Thanks. My experience was mostly batch MVS and CONMAN on DOS VS/E. The market for BAL programmers kind of dried up when the PC came around, and this ISPF stuff is all new to me, but I'm kinda really surprised how it comes back. Windows even comes with a hex calculator, I don't know if you ever worked with assembly, but if you did, you probably remember the days when you did hex arithmetic by writing address calculations on greenbar listings. You got a program dump and a register dump and you did the calculations from the dump ...
I've done Assembly from OS/360 through z/OS; I've done all that. In the 1980s and 1990s there were a few calculators that could do hex arithmetic, though I suppose the Windows calculators kind of killed them off. Last I looked (6 or 7years ago) they had disappeared.

z/OS assembler is somewhat different than z/VSE assembler. The instructions are all the same, of course, but the macros are different to much different.
steve-myers
 
Posts: 452
Joined: Tue 04 May 2010, 15:43

Re: I may have caused an RACF violation

Postby viridian » Fri 15 Nov 2013, 11:10

steve-myers wrote:The data set contains programs the admins use to maintain the system.

The "approved" method to assemble Assembler programs is to use the procedures in SYS1.PROCLIB; either ASMAxx or HLASMxx. I doubt the ASMFxx procs will actually work any more.

I sent via XMIT to your ID a somewhat different solution to your lm program.


I'll bet it's great being a systems programmer, you get to look at everyone else's stuff, and sometimes you even get to tell them when they're doing something wrong!

This may sound stupid, but how do I get an XMIT file? I tried typing RECV at the TSO ready prompt but that's not a valid program name. Ahh, 'Receive'. That works. But you'd think it would tell you, if the sender doesn't you could have lots of files waiting in wherever they are.

I think XMIT might have come around after I got out of the mainframe business for greener pa$tures in PC work. And I know VM had the ability to send files to virtual readers and punches, but I can't find it and if you hadn't mentioned it I'd never have known I was sent anything. I tried using SDSF (I keep thinking that name was just picked by someone running their fingers on the keyboard), but it's not in a hold, input or output queue. Where do I find it and how to I read it?

Coming up, new IBM functionality with new programs ASDF, ERTY, UIOP, DFGH, ZXCV, and the all-powerful VBNM. And a new batch system called WER because it doesn't use Queues.
Last edited by viridian on Fri 15 Nov 2013, 11:33, edited 3 times in total.
viridian
 
Posts: 4
Joined: Fri 15 Nov 2013, 07:29

Re: I may have caused an RACF violation

Postby viridian » Fri 15 Nov 2013, 11:23

steve-myers wrote:z/OS assembler is somewhat different than z/VSE assembler. The instructions are all the same, of course, but the macros are different to much different.


Yeah, I kind of remember. You had a whole bunch of macros for opening files and such on DOS, then when you go to MVS and later VS/1 now you have JCL where you name files and then you have a whole new set of file routines and everything changes. DOS called the C equivalent of malloc() GETVIS and then when they went to VS/1 they changed it to GETMAIN. And so on and so forth. it kind of struck me as funny that the COMRG function, where you have a small parameter area available for programs to use, was not only in IBM Mainframe DOS but in PC DOS too.

I looked at your program. I don't even recognize 1/2 of the macros you're using, and the function of SvC 99, it's probably the most famous semi-undocumented function in OS/VS1.

You know, I never even knew that TSO is implemented as a fake on the batch system, as far as batch is concerned, TSO is just another batch program that is talking to a terminal, and your terminal is just a job running in batch. It's amazing to see your terminal session is a running job that hasn't yet finished, but when you have a major event something gets done on your JES2 job listing. Your terminal login is just a batch //yourname JOB card, and everything else is just more batch commands.

Or ISPF is, anyway. Strange. Like waking up one day and discovering your life was all simulated, and you actually are soaking naked and wet in a large pod with wires in your arms and a thing stuck in the back of your head...
viridian
 
Posts: 4
Joined: Fri 15 Nov 2013, 07:29

Re: I may have caused an RACF violation

Postby steve-myers » Fri 15 Nov 2013, 13:40

viridian wrote:You know, I never even knew that TSO is implemented as a fake on the batch system, as far as batch is concerned, TSO is just another batch program that is talking to a terminal, and your terminal is just a job running in batch. It's amazing to see your terminal session is a running job that hasn't yet finished, but when you have a major event something gets done on your JES2 job listing. Your terminal login is just a batch //yourname JOB card, and everything else is just more batch commands.

Or ISPF is, anyway. Strange. Like waking up one day and discovering your life was all simulated, and you actually are soaking naked and wet in a large pod with wires in your arms and a thing stuck in the back of your head...

Actually, the TSO "job" more closely resembles a start task "job" than a batch "job." The TSO "job" has one step; the DD statements in the logon procedure are more in the nature of an initial start that is modified by dynamic allocation as the session proceeds. The relatively long delay after the last of the annoying screens that no one seems to actually read is occupied, in part, by allocating additional data sets and starting ISPF.

The group of macros starting with IKJPARM through IKJENDP define the contents of a command line; your LM program has a similar group, though more deeply buried in the program. They actually define two things; the format of the command line and the format of the output area created by IKJPARS and returned to your program. IEFZB4D0 defines the format of the data areas sent to the MVS version of SVC 99, IEFZB4D2 defines the "keys" sent in the IEFZB4D0 data areas to IKJPARS. DCBD describes the data in a DCB, CVT describes the data in the CVT (Communications Vector Table), a large data area in shared storage that has a lot of system related data. The only CVT data used in the program is the address of the TSO IKJPARS service routine and the TSO IKJEFF02 message builder routine. IHAPDS describes the format of a directory entry; the directory entry has fields alternate data for ISPF statistics. IKJIOPL and IKJCPPL are TSO data areas; when TSO starts a command it sends the IKJCPPL data area to the command in place of the parameter list sent to a batch program. The IKJPPL macro defines the parameter list sent to IKJPARS; it is extended to form the work area for the program. Your LM program has storage for a PPL embedded in its work area; the odds are it is incorrect, by the way, but it's probably OK; the extra word is rarely used.

There is a fundamental difference between the C library storage management malloc function and GETMAIN in MVS. malloc allocates storage so it can be released by specifying the address of the allocated storage. GETMAIN does no such thing; when you FREEMAIN storage you give an address and a length. FREEMAIN makes sure you're not screwing anything up. FREEMAIN does storage extent consolidation; the C library free function is not required by the standard to do this; the extent released by free joins the list of free extents, but it may not be connected to adjoining free extents.

In many ways, other than the use of TSO specific services, a TSO command functions much like a batch program; it uses standard MVS data management services (OPEN, CLOSE, GET, PUT etc., etc.) the same way they are used in batch programs. You can discover more by reading the code yourself.
steve-myers
 
Posts: 452
Joined: Tue 04 May 2010, 15:43

Re: I may have caused an RACF violation

Postby steve-myers » Sat 16 Nov 2013, 02:03

viridian wrote:... This may sound stupid, but how do I get an XMIT file? I tried typing RECV at the TSO ready prompt but that's not a valid program name. Ahh, 'Receive'. That works. But you'd think it would tell you, if the sender doesn't you could have lots of files waiting in wherever they are.

I think XMIT might have come around after I got out of the mainframe business for greener pa$tures in PC work. And I know VM had the ability to send files to virtual readers and punches, but I can't find it and if you hadn't mentioned it I'd never have known I was sent anything. I tried using SDSF (I keep thinking that name was just picked by someone running their fingers on the keyboard), but it's not in a hold, input or output queue. Where do I find it and how to I read it? ...
The intended goal of XMIT/RECEIVE is to exchange data with a different system. It's been in VM for a long time, and the data that is exchanged is the same for both VM and MVS. There is a notification capability, but it depends on a "standard" (in the sense that the exit source is in SHASSAMP) JES2 exit, and I think it only works if the input comes from a different system. But I don't think the exit is installed in the Fandezhi system, and we don't do JES2 networking so it's moot.

The original name of SDSF was SYSLOG Display and Search Facility, but it morphed pretty quickly into a more generalized JES2 (and in more recent releases JES3) display facility.
steve-myers
 
Posts: 452
Joined: Tue 04 May 2010, 15:43

Re: I may have caused an RACF violation

Postby JNicoll » Sun 08 Dec 2013, 23:44

viridian wrote:I tried using SDSF ... but it's not in a hold, input or output queue. Where do I find it and how to I read it?


I have some ancient notes which tell me that:

Special characters for looking at various queues are:
* - jobs on jcl conversion queue
# - STC things only
$ - TSU things only
! - hard copy queue
@ - jobs waiting for transmission or spool offload

so I think if in sdsf you do something like: i@ or o@
you will possibly see xmit files waiting to be sent to another node or those that have arrived at this node (those that don't need to be sent to another node will be there too). I'm not sure that you can actually read them in a meaningful way on the spool. You have to run a RECEIVE to move the data from the spool to a dataset.
- it was just my opinion!
JNicoll
 
Posts: 1
Joined: Thu 05 Dec 2013, 23:12
Location: Edinburgh, Scotland

Re: I may have caused an RACF violation

Postby steve-myers » Mon 09 Dec 2013, 01:36

Actually, none of your ideas would work. The SYSOUT data set created by XMIT belongs to the job/TSO session that created the data set. Even if you know you have a data set the RECEIVE command will get, finding it in SDSF is not so easy unless you know who sent it. If the job/TSO session is still active when you try to find it in SDSF, the queue names you posted should work. If the job/TSO session has ended, the job/TSO session is in the JES2 "hardcopy" queue.

Your "transmission or spool offload" queue, more properly, is just the SPOOL offload queue; it has nothing to do with data being sent by the XMIT command. Jobs in the SPOOL offload queue are processed by offload job transmitter and SYSOUT transmitter tasks in JES2.
steve-myers
 
Posts: 452
Joined: Tue 04 May 2010, 15:43

Re: I may have caused an RACF violation

Postby rsilver » Mon 09 Dec 2013, 03:21

steve-myers wrote:Actually, none of your ideas would work. The SYSOUT data set created by XMIT belongs to the job/TSO session that created the data set. Even if you know you have a data set the RECEIVE command will get, finding it in SDSF is not so easy unless you know who sent it. If the job/TSO session is still active when you try to find it in SDSF, the queue names you posted should work. If the job/TSO session has ended, the job/TSO session is in the JES2 "hardcopy" queue.

Your "transmission or spool offload" queue, more properly, is just the SPOOL offload queue; it has nothing to do with data being sent by the XMIT command. Jobs in the SPOOL offload queue are processed by offload job transmitter and SYSOUT transmitter tasks in JES2.


Working in a very large mainframe environment currently on multiple systems/LPARs and here are some more notes on Transmit (Xmit) and Receive. When you/someone else transmits a file or message to anoter NODEid (NODEid=z/OS system or LPAR) ...a JES message will be displayed on sending NODEid

20.22.21 TSU10354 $HASP546 RSILVER(TSU49776 from TSO03) SYSTEM OUTPUT RECEIVED AT TSO09 CN(INTERNAL)

The red Highlight above will show up in SDSF on receiving TSO09 in SDSF/ST with JOBNAME (RSILVER) JOBID(TSU10354) QUEUE(PRINT) DEST(RSILVER). . And the jobs will have DDNAMES as SYS##### were the XMIT is located in IEBCOPY format. On Fandezhi because there is only 1 NODEid N1 you wont see the JES messages. Also, remember in SDSF/ST make sure you have JOBID filter set to FILTER JOBID EQ *. This will show both TSU (TSO jobs) and JOB (batch jobs).

If you want to try on Fandezhi, you can see the TRANSMITs under your TSU sessions as SYS#####. These are in IEBCOPY format and cannot be easily read. Transmit and Receive use IEBCOPY to send and receive datasets and messages.

Code: Select all
NP   DDNAME   StepName ProcStep DSID Owner    C Dest     
     JESMSGLG JES2                 2 RSILVER  K         
     JESJCL   JES2                 3 RSILVER  K         
     JESYSMSG JES2                 4 RSILVER  K         
     SYS00043 SYSUSER  SYSUSER   101 RSILVER  B RSILVER 
     SYS00046 SYSUSER  SYSUSER   102 RSILVER  B RSILVER 


All the information about TRANSMITs and RECEIVEs are maintained in a system data set named USERID.LOG.MISC

Code: Select all
VIEW       RSILVER.LOG.MISC                                Columns 00001 00072
Command ===>                                                  Scroll ===> 0005
=COLS> ----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
****** ***************************** Top of Data ******************************
000001 ------------------------------------------------------------------------
000002 TRANSMIT        RSILVER.EXEC                                  08 DEC 201
000003  TO:            N1       RSILVER                                       
000004        MEMBERS: LAMBO                                                   
000005 ------------------------------------------------------------------------
000006 TRANSMIT        **MESSAGE**                                   08 DEC 201
000007  TO:            N1       RSILVER                                       
000008 This is a test                                                         
000009 This is a test                                                         
000010 This is a test                                                         
000011 This is a test                                                         
000012 This is a test                                                         
000013 This is a test                                                         


TRANSMIT (Xmit) and Receive have been around a long time...based I believe on IBM SNA. I know working in a multiple platform environment AS/400 (iSeries, IBM system I) has similar commands WRKNETF, RCVNETF, and SNDNETF as does VM that was mentioned on this post. But, in lots of shops this has been replaced with NDM (Connect/Direct) or FTP. I believe the whole ideal behind using XMIT NODE.USERID was not to use a password and send across networks which made it a whole lot safer then FTP....

On Fandezhi, the TSO HELP PDS is not allocated to DD SYSHELP...so if you type TSO HELP TRANSMIT...you will get message IKJ56802I HELP NOT AVAILABLE+.View the 'SYS1.HELP' PDS and you can read about TRANSMIT 'SYS1.HELP(TRANSMIT)
' and RECEIVE 'SYS1.HELP(RECEIVE)'.
Richard (Rick) Silvers

E-mail.......: rsilvers@mebtel.net or rick_silvers@rsilvers.com
My Website: http://www.rsilvers.com/
Webmaster: http://main.nc.us/yancey/
rsilver
 
Posts: 92
Joined: Thu 10 Nov 2011, 13:08
Location: Mebane, NC USA

Re: I may have caused an RACF violation

Postby steve-myers » Tue 10 Dec 2013, 01:35

The origin of XMIT/RECEIVE is somewhat cloudy in my mind. In VM/370 I'm pretty sure they were connected with the development of RSCS machine to machine networking, which, in turn, stole quite a bit from HASP RJE for binary synchronous communication links. Actually, I think RSCS started as an RJE package, possibly as early as CP67, and stole HASP RJE code for the purpose. Somewhat later JES2 - HASP by another name - stole stuff from RSCS machine to machine networking to build JES2 NJE so JES2 could connect to the VNET network built from RSCS. The RSCS article in Wikpedia claims the reverse: JES2 NJE code and the inter system protocol went into RSCS. I don't know which is true. The TSO version of XMIT/RECEIVE is considerably different than the VM/370 version since VM/370 does not have the IEBCOPY program or PDS data sets as they are known in MVS.

Someone mentioned that XMIT/RECEIVE communicate IEBCOPY data. This is true for PDS/PDSE data sets, but sequential data sets are sent as augmented 80 byte logical records. No compression.

Well, this has diverged far from the original topic; I doubt the topic starter intended for this thread to become a history discussion!
steve-myers
 
Posts: 452
Joined: Tue 04 May 2010, 15:43


Return to Dezhi systems: Mainframe

Who is online

Users browsing this forum: No registered users and 0 guests